[要約] RFC 6618は、モバイルノードとホームエージェント間の通信にTransport Layer Security（TLS）を使用するためのMobile IPv6セキュリティフレームワークに関するものです。このRFCの目的は、モバイルIPv6ネットワークでのセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6618 Nokia Siemens Networks
Category: Experimental B. Patil
ISSN: 2070-1721 Nokia
H. Tschofenig
Nokia Siemens Networks
D. Kroeselberg
Siemens
May 2012
Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent
モバイルノードとホームエージェント間の通信にトランスポート層セキュリティを使用するモバイルIPv6セキュリティフレームワーク
Abstract
概要
Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA.
モバイルノード（MN）とそのホームエージェント（HA）間のモバイルIPv6シグナリングは、IPsecを使用して保護されます。 MNとHA間のセキュリティアソシエーション（SA）は、インターネットキー交換プロトコル（IKE）バージョン1または2を使用して確立されます。IKE/ IPsecに依存するモバイルIPv6に指定されたセキュリティモデルは、モバイルIPv6プロトコルコンポーネント間の相互作用を必要としますIPスタックのIKE / IPsecモジュール。このドキュメントは、モバイルIPv6およびデュアルスタックモバイルIPv6の代替セキュリティフレームワークを提案します。これは、MNとHA間のモバイルIPv6シグナリングとデータトラフィックを保護するために必要なキーイングマテリアルとその他のブートストラップパラメータを確立するためにトランスポート層セキュリティに依存します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6618.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6618で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology and Abbreviations ...................................4
3. Background ......................................................5
4. TLS-Based Security Establishment ................................5
4.1. Overview ...................................................5
4.2. Architecture ...............................................7
4.3. Security Association Management ............................7
4.4. Bootstrapping of Additional Mobile IPv6 Parameters .........9
4.5. Protecting Traffic between Mobile Node and Home Agent .....10
5. MN-to-HAC Communication ........................................10
5.1. Request-Response Message Framing over TLS-Tunnel ..........10
5.2. Request-Response Message Content Encoding .................11
5.3. Request-Response Message Exchange .........................12
5.4. Home Agent Controller Discovery ...........................13
5.5. Generic Request-Response Parameters .......................13
5.5.1. Mobile Node Identifier .............................13
5.5.2. Authentication Method ..............................13
5.5.3. Extensible Authentication Protocol Payload .........14
5.5.4. Status Code ........................................14
5.5.5. Message Authenticator ..............................14
5.5.6. Retry After ........................................14
5.5.7. End of Message Content .............................14
5.5.8. Random Values ......................................15
5.6. Security Association Configuration Parameters .............15
5.6.1. Security Parameter Index ...........................15
5.6.2. MN-HA Shared Keys ..................................16
5.6.3. Security Association Validity Time .................16
5.6.4. Security Association Scope (SAS) ...................16
5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping ..17
5.7. Mobile IPv6 Bootstrapping Parameters ......................18
5.7.1. Home Agent Address .................................18
5.7.2. Mobile IPv6 Service Port Number ....................18
5.7.3. Home Addresses and Home Network Prefix .............18
5.7.4. DNS Server .........................................19
5.8. Authentication of the Mobile Node .........................19
5.9. Extensible Authentication Protocol Methods ................22
6. Mobile Node to Home Agent Communication ........................23
6.1. General ...................................................23
6.2. PType and Security Parameter Index ........................25
6.3. Binding Management Message Formats ........................25
6.4. Reverse-Tunneled User Data Packet Formats .................27
7. Route Optimization .............................................29
8. IANA Considerations ............................................29
8.1. New Registry: Packet Type .................................29
8.2. Status Codes ..............................................29
8.3. Port Numbers ..............................................29
9. Security Considerations ........................................30
9.1. Discovery of the HAC ......................................30
9.2. Authentication and Key Exchange Executed between
the MN and the HAC ........................................30
9.3. Protection of MN and HA Communication .....................33
9.4. AAA Interworking ..........................................35
10. Acknowledgements ..............................................35
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................36
Mobile IPv6 (MIPv6) [RFC6275] signaling, and optionally user traffic, between a Mobile Node (MN) and Home Agent (HA) are secured by IPsec [RFC4301]. The current Mobile IPv6 security architecture is specified in [RFC3776] and [RFC4877]. This security model requires a tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ IPsec part of the IP stack. Client implementation experience has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex.
モバイルノード（MN）とホームエージェント（HA）間のモバイルIPv6（MIPv6）[RFC6275]シグナリング、およびオプションでユーザートラフィックは、IPsec [RFC4301]によって保護されます。現在のモバイルIPv6セキュリティアーキテクチャは、[RFC3776]および[RFC4877]で指定されています。このセキュリティモデルでは、モバイルIPv6プロトコル部分とIPスタックのIKE（v2）/ IPsec部分の間の密結合が必要です。クライアント実装の経験から、モバイルIPv6でのIKE（v2）/ IPsecの使用はかなり複雑であることがわかっています。
This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify implementations as well as make it easy to deploy the protocol without compromising on security. Transport Layer Security (TLS) [RFC5246] is widely implemented in almost all major operating systems and extensively used by various applications. Instead of using IKEv2 to establish security associations, the security framework proposed in this document is based on TLS-protected messages to exchange keys and bootstrapping parameters between the MN and a new functional entity called the "Home Agent Controller" (HAC). The Mobile IPv6 signaling between the mobile node and home agent is subsequently secured using the resulting keys and negotiated ciphersuite. The HAC can be co-located with the HA, or it can be an independent entity. For the latter case, communication between the HAC and HA is not defined by this document. Such communication could be built on top of AAA protocols such as Diameter.
このドキュメントは、モバイルIPv6およびデュアルスタックモバイルIPv6の代替セキュリティフレームワークを提案します。目的は、実装を簡素化するだけでなく、セキュリティを損なうことなくプロトコルを簡単に展開できるようにすることです。トランスポート層セキュリティ（TLS）[RFC5246]は、ほとんどすべての主要なオペレーティングシステムに広く実装されており、さまざまなアプリケーションで広く使用されています。このドキュメントで提案するセキュリティフレームワークは、IKEv2を使用してセキュリティアソシエーションを確立する代わりに、TLSで保護されたメッセージに基づいており、MNと「ホームエージェントコントローラ」（HAC）と呼ばれる新しい機能エンティティ間でキーとブートストラップパラメータを交換します。その後、モバイルノードとホームエージェント間のモバイルIPv6シグナリングは、結果のキーとネゴシエートされた暗号スイートを使用して保護されます。 HACはHAと同じ場所に配置することも、独立したエンティティにすることもできます。後者の場合、HACとHA間の通信は、このドキュメントでは定義されていません。このような通信は、DiameterなどのAAAプロトコルの上に構築できます。
The primary advantage of using TLS for the establishment of Mobile IPv6 security associations as compared to the use of IKEv2 is the ease of implementation (especially on the mobile nodes) while providing an equivalent level of security. A solution which decouples Mobile IPv6 security from IPsec, for securing signaling messages and user plane traffic, is proposed herein that reduces client implementation complexity.
IKEv2の使用と比較して、モバイルIPv6セキュリティアソシエーションの確立にTLSを使用する主な利点は、同等のレベルのセキュリティを提供しながら、（特にモバイルノードで）実装が容易なことです。シグナリングメッセージとユーザープレーントラフィックを保護するために、モバイルIPv6セキュリティをIPsecから分離するソリューションがここに提案され、クライアントの実装の複雑さが軽減されます。
The security framework proposed in this document is not intended to replace the currently specified architecture that relies on IPsec and IKEv2. It provides an alternative solution that is more optimal for certain deployment scenarios. This and other alternative security models have been considered by the MEXT working group at the IETF, and it has been decided that the alternative solutions should be published as Experimental RFCs, so that more implementation and deployment experience with these models can be gathered. The status of this proposal may be reconsidered in the future if it becomes clear that it is superior to others.
このドキュメントで提案されているセキュリティフレームワークは、IPsecとIKEv2に依存する現在指定されているアーキテクチャを置き換えることを意図したものではありません。特定の展開シナリオに最適な代替ソリューションを提供します。このモデルや他の代替セキュリティモデルは、IETFの文部科学省ワーキンググループによって検討されており、これらのモデルを使用した実装と展開の経験をさらに収集できるように、代替ソリューションを試験的RFCとして公開することが決定されています。この提案の状況は、他よりも優れていることが明らかになった場合、将来的に再検討される可能性があります。
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]で説明されているように解釈されます。
Home Agent Controller (HAC):
ホームエージェントコントローラー（HAC）：
The home agent controller is a node responsible for bootstrapping Mobile IPv6 security associations between a mobile node and one or more home agents. The home agent controller also provides key distribution to both mobile nodes and home agents. Mobile IPv6 bootstrapping is also performed by the HA in addition to the security association bootstrapping between the mobile node and home agent controller.
ホームエージェントコントローラは、モバイルノードと1つ以上のホームエージェント間のモバイルIPv6セキュリティアソシエーションのブートストラップを担当するノードです。また、ホームエージェントコントローラは、モバイルノードとホームエージェントの両方にキーを配布します。モバイルノードとホームエージェントコントローラ間のセキュリティアソシエーションブートストラップに加えて、モバイルIPv6ブートストラップもHAによって実行されます。
Binding Management Messages:
バインディング管理メッセージ：
Mobile IPv6 signaling messages between a mobile node and a home agent, correspondent node, or mobility access point to manage the bindings are referred to as binding management messages. Binding Updates (BUs) and Binding Acknowledgement (BA) messages are examples of binding management messages.
バインディングを管理するためのモバイルノードとホームエージェント、コレスポンデントノード、またはモビリティアクセスポイント間のモバイルIPv6シグナリングメッセージは、バインディング管理メッセージと呼ばれます。バインディング更新（BU）メッセージとバインディング確認（BA）メッセージは、バインディング管理メッセージの例です。
Mobile IPv6 design and specification began in the mid-to-late 90s. The security architecture of Mobile IPv6 was based on the understanding that IPsec is an inherent and integral part of the IPv6 stack and any protocol that needs security should use IPsec unless there is a good reason not to. As a result of this mindset, the Mobile IP6 protocol relied on the use of IPsec for security between the MN and HA. Reusing security components that are an integral part of the IP stack is a good design objective for any protocol; however, in the case of Mobile IPv6, it increases implementation complexity. It should be noted that Mobile IPv4 [RFC5944], for example, does not use IPsec for security and instead has specified its own security solution. Mobile IPv4 has been implemented and deployed on a reasonably large scale and the security model has proven itself to be sound.
モバイルIPv6の設計と仕様は90年代半ばから後半にかけて始まりました。モバイルIPv6のセキュリティアーキテクチャは、IPsecがIPv6スタックに固有の不可欠な部分であり、セキュリティを必要とするプロトコルは、正当な理由がない限りIPsecを使用する必要があるという理解に基づいていました。この考え方の結果として、モバイルIP6プロトコルは、MNとHA間のセキュリティのためにIPsecの使用に依存していました。 IPスタックの不可欠な部分であるセキュリティコンポーネントを再利用することは、どのプロトコルにとっても優れた設計目標です。ただし、モバイルIPv6の場合は、実装が複雑になります。たとえば、モバイルIPv4 [RFC5944]は、セキュリティにIPsecを使用せず、独自のセキュリティソリューションを指定していることに注意してください。モバイルIPv4は適度に大規模に実装および展開されており、セキュリティモデル自体が健全であることが証明されています。
Mobile IPv6 standardization was completed in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776
[RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IPv6
security has also been updated to rely on the use of IKEv2 [RFC4877].
Implementation exercises of Mobile IPv6 and Dual-Stack Mobile IPv6
[RFC5555] have identified the complexity of using IPsec and IKEv2 in
conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec
and IKEv2 requires modifications to both the IPsec and IKEv2
components, due to the communication models that Mobile IPv6 uses and
the changing IP addresses. For further details, see Section 7.1 in
[RFC3776].
This document proposes a security framework based on TLS-protected establishment of Mobile IPv6 security associations, which reduces implementation complexity while maintaining an equivalent (to IKEv2/ IPsec) level of security.
このドキュメントは、TLSで保護されたモバイルIPv6セキュリティアソシエーションの確立に基づくセキュリティフレームワークを提案します。これにより、同等の（IKEv2 / IPsecへの）レベルのセキュリティを維持しながら、実装の複雑さが軽減されます。
The security architecture proposed in this document relies on a secure TLS session established between the MN and the HAC for mutual authentication and MN-HA security association bootstrapping. Authentication of the HAC is done via standard TLS operation wherein the HAC uses a TLS server certificate as its credentials. MN authentication is done by the HAC via signaling messages that are secured by the TLS connection. Any Extensible Authentication Protocol (EAP) method or Pre-Shared Key (PSK) can be used for authenticating the MN to the HAC. Upon successful completion of authentication, the HAC generates keys that are delivered to the MN through the secure TLS channel. The same keys are also provided to the assigned HA. The HAC also provides the MN with MIPv6 bootstrapping information such as the IPv6 and IPv4 address of the HA, the home network prefix, the IPv6 and/or IPv4 Home Address (HoA), and DNS server address.
このドキュメントで提案されているセキュリティアーキテクチャは、相互認証とMN-HAセキュリティアソシエーションのブートストラップを、MNとHACの間に確立された安全なTLSセッションに依存しています。 HACの認証は、HACが資格情報としてTLSサーバー証明書を使用する標準のTLS操作を介して行われます。 MN認証は、TLS接続によって保護されているシグナリングメッセージを介してHACによって行われます。 HACに対するMNの認証には、任意の拡張認証プロトコル（EAP）メソッドまたは事前共有キー（PSK）を使用できます。認証が正常に完了すると、HACは安全なTLSチャネルを介してMNに配信される鍵を生成します。同じキーが割り当てられたHAにも提供されます。 HACは、MNに、HAのIPv6およびIPv4アドレス、ホームネットワークプレフィックス、IPv6またはIPv4ホームアドレス（HoA）、DNSサーバーアドレスなどのMIPv6ブートストラップ情報も提供します。
The MN and HA use security associations based on the keys and Security Parameter Indexes (SPIs) generated by the HAC and delivered to the MN and HA to secure signaling and optionally user plane traffic. Figure 1 below is an illustration of the process.
MNとHAは、HACによって生成され、MNとHAに配信されるキーとセキュリティパラメータインデックス（SPI）に基づいてセキュリティアソシエーションを使用して、シグナリングとオプションのユーザープレーントラフィックを保護します。下の図1は、このプロセスを示しています。
Signaling messages and user plane traffic between the MN and HA are always UDP encapsulated. The packet formats for the signaling and user plane traffic is described in Sections 6.3 and 6.4.
MNとHA間のシグナリングメッセージとユーザープレーントラフィックは、常にUDPカプセル化されます。シグナリングおよびユーザープレーントラフィックのパケット形式については、セクション6.3および6.4で説明します。
MN HAC HA
-- --- --
| | |
| /-------------------------\ | |
|/ \| |
|\ TLS session setup /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ MN Authentication \| |
|\ /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ HAC provisions the MN \| |
|\ keys, SPI, & MIPv6 parms /| |
| \-------------------------/ | |
| |--MNID, keys, SPI->|
| | |
| /--------------------------------------------\ |
|/ MN-HA SA established; Secures \ |
|\ signaling and optionally user traffic / |
| \--------------------------------------------/ |
| |
|------------BU(encrypted)----------------------->|
| |
|<---------BAck(encrypted)------------------------|
Figure 1: High-Level Architecture
図1：高レベルのアーキテクチャ
The TLS-based security architecture is shown in Figure 2. The signaling message exchange between the MN and the HAC is protected by TLS. It should be noted that an HAC, a AAA server, and an HA are logically separate entities and can be collocated in all possible combinations. There MUST be a strong trust relationship between the HA and the HAC, and the communication between them MUST be both integrity and confidentially protected.
TLSベースのセキュリティアーキテクチャを図2に示します。MNとHAC間のシグナリングメッセージ交換は、TLSによって保護されています。 HAC、AAAサーバー、およびHAは論理的に別個のエンティティーであり、可能なすべての組み合わせで配置することができることに注意してください。 HAとHACの間には強力な信頼関係がなければならず、それらの間の通信は整合性と機密保護の両方を行う必要があります。
+------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | |
+------+ +------+ +------+
^ ^ ^
| | |
| BU/BA/../ | e.g., AAA | AAA
| (Data) | |
| v |
| +---------+ |
| | MIPv6 | |
+--------------->| Home |<-------------+
| Agent(s)|
+---------+
Figure 2: TLS-Based Security Architecture Overview
図2：TLSベースのセキュリティアーキテクチャの概要
Once the MN has contacted the HAC and mutual authentication has taken place between the MN and the HAC, the HAC securely provisions the MN with all security-related information inside the TLS protected tunnel. This security-related information constitutes a security association (SA) between the MN and the HA. The created SA MUST NOT be tied to the Care-of Address (CoA) of the MN.
MNがHACに接続し、MNとHACの間で相互認証が行われると、HACはTLSで保護されたトンネル内のすべてのセキュリティ関連情報を安全にMNにプロビジョニングします。このセキュリティ関連情報は、MNとHA間のセキュリティアソシエーション（SA）を構成します。作成されたSAは、MNの気付アドレス（CoA）に関連付けられてはなりません（MUST NOT）。
The HAC may proactively distribute the SA information to HAs, or the HA may query the SA information from the HAC once the MN contacts the HA. If the HA requests SA information from the HAC, then the HA MUST be able to query/index the SA information from the HAC based on the SPI identifying the correct security association between the MN and the HA.
ＨＡＣは、積極的にＳＡ情報をＨＡに配信することができ、またはＭＮがＨＡに連絡すると、ＨＡは、ＨＡＣにＳＡ情報を照会することができる。 HAがHACからSA情報を要求する場合、HAは、MNとHAの間の正しいセキュリティアソシエーションを識別するSPIに基づいて、HACからSA情報をクエリ/インデックス付けできる必要があります。
The HA may want the MN to re-establish the SA even if the existing SA is still valid. The HA can indicate this to the MN using a dedicated Status Code in a BA (value set to REINIT_SA_WITH_HAC). As a result, the MN SHOULD contact the HAC prior to the SA timing out, and the HAC would provision the MN and HAs with a new SA to be used subsequently.
HAは、既存のSAがまだ有効である場合でも、MNにSAの再確立を要求する場合があります。 HAは、BAの専用のステータスコード（値をREINIT_SA_WITH_HACに設定）を使用して、MNにこれを示すことができます。その結果、MNはSAがタイムアウトする前にHACに連絡する必要があり（SHOULD）、HACはMNとHAに、後で使用する新しいSAをプロビジョニングします。
The SA established between MN and HAC SHALL contain at least the following information:
MNとHACの間に確立されたSAには、少なくとも以下の情報が含まれている必要があります。
Mobility SPI:
モビリティSPI：
This parameter is an SPI used by the MN and the HA to index the SA between the MN and the HA. The HAC is responsible for assigning SPIs to MNs. There is only one SPI for both binding management messaging and possible user data protection. The same SPI is used for both directions between the MN and the HA. The SPI values are assigned by the HAC. The HAC MUST ensure uniqueness of the SPI values across all MNs controlled by the HAC.
このパラメータは、MNとHAがSAにインデックスを付けるために使用するSPIです。 HACはSPIをMNに割り当てる責任があります。バインディング管理メッセージングと可能なユーザーデータ保護の両方に対応するSPIは1つだけです。同じSPIがMNとHAの間の両方向に使用されます。 SPI値はHACによって割り当てられます。 HACは、HACによって制御されるすべてのMNにわたってSPI値の一意性を保証する必要があります。
MN-HA keys for ciphering:
暗号化用のMN-HAキー：
A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering Mobile IPv6 traffic between the MN and the HA. The HAC is responsible for generating these keys. The key generation algorithm is specific to the HAC implementation.
MNとHA間のモバイルIPv6トラフィックを暗号化するために使用される対称鍵のペア（MN-> HA、HA-> MN）。 HACはこれらの鍵の生成を担当します。鍵生成アルゴリズムは、HAC実装に固有です。
MN-HA shared key for integrity protection:
完全性保護のためのMN-HA共有キー：
A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity protecting Mobile IPv6 traffic between the MN and the HA. This includes both binding management messages and reverse-tunneled user data traffic between the MN and the HA. The HAC is responsible for generating these keys. The key generation algorithm is specific to the HAC implementation. In the case of combined algorithms, a separate integrity protection key is not needed and may be omitted, i.e., the encryption keys SHALL be used.
MNとHA間のモバイルIPv6トラフィックを完全に保護するために使用される対称鍵のペア（MN-> HA、HA-> MN）。これには、MNとHAの間のバインディング管理メッセージと逆トンネルされたユーザーデータトラフィックの両方が含まれます。 HACはこれらの鍵の生成を担当します。鍵生成アルゴリズムは、HAC実装に固有です。組み合わせたアルゴリズムの場合、個別の完全性保護キーは不要であり、省略できます。つまり、暗号化キーを使用する必要があります。
Security association validity time:
セキュリティアソシエーションの有効期間：
This parameter represents the validity time for the security association. The HAC is responsible for defining the lifetime value based on its policies. The lifetime may be in the order of hours or weeks. The MN MUST re-contact the HAC before the SA validity time ends.
このパラメーターは、セキュリティアソシエーションの有効期間を表します。 HACは、そのポリシーに基づいてライフタイム値を定義する責任があります。寿命は数時間または数週間のオーダーです。 MNは、SAの有効期間が終了する前にHACに再接続する必要があります。
Security association scope:
セキュリティアソシエーションスコープ：
This parameter defines whether the security association is applied to Mobile IPv6 signaling messages only or to both Mobile IPv6 signaling messages and data traffic.
このパラメータは、セキュリティアソシエーションをモバイルIPv6シグナリングメッセージのみに適用するか、モバイルIPv6シグナリングメッセージとデータトラフィックの両方に適用するかを定義します。
Selected ciphersuite:
選択された暗号スイート：
This parameter is the ciphersuite used to protect the traffic between the MN and the HA. This includes both binding management messages and reverse-tunneled user data traffic between the MN and the HA. The selected algorithms SHOULD be one of the mutually supported ciphersuites of the negotiated TLS version between the MN and the HAC. The HAC is responsible for choosing the mutually supported ciphersuite that complies with the policy of the HAC. Obviously, the HAs under HAC's management must have at least one ciphersuite with the HAC in common and need to be aware of the implemented ciphersuites. The selected ciphersuite is the same for both directions (MN -> HA and HA -> MN).
このパラメーターは、MNとHA間のトラフィックを保護するために使用される暗号スイートです。これには、MNとHAの間のバインディング管理メッセージと逆トンネルされたユーザーデータトラフィックの両方が含まれます。選択されたアルゴリズムは、MNとHACの間でネゴシエートされたTLSバージョンの相互にサポートされた暗号スイートの1つである必要があります（SHOULD）。 HACは、HACのポリシーに準拠する相互にサポートされる暗号スイートを選択する責任があります。明らかに、HACの管理下にあるHAには、HACと共通の暗号スイートが少なくとも1つ必要であり、実装された暗号スイートを認識する必要があります。選択された暗号スイートは、両方向で同じです（MN-> HAおよびHA-> MN）。
Sequence numbers:
シーケンス番号：
A monotonically increasing unsigned sequence number used in all protected packets exchanged between the MN and the HA in the same direction. Sequence numbers are maintained per direction, so each SA includes two independent sequence numbers (MN -> HA, HA -> MN). The initial sequence number for each direction MUST always be set to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing beyond their maximum defined value.
MNとHAの間で同じ方向に交換されるすべての保護されたパケットで使用される単調に増加する符号なしシーケンス番号。シーケンス番号は方向ごとに維持されるため、各SAには2つの独立したシーケンス番号が含まれます（MN-> HA、HA-> MN）。各方向の初期シーケンス番号は常に0（ゼロ）に設定する必要があります。シーケンス番号は、定義された最大値を超えると0（ゼロ）に循環します。
When the MN contacts the HAC to distribute the security-related information, the HAC may also provision the MN with various MIPv6- related bootstrapping information. Bootstrapping of the following information SHOULD at least be possible:
MNがHACに連絡してセキュリティ関連の情報を配布すると、HACはMNにさまざまなMIPv6関連のブートストラップ情報をプロビジョニングすることもできます。次の情報のブートストラップは、少なくとも可能である必要があります。
Home Agent IP Address:
ホームエージェントのIPアドレス：
The IPv6 and IPv4 address of the home agent assigned by the HAC.
HACによって割り当てられたホームエージェントのIPv6およびIPv4アドレス。
Mobile IPv6 Service Port Number:
モバイルIPv6サービスのポート番号：
The port number where the HA is listening to UDP [RFC0768] packets.
HAがUDP [RFC0768]パケットをリッスンしているポート番号。
Home Address:
自宅住所：
The IPv6 and/or IPv4 home address assigned to the mobile node by the HAC.
HACによってモバイルノードに割り当てられたIPv6またはIPv4のホームアドレス。
Home Link Prefix:
ホームリンクプレフィックス：
Concerns the IPv6 Home link prefix and the associated prefix length.
IPv6ホームリンクプレフィックスと関連するプレフィックス長が関係しています。
DNS Server Address:
DNSサーバーアドレス：
The address of a DNS server that can be reached via the HA. DNS queries in certain cases cannot be routed to the DNS servers assigned by the access network to which the MN is attached; hence, an additional DNS server address that is reachable via the HA needs to be configured.
HA経由で到達できるDNSサーバーのアドレス。特定の場合のDNSクエリは、MNが接続されているアクセスネットワークによって割り当てられたDNSサーバーにルーティングできません。したがって、HAを介して到達可能な追加のDNSサーバーアドレスを構成する必要があります。
The MIPv6-related bootstrapping information is delivered from the HAC to the MN over the same TLS protected tunnel as the security related information.
MIPv6関連のブートストラップ情報は、セキュリティ関連情報と同じTLS保護トンネルを介してHACからMNに配信されます。
The same integrity and confidentiality algorithms MUST be used to protect both binding management messages and reverse-tunneled user data traffic between the MN and the HA. Generally, all binding management messages (BUs, BAs, and so on) MUST be integrity protected and SHOULD be confidentially protected. The reverse-tunneled user data traffic SHOULD be equivalently protected. Generally, the requirements stated in [RFC6275] concerning the protection of the traffic between the MN and the HA also apply to the mechanisms defined by this specification.
MNとHAの間のバインディング管理メッセージと逆トンネルされたユーザーデータトラフィックの両方を保護するには、同じ整合性と機密性のアルゴリズムを使用する必要があります。一般に、すべてのバインディング管理メッセージ（BU、BAなど）は整合性を保護しなければならず（MUST）、機密情報として保護する必要があります。リバーストンネリングされたユーザーデータトラフィックは同等に保護されるべきです（SHOULD）。一般に、MNとHAの間のトラフィックの保護に関する[RFC6275]で述べられている要件は、この仕様で定義されているメカニズムにも適用されます。
The MN and the HAC communicate with each other using a simple lockstep request-response protocol that is run inside the protected TLS-tunnel. A generic message container framing for the request messages and for the response messages is defined. The message containers are only meant to be exchanged on top of a connection-oriented TLS-layer. Therefore, the end of message exchange is determined by the other end closing the transport connection (assuming the "application layer" has also indicated the completion of the message exchange). The peer initiating the TLS connection is always sending "Requests", and the peer accepting the TLS connection is always sending "Responses". The format of the message container is shown in Figure 3.
MNとHACは、保護されたTLSトンネル内で実行される単純なロックステップ要求/応答プロトコルを使用して相互に通信します。要求メッセージおよび応答メッセージ用の汎用メッセージコンテナーフレーミングが定義されています。メッセージコンテナーは、接続指向のTLSレイヤーの上で交換されることのみを目的としています。したがって、メッセージ交換の終了は、トランスポート接続を閉じるもう一方の端によって決定されます（「アプリケーション層」もメッセージ交換の完了を示していると想定）。 TLS接続を開始するピアは常に「要求」を送信し、TLS接続を受け入れるピアは常に「応答」を送信します。メッセージコンテナのフォーマットを図3に示します。
All data inside the Content portion of the message container MUST be encoded using octets. Fragmentation of message containers is not supported, which means one request or response at the "application layer" MUST NOT exceed the maximum size allowed by the message container format.
メッセージコンテナーのコンテンツ部分内のすべてのデータは、オクテットを使用してエンコードする必要があります。メッセージコンテナーの断片化はサポートされていません。つまり、「アプリケーションレイヤー」での1つの要求または応答は、メッセージコンテナー形式で許可されている最大サイズを超えてはいけません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rsrvd | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content portion.. ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Request-Response Message Container
図3：要求/応答メッセージコンテナー
The 3-bit Ver field identifies the protocol version. The current version is 0, i.e., all bits are set to a value of 0 (zero).
3ビットのVerフィールドは、プロトコルバージョンを識別します。現在のバージョンは0です。つまり、すべてのビットは0（ゼロ）の値に設定されます。
The Rsrvd field MUST be set to a value of 0 (zero),
Rsrvdフィールドは0（ゼロ）の値に設定する必要があります。
The Identifier field is meant to match requests and responses. The valid Identifier values are between 1-255. The value 0 MUST NOT be used. The first request for each communication session between the MN and the HAC MUST have the Identifier values set to 1.
Identifierフィールドは、要求と応答を照合するためのものです。有効な識別子の値は1〜255です。値0は使用してはなりません。 MNとHAC間の各通信セッションの最初のリクエストでは、識別子の値を1に設定する必要があります。
The Length field tells the length of the Content portion of the container (i.e., Reserved octet, Identifier octet, and Length field are excluded). The Content portion length MUST always be at least one octet and up to 65535 octets. The value is in network order.
長さフィールドは、コンテナのコンテンツ部分の長さを示します（つまり、予約済みオクテット、識別子オクテット、および長さフィールドは除外されます）。コンテンツ部分の長さは常に少なくとも1オクテットから最大65535オクテットでなければなりません。値はネットワーク順です。
The encoding of the message content is similar to HTTP header encoding and complies with the augmented Backus-Naur Form (BNF) defined in Section 2.1 of [RFC2616]. All presented hexadecimal numbers are in network byte order. From now on, we use the TypeValue header (TV-header) term to refer to request-response message content HTTP-like headers.
メッセージコンテンツのエンコードはHTTPヘッダーエンコードに似ており、[RFC2616]のセクション2.1で定義されている拡張バッカスナウアフォーム（BNF）に準拠しています。提示されたすべての16進数は、ネットワークバイト順です。今後は、TypeValueヘッダー（TVヘッダー）の用語を使用して、リクエスト/レスポンスメッセージのコンテンツのHTTPのようなヘッダーを参照します。
The message exchange between the MN and the HAC is a simple lockstep request-response type as stated in Section 5.1. A request message includes a monotonically increasing Identifier value that is copied to the corresponding response message. Each request MUST have a different Identifier value. Hence, a reliable connection-oriented transport below the message container framing is assumed. The number of request-response message exchanges MUST NOT exceed 255.
MNとHACの間のメッセージ交換は、セクション5.1で説明されているように、単純なロックステップ要求/応答タイプです。要求メッセージには、対応する応答メッセージにコピーされる単調に増加する識別子の値が含まれます。各リクエストには、異なるID値が必要です。したがって、メッセージコンテナーフレーミングの下の信頼性の高い接続指向のトランスポートが想定されます。要求と応答のメッセージ交換の数は255を超えてはなりません。
Each new communication session between the MN and the HAC MUST reset the Identifier value to 1. The MN is also the peer that always sends only request messages and the HAC only sends response messages. Once the request-response message exchange completes, the HAC and the MN MUST close the transport connection and the corresponding TLS-tunnel.
MNとHACの間の新しい各通信セッションは、識別子の値を1にリセットする必要があります。MNは、常に要求メッセージのみを送信し、HACは応答メッセージのみを送信するピアでもあります。要求と応答のメッセージ交換が完了すると、HACとMNはトランスポート接続と対応するTLSトンネルを閉じなければなりません（MUST）。
In the case of an HAC-side error, the HAC MUST send a response back to an MN with an appropriate status code and then close the transport connection.
HAC側のエラーの場合、HACは適切なステータスコードを含む応答をMNに送信してから、トランスポート接続を閉じる必要があります。
The first request message - MHAuth-Init - (i.e., the Identifier is 1) MUST always contain at least the following parameters:
最初の要求メッセージ-MHAuth-Init-（つまり、Identifierは1）には、常に少なくとも次のパラメーターを含める必要があります。
MN-Identity - See Section 5.5.1.
MN-Identity-セクション5.5.1を参照してください。
Authentication Method - See Section 5.5.2.
認証方法-セクション5.5.2を参照してください。
The first response message - MHAuth-Init - (i.e., the Identifier is 1) MUST contain at minimum the following parameters:
最初の応答メッセージ-MHAuth-Init-（つまり、Identifierは1）には、少なくとも以下のパラメーターを含める必要があります。
Selected authentication Method - See Section 5.5.2.
選択した認証方法-セクション5.5.2を参照してください。
The last request message from the MN side - MHAuth-Done - MUST contain the following parameters:
MN側からの最後のリクエストメッセージ-MHAuth-Done-には、次のパラメーターを含める必要があります。
Security association scope - See Section 5.6.4.
セキュリティアソシエーションスコープ-セクション5.6.4を参照してください。
Proposed ciphersuites - See Section 5.6.5.
提案された暗号スイート-セクション5.6.5を参照してください。
Message Authenticator - See Section 5.5.5.
メッセージ認証システム-セクション5.5.5を参照してください。
The last response message - MHAuth-Done - that ends the request-response message exchange MUST contain the following parameters:
要求/応答メッセージ交換を終了する最後の応答メッセージ-MHAuth-Done-には、次のパラメーターを含める必要があります。
Status Code - See Section 5.5.4.
ステータスコード-セクション5.5.4を参照してください。
Message Authenticator - See Section 5.5.5.
メッセージ認証システム-セクション5.5.5を参照してください。
In the case of successful authentication, the following additional parameters:
認証が成功した場合は、次の追加パラメーター：
Selected ciphersuite - See Section 5.6.5.
選択された暗号スイート-セクション5.6.5を参照してください。
Security association scope - See Section 5.6.4.
セキュリティアソシエーションスコープ-セクション5.6.4を参照してください。
The rest of the security association data - See Section 5.6.
残りのセキュリティアソシエーションデータ-セクション5.6を参照してください。
All bootstrapping information, whether for setting up the SA or for bootstrapping MIPv6-specific information, is exchanged between the MN and the HAC using the framing protocol defined in Section 5.1. The IP address of the HAC MAY be statically configured in the MN or alternatively MAY be dynamically discovered using DNS. In the case of DNS-based HAC discovery, the MN queries either an A/AAAA or a SRV record for the HAC IP address. The actual domain name used in queries is up to the deployment to decide and out of scope of this specification.
SAのセットアップまたはMIPv6固有の情報のブートストラップのいずれの場合でも、すべてのブートストラップ情報は、セクション5.1で定義されたフレーミングプロトコルを使用して、MNとHACの間で交換されます。 HACのIPアドレスは、MNで静的に構成することも、DNSを使用して動的に検出することもできます（MAY）。 DNSベースのHACディスカバリーの場合、MNはHAC IPアドレスについてA / AAAAまたはSRVレコードを照会します。クエリで使用される実際のドメイン名は、この仕様の範囲外であり、決定する展開次第です。
The grammar used in the following sections is the augmented Backus-Naur Form (BNF), the same as that used by HTTP [RFC2616].
以下のセクションで使用される文法は、HTTP [RFC2616]で使用されるものと同じ、拡張バッカスナウアフォーム（BNF）です。
An identifier that identifies an MN. The Mobile Node Identifier is in the form of a Network Access Identifier (NAI) [RFC4282].
MNを識別する識別子。モバイルノード識別子は、ネットワークアクセス識別子（NAI）[RFC4282]の形式です。
mn-id = "mn-id" ":" RFC4282-NAI CRLF
以降=「以降」：RFC4282-NAI CRLF
The HAC is the peer that mandates the authentication method. The MN sends its authentication method proposal to the HAC. The HAC, upon receipt of the MN proposal, returns the selected authentication method. The MN MUST propose at least one authentication method. The HAC MUST select exactly one authentication method or return an error and then close the connection.
HACは、認証方法を要求するピアです。 MNはその認証方法提案をHACに送信します。 HACは、MNプロポーザルを受信すると、選択した認証方法を返します。 MNは、少なくとも1つの認証方法を提案する必要があります。 HACは1つの認証方法を選択するか、エラーを返して接続を閉じる必要があります。
auth-method = "auth-method" ":" a-method *("," a-method) CRLF
a-method =
"psk" ; PSK-based authentication
| "eap" ; EAP-based authentication
Each Extensible Authentication Protocol (EAP) [RFC3748] message is an encoded string of hexadecimal numbers. The "eap-payload" is completely transparent as to which EAP-method or EAP message is carried inside it. The "eap-payload" can appear in both request and response messages:
各拡張認証プロトコル（EAP）[RFC3748]メッセージは、16進数のエンコードされた文字列です。 「eap-payload」は、どのEAPメソッドまたはEAPメッセージがその内部で伝送されるかについて完全に透過的です。 「eap-payload」は、要求メッセージと応答メッセージの両方に表示されます。
eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF
The "status-code" MUST only be present in the response message that ends the request-response message exchange. The "status-code" follows the principles of HTTP and the definitions found in Section 10 of RFC 2616 also apply for these status codes listed below:
「ステータスコード」は、要求/応答メッセージ交換を終了する応答メッセージにのみ存在する必要があります。 「ステータスコード」はHTTPの原則に従い、RFC 2616のセクション10にある定義は、以下にリストされているこれらのステータスコードにも適用されます。
status-code = "status-code" ":" status-value CRLF
status-value =
"100" ; Continue
| "200" ; OK
| "400" ; Bad Request
| "401" ; Unauthorized
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
The "auth" header contains data used for authentication purposes. It MUST be the last TV-header in the message and calculated over the whole message till the start of the "msg-header":
「auth」ヘッダーには、認証目的で使用されるデータが含まれています。これはメッセージの最後のTVヘッダーである必要があり、「msg-header」の開始までメッセージ全体で計算されます。
msg-auth = "auth" ":" 1*(HEX HEX) CRLF
retry-after = "retry-after" ":" rfc1123-date CRLF
再試行後= "再試行後" "：" rfc1123-日付CRLF
end-of-message = 2CRLF
Random numbers generated by the MN and the HAC, respectively. The length of the random number MUST be 32 octets (before TV-header encoding):
MNおよびHACによってそれぞれ生成された乱数。乱数の長さは32オクテットでなければなりません（TVヘッダーのエンコード前）。
mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF
hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF
During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a single ciphersuite for protecting the traffic between the MN and the HA. The allowed ciphersuites for this specification are a subset of those in TLS version 1.2 (see Appendix A.5 of [RFC5246]) per Section 5.6.5. This might appear as a constraint as the HA and the HAC may have implemented different ciphersuites. These two nodes are, however, assumed to belong to the same administrative domain. In order to avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol and to reuse the TLS ciphersuite negotiation procedure, we make this simplifying assumption. The selected ciphersuite MUST provide integrity and confidentiality protection.
モバイルIPv6ブートストラップ中に、MNとHACは、MNとHA間のトラフィックを保護するために単一の暗号スイートをネゴシエートします。この仕様で許可されている暗号スイートは、セクション5.6.5に従って、TLSバージョン1.2のサブセット（[RFC5246]の付録A.5を参照）です。 HAとHACが異なる暗号スイートを実装している可能性があるため、これは制約として表示される場合があります。ただし、これら2つのノードは同じ管理ドメインに属していると想定されています。 MN-HACプロトコルでサポートされているMN-HA暗号スイートの交換を回避し、TLS暗号スイートネゴシエーション手順を再利用するために、この単純化を前提としています。選択された暗号スイートは、整合性と機密保護を提供する必要があります。
Section 5.6.5 provides the mapping from the TLS ciphersuites to the integrity and encryption algorithms allowed for MN-HA protection. This mapping mainly ignores the authentication algorithm part that is not required within the context of this specification. For example, [RFC5246] defines a number of AES-based ciphersuites for TLS including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification, the relevant part is 'AES_128_CBC_SHA'.
セクション5.6.5は、TLS暗号スイートから、MN-HA保護で許可されている整合性および暗号化アルゴリズムへのマッピングを示しています。このマッピングは主に、この仕様のコンテキスト内で必要とされない認証アルゴリズムの部分を無視します。たとえば、[RFC5246]は、「TLS_RSA_WITH_AES_128_CBC_SHA」を含む、TLSのAESベースの暗号スイートの数を定義しています。この仕様では、関連する部分は「AES_128_CBC_SHA」です。
All the parameters described in the following sections apply only to a request-response protocol response message to the MN. The MN has no way of affecting the provisioning decision of the HAC.
次のセクションで説明するすべてのパラメータは、MNへの要求/応答プロトコル応答メッセージにのみ適用されます。 MNはHACのプロビジョニングの決定に影響を与える方法はありません。
The 28-bit unsigned SPI number identifies the SA used between the MN and the HA. The value 0 (zero) is reserved and MUST NOT be used. Therefore, values ranging from 1 to 268435455 are valid.
28ビットの符号なしSPI番号は、MNとHAの間で使用されるSAを識別します。値0（ゼロ）は予約されており、使用してはなりません（MUST NOT）。したがって、1〜268435455の範囲の値が有効です。
The TV-header corresponding to the SPI number is as follows:
SPI番号に対応するTVヘッダーは次のとおりです。
mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF
The MN-HA shared integrity (ikey) and encryption (ekey) keys are used to protect the traffic between the MN and the HA. The length of these keys depend on the selected ciphersuite.
MN-HA共有整合性（ikey）および暗号化（ekey）キーは、MNとHA間のトラフィックを保護するために使用されます。これらのキーの長さは、選択した暗号スイートによって異なります。
The TV-headers that carry these two parameters are the following:
これらの2つのパラメーターを持つTVヘッダーは次のとおりです。
mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF
mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF
The end of the SA validity time is encoded using the "rfc1123-date" format, as defined in Section 3.3.1 of [RFC2616].
[RFC2616]のセクション3.3.1で定義されている「rfc1123-date」形式を使用して、SAの有効期限の終わりがエンコードされます。
The TV-header corresponding to the SA validity time value is as follows:
SAの有効期間の値に対応するTVヘッダーは次のとおりです。
mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF
mip6-sa-validity-end = "mip6-sa-validity-end" "：" rfc1123-date CRLF
The SA is applied either to Mobile IPv6 signaling messages only or to both Mobile IPv6 signaling messages and data traffic. This policy MUST be agreed between the MN and HA prior to using the SA. Otherwise, the receiving side will be unaware of whether the SA applies to data traffic and hence unable to decide how to act when receiving unprotected packets of PType 1 (see Section 6.4).
SAは、モバイルIPv6シグナリングメッセージのみ、またはモバイルIPv6シグナリングメッセージとデータトラフィックの両方に適用されます。このポリシーは、SAを使用する前に、MNとHAの間で合意する必要があります。そうしないと、受信側はSAがデータトラフィックに適用されるかどうかを認識しないため、PType 1の保護されていないパケットを受信する際の対処方法を決定できません（セクション6.4を参照）。
mip6-sas = "mip6-sas" ":" 1DIGIT CRLF
μηπ6-sas= "μηπ6-sas" "：" 1DIGIT CRLF
where a value of "O" indicates that the SA does not protect data traffic and a value of "1" indicates that all data traffic MUST be protected by the SA. If the mip6-sas value of an SA is set to 1, any packet received with a PType value that does not match the mip6-sas value of the SA MUST be silently discarded.
「O」の値はSAがデータトラフィックを保護しないことを示し、「1」の値はすべてのデータトラフィックがSAによって保護されなければならないことを示します。 SAのmip6-sas値が1に設定されている場合、SAのmip6-sas値と一致しないPType値で受信されたパケットは、通知なく破棄されなければなりません（MUST）。
The HAC is the peer that mandates the used security association scope. The MN sends its proposal to the HAC, but eventually the security association scope returned from the HAC defines the used scope.
HACは、使用されるセキュリティアソシエーションスコープを要求するピアです。 MNは提案をHACに送信しますが、最終的にはHACから返されたセキュリティアソシエーションスコープが使用されるスコープを定義します。
The ciphersuite negotiation between HAC and MN uses a subset of the TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation defined in Appendix A.5 of [RFC5246]. The TV-headers corresponding to the selected ciphersuite and ciphersuite list are the following:
HACとMN間の暗号スイートネゴシエーションは、TLS 1.2暗号スイートのサブセットを使用し、[RFC5246]の付録A.5で定義されているTLS 1.2数値表現に従います。選択した暗号スイートと暗号スイートリストに対応するTVヘッダーは次のとおりです。
mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
csuite = "{" suite "}"
suite =
"00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02}
| "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B}
| "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A}
| "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F}
| "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}
mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
All other Ciphersuite values are reserved.
他のすべてのCiphersuite値は予約されています。
The following integrity algorithms MUST be supported by all implementations:
次の整合性アルゴリズムは、すべての実装でサポートされている必要があります。
HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566]
HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566]
The binding management messages between the MN and HA MUST be integrity protected. Implementations MUST NOT use a NULL integrity algorithm.
MNとHAの間のバインディング管理メッセージは、完全性を保護する必要があります。実装では、NULL整合性アルゴリズムを使用してはなりません（MUST NOT）。
The following encryption algorithms MUST be supported:
次の暗号化アルゴリズムをサポートする必要があります。
NULL [RFC2410]
TripleDES-CBC [RFC2451]
AES-CBC with 128-bit keys [RFC3602]
Traffic between MN and HA MAY be encrypted. Any integrity-only Ciphersuite makes use of the NULL encryption algorithm.
MNとHA間のトラフィックは暗号化される場合があります。整合性のみのCiphersuiteは、NULL暗号化アルゴリズムを使用します。
Note: This document does not consider combined algorithms. The following table provides the mapping of each ciphersuite to a combination of integrity and encryption algorithms that are part of the negotiated SA between MN and HA.
注：このドキュメントでは、組み合わせたアルゴリズムについては考慮していません。次の表は、MNとHAの間でネゴシエートされたSAの一部である整合性アルゴリズムと暗号化アルゴリズムの組み合わせへの各暗号スイートのマッピングを示しています。
+-------------------+-----------------+--------------------------+
|Ciphersuite |Integ. Algorithm |Encr. Algorithm |
+-------------------+-----------------+--------------------------+
|NULL_SHA |HMAC-SHA1-96 |NULL |
|NULL_SHA256 |AES-XCBC-MAC-96 |NULL |
|3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC |
|AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys |
|AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys |
+-------------------+----------------+---------------------------+
Ciphersuite-to-Algorithm Mapping
暗号スイートからアルゴリズムへのマッピング
In parallel with the SA bootstrapping, the HAC SHOULD provision the MN with relevant MIPv6-related bootstrapping information.
SAブートストラップと並行して、HACは関連するMIPv6関連のブートストラップ情報をMNにプロビジョニングする必要があります（SHOULD）。
The following generic BNFs are used to form IP addresses and prefixes. They are used in subsequent sections.
次の一般的なBNFは、IPアドレスとプレフィックスを形成するために使用されます。これらは後続のセクションで使用されます。
ip6-addr = 7( word ":" ) word CRLF
word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ip4-subnet = ip4-addr "/" 1*2DIGIT
The HAC MAY provision the MN with an IPv4 or an IPv6 address of an HA, or both.
HACは、MNにHAのIPv4またはIPv6アドレス、あるいはその両方をプロビジョニングできます（MAY）。
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF
The HAC SHOULD provision the MN with an UDP port number, where the HA expects to receive UDP packets. If this parameter is not present, then the IANA reserved port number (mipv6tls) MUST be used instead.
HACは、HAがUDPパケットを受信することを期待しているUDPポート番号をMNにプロビジョニングする必要があります。このパラメーターが存在しない場合は、代わりにIANA予約ポート番号（mipv6tls）を使用する必要があります。
mip6-port = "mip6-port" ":" 1*5DIGIT CRLF
The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or both. The HAC MAY also provision the MN with its home network prefix.
HACは、IPv4またはIPv6のホームアドレス、あるいはその両方をMNにプロビジョニングできます（MAY）。 HACは、MNにそのホームネットワークプレフィックスをプロビジョニングすることもできます（MAY）。
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF
mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF
mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF
The HAC may also provide the MN with DNS server configuration options. These DNS servers are reachable via the home agent.
HACは、MNにDNSサーバー構成オプションを提供することもできます。これらのDNSサーバーは、ホームエージェントを介して到達可能です。
dns-ip6 = "dns-ip6" ":" ip6-addr CRLF
dns-ip4 = "dns-ip4" ":" ip4-addr CRLF
This section describes the basic operation required for the MN-HAC mutual authentication and the channel binding. The authentication protocol described as part of this section is a simple exchange that follows the Generalized Pre-Shared Key (GPSK) exchange used by EAP-GPSK [RFC5433]. It is secured by the TLS tunnel and is cryptographically bound to the TLS tunnel through channel binding based on [RFC5056] and on the channel binding type 'tls-server-endpoint' described in [RFC5929]. As a result of the channel binding type, this method can only be used with TLS ciphersuites that use server certificates and the Certificate handshake message. For example, TLS ciphersuites based on PSK or anonymous authentication cannot be used.
このセクションでは、MN-HAC相互認証とチャネルバインディングに必要な基本操作について説明します。このセクションの一部として説明されている認証プロトコルは、EAP-GPSK [RFC5433]によって使用されるGeneralized Pre-Shared Key（GPSK）交換に続く単純な交換です。これはTLSトンネルによって保護され、[RFC5056]と[RFC5929]で説明されているチャネルバインディングタイプ「tls-server-endpoint」に基づくチャネルバインディングを介して、TLSトンネルに暗号でバインドされます。チャネルバインディングタイプの結果として、このメソッドはサーバー証明書と証明書ハンドシェイクメッセージを使用するTLS暗号スイートでのみ使用できます。たとえば、PSKまたは匿名認証に基づくTLS暗号スイートは使用できません。
The authentication exchange MUST be performed through the encrypted TLS tunnel. It performs mutual authentication between the MN and the HAC based on a PSK or based on an EAP-method (see Section 5.9). Note that an HAC MUST NOT allow MNs to renegotiate TLS sessions. The PSK protocol is described in this section. It consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-Done) in which both sides exchange nonces and their identities, and compute and exchange a message authenticator 'auth' over the previously exchanged values, keyed with the pre-shared key. The MHAuth-Done messages are used to deal with error situations. Key binding with the TLS tunnel is ensured by channel binding of the type "tls-server-endpoint" as described by [RFC5929] where the hash of the TLS server certificate serves as input to the 'auth' calculation of the MHAuth messages.
認証交換は、暗号化されたTLSトンネルを介して実行する必要があります。 PSKまたはEAP方式に基づいて、MNとHAC間の相互認証を実行します（セクション5.9を参照）。 HACは、MNがTLSセッションの再ネゴシエーションを許可してはならないことに注意してください。このセクションでは、PSKプロトコルについて説明します。これは、メッセージ交換（MHAuth-Init、MHAuth-Mid、MHAuth-Done）で構成され、両側でナンスとそのIDを交換し、事前に交換された以前に交換された値に対してメッセージ認証子「auth」を計算して交換します。共有キー。 MHAuth-Doneメッセージは、エラー状況を処理するために使用されます。 TLSトンネルを使用したキーバインディングは、[RFC5929]で説明されている「tls-server-endpoint」タイプのチャネルバインディングによって保証されます。TLSサーバー証明書のハッシュは、MHAuthメッセージの「auth」計算への入力として機能します。
Note: The authentication exchange is based on the GPSK exchange used by EAP-GPSK. In comparison to GPSK, it does not support exchanging an encrypted container (it always runs through an already protected TLS tunnel). Furthermore, the initial request of the authentication exchange (MHAuth-Init) is sent by the MN (client side) and is comparable to EAP-Response/Identity, which reverses the roles of request and response messages compared to EAP-GPSK. Figure 4 shows a successful protocol exchange.
注：認証交換は、EAP-GPSKで使用されるGPSK交換に基づいています。 GPSKと比較して、暗号化されたコンテナーの交換はサポートされていません（常に保護されたTLSトンネルを介して実行されます）。さらに、認証交換（MHAuth-Init）の最初の要求はMN（クライアント側）によって送信され、EAP-GPSKと比較して要求メッセージと応答メッセージの役割を逆にするEAP-Response / Identityに相当します。図4は、成功したプロトコル交換を示しています。
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (...) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Done (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (...) |
|<------------------------------------------------------|
| |
Figure 4: Authentication of the Mobile Node Using Shared Secrets
図4：共有シークレットを使用したモバイルノードの認証
1) Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=psk
mn-id、mn-rand、auth-method = psk
2) Response/MHAuth-Init: (MN <- HAC)
[mn-rand, hac-rand, auth-method=psk, [status],] auth
[mn-rand、hac-rand、auth-method = psk、[ステータス]、] auth
3) Request/MHAuth-Done: (MN -> HAC)
mn-rand, hac-rand, sa-scope, ciphersuite-list, auth
mn-rand、hac-rand、sa-scope、ciphersuite-list、auth
4) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, hac-rand, status, auth
[sa-scope、sa-data、ciphersuite、bootstrapping-data、] mn-rand、hac-rand、status、auth
Where 'auth' for MN -> HAC direction is as follows:
MNの「auth」-> HAC方向は次のとおりです。
auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets)
auth = HMAC-SHA256（PSK、 "MN" | msg-octets | CB-octets）
Where 'auth' for MN <- HAC direction is as follows:
MNの「auth」<-HAC方向は次のとおりです。
auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets)
auth = HMAC-SHA256（PSK、 "HAC" | msg-octets | CB-octets）
In the above, "MN" is 2 ASCII characters without null termination and "HAC" is 3 ASCII characters without null termination.
上記では、「MN」はヌル終了のない2つのASCII文字であり、「HAC」はヌル終了のない3つのASCII文字です。
The length "mn-rand", "hac-rand" is 32 octets. Note that "|" indicates concatenation and optional parameters are shown in square brackets [..]. The square brackets can be nested.
長さ「mn-rand」、「hac-rand」は32オクテットです。 「|」に注意してください連結を示し、オプションのパラメータは角括弧[..]で示されます。大括弧はネストすることができます。
The shared secret PSK can be variable length. 'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the auth calculation that is the "TLS-server-endpoint" channel binding type. The content and algorithm (only required for the "TLS-server-endpoint" type) are the same as described in [RFC5929].
共有秘密PSKは可変長にすることができます。 「msg-octets」には、「auth」ペイロードを除く、署名されるそれぞれのメッセージのすべてのペイロードパラメータが含まれます。 CB-octetsは、「TLS-server-endpoint」チャネルバインディングタイプである認証計算へのチャネルバインディング入力です。内容とアルゴリズム（「TLS-server-endpoint」タイプにのみ必要）は、[RFC5929]で説明されているものと同じです。
The MN starts by selecting a random number 'mn-rand' and choosing a list of supported authentication methods coded in 'auth-method'. The MN sends its identity 'mn-id', 'mn-rand', and 'auth-method' to the HAC in MHAuth-Init. The decision of which authentication method to offer and which to pick is policy and implementation dependent and, therefore, outside the scope of this document.
MNは、最初に乱数「mn-rand」を選択し、「auth-method」でコーディングされたサポートされている認証方法のリストを選択します。 MNは、そのID「mn-id」、「mn-rand」、および「auth-method」をMHAuth-InitでHACに送信します。提供する認証方法と選択する認証方法の決定は、ポリシーと実装に依存するため、このドキュメントの範囲外です。
In MHAuth-Done, the HAC sends a random number 'hac-rand' and the selected ciphersuite. The selection MUST be one of the MN-supported ciphersuites as received in 'ciphersuite-list'. Furthermore, it repeats the received parameters of the MHAuth-Init message 'mn-rand'. It computes a message authenticator 'auth' over all the transmitted parameters except 'auth' itself. The HAC calculates 'auth' over all parameters and appends it to the message.
MHAuth-Doneでは、HACは乱数「hac-rand」と選択された暗号スイートを送信します。選択は、「ciphersuite-list」で受け取ったMNがサポートする暗号スイートの1つでなければなりません。さらに、MHAuth-Initメッセージ「mn-rand」の受信パラメータを繰り返します。これは、「auth」自体を除くすべての送信されたパラメーターに対してメッセージ認証子「auth」を計算します。 HACはすべてのパラメーターに対して「auth」を計算し、それをメッセージに追加します。
The MN verifies the received Message Authentication Code (MAC) and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Auth. In case of successful verification, the MN computes a MAC over the session parameter and returns it to the HAC in MHAuth-Done. The HAC verifies the received MAC and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Init. If the verification is successful, MHAuth-Done is prepared and sent by the HAC to confirm successful completion of the exchange.
MNは、受信したメッセージ認証コード（MAC）と、MHAuth-Authで送信されたID、ノンス、暗号スイートパラメータの整合性を検証します。検証が成功した場合、MNはセッションパラメータを介してMACを計算し、それをMHAuth-DoneでHACに返します。 HACは、受信したMACと、MHAuth-Initで送信されたID、ノンス、暗号スイートパラメーターの整合性を検証します。検証が成功した場合、MHAuth-Doneが準備され、交換が正常に完了したことを確認するためにHACによって送信されます。
Basic operation required for the MN-HAC mutual authentication using EAP-based methods.
EAPベースのメソッドを使用したMN-HAC相互認証に必要な基本操作。
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (..., |
| eap-payload=EAP-Request/Identity) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Mid (eap-payload= |
| EAP-Response/Identity) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Mid (eap-payload=EAP-Request/...) |
|<------------------------------------------------------|
| |
: :
: ..EAP-method specific exchanges.. :
: :
| |
| Request/MHAuth-Done (eap-payload=EAP-Response/..., |
| ..., auth) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (eap-payload=EAP-Success, |
| ..., auth) |
|<------------------------------------------------------|
| |
Figure 5: Authentication of the Mobile Node Using EAP
図5：EAPを使用したモバイルノードの認証
1) Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=eap
mn-id、mn-rand、auth-method = eap
2) Response/MHAuth-Init: (MN <- HAC)
[auth-method=eap, eap, [status,]] auth
[auth-method = eap、eap、[status、]] auth
3) Request/MHAuth-Mid: (MN -> HAC)
eap, auth
eap、auth
4) Response/MHAuth-Mid: (MN <- HAC)
eap, auth
eap、auth
MHAuth-Mid exchange is repeated as many times as needed by the used EAP-method.
MHAuth-Mid交換は、使用されているEAPメソッドで必要な回数だけ繰り返されます。
5) Request/MHAuth-Done: (MN -> HAC)
sa-scope, ciphersuite-list, eap, auth
sa-scope、ciphersuite-list、eap、auth
6) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, status, auth
[sa-scope、sa-data、ciphersuite、bootstrapping-data、] eap、status、auth
Where 'auth' for MN -> HAC direction is as follows:
MNの「auth」-> HAC方向は次のとおりです。
auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets)
auth = HMAC-SHA256（shared-key、 "MN" | msg-octets | CB-octets）
Where 'auth' for MN <- HAC direction is as follows:
MNの「auth」<-HAC方向は次のとおりです。
auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets)
auth = HMAC-SHA256（shared-key、 "HAC" | msg-octets | CB-octets）
In the above, "MN" is 2 ASCII characters without null termination and "HAC" is 3 ASCII characters without null termination.
上記では、「MN」はヌル終了のない2つのASCII文字であり、「HAC」はヌル終了のない3つのASCII文字です。
In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If the EAP-method is key-deriving and creates a shared Master Session Key (MSK) as a side effect of Authentication shared-key MUST be the MSK in all MHAuth-Done messages. This MSK MUST NOT be used for any other purpose. In case the EAP method does not generate an MSK, shared-key is set to "1".
MHAuth-InitおよびMHAuth-Midメッセージでは、共有キーが「1」に設定されます。 EAP方式がキー派生であり、認証の副作用として共有マスターセッションキー（MSK）を作成する場合、共有キーはすべてのMHAuth-DoneメッセージのMSKである必要があります。このMSKを他の目的に使用してはなりません。 EAP方式でMSKが生成されない場合、共有キーは「1」に設定されます。
'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the AUTH calculation that is the "TLS-server-endpoint" channel binding type. The content and algorithm (only required for the "TLS-server-endpoint" type) are the same as described in [RFC5929].
「msg-octets」には、「auth」ペイロードを除く、署名されるそれぞれのメッセージのすべてのペイロードパラメータが含まれます。 CB-octetsは、「TLS-server-endpoint」チャネルバインディングタイプであるAUTH計算へのチャネルバインディング入力です。内容とアルゴリズム（「TLS-server-endpoint」タイプにのみ必要）は、[RFC5929]で説明されているものと同じです。
The following subsections describe the packet formats used for the traffic between the MN and the HA. This traffic includes binding management messages (for example, BU and BA messages), reverse- tunneled and encrypted user data, and reverse-tunneled plaintext user data. This specification defines a generic packet format, where everything is encapsulated inside UDP. See Sections 6.3 and 6.4 for detailed illustrations of the corresponding packet formats.
次のサブセクションでは、MNとHA間のトラフィックに使用されるパケット形式について説明します。このトラフィックには、バインディング管理メッセージ（たとえば、BUおよびBAメッセージ）、逆トンネルおよび暗号化されたユーザーデータ、および逆トンネルされたプレーンテキストのユーザーデータが含まれます。この仕様は、すべてがUDP内にカプセル化される一般的なパケット形式を定義します。対応するパケット形式の詳細な図については、セクション6.3および6.4を参照してください。
The Mobile IPv6 service port number is where the HA expects to receive UDP packets. The same port number is used for both binding management messages and user data packets. The reason for multiplexing data and control messages over the same port number is due to the possibility of Network Address and Port Translators located along the path between the MN and the HA. The Mobile IPv6 service MAY use any ephemeral port number as the UDP source port, and it MUST use the Mobile IPv6 service port number as the UDP destination port. The Mobile IPv6 service port is dynamically assigned to the MN during the bootstrapping phase (i.e., the mip6- port parameter) or, in absence of the bootstrapping parameter, the IANA reserved port (mipv6tls) MUST be used.
モバイルIPv6サービスポート番号は、HAがUDPパケットを受信することを予期している場所です。バインディング管理メッセージとユーザーデータパケットの両方に同じポート番号が使用されます。同じポート番号でデータと制御メッセージを多重化する理由は、MNとHA間のパスに沿ってネットワークアドレスとポートトランスレーターが配置されている可能性があるためです。モバイルIPv6サービスは、任意のエフェメラルポート番号をUDP送信元ポートとして使用することができます。また、モバイルIPv6サービスポート番号をUDP宛先ポートとして使用する必要があります。モバイルIPv6サービスポートは、ブートストラップフェーズ中にMNに動的に割り当てられます（つまり、mip6- portパラメーター）。または、ブートストラップパラメーターがない場合は、IANA予約ポート（mipv6tls）を使用する必要があります。
The encapsulating UDP header is immediately followed by a 4-bit Packet Type (PType) field that defines whether the packet contains an encrypted mobility management message, an encrypted user data packet, or a plaintext user data packet.
カプセル化するUDPヘッダーの直後には、暗号化されたモビリティ管理メッセージ、暗号化されたユーザーデータパケット、またはプレーンテキストのユーザーデータパケットをパケットに含めるかどうかを定義する4ビットのパケットタイプ（PType）フィールドが続きます。
The Packet Type field is followed by a 28-bit SPI value, which identifies the correct SA concerning the encrypted packet. For any packet that is neither integrity protected nor encrypted (i.e., no SA is applied by the originator), the SPI MUST be set to 0 (zero). Mobility management messages MUST always be at least integrity protected. Hence, mobility management messages MUST NOT be sent with an SPI value of 0 (zero).
パケットタイプフィールドの後には、暗号化されたパケットに関する正しいSAを識別する28ビットのSPI値が続きます。完全性保護も暗号化もされていない（つまり、発信元によってSAが適用されていない）パケットの場合、SPIは0（ゼロ）に設定する必要があります。モビリティ管理メッセージは、常に少なくとも完全性を保護する必要があります。したがって、モビリティ管理メッセージは、0（ゼロ）のSPI値で送信してはならない（MUST NOT）。
There is always only one SPI per MN-HA mobility session and the same SPI is used for all types of protected packets independent of the direction.
MN-HAモビリティセッションごとに常に1つのSPIがあり、方向に関係なく、すべてのタイプの保護パケットに同じSPIが使用されます。
The SPI value is followed by a 32-bit Sequence Number value that is used to identify retransmissions of protected messages (integrity protected or both integrity protected and encrypted, see Figures 7 and 8) . Each endpoint in the security association maintains two "current" Sequence Numbers: the next one to be used for a packet it initiates and the next one it expects to see in a packet from the other end. If the MN and the HA ends initiate very different numbers of messages, the Sequence Numbers in the two directions can be very different. In the case data protection is not used (see Figure 9), the Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD initiate a re-establishment of the SA before any of the Sequence Number cycle.
SPI値の後には、32ビットのシーケンス番号値が続きます。この値は、保護されたメッセージの再送信を識別するために使用されます（完全性保護、または完全性保護と暗号化の両方。図7および8を参照）。セキュリティアソシエーションの各エンドポイントは、2つの「現在の」シーケンス番号を維持します。次のシーケンス番号は、開始するパケットに使用されるものと、もう一方の端からのパケットで予期される次のものです。 MNとHAの終端が非常に異なる数のメッセージを開始する場合、2つの方向のシーケンス番号は非常に異なる場合があります。データ保護を使用しない場合（図9を参照）、シーケンス番号は0（ゼロ）に設定する必要があります。 HAは、シーケンス番号サイクルの前にSAの再確立を開始する必要があることに注意してください。
Finally, the Sequence Number field is followed by the data portion, whose content is identified by the Packet Type. The data portion may be protected.
最後に、シーケンス番号フィールドの後にデータ部分が続きます。その内容はパケットタイプによって識別されます。データ部分が保護されている可能性があります。
The PType is a 4-bit field that indicates the Packet Type (PType) of the UDP encapsulated packet. The PType is followed by a 28-bit SPI value. The PType and the SPI fields are treated as one 32-bit field during the integrity protection calculation.
PTypeは、UDPカプセル化パケットのパケットタイプ（PType）を示す4ビットのフィールドです。 PTypeの後には28ビットのSPI値が続きます。 PTypeおよびSPIフィールドは、整合性保護の計算中に1つの32ビットフィールドとして扱われます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Parameter Index with Packet Type
図6：パケットタイプを含むセキュリティパラメータインデックス
A SPI value of 0 (zero) indicates a plaintext packet. If the packet is integrity protected or both integrity protected and encrypted, the SPI value MUST be different from 0. When the SPI value is set to 0, then the PType MUST also be 0.
SPI値0（ゼロ）は、平文パケットを示します。パケットが完全性保護されているか、完全性保護と暗号化の両方である場合、SPI値は0とは異なる必要があります。SPI値が0に設定されている場合、PTypeも0でなければなりません。
The binding management messages that are only meant to be exchanged between the MN and the HA MUST be integrity protected and MAY be encrypted. They MUST use the packet format shown in Figure 7.
MNとHAの間で交換されることのみを目的としたバインディング管理メッセージは、完全性が保護され、暗号化されている必要があります。図7に示すパケット形式を使用する必要があります。
All packets that are specific to the Mobile IPv6 protocol, contain a Mobility Header (as defined in Section 6.1.1. of RFC 6275) and are used between the MN and the HA shall use the packet format shown in Figure 7. (This means that some Mobile IPv6 mobility management messages, such as the Home Test Init (HoTI) message, are treated as data packets and using encapsulation described in Section 6.4 and shown in Figures 8 and 9).
モバイルIPv6プロトコルに固有のすべてのパケットは、（RFC 6275のセクション6.1.1で定義されている）モビリティヘッダーを含み、MNとHAの間で使用されます。図7に示すパケット形式を使用する必要があります（つまり、 Home Test Init（HoTI）メッセージなどの一部のモバイルIPv6モビリティ管理メッセージは、データパケットとして扱われ、セクション6.4で説明され、図8および9に示されているカプセル化を使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PType=8| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UDP-Encapsulated Binding Management Message Format
図7：UDPカプセル化バインディング管理メッセージ形式
The PType value 8 (eight) identifies that the UDP-encapsulated packet contains a Mobility Header (defined by RFC 6275) and other relevant IPv6 extension headers. Note, there is no additional IP header inside the encapsulated part. The Next Header field MUST be set to value of the first encapsulated header. The encapsulated headers follow the natural IPv6 and Mobile IPv6 extension header alignment and formatting rules.
PType値8（8）は、UDPカプセル化パケットにモビリティヘッダー（RFC 6275で定義）およびその他の関連するIPv6拡張ヘッダーが含まれていることを示します。カプセル化された部分の内部に追加のIPヘッダーがないことに注意してください。次のヘッダーフィールドは、最初のカプセル化されたヘッダーの値に設定する必要があります。カプセル化されたヘッダーは、IPv6およびモバイルIPv6の自然な拡張ヘッダーの配置とフォーマットのルールに従います。
The Padding, Pad Length, Next Header, and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document. For an SPI value of 0 (zero) that indicates an unprotected packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT be present.
このドキュメントで特に明記されていない限り、パディング、パッド長、次のヘッダー、およびICVフィールドは、[RFC4303]のセクション2.4〜2.8の規則に従います。保護されていないパケットを示す0（ゼロ）のSPI値の場合、パディング、パッド長、次のヘッダー、およびICVフィールドが存在してはなりません（MUST NOT）。
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 7) use the current CoA of the MN and the HA address.
外部IPヘッダーの送信元IPアドレスと宛先IPアドレス（つまり、図7のsrc-addrとdst-addr）は、MNの現在のCoAとHAアドレスを使用します。
There are two types of reverse-tunneled user data packets between the MN and the HA: those that are integrity protected and/or encrypted and those that are sent in the clear. The MN or the HA decides whether to apply integrity protection and/or encryption to a packet or to send it in the clear based on the mip6-sas value in the SA. If the mip6-sas is set to 1, the originator MUST NOT send any user data packets in the clear, and the receiver MUST silently discard any packet with the PType set to 0 (unprotected). It is RECOMMENDED that confidentiality and integrity protection of user data traffic be applied. The reverse-tunneled IPv4 or IPv6 user data packets are encapsulated as is inside the 'Payload Data' shown in Figures 8 and 9.
MNとHAの間には、2つのタイプのリバーストンネリングされたユーザーデータパケットがあります。それらは、整合性が保護または暗号化されているものと、クリアテキストで送信されるものです。 MNまたはHAは、SAのmip6-sas値に基づいて、完全性保護や暗号化をパケットに適用するか、それをクリアテキストで送信するかを決定します。 mip6-sasが1に設定されている場合、発信者はユーザーデータパケットを平文で送信してはならず（MUST）、受信者はPTypeが0（保護されていない）に設定されているパケットをサイレントに破棄する必要があります。ユーザーデータトラフィックの機密性と整合性の保護を適用することをお勧めします。逆トンネルされたIPv4またはIPv6ユーザーデータパケットは、図8および9に示す「ペイロードデータ」内にあるようにカプセル化されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: UDP-Encapsulated Protected User Data Packet Format
図8：UDPカプセル化保護ユーザーデータパケット形式
The PType value 1 (one) identifies that the UDP-encapsulated packet contains an encrypted-tunneled IPv4/IPv6 user data packet. The Next Header field header MUST be set to value corresponding the tunneled IP packet (e.g., 41 for IPv6).
PType値1（1）は、UDPカプセル化パケットに、暗号化されたトンネルIPv4 / IPv6ユーザーデータパケットが含まれていることを示します。次のヘッダーフィールドのヘッダーは、トンネリングされたIPパケットに対応する値に設定する必要があります（IPv6の場合は41など）。
The Padding, Pad Length, Next Header, and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document. For an SPI value of 0 (zero) that indicates an unprotected packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT be present.
このドキュメントで特に明記されていない限り、パディング、パッド長、次のヘッダー、およびICVフィールドは、[RFC4303]のセクション2.4〜2.8の規則に従います。保護されていないパケットを示す0（ゼロ）のSPI値の場合、パディング、パッド長、次のヘッダー、およびICVフィールドが存在してはなりません（MUST NOT）。
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 8) use the current CoA of the MN and the HA address. The ESP-protected inner IP header, which is not shown in Figure 8, uses the home address of the MN and the correspondent node (CN) address.
外部IPヘッダーの送信元と宛先のIPアドレス（つまり、図8のsrc-addrとdst-addr）は、MNの現在のCoAとHAアドレスを使用します。 ESPで保護された内部IPヘッダーは、図8には表示されていませんが、MNのホームアドレスとコレスポンデントノード（CN）アドレスを使用しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Payload Data (plain IPv4 or IPv6 Packet) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UDP-Encapsulated Non-Protected User Data Packet Format
図9：UDPカプセル化非保護ユーザーデータパケット形式
The PType value 0 (zero) identifies that the UDP-encapsulated packet contains a plaintext-tunneled IPv4/IPv6 user data packet. Also, the SPI and the Sequence Number fields MUST be set to 0 (zero).
PType値0（ゼロ）は、UDPカプセル化パケットにプレーンテキストトンネリングされたIPv4 / IPv6ユーザーデータパケットが含まれていることを示します。また、SPIおよびシーケンス番号フィールドは0（ゼロ）に設定する必要があります。
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 9) use the current CoA of the MN and the HA address. The plaintext inner IP header uses the home address of the MN and the CN address.
外部IPヘッダーの送信元および宛先IPアドレス（つまり、図9のsrc-addrおよびdst-addr）は、MNの現在のCoAとHAアドレスを使用します。プレーンテキストの内部IPヘッダーは、MNのホームアドレスとCNアドレスを使用します。
Mobile IPv6 route optimization as described in [RFC6275] is not affected by this specification. Route optimization is possible only between an IPv6 MN and CN. UDP encapsulation of signaling and data traffic is only between the MN and HA. The return routability signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are treated as data packets and encapsulation, when needed, is per the description in Section 6.4 of this specification. The data packets between an MN and CN that have successfully completed the return routability test and created the appropriate entries in their binding cache are not UDP encapsulated using the packet formats defined in this specification but follow the [RFC6275] specification.
[RFC6275]で説明されているモバイルIPv6ルート最適化は、この仕様の影響を受けません。ルートの最適化は、IPv6 MNとCNの間でのみ可能です。シグナリングとデータトラフィックのUDPカプセル化は、MNとHAの間のみです。 HoTI / HoTやCoTI / CoT [RFC6275]などのリターンルーティング可能性シグナリングメッセージは、データパケットとして扱われ、必要に応じて、この仕様のセクション6.4の説明に従ってカプセル化されます。戻りルーティング可能性テストを正常に完了し、バインディングキャッシュに適切なエントリを作成したMNとCN間のデータパケットは、この仕様で定義されているパケット形式を使用してUDPカプセル化されませんが、[RFC6275]仕様に従います。
IANA has created a new registry under the [RFC6275] Mobile IPv6 parameters registry for the Packet Type as described in Section 6.1.
セクション6.1で説明されているように、IANAは[RFC6275]モバイルIPv6パラメータレジストリの下にパケットタイプの新しいレジストリを作成しました。
Description | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
Following the allocation policies from [RFC5226], new values for the Packet Type AVP MUST be assigned based on the "RFC Required" policy.
[RFC5226]の割り当てポリシーに従って、「RFC必須」ポリシーに基づいて、パケットタイプAVPの新しい値を割り当てる必要があります。
A new Status Code (to be used in BA messages) is reserved for the cases where the HA wants to indicate to the MN that it needs to re-establish the SA information with the HAC. The following value is reserved in the [RFC6275] Status Codes registry:
新しいステータスコード（BAメッセージで使用される）は、HACでSA情報を再確立する必要があることをHAがMNに示したい場合のために予約されています。次の値は、[RFC6275]ステータスコードレジストリで予約されています。
REINIT_SA_WITH_HAC 176
REINIT_SA_WITH_HAC 176
A new port number (mipv6tls) for UDP packets is reserved from the existing PORT NUMBERS registry.
UDPパケットの新しいポート番号（mipv6tls）は、既存のPORT NUMBERSレジストリから予約されています。
mipv6tls 7872
mipv6tls 7872
This document describes and uses a number of building blocks that introduce security mechanisms and need to interwork in a secure manner.
このドキュメントでは、セキュリティメカニズムを導入し、安全な方法で相互作用する必要のあるいくつかのビルディングブロックについて説明し、使用します。
The following building blocks are considered from a security point of view:
次の構成要素は、セキュリティの観点から考慮されます。
1. Discovery of the HAC
1. HACの発見
2. Authentication and MN-HA SA establishment executed between the MN and the HAC (PSK- or EAP-based) through a TLS tunnel
2. TLSトンネルを介してMNとHAC（PSKまたはEAPベース）の間で実行される認証とMN-HA SAの確立
3. Protection of MN-HA communication
3. MN-HA通信の保護
4. AAA interworking
4. AAAインターワーキング
No dynamic procedure for discovering the HAC by the MN is described in this document. As such, no specific security considerations apply to the scope of this document.
このドキュメントでは、MNがHACを検出するための動的な手順については説明していません。そのため、このドキュメントの範囲に適用される特定のセキュリティ上の考慮事項はありません。
9.2. Authentication and Key Exchange Executed between the MN and the HAC
9.2. MNとHACの間で実行される認証と鍵交換
This document describes a simple authentication and MN-HA SA negotiation exchange over TLS. The TLS procedures remain unchanged; however, channel binding is provided.
このドキュメントでは、TLSを介した単純な認証とMN-HA SAネゴシエーション交換について説明します。 TLSの手順は変更されていません。ただし、チャネルバインディングは提供されます。
Authentication: Server-side certificate-based authentication MUST be performed using TLS version 1.2 [RFC5246]. The MN MUST verify the HAC's TLS server certificate, using either the subjectAltName extension [RFC5280] dNSName identities as described in [RFC6125] or subjectAltName iPAddress identities. In case of iPAddress identities, the MN MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match the connection. In case of dNSName identities, the rules and guidelines defined in [RFC6125] apply here, with the following considerations:
認証：サーバー側の証明書ベースの認証は、TLSバージョン1.2 [RFC5246]を使用して実行する必要があります。 MNは、[RFC6125]で説明されているsubjectAltName拡張[RFC5280] dNSName IDまたはsubjectAltName iPAddress IDのいずれかを使用して、HACのTLSサーバー証明書を検証する必要があります。 iPAddress IDの場合、MNはこれらのiPAddress IDに対してTLS接続のIPアドレスをチェックする必要があり、どのiPAddress IDも接続と一致しない場合は接続を拒否する必要があります。 dNSNameアイデンティティの場合、[RFC6125]で定義されたルールとガイドラインがここで適用されますが、以下の考慮事項があります。
* Support for DNS-ID identifier type (the dNSName identity in the subjectAltName extension) is REQUIRED in the HAC and the MN TLS implementations.
* HACおよびMN TLS実装では、DNS-ID識別子タイプ（subjectAltName拡張のdNSNameアイデンティティ）のサポートが必要です。
* DNS names in the HAC server certificates MUST NOT contain the wildcard character "*".
* HACサーバー証明書のDNS名には、ワイルドカード文字「*」を含めることはできません。
* The CN-ID MUST NOT be used for authentication within the rules described in [RFC6125].
* CN-IDは、[RFC6125]で説明されているルール内の認証に使用してはなりません（MUST NOT）。
* The MN MUST set its "reference identifier" to the DNS name of the HAC.
* MNは、その「参照識別子」をHACのDNS名に設定する必要があります。
The client-side authentication may depend on the specific deployment and is therefore not mandated. Note that TLS-PSK [RFC4279] cannot be used in conjunction with the methods described in Sections 5.8 and 5.9 of this document due to the limitations of the channel binding type used.
クライアント側の認証は特定の展開に依存する可能性があるため、必須ではありません。 TLS-PSK [RFC4279]は、使用されるチャネルバインディングタイプの制限により、このドキュメントのセクション5.8および5.9で説明されている方法と併用できないことに注意してください。
Through the protected TLS tunnel, an additional authentication exchange is performed that provides client-side or mutual authentication and exchanges SA parameters and optional configuration data to be used in the subsequent protection of MN-HA communication. The additional authentication exchange can be either PSK-based (Section 5.8) or EAP-based (Section 5.9). Both exchanges are always performed within the protected TLS tunnel and MUST NOT be used as standalone protocols.
保護されたTLSトンネルを通じて、追加の認証交換が実行され、クライアント側または相互認証が提供され、その後のMN-HA通信の保護で使用されるSAパラメーターとオプションの構成データが交換されます。追加の認証交換は、PSKベース（セクション5.8）またはEAPベース（セクション5.9）のいずれかです。両方の交換は常に保護されたTLSトンネル内で実行され、スタンドアロンプロトコルとして使用してはなりません。
The simple PSK-based authentication exchange provides mutual authentication and follows the GPSK exchange used by EAP-GPSK [RFC5433] and has similar properties, although some features of GPSK like the exchange of a protected container are not supported.
単純なPSKベースの認証交換は相互認証を提供し、EAP-GPSK [RFC5433]によって使用されるGPSK交換に従い、同様のプロパティを持っていますが、保護されたコンテナの交換などのGPSKの一部の機能はサポートされていません。
The EAP-based authentication exchange simply defines message containers to allow carrying the EAP packets between the MN and the HAC. In principle, any EAP method can be used. However, it is strongly recommended to use only EAP methods that provide mutual authentication and that derive keys including an MSK in compliance with [RFC3748].
EAPベースの認証交換では、単純にメッセージコンテナを定義して、MNとHACの間でEAPパケットを伝送できるようにします。原則として、どのEAP方式も使用できます。ただし、相互認証を提供し、[RFC3748]に準拠したMSKを含むキーを導出するEAPメソッドのみを使用することを強くお勧めします。
Both exchanges use channel binding with the TLS tunnel. The channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be used.
どちらの交換でも、TLSトンネルでチャネルバインディングを使用します。 [RFC5929]のチャネルバインディングタイプ「TLS-server-endpoint」を使用する必要があります。
Dictionary Attacks: All messages of the authentication exchanges specified in this document are protected by TLS. However, any implementation SHOULD assume that the properties of the authentication exchange are the same as for GPSK [RFC5433], in case the PSK-based method per Section 5.8 is used, and are the same as those of the underlying EAP method, in case the EAP-based exchange per Section 5.9 is used.
辞書攻撃：このドキュメントで指定されている認証交換のすべてのメッセージは、TLSによって保護されています。ただし、実装では、セクション5.8のPSKベースのメソッドが使用されている場合、認証交換のプロパティはGPSK [RFC5433]と同じであり、基盤となるEAPメソッドのプロパティと同じであると想定する必要があります（SHOULD）。セクション5.9のEAPベースの交換が使用されます。
Replay Protection: The underlying TLS protection provides protection against replays.
リプレイ保護：基盤となるTLS保護は、リプレイに対する保護を提供します。
Key Derivation and Key Strength: For TLS, the TLS-specific considerations apply unchanged. For the authentication exchanges defined in this document, no key derivation step is performed as the MN-HA keys are generated by the HAC and are distributed to the MN through the secure TLS connection.
鍵の派生と鍵の強度：TLSの場合、TLS固有の考慮事項は変更されずに適用されます。このドキュメントで定義されている認証交換では、MN-HAキーがHACによって生成され、セキュアなTLS接続を介してMNに配布されるため、キーの導出手順は実行されません。
Key Control: No joint key control for MN-HA keys is provided by this version of the specification.
キー制御：このバージョンの仕様では、MN-HAキーの共同キー制御は提供されていません。
Lifetime: The TLS-protected authentication exchange between the MN and the HAC is only to bootstrap keys and other parameters for usage with MN-HA security. The SAs that contain the keys have an associated lifetime. The usage of Transport Layer Security (TLS) Session Resumption without Server-Side State, described in [RFC5077], provides the ability for the MN to minimize the latency of future exchanges towards the HA without having to keep state at the HA itself.
ライフタイム：MNとHACの間のTLSで保護された認証交換は、MN-HAセキュリティで使用するためのキーとその他のパラメーターをブートストラップするためだけのものです。キーを含むSAには、ライフタイムが関連付けられています。 [RFC5077]で説明されているサーバー側状態なしのトランスポート層セキュリティ（TLS）セッション再開の使用は、MNがHA自体の状態を維持する必要なく、HAへの将来の交換の待ち時間を最小限に抑える機能を提供します。
Denial-of-Service (DoS) Resistance: The level of resistance against DoS attacks SHOULD be considered the same as for common TLS operation, as TLS is used unchanged. For the PSK-based authentication exchange, no additional factors are known. For the EAP-based authentication exchange, any considerations regarding DoS resistance specific to the chosen EAP method are expected to be applicable and need to be taken into account.
サービス拒否（DoS）耐性：TLSは変更されずに使用されるため、DoS攻撃に対する耐性のレベルは、一般的なTLS操作と同じであると考えるべきです（SHOULD）。 PSKベースの認証交換の場合、追加の要素はわかっていません。 EAPベースの認証交換の場合、選択したEAP方式に固有のDoS耐性に関する考慮事項が適用可能であると予想され、考慮する必要があります。
Session Independence: Each individual TLS protocol run is independent from any previous exchange based on the security properties of the TLS handshake protocol. However, several PSK-or EAP-based authentication exchanges can be performed across the same TLS connection.
セッションの独立性：個々のTLSプロトコルの実行は、TLSハンドシェイクプロトコルのセキュリティプロパティに基づいて、以前の交換から独立しています。ただし、いくつかのPSKまたはEAPベースの認証交換は、同じTLS接続を介して実行できます。
Fragmentation: TLS runs on top of TCP and no fragmentation-specific considerations apply to the MN-HAC authentication exchanges.
断片化：TLSはTCPの上で実行され、MN-HAC認証交換には断片化固有の考慮事項は適用されません。
Channel Binding: Both the PSK and the EAP-based exchanges use channel binding with the TLS tunnel. The channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be used.
チャネルバインディング：PSKとEAPベースの交換はどちらも、TLSトンネルでチャネルバインディングを使用します。 [RFC5929]のチャネルバインディングタイプ「TLS-server-endpoint」を使用する必要があります。
Fast Reconnect: This protocol provides session resumption as part of TLS and optionally the support for [RFC5077]. No fast reconnect is supported for the PSK-based authentication exchange. For the EAP-based authentication exchange, availability of fast reconnect depends on the EAP method used.
高速再接続：このプロトコルは、TLSの一部としてセッション再開を提供し、オプションで[RFC5077]をサポートします。 PSKベースの認証交換では、高速再接続はサポートされていません。 EAPベースの認証交換の場合、高速再接続の可用性は、使用されるEAP方式によって異なります。
Identity Protection: Based on the security properties of the TLS tunnel, passive user identity protection is provided. An attacker acting as man-in-the-middle in the TLS connection would be able to observe the MN identity value sent in MHAuth-Init messages.
ID保護：TLSトンネルのセキュリティプロパティに基づいて、パッシブユーザーID保護が提供されます。 TLS接続で中間者として動作する攻撃者は、MHAuth-Initメッセージで送信されたMN ID値を監視することができます。
Protected Ciphersuite Negotiation: This protocol provides ciphersuite negotiation based on TLS.
保護された暗号スイートネゴシエーション：このプロトコルは、TLSに基づく暗号スイートネゴシエーションを提供します。
Confidentiality: Confidentiality protection of payloads exchanged between the MN and the HAC are protected with the TLS Record Layer. TLS ciphersuites with confidentiality and integrity protection MUST be negotiated and used in order to exchange security sensitive material inside the TLS connection.
機密性：MNとHACの間で交換されるペイロードの機密性保護は、TLSレコードレイヤーで保護されます。機密性と完全性保護を備えたTLS暗号スイートは、TLS接続内のセキュリティ上重要な資料を交換するためにネゴシエートして使用する必要があります。
Cryptographic Binding: No cryptographic bindings are provided by this protocol specified in this document.
暗号バインディング：このドキュメントで指定されているこのプロトコルでは、暗号バインディングは提供されていません。
Perfect Forward Secrecy: Perfect forward secrecy is provided with appropriate TLS ciphersuites.
Perfect Forward Secrecy：Perfect Forward Secrecyは、適切なTLS暗号スイートで提供されます。
Key confirmation: Key confirmation of the keys established with TLS is provided by the TLS Record Layer when the keys are used to protect the subsequent TLS exchange.
キー確認：後続のTLS交換を保護するためにキーが使用される場合、TLSで確立されたキーのキー確認は、TLSレコードレイヤーによって提供されます。
Authentication: Data origin authentication is provided for the communication between the MN and the HA. The chosen level of security of this authentication depends on the selected ciphersuite. Entity authentication is offered by the MN to HAC protocol exchange.
認証：データ発信元認証は、MNとHA間の通信に提供されます。この認証で選択するセキュリティレベルは、選択した暗号スイートによって異なります。エンティティー認証は、MNからHACプロトコルへの交換によって提供されます。
Dictionary Attacks: The concept of dictionary attacks is not applicable to the MN-HA communication as the keying material used for this communication is randomly created by the HAC and its length depends on the chosen cryptographic algorithms.
辞書攻撃：辞書通信の概念はMN-HA通信には適用されません。この通信に使用されるキー情報はHACによってランダムに作成され、その長さは選択された暗号アルゴリズムに依存するためです。
Replay Protection: Replay protection for the communication between the MN and the HA is provided based on sequence numbers and follows the design of IPsec ESP.
リプレイ保護：MNとHA間の通信のリプレイ保護は、シーケンス番号に基づいて提供され、IPsec ESPの設計に従います。
Key Derivation and Key Strength: The strength of the keying material established for the communication between the MN and the HA is selected based on the negotiated ciphersuite (based on the MN-HAC exchange) and the key created by the HAC. The randomness requirements for security described in [RFC4086] are applicable to the key generation by the HAC.
鍵の導出と鍵の強度：MNとHA間の通信用に確立された鍵情報の強度は、ネゴシエートされた暗号スイート（MN-HAC交換に基づく）とHACによって作成された鍵に基づいて選択されます。 [RFC4086]で説明されているセキュリティのランダム性要件は、HACによるキー生成に適用されます。
Key Control: The keying material established during the MN-HAC protocol exchange for subsequent protection of the MN-HA communication is created by the HA and therefore no joint key control is provided for it.
鍵管理：MN-HA通信のその後の保護のためにMN-HACプロトコル交換中に確立される鍵素材は、HAによって作成されるため、共同鍵管理は提供されません。
Key Naming: For the MN-HA communication, the security associations are indexed with the help of the SPI and additionally based on the direction (inbound communication or outbound communication).
キーの命名：MN-HA通信の場合、セキュリティアソシエーションは、SPIの助けを借りて、さらに方向（インバウンド通信またはアウトバウンド通信）に基づいてインデックス化されます。
Lifetime: The lifetime of the MN-HA security associations is based on the value in the mip6-sa-validity-end header field exchanged during the MN-HAC exchange. The HAC controls the SA lifetime.
ライフタイム：MN-HAセキュリティアソシエーションのライフタイムは、MN-HAC交換中に交換されるmip6-sa-validity-endヘッダーフィールドの値に基づいています。 HACはSAライフタイムを制御します。
DoS Resistance: For the communication between the MN and the HA, there are no heavy cryptographic operations (such as public key computations). As such, there are no DoS concerns.
DoS耐性：MNとHA間の通信では、重い暗号化操作（公開鍵の計算など）はありません。そのため、DoSの問題はありません。
Session Independence: Sessions are independent from each other when new keys are created via the MN-HAC protocol. A new MN-HAC protocol run produces fresh and unique keying material for protection of the MN-HA communication.
セッションの独立性：MN-HACプロトコルを介して新しいキーが作成されると、セッションは互いに独立します。新しいMN-HACプロトコルの実行により、MN-HA通信を保護するための新鮮でユニークなキーイングマテリアルが生成されます。
Fragmentation: There is no additional fragmentation support provided beyond what is offered by the network layer.
断片化：ネットワーク層によって提供されるものを超える追加の断片化サポートはありません。
Channel Binding: Channel binding is not applicable to the MN-HA communication.
チャネルバインディング：チャネルバインディングはMN-HA通信には適用されません。
Fast Reconnect: The concept of fast reconnect is not applicable to the MN-HA communication.
高速再接続：高速再接続の概念は、MN-HA通信には適用されません。
Identity Protection: User identities SHOULD NOT be exchanged between the MN and the HA. In the case where binding management messages contain the user identity, the messages SHOULD be confidentiality protected.
ID保護：ユーザーIDは、MNとHAの間で交換しないでください。バインディング管理メッセージにユーザーIDが含まれている場合、メッセージは機密性を保護する必要があります（SHOULD）。
Protected Ciphersuite Negotiation: The MN-HAC protocol provides protected ciphersuite negotiation through a secure TLS connection.
保護された暗号スイートネゴシエーション：MN-HACプロトコルは、安全なTLS接続を介して保護された暗号スイートネゴシエーションを提供します。
Confidentiality: Confidentiality protection of payloads exchanged between the MN and the HAC (for Mobile IPv6 signaling and optionally for the data traffic) is provided utilizing algorithms negotiated during the MN-HAC exchange.
機密性：MNとHACの間で交換されるペイロードの機密性保護（モバイルIPv6シグナリング用、オプションでデータトラフィック用）は、MN-HAC交換中にネゴシエートされたアルゴリズムを利用して提供されます。
Cryptographic Binding: No cryptographic bindings are provided by this protocol specified in this document.
暗号バインディング：このドキュメントで指定されているこのプロトコルでは、暗号バインディングは提供されていません。
Perfect Forward Secrecy: Perfect forward secrecy is provided when the MN bootstraps new keying material with the help of the MN-HAC protocol (assuming that a proper TLS ciphersuite is used).
完全転送秘密：完全転送秘密は、MNがMN-HACプロトコルを使用して新しいキー情報をブートストラップするときに提供されます（適切なTLS暗号スイートが使用されていると想定）。
Key Confirmation: Key confirmation of the MN-HA keying material conveyed from the HAC to the MN is provided when the first packets are exchanged between the MN and the HA (in both directions as two different keys are used).
鍵の確認：HACからMNに伝達されるMN-HAのキー情報の鍵の確認は、MNとHAの間で最初のパケットが交換されるときに提供されます（2つの異なる鍵が使用されるため、両方向で）。
The AAA backend infrastructure interworking is not defined in this document and is therefore out of scope.
AAAバックエンドインフラストラクチャのインターワーキングは、このドキュメントでは定義されていないため、範囲外です。
The authors would like to thank Pasi Eronen, Domagoj Premec, Julien Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and Christian Bauer for their comments.
著者は、コメントを提供してくれたPasi Eronen、Domagoj Premec、Julien Laganier、Jari Arkko、Stephen Farrell、Peter Saint-Andre、およびChristian Bauerに感謝します。
[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月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C。およびR. Glenn、「The Use of HMAC-SHA-1-96 within ESP and AH」、RFC 2404、1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn、R。およびS. Kent、「NULL暗号化アルゴリズムとIPsecでのその使用」、RFC 2410、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]フランケルS.およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとIPsecでのその使用」、RFC 3566、2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]フランケルS.、グレンR.、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPsecでのその使用」、RFC 3602、2003年9月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズN.、「セキュアチャネルへのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、2010年7月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "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月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776] Arkko、J.、Devarapalli、V。、およびF. Dupont、「IPsecを使用したモバイルノードとホームエージェント間のモバイルIPv6シグナリングの保護」、RFC 3776、2004年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279] Eronen、P。およびH. Tschofenig、「トランスポート層セキュリティ（TLS）の事前共有鍵暗号スイート」、RFC 4279、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V。およびF. Dupont、「Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture」、RFC 4877、2007年4月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、RFC 5077、2008年1月。
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.
[RFC5433] Clancy、T。およびH. Tschofenig、「Extensible Authentication Protocol-Generalized Pre-Shared Key（EAP-GPSK）Method」、RFC 5433、2009年2月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマンH.、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（編集者）Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600フィンランド
EMail: jouni.nospam@gmail.com
Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia 6021 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nokia.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@gmx.net
Dirk Kroeselberg Siemens Otto-Hahn-Ring 6 Munich 81739 Germany
Dirk Kroeselberg Siemens Otto-Hahn-Ring 6ミュンヘン81739ドイツ
EMail: dirk.kroeselberg@siemens.com