Network Working Group V. Devarapalli
Request for Comments: 4877 Azaire Networks
Updates: 3776 F. Dupont
Category: Standards Track CELAR
April 2007
Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
IKEv2の持つモバイルIPv6運用と改訂IPsecのアーキテクチャ
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2.
この文書では、改訂されたIPsecアーキテクチャとのIKEv2とモバイルIPv6の動作を説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5
4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7
4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9
5. Selector Granularity Considerations . . . . . . . . . . . . . 10
6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11
6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 12
6.2. Return Routability Messages . . . . . . . . . . . . . . . 13
6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 14
6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14
7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 15
7.1. Peer Authorization Database Entries . . . . . . . . . . . 15
7.2. Security Policy Database Entries . . . . . . . . . . . . . 15
7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 16
7.2.2. Return Routability Messages . . . . . . . . . . . . . 17
7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17
7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18
7.3. Security Association Negotiation Using IKEv2 . . . . . . . 18
7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20
8. The Use of EAP Authentication . . . . . . . . . . . . . . . . 21
9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used with Mobile IPv6 [2] to protect the signaling messages. It also illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages.
RFC 3776は、RFC 2401 [11]に記載されているようにIPsec、シグナリングメッセージを保護するために、モバイルIPv6 [2]で使用される方法について説明します。また、セキュリティポリシーデータベースとモバイルIPv6シグナリングメッセージを保護するために使用することができ、セキュリティアソシエーションデータベースのエントリの例を示しています。
The IPsec architecture has been revised in RFC 4301 [5]. Among the many changes, the list of selectors has been expanded to include the Mobility Header message type. This has an impact on how security policies and security associations are configured for protecting mobility header messages. It becomes easier to differentiate between the various Mobility Header messages based on the type value instead of checking if a particular mobility header message is being sent on a tunnel interface between the mobile node and the home agent, as it was in RFC 3776. The revised IPsec architecture specification also includes ICMP message type and code as selectors. This makes it possible to protect Mobile Prefix Discovery messages without applying the same security associations to all ICMPv6 messages.
IPsecのアーキテクチャは、RFC 4301に改訂されている[5]。多くの変化の中で、セレクターのリストは、モビリティヘッダのメッセージタイプを含むように拡張されました。これは、セキュリティポリシーとセキュリティアソシエーションは、モビリティヘッダのメッセージを保護するために設定されているどのように影響を与えます。その代わりに、特定のモビリティヘッダメッセージは、モバイルノードとホームエージェント間のトンネルインターフェイス上で送信される場合、それはRFC 3776.改訂であったように、検査の種類の値に基づいて、様々なモビリティヘッダのメッセージを区別することが容易になりますIPsecのアーキテクチャ仕様では、セレクタとしてICMPメッセージタイプとコードを含みます。これは、すべてのICMPv6メッセージに同じセキュリティアソシエーションを適用せずにモバイルプレフィックスディスカバリーメッセージを保護することが可能となります。
This document discusses new requirements for the home agent and the mobile node to use the revised IPsec architecture and IKEv2. Section 4 lists the requirements. Sections 6 and 7 describe the required Security Policy Database (SPD) and Security Association Database (SAD) entries.
この文書では、ホームエージェントと改訂されたIPsecアーキテクチャとのIKEv2を使用するために、モバイルノードのための新たな要件について説明します。第4章では、要件を示します。セクション6および7は、必要なセキュリティポリシーデータベース（SPD）とセキュリティアソシエーションデータベース（SAD）のエントリを記述します。
The Internet Key Exchange (IKE) protocol has also been substantially revised and simplified [4]. Section 7.3 of this document describes how IKEv2 can be used to set up security associations for Mobile IPv6.
インターネット鍵交換（IKE）プロトコルはまた、実質的に改訂し、簡略化されている[4]。このドキュメントのセクション7.3は、IKEv2のモバイルIPv6のセキュリティアソシエーションを設定するために使用する方法について説明します。
The use of EAP within IKEv2 is allowed to authenticate the mobile node to the home agent. This is described in Section 8. A method for dynamically configuring a home address from the home agent using the Configuration Payload in IKEv2 is described in Section 9.
IKEv2の中のEAPの使用はホームエージェントにモバイルノードを認証するために許可されています。これは、セクション8に記載された動的のIKEv2に設定ペイロードを使用して、ホームエージェントからホームアドレスを設定するための方法は、第9章で説明されています。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
The mobile node and the home agent MUST support the packet formats as defined in Section 3 of RFC 3776.
RFC 3776のセクション3で定義されるように、モバイルノードとホームエージェントは、パケットフォーマットをサポートしなければなりません。
In case the mobile node reverse tunnels all traffic including Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, then the Home Address Option is not required to be present in the messages sent to the home agent. The packet format for the binding update when sent in the tunnel mode looks as follows.
場合には、モバイルノードは、モバイルIPv6を含む、すべてのトラフィックは、シグナリングメッセージをトンネルを逆その後、ホームアドレスオプションは、ホームエージェントに送信されたメッセージに存在することが必要とされていない、モバイルノードとホームエージェント間で交換。次のようにトンネルモードで送られたバインディングアップデートのためのパケットフォーマットに見えます。
IPv6 hdr (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 hdr (source = home address, destination = home agent) Mobility Header Binding Update Alternate Care-of Address option (care-of address)
IPv6のHDR（ソース=気付アドレス、宛先=ホームエージェント）ESPヘッダトンネルモードでのIPv6 HDR（ソース=ホームアドレス、宛先=ホームエージェント）モビリティヘッダは、更新、代替気付アドレスオプション（気付アドレス）をバインド
The binding acknowledgement sent to the mobile node when it is away from the home link looks as follows.
次のようにそれがホームリンクから離れているとき、モバイルノードに送信されたバインディング確認が見えます。
IPv6 hdr (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 hdr (source = home agent, destination = home address) Mobility Header Binding Acknowledgement
謝辞結合のIPv6 HDRトンネルモードのIPv6 HDRで（ソース=ホーム・エージェント、宛先=気付アドレス）ESPヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）モビリティヘッダ
The packet formats for tunneled mobile prefix discovery messages are very similar to the tunneled Binding Update and Binding Acknowledgment with the with the home address as the source address in the inner IP header.
トンネリングされたモバイルプレフィックス発見メッセージのパケットフォーマットは、トンネルバインディングアップデートに非常に類似しており、内側のIPヘッダ内の送信元アドレスとしてホームアドレスを持つと謝辞を結合します。
The support for the above tunneled packet format is optional on the mobile node and the home agent.
上記のトンネリングされたパケット・フォーマットのサポートは、モバイルノードとホームエージェントではオプションです。
This section describes mandatory rules and requirements for all Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as the key management protocol, can be used to protect traffic between the mobile node and the home agent. Many of the requirements are repeated from RFC 3776 to make this document self-contained and complete.
IPsecは、鍵管理プロトコルなどのIKEv2で、モバイルノードとホームエージェント間のトラフィックを保護するために使用することができるように、このセクションでは、すべてのモバイルIPv6モバイルノードとホームエージェントのために必須のルールと要件について説明します。要件の多くは、この文書は自己完結型と完全にするために、RFC 3776から繰り返します。
o RFC 3775 states that manual configuration of IPsec security associations MUST be supported, and automated key management MAY be supported. This document does not make any recommendations regarding the support of manual IPsec configuration and dynamic IPsec configuration. This document just describes the use of manually created IPsec security associations and the use of IKEv2 as the automated IPsec key management protocol for protecting Mobile IPv6 signaling messages.
OのRFC 3775は、IPsecセキュリティアソシエーションの手動設定をサポートしなければならないと述べ、および自動化された鍵管理をサポートすることができます。この文書では、手動IPsec構成と動的IPsec構成のサポートに関するいかなる勧告を行いません。この文書では、単に手動で作成したIPsecセキュリティアソシエーションの使用およびモバイルIPv6シグナリングメッセージを保護するための自動化されたIPsecの鍵管理プロトコルとしてのIKEv2の使用を記載しています。
o ESP encapsulation for Binding Updates and Binding Acknowledgements MUST be supported and used.
O結合更新し、謝辞を結合するためのESPのカプセル化をサポートして使用しなければなりません。
o ESP encapsulation in tunnel mode for the Home Test Init (HoTi) and Home Test (HoT) messages tunneled between the mobile node and the home agent MUST be supported and SHOULD be used.
Oモバイルノードとホームエージェントとの間でトンネリングホームテスト開始（HoTiメッセージ）とホーム試験（HOT）のためのトンネル・モードでESPカプセル化メッセージがサポートしなければならなくて、使用されるべきです。
o ESP encapsulation of the ICMPv6 messages related to mobile prefix discovery MUST be supported and SHOULD be used.
モバイルプレフィックスの発見に関連するICMPv6メッセージのO ESPのカプセル化をサポートしなければなりませんし、使用されるべきです。
o ESP encapsulation of the payload packets tunneled between the mobile node and the home agent MAY be supported and used.
Oモバイルノードとホームエージェント間のトンネル化ペイロードパケットのESPカプセル化をサポートして使用することができます。
o If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported for those protocols.
マルチキャストグループメンバーシップの制御プロトコルまたはステートフルアドレス自動設定プロトコルがサポートされている場合は、O、ペイロードデータ保護は、これらのプロトコルのためにサポートしなければなりません。
o The home agent and the mobile node MAY support authentication using EAP in IKEv2 as described in Section 8.
第8章で説明したように、O、ホームエージェントと、モバイルノードは、IKEv2の中でEAPを使用して認証をサポートするかもしれません。
o The home agent and the mobile node MAY support remote configuration of the home address as described in Section 9. When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it must reply with a valid home address for the mobile node. The home agent can pick a home address from a local database or from a DHCPv6 server on the home link.
第9節で説明したように、ホームエージェントは、INTERNAL_IP6_ADDRESSためCFG_REQUESTで設定ペイロードを受信すると、ホームエージェントと、モバイルノードがホームアドレスのリモート構成をサポートするかもしれO、それはモバイルノードのための有効なホームアドレスで応答しなければなりません。ホームエージェントは、ローカルデータベースまたはホームリンク上のDHCPv6サーバから自宅の住所を選ぶことができます。
The following requirements are related to the configuration of the security policy database on the home agent and the mobile node.
以下の要件は、ホームエージェントのセキュリティポリシーデータベースとモバイルノードの構成に関連しています。
o RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and those tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required for protecting mobility header messages. Note that without per-interface security policies, payload packet protection is limited to packets originating/terminating at the home address. Traffic using a link local address within the Mobile IP tunnel cannot be provided IPsec protection without per-interface security policies.
OのRFC 3776は、モビリティヘッダのホームエージェントに送信されたメッセージとコレスポンデントノードにホームエージェントを介してトンネルそれらを区別できるようにするために、インターフェイスごとのセキュリティポリシーの設定が必要でした。モビリティヘッダのメッセージタイプがセレクタであるので、今のHoTi及び他のモビリティヘッダメッセージからのHoTメッセージを区別することは容易です。したがって、セキュリティポリシーのインターフェースごとの構成は、モビリティヘッダのメッセージを保護するために必要とされません。インターフェイスごとのセキュリティポリシーなしに、ペイロードパケットの保護はホームアドレスで終端/発信さのパケットに制限されていることに注意してください。モバイルIPトンネル内のリンクローカルアドレスを使用してトラフィックは、インターフェイスごとのセキュリティポリシーなしでIPsec保護を提供することができません。
o The home agent MUST be able to prevent a mobile node from using its security association to send a Binding Update on behalf of another mobile node. With manual IPsec configuration, the home agent MUST be able to verify that a security association was created for a particular home address. With dynamic keying, the home agent MUST be able to verify that the identity presented in the IKE_AUTH exchange is allowed to create security associations for a particular home address.
Oホームエージェントは、他の移動ノードの代わりにバインディングアップデートを送信するために、そのセキュリティアソシエーションを使用してから、移動ノードのを防ぐことができなければなりません。手動IPsec構成では、ホームエージェントは、セキュリティアソシエーションが特定のホームアドレスのために作成されたことを確認することができなければなりません。動的なキーを使用すると、ホームエージェントは、IKE_AUTH交換に提示身元が特定のホームアドレスのためのセキュリティアソシエーションを作成するために許可されていることを確認することができなければなりません。
o The home agent uses the Peer Authorization Database (PAD) [5] to store per-mobile node state. More specifically the per-mobile state stores information that is used to authenticate the mobile node and the authorization information that ties the mobile node's identity to the home address of the mobile node. This will allow the home agent to prevent a mobile node from creating IPsec security associations for another mobile node's home address. In case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address.
Oホームエージェントは、ピア認証データベース（PAD）[5]あたりのモバイルノードの状態を格納するために使用します。具体的には当たりのモバイルモバイルノードとモバイルノードのホームアドレスにモバイルノードのIDを結びつける認証情報を認証するために使用されている状態情報を格納します。これは、ホームエージェントは、他のモバイルノードのホームアドレスのためのIPsecセキュリティアソシエーションを作成するから、移動ノードを防ぐことができるようになります。動的ホームアドレス割り当ての場合は、ホームエージェントは、認証されたピアのIDと新たに割り当てられたホームアドレスを結ぶ一時的なパッドのエントリを作成します。
o As required in the base specification [2], when a packet destined to the receiving node is matched against IPsec security policy or selectors of a security association, an address appearing in a Home Address destination option is considered as the source address of the packet.
ベース仕様で必要に応じてO [2]、受信ノード宛のパケットは、IPsecセキュリティポリシーまたはセキュリティアソシエーションのセレクタと照合された場合、ホームアドレス宛先オプションに現れるアドレスがパケットの送信元アドレスとして考えられています。
Note that the home address option appears before IPsec headers. Section 11.3.2 of the base specification describes one possible implementation approach for this: The IPsec policy operations can be performed at the time when the packet has not yet been modified per Mobile IPv6 rules, or has been brought back to its normal form after Mobile IPv6 processing. That is, the processing of the Home Address option is seen as a fixed transformation of the packets that does not affect IPsec processing.
ホームアドレスオプションは、IPsecのヘッダーの前に現れることに注意してください。基本仕様のセクション11.3.2は、このための1つの可能な実装手法を説明：IPsecポリシーの動作は、パケットがまだモバイルIPv6ルールごとに変更されていない時に実行することができ、あるいはモバイル後にその通常の形に戻されていますIPv6処理。これは、ホームアドレスオプションの処理は、IPsec処理には影響を与えませんパケットの固定変換として見られている、です。
o Similarly, a home address within a Type 2 Routing header destined to the receiving node is considered as the destination address of the packet, when a packet is matched against IPsec security policy or selectors of a security association.
O同様に、受信ノード宛タイプ2ルーティングヘッダ内のホームアドレスは、パケットがIPsecセキュリティポリシーまたはセキュリティアソシエーションのセレクタと照合された場合、パケットの宛先アドレスとして考えられています。
Similar implementation considerations apply to the Routing header processing as was described above for the Home Address destination option.
ホームアドレス宛先オプションについて上述したと同様の実装の考慮事項は、ルーティングヘッダ処理に適用されます。
o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent, SHOULD be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual configuration, they MUST be retained and used later when the mobile node moves away from home again. The security associations protecting Binding Updates, Binding Acknowledgements and Mobile Prefix Discovery messages SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again.
モバイルノードがホームを返し、ホームエージェント、ホームエージェントとモバイルノードの気付アドレス間のトンネルで登録解除するとO取り壊されます。モバイルノードとホームエージェント間のトンネルトラフィックを保護するために使用されたセキュリティポリシーエントリは、（例えば、それらを削除し、APIを介してそれらを後で戻ってインストールすることで）非アクティブになされるべきです。対応するセキュリティアソシエーションは、それらが作成されたかに応じて、彼らがそうであるように保持または削除することができました。セキュリティアソシエーションは、IKEを使用して動的に作成された場合、それらの期限が切れたときに、それらは自動的に削除されます。セキュリティアソシエーションを手動設定によって作成された場合、移動ノードは再び家から離れて移動したとき、彼らは後に保持され、使用されなければなりません。彼らは気付アドレスに依存しないと、再び使用することができますようバインディングアップデート、バインディング謝辞およびモバイルプレフィックスディスカバリーメッセージを保護するセキュリティアソシエーションを削除しないでください。
o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations when transport mode IPsec protection is used, so that the home address is visible when the IPsec policy checks are made.
Oモバイルノードは、IPsecポリシーのチェックが行われたときに自宅の住所が表示されるように、トランスポートモードのIPsec保護は、使用されたときに更新およびモバイルプレフィックス要請の結合にホームアドレス宛先オプションを使用しなければなりません。
o The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node when transport mode IPsec protection is used, again due to the need to have the home address visible when the policy checks are made.
ホームエージェントはバインディング謝辞とモバイルプレフィックス広告タイプ2ルーティングヘッダを使用しなければならないoをトランスポート・モードのIPsec保護を使用した場合、再びによるポリシーのチェックが行われたときに目に見えるホームアドレスを持っている必要があるため、モバイル・ノードに送信されます。
The following lists requirements for IPsec processing at the Home Agent and the mobile node.
ホームエージェントとモバイルノードのIPsec処理のために、次の要件を示します。
o The home agent and mobile node SHOULD support Mobility Header message type as an IPsec selector.
Oホームエージェントと、モバイルノードは、IPsecセレクタとしてモビリティヘッダのメッセージタイプをサポートしなければなりません。
o The home agent and mobile node SHOULD support ICMPv6 message type as an IPsec selector.
Oホームエージェントと、モバイルノードは、IPsecセレクタとしてのICMPv6メッセージタイプをサポートしなければなりません。
o The home agent MUST be able to distinguish between HoTi messages sent to itself (when it is acting as a Correspondent Node) and those sent to Correspondent Nodes (when it is acting as a home agent) based on the destination address of the packet.
パケットの宛先アドレスに基づいて（それは相手ノードとして動作している場合）と（それがホームエージェントとして機能している場合）、それらが対応ノードに送信されたO、ホームエージェントは、自身に送信されたのHoTiメッセージを区別できなければなりません。
o When securing Binding Updates, Binding Acknowledgements, and Mobile Prefix Discovery messages, both the mobile node and the home agent MUST support the use of the Encapsulating Security Payload (ESP) [6] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity, and optional anti-replay protection. The use of sequence number in the ESP header to provide anti-replay protection is optional because the sequence numbers in the Binding Updates provide anti-replay protection. However, the anti-replay protection fails if the home agent loses the binding cache state, for example, due to a reboot. Since the IPsec security association state can also be assumed to be lost, ESP cannot provide anti-replay protection in this case. Complete anti-replay protection can only be provided by the use of a dynamic keying mechanism, like IKEv2.
O結合更新結合謝辞を確保し、モバイルプレフィックス探索メッセージを、モバイルノードとホームエージェントの両方が、トランスポートモードでカプセル化セキュリティペイロード（ESP）[6]ヘッダの使用をサポートしなければならない非ヌルペイロードを使用する必要がある場合データ発信元認証、コネクションレス完全性、およびオプションのアンチリプレイ保護を提供するために、認証アルゴリズム。結合更新のシーケンス番号はアンチリプレイ保護を提供するため、アンチリプレイ保護を提供するために、ESPヘッダ内のシーケンス番号の使用は任意です。ホームエージェントが原因の再起動に、例えば、バインディングキャッシュ状態を失った場合は、アンチリプレイ保護は失敗します。 IPSecセキュリティアソシエーションの状態も失われると仮定することができますので、ESPは、この場合にはリプレイ保護を提供することはできません。コンプリートアンチリプレイ保護が唯一のIKEv2のように、動的なキーイングメカニズムの使用により提供することができます。
Support for protecting these messages using ESP in tunnel mode is optional.
トンネルモードでESPを使用して、これらのメッセージを保護するためのサポートはオプションです。
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. A non-null encryption transform and a non-null authentication algorithm MUST be applied.
OトンネルモードのIPsec ESPをサポートしなければなりませんし、リターン・ルータビリティ手順に属するパケットの保護のために使用されるべきです。 null以外の暗号化変換と非ヌル認証アルゴリズムを適用しなければなりません。
o When ESP is used to protect Binding Updates, there is no protection for the care-of address that appears in the IPv6 header outside the area protected by ESP. It is important for the home agent to verify that the care-of address has not been tampered with. As a result, the attacker would have redirected the mobile node's traffic to another address. In order to prevent this, Mobile IPv6 implementations MUST use the Alternate Care-of Address mobility option in Binding Updates sent by mobile nodes while away from home. The exception to this is when the mobile node returns home and sends a Binding Update to the home agent in order to de-register.
ESPは、バインディングアップデートを保護するために使用されている場合は、O、気付アドレスESPによって保護された領域の外側のIPv6ヘッダーに表示されるための保護はありません。ホームエージェントは気付アドレスが改ざんされていないことを確認することが重要です。その結果、攻撃者が別のアドレスに移動ノードのトラフィックをリダイレクトしているだろう。これを防ぐために、モバイルIPv6の実装では、自宅から離れている間、モバイルノードによって送られた結合更新で代替気付アドレスモビリティオプションを使用しなければなりません。モバイルノードがホームを返し、登録解除するために、ホームエージェントにバインディングアップデートを送信する場合は例外です。
When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care-of address.
IPsecはリターン・ルータビリティ・シグナリングまたはペイロードパケットを保護するために使用される場合、モバイルノードは、それが現在の主気付アドレスへの発信トンネルパケットに使用する送信元アドレスを設定しなければなりません。
o When IPsec is used to protect return routability signaling or payload packets, IPsec security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed. Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node.
IPsecはリターン・ルータビリティ・シグナリングまたはペイロードパケットを保護するために使用された場合は、O、IPsecセキュリティアソシエーションがこの保護を提供するために必要とされます。気付アドレス受け付け結合更新の結果としてモバイルノードの変更のためには、特別な処理は、これらのセキュリティアソシエーションを使用して送信され、次のパケットのために必要とされる場合。セキュリティアソシエーションで、外側ヘッダの宛先アドレスが変更されたかのように、ホームエージェントは、これらのパケットの宛先アドレスとして新しい気付アドレスを設定しなければなりません。同様に、ホームエージェントは、モバイルノードから受信したトンネルパケットに新しい送信元アドレスを期待し始めます。
Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. One such API is described in [12]. It should be noted that the use of such an API and the address changes MUST only be done based on the Binding Updates received by the home agent and protected by the use of IPsec. Address modifications based on other sources, such as Binding Updates to the correspondent nodes protected by return routability, or open access to an API from any application may result in security vulnerabilities.
そのようなアドレス変更は、IPsec実装にモバイルIPv6実装からAPIを介して、例えば、実装することができます。そのようなAPIは、[12]に記載されています。このようなAPIを使用すると、アドレスの変更が唯一のIPsecを使用することにより、ホームエージェントによって受信され、保護されたバインディングアップデートに基づいて行わなければならないことに留意すべきです。このようなセキュリティの脆弱性をもたらすことができる任意のアプリケーションからAPIにリターンルータビリティ、又はオープンアクセスによって保護コレスポンデントノードへ結合更新のような他の情報源に基づいて、アドレスの変更。
The following requirements are related to the use of a dynamic key management protocol by the mobile node and the home agent. Section 7.3 describes the use of IKEv2 as the dynamic key management protocol.
以下の要件は、モバイルノードとホームエージェントによる動的鍵管理プロトコルの使用に関連しています。 7.3節では、動的キー管理プロトコルとしてのIKEv2の使用を記載しています。
o The mobile node MUST use its care-of address as source address in protocol exchanges, when using dynamic keying.
ダイナミックキーを使用する場合、O、移動ノードは、プロトコル交換のソースアドレスとしてその気付アドレスを使用しなければなりません。
o The mobile node and the home agent MUST create security associations based on the home address, so that the security associations survive changes in care-of address. When using IKEv2 as the key exchange protocol, the home address should be carried as the initiator IP address in the TSi payload during the CREATE_CHILD_SA exchange [4].
セキュリティアソシエーションは、気付アドレスの変更を生き残るように、モバイルノードとホームエージェントO、ホームアドレスに基づいてセキュリティアソシエーションを作成する必要があります。鍵交換プロトコルとしてのIKEv2を使用する場合は、ホームアドレスは、CREATE_CHILD_SA交換中のTSIペイロードのイニシエータIPアドレスとして実施すべきである[4]。
o If the mobile node has used IKEv2 to establish security associations with its home agent, it should follow the procedures discussed in Sections 11.7.1 and 11.7.3 of the base specification [2] to determine whether the IKE endpoints can be moved or if the SAs, including the IKEv2 SA, have to be re-established.
モバイルノードがそのホームエージェントとのセキュリティアソシエーションを確立するためのIKEv2を用いた場合、Oは、セクション11.7.1と基本仕様の11.7.3で説明した手順に従うべきである[2] IKEエンドポイントが移動した場合、またはすることができるかどうかを決定しますIKEv2のSAを含むSAは、再確立する必要があります。
o If the home agent has used IKEv2 to establish security associations with the mobile node, it should follow the procedures discussed in Section 10.3.1 and 10.3.2 of the base specification [2] to determine whether the IKE endpoints can be moved or if the SAs, including the IKEv2 SA, have to be re-established.
ホームエージェントは、モバイルノードとのセキュリティアソシエーションを確立するためのIKEv2を用いた場合、Oは、10.3.1項で説明した手順に従い、基本仕様の10.3.2べきである[2] IKEエンドポイントが移動した場合、またはすることができるかどうかを決定しますIKEv2のSAを含むSAは、再確立する必要があります。
IPsec implementations are compatible with this document even if they do not support fine-grain selectors such as the Mobility Header message type and ICMPv6 message type. Note that such IPsec implementations are not compliant with RFC 4301 [5]. For various reasons, some implementations may choose to support only coarse-grain selectors (i.e., addresses and in some cases the protocol field) for forwarded traffic. As finer-grain selectors give better control, i.e., the protection is only applied when required, the examples in this document always use the finest granularity.
彼らは、このようなモビリティヘッダのメッセージタイプとICMPv6メッセージタイプとして細粒セレクタをサポートしていない場合でも、IPsec実装は、この文書に対応しています。このようなIPsec実装は、RFC 4301に準拠していないことに留意されたい[5]。様々な理由のために、いくつかの実装は、転送されたトラフィックのみ粗粒セレクタ（すなわち、アドレス及びいくつかの場合にプロトコルフィールド）をサポートすることを選択してもよいです。より細かい粒度のセレクタは、よりよい制御を与えるとして、必要なときに、すなわち、保護のみ適用され、このドキュメントの例では、常に最高の精度を使用しています。
The following describes different ways of setting up IPsec policies for protecting Mobile IPv6 messages:
以下は、モバイルIPv6メッセージを保護するためにIPsecポリシーを設定するさまざまな方法について説明します。
1. The IPsec implementations on the mobile node and the home agent support fine-grain selectors, including the Mobility Header message type. This is the case assumed in the IPsec SPD and SAD examples in this document.
1.モビリティヘッダのメッセージタイプを含むモバイル・ノード上のIPsec実装とホームエージェントのサポート細粒セレクタは、。これは、IPsec SPDとこの文書のSADの例で想定している場合です。
2. The IPsec implementations only support selectors at a protocol level. Such an IPsec implementation can only identify mobility header traffic and cannot identify the individual mobility header messages. In this case, the protection of Return Routability Messages uses a setup similar to the regular payload packets sent to the correspondent node with the protocol selector set to Mobility Header. All tunneled Mobility Header messages will be protected.
2. IPsec実装は、プロトコルレベルでセレクタをサポートします。そのようなIPsec実装は、モビリティヘッダのトラフィックを識別することができ、個々のモビリティヘッダメッセージを識別することができません。この場合には、リターンルータビリティ・メッセージの保護は、モビリティヘッダに設定プロトコルセレクタとコレスポンデントノードに送信された定期的なペイロードパケットと同様のセットアップを使用します。すべてのトンネリングされたモビリティヘッダのメッセージが保護されます。
3. The third case is where the protocol selector is not available in the IPsec implementation. In this case, all traffic sent by the mobile node that is reverse tunneled through the home agent is protected using ESP in tunnel mode. This case is also applicable when the mobile node, due to privacy considerations, tunnels all traffic to the home agent. This includes Mobile IPv6 signaling messages exchanged between the mobile node and the home agent and all traffic exchanged between the mobile node and the correspondent node. This case uses IPsec tunnel mode SA with the protocol selector set to 'any'.
プロトコルセレクタはIPsec実装では利用できない第3の場合です。この場合は、逆のホームエージェントを介してトンネリングされ、モバイルノードによって送信されるすべてのトラフィックがトンネルモードでESPを使用して保護されています。プライバシーの配慮のために、モバイルノードは、ホームエージェントへのすべてのトラフィックをトンネリングすると、この場合にも適用されます。これは、シグナリングメッセージをモバイルIPv6は、モバイルノードとホームエージェント間で交換し、すべてのトラフィックは、モバイルノードとコレスポンデントノード間で交換されます。この場合は、「任意」に設定プロトコルセレクタとのIPsecトンネルモードSAを使用します。
The third case where all tunneled traffic is protected introduces some additional considerations:
すべてのトンネルトラフィックが保護されている第三のケースは、いくつかの追加の考慮事項が導入されています。
o If there is just one IPsec SA providing protection for all traffic, then the SA MUST fulfill the requirements for protecting the Return Routability messages which require confidentiality protection. If the third case is being used for privacy considerations, then there can also be separate tunnel mode SPD entries for protecting the Return Routability messages with a higher priority in the SPD so that the SPD entry with the higher priority gets applied first.
ただ一つのIPsec SAは、すべてのトラフィックに対する保護を提供している場合は、O、そしてSAは、機密性の保護を必要とリターンルータビリティのメッセージを保護するための要件を満たす必要があります。第三のケースは、プライバシーの考慮のために使用されている場合、また、優先度の高いSPDエントリが最初に適用されますように、SPDに優先的リターン・ルータビリティ・メッセージを保護するための別個のトンネルモードSPDエントリが存在することができます。
o The receipt of a Binding Update from the new care-of address updates the tunnel endpoint of the IPsec SA as described in Section 4.3. Since the Binding Update that updates the tunnel endpoint is received through the same tunnel interface that needs to be updated, special care should be taken on the home agent to ensure that the Binding Update is not dropped. This can be achieved either by performing the source address check on the outer IPv6 header after the binding update is processed or by having exception handling to check the inner packet for a Binding Update when the source address match on the outer source address fails. Typical IPsec processing does not check the outer source address when the originator of the packet has already been authenticated.
新しい気付アドレスからバインディングアップデートを受信Oセクション4.3に記載したようにIPsec SAのトンネルエンドポイントを更新します。トンネルエンドポイントを更新バインディングアップデートを更新する必要が同じトンネルインターフェースを介して受信されているので、特別なケアは、バインディングアップデートがドロップされていないことを確認するために、ホームエージェントに取られるべきです。これは、バインディング更新を処理または外側のソースアドレスに送信元アドレス一致が失敗したときにバインディング更新の内部パケットをチェックするために例外処理を有することをされた後、外側のIPv6ヘッダに送信元アドレスチェックを行うのいずれかによって達成することができます。典型的なIPsec処理は、パケットの発信元がすでに認証された外側の送信元アドレスをチェックしません。
This section describes the SPD and SAD entries that can be used to protect Mobile IPv6 signaling messages. The SPD and SAD entries are only example configurations. A particular mobile node implementation and a home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
このセクションでは、SPDとモバイルIPv6シグナリングメッセージを保護するために使用することができSADエントリについて説明します。 SPDとSADエントリは一例の構成です。特定のモバイルノードの実装とホームエージェントの実装は、限り、彼らはモバイルIPv6シグナリングメッセージの必要なセキュリティを提供するように、異なるSPDとSADエントリを設定することができます。
For the examples described in this document, a mobile node with home address, "home_address_1", primary care-of address, "care_of_address_1", a home agent with address, "home_agent_1" and a user of the mobile node with identity "user_1" are assumed. If the home address of the mobile node changes, the SPD and SAD entries need to be re-created or updated for the new home address.
この文書で説明する例については、ホームアドレスとモバイルノード、「home_address_1」、プライマリーケア-のアドレス、「care_of_address_1」、アドレスとホームエージェント、「home_agent_1」とアイデンティティを持つモバイルノードのユーザ「USER_1」想定しています。モバイルノードの変化のホームアドレス場合は、SPDとSADエントリは、新たなホームアドレスのために再作成または更新する必要があります。
The Peer Authorization Database is not used when manual IPsec configuration is used for setting up security associations for protecting Mobile IPv6 signaling messages.
手動IPsec構成は、モバイルIPv6シグナリングメッセージを保護するためのセキュリティアソシエーションを設定するために使用されている場合、ピア認証データベースが使用されていません。
The following are the SPD and SAD entries on the mobile node and the home agent to protect Binding Updates and Acknowledgements.
以下は、バインディング更新と謝辞を保護するために、モバイルノードとホームエージェントのSPDとSADエントリです。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = MH &
local_mh_type = BU & remote_mh_type = BAck
Then use SA SA1 (OUT) and SA2 (IN)
mobile node SAD: - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & mh_type = BU - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & mh_type = BAck
SADモバイルノード： - SA1（OUT、spi_a、home_agent_1、ESP、TRANSPORT）：local_address = home_address_1＆REMOTE_ADDRESS = home_agent_1＆プロト= MH＆mh_type = BU - SA2（IN、spi_b、home_address_1、ESP、TRANSPORT）：local_address = home_agent_1 ＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆mh_type =のBAck
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use SA SA2 (OUT) and SA1 (IN)
ホームエージェントSPD-S： - IF local_address = home_agent_1＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆local_mh_type =バック＆remote_mh_type = BUその後SA SA2（OUT）とSA1（IN）を使用します
home agent SAD: - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & mh_type = BAck - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & mh_type = BU
SADホームエージェント： - SA2（OUT、spi_b、home_address_1、ESP、TRANSPORT）：local_address = home_agent_1＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆mh_type =のBAck - SA1（IN、spi_a、home_agent_1、ESP、TRANSPORT）：local_address = home_address_1 ＆REMOTE_ADDRESS = home_agent_1＆プロト= MH＆mh_type = BU
The following are the SPD and SAD entries on the mobile node and the home agent to protect Return Routability messages.
以下は、リターンルータビリティメッセージを保護するために、モバイルノードとホームエージェントのSPDとSADエントリです。
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA SA3 (OUT) and SA4 (IN)
mobile node SAD: - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): local_address = home_address_1 & remote_address = any & proto = MH & mh_type = HoTi - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): local_address = any & remote_address = home_address_1 & proto = MH & mh_type = HoT
モバイルノードSAD： - SA3（OUT、spi_c、home_agent_1、ESP、トンネル）：local_address = home_address_1＆REMOTE_ADDRESS =あらゆる＆プロト= MH＆mh_type =のHoTi - SA4（IN、spi_d、care_of_address_1、ESP、トンネル）：local_address =任意の＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆mh_type =のHoT
home agent SPD-S: - IF remote_address = home_address_1 & local_address = any & proto = MH & local_mh_type = HoT & remote_mh_type = HoTi Then use SA SA4 (OUT) and SA3 (IN)
ホームエージェントSPD-S： - その後、SA SA4（OUT）とSA3（IN）を使用REMOTE_ADDRESS = home_address_1＆local_address =あらゆる＆プロト= MH＆local_mh_type =ホット＆remote_mh_type =のHoTiのIF
home agent SAD: - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): local_address = any & remote_address = home_address_1 & proto = MH & mh_type = HoT - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): local_address = home_address_1 & remote_address = any & proto = MH & mh_type = HoTi
ホームエージェントSAD： - SA4（OUT、spi_d、care_of_address_1、ESP、トンネル）：local_address =あらゆる＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆mh_type =のHoT - SA3（IN、spi_c、home_agent_1、ESP、トンネル）：local_address = home_address_1 ＆REMOTE_ADDRESS =あらゆる＆プロト= MH＆mh_type =のHoTi
The following are the SPD and SAD entries used to protect Mobile Prefix Discovery messages.
以下のモバイルプレフィックスディスカバリーメッセージを保護するために使用SPDとSADエントリです。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = ICMPv6 &
local_icmp6_type = MPS & remote_icmp6_type = MPA
Then use SA SA5 (OUT) and SA6 (IN)
mobile node SAD: - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & icmp6_type = MPA
モバイルノードSAD： - SA5（OUT、spi_e、home_agent_1、ESP、TRANSPORT）：local_address = home_address_1＆REMOTE_ADDRESS = home_agent_1＆プロト=のICMPv6＆icmp6_type = MPS - SA6（IN、spi_f、home_address_1、ESP、TRANSPORT）：local_address = home_agent_1 ＆REMOTE_ADDRESS = home_address_1＆プロト=のICMPv6＆icmp6_type = MPA
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & local_icmp6_type = MPA & remote_icmp6_type = MPS Then use SA SA6 (OUT) and SA5 (IN)
ホームエージェントSPD-S： - IF local_address = home_agent_1＆REMOTE_ADDRESS = home_address_1＆プロト=のICMPv6＆local_icmp6_type = MPA＆remote_icmp6_type = MPSは、次にSA SA6（OUT）とSA5（IN）を使用します
home agent SAD: - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & icmp6_type = MPA - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS
ホームエージェントSAD： - SA6（OUT、spi_f、home_address_1、ESP、TRANSPORT）：local_address = home_agent_1＆REMOTE_ADDRESS = home_address_1＆プロト=のICMPv6＆icmp6_type = MPA - SA5（IN、spi_e、home_agent_1、ESP、TRANSPORT）：local_address = home_address_1 ＆REMOTE_ADDRESS = home_agent_1＆プロト=のICMPv6＆icmp6_type = MPS
Regular payload traffic between the mobile node and the correspondent node tunneled through the home agent can be protected by IPsec, if required. The mobile node and the home agent use ESP in tunnel mode to protect the tunneled traffic. The SPD and SAD entries shown in Section 5.2.4 of [3] are applicable here.
必要に応じて、ホームエージェントを介してトンネルモバイルノードとコレスポンデントノード間の定期的なペイロードトラフィックは、IPSecで保護することができます。モバイルノードとホームエージェントは、トンネルトラフィックを保護するためにトンネルモードでESPを使用します。 [3]のセクション5.2.4に示すSPDとSADエントリはここで適用可能です。
This section describes the use of IKEv2 to set up the required security associations.
このセクションでは、必要なセキュリティアソシエーションをセットアップするのIKEv2の使用を記載しています。
The following describes PAD entries on the mobile node and the home agent. The PAD entries are only example configurations. Note that the PAD is a logical concept; a particular mobile node and a home agent can implement the PAD in an implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
以下は、モバイルノードとホームエージェント上のパッドのエントリについて説明します。 PADのエントリは、あくまでも一例の構成です。 PADが論理的な概念であることに注意してください。特定のモバイルノードとホームエージェントは、実装固有の方法でパッドを実装することができます。 PAD状態はまた、特定の実装に様々なデータベースに分散されてもよいです。
mobile node PAD:
- IF remote_identity = home_agent_identity_1
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address home_agent_1
home agent PAD: - IF remote_identity = user_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address home_address_1
ホームエージェントパッド： - IF remote_identity = USER_1次に認証（共有秘密/証明書/ EAP）とリモートアドレスhome_address_1のためのCHILD_SAsを承認
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上記の例の認証メカニズムのリストは網羅的ではありません。パッド内に格納された認証のために使用される他の資格情報があるかもしれません。
In case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address.
動的ホームアドレス割り当ての場合は、ホームエージェントは、認証されたピアのIDと新たに割り当てられたホームアドレスを結ぶ一時的なパッドのエントリを作成します。
The following sections describe the security policy entries on the mobile node and the home agent. The SPD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
次のセクションでは、モバイルノードとホームエージェントのセキュリティポリシーエントリを記述します。 SPDエントリは一例の構成です。特定のモバイルノードの実装とホームエージェントの実装は、限り、彼らはモバイルIPv6シグナリングメッセージの必要なセキュリティを提供して別のSPDエントリを設定することができます。
In the examples shown below, the identity of the user of the mobile node is assumed to be user_1, the home address of the mobile node is assumed to be home_address_1, the primary care-of address of the mobile node is assumed to be care_of_address_1, and the IPv6 address of the Home Agent is assumed to be home_agent_1.
以下に示す実施例では、移動ノードのユーザのアイデンティティをUSER_1であると仮定され、モバイルノードのホームアドレスをhome_address_1されているものと、一次気付モバイルノードのアドレスは、care_of_address_1であると仮定されますそして、ホームエージェントのIPv6アドレスがhome_agent_1されているものとします。
The following are the SPD entries on the mobile node and the home agent for protecting Binding Updates and Acknowledgements.
モバイルノードとの結合更新と謝辞を保護するためのホームエージェントのSPDエントリは以下のとおりです。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use SA ESP transport mode
ホームエージェントSPD-S： - IF local_address = home_agent_1＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆local_mh_type =バック＆remote_mh_type = BUは、次にSA ESPトランスポートモードを使用します
In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might not have configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address.
上図の例では、モバイルノードのホームアドレスは、すべての時間を利用できない場合があります。例えば、モバイルノードは、まだホームアドレスを構成していない可能性があります。モバイルノードは、新しいホームアドレスを取得すると、それは対応するSPDエントリにアドレスを追加したり、自宅の住所のためのSPDエントリを作成する必要があります。
The home agent should have named SPD entries per mobile node, based on the identity of the mobile node. The identity of the mobile node is stored in the "Name" selector in the SPD [5]. The home address presented by the mobile node during the IKE negotiation is stored as the remote IP address in the resultant IPsec security associations. If the mobile node dynamically configures a home agent and the home address, the home agent may not know which mobile nodes it is supposed to be serving. Therefore, the home agent cannot have SPD entries configured per mobile node. Instead, the home agent should have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. Once a mobile node authenticates to the home agent and configures a home address, appropriate SPD entries are created for the mobile node.
ホームエージェントは、モバイルノードのIDに基づいて、モバイルノードあたりのSPDエントリを命名している必要があります。モバイルノードのアイデンティティは、SPD [5]における「名前」セレクタに格納されます。 IKEネゴシエーションの間に、モバイルノードによって提示されたホームアドレスは、得られたIPsecセキュリティアソシエーションでのリモートIPアドレスとして格納されています。モバイルノードが動的にホームエージェントとホームアドレスを設定する場合は、ホームエージェントは、それが提供されると想定されるモバイルノード知らないかもしれません。したがって、ホームエージェントは、モバイルノードごとに設定SPDエントリを持つことができません。代わりに、ホームエージェントは、IPsecフィルタをバイパスからのIPsec保護を必要とするモビリティヘッダのトラフィックを防ぐために、一般的なSPDエントリを持つ必要があります。モバイルノードがホームエージェントに認証し、ホームアドレスを設定したら、適切なSPDエントリは、モバイルノードのために作成されます。
The Mobility Header message type is negotiated by placing it in the most significant eight bits of the 16-bit local "port" selector during IKEv2 exchange. For more details, refer to [5]. The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For the sake of brevity, we show only those values that are relevant for Mobile IPv6.
モビリティヘッダのメッセージタイプは、IKEv2の交換中に、16ビットのローカル「ポート」セレクタの最上位8ビットにそれを置くことによってネゴシエートされます。詳細については、[5]を参照。上記の例でをTSiおよびTSrをペイロードはhome_address_1から離れて他の多くのセレクタを含むことになります。簡潔にするために、我々はモバイルIPv6に関連するだけでそれらの値を示しています。
The following are the SPD entries on the mobile node and the home agent for protecting the Return Routability messages.
モバイルノードとリターンルータビリティのメッセージを保護するためのホームエージェントのSPDエントリは以下のとおりです。
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S: - IF local_address = any & remote_address = home_address_1 & proto = MH & local_mh_type = HoT & remote_mh_type = HoTi Then use SA ESP tunnel mode
ホームエージェントSPD-S： - IF local_address =あらゆる＆REMOTE_ADDRESS = home_address_1＆プロト= MH＆local_mh_type =ホット＆remote_mh_type =のHoTi次に使うSA ESPトンネルモード
When the mobile node's care-of address changes, the SPD entries on both the mobile node and the home agent must be updated. The home agent knows about the change in care-of address of the mobile node when it receives a Binding Update from the mobile node.
場合は、モバイルノードの気付アドレスの変更、移動ノードとホームエージェントの両方で、SPDエントリを更新する必要があります。それは、モバイルノードからバインディングアップデートを受信したときにホームエージェントは、モバイルノードの気付アドレスの変更を知っています。
The following are the SPD entries on the mobile node and the home agent for protecting Mobile Prefix Discovery messages.
モバイルノードとモバイルプレフィックスディスカバリーメッセージを保護するためのホームエージェントのSPDエントリは以下のとおりです。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & local_icmp6_type = MPS &
remote_icmp6_type = MPA
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & local_icmp6_type = MPA & remote_icmp6_type = MPS Then use SA ESP transport mode
ホームエージェントSPD-S： - IF local_address = home_agent_1＆REMOTE_ADDRESS = home_address_1＆プロト=のICMPv6＆local_icmp6_type = MPA＆remote_icmp6_type = MPSは、次にSA ESPトランスポートモードを使用します
In the examples shown above, the home address of the mobile node might not be available all the time. When the mobile node acquires a new home address, it must add the address to the corresponding SPD entries.
上図の例では、モバイルノードのホームアドレスは、すべての時間を利用できない場合があります。モバイルノードは、新しいホームアドレスを取得すると、それは対応するSPDエントリにアドレスを追加する必要があります。
The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For brevity, they are not shown here.
上記の例でをTSiおよびTSrをペイロードはhome_address_1から離れて他の多くのセレクタを含むことになります。簡潔にするために、彼らはここでは示されていません。
The following are the SPD entries on the mobile node and the home agent if payload traffic exchanged between the mobile node and its Correspondent Node needs to be protected. The SPD entries are similar to the entries for protecting Return Routability messages and have lower priority than the above SPD entries.
ペイロードトラフィックは、モバイルノード間で交換し、その相手ノードを保護する必要がある場合は、以下では、モバイルノードとホームエージェントのSPDエントリです。 SPDエントリは、リターン・ルータビリティ・メッセージを保護するためのエントリと同様であり、上記SPDエントリよりも低い優先順位を有します。
mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & proto = X
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X Then use SA ESP tunnel mode
ホームエージェントSPD-S： - ホームアドレス1とソースへのインタフェース= IPv6トンネル=＆任意の宛先=ホームADDRESS_1＆プロト= Xそして使用SA ESPトンネルモードIF
Mobile IPv6 signaling messages are typically initiated by the mobile node. The mobile node sends a Binding Update to the home agent whenever it moves and acquires a new care-of address.
モバイルIPv6シグナリングメッセージは、典型的には、モバイルノードによって開始されます。それは移動して、新たな気付アドレスを取得するたびに、モバイルノードは、ホームエージェントにバインディングアップデートを送信します。
The mobile node initiates an IKEv2 protocol exchange if the required security associations are not present. A possible mechanism used for mutual authentication is a shared secret between the mobile node and the home agent. The home agent uses the identity of the mobile node to identify the corresponding shared secret. When a public-key-based mechanism is available, it should be the preferred mechanism for mutual authentication.
必要なセキュリティアソシエーションが存在しない場合、モバイルノードは、IKEv2のプロトコル交換を開始します。相互認証のために使用可能なメカニズムは、モバイルノードとホームエージェント間の共有秘密です。ホームエージェントは、対応する共有秘密を識別するために、モバイルノードのIDを使用しています。公開鍵ベースのメカニズムが利用可能な場合、それは、相互認証のための好適なメカニズムである必要があります。
If a shared secret is being used, the mobile node uses the shared secret to generate the AUTH payload in the IKE_AUTH exchange. If the mobile node is using a public-key-based mechanism, then it uses its private key to generate the AUTH payload in the IKE_AUTH exchange.
共有秘密が使用されている場合、モバイルノードは、IKE_AUTH交換においてAUTHペイロードを生成するために共有秘密を使用します。モバイルノードは、公開鍵ベースのメカニズムを使用している場合、それはIKE_AUTH交換にAUTHペイロードを生成するために、その秘密鍵を使用しています。
Mobile Node Home Agent
----------- ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
< - HDR、SAR1、KER、Nrと、[CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} -->
HDR、SK {IDI、[CERT、] [CERTREQ] [IDR】認証、SAI2とTSR} - >
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The mobile node always includes its identity in the IDi payload in the IKE_AUTH exchange. The mobile node could use the following different types of identities to identify itself to the home agent.
モバイルノードは、常にIKE_AUTH交換でのIDIペイロードでの識別を含みます。モバイルノードは、ホームエージェントに自分自身を識別するために、アイデンティティの以下の異なる種類を使用することができます。
o Home Address - The mobile node could use its statically configured home address as its identity. In this case the ID Type field is set to ID_IPV6_ADDR.
Oのホームアドレス - モバイルノードがそのIDとその静的に設定されたホームアドレスを使用することができます。この場合、ID TypeフィールドがID_IPV6_ADDRに設定されています。
o FQDN - The mobile node can use a Fully Qualified Domain Name as the identifier and set the ID Type field to ID_FQDN.
O FQDN - モバイルノードが識別子として完全修飾ドメイン名を使用してID_FQDNにID Typeフィールドを設定することができます。
o RFC 822 identifier - If the mobile node uses a RFC 822 identifier [9], it sets the ID Type field to ID_RFC822_ADDR.
O RFC 822識別子 - モバイルノードがRFC 822の識別子を使用している場合は、[9]、それはID_RFC822_ADDRにID Typeフィールドを設定します。
The above list of identities is not exhaustive.
アイデンティティの上記のリストは網羅的なものではありません。
In the IKE_AUTH exchange, the mobile node includes the home address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate IPsec security associations for protecting the Binding Update and Binding Acknowledgement messages. The mobile node MAY use a range of selectors that includes the mobility message types for Binding Update and Binding Acknowledgement to use the same pair of IPsec security associations for both messages.
IKE_AUTH交換において、モバイルノードはホームアドレスとバインディングアップデートを保護し、応答メッセージを結合するためのIPsecセキュリティアソシエーションをネゴシエートするをTSi（トラフィックセレクタイニシエータ）ペイロードに適切なセレクタを含みます。モバイルノードは、バインディング更新、両方のメッセージにIPsecセキュリティアソシエーションの同じ組を使用する肯定応答を結合するためのモビリティメッセージタイプを含むセレクタの範囲を使用するかもしれません。
After the IKE_AUTH exchange completes, the mobile node initiates CREATE_CHILD_SA exchanges to negotiate additional security associations for protecting Return Routability signaling, Mobile Prefix Discovery messages, and (optionally) payload traffic. The CREATE_CHILD_SA exchanges are protected by IKEv2 security associations created during the IKE_SA_INIT exchange. If a correspondent node, that is also a mobile node, initiates the return routability exchange, then the home agent initiates the CREATE_CHILD_SA exchange to negotiate security associations for protecting Return Routabilty messages.
IKE_AUTH交換が完了した後、モバイルノードは、リターン・ルータビリティシグナリング、モバイルプレフィックス探索メッセージ、および（オプション）ペイロードトラフィックを保護するための追加のセキュリティアソシエーションをネゴシエートするCREATE_CHILD_SA交換を開始します。 CREATE_CHILD_SA交換はIKE_SA_INIT交換中に作成されたのIKEv2セキュリティアソシエーションにより保護されています。また、モバイルノードであるコレスポンデントノードは、リターン・ルータビリティ・交換を開始する場合は、ホームエージェントはリターンRoutabiltyメッセージを保護するためのセキュリティアソシエーションをネゴシエートするCREATE_CHILD_SA交換を開始します。
It is important that the security associations are created based on the home address of the mobile node, so that the security associations survive care-of address change. The mobile node MUST use its home address as the initiator IP address in the TSi payload in the CREATE_CHILD_SA exchange in order to create the IPsec security associations for the home address.
セキュリティアソシエーションが気付アドレスの変更を生き残るように、セキュリティアソシエーションは、モバイルノードのホームアドレスに基づいて作成されていることが重要です。モバイルノードは、ホームアドレスのためのIPsecセキュリティアソシエーションを作成するために、CREATE_CHILD_SA交換中のTSIペイロードのイニシエータのIPアドレスとしてそのホームアドレスを使用する必要があります。
Mobile Node Home Agent
----------- ----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
When PKI-based authentication is used between the mobile node and the Home Agent, the identity presented by the mobile node in the IDi payload MUST correspond to the identity in the certificate obtained by the Home Agent. The home agent uses the identity presented in the IDi payload to lookup the policy and the certificate that corresponds to the mobile node. If the mobile node presents its home address in the IDi payload, then the home agent MUST verify that the home address matches the address in an iPAddress field in the SubjectAltName extension [8].
PKIベースの認証は、モバイルノードとホームエージェントとの間で使用される場合、IDIペイロード内のモバイルノードによって提示されたアイデンティティは、ホームエージェントによって取得した証明書のIDに対応しなければなりません。ホームエージェントは、ポリシーおよびモバイルノードに対応する証明書を検索するためのIDIペイロードに提示アイデンティティを使用しています。モバイルノードがIDiとペイロードにおけるそのホームアドレスを提示した場合、ホームエージェントは、ホームアドレスはsubjectAltName拡張[8]にIPアドレス欄にアドレスと一致することを確かめなければなりません。
When the mobile node uses its home address in the IDi field, implementations are not required to match the source address in the outermost IP header with the IP address in the IDi field. According to RFC 4306 [4], the IP header fields in the IKEv2 messages are ignored and used only in the IP headers for IKEv2 messages sent as replies.
モバイルノードは、IDiをフィールドにそのホームアドレスを使用する場合、実装は、のIDIフィールドにIPアドレスを持つ最も外側IPヘッダの送信元アドレスと一致する必要はありません。 RFC 4306によると[4]のIKEv2メッセージにおけるIPヘッダフィールドは無視され、返信として送信されるのIKEv2メッセージのIPヘッダにのみ使用されます。
If the mobile node moves and its care-of address changes, the IKEv2 SA might not be valid. RFC 3775 defines a mechanism based on the successful exchange of Binding Update and Binding Acknowledgement messages. The mobile node establishes the IKE SA with the home agent using its primary care-of address. The IKE SA endpoints are updated on the home agent when it receives the Binding Update from the mobile node's new care-of address and on the mobile node when it sends the Binding Update to the home agent or when it receives the Binding acknowledgement sent by the home agent. This capability to change IKE endpoints is indicated through setting the Key Management Capability (K) flag [2] in the Binding Update and Binding Acknowledgement messages. If the mobile node or the home agent does not support this capability, and has no other means to update the addresses, then an IKEv2 exchange MUST be initiated to re-establish a new IKE SA.
モバイルノードが移動すると、その気付アドレスを変更した場合、IKEv2のSAは有効ではないかもしれません。 RFC 3775は、アップデートをバインドし、受信確認メッセージをバインディングの成功交換に基づいてメカニズムを定義します。モバイルノードは、そのプライマリケア-のアドレスを使用して、ホームエージェントとのIKE SAを確立します。それはホームエージェントにバインディングアップデートを送信するとき、またはそれがによって送られたバインディング確認応答を受信したとき、それは、モバイルノードの新しい気付アドレスから、モバイルノードにバインディングアップデートを受信したときに、IKE SAのエンドポイントはホームエージェントに更新されていますホームエージェント。 IKEエンドポイントを変更するこの能力は、結合更新でキー管理能力（K）フラグ[2]を設定し、応答メッセージを結合することによって示されています。モバイルノードまたはホームエージェントは、この機能をサポートし、アドレスを更新する他の手段を持っていないしていない場合、IKEv2の交換は新しいIKE SAを再確立するために開始されなければなりません。
In addition to using public key signatures and shared secrets, EAP [10] can be used with IKEv2 for authenticating the mobile node to the home agent.
公開鍵署名と共有秘密を使用することに加えて、EAP [10]ホームエージェントにモバイルノードを認証するためのIKEv2と共に使用することができます。
The mobile node indicates that it wants to use EAP by including the IDi payload but leaving out the AUTH payload in the first message during the IKE_AUTH exchange. The home agent then includes an EAP payload if it is willing to use an extensible authentication method. Security associations are not created until the subsequent IKE_AUTH exchange after successful EAP authentication. The use of EAP adds at least two round trips to the IKE negotiation. The number of round trips depends on the EAP method used.
モバイルノードは、それがのIDIペイロードを含むがIKE_AUTH交換中に最初のメッセージでAUTHペイロードを残してEAPを使用したいことを示しています。拡張可能な認証方法を使用して喜んでいる場合は、ホームエージェントは、EAPペイロードを含んでいます。セキュリティアソシエーションが成功したEAP認証の後、後続のIKE_AUTH交換するまで作成されません。 EAPを使用すると、IKEネゴシエーションに少なくとも2回の往復が追加されます。ラウンドトリップの数は、使用されるEAP方式に依存します。
Mobile Node Home Agent
------------ ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
< - HDR、SAR1、KER、Nrと、[CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr}-->
HDR、SK {IDI、[CERTREQ] [IDR] SAI2とTSR} - >
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP }
.
.
.
HDR, SK {EAP} -->
HDR、SK {EAP} - >
<-- HDR, SK {EAP (success)}
< - HDR、SK {EAP（成功）}
HDR, SK {AUTH} -->
HDR、SK {AUTH} - >
<-- HDR, SK {AUTH, SAr2, TSi,
TSr}
When EAP is used, the identity presented by the mobile node in the IDi field may not be the actual identity of the mobile node. It could be set to an identity that is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting the right EAP method. It is possible that the actual identity is carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document.
EAPを使用する場合、IDIフィールドに移動ノードによって提示されたアイデンティティは、モバイルノードの実際の同一ではないかもしれません。それだけで、認証、許可、アカウンティング（AAA）は、目的ルーティングと右EAPメソッドを選択するために使用される同一に設定することができます。実際のアイデンティティがホームエージェントに見えない、EAPの内側に搭載されている可能性があります。 IKEv2のは、EAPアイデンティティ要求/応答メッセージ交換を許可していませんが、EAPメソッドは、自分自身の中にアイデンティティを交換してもよいです。この場合、ホームエージェントは、対応するAAAサーバからモバイルノードのIDを取得する必要があります。どのようにホームエージェントは、モバイルノードのIDを取得することは、この文書の範囲外です。
Some EAP methods, when used with IKEv2, generate a shared key on the mobile node and the Home Agent once the EAP authentication succeeds. This shared key is used to generate the AUTH payloads in the subsequent IKEv2 messages. The shared key, if used to generate the AUTH payloads, MUST NOT be used for any other purpose. For more details, refer to [4].
EAP認証が成功したら、いくつかのEAPメソッドは、IKEv2のに使用された場合、モバイルノード上の共有キーとホームエージェントを生成します。この共有キーは、後続のIKEv2メッセージでAUTHペイロードを生成するために使用されます。共有キーは、AUTHペイロードを生成するために使用される場合は、他の目的に使用してはいけません。詳細については、[4]を参照。
The use of EAP between the mobile node and the home agent might require the home agent to contact an authorization server like the AAA Home server, on the home link, to authenticate the mobile node. Please refer to [7] for more details.
モバイルノードとホームエージェント間のEAPの使用は、移動ノードを認証するために、ホームリンク上で、AAAホームサーバなどの認証サーバーに接続するために、ホームエージェントが必要な場合があります。詳細については、[7]を参照してください。
The mobile node can dynamically configure a home address by including a Configuration Payload in the IKE_AUTH exchange, with a request for an address from the home link. The mobile node should include a zero-length INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The mobile node MAY include multiple instances of the INTERNAL_IP6_ADDRESS to request multiple home address to the assigned by the home agent.
モバイルノードは、動的ホームリンクからアドレスの要求で、IKE_AUTH交換で設定ペイロードを含むことにより、ホームアドレスを設定することができます。モバイルノードは、CFG_REQUESTペイロードにゼロ長INTERNAL_IP6_ADDRESS属性を含むべきです。モバイルノードは、ホームエージェントによって割り当てに複数のホームアドレスを要求するINTERNAL_IP6_ADDRESSの複数のインスタンスを含むかもしれません。
When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY contains the prefix length of the home prefix in addition to a 128 bit home address. The home agent could use a local database or contact a DHCPv6 server on the home link to allocate a home address. The duration for which the home address is allocated to the mobile node is the same as the duration for which an IKEv2 security association exists between the mobile node and the home agent. If the IKEv2 security association is rekeyed, the home address lifetime is also extended.
ホームエージェントはINTERNAL_IP6_ADDRESSためCFG_REQUESTで設定ペイロードを受信すると、モバイルノードのための有効なホームアドレスで応答します。 CFG_REPLYでINTERNAL_IP6_ADDRESS属性は、128ビットのホームアドレスに加えて、ホームプレフィックスのプレフィックス長が含まれています。ホームエージェントはホームアドレスを割り当てるためにローカルデータベースを使用するか、ホームリンクでDHCPv6サーバに接続できます。ホームアドレスは、モバイルノードに割り当てられている期間は、IKEv2のセキュリティアソシエーションがモバイルノードとホームエージェントとの間に存在する期間と同じです。 IKEv2のセキュリティアソシエーションが再 - 合わせされている場合は、ホームアドレスの有効期間も延長されます。
Mobile Node Home Agent
----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr}
-->
<-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2,
TSi, TSr}
The mobile node could suggest a home address that it wants to use in the CFG_REQUEST. For example, this could be a home address that was allocated for the mobile node before or an address that the mobile node auto-configured from the IPv6 prefix on the home link. The Home Agent could let the mobile node use the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same home address. If the home agent wants the mobile node to use a different home address, it sends a new home address in the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile Node MUST stop using its old home address and start using the newly allocated home address.
モバイルノードは、それがCFG_REQUESTで使用したいホームアドレスを提案することができます。たとえば、これは前にモバイルノードまたはモバイルノードがホームリンク上のIPv6プレフィックスから自動設定されたアドレスのために割り当てられていた自宅の住所である可能性があります。ホームエージェントは、モバイルノードが同じホームアドレスにCFG_REPLYペイロードでINTERNAL_IP6_ADDRESS属性を設定することで、同じホームアドレスを使用してみましょうことができます。ホームエージェントが異なるホームアドレスを使用するように、モバイルノードを望んでいるなら、それはCFG_REPLYペイロードでINTERNAL_IP6_ADDRESS属性に新しいホームアドレスを送信します。モバイルノードは、その旧ホームアドレスの使用を停止し、新たに割り当てられたホームアドレスを使用して起動する必要があります。
In case the home agent is unable to allocate a home address for the mobile node during the IKE_AUTH exchange, it MUST send a Notify Payload with an INTERNAL_ADDRESS_FAILURE message. When the mobile node receives a Notify Payload with an INTERNAL_ADDRESS_FAILURE message, it SHOULD terminate the IKE_AUTH exchange. The mobile node then should initiate a new IKE_SA_INIT and IKE_AUTH exchange and try to auto-configure a home address as described in [13]. The mobile node MAY also switch to another home agent. The new home agent address can be obtained by consulting a home agent list received during a previous home agent discovery phase or, if such list is empty or not available, by attempting a new home agent discovery.
ホームエージェントはIKE_AUTH交換中に、モバイルノードのホームアドレスを割り当てることができない場合は、INTERNAL_ADDRESS_FAILUREメッセージで通知ペイロードを送らなければなりません。モバイルノードがINTERNAL_ADDRESS_FAILUREメッセージで通知ペイロードを受信すると、IKE_AUTH交換を終了すべきです。モバイルノードは、新しいIKE_SA_INIT及びIKE_AUTH交換を開始し、[13]で説明したように自動設定するには、ホームアドレスを試してみてください。モバイルノードは、別のホームエージェントに切り換えることができます。新しいホーム・エージェント・アドレスは、ホームエージェントのリストを調べることによって得ることができ、そのようなリストは、新しいホームエージェント発見を試みることによって、空または利用できない場合は、前回のホームエージェント発見フェーズ中に受信しましたか。
If the mobile node wants to configure a DNS server from the home link, it can request the DNS server information by including an INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload.
モバイルノードがホームリンクからDNSサーバを設定したい場合、それはCFG_REQUESTペイロードでINTERNAL_IP6_DNS属性を含めることによって、DNSサーバーの情報を要求することができます。
This document describes how IPsec can be used to secure Mobile IPv6 signaling messages. Please refer to RFC 3775 [2] for security considerations related to the use of IPsec with Mobile IPv6.
この文書では、IPsecはモバイルIPv6シグナリングメッセージを保護するために使用する方法について説明します。モバイルIPv6でのIPsecの使用に関連するセキュリティ上の考慮事項については、RFC 3775 [2]を参照してください。
A misbehaving mobile node could create IPsec security associations for a home address that belongs to another mobile node. Therefore, the home agent should check if a particular mobile node is authorized to use a home address before creating IPsec security associations for the home address. If the home address is assigned as described in Section 9, the home agent MUST associate the home address with the identity used in IKE negotiation. The home agent MAY store the assigned home address in the SPD entries created for the mobile node.
ふらちなモバイルノードは、他の移動ノードに属しているホームアドレスのIPsecセキュリティアソシエーションを作成することができます。特定の移動ノードがホームアドレスのためのIPsecセキュリティアソシエーションを作成する前に、ホームアドレスの使用を許可されている場合はそのため、ホームエージェントがチェックする必要があります。第9章で説明したようにホームアドレスが割り当てられている場合、ホームエージェントは、IKEネゴシエーションで使用するIDを持つホームアドレスを関連付ける必要があります。ホームエージェントは、モバイルノード用に作成されたSPDエントリに割り当てられたホームアドレスを格納することができます。
The use of EAP for authenticating the mobile node to the home agent is described in Section 8. Security considerations related to the use of EAP with IKEv2 are described in [4].
ホームエージェントにモバイルノードを認証するためのEAPの使用は、セクションに記載されているのIKEv2とEAPの使用に関連する8セキュリティ問題は、[4]に記載されています。
The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari Arkko, Gerardo Giaretta, Shinta Sugimoto, Tero Kivinen, Steve Bellovin, Kilian Weniger, and Vijay Gurbani for reviewing the document.
著者は、文書をレビューするミカJoutsenvirta、パシEronen、ヤリArkko、ヘラルド・Giaretta、信太杉本、TERO Kivinen、スティーブBellovin氏、キリアンWeniger、およびビジェイGurbaniに感謝したいと思います。
Many of the requirements listed in Section 4 are copied from RFC 3776. Therefore, the authors of RFC 3776 are acknowledged.
第4章に記載されている要件の多くは、したがってRFC 3776.からコピーされ、RFC 3776の作者は認めています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[3] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月を。
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[4]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[5]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[6]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[7] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress, September 2006.
進歩、2006年9月[7] Giaretta、G.、 "モバイルIPv6のためのAAAの目標"、仕事。
[8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
[8]コーバー、B.、進歩、2007年2月ワーク "のIKEv1 / ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロファイル"。
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[9]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[10] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[11]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Work in Progress, September 2006.
[12]杉本、S.、 "モバイルIPv6とIPsec / IKEとの間のインターフェイスとしてPF_KEY拡張"、進歩、2006年9月での作業。
[13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", Work in Progress, December 2006.
[13] Giaretta、G.、 "分割シナリオにおけるモバイルIPv6ブートストラップ"、進歩、2006年12月に作業。
Authors' Addresses
著者のアドレス
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireネットワーク3121ジェイ・ストリートサンタクララ、CA 95054 USA
EMail: vijay.devarapalli@azairenet.com
メールアドレス：vijay.devarapalli@azairenet.com
Francis Dupont CELAR
フランシスデュポン隠します
EMail: Francis.Dupont@fdupont.fr
メールアドレス：Francis.Dupont@fdupont.fr
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。