[要約] RFC 5191は、ネットワークアクセスの認証を行うためのプロトコルであり、PANAと呼ばれます。このRFCの目的は、ネットワークへのアクセス時にセキュアな認証を提供することです。
Network Working Group D. Forsberg
Request for Comments: 5191 Nokia
Category: Standards Track Y. Ohba, Ed.
Toshiba
B. Patil
H. Tschofenig
Nokia Siemens Networks
A. Yegin
Samsung
May 2008
Protocol for Carrying Authentication for Network Access (PANA)
ネットワークアクセスの認証を実行するためのプロトコル（PANA）
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator.
このドキュメントでは、クライアントとアクセスネットワーク間のネットワークアクセス認証を可能にする拡張認証プロトコル（EAP）のネットワーク層トランスポートである、ネットワークアクセス（PANA）の認証を運ぶためのプロトコルを定義します。 EAP用語では、PANAはUDPベースのEAP下位層であり、EAPピアとEAPオーセンティケーターの間で実行されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Protocol Details ................................................7
4.1. Authentication and Authorization Phase .....................7
4.2. Access Phase ..............................................11
4.3. Re-Authentication Phase ...................................11
4.4. Termination Phase .........................................13
5. Processing Rules ...............................................13
5.1. Fragmentation .............................................13
5.2. Sequence Number and Retransmission ........................14
5.3. PANA Security Association .................................15
5.4. Message Authentication ....................................17
5.5. Message Validity Check ....................................17
5.6. PaC Updating Its IP Address ...............................19
5.7. Session Lifetime ..........................................19
6. Message Format .................................................20
6.1. IP and UDP Headers ........................................20
6.2. PANA Message Header .......................................20
6.3. AVP Format ................................................22
7. PANA Messages ..................................................24
7.1. PANA-Client-Initiation (PCI) ..............................27
7.2. PANA-Auth-Request (PAR) ...................................28
7.3. PANA-Auth-Answer (PAN) ....................................28
7.4. PANA-Termination-Request (PTR) ............................28
7.5. PANA-Termination-Answer (PTA) .............................29
7.6. PANA-Notification-Request (PNR) ...........................29
7.7. PANA-Notification-Answer (PNA) ............................29
8. AVPs in PANA ...................................................29
8.1. AUTH AVP ..................................................30
8.2. EAP-Payload AVP ...........................................30
8.3. Integrity-Algorithm AVP ...................................31
8.4. Key-Id AVP ................................................31
8.5. Nonce AVP .................................................31
8.6. PRF-Algorithm AVP .........................................32
8.7. Result-Code AVP ...........................................32
8.8. Session-Lifetime AVP ......................................32
8.9. Termination-Cause AVP .....................................33
9. Retransmission Timers ..........................................33
9.1. Transmission and Retransmission Parameters ................35
10. IANA Considerations ...........................................35
10.1. PANA UDP Port Number .....................................36
10.2. PANA Message Header ......................................36
10.2.1. Message Type ......................................36
10.2.2. Flags .............................................36
10.3. AVP Header ...............................................36
10.3.1. AVP Code ..........................................37
10.3.2. Flags .............................................37
10.4. AVP Values ...............................................37
10.4.1. Result-Code AVP Values ............................37
10.4.2. Termination-Cause AVP Values ......................38
11. Security Considerations .......................................38
11.1. General Security Measures ................................38
11.2. Initial Exchange .........................................40
11.3. EAP Methods ..............................................40
11.4. Cryptographic Keys .......................................40
11.5. Per-Packet Ciphering .....................................41
11.6. PAA-to-EP Communication ..................................41
11.7. Liveness Test ............................................41
11.8. Early Termination of a Session ...........................42
12. Acknowledgments ...............................................42
13. References ....................................................42
13.1. Normative References .....................................42
13.2. Informative References ...................................43
Providing secure network access service requires access control based on the authentication and authorization of the clients and the access networks. Client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication methods between the client and the access network.
安全なネットワークアクセスサービスを提供するには、クライアントとアクセスネットワークの認証と承認に基づくアクセス制御が必要です。クライアントからネットワークへの認証は、実施ポイントを通過するトラフィックフローをポリシングするために必要なパラメーターを提供します。クライアントとアクセスネットワーク間で認証方法を実行するには、プロトコルが必要です。
The scope of this work is identified as designing a network-layer transport for network access authentication methods. The Extensible Authentication Protocol (EAP) [RFC3748] provides such authentication methods. In other words, PANA carries EAP, which can carry various authentication methods. By the virtue of enabling the transport of EAP above IP, any authentication method that can be carried as an EAP method is made available to PANA and hence to any link-layer technology. There is a clear division of labor between PANA (an EAP lower layer), EAP, and EAP methods as described in [RFC3748].
この作業の範囲は、ネットワークアクセス認証方法のネットワーク層トランスポートの設計として識別されます。拡張認証プロトコル（EAP）[RFC3748]は、このような認証方法を提供します。つまり、PANAはEAPを伝送し、EAPはさまざまな認証方法を伝送できます。 IPを超えるEAPのトランスポートを有効にすることにより、EAPメソッドとして実行できるすべての認証方法をPANAで使用できるようになり、リンク層テクノロジで使用できるようになります。 [RFC3748]で説明されているように、PANA（EAP下位層）、EAP、およびEAPメソッドの間には、明確な分業があります。
Various environments and usage models for PANA are identified in Appendix A of [RFC4058]. Potential security threats for network-layer access authentication protocol are discussed in [RFC4016]. These have been essential in defining the requirements [RFC4058] of the PANA protocol. Note that some of these requirements are imposed by the chosen payload, EAP [RFC3748].
[RFC4058]の付録Aに、PANAのさまざまな環境と使用モデルが示されています。ネットワーク層アクセス認証プロトコルの潜在的なセキュリティ脅威については、[RFC4016]で説明されています。これらは、PANAプロトコルの要件[RFC4058]を定義する上で不可欠でした。これらの要件の一部は、選択したペイロードEAP [RFC3748]によって課されることに注意してください。
There are components that are part of a complete secure network access solution but are outside of the PANA protocol specification, including PANA Authentication Agent (PAA) discovery, authentication method choice, PANA Authentication Agent-Enforcement Point (PAA-EP) protocol, access control filter creation, and data traffic protection. These components are described in separate documents (see [RFC5193] and [RFC5192]).
完全なセキュアネットワークアクセスソリューションの一部であるが、PANA認証エージェント（PAA）の検出、認証方法の選択、PANA認証エージェント-実施ポイント（PAA-EP）プロトコル、アクセス制御など、PANAプロトコル仕様の範囲外のコンポーネントがあります。フィルターの作成、およびデータトラフィックの保護。これらのコンポーネントは、個別のドキュメントで説明されています（[RFC5193]および[RFC5192]を参照）。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語が使用されています。これらの単語は、多くの場合大文字です。このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
PANA Client (PaC):
PANAクライアント（PaC）：
The client side of the protocol that resides in the access device (e.g., laptop, PDA, etc.). It is responsible for providing the credentials in order to prove its identity (authentication) for network access authorization. The PaC and the EAP peer are colocated in the same access device.
アクセスデバイスに存在するプロトコルのクライアント側（ラップトップ、PDAなど）。ネットワークアクセス許可のID（認証）を証明するために、資格情報を提供します。 PaCとEAPピアは同じアクセスデバイスに配置されます。
PANA Authentication Agent (PAA):
PANA認証エージェント（PAA）：
The protocol entity in the access network whose responsibility it is to verify the credentials provided by a PANA client (PaC) and authorize network access to the access device. The PAA and the EAP authenticator (and optionally the EAP server) are colocated in the same node. Note the authentication and authorization procedure can, according to the EAP model, also be offloaded to the back end Authentication, Authorization, and Accounting (AAA) infrastructure.
PANAクライアント（PaC）によって提供される資格情報を検証し、アクセスデバイスへのネットワークアクセスを承認する責任があるアクセスネットワークのプロトコルエンティティ。 PAAとEAPオーセンティケーター（およびオプションでEAPサーバー）は同じノードに配置されます。認証と承認の手順は、EAPモデルに従って、バックエンドの認証、承認、およびアカウンティング（AAA）インフラストラクチャにオフロードすることもできます。
PANA Session:
PANAセッション：
A PANA session is established between the PANA Client (PaC) and the PANA Authentication Agent (PAA), and it terminates as a result of an authentication and authorization or liveness test failure, a message delivery failure after retransmissions reach maximum values, session lifetime expiration, an explicit termination message or any event that causes discontinuation of the access service. A fixed session identifier is maintained throughout a session. A session cannot be shared across multiple network interfaces.
PANAセッションがPANAクライアント（PaC）とPANA認証エージェント（PAA）の間に確立され、認証と承認または活性テストの失敗、再送信が最大値に達した後のメッセージ配信の失敗、セッションの有効期限の終了の結果として終了する、明示的な終了メッセージ、またはアクセスサービスの中断を引き起こすイベント。固定セッション識別子は、セッション全体を通じて維持されます。セッションは、複数のネットワークインターフェイス間で共有できません。
Session Lifetime:
セッションの存続期間：
A duration that is associated with a PANA session. For an established PANA session, the session lifetime is bound to the lifetime of the current authorization given to the PaC. The session lifetime can be extended by a new round of EAP authentication before it expires. Until a PANA session is established, the lifetime SHOULD be set to a value that allows the PaC to detect a failed session in a reasonable amount of time.
PANAセッションに関連付けられている期間。確立されたPANAセッションの場合、セッションの存続期間は、PaCに与えられた現在の承認の存続期間にバインドされます。セッションの有効期限は、有効期限が切れる前に、EAP認証の新しいラウンドによって延長できます。 PANAセッションが確立されるまで、ライフタイムは、PaCが失敗したセッションを妥当な時間内に検出できる値に設定する必要があります（SHOULD）。
Session Identifier:
セッション識別子：
This identifier is used to uniquely identify a PANA session on the PaC and the PAA. It is included in PANA messages to bind the message to a specific PANA session. This bidirectional identifier is allocated by the PAA in the initial request message and freed when the session terminates. The session identifier is assigned by the PAA and is unique within the PAA.
この識別子は、PaCおよびPAA上のPANAセッションを一意に識別するために使用されます。メッセージを特定のPANAセッションにバインドするために、PANAメッセージに含まれています。この双方向識別子は、初期要求メッセージでPAAによって割り当てられ、セッションが終了すると解放されます。セッションIDはPAAによって割り当てられ、PAA内で一意です。
PANA Security Association (PANA SA):
ぱな せくりｔｙ あっそしあちおん （ぱな さ）：
A PANA security association is formed between the PaC and the PAA by sharing cryptographic keying material and associated context. The formed duplex security association is used to protect the bidirectional PANA signaling traffic between the PaC and PAA.
PANAセキュリティアソシエーションは、PayCとPAAの間で、暗号化キー情報と関連するコンテキストを共有することによって形成されます。形成された二重セキュリティアソシエーションは、PaCとPAA間の双方向PANAシグナリングトラフィックを保護するために使用されます。
Enforcement Point (EP):
実施ポイント（EP）：
A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of access devices. The EP and the PAA may be colocated. EPs should prevent data traffic from and to any unauthorized client, unless that data traffic is either PANA or one of the other allowed traffic types (e.g., Address Resolution Protocol (ARP), IPv6 neighbor discovery, DHCP, etc.).
パケットごとの適用ポリシー（つまり、フィルター）がアクセスデバイスのインバウンドおよびアウトバウンドトラフィックに適用される、アクセスネットワーク上のノード。 EPとPAAは同じ場所に配置できます。 EPは、データトラフィックがPANAまたは他の許可されたトラフィックタイプ（アドレス解決プロトコル（ARP）、IPv6近隣探索、DHCPなど）のいずれかでない限り、不正なクライアントとの間のデータトラフィックを防止する必要があります。
Master Session Key (MSK):
マスターセッションキー（MSK）：
A key derived by the EAP peer and the EAP server and transported to the EAP authenticator [RFC3748].
EAPピアとEAPサーバーによって導出され、EAPオーセンティケーター[RFC3748]に転送されるキー。
For additional terminology definitions, see the PANA framework document [RFC5193].
その他の用語の定義については、PANAフレームワークドキュメント[RFC5193]を参照してください。
The PANA protocol is run between a client (PaC) and a server (PAA) in order to perform authentication and authorization for the network access service.
PANAプロトコルは、ネットワークアクセスサービスの認証と承認を実行するために、クライアント（PaC）とサーバー（PAA）の間で実行されます。
The protocol messaging consists of a series of requests and answers, some of which may be initiated by either end. Each message can carry zero or more AVPs (Attribute-Value Pairs) within the payload. The main payload of PANA is EAP, which performs authentication. PANA helps the PaC and PAA establish an EAP session.
プロトコルメッセージングは一連の要求と応答で構成されており、その一部は両端から開始できます。各メッセージは、ペイロード内で0個以上のAVP（属性と値のペア）を運ぶことができます。 PANAの主なペイロードは、認証を実行するEAPです。 PANAは、PaCとPAAがEAPセッションを確立するのに役立ちます。
PANA is a UDP-based protocol. It has its own retransmission mechanism to reliably deliver messages.
PANAはUDPベースのプロトコルです。メッセージを確実に配信するための独自の再送信メカニズムがあります。
PANA messages are sent between the PaC and PAA as part of a PANA session. A PANA session consists of distinct phases:
PANAメッセージは、PANAセッションの一部としてPaCとPAAの間で送信されます。 PANAセッションは、次の異なるフェーズで構成されています。
o Authentication and authorization phase: This is the phase that initiates a new PANA session and executes EAP between the PAA and PaC. The PANA session can be initiated by both the PaC and the PAA. The EAP payload (which carries an EAP method inside) is what is used for authentication. The PAA conveys the result of authentication and authorization to the PaC at the end of this phase.
o 認証および承認フェーズ：これは、新しいPANAセッションを開始し、PAAとPaCの間でEAPを実行するフェーズです。 PANAセッションは、PaCとPAAの両方で開始できます。 EAPペイロード（内部にEAPメソッドが含まれる）は、認証に使用されます。 PAAは、このフェーズの最後に、認証と承認の結果をPaCに伝えます。
o Access phase: After successful authentication and authorization, the access device gains access to the network and can send and receive IP traffic through the EP(s). At any time during this phase, the PaC and PAA may optionally send PANA notification messages to test liveness of the PANA session on the peer.
o アクセスフェーズ：認証と承認が成功すると、アクセスデバイスはネットワークにアクセスし、EPを介してIPトラフィックを送受信できます。このフェーズ中いつでも、PaCとPAAはオプションでPANA通知メッセージを送信して、ピアでのPANAセッションの活性をテストできます。
o Re-authentication phase: During the access phase, the PAA may, and the PaC should, initiate re-authentication if they want to update the PANA session lifetime before the PANA session lifetime expires. EAP is carried by PANA to perform re-authentication. This phase may be optionally triggered by both the PaC and the PAA without any respect to the session lifetime. The re-authentication phase is a sub-phase of the access phase. The session moves to this sub-phase from the access phase when re-authentication starts, and returns back there upon successful re-authentication.
o 再認証フェーズ：アクセスフェーズ中に、PAAは、PANAセッションの有効期限が切れる前にPANAセッションの有効期間を更新したい場合、PaCが再認証を開始する必要があります。 EAPはPANAによって実行され、再認証を実行します。このフェーズは、セッションの存続時間に関係なく、PaCとPAAの両方によってオプションでトリガーできます。再認証フェーズは、アクセスフェーズのサブフェーズです。再認証が開始されると、セッションはアクセスフェーズからこのサブフェーズに移動し、再認証が成功するとそこに戻ります。
o Termination phase: The PaC or PAA may choose to discontinue the access service at any time. An explicit disconnect message can be sent by either end. If either the PaC or the PAA disconnects without engaging in termination messaging, it is expected that either the expiration of a finite session lifetime or failed liveness tests would clean up the session at the other end.
o 終了フェーズ：PaCまたはPAAは、いつでもアクセスサービスを停止することを選択できます。明示的な切断メッセージは、どちらの側からも送信できます。 PaCまたはPAAのいずれかが終了メッセージに関与せずに切断した場合、有限のセッションライフタイムの期限切れまたは生存テストの失敗により、もう一方の端のセッションがクリーンアップされることが予想されます。
Cryptographic protection of messages between the PaC and PAA is possible as soon as EAP in conjunction with the EAP method exports a shared key. That shared key is used to create a PANA SA. The PANA SA helps generate per-message authentication codes that provide integrity protection and authentication.
EAP方式とEAPが共有キーをエクスポートするとすぐに、PaCとPAAの間のメッセージの暗号保護が可能になります。その共有キーは、PANA SAの作成に使用されます。 PANA SAは、整合性の保護と認証を提供するメッセージごとの認証コードの生成に役立ちます。
The following sections explain in detail the various phases of a PANA session.
次のセクションでは、PANAセッションのさまざまなフェーズについて詳しく説明します。
The main task of the authentication and authorization phase is to establish a PANA session and carry EAP messages between the PaC and the PAA. The PANA session can be initiated by either the PaC or the PAA.
認証および承認フェーズの主なタスクは、PANAセッションを確立し、PaCとPAAの間でEAPメッセージを伝送することです。 PANAセッションは、PaCまたはPAAのいずれかによって開始できます。
PaC-initiated Session:
PaCによって開始されたセッション：
When the PaC initiates a PANA session, it sends a PANA-Client-Initiation message to the PAA. When the PaC is not configured with an IP address of the PAA before initiating the PANA session, DHCP [RFC5192] is used as the default method for dynamically configuring the IP address of the PAA. Alternative methods for dynamically discovering the IP address of the PAA may be used for PaC-initiated sessions, but they are outside the scope of this specification. The PAA that receives the PANA-Client-Initiation message MUST respond to the PaC with a PANA-Auth-Request message.
PaCがPANAセッションを開始すると、PANA-Client-InitiationメッセージがPAAに送信されます。 PANAセッションを開始する前にPaCにPAAのIPアドレスが設定されていない場合、PAAのIPアドレスを動的に設定するデフォルトの方法としてDHCP [RFC5192]が使用されます。 PAAのIPアドレスを動的に検出する別の方法をPaCで開始されたセッションに使用できますが、これらはこの仕様の範囲外です。 PANA-Client-Initiationメッセージを受信するPAAは、PANA-Auth-RequestメッセージでPaCに応答する必要があります。
PAA-initiated Session:
PAAが開始したセッション：
When the PAA knows the IP address of the PaC, it MAY send an unsolicited PANA-Auth-Request to the PaC. The details of how PAA can learn the IP address of the PaC are outside the scope of this specification.
PAAがPaCのIPアドレスを知っている場合、PAAは非請求PANA-Auth-RequestをPaCに送信してもよい（MAY）。 PAAがPaCのIPアドレスを学習する方法の詳細は、この仕様の範囲外です。
A session identifier for the session is assigned by the PAA and carried in the initial PANA-Auth-Request message. The same session identifier MUST be carried in the subsequent messages exchanged between the PAA and PaC throughout the session.
セッションのセッション識別子はPAAによって割り当てられ、最初のPANA-Auth-Requestメッセージで伝達されます。同じセッション識別子は、セッション全体でPAAとPaCの間で交換される後続のメッセージで運ばれる必要があります。
When the PaC receives the initial PANA-Auth-Request message from a PAA, it responds with a PANA-Auth-Answer message, if it wishes to continue the PANA session. Otherwise, it silently discards the PANA-Auth-Request message.
PaCがPAAから最初のPANA-Auth-Requestメッセージを受信すると、PANAセッションを続行する場合は、PANA-Auth-Answerメッセージで応答します。それ以外の場合は、PANA-Auth-Requestメッセージを静かに破棄します。
The initial PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'S' (Start) bit set, regardless of whether the session is initiated by the PaC or the PAA. Non-initial PANA-Auth-Request and PANA-Auth-Answer messages as well as any other messages MUST NOT have the 'S' (Start) bit set.
最初のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージには、セッションがPaCとPAAのどちらで開始されたかに関係なく、「S」（開始）ビットが設定されている必要があります。先頭以外のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージ、およびその他のメッセージには、「S」（開始）ビットを設定してはいけません（MUST NOT）。
It is recommended that the PAA limit the rate at which it processes incoming PANA-Client-Initiation messages to provide robustness against denial of service (DoS) attacks. The details of rate limiting are outside the scope of this specification.
PAAが受信PANA-Client-Initiationメッセージを処理するレートを制限して、サービス拒否（DoS）攻撃に対する堅牢性を提供することをお勧めします。レート制限の詳細は、この仕様の範囲外です。
If a PANA SA needs to be established with use of a key-generating EAP method, the Pseudo-Random Function (PRF) and integrity algorithms to be used for PANA_AUTH_KEY derivation (see Section 5.3) and AUTH AVP calculation (see Section 5.4) are negotiated as follows: the PAA sends the initial PANA-Auth-Request carrying one or more PRF-Algorithm AVPs and one or more Integrity-Algorithm AVPs for the PRF and integrity algorithms supported by it, respectively. The PaC then selects one PRF algorithm and one integrity algorithm from these AVPs carried in the initial PANA-Auth-Request, and it responds with the initial PANA-Auth-Answer carrying one PRF-Algorithm AVP and one Integrity-Algorithm AVP for the selected algorithms. The negotiation is protected after the MSK is available, as described in Section 5.3.
鍵生成EAPメソッドを使用してPANA SAを確立する必要がある場合、PANA_AUTH_KEYの導出（セクション5.3を参照）およびAUTH AVPの計算（セクション5.4を参照）に使用する疑似ランダム関数（PRF）と整合性アルゴリズム次のようにネゴシエートされます。PAAは、1つ以上のPRFアルゴリズムAVPと、それがサポートするPRFおよび整合性アルゴリズム用の1つ以上の整合性アルゴリズムAVPを運ぶ最初のPANA-Auth-Requestをそれぞれ送信します。次に、PaCは、最初のPANA-Auth-Requestで伝送されるこれらのAVPから1つのPRFアルゴリズムと1つの整合性アルゴリズムを選択し、選択されたPRFアルゴリズムAVPと1つの整合性アルゴリズムAVPを伝送する最初のPANA-Auth-Answerで応答します。アルゴリズム。セクション5.3で説明されているように、MSKが使用可能になった後、ネゴシエーションは保護されます。
If the PAA wants to stay stateless in response to a PANA-Client-Initiation message, it doesn't include an EAP-Payload AVP in the initial PANA-Auth-Request message, and it should not retransmit the message on a timer. For this reason, the PaC MUST retransmit the PANA-Client-Initiation message until it receives the second PANA-Auth-Request message (not a retransmission of the initial one) from the PAA.
PAAがPANA-Client-Initiationメッセージに応答してステートレスを維持したい場合は、最初のPANA-Auth-RequestメッセージにEAP-Payload AVPが含まれていないため、タイマーでメッセージを再送信しないでください。このため、PaCは、PAAから2番目のPANA-Auth-Requestメッセージ（最初のメッセージの再送信ではない）を受信するまで、PANA-Client-Initiationメッセージを再送信する必要があります。
It is possible that both the PAA and the PaC initiate the PANA session at the same time, i.e., the PAA sends the initial PANA-Auth-Request message without solicitation while the PaC sends a PANA-Client-Initiation message. To resolve the race condition, the PAA MUST silently discard the PANA-Client-Initiation message received from the PaC after it has sent the initial PANA-Auth-Request message. The PAA uses the source IP address and the source port number of the PANA-Client-Initiation message to identify the PaC among multiple PANA-Client-Initiation messages sent from different PaCs.
PAAとPaCの両方が同時にPANAセッションを開始する可能性があります。つまり、PACがPANA-Client-Initiationメッセージを送信している間、PAAは要請なしに最初のPANA-Auth-Requestメッセージを送信します。競合状態を解決するために、PAAは、最初のPANA-Auth-Requestメッセージを送信した後、PaCから受信したPANA-Client-Initiationメッセージをサイレントに破棄する必要があります。 PAAは、PANA-Client-InitiationメッセージのソースIPアドレスとソースポート番号を使用して、異なるPaCから送信された複数のPANA-Client-InitiationメッセージからPaCを識別します。
EAP messages are carried in PANA-Auth-Request messages. PANA-Auth-Answer messages are simply used to acknowledge receipt of the requests. As an optimization, a PANA-Auth-Answer message sent from the PaC MAY include the EAP message. This optimization SHOULD NOT be used when it takes time to generate the EAP message (due to, e.g., intervention of human input), in which case returning an PANA-Auth-Answer message without piggybacking an EAP message can avoid unnecessary retransmission of the PANA-Auth-Request message.
EAPメッセージは、PANA-Auth-Requestメッセージで伝達されます。 PANA-Auth-Answerメッセージは、要求の受信を確認するために使用されます。最適化として、PaCから送信されたPANA-Auth-AnswerメッセージにEAPメッセージが含まれる場合があります。この最適化は、EAPメッセージの生成に時間がかかる場合（人間の入力の介入などにより）は使用しないでください。この場合、EAPメッセージをピギーバックせずにPANA-Auth-Answerメッセージを返すことで、PANAの不要な再送信を回避できます。 -Auth-Requestメッセージ。
A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-Auth-Answer messages following the initial PANA-Auth-Request and PANA-Auth-Answer messages (i.e., with the 'S' (Start) bit set), and MUST NOT be included in any other message, except during re-authentication procedures (see Section 4.3).
Nonce AVPは、最初のPANA-Auth-RequestおよびPANA-Auth-Answerメッセージに続く最初のPANA-Auth-RequestおよびPANA-Auth-Answerメッセージに含まれている必要があります（つまり、「S」（開始）ビットが設定されています）。 、および再認証手順中を除いて、他のメッセージに含めることはできません（セクション4.3を参照）。
The result of PANA authentication is carried in the last PANA-Auth-Request message sent from the PAA to the PaC. This message carries the EAP authentication result and the result of PANA authentication. The last PANA-Auth-Request message MUST be acknowledged with a PANA-Auth-Answer message. The last PANA-Auth-Request and PANA-Auth-Answer messages MUST have the 'C' (Complete) bit set, and any other message MUST NOT have the 'C' (Complete) bit set. Figure 1 shows an example sequence in the authentication and authorization phase for a PaC-initiated session.
PANA認証の結果は、PAAからPaCに送信された最後のPANA-Auth-Requestメッセージで伝達されます。このメッセージには、EAP認証の結果とPANA認証の結果が含まれます。最後のPANA-Auth-RequestメッセージはPANA-Auth-Answerメッセージで確認されなければなりません。最後のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージには「C」（完全）ビットが設定されている必要があり、その他のメッセージには「C」（完全）ビットが設定されていてはなりません（MUST NOT）。図1は、PaCで開始されたセッションの認証および許可フェーズのシーケンス例を示しています。
PaC PAA Message(sequence number)[AVPs]
---------------------------------------------------------------------
-----> PANA-Client-Initiation(0)
<----- PANA-Auth-Request(x)[PRF-Algorithm,Integrity-Algorithm]
// The 'S' (Start) bit set
-----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm]
// The 'S' (Start) bit set
<----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload]
-----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP
-----> PANA-Auth-Request(y)[EAP-Payload]
<----- PANA-Auth-Answer(y)
<----- PANA-Auth-Request(x+2)[EAP-Payload]
-----> PANA-Auth-Answer(x+2)[EAP-Payload]
// Piggybacking EAP
<----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload,
Key-Id, Session-Lifetime, AUTH]
// The 'C' (Complete) bit set
-----> PANA-Auth-Answer(x+3)[Key-Id, AUTH]
// The 'C' (Complete) bit set
Figure 1: Example sequence for the authentication and authorization phase for a PaC-initiated session ("Piggybacking EAP" is the case in which an EAP-Payload AVP is carried in PAN)
図1：PaCで開始されたセッションの認証および承認フェーズのシーケンスの例（「ピギーバッキングEAP」は、EAPペイロードAVPがPANで実行される場合です）
If a PANA SA needs to be established with use of a key-generating EAP method and an MSK is successfully generated, the last PANA-Auth-Request message with the 'C' (Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP for the first derivation of keys in the session, and any subsequent message MUST contain an AUTH AVP.
鍵生成EAPメソッドを使用してPANA SAを確立する必要があり、MSKが正常に生成された場合、「C」（完全）ビットが設定された最後のPANA-Auth-RequestメッセージにKey-Id AVPが含まれている必要があり、セッション内の鍵の最初の派生に対するAUTH AVP、および後続のメッセージにはAUTH AVPが含まれている必要があります。
EAP authentication can fail at a pass-through authenticator without sending an EAP Failure message [RFC4137]. When this occurs, the PAA SHOULD silently terminate the session, expecting that a session timeout on the PaC will clean up the state on the PaC.
EAP認証は、EAP失敗メッセージ[RFC4137]を送信せずにパススルー認証システムで失敗する可能性があります。これが発生した場合、PAAは、PaCのセッションタイムアウトによりPaCの状態がクリーンアップされることを想定して、セッションをサイレントに終了する必要があります（SHOULD）。
There is a case where EAP authentication succeeds with producing an EAP Success message, but network access authorization fails due to, e.g., authorization rejected by a AAA server or authorization locally rejected by the PAA. When this occurs, the PAA MUST send the last PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED. If an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer messages with the 'C' (Complete) bit set MUST be protected with an AUTH AVP and carry a Key-Id AVP. The PANA session MUST be terminated immediately after the last PANA-Auth message exchange.
EAP認証は成功し、EAP Successメッセージを生成しますが、AAAサーバーによって拒否された許可やPAAによってローカルで拒否された許可などにより、ネットワークアクセス許可が失敗する場合があります。これが発生した場合、PAAは最後のPANA-Auth-Requestを結果コードPANA_AUTHORIZATION_REJECTEDとともに送信する必要があります。 MSKが利用可能な場合、「C」（完全）ビットが設定された最後のPANA-Auth-RequestおよびPANA-Auth-Answerメッセージは、AUTH AVPで保護され、Key-Id AVPを伝送する必要があります。 PANAセッションは、最後のPANA-Authメッセージ交換の直後に終了しなければなりません（MUST）。
For reasons described in Section 3 of [RFC5193], the PaC may need to reconfigure the IP address after a successful authentication and authorization phase to obtain an IP address that is usable for exchanging data traffic through EP. In this case, the PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request messages in the authentication and authorization phase to indicate to the PaC the need for IP address reconfiguration. How IP address reconfiguration is performed is outside the scope of this document.
[RFC5193]のセクション3で説明されている理由により、認証と承認のフェーズが成功した後、EPを介したデータトラフィックの交換に使用できるIPアドレスを取得するために、PaCがIPアドレスを再構成する必要がある場合があります。この場合、PAAは、認証および許可フェーズでPANA-Auth-Requestメッセージの「I」（IP Reconfiguration）ビットを設定して、PaCにIPアドレスの再構成の必要性を示します。 IPアドレスの再構成の実行方法は、このドキュメントの範囲外です。
Once the authentication and authorization phase successfully completes, the PaC gains access to the network and can send and receive IP data traffic through the EP(s), and the PANA session enters the access phase. In this phase, PANA-Notification-Request and PANA-Notification-Answer messages with the 'P' (Ping) bit set (ping request and ping answer messages, respectively) can be used for testing the liveness of the PANA session on the PANA peer. Both the PaC and the PAA are allowed to send a ping request to the communicating peer whenever they need to ensure the availability of the session on the peer, and they expect the peer to return a ping answer message. The ping request and answer messages MUST be protected with an AUTH AVP when a PANA SA is available. A ping request MUST NOT be sent in the authentication and authorization phase, re-authentication phase, and termination phase.
認証と承認のフェーズが正常に完了すると、PaCはネットワークにアクセスし、EPを介してIPデータトラフィックを送受信できるようになり、PANAセッションはアクセスフェーズに入ります。このフェーズでは、「P」（Ping）ビットが設定されたPANA-Notification-RequestメッセージとPANA-Notification-Answerメッセージ（それぞれping要求メッセージとping応答メッセージ）を使用して、PANAでのPANAセッションの活性をテストできます。ピア。 PaCとPAAはどちらも、ピアでのセッションの可用性を確認する必要があるときはいつでも、通信するピアにping要求を送信でき、ピアがping応答メッセージを返すことを期待しています。 PANA SAが使用可能な場合、ping要求および応答メッセージはAUTH AVPで保護する必要があります。 ping要求は、認証および承認フェーズ、再認証フェーズ、および終了フェーズで送信してはなりません（MUST NOT）。
Implementations MUST limit the rate of performing this test. The PaC and the PAA can handle rate limitation on their own, they do not have to perform any coordination with each other. There is no negotiation of timers for this purpose. Additionally, an implementation MAY rate limit processing the incoming ping requests. It should be noted that if a PAA or PaC that considers its connectivity lost after a relatively small number of unresponsive pings is coupled with a peer that is aggressively rate limiting the ping request and answer messages, then false-positives could result. Therefore, a PAA or PaC should not rely on frequent ping operation to quickly determine loss of connectivity.
実装は、このテストを実行する速度を制限する必要があります。 PaCとPAAは、独自にレート制限を処理でき、相互に調整を行う必要はありません。この目的のためのタイマーのネゴシエーションはありません。さらに、実装は、着信ping要求を処理するレート制限を行う場合があります。比較的少数の応答しないpingの後に接続が失われたと見なすPAAまたはPaCが、ping要求と応答メッセージを積極的にレート制限しているピアと結合された場合、誤検知が発生する可能性があることに注意してください。したがって、PAAまたはPaCは頻繁なping操作に依存して接続の喪失を迅速に判断するべきではありません。
The PANA session in the access phase can enter the re-authentication phase to extend the current session lifetime by re-executing EAP. Once the re-authentication phase successfully completes, the session re-enters the access phase. Otherwise, the session is terminated.
アクセスフェーズのPANAセッションは、再認証フェーズに入り、EAPを再実行して現在のセッションの有効期間を延長できます。再認証フェーズが正常に完了すると、セッションはアクセスフェーズに再び入ります。それ以外の場合、セッションは終了します。
When the PaC initiates re-authentication, it sends a PANA-Notification-Request message with the 'A' (re-Authentication) bit set (a re-authentication request message) to the PAA. This message MUST contain the session identifier assigned to the session being re-authenticated. If the PAA already has an established PANA session for the PaC with the matching session identifier, it MUST first respond with a PANA-Notification-Answer message with the 'A' (re-Authentication) bit set (a re-authentication answer message), followed by a PANA-Auth-Request message that starts a new EAP authentication. If the PAA cannot identify the session, it MUST silently discard the message. The first PANA-Auth-Request and PANA-Auth-Answer messages in the re-authentication phase MUST have the 'S' (Start) bit cleared and carry a Nonce AVP.
PaCが再認証を開始すると、「A」（再認証）ビットが設定されたPANA-Notification-Requestメッセージ（再認証要求メッセージ）がPAAに送信されます。このメッセージには、再認証されるセッションに割り当てられたセッション識別子が含まれている必要があります。 PAAが、一致するセッションIDを持つPaCの確立されたPANAセッションをすでに持っている場合、最初に「A」（再認証）ビットが設定されたPANA-Notification-Answerメッセージで応答する必要があります（再認証応答メッセージ） 、その後に新しいEAP認証を開始するPANA-Auth-Requestメッセージが続きます。 PAAがセッションを識別できない場合は、メッセージを静かに破棄する必要があります。再認証フェーズの最初のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージでは、「S」（開始）ビットをクリアして、Nonce AVPを伝送する必要があります。
The PaC may receive a PANA-Auth-Request before receiving the answer to its outstanding re-authentication request message. This condition can arise due to packet re-ordering or a race condition between the PaC and PAA when they both attempt to engage in re-authentication. The PaC MUST keep discarding the received PANA-Auth-Requests until it receives the answer to its request.
PaCは、未処理の再認証要求メッセージに対する応答を受信する前に、PANA-Auth-Requestを受信する場合があります。この状態は、パケットの並べ替え、またはPaCとPAAの両方が再認証を試みたときに発生する可能性があります。 PaCは、リクエストに対する応答を受信するまで、受信したPANA-Auth-Requestsを破棄し続けなければなりません（MUST）。
When the PAA initiates re-authentication, it sends a PANA-Auth-Request message containing the session identifier for the PaC. The PAA MUST initiate EAP re-authentication before the current session lifetime expires.
PAAは再認証を開始すると、PaCのセッション識別子を含むPANA-Auth-Requestメッセージを送信します。 PAAは、現在のセッションの有効期限が切れる前にEAP再認証を開始する必要があります。
Re-authentication of an ongoing PANA session MUST NOT reset the sequence numbers.
進行中のPANAセッションの再認証はシーケンス番号をリセットしてはいけません。
For any re-authentication, if there is an established PANA SA, re-authentication request and answer messages and subsequent PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected with an AUTH AVP. The final PANA-Auth-Request and PANA-Auth-Answer messages and any subsequent PANA message MUST be protected by using the key generated from the latest EAP authentication.
再認証の場合、確立されたPANA SAがあれば、再認証要求と応答メッセージ、および後続のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージは、AUTH AVPで保護する必要があります。最後のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージ、および後続のPANAメッセージは、最新のEAP認証から生成されたキーを使用して保護する必要があります。
PaC PAA Message(sequence number)[AVPs]
---------------------------------------------------------------------
-----> PANA-Notification-Request(q)[AUTH]
// The 'A' (re-Authentication) bit set
<----- PANA-Notification-Answer(q)[AUTH]
// The 'A' (re-Authentication) bit set
<----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH]
-----> PANA-Auth-Answer(p)[AUTH, Nonce]
-----> PANA-Auth-Request(q+1)[EAP-Payload, AUTH]
<----- PANA-Auth-Answer(q+1)[AUTH]
<----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH]
-----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH]
<----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload,
Key-Id, Session-Lifetime, AUTH]
// The 'C' (Complete) bit set
-----> PANA-Auth-Answer(p+2)[Key-Id, AUTH]
// The 'C' (Complete) bit set
Figure 2: Example sequence for the re-authentication phase initiated by PaC
図2：PaCによって開始された再認証フェーズのシーケンスの例
A procedure for explicitly terminating a PANA session can be initiated either from the PaC (i.e., disconnect indication) or from the PAA (i.e., session revocation). The PANA-Termination-Request and PANA-Termination-Answer message exchanges are used for disconnect-indication and session-revocation procedures.
PANAセッションを明示的に終了する手順は、PaC（つまり、切断表示）またはPAA（つまり、セッションの取り消し）から開始できます。 PANA-Termination-RequestおよびPANA-Termination-Answerメッセージ交換は、切断表示およびセッション取り消し手順に使用されます。
The reason for termination is indicated in the Termination-Cause AVP. When there is an established PANA SA between the PaC and the PAA, all messages exchanged during the termination phase MUST be protected with an AUTH AVP. When the sender of the PANA-Termination-Request message receives a valid acknowledgment, all states maintained for the PANA session MUST be terminated immediately.
終了の理由は、Termination-Cause AVPに示されています。 PaCとPAAの間に確立されたPANA SAがある場合、終了フェーズ中に交換されるすべてのメッセージは、AUTH AVPで保護する必要があります。 PANA-Termination-Requestメッセージの送信者が有効な確認応答を受信すると、PANAセッションで維持されているすべての状態を直ちに終了する必要があります。
PANA does not provide fragmentation of PANA messages. Instead, it relies on fragmentation provided by EAP methods and IP layer when needed.
PANAは、PANAメッセージの断片化を提供しません。代わりに、必要に応じて、EAPメソッドとIPレイヤーによって提供されるフラグメンテーションに依存します。
PANA uses sequence numbers to provide ordered and reliable delivery of messages.
PANAは、シーケンス番号を使用して、順序正しく信頼性の高いメッセージ配信を提供します。
The PaC and PAA maintain two sequence numbers: one is for setting the sequence number of the next outgoing request; the other is for matching the sequence number of the next incoming request. These sequence numbers are 32-bit unsigned numbers. They are monotonically incremented by 1 as new requests are generated and received, and wrapped to zero on the next message after 2^32-1. Answers always contain the same sequence number as the corresponding request. Retransmissions reuse the sequence number contained in the original packet.
PaCとPAAは2つのシーケンス番号を維持します。1つは次の発信要求のシーケンス番号を設定するためのものです。もう1つは、次の着信要求のシーケンス番号を照合するためのものです。これらのシーケンス番号は、32ビットの符号なしの番号です。新しい要求が生成されて受信されると、それらは1ずつ単調に増加し、2 ^ 32-1の次のメッセージでゼロにラップされます。回答には常に、対応するリクエストと同じシーケンス番号が含まれています。再送信では、元のパケットに含まれるシーケンス番号が再利用されます。
The initial sequence numbers (ISN) are randomly picked by the PaC and PAA as they send their very first request messages. PANA-Client-Initiation message carries sequence number 0.
最初のシーケンス番号（ISN）は、最初の要求メッセージを送信するときに、PaCおよびPAAによってランダムに選択されます。 PANA-Client-Initiationメッセージのシーケンス番号は0です。
When a request message is received, it is considered valid in terms of sequence numbers if and only if its sequence number matches the expected value. This check does not apply to the PANA-Client-Initiation message and the initial PANA-Auth-Request message.
要求メッセージが受信されると、シーケンス番号が期待値と一致する場合にのみ、シーケンス番号に関して有効と見なされます。このチェックは、PANA-Client-Initiationメッセージと最初のPANA-Auth-Requestメッセージには適用されません。
When an answer message is received, it is considered valid in terms of sequence numbers if and only if its sequence number matches that of the currently outstanding request. A peer can only have one outstanding request at a time.
応答メッセージが受信されると、そのシーケンス番号が現在未解決の要求のシーケンス番号と一致する場合にのみ、シーケンス番号に関して有効であると見なされます。ピアは一度に1つの未処理の要求のみを持つことができます。
PANA request messages are retransmitted based on a timer until an answer is received (in which case the retransmission timer is stopped) or the number of retransmission reaches the maximum value (in which case the PANA session MUST be terminated immediately).
PANA要求メッセージは、応答が受信される（再送信タイマーが停止する）か、再送信の数が最大値に達する（この場合、PANAセッションを直ちに終了する必要がある）まで、タイマーに基づいて再送信されます。
The retransmission timers SHOULD be calculated as described in Section 9, unless a given deployment chooses to use its own retransmission timers optimized for the underlying link-layer characteristics.
再送タイマーは、基礎となるリンク層の特性に合わせて最適化された独自の再送タイマーを使用することを選択しない限り、セクション9の説明に従って計算する必要があります。
Unless dropped due to rate limiting, the PaC and PAA MUST respond to all duplicate request messages received. The last transmitted answer MAY be cached in case it is not received by the peer, which generates a retransmission of the last request. When available, the cached answer can be used instead of fully processing the retransmitted request and forming a new answer from scratch.
レート制限のためにドロップされない限り、PaCとPAAは受信したすべての重複する要求メッセージに応答する必要があります。最後に送信された応答は、最後の要求の再送信を生成するピアによって受信されない場合に備えてキャッシュされる場合があります。利用可能な場合は、再送信されたリクエストを完全に処理して新しい回答を最初から作成する代わりに、キャッシュされた回答を使用できます。
A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of an MSK. A PANA SA is not created when the PANA authentication fails or no MSK is produced by the EAP authentication method. When a new MSK is derived in the PANA re-authentication phase, any key derived from the old MSK MUST be updated to a new one that is derived from the new MSK. In order to distinguish the new MSK from old ones, one Key-Id AVP MUST be carried in the last PANA-Auth-Request and PANA-Auth-Answer messages with the 'C' (Complete) bit set at the end of the EAP authentication, which resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the MSK within the PANA session. The last PANA-Auth-Answer message with the 'C' (Complete) bit set in response to the last PANA-Auth-Request message with the 'C' (Complete) bit set MUST contain a Key-Id AVP with the same MSK identifier carried in the request. The last PANA-Auth-Request and PANA-Auth-Answer messages with a Key-Id AVP MUST also carry an AUTH AVP whose value is computed by using the new PANA_AUTH_KEY derived from the new MSK. Although the specification does not mandate a particular method for calculation of the Key-Id AVP value, a simple method is to use monotonically increasing numbers.
EAP認証がMSKの作成で成功した場合、PANA SAはPANAセッションの属性として作成されます。 PANA認証が失敗した場合、またはEAP認証方法でMSKが生成されなかった場合、PANA SAは作成されません。 PANA再認証フェーズで新しいMSKが派生した場合、古いMSKから派生したキーはすべて、新しいMSKから派生した新しいキーに更新する必要があります。新しいMSKを古いものと区別するために、最後のPANA-Auth-RequestおよびPANA-Auth-Answerメッセージで、EAPの最後に「C」（完全）ビットが設定された1つのKey-Id AVPを運ぶ必要があります。その結果、新しいMSKが導出されました。 Key-Id AVPはUnsigned32タイプであり、PANAセッション内でMSKを一意に識別する値を含んでいる必要があります。 「C」（完全）ビットが設定された最後のPANA-Auth-Requestメッセージに応答して「C」（完全）ビットが設定された最後のPANA-Auth-Answerメッセージには、同じMSKのKey-Id AVPが含まれている必要がありますリクエストに含まれる識別子。 Key-Id AVPを含む最後のPANA-Auth-RequestおよびPANA-Auth-Answerメッセージは、新しいMSKから派生した新しいPANA_AUTH_KEYを使用して値が計算されるAUTH AVPも運ぶ必要があります。仕様では、Key-Id AVP値の計算に特定の方法を義務付けていませんが、単純な方法は、単調に増加する数値を使用することです。
The PANA session lifetime is bounded by the authorization lifetime granted by the authentication server (same as the MSK lifetime). The lifetime of the PANA SA (hence the PANA_AUTH_KEY) is the same as the lifetime of the PANA session. The created PANA SA is deleted when the corresponding PANA session is terminated.
PANAセッションライフタイムは、認証サーバーによって付与された承認ライフタイムによって制限されます（MSKライフタイムと同じ）。 PANA SA（つまり、PANA_AUTH_KEY）の存続期間は、PANAセッションの存続期間と同じです。作成されたPANA SAは、対応するPANAセッションが終了すると削除されます。
PANA SA attributes as well as PANA session attributes are listed below:
PANA SA属性とPANAセッション属性を以下に示します。
PANA Session attributes:
PANAセッション属性：
* Session Identifier
* セッション識別子
* IP address and UDP port number of the PaC
* PaCのIPアドレスとUDPポート番号
* IP address and UDP port number of the PAA
* PAAのIPアドレスとUDPポート番号
* Sequence number for the next outgoing request
* 次の発信要求のシーケンス番号
* Sequence number for the next incoming request
* 次の着信要求のシーケンス番号
* Last transmitted message payload
* 最後に送信されたメッセージのペイロード
* Retransmission interval
* 再送間隔
* Session lifetime
* セッション存続期間
* PANA SA attributes
* PANA SAの属性
PANA SA attributes:
PANA SAの属性：
* Nonce generated by PaC (PaC_nonce)
* PaCによって生成されたノンス（PaC_nonce）
* Nonce generated by PAA (PAA_nonce)
* PAAによって生成されたノンス（PAA_nonce）
* MSK
* MSK
* MSK Identifier
* MSK識別子
* PANA_AUTH_KEY
* ドリンク
* Pseudo-random function
* 疑似ランダム関数
* Integrity algorithm
* 整合性アルゴリズム
The PANA_AUTH_KEY is derived from the available MSK, and it is used to integrity protect PANA messages. The PANA_AUTH_KEY is computed in the following way:
PANA_AUTH_KEYは、使用可能なMSKから派生し、PANAメッセージの整合性を保護するために使用されます。 PANA_AUTH_KEYは次の方法で計算されます。
PANA_AUTH_KEY = prf+(MSK, "IETF PANA"|I_PAR|I_PAN| PaC_nonce|PAA_nonce|Key_ID)
Drink_Youth_Kiya = Proof +（Musk、 "Eat Drink" | E_Par | E_Pan | Pach_Nons | Pa_Nons | Kiya_ Eid
where:
ただし：
- The prf+ function is defined in IKEv2 [RFC4306]. The pseudo-random function to be used for the prf+ function is negotiated using PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' (Start) bit set.
- prf +関数はIKEv2 [RFC4306]で定義されています。 prf +関数に使用される疑似ランダム関数は、最初のPANA-Auth-RequestおよびPANA-Auth-Answer交換でPRF-Algorithm AVPを使用して、「S」（開始）ビットが設定された状態でネゴシエートされます。
- MSK is the master session key generated by the EAP method.
- MSKは、EAP方式で生成されるマスターセッションキーです。
- "IETF PANA" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it).
- 「IETF PANA」は、NULL以外で終了する文字列のASCIIコード表現です（二重引用符を除く）。
- I_PAR and I_PAN are the initial PANA-Auth-Request and PANA-Auth-Answer messages (the PANA header and the following PANA AVPs) with 'S' (Start) bit set, respectively.
- I_PARおよびI_PANは、それぞれ「S」（開始）ビットが設定された最初のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージ（PANAヘッダーと次のPANA AVP）です。
- PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in the authentication and authorization phase or the first PANA-Auth-Answer and PANA-Auth-Request messages in the re-authentication phase, respectively.
- PaC_nonceおよびPAA_nonceは、認証および承認フェーズの最初の非初期PANA-Auth-AnswerおよびPANA-Auth-Requestメッセージ、または最初のPANA-Auth-AnswerおよびPANA-Auth-Requestメッセージで運ばれるNonce AVPの値です。それぞれ再認証フェーズ。
- Key_ID is the value of the Key-Id AVP.
- Key_IDは、Key-Id AVPの値です。
The length of PANA_AUTH_KEY depends on the integrity algorithm in use. See Section 5.4 for the detailed usage of the PANA_AUTH_KEY.
PANA_AUTH_KEYの長さは、使用している整合性アルゴリズムによって異なります。 PANA_AUTH_KEYの詳細な使用法については、5.4項を参照してください。
A PANA message can contain an AUTH AVP for cryptographically protecting the message.
PANAメッセージには、メッセージを暗号で保護するためのAUTH AVPを含めることができます。
When an AUTH AVP is included in a PANA message, the Value field of the AUTH AVP is calculated by using the PANA_AUTH_KEY in the following way:
AUTH AVPがPANAメッセージに含まれている場合、AUTH AVPのValueフィールドは、PANA_AUTH_KEYを使用して次のように計算されます。
AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)
AUTH AVP値= PANA_AUTH_HASH（PANA_AUTH_KEY、PANA_PDU）
where PANA_PDU is the PANA message including the PANA header, with the AUTH AVP Value field first initialized to 0. PANA_AUTH_HASH represents the integrity algorithm negotiated using Integrity-Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' (Start) bit set. The PaC and PAA MUST use the same integrity algorithm to calculate an AUTH AVP they originate and receive.
ここで、PANA_PDUはPANAヘッダーを含むPANAメッセージで、最初にAUTH AVP値フィールドが0に初期化されます。PANA_AUTH_HASHは、最初のPANA-Auth-RequestおよびPANA-Auth-Answer交換でIntegrity-Algorithm AVPを使用してネゴシエートされた整合性アルゴリズムを表します。 S '（開始）ビットセット。 PaCとPAAは、同じ整合性アルゴリズムを使用して、発信および受信するAUTH AVPを計算する必要があります。
When a PANA message is received, the message is considered to be invalid, at least when one of the following conditions are not met:
PANAメッセージを受信すると、少なくとも次のいずれかの条件が満たされない場合、メッセージは無効であると見なされます。
o Each field in the message header contains a valid value including sequence number, message length, message type, flags, session identifier, etc.
o メッセージヘッダーの各フィールドには、シーケンス番号、メッセージ長、メッセージタイプ、フラグ、セッション識別子などの有効な値が含まれています。
o The message type is one of the expected types in the current state. Specifically, the following messages are unexpected and invalid:
o メッセージタイプは、現在の状態で予期されるタイプの1つです。具体的には、次のメッセージは予期せず、無効です。
* In the authentication and authorization phase:
* 認証および承認フェーズでは、次のことを行います。
+ PANA-Client-Initiation after completion of the initial PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' (Start) bit set.
+ 「S」（開始）ビットが設定された初期PANA-Auth-RequestおよびPANA-Auth-Answer交換の完了後のPANA-Client-Initiation。
+ Re-authentication request.
+ 再認証リクエスト。
+ Ping request.
+ pingリクエスト。
+ The last PANA-Auth-Request with 'C' (Complete) bit set before completion of the initial PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' (Start) bit set.
+ 最初のPANA-Auth-RequestおよびPANA-Auth-Answerの交換が完了する前に「S」（開始）ビットが設定された「C」（完全）ビットが設定された最後のPANA-Auth-Request。
+ The initial PANA-Auth-Request with 'S' (Start) bit set after a PaC receives a valid non-initial PANA-Auth-Request with 'S' (Start) bit cleared.
+ PaCが 'S'（開始）ビットがクリアされた有効な非初期PANA-Auth-Requestを受信した後に 'S'（開始）ビットが設定された初期PANA-Auth-Request。
+ PANA-Termination-Request.
+ PANA-Termination-Request。
* In the re-authentication phase:
* 再認証フェーズでは：
+ PANA-Client-Initiation.
+ PANA-Client-Initiation。
+ The initial PANA-Auth-Request.
+ 最初のPANA-Auth-Request。
* In the access phase:
* アクセス段階では：
+ PANA-Auth-Request.
+ PANA-Auth-Request。
+ PANA-Client-Initiation.
+ PANA-Client-Initiation。
* In the termination phase:
* 終了フェーズ：
+ PANA-Client-Initiation.
+ PANA-Client-Initiation。
+ All requests but PANA-Termination-Request and ping request.
+ PANA-Termination-Requestおよびpingリクエスト以外のすべてのリクエスト。
o The message payload contains a valid set of AVPs allowed for the message type. There is no missing AVP that needs to be included in the payload, and no AVP, which needs to be at a fixed position, is included in a position different from this fixed position.
o メッセージペイロードには、メッセージタイプに許可された有効なAVPのセットが含まれています。ペイロードに含める必要のある欠落したAVPはなく、固定位置にある必要のあるAVPは、この固定位置とは異なる位置に含まれていません。
o Each AVP is recognized and decoded correctly.
o 各AVPは正しく認識され、デコードされます。
o Once the PANA authentication succeeds in using a key-generating EAP method, the PANA-Auth-Request message that carries the EAP Success and any subsequent message in that session contains an AUTH AVP. The AVP value matches the hash value computed against the received message.
o PANA認証が鍵生成EAP方式の使用に成功すると、EAP Successを伝えるPANA-Auth-Requestメッセージと、そのセッションの後続のメッセージには、AUTH AVPが含まれます。 AVP値は、受信したメッセージに対して計算されたハッシュ値と一致します。
Invalid messages MUST be discarded in order to provide robustness against DoS attacks.
DoS攻撃に対する堅牢性を提供するには、無効なメッセージを破棄する必要があります。
A PaC's IP address used for PANA can change in certain situations, e.g., when IP address reconfiguration is needed for the PaC to obtain an IP address after successful PANA authentication (see Section 3 of [RFC5193]) or when the PaC moves from one IP link to another within the same PAA's realm. In order to maintain the PANA session, the PAA needs to be notified about the change of PaC address.
PANAに使用されるPaCのIPアドレスは、PANA認証が成功した後にPaCがIPアドレスを取得するためにIPアドレスの再構成が必要な場合（[RFC5193]のセクション3を参照）や、PaCが1つのIPから移動した場合などに変更される可能性があります。同じPAAのレルム内の別のリンク。 PANAセッションを維持するには、PACにPaCアドレスの変更を通知する必要があります。
After the PaC has changed its IP address used for PANA, it MUST send any valid PANA message. If the message that carries the new PaC IP address in the Source Address field of the IP header is valid, the PAA MUST update the PANA session with the new PaC address. If there is an established PANA SA, the message MUST be protected with an AUTH AVP.
PaCがPANAに使用するIPアドレスを変更した後、PaCは有効なPANAメッセージを送信する必要があります。 IPヘッダーの送信元アドレスフィールドに新しいPaC IPアドレスを含むメッセージが有効な場合、PAAは新しいPaCアドレスでPANAセッションを更新する必要があります。確立されたPANA SAがある場合、メッセージはAUTH AVPで保護する必要があります。
The authentication and authorization phase determines the PANA session lifetime, and the lifetime is indicated to the PaC when the network access authorization succeeds. For this purpose, when the last PANA-Auth-Request message (i.e., with the 'C' (Complete) bit set) in authentication and authorization phase or re-authentication phase carries a Result-Code AVP with a value of PANA_SUCCESS, a Session-Lifetime AVP MUST also be carried in the message. A Session-Lifetime AVP MUST be ignored when included in other PANA messages.
認証と承認のフェーズでPANAセッションの存続期間が決まり、ネットワークアクセスの承認が成功すると、その存続期間がPaCに示されます。この目的のために、認証および承認フェーズまたは再認証フェーズの最後のPANA-Auth-Requestメッセージ（「C」（完全）ビットが設定されている）が、PANA_SUCCESSの値を持つResult-Code AVPを運ぶ場合、 Session-Lifetime AVPもメッセージに含める必要があります。他のPANAメッセージに含まれる場合、Session-Lifetime AVPを無視する必要があります。
The lifetime is a non-negotiable parameter that can be used by the PaC to manage PANA-related state. The PaC MUST initiate the re-authentication phase before the current session lifetime expires, if it wants to extend the session.
ライフタイムは交渉不能なパラメーターであり、PaCがPANA関連の状態を管理するために使用できます。 PaCは、セッションを延長する場合、現在のセッションの有効期限が切れる前に再認証フェーズを開始する必要があります。
The PaC and the PAA MAY use information obtained outside PANA (e.g., lower-layer indications) to expedite the detection of a disconnected peer. Availability and reliability of such indications MAY depend on a specific link-layer or network topology and are therefore only hints. A PANA peer SHOULD use the ping request and answer exchange to verify that a peer is, in fact, no longer alive, unless information obtained outside PANA is being used to expedite the detection of a disconnected peer.
PaCとPAAは、PANAの外部で取得された情報（下位層の表示など）を使用して、切断されたピアの検出を促進できます（MAY）。そのような表示の可用性と信頼性は、特定のリンク層またはネットワークトポロジに依存する可能性があるため、単なるヒントにすぎません。 PANAピアは、ping要求と応答交換を使用して、切断されたピアの検出を促進するためにPANAの外部で取得された情報が使用されていない限り、ピアが実際にはもはや存在していないことを確認する必要があります。
The session lifetime parameter is not related to the transmission of ping request messages. These messages can be used for asynchronously verifying the liveness of the peer. The decision to send a ping request message is made locally and does not require coordination between the peers.
セッション存続時間パラメーターは、ping要求メッセージの送信とは関係ありません。これらのメッセージは、ピアの活性を非同期的に検証するために使用できます。 ping要求メッセージを送信する決定はローカルで行われ、ピア間の調整を必要としません。
This section defines message formats for PANA protocol.
このセクションでは、PANAプロトコルのメッセージ形式を定義します。
Any PANA message is unicast between the PaC and the PAA.
PANAメッセージはすべて、PaCとPAAの間でユニキャストされます。
For any PANA message sent from the peer that has initiated the PANA session, the UDP source port is set to any number on which the peer can receive incoming PANA messages, and the destination port is set to the assigned PANA port number (716). For any PANA message sent from the other peer, the source port is set to the assigned PANA port number (716), and the destination port is copied from the source port of the last received message. In case both the PaC and PAA initiate the session (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request messages cross each other), then the PaC is identified as the initiator. All PANA peers MUST listen on the assigned PANA port number (716).
PANAセッションを開始したピアから送信されたPANAメッセージの場合、UDP送信元ポートは、ピアが着信PANAメッセージを受信できる任意の番号に設定され、宛先ポートは割り当てられたPANAポート番号に設定されます（716）。他のピアから送信されたPANAメッセージの場合、送信元ポートは割り当てられたPANAポート番号（716）に設定され、宛先ポートは最後に受信したメッセージの送信元ポートからコピーされます。 PaCとPAAの両方がセッションを開始した場合（つまり、PANA-Client-Initiationと未承諾のPANA-Auth-Requestメッセージが相互に交差する場合）、PaCは開始者として識別されます。すべてのPANAピアは、割り当てられたPANAポート番号（716）で待機する必要があります。
A summary of the PANA message header format is shown below. The fields are transmitted in network byte order.
PANAメッセージヘッダー形式の概要を以下に示します。フィールドはネットワークバイトオーダーで送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Reserved
予約済み
This 16-bit field is reserved for future use. It MUST be set to zero and ignored by the receiver.
この16ビットのフィールドは、将来の使用のために予約されています。これはゼロに設定されなければならず、受信側によって無視されなければなりません。
Message Length
メッセージの長さ
The Message Length field is two octets and indicates the length of the PANA message including the header fields.
メッセージ長フィールドは2オクテットで、ヘッダーフィールドを含むPANAメッセージの長さを示します。
Flags
旗
The Flags field is two octets. The following bits are assigned:
Flagsフィールドは2オクテットです。以下のビットが割り当てられています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S C A P I r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Request)
R（リクエスト）
If set, the message is a request. If cleared, the message is an answer.
設定されている場合、メッセージは要求です。クリアされている場合、メッセージは回答です。
S (Start)
S（開始）
If set, the message is the first PANA-Auth-Request or PANA-Auth-Answer in authentication and authorization phase. For other messages, this bit MUST be cleared.
設定されている場合、メッセージは認証および承認フェーズの最初のPANA-Auth-RequestまたはPANA-Auth-Answerです。他のメッセージでは、このビットをクリアする必要があります。
C (Complete)
C（完全）
If set, the message is the last PANA-Auth-Request or PANA-Auth-Answer in authentication and authorization phase. For other messages, this bit MUST be cleared.
設定されている場合、メッセージは認証および許可フェーズの最後のPANA-Auth-RequestまたはPANA-Auth-Answerです。他のメッセージでは、このビットをクリアする必要があります。
A (re-Authentication)
A（再認証）
If set, the message is a PANA-Notification-Request or PANA-Notification-Answer to initiate re-authentication. For other messages, this bit MUST be cleared.
設定されている場合、メッセージはPANA-Notification-RequestまたはPANA-Notification-Answerであり、再認証を開始します。他のメッセージでは、このビットをクリアする必要があります。
P (Ping)
P（ピン）
If set, the message is a PANA-Notification-Request or PANA-Notification-Answer for liveness test. For other messages, this bit MUST be cleared.
設定されている場合、メッセージは、生存テストのためのPANA-Notification-RequestまたはPANA-Notification-Answerです。他のメッセージでは、このビットをクリアする必要があります。
I (IP Reconfiguration)
I（IP再構成）
If set, it indicates that the PaC is required to perform IP address reconfiguration after successful authentication and authorization phase to configure an IP address that is usable for exchanging data traffic across EP. This bit is set by the PAA only for PANA-Auth-Request messages in the authentication and authorization phase. For other messages, this bit MUST be cleared.
設定されている場合、EP間でデータトラフィックを交換するために使用できるIPアドレスを構成するために、認証および許可フェーズが成功した後、PaCがIPアドレスの再構成を実行する必要があることを示します。このビットは、認証および許可フェーズのPANA-Auth-Requestメッセージに対してのみPAAによって設定されます。他のメッセージでは、このビットをクリアする必要があります。
r (reserved)
r（予約済み）
These flag bits are reserved for future use. They MUST be set to zero and ignored by the receiver.
これらのフラグビットは、将来の使用のために予約されています。それらはゼロに設定されなければならず、受信者によって無視されなければなりません。
Message Type
メッセージタイプ
The Message Type field is two octets, and it is used in order to communicate the message type with the message. Message Type allocation is managed by IANA [IANAWEB].
メッセージタイプフィールドは2オクテットであり、メッセージとメッセージタイプを通信するために使用されます。メッセージタイプの割り当ては、IANA [IANAWEB]によって管理されます。
Session Identifier
セッション識別子
This field contains a 32-bit session identifier.
このフィールドには、32ビットのセッションIDが含まれています。
Sequence Number
シーケンス番号
This field contains a 32-bit sequence number.
このフィールドには、32ビットのシーケンス番号が含まれています。
AVPs
AVP
AVPs are a method of encapsulating information relevant to the PANA message. See Section 6.3 for more information on AVPs.
AVPは、PANAメッセージに関連する情報をカプセル化する方法です。 AVPの詳細については、セクション6.3を参照してください。
Each AVP of type OctetString MUST be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero-valued bytes are added to the end of the AVP Value field until a word boundary is reached. The length of the padding is not reflected in the AVP Length field [RFC3588].
タイプOctetStringの各AVPは、32ビット境界で整列するようにパディングする必要がありますが、他のAVPタイプは自然に整列します。ワード境界に達するまで、ゼロ値のバイトがAVP値フィールドの最後に追加されます。パディングの長さは、AVP長さフィールド[RFC3588]には反映されません。
The fields in the AVP are sent in network byte order. The AVP format is:
AVPのフィールドは、ネットワークバイトオーダーで送信されます。 AVP形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+
AVP Code
AVPコード
The AVP Code, together with the optional Vendor-Id field, identifies an attribute that follows. If the V-bit is not set, then the Vendor-Id is not present and the AVP Code refers to an IETF attribute.
AVPコードは、オプションのVendor-Idフィールドとともに、後に続く属性を識別します。 Vビットが設定されていない場合、Vendor-Idは存在せず、AVPコードはIETF属性を参照します。
AVP Flags
AVPフラグ
The AVP Flags field is two octets. The following bits are assigned:
AVP Flagsフィールドは2オクテットです。以下のビットが割り当てられています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V r r r r r r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V (Vendor)
B（ベンダー）
The 'V' (Vendor) bit indicates whether the optional Vendor-Id field is present in the AVP header. When set, the AVP Code belongs to the specific vendor code address space. All AVPs defined in this document MUST have the 'V' (Vendor) bit cleared.
「V」（ベンダー）ビットは、オプションのベンダーIDフィールドがAVPヘッダーに存在するかどうかを示します。設定すると、AVPコードは特定のベンダーコードアドレス空間に属します。このドキュメントで定義されているすべてのAVPは、「V」（ベンダー）ビットをクリアする必要があります。
r (reserved)
r（予約済み）
These flag bits are reserved for future use. They MUST be set to zero and ignored by the receiver.
これらのフラグビットは、将来の使用のために予約されています。それらはゼロに設定されなければならず、受信者によって無視されなければなりません。
AVP Length
AVPの長さ
The AVP Length field is two octets, and indicates the number of octets in the Value field. The length of the AVP Code, AVP Length, AVP Flags, Reserved and Vendor-Id fields are not counted in the AVP Length value.
AVP長さフィールドは2オクテットで、値フィールドのオクテット数を示します。 AVPコード、AVP長さ、AVPフラグ、予約済み、およびベンダーIDフィールドの長さは、AVP長さの値には含まれません。
Reserved
予約済み
This two-octet field is reserved for future use. It MUST be set to zero and ignored by the receiver.
この2オクテットのフィールドは、将来の使用のために予約されています。これはゼロに設定されなければならず、受信側によって無視されなければなりません。
Vendor-Id
ベンダーID
The Vendor-Id field is present if the 'V' (Vendor) bit is set in the AVP Flags field. The optional four-octet Vendor-Id field contains the IANA assigned "SMI Network Management Private Enterprise Codes" [IANAWEB] value, encoded in network byte order. Any vendor wishing to implement a vendor-specific PANA AVP MUST use their own Vendor-Id along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP(s) nor with future IETF applications.
「V」（ベンダー）ビットがAVPフラグフィールドに設定されている場合、ベンダーIDフィールドが存在します。オプションの4オクテットVendor-Idフィールドには、ネットワークバイトオーダーでエンコードされた、IANAが割り当てた「SMIネットワーク管理プライベートエンタープライズコード」[IANAWEB]値が含まれます。ベンダー固有のPANA AVPの実装を希望するベンダーは、プライベートに管理されたAVPアドレススペースとともに独自のベンダーIDを使用し、他のベンダーのベンダー固有のAVPや将来のIETFアプリケーションと衝突しないことを保証する必要があります。
Value
値
The Value field is zero or more octets and contains information specific to the Attribute. The format of the Value field is determined by the AVP Code and Vendor-Id fields. The length of the Value field is determined by the AVP Length field.
値フィールドは0オクテット以上であり、属性に固有の情報が含まれます。値フィールドの形式は、AVPコードおよびベンダーIDフィールドによって決定されます。 Valueフィールドの長さは、AVP Lengthフィールドによって決定されます。
Each Request/Answer message pair is assigned a sequence number, and the sub-type (i.e., request or answer) is identified via the 'R' (Request) bit in the Message Flags field of the PANA message header.
各要求/応答メッセージのペアにはシーケンス番号が割り当てられ、サブタイプ（つまり、要求または応答）は、PANAメッセージヘッダーのメッセージフラグフィールドの「R」（要求）ビットで識別されます。
Every PANA message MUST contain a message type in its header's Message Type field, which is used to determine the action that is to be taken for a particular message. Figure 3 lists all PANA messages defined in this document:
すべてのPANAメッセージは、ヘッダーのメッセージタイプフィールドにメッセージタイプを含まなければなりません。これは、特定のメッセージに対して実行されるアクションを決定するために使用されます。図3は、このドキュメントで定義されているすべてのPANAメッセージを示しています。
Message Name Abbrev. Message PaC<->PAA Ref.
Type
---------------------------------------------------------------------
PANA-Client-Initiation PCI 1 --------> 7.1
PANA-Auth-Request PAR 2 <-------> 7.2
PANA-Auth-Answer PAN 2 <-------> 7.3
PANA-Termination-Request PTR 3 <-------> 7.4
PANA-Termination-Answer PTA 3 <-------> 7.5
PANA-Notification-Request PNR 4 <-------> 7.6
PANA-Notification-Answer PNA 4 <-------> 7.7
---------------------------------------------------------------------
Figure 3: Table of PANA Messages
図3：PANAメッセージの表
The language used for PANA message definitions (i.e., AVPs valid for that PANA message type), in Section 7.1 through Section 7.7, is defined using ABNF [RFC5234] as follows:
セクション7.1からセクション7.7でPANAメッセージ定義に使用される言語（つまり、そのPANAメッセージタイプに有効なAVP）は、ABNF [RFC5234]を使用して次のように定義されます。
message-def = Message-Name LWSP "::=" LWSP PANA-message
Message-Name = PANA-name
PANA-name = ALPHA *(ALPHA / DIGIT / "-")
PANA-message = header LWSP *fixed LWSP *required
LWSP *optional LWSP *fixed
header = "<" LWSP "PANA-Header:" LWSP Message-Type [r-bit] [s-bit] [c-bit] [a-bit] [p-bit] [i-bit] LWSP ">"
header = "<" LWSP "PANA-Header：" LWSPメッセージタイプ[rビット] [sビット] [cビット] [aビット] [pビット] [iビット] LWSP ">"
Message-Type = 1*DIGIT
; The Message Type assigned to the message
r-bit = ",REQ"
; If present, the 'R' (Request) bit in the Message
; Flags is set, indicating that the message
; is a request, as opposed to an answer.
s-bit = ",STA"
; If present, the 'S' (Start) bit in the Message
; Flags is set, indicating that the message
; is the initial PAR or PAN in authentication
; and authorization phase.
c-bit = ",COM"
; If present, the 'C' bit in the Message
; Flags is set, indicating that the message
; is the final PAR and PAN in authentication
; and authorization phase or re-authentication
; phase.
a-bit = ",REA"
; If present, the 'A' (re-Authentication) bit
; in the Message Flags is set, indicating that
; the message is a re-authentication request or
; answer.
p-bit = ",PIN"
; If present, the 'P' (Ping) bit in the Message
; Flags is set, indicating that the message
; is a ping request or answer.
i-bit = ",IPR"
; If present, the 'I' (IP Reconfiguration) bit
; in the Message Flags is set, indicating that
; the PaC requires IP address reconfiguration
; after successful authentication and
; authorization phase.
fixed = [qual] "<" LWSP avp-spec LWSP ">"
; Defines the fixed position of an AVP.
required = [qual] "{" LWSP avp-spec LWSP "}"
; The AVP MUST be present and can appear
; anywhere in the message.
optional = [qual] "[" LWSP avp-name LWSP "]"
; The avp-name in the 'optional' rule cannot
; evaluate any AVP Name that is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
qual = [min] "*" [max]
; See ABNF conventions, RFC 5234 Section 3.6.
; The absence of any qualifiers depends on whether
; it precedes a fixed, required, or optional
; rule. If a fixed or required rule has no
; qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present.
;
; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used to express
; optional fixed rules (such as an optional
; AUTH at the end). To do this, the convention
; is '0*1fixed'.
min = 1*DIGIT
; The minimum number of times the element may
; be present. The default value is zero.
max = 1*DIGIT
; The maximum number of times the element may
; be present. The default value is infinity. A
; value of zero implies the AVP MUST NOT be
; present.
avp-spec = PANA-name
; The avp-spec has to be an AVP Name, defined
; in the base or extended PANA protocol
; specifications.
avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the message definition.
The PANA-Client-Initiation (PCI) message is used for PaC-initiated session. The Sequence Number and Session Identifier fields in this message MUST be set to zero (0).
PANA-Client-Initiation（PCI）メッセージは、PaCで開始されたセッションに使用されます。このメッセージのシーケンス番号およびセッションIDフィールドは、ゼロ（0）に設定する必要があります。
PANA-Client-Initiation ::= < PANA-Header: 1 >
*[ AVP ]
The PANA-Auth-Request (PAR) message is either sent by the PAA or the PaC.
PANA-Auth-Request（PAR）メッセージは、PAAまたはPaCによって送信されます。
The message MUST NOT have both the 'S' (Start) and 'C' (Complete) bits set.
メッセージには、「S」（開始）ビットと「C」（完全）ビットの両方を設定してはいけません（MUST NOT）。
PANA-Auth-Request ::= < PANA-Header: 2,REQ[,STA][,COM][,IPR] >
[ EAP-Payload ]
[ Nonce ]
*[ PRF-Algorithm ]
*[ Integrity-Algorithm ]
[ Result-Code ]
[ Session-Lifetime ]
[ Key-Id ]
*[ AVP ]
0*1< AUTH >
The PANA-Auth-Answer (PAN) message is sent by either the PaC or the PAA in response to a PANA-Auth-Request message.
PANA-Auth-Answer（PAN）メッセージは、PANA-Auth-Requestメッセージへの応答としてPaCまたはPAAのいずれかによって送信されます。
The message MUST NOT have both the 'S' (Start) and 'C' (Complete) bits set.
メッセージには、「S」（開始）ビットと「C」（完全）ビットの両方を設定してはいけません（MUST NOT）。
PANA-Auth-Answer ::= < PANA-Header: 2[,STA][,COM] >
[ Nonce ]
[ PRF-Algorithm ]
[ Integrity-Algorithm ]
[ EAP-Payload ]
[ Key-Id ]
*[ AVP ]
0*1< AUTH >
The PANA-Termination-Request (PTR) message is sent either by the PaC or the PAA to terminate a PANA session.
PANA-Termination-Request（PTR）メッセージは、PANAセッションを終了するためにPaCまたはPAAによって送信されます。
PANA-Termination-Request ::= < PANA-Header: 3,REQ >
< Termination-Cause >
*[ AVP ]
0*1< AUTH >
The PANA-Termination-Answer (PTA) message is sent either by the PaC or the PAA in response to PANA-Termination-Request.
PANA-Termination-Answer（PTA）メッセージは、PANA-Termination-Requestに応答してPaCまたはPAAのいずれかによって送信されます。
PANA-Termination-Answer ::= < PANA-Header: 3 >
*[ AVP ]
0*1< AUTH >
The PANA-Notification-Request (PNR) message is used for signaling re-authentication and performing liveness test. See Section 4.3 and Section 4.2 for details on re-authentication and liveness test, respectively.
PANA-Notification-Request（PNR）メッセージは、再認証のシグナリングと活性テストの実行に使用されます。再認証と活性テストの詳細については、それぞれセクション4.3とセクション4.2を参照してください。
The message MUST have one of the 'A' (re-Authentication) and 'P' (Ping) bits exclusively set.
メッセージには、「A」（再認証）ビットと「P」（Ping）ビットのいずれかが排他的に設定されている必要があります。
PANA-Notification-Request ::= < PANA-Header: 4,REQ[,REA][,PIN] >
*[ AVP ]
0*1< AUTH >
The PANA-Notification-Answer (PNA) message is sent by the PAA (PaC) to the PaC (PAA) in response to a PANA-Notification-Request from the PaC (PAA).
PANA-Notification-Answer（PNA）メッセージは、PaC（PAA）からのPANA-Notification-Requestに応答して、PAA（PaC）からPaC（PAA）に送信されます。
The message MUST have one of the 'A' (re-Authentication) and 'P' (Ping) bits exclusively set.
メッセージには、「A」（再認証）ビットと「P」（Ping）ビットのいずれかが排他的に設定されている必要があります。
PANA-Notification-Answer ::= < PANA-Header: 4[,REA][,PIN] >
*[ AVP ]
0*1< AUTH >
This document uses AVP Value Format such as 'OctetString' and 'Unsigned32' as defined in Section 4.2 of [RFC3588]. The definitions of these data formats are not repeated in this document.
このドキュメントでは、[RFC3588]のセクション4.2で定義されている「OctetString」や「Unsigned32」などのAVP値形式を使用します。これらのデータ形式の定義は、このドキュメントでは繰り返されません。
The following table lists the AVPs used in this document, and specifies in which PANA messages they MAY or MAY NOT be present.
次の表は、このドキュメントで使用されているAVPの一覧と、それらが存在する場合と存在しない場合があるPANAメッセージを示しています。
The table uses the following symbols:
この表では次の記号を使用しています。
0 The AVP MUST NOT be present in the message.
0 AVPはメッセージに存在してはなりません。
0-1 Zero or one instance of the AVP MAY be present in the message. It is considered an error if there is more than one instance of the AVP.
0-1 AVPのゼロまたは1つのインスタンスがメッセージに存在する場合があります。 AVPのインスタンスが複数ある場合は、エラーと見なされます。
1 One instance of the AVP MUST be present in the message.
1 AVPの1つのインスタンスがメッセージに存在する必要があります。
0+ Zero or more instances of the AVP MAY be present in the message.
0+ AVPのゼロ個以上のインスタンスがメッセージに存在する場合があります。
+---------------------------+
| Message Type |
+---+---+---+---+---+---+---+
Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA|
----------------------+---+---+---+---+---+---+---+
AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1|
EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
Integrity-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
PRF-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
----------------------+---+---+---+---+---+---+---+
Figure 4: AVP Occurrence Table
図4：AVPオカレンステーブル
The AUTH AVP (AVP Code 1) is used to integrity protect PANA messages. The AVP data payload contains the Message Authentication Code encoded in network byte order. The AVP length varies depending on the integrity algorithm used. The AVP data is of type OctetString.
AUTH AVP（AVPコード1）は、PANAメッセージの整合性を保護するために使用されます。 AVPデータペイロードには、ネットワークバイトオーダーでエンコードされたメッセージ認証コードが含まれています。 AVPの長さは、使用される整合性アルゴリズムによって異なります。 AVPデータのタイプはOctetStringです。
The EAP-Payload AVP (AVP Code 2) is used for encapsulating the actual EAP message that is being exchanged between the EAP peer and the EAP authenticator. The AVP data is of type OctetString.
EAP-Payload AVP（AVPコード2）は、EAPピアとEAPオーセンティケーターの間で交換される実際のEAPメッセージをカプセル化するために使用されます。 AVPデータのタイプはOctetStringです。
The Integrity-Algorithm AVP (AVP Code 3) is used for conveying the integrity algorithm to compute an AUTH AVP. The AVP data is of type Unsigned32. The AVP data contains an Internet Key Exchange Protocol version 2 (IKEv2) Transform ID of Transform Type 3 [RFC4306] for the integrity algorithm. All PANA implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595].
Integrity-Algorithm AVP（AVPコード3）は、AUTH AVPを計算するための整合性アルゴリズムを伝達するために使用されます。 AVPデータのタイプはUnsigned32です。 AVPデータには、整合性アルゴリズムの変換タイプ3 [RFC4306]のインターネットキー交換プロトコルバージョン2（IKEv2）変換IDが含まれています。すべてのPANA実装は、AUTH_HMAC_SHA1_160（7）[RFC4595]をサポートする必要があります。
The Key-Id AVP (AVP Code 4) is of type Integer32 and contains an MSK identifier. The MSK identifier is assigned by PAA and MUST be unique within the PANA session.
Key-Id AVP（AVPコード4）のタイプはInteger32で、MSK識別子が含まれています。 MSK識別子はPAAによって割り当てられ、PANAセッション内で一意である必要があります。
The Nonce AVP (AVP Code 5) carries a randomly chosen value that is used in cryptographic key computations. The recommendations in [RFC4086] apply with regard to generation of random values. The AVP data is of type OctetString, and it contains a randomly generated value in opaque format. The data length MUST be between 8 and 256 octets, inclusive.
Nonce AVP（AVPコード5）は、暗号化キーの計算で使用されるランダムに選択された値を伝送します。 [RFC4086]の推奨事項は、ランダム値の生成に関して適用されます。 AVPデータのタイプはOctetStringで、ランダムに生成された値が不透明な形式で含まれています。データ長は、8〜256オクテットである必要があります。
The length of the nonces are determined based on the available pseudo-random functions (PRFs) and the degree of trust placed into the PaC and the PAA to compute random values. The length of the random value for the nonce is determined in one of two ways, depending on whether:
ナンスの長さは、使用可能な疑似ランダム関数（PRF）と、ランダムな値を計算するためにPaCおよびPAAに設定された信頼度に基づいて決定されます。 nonceのランダム値の長さは、次のいずれかに応じて、2つの方法のいずれかで決定されます。
1. The PaC and the PAA each are likely to be able to compute a random nonce (according to [RFC4086]). The length of the nonce has to be 1/2 the length of the PRF key (e.g., 10 octets in the case of HMAC-SHA1).
1. PaCとPAAはそれぞれ、ランダムなノンスを計算できる可能性があります（[RFC4086]に従って）。 nonceの長さは、PRF鍵の長さの1/2（たとえば、HMAC-SHA1の場合は10オクテット）でなければなりません。
2. The PaC and the PAA each are not trusted with regard to the computation of a random nonce (according to [RFC4086]). The length of the nonce has to have the full length of the PRF key (e.g., 20 octets in the case of HMAC-SHA1).
2. PaCとPAAはそれぞれ、ランダムナンスの計算に関して信頼されていません（[RFC4086による]）。ナンスの長さは、PRFキーの全長（たとえば、HMAC-SHA1の場合は20オクテット）である必要があります。
Furthermore, the strongest available PRF for PANA has to be considered in this computation. Currently, only a single PRF (namely HMAC-SHA1) is available and therefore the maximum output length is 20 octets. Therefore, the maximum length of the nonce value SHOULD be 20 octets.
さらに、PANAで利用可能な最強のPRFをこの計算で考慮する必要があります。現在、単一のPRF（つまりHMAC-SHA1）のみが使用可能であるため、最大出力長は20オクテットです。したがって、ノンス値の最大長は20オクテットである必要があります。
The PRF-Algorithm AVP (AVP Code 6) is used for conveying the pseudo-random function to derive PANA_AUTH_KEY. The AVP data is of type Unsigned32. The AVP data contains an IKEv2 Transform ID of Transform Type 2 [RFC4306]. All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104].
PRFアルゴリズムAVP（AVPコード6）は、疑似ランダム関数を伝達してPANA_AUTH_KEYを導出するために使用されます。 AVPデータのタイプはUnsigned32です。 AVPデータには、Transform Type 2 [RFC4306]のIKEv2 Transform IDが含まれています。すべてのPANA実装は、PRF_HMAC_SHA1（2）[RFC2104]をサポートする必要があります。
The Result-Code AVP (AVP Code 7) is of type Unsigned32 and indicates whether an EAP authentication was completed successfully. Result-Code AVP values are described below.
Result-Code AVP（AVPコード7）はUnsigned32タイプで、EAP認証が正常に完了したかどうかを示します。結果コードのAVP値については、以下で説明します。
PANA_SUCCESS 0
PANA_SUCCESS 0
Both authentication and authorization processes are successful.
認証と承認の両方のプロセスが成功します。
PANA_AUTHENTICATION_REJECTED 1
PANA_AUTHENTICATION_REJECTED 1
Authentication has failed. When authentication fails, authorization is also considered to have failed.
認証に失敗しました。認証が失敗すると、承認も失敗したと見なされます。
PANA_AUTHORIZATION_REJECTED 2
PANA_AUTHORIZATION_REJECTED 2
The authorization process has failed. This error could occur when authorization is rejected by a AAA server or rejected locally by a PAA, even if the authentication procedure has succeeded.
承認プロセスが失敗しました。このエラーは、認証手順が成功した場合でも、認証がAAAサーバーによって拒否されたか、PAAによってローカルで拒否された場合に発生する可能性があります。
The Session-Lifetime AVP (AVP Code 8) contains the number of seconds remaining before the current session is considered expired. The AVP data is of type Unsigned32.
Session-Lifetime AVP（AVPコード8）には、現在のセッションが期限切れと見なされるまでの残りの秒数が含まれています。 AVPデータのタイプはUnsigned32です。
The Termination-Cause AVP (AVP Code 9) is used for indicating the reason why a session is terminated by the requester. The AVP data is of type Enumerated. The following Termination-Cause data values are used with PANA.
Termination-Cause AVP（AVPコード9）は、リクエスタがセッションを終了した理由を示すために使用されます。 AVPデータは列挙型です。次のTermination-Causeデータ値は、PANAで使用されます。
LOGOUT 1 (PaC -> PAA)
ログアウト1（パス-> Pa）
The client initiated a disconnect.
クライアントが切断を開始しました。
ADMINISTRATIVE 4 (PAA -> PaC)
管理4（PAA-> PaC）
The client was not granted access or was disconnected due to administrative reasons.
クライアントはアクセスを許可されなかったか、管理上の理由により切断されました。
SESSION_TIMEOUT 8 (PAA -> PaC)
SESSION_TIMEOUT 8（PAA-> PaC）
The session has timed out, and service has been terminated.
セッションがタイムアウトし、サービスが終了しました。
The PANA protocol provides retransmissions for the PANA-Client-Initiation message and all request messages.
PANAプロトコルは、PANA-Client-Initiationメッセージとすべての要求メッセージの再送信を提供します。
PANA retransmission timers are based on the model used in DHCPv6 [RFC3315]. Variables used here are also borrowed from this specification. PANA is a request/response-based protocol. The message exchange terminates when the requester successfully receives the answer, or the message exchange is considered to have failed according to the retransmission mechanism described below.
PANA再送信タイマーは、DHCPv6 [RFC3315]で使用されているモデルに基づいています。ここで使用される変数も、この仕様から借用されています。 PANAは、要求/応答ベースのプロトコルです。メッセージ交換は、リクエスタが応答を正常に受信したときに終了します。または、メッセージ交換は、以下で説明する再送信メカニズムに従って失敗したと見なされます。
The retransmission behavior is controlled and described by the following variables:
再送信動作は、次の変数によって制御および記述されます。
RT Retransmission timeout from the previous (re)transmission
前回の（再）送信からのRT再送信タイムアウト
IRT Base value for RT for the initial retransmission
最初の再送信のRTのIRTベース値
MRC Maximum retransmission count
MRC最大再送信カウント
MRT Maximum retransmission time
MRT最大再送信時間
MRD Maximum retransmission duration
MRD最大再送信期間
RAND Randomization factor
RANDランダム化係数
With each message transmission or retransmission, the sender sets RT according to the rules given below. If RT expires before the message exchange terminates, the sender recomputes RT and retransmits the message.
メッセージの送信または再送信のたびに、送信者は以下に示すルールに従ってRTを設定します。メッセージ交換が終了する前にRTが期限切れになると、送信者はRTを再計算してメッセージを再送信します。
Each of the computations of a new RT include a randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize the synchronization of messages.
新しいRTの各計算には、ランダム化係数（RAND）が含まれます。これは、-0.1から+0.1までの一様分布で選択された乱数です。メッセージの同期を最小限に抑えるために、ランダム化係数が含まれています。
The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of random numbers from each invocation.
乱数を選択するアルゴリズムは、暗号的に適切である必要はありません。アルゴリズムは、呼び出しごとに異なる一連の乱数を生成する必要があります（SHOULD）。
RT for the first message retransmission is based on IRT:
最初のメッセージ再送信のRTはIRTに基づいています。
RT = IRT + RAND*IRT
RT for each subsequent message retransmission is based on the previous value of RT:
後続の各メッセージ再送信のRTは、RTの以前の値に基づいています。
RT = 2*RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT (disregarding the randomization added by the use of RAND). If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise:
MRTは、RTの値の上限を指定します（RANDの使用によって追加されたランダム化は無視されます）。 MRTの値が0の場合、RTの値に上限はありません。さもないと：
if (RT > MRT)
RT = MRT + RAND*MRT
MRC specifies an upper bound on the number of times a sender may retransmit a message. Unless MRC is zero, the message exchange fails once the sender has transmitted the message MRC times.
MRCは、送信者がメッセージを再送信できる回数の上限を指定します。 MRCがゼロでない限り、送信者がメッセージをMRC回送信すると、メッセージ交換は失敗します。
MRD specifies an upper bound on the length of time a sender may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message.
MRDは、送信者がメッセージを再送信できる時間の長さの上限を指定します。 MRDがゼロでない限り、クライアントが最初にメッセージを送信してからMRD秒が経過すると、メッセージ交換は失敗します。
If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met.
MRCとMRDの両方がゼロ以外の場合、前の2つの段落で指定された条件のいずれかが満たされると、メッセージ交換は失敗します。
If both MRC and MRD are zero, the client continues to transmit the message until it receives a response.
MRCとMRDの両方がゼロの場合、クライアントは応答を受信するまでメッセージを送信し続けます。
This section presents a table of values used to describe the message retransmission behavior of PANA requests (REQ_*) and PANA-Client-Initiation message (PCI_*). The table shows default values.
このセクションでは、PANA要求（REQ_ *）およびPANA-Client-Initiationメッセージ（PCI_ *）のメッセージ再送信動作を説明するために使用される値の表を示します。表にデフォルト値を示します。
Parameter Default Description
---------------------------------------------------------------------
PCI_IRT 1 sec Initial PCI timeout.
PCI_MRT 120 secs Max PCI timeout value.
PCI_MRC 0 Max PCI retransmission attempts.
PCI_MRD 0 Max PCI retransmission duration.
REQ_IRT 1 sec Initial Request timeout. REQ_MRT 30 secs Max Request timeout value. REQ_MRC 10 Max Request retransmission attempts. REQ_MRD 0 Max Request retransmission duration.
REQ_IRT 1秒初期リクエストのタイムアウト。 REQ_MRT 30秒の最大要求タイムアウト値。 REQ_MRC 10最大要求再送信試行。 REQ_MRD 0最大要求再送信期間。
So, for example, the first RT for the PANA-Auth-Request (PAR) message is calculated using REQ_IRT as the IRT:
したがって、たとえば、PANA-Auth-Request（PAR）メッセージの最初のRTは、IRTとしてREQ_IRTを使用して計算されます。
RT = REQ_IRT + RAND*REQ_IRT
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the registration of values related to the PANA protocol, in accordance with BCP 26 [IANA]. The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", and "Standards Action".
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the registration of values related to the PANA protocol, in accordance with BCP 26 [IANA]. The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", and "Standards Action".
This section explains the criteria to be used by the IANA for assignment of numbers within namespaces defined within this document.
This section explains the criteria to be used by the IANA for assignment of numbers within namespaces defined within this document.
For registration requests where a Designated Expert should be consulted, the responsible IESG Area Director should appoint the Designated Expert. For Designated Expert with Specification Required, the request is posted to the PANA WG mailing list (or, if it has been disbanded, a successor designated by the Area Director) for comment and review, and MUST include a pointer to a public specification. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the PANA WG mailing list or its successor. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
指定専門家に相談する必要がある登録要求については、担当IESGエリアディレクターが指定専門家を指名する必要があります。仕様が必要な指定エキスパートの場合、リクエストはPANA WGメーリングリスト（または解散された場合は、エリアディレクターによって指定された後継者）にコメントとレビューのために投稿され、公開仕様へのポインターを含める必要があります。 30日が経過する前に、指定専門家は登録要求を承認または拒否し、決定の通知をPANA WGメーリングリストまたはその後継者に公開します。拒否通知は説明によって正当化する必要があり、可能な場合は、要求を受け入れられるように変更する方法に関する具体的な提案を行う必要があります。
IANA has created a registry for PANA.
IANAはPANAのレジストリを作成しました。
PANA uses one well-known UDP port number (see Section 6.1), which has been assigned by the IANA (716).
PANAは、IANA（716）によって割り当てられた1つの既知のUDPポート番号（セクション6.1を参照）を使用します。
As defined in Section 6.2, the PANA message header contains two fields that require IANA namespace management; the Message Type and Flags fields.
セクション6.2で定義されているように、PANAメッセージヘッダーには、IANA名前空間の管理を必要とする2つのフィールドが含まれています。メッセージタイプとフラグフィールド。
The Message Type namespace is used to identify PANA messages. Message Type 0 is not used and is not assigned by IANA. The range of values 1 - 65,519 are for permanent, standard message types, allocated by IETF Consensus [IANA]. This document defines the range of values 1 - 4. The same Message Type is used for both the request and the answer messages, except for type 1. The Request bit distinguishes requests from answers. See Section 7 for the assignment of the namespace in this specification.
メッセージタイプ名前空間は、PANAメッセージを識別するために使用されます。メッセージタイプ0は使用されず、IANAによって割り当てられません。値の範囲1〜65,519は、IETFコンセンサス[IANA]によって割り当てられた永続的な標準メッセージタイプ用です。このドキュメントでは、値1〜4の範囲を定義します。タイプ1を除いて、要求メッセージと応答メッセージの両方に同じメッセージタイプが使用されます。要求ビットは、要求と応答を区別します。この仕様での名前空間の割り当てについては、セクション7を参照してください。
The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 - 0xffff) are reserved for experimental messages. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between the communicating PaC and PAA using experimental commands, as outlined in [IANA-EXP].
値の範囲65,520〜65,535（16進値0xfff0〜0xffff）は、実験的なメッセージ用に予約されています。これらのコードは実験とテストのみを目的としているため、[IANA-EXP]で概説されているように、実験コマンドを使用して通信するPaCとPAA間の相互運用性は保証されません。
There are 16 bits in the Flags field of the PANA message header. This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4 ('P'), and 5 ('I') in Section 6.2. The remaining bits MUST only be assigned via a Standards Action [IANA].
PANAメッセージヘッダーのフラグフィールドには16ビットがあります。このドキュメントでは、セクション6.2でビット0（ 'R'）、1（ 'S'）、2（ 'C'）、3（ 'A'）、4（ 'P'）、および5（ 'I'）を割り当てます。残りのビットは、標準アクション[IANA]を介してのみ割り当てられる必要があります。
As defined in Section 6.3, the AVP header contains three fields that require IANA namespace management; the AVP Code, AVP Flags, and Vendor-Id fields, where only the AVP Code and AVP Flags created new namespaces.
セクション6.3で定義されているように、AVPヘッダーには、IANA名前空間の管理を必要とする3つのフィールドが含まれています。 AVPコード、AVPフラグ、およびベンダーIDフィールド。AVPコードとAVPフラグのみが新しい名前空間を作成します。
The 16-bit AVP code namespace is used to identify attributes. There are multiple namespaces. Vendors can have their own AVP codes namespace, which will be identified by their Vendor-Id (also known as Enterprise-Number), and they control the assignments of their vendor-specific AVP codes within their own namespace. The absence of a Vendor-Id identifies the IETF IANA controlled AVP codes namespace. The AVP codes, and sometimes also possible values in an AVP, are controlled and maintained by IANA.
16ビットのAVPコード名前空間は、属性を識別するために使用されます。複数の名前空間があります。ベンダーは、独自のAVPコード名前空間を持つことができます。これは、ベンダーID（別名エンタープライズ番号）によって識別され、独自の名前空間内のベンダー固有のAVPコードの割り当てを制御します。 Vendor-Idがないことは、IETF IANAが制御するAVPコード名前空間を識別します。 AVPコード、およびAVPで可能な値も、IANAによって制御および維持されます。
AVP Code 0 is not used and is not assigned by IANA. This document defines the AVP Codes 1-9. See Section 8.1 through Section 8.9 for the assignment of the namespace in this specification.
AVPコード0は使用されず、IANAによって割り当てられません。このドキュメントでは、AVPコード1〜9を定義しています。この仕様での名前空間の割り当てについては、セクション8.1からセクション8.9を参照してください。
AVPs may be allocated following Designated Expert Review with Specification Required [IANA] or Standards Action.
AVPは、Specified Required [IANA]またはStandards Actionを指定したDesignated Expert Reviewに従って割り当てることができます。
Note that PANA defines a mechanism for Vendor-Specific AVPs, where the Vendor-Id field in the AVP header is set to a non-zero value. Vendor-Specific AVP codes are for Private Use and should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of PANA, where no interoperability is deemed useful. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs should be encouraged instead.
PANAはベンダー固有のAVPのメカニズムを定義することに注意してください。AVPヘッダーのベンダーIDフィールドはゼロ以外の値に設定されます。ベンダー固有のAVPコードは私的使用のためのものであり、相互運用性が役に立たないと見なされるPANAの1つのベンダーの実装にのみ固有の機能では、グローバル属性タイプの割り当ての代わりに推奨されます。ベンダー固有のAVPが複数のベンダーによって実装されている場合は、代わりにグローバルAVPの割り当てを推奨する必要があります。
There are 16 bits in the AVP Flags field of the AVP header, defined in Section 6.3. This document assigns bit 0 ('V'). The remaining bits should only be assigned via a Standards Action .
セクション6.3で定義されているAVPヘッダーのAVPフラグフィールドには16ビットがあります。このドキュメントはビット0（ 'V'）を割り当てます。残りのビットは、標準アクションを介してのみ割り当てる必要があります。
Certain AVPs in PANA define a list of values with various meanings. For attributes other than those specified in this section, adding additional values to the list can be done on a First Come, First Served basis by IANA [IANA].
PANAの特定のAVPは、さまざまな意味を持つ値のリストを定義します。このセクションで指定されている以外の属性については、リストに値を追加することは、IANA [IANA]による先着順で行うことができます。
As defined in Section 8.7, the Result-Code AVP (AVP Code 7) defines the values 0-2.
セクション8.7で定義されているように、結果コードAVP（AVPコード7）は値0〜2を定義します。
All remaining values are available for assignment via IETF Consensus [IANA].
残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.9, the Termination-Cause AVP (AVP Code 9) defines the values 1, 4, and 8.
セクション8.9で定義されているように、Termination-Cause AVP（AVPコード9）は値1、4、および8を定義します。
All remaining values are available for assignment via IETF Consensus [IANA].
残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
The PANA protocol defines a UDP-based EAP encapsulation that runs between two IP-enabled nodes. Various security threats that are relevant to a protocol of this nature are outlined in [RFC4016]. Security considerations stemming from the use of EAP and EAP methods are discussed in [RFC3748] [EAP-KEYING]. This section provides a discussion on the security-related issues that are related to PANA framework and protocol design.
The PANA protocol defines a UDP-based EAP encapsulation that runs between two IP-enabled nodes. Various security threats that are relevant to a protocol of this nature are outlined in [RFC4016]. Security considerations stemming from the use of EAP and EAP methods are discussed in [RFC3748] [EAP-KEYING]. This section provides a discussion on the security-related issues that are related to PANA framework and protocol design.
An important element in assessing the security of PANA design and deployment in a network is the presence of lower-layer security. In the context of this document, lower layers are said to be secure if the environment provides adequate protection against spoofing and confidentiality based on its operational needs. For example, DSL and cdma2000 networks' lower-layer security is enabled even before running the first PANA-based authentication. In the absence of such a preestablished secure channel prior to running PANA, one can be created after the successful PANA authentication using a link-layer or network-layer cryptographic mechanism (e.g., IPsec).
PANAの設計とネットワークへの展開のセキュリティを評価する上で重要な要素は、下位層のセキュリティの存在です。このドキュメントのコンテキストでは、環境がその運用上のニーズに基づいてスプーフィングと機密性に対する適切な保護を提供する場合、下位層は安全であると言われます。たとえば、DSLおよびcdma2000ネットワークの下位層セキュリティは、最初のPANAベースの認証を実行する前でも有効になっています。 PANAを実行する前にそのような事前に確立された安全なチャネルがない場合、リンク層またはネットワーク層の暗号化メカニズム（IPsecなど）を使用してPANA認証が成功した後にチャネルを作成できます。
PANA provides multiple mechanisms to secure a PANA session.
PANAは、PANAセッションを保護するための複数のメカニズムを提供します。
PANA messages carry sequence numbers, which are monotonically incremented by 1 with every new request message. These numbers are randomly initialized at the beginning of the session, and they are verified against expected numbers upon receipt. A message whose sequence number is different than the expected one is silently discarded. In addition to accomplishing orderly delivery of EAP messages and duplicate elimination, this scheme also helps prevent an adversary from spoofing messages to disturb ongoing PANA and EAP sessions unless it can also eavesdrop to synchronize with the expected sequence number. Furthermore, impact of replay attacks is reduced as any stale message (i.e., a request or answer with an unexpected sequence number and/or a session identifier for a non-existing session) and any duplicate answer are immediately discarded, and a duplicate request can trigger transmission of the cached answer (i.e., no need to process the request and generate a new answer).
PANAメッセージにはシーケンス番号があり、新しい要求メッセージごとに1ずつ単調に増加します。これらの番号はセッションの開始時にランダムに初期化され、受信時に予想される番号に対して検証されます。シーケンス番号が予期したものと異なるメッセージは、通知なく破棄されます。このスキームは、EAPメッセージの順序どおりの配信と重複の排除に加えて、予想されるシーケンス番号と同期して傍受できない限り、攻撃者がメッセージをスプーフィングして進行中のPANAおよびEAPセッションを妨害するのを防ぐのにも役立ちます。さらに、古くなったメッセージ（つまり、予期しないシーケンス番号を含む要求または応答、および/または存在しないセッションのセッション識別子）や、重複する応答がすぐに破棄されるため、リプレイ攻撃の影響が軽減され、重複した要求はキャッシュされた回答の送信をトリガーします（つまり、要求を処理して新しい回答を生成する必要はありません）。
The PANA framework defines EP, which is ideally located on a network device that can filter traffic from the PaCs before the traffic enters the Internet/intranet. A set of filters can be used to discard unauthorized packets, such as the initial PANA-Auth-Request message that is received from the segment of the access network, where only the PaCs are supposed to be connected (i.e., preventing PAA impersonation).
PANAフレームワークはEPを定義します。EPは、トラフィックがインターネット/イントラネットに入る前に、PaCからのトラフィックをフィルタリングできるネットワークデバイスに理想的に配置されます。一連のフィルターを使用して、アクセスネットワークのセグメントから受信された最初のPANA-Auth-Requestメッセージなど、PaCのみが接続されている（つまり、PAAのなりすましを防ぐ）ように、不正なパケットを破棄できます。
The protocol also provides authentication and integrity protection to PANA messages when the used EAP method can generate cryptographic session keys. A PANA SA is generated based on the MSK exported by the EAP method. This SA is used for generating an AUTH AVP to protect the PANA message header and payload (including the complete EAP message).
また、このプロトコルは、使用されるEAP方式が暗号化セッションキーを生成できる場合、PANAメッセージに認証と整合性保護を提供します。 PANA SAは、EAP方式でエクスポートされたMSKに基づいて生成されます。このSAは、AUTH AVPを生成してPANAメッセージヘッダーとペイロード（完全なEAPメッセージを含む）を保護するために使用されます。
The cryptographic protection prevents an adversary from acting as a man-in-the-middle, injecting messages, replaying messages and modifying the content of the exchanged messages. Any packet that fails to pass the AUTH verification is silently discarded. The earliest this protection can be enabled is when the PANA-Auth-Request message that signals a successful authentication (EAP Success) is generated. Starting with these messages, any subsequent PANA message can be cryptographically protected until the session gets torn down.
The cryptographic protection prevents an adversary from acting as a man-in-the-middle, injecting messages, replaying messages and modifying the content of the exchanged messages. Any packet that fails to pass the AUTH verification is silently discarded. The earliest this protection can be enabled is when the PANA-Auth-Request message that signals a successful authentication (EAP Success) is generated. Starting with these messages, any subsequent PANA message can be cryptographically protected until the session gets torn down.
The lifetime of the PANA SA is set to the PANA session lifetime, which is bounded by the authorization lifetime granted by the authentication server. An implementation MAY add a grace period to that value. Unless the PANA session is extended by executing another EAP authentication, the PANA SA is removed when the current session expires.
The lifetime of the PANA SA is set to the PANA session lifetime, which is bounded by the authorization lifetime granted by the authentication server. An implementation MAY add a grace period to that value. Unless the PANA session is extended by executing another EAP authentication, the PANA SA is removed when the current session expires.
The ability to use cryptographic protection within PANA is determined by the used EAP method, which is generally dictated by the deployment environment. Insecure lower layers necessitate the use of key-generating EAP methods. In networks where lower layers are already secured, cryptographic protection of PANA messages is not necessary.
PANA内で暗号化保護を使用する機能は、使用されているEAP方式によって決まります。EAP方式は、通常、展開環境によって決まります。安全でない下位層では、キー生成EAPメソッドを使用する必要があります。下位層がすでに保護されているネットワークでは、PANAメッセージの暗号化による保護は必要ありません。
The initial PANA-Auth-Request and PANA-Auth-Answer exchange is vulnerable to spoofing attacks as these messages are not authenticated and integrity protected. In order to prevent very basic DoS attacks, an adversary should not be able to cause state creation by sending PANA-Client-Initiation messages to the PAA. This protection is achieved by allowing the responder (PAA) to create as little state as possible in the initial message exchange. However, it is difficult to prevent all spoofing attacks in the initial message exchange entirely.
最初のPANA-Auth-RequestおよびPANA-Auth-Answer交換は、これらのメッセージが認証されておらず、整合性が保護されていないため、なりすまし攻撃に対して脆弱です。非常に基本的なDoS攻撃を防ぐために、攻撃者はPANA-Client-InitiationメッセージをPAAに送信して状態を作成できないようにする必要があります。この保護は、レスポンダー（PAA）が最初のメッセージ交換でできる限り少ない状態を作成できるようにすることで実現されます。ただし、最初のメッセージ交換ですべてのなりすまし攻撃を完全に防ぐことは困難です。
Eavesdropping EAP messages might cause problems when the EAP method is weak and enables dictionary or replay attacks or even allows an adversary to learn the long-term password directly. Furthermore, if the optional EAP Response/Identity payload is used, then it allows the adversary to learn the identity of the PaC. In such a case, a privacy problem is prevalent.
EAPメッセージが盗聴されると、EAPメソッドが脆弱で、辞書攻撃やリプレイ攻撃が可能になったり、攻撃者が長期間のパスワードを直接知ることができる場合に問題が発生する可能性があります。さらに、オプションのEAP Response / Identityペイロードを使用すると、攻撃者はPaCのIDを知ることができます。このような場合、プライバシーの問題が蔓延します。
To prevent these threats, [RFC5193] suggests using proper EAP methods for particular environments. Depending on the deployment environment, an EAP authentication method that supports user-identity confidentiality, protection against dictionary attacks, and session-key establishment must be used. It is therefore the responsibility of the network operators and users to choose a proper EAP method.
これらの脅威を防ぐために、[RFC5193]は特定の環境に適切なEAP方法を使用することを提案しています。展開環境によっては、ユーザーIDの機密性、辞書攻撃からの保護、およびセッションキーの確立をサポートするEAP認証方法を使用する必要があります。したがって、適切なEAP方式を選択するのは、ネットワークオペレーターとユーザーの責任です。
When the EAP method exports an MSK, this key is used to produce a PANA SA with PANA_AUTH_KEY with a distinct key ID. The PANA_AUTH_KEY is unique to the PANA session, and it takes PANA-based nonce values into computation to cryptographically separate itself from the MSK.
EAP方式がMSKをエクスポートする場合、このキーは、異なるキーIDを持つPANA_AUTH_KEYを持つPANA SAを生成するために使用されます。 PANA_AUTH_KEYは、PANAセッションに固有であり、PANAベースのナンス値を計算に使用して、MSKから暗号的に分離されます。
The PANA_AUTH_KEY is solely used for the authentication and integrity protection of the PANA messages within the designated session.
PANA_AUTH_KEYは、指定されたセッション内のPANAメッセージの認証と整合性保護にのみ使用されます。
The PANA SA lifetime is bounded by the MSK lifetime. Another execution of the EAP method yields a new MSK, and it updates the PANA SA, PANA_AUTH_KEY, and key ID.
PANA SAの有効期間は、MSKの有効期間によって制限されます。 EAPメソッドをもう一度実行すると、新しいMSKが生成され、PANA SA、PANA_AUTH_KEY、およびキーIDが更新されます。
Networks that are not secured at the lower layers prior to running PANA can rely on enabling per-packet data-traffic ciphering upon successful PANA SA establishment. The PANA framework allows generation of cryptographic keys from the PANA SA and uses the keys with a secure association protocol to enable per-packet cryptographic protection, such as link-layer or IPsec-based ciphering [PANA-IPSEC]. These mechanisms ultimately establish a cryptographic binding between the data traffic generated by and for a client and the authenticated identity of the client. Data traffic can be data origin authenticated, replay and integrity protected, and optionally encrypted using the cryptographic keys. How these keys are generated from the PANA SA and used with a secure association protocol is outside the scope of this document.
PANAを実行する前に下位層で保護されていないネットワークは、PANA SAの確立が成功したときに、パケットごとのデータトラフィック暗号化を有効にすることに依存できます。 PANAフレームワークは、PANA SAからの暗号化キーの生成を可能にし、セキュアアソシエーションプロトコルでキーを使用して、リンク層またはIPsecベースの暗号化[PANA-IPSEC]などのパケットごとの暗号化保護を有効にします。これらのメカニズムは、最終的に、クライアントによって生成されたデータトラフィックとクライアントの認証済みIDとの間に暗号バインディングを確立します。データトラフィックは、データ発信元を認証し、再生と整合性を保護し、オプションで暗号化キーを使用して暗号化できます。これらのキーがPANA SAから生成され、セキュアアソシエーションプロトコルで使用される方法は、このドキュメントの範囲外です。
The PANA framework allows separation of PAA from EP. The protocol exchange between the PAA and EP for provisioning authorized PaC information on the EP must be protected for authentication, integrity, and replay protection.
PANAフレームワークでは、EPからPAAを分離できます。 EPで承認されたPaC情報をプロビジョニングするためのPAAとEP間のプロトコル交換は、認証、整合性、および再生保護のために保護する必要があります。
A PANA session is associated with a session lifetime. The session is terminated unless it is refreshed by a new round of EAP authentication before it expires. Therefore, the latest a disconnected client can be detected is when its session expires. A disconnect may also be detected earlier by using PANA ping messages.
PANAセッションは、セッションの存続期間に関連付けられています。セッションは、有効期限が切れる前に新しいEAP認証で更新されない限り終了します。したがって、切断された最新のクライアントを検出できるのは、セッションの有効期限が切れたときです。切断は、PANA pingメッセージを使用して早期に検出される場合もあります。
A request message can be generated by either PaC or PAA at any time in access phase with the expectation that the peer responds with an answer message. A successful round-trip of this exchange is a simple verification that the peer is alive.
要求メッセージは、ピアが応答メッセージで応答することを期待して、アクセスフェーズのいつでもPaCまたはPAAによって生成できます。この交換のラウンドトリップが成功すると、ピアが生きていることを簡単に確認できます。
This test can be engaged when there is a possibility that the peer might have disconnected (e.g., after the discontinuation of data traffic for an extended period of time). Periodic use of this exchange as a keep-alive requires additional care, as it might result in congestion and hence false alarms.
このテストは、ピアが切断された可能性がある場合に実行できます（たとえば、長期間のデータトラフィックの中断後など）。キープアライブとしてこの交換を定期的に使用すると、輻輳が発生して誤警報が発生する可能性があるため、追加の注意が必要です。
This exchange is cryptographically protected when a PANA SA is available in order to prevent threats associated with the abuse of this functionality.
この機能の悪用に関連する脅威を防止するために、PANA SAが利用可能な場合、この交換は暗号で保護されます。
Any valid PANA answer message received in response to a recently sent request message can be taken as an indication of a peer's liveness. The PaC or PAA MAY forgo sending an explicit ping request message if a recent exchange has already confirmed that the peer is alive.
最近送信された要求メッセージへの応答として受信された有効なPANA応答メッセージは、ピアの活性の指標と見なすことができます。最近の交換でピアが有効であることをすでに確認している場合、PaCまたはPAAは明示的なping要求メッセージの送信を省略できます。
The PANA protocol supports the ability for both the PaC and the PAA to transmit a tear-down message before the session lifetime expires. This message causes state removal, a stop of the accounting procedure and removes the installed per-PaC state on the EP(s). This message is cryptographically protected when PANA SA is present.
PANAプロトコルは、PaCとPAAの両方がセッションの有効期限が切れる前にティアダウンメッセージを送信する機能をサポートしています。このメッセージにより、状態が削除され、アカウンティング手順が停止し、EPにインストールされているPaCごとの状態が削除されます。このメッセージは、PANA SAが存在するときに暗号で保護されます。
We would like to thank Mark Townsley, Jari Arkko, Mohan Parthasarathy, Julien Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo, Joseph Salowey, Sasikanth Bharadwaj, Spencer Dawkins, Tom Yu, Bernard Aboba, Subir Das, John Vollbrecht, Prakash Jayaraman, and all members of the PANA working group for their valuable comments on this document.
Mark Townsley、Jari Arkko、Mohan Parthasarathy、Julien Bournelle、Rafael Marin Lopez、Pasi Eronen、Randy Turner、Erik Nordmark、Lionel Morand、Avi Lior、Susan Thomson、Giaretta Gerardo、Joseph Salowey、Sasikanth Bharadwaj、Spencepに感謝します、トムユー、バーナードアボバ、スーバーダス、ジョンボルブレヒト、プラカシュジャヤラマン、およびこのドキュメントに関する貴重なコメントをいただいたPANAワーキンググループのすべてのメンバー。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5192] Morand, L., Yegin A., Kumar S., and S. Madanapalli, "DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents", RFC 5192, May 2008.
[RFC5192] Morand、L.、Yegin A.、Kumar S.、およびS. Madanapalli、「ネットワークアクセス（PANA）認証エージェントの認証を実行するためのプロトコルのDHCPオプション」、RFC 5192、2008年5月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、2003年7月。
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005.
[RFC4016] Parthasarathy、M。、「認証とネットワークアクセス（PANA）の脅威分析とセキュリティ要件を実行するためのプロトコル」、RFC 4016、2005年3月。
[RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005.
[RFC4058] Yegin、A.、Ed。、Ohba、Y.、Penno、R.、Tsirtsis、G。、およびC. Wang、「Protocol for Carrying Authentication for Network Access（PANA）Requirements」、RFC 4058、2005年5月。
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4137] Vollbrecht、J.、Eronen、P.、Petroni、N。、およびY. Ohba、「State Machines for Extensible Authentication Protocol（EAP）Peer and Authenticator」、RFC 4137、2005年8月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、編、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006.
[RFC4595] Maino、F。およびD. Black、「ファイバーチャネルセキュリティアソシエーション管理プロトコルでのIKEv2の使用」、RFC 4595、2006年7月。
[RFC5193] Jayaraman, P., Lopez R., Ohba Y., Ed., Parthasarathy, M., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Framework", RFC 5193, May 2008.
[RFC5193] Jayaraman、P.、Lopez R.、Ohba Y.、編、Parthasarathy、M。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）Framework」、RFC 5193、2008年5月。
[EAP-KEYING] Aboba, B., Simon D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, November 2007.
[EAP-KEYING] Aboba、B.、Simon D.、およびP. Eronen、「Extensible Authentication Protocol（EAP）Key Management Framework」、Work in Progress、2007年11月。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in progress, July 2005.
[PANA-IPSEC] Parthasarathy、M。、「PANA enable IPsec based Access Control」、進行中の作業、2005年7月。
[IANAWEB] IANA, "Number assignment", http://www.iana.org.
[IANAWEB] IANA、「番号割り当て」、http：//www.iana.org。
[IANA-EXP] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[IANA-EXP] Narten、T。、「Assigning Testing and Testing Numbers考慮されたUseful」、BCP 82、RFC 3692、2004年1月。
Authors' Addresses
著者のアドレス
Dan Forsberg Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Finland
ダンフォースバーグノキアリサーチセンターP.O.ボックス407 FIN-00045 NOKIA GROUPフィンランド
Phone: +358 50 4839470
EMail: dan.forsberg@nokia.com
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
大場義博東芝アメリカリサーチ社1 Telcordia Drive Piscataway、NJ 08854 USA
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nsn.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Alper E. Yegin Samsung Istanbul, Turkey
Alper E. Yegin Samsungイスタンブール、トルコ
EMail: a.yegin@partner.samsung.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。