Network Working Group J. Arkko
Request for Comments: 3776 Ericsson
Category: Standards Track V. Devarapalli
Nokia Research Center
F. Dupont
GET/ENST Bretagne
June 2004
Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents
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 Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
モバイルIPv6は、ホームエージェントとモバイルノード間のシグナリングを保護するためにIPsecを使用しています。モバイルIPv6ベースの文書は、これらのノードが従わなければならない主な要件を定義します。この文書は、より深さでこれらの要件を議論使用されるパケットフォーマットを示し、適切な設定手順を説明し、かつ実装が正しい順序でパケットを処理する方法を示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
This document illustrates the use of IPsec in securing Mobile IPv6 [7] traffic between mobile nodes and home agents. In Mobile IPv6, a mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node's home link.
この文書では、モバイルノードとホームエージェントとの間のモバイルIPv6 [7]のトラフィックを確保する上でのIPsecの使用を示します。モバイルIPv6では、モバイル・ノードは、常にそれが現在、ホームリンクに貼ったり、ホームから離れているされているかどうか、そのホームアドレスにアドレス指定可能であることが予想されます。 「ホームアドレス」はそのホームリンク上のホームサブネットプレフィックス内の移動ノードに割り当てられたIPアドレスです。モバイルノードがホームにあるものの、そのホームアドレス宛のパケットは、モバイルノードのホームリンクにルーティングされます。
While a mobile node is attached to some foreign link away from home, it is also addressable at a care-of address. A care-of address is an IP address associated with a mobile node that has a subnet prefix from a particular foreign link. The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message.
モバイルノードがホームから離れて、いくつかの外部リンクに接続されているが、それはまた気付アドレスにアドレス指定されます。気付アドレスは、特定の外部リンクからサブネット・プレフィックスを有するモバイルノードに関連付けられたIPアドレスです。モバイルノードのホームアドレスと気付アドレスとの関連付けは、モバイルノードのための「結合」として知られています。家から離れている間、モバイルノードは、モバイルノードのための「ホームエージェント」として機能するように、このルータを要求し、そのホームリンク上のルータで、その主気付アドレスを登録します。モバイルノードは、ホームエージェントに「バインディングアップデート」メッセージを送信することにより、このバインディング登録を行います。ホームエージェントは、「バインディング確認」メッセージを返すことによって、モバイルノードに応答します。
Any other nodes communicating with a mobile node are referred to as "correspondent nodes". Mobile nodes can provide information about their current location to correspondent nodes, again using Binding Updates and Acknowledgements. Additionally, return routability test is performed between the mobile node, home agent, and the correspondent node in order to authorize the establishment of the binding. Packets between the mobile node and the correspondent node are either tunneled via the home agent, or sent directly if a binding exists in the correspondent node for the current location of the mobile node.
モバイルノードと通信する任意の他のノードは、「先ノード」と呼ばれます。モバイルノードは、バインディング更新と謝辞を用いて再度、コレスポンデントノードへの現在位置に関する情報を提供することができます。また、リターン・ルータビリティ・テストは、結合の設立を認可するために、モバイルノード、ホームエージェント、およびコレスポンデントノードとの間で行われます。モバイルノードおよびコレスポンデント・ノードの間のパケットがいずれかのホーム・エージェントを介してトンネリングされ、または結合は、モバイルノードの現在の位置のためのコレスポンデントノードに存在する場合に直接送られます。
Mobile IPv6 tunnels payload packets between the mobile node and the home agent in both directions. This tunneling uses IPv6 encapsulation [6]. Where these tunnels need to be secured, they are replaced by IPsec tunnels [2].
モバイルIPv6は、モバイルノードと両方向のホームエージェントとの間のペイロード・パケットをトンネリングします。このトンネルは、IPv6カプセル化を使用する[6]。これらのトンネルを確保する必要がある場合、それらは、IPsecトンネルによって置き換えられている[2]。
Mobile IPv6 also provides support for the reconfiguration of the home network. Here, the home subnet prefixes may change over time. Mobile nodes can learn new information about home subnet prefixes through the "prefix discovery" mechanism.
モバイルIPv6は、ホームネットワークの再構成のためのサポートを提供します。ここでは、ホームサブネットプレフィックスは、時間の経過とともに変化することがあります。モバイルノードは、「接頭辞発見」メカニズムを介してホームサブネットプレフィックスについての新しい情報を学ぶことができます。
This document discusses security mechanisms for the control traffic between the mobile node and the home agent. If this traffic is not protected, mobile nodes and correspondent nodes are vulnerable to man-in-the-middle, hijacking, passive wiretapping, impersonation, and denial-of-service attacks. Any third parties are also vulnerable to denial-of-service attacks, for instance if an attacker could direct the traffic flowing through the home agent to a innocent third party. These attacks are discussed in more detail in Section 15.1 of the Mobile IPv6 base specification [7].
この文書では、モバイルノードとホームエージェント間の制御トラフィック用のセキュリティメカニズムについて説明します。このトラフィックが保護されていない場合は、モバイルノードとコレスポンデントノードは、イン・ザ・ミドル男-、ハイジャック、受動的な盗聴、なりすまし、およびサービス拒否攻撃に対して脆弱です。攻撃者は無実の第三者にホームエージェントを流れるトラフィックを指示することができれば、任意の第三者は、例えば、また、サービス拒否攻撃に対して脆弱です。これらの攻撃は、モバイルIPv6の基本仕様[7]のセクション15.1でより詳細に議論されます。
In order to avoid these attacks, the base specification uses IPsec Encapsulating Security Payload (ESP) [3] to protect control traffic between the home agent and the mobile node. This control traffic consists of various messages carried by the Mobility Header protocol in IPv6 [5]. The traffic takes the following forms:
これらの攻撃を避けるために、基本仕様は、IPsecカプセル化セキュリティペイロード（ESP）を使用しています[3]ホームエージェントとモバイルノード間の制御トラフィックを保護しています。この制御トラフィックは、IPv6 [5]にモビリティヘッダプロトコルによって運ばれる様々なメッセージで構成されています。トラフィックは、次の形式をとります。
o Binding Update and Acknowledgement messages exchanged between the mobile node and the home agent, as described in Sections 10.3.1, 10.3.2, 11.7.1, and 11.7.3 of the base specification [7].
Oバインディング更新肯定応答メッセージは、セクション10.3.1、10.3.2、11.7.1に記載されているように、モバイルノードとホームエージェントの間で交換し、基本仕様[7]の11.7.3。
o Return routability messages Home Test Init and Home Test that pass through the home agent on their way to a correspondent node, as described in Section 10.4.6 of the base specification [7].
基本仕様のセクション10.4.6に記載されているように、コレスポンデントノードへの途中でホームエージェントを通過Oリターン・ルータビリティ・メッセージホーム試験開始とホーム試験[7]。
o ICMPv6 messages exchanged between the mobile node and the home agent for the purposes of prefix discovery, as described in Sections 10.6 and 11.4 of the base specification [7].
セクション10.6ベース仕様の11.4に記載されているようにO ICMPv6メッセージは、[7]、プレフィックス発見の目的のために、モバイルノードとホームエージェントの間で交換しました。
The nodes may also optionally protect payload traffic passing through the home agent, as described in Section 5.5 of the base specification [7]. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection support is required.
基本仕様のセクション5.5に記載したように、ノードはまた、必要に応じて[7]、ホーム・エージェントを通過するペイロードトラフィックを保護することができます。マルチキャストグループメンバーシップの制御プロトコルまたはステートフルアドレス自動設定プロトコルがサポートされている場合は、ペイロードデータ保護のサポートが必要です。
The control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and anti-replay protection. The mobile node and the home agent must have an IPsec security association to protect this traffic. IPsec does not proving correct ordering of messages. Correct ordering of the control traffic is ensured by a sequence number in the Binding Update and Binding Acknowledgement messages. The sequence number in the Binding Updates also provides protection to a certain extent. It fails in some scenarios, for example, if the Home Agent loses the Binding Cache state. Full protection against replay attacks is possible only when IKE is used.
モバイルノードとホームエージェントとの間の制御トラフィックは、メッセージ認証、完全性、正確発注及びアンチリプレイ保護を必要とします。モバイルノードとホームエージェントは、このトラフィックを保護するためのIPsecセキュリティアソシエーションを持っている必要があります。 IPsecは、メッセージの正しい順序を証明していません。制御トラフィックの正しい順序は、バインディング更新と結合確認メッセージ内のシーケンス番号によって保証されます。バインディングアップデート内のシーケンス番号はまた、ある程度の保護を提供します。ホームエージェントはバインディングキャッシュの状態を失った場合には、例えば、いくつかのシナリオで失敗します。リプレイ攻撃に対する完全な保護は、IKEが使用されている場合にのみ可能です。
Great care is needed when using IKE [4] to establish security associations to Mobile IPv6 home agents. The right kind of addresses must be used for transporting IKE. This is necessary to avoid circular dependencies in which the use of a Binding Update triggers the need for an IKE exchange that cannot complete prior to the Binding Update having been completed.
IKEを使用する場合に細心の注意を[4]モバイルIPv6のホームエージェントにセキュリティアソシエーションを確立するために必要とされます。アドレスの正しい種類は、IKEを輸送するために使用する必要があります。これは、バインディングアップデートの使用は事前バインディング更新が完了されていたことに完了することはできませんIKE交換の必要性をトリガするに循環依存を回避する必要があります。
The mobile IPv6 base document defines the main requirements the mobile nodes and home agents must follow when securing the above traffic. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
モバイルIPv6ベースの文書は、上記のトラフィックを保護する際に、モバイルノードとホームエージェントが従わなければならない主な要件を定義します。この文書は、より深さでこれらの要件を議論使用されるパケットフォーマットを示し、適切な設定手順を説明し、かつ実装が正しい順序でパケットを処理する方法を示しています。
We begin our description by showing the required wire formats for the protected packets in Section 3. Section 4 describes rules which associated Mobile IPv6, IPsec, and IKE implementations must observe. Section 5 discusses how to configure either manually keyed IPsec security associations or how to configure IKE to establish them automatically. Section 6 shows examples of how packets are processed within the nodes.
私たちは、第3節第4節で保護されたパケットのために必要なワイヤフォーマットを示すことによって私たちの説明は、関連するモバイルIPv6、IPsecの、およびIKEの実装は守らなければならないルールを説明し始めます。第5節ではそれらを自動的に確立するために、IKEを設定するには、手動でキー付きのIPsecセキュリティアソシエーションまたは方法のいずれかを設定する方法について説明します。セクション6は、パケットがノード内で処理される方法の例を示しています。
All implementations of Mobile IPv6 mobile node and home agent MUST support at least the formats described in Section 3 and obey the rules in Section 4.
モバイルIPv6モバイルノードとホームエージェントのすべての実装は、セクション3に記載の少なくともフォーマットをサポートし、第4のルールに従わなければなりません。
The configuration and processing sections are informative, and should only be considered as one possible way of providing the required functionality.
構成および処理セクションが有益であり、唯一の必要な機能を提供する1つの可能な方法として考慮されるべきです。
Note that where this document indicates a feature MUST be supported and SHOULD be used, this implies that all implementations must be capable of using the specified feature, but there may be cases where, for instance, a configuration option disables to use of the feature in a particular situation.
この文書は、機能がサポートしなければならなくて、使用されるべきであることを示す場合、これはすべての実装は、指定された機能を使用することができなければならないことを意味することに注意してください、しかし、例えば、コンフィギュレーションオプションがで機能を使用するために無効に場合があります特定の状況。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますRFC 2119に記載されるように解釈される[1]。
When the mobile node is away from its home, the BUs sent by it to the home agent MUST support at least the following headers in the following order:
モバイルノードが離れてそのホームからの場合は、ホームエージェントにそれで送られたバスは、次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）宛先オプションは、ホームアドレスオプション（ホームアドレス）トランスポートモードにおけるESPヘッダヘッダ
Mobility header Binding Update Alternate Care-of Address option (care-of address)
アップデート代替気付アドレスオプション（気付アドレス）をバインドモビリティヘッダ
Note that the Alternate Care-of Address option is used to ensure that the care-of address is protected by ESP. The home agent considers the address within this option as the current care-of address for the mobile node. The home address is not protected by ESP directly, but the use of a specific home address with a specific security association is required by policy.
代替気付アドレスオプションは気付アドレスは、ESPによって保護されていることを保証するために使用されることに注意してください。ホームエージェントは、現在の気付アドレスモバイルノードの場合と同様に、このオプション内のアドレスとみなします。ホームアドレスが直接ESPによって保護されていないが、特定のセキュリティアソシエーションを持つ特定のホームアドレスの使用がポリシーによって必要とされます。
The Binding Acknowledgements sent back to the mobile node when it is away from home MUST support at least the following headers in the following order:
それがホームから離れているとき、モバイルノードに送り返さバインディング謝辞は、次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode Mobility header Binding Acknowledgement
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=気付アドレス）謝辞バインディング転送モードモビリティヘッダ内のヘッダ（タイプ2）のホームアドレスのESPヘッダをルーティング
When the mobile node is at home, the above rules are different as the mobile node can use its home address as a source address. This typically happens for the de-registration Binding Update when the mobile is returning home. In this situation, the Binding Updates MUST support at least the following headers in the following order:
モバイルノードがホームにある場合、上記の規則は、移動ノードとして異なるソースアドレスとしてホームアドレスを使用することができます。これは、典型的には移動が帰宅したときバインディング更新登録解除のために起こります。このような状況では、バインディングアップデートは、次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = home address, destination = home agent) ESP header in transport mode Mobility header Binding Update
IPv6ヘッダ（ソース=ホームアドレス、宛先=ホームエージェント）の更新をバインディング転送モードモビリティヘッダ内のESPヘッダ
The Binding Acknowledgement messages sent to the home address MUST support at least the following headers in the following order:
ホームアドレスに送信された結合確認メッセージは、次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = home agent, destination = home address) ESP header in transport mode Mobility header Binding Acknowledgement
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）確認応答バインディング転送モードモビリティヘッダ内のESPヘッダ
When the Home Test Init messages tunneled to the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
ホームエージェントにトンネルホーム試験開始メッセージは、IPSecで保護されている場合、彼らは次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）トンネルモードでESPヘッダIPv6ヘッダ（ソース=ホームアドレス、宛先=コレスポンデントノード）モビリティヘッダホーム試験開始
This format assumes that the mobile node's current care-of address is used as the outer header destination address in the security association. As discussed in Section 4.3, this requires the home agent to update the destination address when the mobile node moves. Policy entries and security association selectors stay the same, however, as the inner packets do not change upon movements.
この形式は、モバイルノードの現在の気付アドレスは、セキュリティアソシエーションで外部ヘッダの宛先アドレスとして使用されることを想定しています。 4.3節で述べたように、これは、モバイルノードが移動した場合、宛先アドレスを更新するために、ホームエージェントが必要です。内側のパケットが動き時に変更しないようポリシーエントリとセキュリティアソシエーションセレクタは、しかし、同じまま。
Note that there are trade-offs in using care-of addresses as the destination addresses versus using the home address and attaching an additional Home Address destination option and/or Routing header to the packets. The basis for requiring support for at least the care-of address case has been discussed in Section 7.
トレードオフはホームアドレスを使用してパケットに追加ホームAddress目的地オプションおよび/またはルーティングヘッダを付加対宛先アドレスとして気付アドレスを使用してあることに注意してください。少なくとも気付アドレスの場合のサポートを必要とするための基礎は、第7節で議論されてきました。
Similarly, when the Home Test messages tunneled from the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
同様に、ホームエージェントからトンネルホームテストメッセージは、IPSecで保護されているとき、彼らは次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test
IPv6ヘッダモビリティヘッダホーム試験トンネルモードIPv6ヘッダーのESPヘッダ（ソース=コレスポンデントノード、宛先=ホームアドレス）（ソース=ホーム・エージェント、宛先=気付アドレス）
The format used to protect return routability packets relies on the destination of the tunnel packets to change for the mobile node as it moves. The home agent's address stays the same, but the mobile node's address changes upon movements, as if the security association's outer header destination address had changed. When the mobile node adopts a new care-of address, it adopts also a new source address for outgoing tunnel packets. The home agent accepts packets sent like this, as the outer source address in tunnel packets is not checked according to the rules in RFC 2401. (We note, however, that
リターン・ルータビリティ・パケットを保護するために使用されるフォーマットは、それが移動するモバイルノードのために変更するトンネルパケットの宛先に依存しています。セキュリティアソシエーションの外側ヘッダの宛先アドレスが変更されたかのようにホームエージェントのアドレスは、同じままですが、動きの際に、移動ノードのアドレスが変更されます。モバイルノードは、新しい気付アドレスを採用する場合、それはまた、発信トンネルパケットの新しい送信元アドレスを採用します。トンネルパケットで外側のソースアドレスは、我々は、そのただし、注意してください（RFC 2401の規則に従ってチェックされていないとして、ホームエージェントは、このように送信されたパケットを受け入れます
some implementations are known to make source address checks.) For a discussion of the role of source addresses in outer tunnel headers, see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent requires the packets to be authenticated regardless of the source address change, hence the "new" sender must possess the same keys for the security association as it had in the previous location. This proves that the sender is the same entity, regardless of the changes in the addresses.
いくつかの実装は、ソースアドレスをチェックすることが知られている。）外側のトンネルヘッダの送信元アドレスの役割の説明については、RFC 2401のセクション5.1.2.1 [2]を参照します。ホームエージェントは関係なく、送信元アドレスの変更の認証されるパケットが必要であることにも注意してください、それは前の場所に持っていたとして、それゆえ「新しい」送信者がセキュリティアソシエーションのために同じ鍵を持っていなければなりません。これは、送信者が関係なく、アドレスの変更を、同一の実体であることを証明しています。
The process is more complicated in the home agent side, as the home agent has stored the previous care-of address in its Security Association Database as the outer header destination address. When IKE is being used, the mobile node runs it on top of its current care-of address, and the resulting tunnel-mode security associations will use the same addresses as IKE run over. In order for the home agent to be able to tunnel a Home Test message to the mobile node, it uses the current care-of address as the destination of the tunnel packets, as if the home agent had modified the outer header destination address in the security association used for this protection. This implies that the same security association can be used in multiple locations, and no new configuration or re-establishment of IKE phases is needed per movement. Section 5.2.2 discusses the security policy and security association database entries that are needed to accomplish this.
ホームエージェントは、外側ヘッダの宛先アドレスとしてのセキュリティアソシエーションデータベース内の前の気付アドレスを記憶しているように、プロセスは、ホームエージェント側ではより複雑です。 IKEが使用されている場合、モバイルノードは、その現在の気付アドレスの上でそれを実行し、IKEがひかとして得られたトンネルモードのセキュリティアソシエーションは、同じアドレスを使用します。ホームエージェントは、外側ヘッダの宛先アドレスを変更したかのように、ホームエージェントは、モバイルノードにホーム・テスト・メッセージトンネルすることができるようにするために、それは、トンネルパケットの宛先として現在の気付アドレスを使用してセキュリティアソシエーションは、この保護のために使用しました。これは、同じセキュリティアソシエーションが複数の場所で使用することができ、およびIKEフェーズの新しい設定または再確立が移動ごとに必要とされないことを意味します。 5.2.2項では、これを達成するために必要なセキュリティポリシーとセキュリティアソシエーションデータベースのエントリについて説明します。
If IPsec is used to protect prefix discovery, requests for prefixes from the mobile node to the home agent MUST support at least the following headers in the following order.
IPsecは、プレフィックスの発見を保護するために使用されている場合は、ホームエージェントにモバイルノードからプレフィックスに対する要求は、次の順序で少なくとも次のヘッダーをサポートしなければなりません。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode ICMPv6 Mobile Prefix Solicitation
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）宛先オプションは、トランスポートモードのICMPv6モバイルプレフィックス要請でホームアドレスオプション（ホームアドレス）ESPヘッダヘッダ
Again if IPsec is used, solicited and unsolicited prefix information advertisements from the home agent to the mobile node MUST support at least the following headers in the following order.
IPsecが使用されている場合は、再度、募集およびモバイルノードにホームエージェントからの迷惑プレフィックス情報の広告は、次の順序で少なくとも次のヘッダーをサポートしなければなりません。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode
トランスポートモードでヘッダ（タイプ2）のホームアドレスのESPヘッダをルーティングIPv6ヘッダ（ソース=ホーム・エージェント、宛先=気付アドレス）
ICMPv6 Mobile Prefix Advertisement
ICMPv6のモバイルプレフィックス広告
If IPsec is used to protect payload packets tunneled to the home agent from the mobile node, we use a format similar to the one in Section 3.2. However, instead of the MobilityHeader, these packets may contain any legal IPv6 protocol(s):
IPsecは、モバイルノードからホームエージェントにトンネルペイロードパケットを保護するために使用されている場合は、我々は、3.2節のものと同様の形式を使用します。しかし、代わりMobilityHeaderの、これらのパケットは、任意の法的なIPv6プロトコル（単数または複数）を含んでいてもよいです。
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Any protocol
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）トンネルモードIPv6ヘッダ（ソース=ホームアドレス、宛先=コレスポンデントノード）すべてのプロトコルにESPヘッダ
Similarly, when the payload packets are tunneled from the home agent to the mobile node with ESP encapsulation, they MUST support at least the following headers in the following order:
ペイロードパケットがESPでカプセル化されたモバイルノードにホームエージェントからトンネリングされたとき同様に、彼らは次の順序で少なくとも次のヘッダーをサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Any protocol
トンネルモードIPv6ヘッダーのIPv6ヘッダー（ソース=ホーム・エージェント、宛先=気付アドレス）ESPヘッダ（ソース=コレスポンデントノード、宛先=ホームアドレス）任意のプロトコル
This section describes mandatory rules for all Mobile IPv6 mobile nodes and home agents. These rules are necessary in order for it to be possible to enable IPsec communications despite movements, guarantee sufficient security, and to ensure correct processing order of packets.
このセクションでは、すべてのモバイルIPv6モバイルノードとホームエージェントのために必須のルールを説明しています。これらのルールは、動きにもかかわらず、IPsecの通信を可能に十分なセキュリティを保証し、パケットの正しい処理順序を確保することが可能であるためには必要です。
The rules in the following sections apply only to the communications between home agents and mobile nodes. They should not be taken as requirements on how IPsec in general is used by mobile nodes.
次のセクションのルールはホームエージェントとモバイルノード間の通信に適用されます。彼らは一般的に、IPsecは、モバイルノードによって使用される方法についての要件として解釈されるべきではありません。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o Manual configuration of IPsec security associations MUST be supported. The configuration of the keys is expected to take place out-of-band, for instance at the time the mobile node is configured to use its home agent.
OのIPsecセキュリティアソシエーションの手動設定をサポートしなければなりません。キーの設定は、モバイルノードがホームエージェントを使用するように設定された時間で、たとえば、アウトオブバンド場所を取ることが期待されます。
o Automatic key management with IKE [4] MAY be supported. Only IKEv1 is discussed in this document. Other automatic key management mechanisms exist and will appear beyond IKEv1, but this document does not address the issues related to them.
O IKEによる自動鍵管理は、[4]サポートされるかもしれません。のみのIKEv1は、この文書で説明されています。他の自動鍵管理メカニズムが存在し、IKEv1のを超えて表示されますが、この文書では、それらに関連する問題に対処していません。
o ESP encapsulation of Binding Updates and Acknowledgements between the mobile node and home agent MUST be supported and MUST be used.
Oモバイルノードとホームエージェント間の結合更新と謝辞のESPカプセル化をサポートしなければなりませんし、使用しなければなりません。
o ESP encapsulation of the Home Test Init and Home Test messages tunneled between the mobile node and home agent MUST be supported and SHOULD be used.
モバイルノードとホームエージェントとの間でトンネリングホーム試験開始とホームテストメッセージのO ESPのカプセル化をサポートしなければなりませんし、使用されるべきです。
o ESP encapsulation of the ICMPv6 messages related to prefix discovery MUST be supported and SHOULD be used.
Oプレフィックスの発見に関連するICMPv6メッセージのESPカプセル化をサポートしなければなりませんし、使用されるべきです。
o ESP encapsulation of the payload packets tunneled between the mobile node and 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、ペイロードデータ保護は、これらのプロトコルのためにサポートしなければなりません。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o As required in the base specification [7], 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 [7]、受信ノード宛のパケットは、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 considers apply to the Routing header processing as was described above for the Home Address destination option.
ホームアドレス宛先オプションについて上述したのと同様の実装では、ルーティングヘッダ処理に適用考慮する。
o When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters this tunnel.
IPsecはリターン・ルータビリティ・シグナリングまたはペイロード・パケットを保護するために使用される場合、O、この保護は、モバイルノードとホームエージェントとの間のIPv6カプセル化トンネルインターフェイスを入力リターン・ルータビリティ・パケットに適用されなければなりません。これは、例えば、具体的にはトンネルインターフェイスのセキュリティポリシーデータベースエントリを定義することによって、達成することができます。つまり、ポリシーエントリは、一般的に、ノードの物理的インタフェース（S）上のすべてのトラフィックには適用されず、むしろ、このトンネルに入るトラフィックに関する。
o The authentication of mobile nodes MAY be based either on machine or user credentials. Note that multi-user operating systems typically allow all users of a node to use any of the IP addresses assigned to the node. This limits the capability of the home agent to restrict the use of a home address to a particular user in such environment. Where user credentials are applied in a multi-user environment, the configuration should authorize all users of the node to control all home addresses assigned to the node.
oをモバイルノードの認証は、いずれかのマシンまたはユーザーの資格情報に基づいてもよいです。マルチユーザ・オペレーティング・システムは、典型的には、ノードのすべてのユーザがノードに割り当てられたIPアドレスのいずれかを使用することを可能にすることに留意されたいです。これは、そのような環境では、特定のユーザにホームアドレスの使用を制限するために、ホームエージェントの機能を制限します。ユーザー資格情報は、マルチユーザー環境に適用されている場合は、構成がノードに割り当てられたすべてのホームアドレスを制御するためにノードのすべてのユーザーを承認する必要があります。
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 MUST 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 and Acknowledgements, and prefix discovery SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again.
モバイルノードがホームを返し、ホームエージェント、ホームエージェントとモバイルノードの気付アドレス間のトンネルで登録解除するとO取り壊されます。モバイルノードとホームエージェント間のトンネルトラフィックを保護するために使用されたセキュリティポリシーエントリは、（例えば、それらを削除し、APIを介してそれらを後で戻ってインストールすることで）非アクティブにしなければなりません。対応するセキュリティアソシエーションは、それらが作成されたかに応じて、彼らがそうであるように保持または削除することができました。セキュリティアソシエーションは、IKEを使用して動的に作成された場合、それらの期限が切れたときに、それらは自動的に削除されます。セキュリティアソシエーションを手動設定によって作成された場合、移動ノードは再び家から離れて移動したとき、彼らは後に保持され、使用されなければなりません。彼らは気付アドレスに依存しないと、再び使用することができるバインディング更新と謝辞、およびプレフィックスの発見を保護するセキュリティアソシエーションを削除しないでください。
The following rules apply to mobile nodes:
次の規則は、モバイルノードに適用されます。
o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations, sent to the home agent from a care-of address.
Oモバイルノードが気付アドレスからホームエージェントに送信された更新情報とモバイルプレフィックス要請を、バインディングでホームアドレス宛先オプションを使用しなければなりません。
o When the mobile node receives a changed set of prefixes from the home agent during prefix discovery, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this.
モバイルノードは、プレフィックスの発見時にホームエージェントからのプレフィックスの変更セットを受信すると、O、新しいセキュリティポリシーエントリを設定する必要がある、との新しいセキュリティアソシエーションを設定する必要があるかもしれません。これは、このための自動的な方法を議論するために、この仕様の範囲外です。
The following rules apply to home agents:
次のルールは、ホームエージェントに適用されます。
o The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node, again due to the need to have the home address visible when the policy checks are made.
ホームエージェントはバインディング謝辞とモバイルプレフィックス広告タイプ2ルーティングヘッダを使用しなければならないoをポリシーチェックが行われたときに再度、可視ホームアドレスを持っている必要があるため、モバイル・ノードに送信されます。
o It is necessary to avoid the possibility that a mobile node could use its security association to send a Binding Update on behalf of another mobile node using the same home agent. In order to do this, the security policy database entries MUST unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent when manually keyed IPsec security associations are used. When dynamic keying is used, the security policy database entries MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address. How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used.
Oモバイルノードが同じホームエージェントを使用して他の移動ノードに代わってバインディングアップデートを送信するために、そのセキュリティアソシエーションを使用することができる可能性を回避するために必要です。これを行うために、セキュリティ・ポリシー・データベース・エントリは明白手動でキー付きIPsecセキュリティアソシエーションが使用される場合、任意の所与のホームアドレスとホームエージェントとの間の結合の更新を保護するための単一のセキュリティアソシエーションを識別しなければなりません。ダイナミックキーを使用した場合、セキュリティポリシーデータベースエントリが一義的特定のホームアドレスのバインディング更新を保護するためのセキュリティアソシエーションの作成を許可するために使用することができるIKEフェーズ1つの認証情報を識別しなければなりません。どのようにこれらのマッピングが維持されているこの仕様の範囲外であるが、彼らは、ホームエージェントでローカルに管理テーブルとして、例えば、維持することができます。フェーズ1のアイデンティティは完全修飾ドメイン名（FQDN）の場合、DNSの安全な形式を使用してもよいです。
o When the set of prefixes advertised by the home agent changes, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this, if new home addresses are required.
O場合は、ホームエージェントの変更によってアドバタイズされたプレフィクスのセットは、新しいセキュリティポリシーエントリを設定する必要がある、との新しいセキュリティアソシエーションを設定する必要があるかもしれません。新しいホームアドレスが必要な場合は、このための自動的な方法を議論するために、この仕様の範囲外です。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] 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.
Oサポートしなければならない結合更新は、結合謝辞、プレフィックスの発見、両方のモバイルノードとホームエージェントを確保し、トランスポートモードでカプセル化セキュリティペイロード（ESP）[3]ヘッダーを使用しなければならず、非ヌルペイロード認証アルゴリズムを使用する必要がある場合データ発信元認証、コネクションレス完全性とオプションのアンチリプレイ保護を提供します。
Mandatory support for encryption and integrity protection algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. Care is needed when selecting suitable encryption algorithms for ESP, however. Currently available integrity protection algorithms are in general considered to be secure. The encryption algorithm, DES, mandated by the current IPsec standards is not, however. This is particularly problematic when IPsec security associations are configured manually, as the same key is used for a long time.
必須の暗号化および完全性保護アルゴリズムのサポートRFC 2401で定義されたように[2]、RFC 2402 [8]、およびRFC 2406 [3]。 ESPのための適切な暗号化アルゴリズムを選択する際に注意がしかし、必要とされています。現在利用可能な完全性保護アルゴリズムは、一般に安全であると考えられています。現在のIPsecの規格で定められた暗号化アルゴリズム、DESは、しかし、ではありません。 IPsecセキュリティアソシエーションを手動で設定されている場合、同じキーを長時間使用されるので、これは特に問題です。
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以外の暗号化変換と非ヌル認証アルゴリズムを適用しなければなりません。
Note that the return routability procedure involves two message exchanges from the mobile node to the correspondent node. The purpose of these exchanges is to assure that the mobile node is live at the claimed home and care-of addresses. One of the exchanges is sent directly to and from the correspondent node, while another one is tunneled through the home agent. If an attacker is on the mobile node's link and the mobile node's current link is an unprotected wireless link, the attacker would able to see both sets of messages, and launch attacks based on it (these attacks are discussed further in Section 15.4 of the base specification [7].) One can prevent the attack by making sure that the packets tunneled through the home agent are encrypted.
リターン・ルータビリティ手順は、コレスポンデント・ノードにモバイルノードから2つのメッセージ交換を含むことに留意されたいです。これらの交換の目的は、モバイルノードがホーム主張と気付アドレスのライブであることを保証することです。もう一つは、ホームエージェントを介してトンネリングされている間の交流の一つは、へとコレスポンデントノードから直接送信されます。攻撃者は、モバイルノードのリンク上にあり、モバイルノードの現在のリンクが保護されていない無線リンクである場合、攻撃者は、メッセージの両方のセットを見て、それに基づいて攻撃を開始することができ（これらの攻撃は、塩基の15.4節で詳しく説明されているでしょう仕様[7]。）一つは、ホームエージェントを介してトンネルパケットが暗号化されていることを確認することで攻撃を防ぐことができます。
Note that this specification concerns itself only with on-the-wire formats, and does not dictate specific implementations mechanisms. In the case of IPsec tunnel mode, the use of IP-in-IP encapsulation followed by IPsec transport mode encapsulation may also be possible.
なお、本明細書でのみオン・ザ・ワイヤ形式と懸念自体を、そして特定の実施メカニズムを決定しません。 IPsecトンネルモードの場合には、IPsecトランスポート・モード・カプセル化、続いてIP-in-IPカプセル化を使用することも可能です。
The following rules apply to mobile nodes:
次の規則は、モバイルノードに適用されます。
o When ESP is used to protect Binding Updates, there is no protection for the care-of address which 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. In this case no Alternate Care-of Address option is needed, as described in Section 3.1.
ESPは、バインディングアップデートを保護するために使用された場合は、O、気付アドレスESPによって保護された領域の外側のIPv6ヘッダーに表示されるための保護はありません。ホームエージェントは気付アドレスが改ざんされていないことを確認することが重要です。その結果、攻撃者が別のアドレスに移動ノードのトラフィックをリダイレクトしているだろう。これを防ぐために、モバイルIPv6の実装では、自宅から離れている間、モバイルノードによって送られた結合更新で代替気付アドレスモビリティオプションを使用しなければなりません。モバイルノードがホームを返し、登録解除するために、ホームエージェントにバインディングアップデートを送信する場合は例外です。 3.1節で説明したようにこの場合は何の代替気付アドレスのオプションは、必要ありません。
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. The mobile node starts to use a new primary care-of address immediately after sending a Binding Update to the home agent to register this new address. Similarly, it starts to use the new address as the required destination address of tunneled packets received from the home agent.
IPsecはリターン・ルータビリティ・シグナリングまたはペイロードパケットを保護するために使用される場合、モバイルノードは、それが現在の主気付アドレスへの発信トンネルパケットに使用する送信元アドレスを設定しなければなりません。モバイルノードは、すぐにこの新しいアドレスを登録するホームエージェントにバインディングアップデートを送信した後に新しいプライマリ気付アドレスを使用することを開始します。同様に、ホームエージェントから受信したトンネルパケットの必要な宛先アドレスとして新しいアドレスを使用することを開始します。
The following rules apply to home agents:
次のルールは、ホームエージェントに適用されます。
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. 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を使用すると、アドレスの変更が唯一のIPsecを使用することにより、ホームエージェントによって受信され、保護されたバインディングアップデートに基づいて行わなければならないことに留意すべきです。このようなセキュリティの脆弱性をもたらすことができる任意のアプリケーションからAPIにリターンルータビリティ、又はオープンアクセスによって保護コレスポンデントノードへ結合更新のような他の情報源に基づいて、アドレスの変更。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o If anti-replay protection is required, dynamic keying MUST be used. IPsec can provide anti-replay protection only if dynamic keying is used (which may not always be the case). IPsec also does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, sequence numbers within the Mobile IPv6 messages are used to ensure correct ordering. However, if the 16 bit Mobile IPv6 sequence number space is cycled through, or the home agent reboots and loses its state regarding the sequence numbers, replay and reordering attacks become possible. The use of dynamic keying, IPsec anti-replay protection, and the Mobile IPv6 sequence numbers can together prevent such attacks.
アンチリプレイ保護が必要な場合は、O、動的なキーを使用しなければなりません。 IPsecは（必ずしもそうでなくてもよい）動的キーが使用されている場合にのみ、アンチリプレイ保護を提供することができます。 IPsecはまた、彼らが再生されていないだけで、パケットの正しい順序を保証するものではありません。このため、モバイルIPv6メッセージ内のシーケンス番号が正しい順序を保証するために使用されています。しかし、あれば16ビットのモバイルIPv6シーケンス番号空間を循環され、またはホームエージェントは再起動し、シーケンス番号に関するその状態を失い、リプレイや並べ替えの攻撃が可能となります。ダイナミックなキーイング、IPsecのリプレイ保護、およびモバイルIPv6シーケンス番号の使用は、一緒に、このような攻撃を防ぐことができます。
o If IKE version 1 is used with preshared secrets in main mode, it determines the shared secret to use from the IP address of the peer. With Mobile IPv6, however, this may be a care-of address and does not indicate which mobile node attempts to contact the home agent. Therefore, if preshared secret authentication is used in IKEv1 between the mobile node and the home agent then aggressive mode MUST be used. Note also that care needs to be taken with phase 1 identity selection. Where the ID_IPV6_ADDR Identity Payloads is used, unambiguous mapping of identities to keys is not possible. (The next version of IKE may not have these limitations.)
IKEバージョン1は、メインモードの事前共有秘密を使用する場合は、O、それはピアのIPアドレスから使用する共有秘密を決定します。モバイルIPv6では、しかし、これは気付アドレスであってもよいし、モバイルノードがホームエージェントに連絡しようとしている示すものではありません。事前共有鍵認証は、モバイルノードとホームエージェント間のIKEv1で使用されている場合ので、その後、アグレッシブモードを使用しなければなりません。注また、そのケアは、フェーズ1のアイデンティティの選択で撮影する必要があります。 ID_IPV6_ADDRアイデンティティペイロードを使用する場合、キーへのアイデンティティを明確にマッピングすることはできません。 （IKEの次のバージョンでは、これらの制限を持っていないかもしれません。）
Note that the difficulties with main mode and preshared secrets in IKE version 1 are well known for dynamic addresses. With static addresses, there has not been a problem. With Mobile IPv6, however, the use of the care-of addresses to run IKE to the home agent presents a problem even when the home address stays stable. Further discussion about the use of care-of addresses in this way appears in Section 7.
IKEバージョン1でメインモードと事前共有秘密の困難がよくダイナミックアドレスのために知られていることに注意してください。静的アドレスを使用すると、問題はなかったです。モバイルIPv6では、しかし、ホームエージェントにIKEを実行するための気付アドレスの使用は、ホームアドレスが安定したままでも問題があります。このように気付アドレスの使用についての更なる議論は、セクション7に表示されます。
The following rules apply to mobile nodes:
次の規則は、モバイルノードに適用されます。
o In addition to the rules above, if dynamic keying is used, the key management protocol MUST use the care-of address as the source address in the protocol exchanges with the mobile node's home agent.
動的キーが使用される場合、O上記の規則に加えて、鍵管理プロトコルは、モバイルノードのホームエージェントとのプロトコル交換で送信元アドレスとして気付アドレスを使用しなければなりません。
o However, the IPsec security associations with the mobile node's home agent use home addresses. That is, the IPsec security associations MUST be requested from the key management protocol using the home address of the mobile node as the client identity.
Oしかし、モバイルノードのホームエージェントとのIPsecセキュリティアソシエーションは、ホームアドレスを使用します。つまり、IPsecセキュリティアソシエーションがクライアントIDとしてモバイルノードのホームアドレスを使用して鍵管理プロトコルから要求されなければなりません。
The security associations for protecting Binding Updates and Acknowledgements are requested for the Mobility header protocol in transport mode and for specific IP addresses as endpoints. No other selectors are used. Similarly, the security associations for protecting prefix discovery are requested for the ICMPv6 protocol and the specific IP addresses, again without other selectors. Security associations for payload and return routability protection are requested for a specific tunnel interface and either the payload protocol or the Mobility header protocol, in tunnel mode. In this case one requested endpoint is an IP address and the other one is a wildcard, and there are no other selectors.
結合更新と謝辞を保護するためのセキュリティアソシエーションは、トランスポートモードにおけるモビリティヘッダプロトコルのためのエンドポイントとして特定のIPアドレスを要求しています。他のセレクタが使用されていません。同様に、プレフィックスの発見を保護するためのセキュリティアソシエーションは、他のセレクタなしで再び、ICMPv6のプロトコルおよび特定のIPアドレスに要求されています。ペイロードと帰路経路保護のためのセキュリティアソシエーションは、トンネルモードでは、特定のトンネルインターフェイスとペイロードプロトコルまたはモビリティヘッダプロトコルのいずれかのために要求されます。この場合、1つの要求されたエンドポイントは、IPアドレスであり、もう一つはワイルドカードであり、他のセレクタはありません。
o If the mobile node has used IKE version 1 to establish security associations with its home agent, it should follow the procedures discussed in Section 11.7.1 and 11.7.3 of the base specification [7] to determine whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established.
モバイルノードがそのホームエージェントとのセキュリティアソシエーションを確立するために、IKEバージョン1を用いた場合、Oは、[7] IKEのエンドポイントが移動できるかどうかを決定するために、セクション11.7.1と基本仕様の11.7.3で説明した手順に従うべきですまたはIKEフェーズ1が再確立する必要がある場合。
The following rules apply to home agents:
次のルールは、ホームエージェントに適用されます。
o If the home agent has used IKE version 1 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 [7] to determine whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established.
ホームエージェントは、モバイルノードとのセキュリティアソシエーションを確立するために、IKEバージョン1を用いた場合、Oは、[7] IKEのエンドポイントが移動できるかどうかを決定するために、セクション10.3.1と基本仕様の10.3.2で説明した手順に従うべきですまたはIKEフェーズ1が再確立する必要がある場合。
In the following we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect Binding Updates and Binding Acknowledgements exchanged between the mobile node and the home agent.
以下では、セキュリティポリシーデータベース（SPD）とセキュリティアソシエーションデータベース（SAD）はバインディングアップデートを保護するために必要なエントリ記述し、バインド謝辞は、モバイルノードとホームエージェント間で交換しました。
Section 5.1 introduces the format we use in the description of the SPD and the SAD. Section 5.2 describes how to configure manually keyed IPsec security associations without dynamic keying, and Section 5.3 describes how to use dynamic keying.
5.1節では、我々はSPDとSADの説明に使用形式を導入しています。 5.2節では、動的キーなしで手動鍵付きのIPsecセキュリティアソシエーションを設定する方法について説明し、5.3節では、動的キーを使用する方法について説明します。
The format used in the examples is as follows. The SPD description has the format
次のように実施例で使用されるフォーマットです。 SPDの記述の形式は
<node> "SPD OUT:" "-" <spdentry> "-" <spdentry> ... "-" <spdentry>
<ノード> "SPD OUT：" " - " <spdentry> " - " <spdentry> ... " - " <spdentry>
<node> "SPD IN:" "-" <spdentry> "-" <spdentry> ... "-" <spdentry>
<ノード> "SPD INは：" " - " <spdentry> " - " <spdentry> ... " - " <spdentry>
Where <node> represents the name of the node, and <spdentry> has the following format:
ここで、<ノード>ノードの名前を表し、<spdentry>は、次の形式を有します。
"IF" <condition> "THEN USE SA " <sa> | "IF" <condition> "THEN USE SA " <pattern> |
<条件> "THEN USE SA" <SA> "IF" | "IF" <条件> "THEN USE SA" <パターン> |
Where <condition> is a boolean expression about the fields of the IPv6 packet, <sa> is the name of a specific security association, and <pattern> is a specification for a security association to be negotiated via IKE [4]. The SAD description has the format
<条件> IPv6パケットのフィールドに関するブール式である場合、<SA>特定のセキュリティアソシエーションの名前、<パターン>は、IKEを介してネゴシエートされるセキュリティアソシエーションのための仕様である[4]。 SADの記述の形式は
<node> "SAD:" "-" <sadentry> "-" <sadentry> ... "-" <sadentry>
<ノード> "SAD：" " - " <sadentry> " - " <sadentry> ... " - " <sadentry>
Where <node> represents the name of the node, and <sadentry> has the following format:
ここで、<ノード>ノードの名前を表し、<sadentry>は、次の形式を有します。
<sa> "(" <dir> "," <spi> "," <destination> "," <ipsec-proto> "," <mode> ")" ":" <rule>
<SA> "（" <DIR> "" <SPI> "" <宛先> "" <IPSecでプロト> "" <モード> "）" "：" <規則>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security association, <destination> is its destination, <ipsec-proto> is in our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule> is an expression which describes the IPsec selectors, i.e., which fields of the IPv6 packet must have which values.
<DIR>は<SPI>は、セキュリティアソシエーションのSPIで、<送信先>が<のipsec-プロト>、その先で、 "IN" または "OUT" である私たちの場合、 "ESP" で、<モード>」のいずれかどこにあるのさTUNNEL」または 『TRANSPORT』、および<ルール>は、IPv6パケットのフィールドは、どの値が持っている必要がありますIPsecのセレクタを記述する式、すなわち、です。
We will be using an example mobile node in this section with the home address "home_address_1". The user's identity in this mobile node is "user_1". The home agent's address is "home_agent_1".
我々はホームアドレス「home_address_1」とこのセクションの例のモバイルノードを使用することになります。この移動ノードにおけるユーザのアイデンティティは「USER_1」です。ホームエージェントのアドレスは「home_agent_1」です。
Here are the contents of the SPD and SAD for protecting Binding Updates and Acknowledgements:
ここではバインディング更新と謝辞を保護するためのSPDとSADの内容は以下のとおりです。
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1
モバイルノードSPD OUT： - ソース= home_address_1＆宛先= home_agent_1＆プロト= MH THEN USE SA SA1 IF
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA SA2
モバイルノードSPD IN： - ソース= home_agent_1＆宛先= home_address_1＆プロト= MH THEN USE SA SA2 IF
mobile node SAD: - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = MH - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = MH
モバイルノードSAD： - SA1（OUT、spi_a、home_agent_1、ESP、トランスポート）：ソース= home_address_1＆宛先= home_agent_1＆プロト= MH - SA2（IN、spi_b、home_address_1、ESP、トランスポート）：ソース= home_agent_1＆宛先= home_address_1 ＆プロト= MH
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA SA2
ホームエージェントSPD OUT： - ソース= home_agent_1＆先= home_address_1＆プロト= MH THEN USE SA SA2 IF
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1
ホームエージェントSPDの場合： - ソース= home_address_1＆先= home_agent_1＆プロト= MH THEN USE SA SA1 IF
home agent SAD: - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = MH - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = MH
ホームエージェントSAD： - SA2（OUT、spi_b、home_address_1、ESP、トランスポート）：ソース= home_agent_1＆先= home_address_1＆プロト= MH - SA1（IN、spi_a、home_agent_1、ESP、トランスポート）：ソース= home_address_1＆先= home_agent_1 ＆プロト= MH
In the above, "MH" refers to the protocol number for the Mobility Header [7].
上記において、「MH」は、モビリティヘッダのプロトコル番号[7]を指します。
In the following we describe the necessary SPD and SAD entries to protect return routability signaling between the mobile node and the home agent. Note that the rules in the SPD are ordered, and the ones in the previous section must take precedence over these ones. In other words, the higher precedence entries must occur first in the RFC 2401 [2] ordered list of SPD entries.
以下では、移動ノードとホームエージェント間のリターン・ルータビリティ・シグナリングを保護するために必要なSPDとSADのエントリを記述します。 SPDのルールが発注されていることに注意してください、そして前節のものはこれらのものに優先しなければなりません。換言すれば、より高い優先順位のエントリは、RFC 2401で最初に発生しなければならない[2] SPDエントリのリストを命じました。
mobile node SPD OUT: - IF interface = IPv6 IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3
モバイルノードSPD OUT： - home_agent_1へのインターフェース= IPv6のIPv6トンネルIF＆ソース= home_address_1＆宛先=任意＆プロト= MH THEN USE SA SA3
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
任意＆宛先= home_address_1＆プロト= MH THEN USE SA SA4 = home_agent_1＆源からインターフェイス= IPv6トンネルIF - ：INモバイルノードSPD
mobile node SAD: - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = MH - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = MH
モバイルノードSAD： - SA3（OUT、spi_c、home_agent_1、ESPトンネル）：ソース= home_address_1＆宛先=任意＆プロト= MH - SA4（IN、spi_d、care_of_address_1、ESPトンネル）：ソース=任意＆宛先= home_address_1 ＆プロト= MH
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
ホームエージェントSPD OUT： - THEN USE SA SA4 MH =ホームアドレス1とソース=あらゆる＆先=ホームADDRESS_1＆プロトへのインターフェース= IPv6トンネルIF
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3
ホームエージェントSPDの場合： - home_address_1からインターフェイス= IPv6トンネルIF＆ソース= home_address_1＆先=あらゆる＆プロト= MH THEN USE SA SA3
home agent SAD: - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = MH - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = MH
ホームエージェントSAD： - SA4（OUT、spi_d、care_of_address_1、ESP、トンネル）：ソース=あらゆる＆先= home_address_1＆プロト= MH - SA3（IN、spi_c、home_agent_1、ESP、トンネル）：ソース= home_address_1＆先=任意の＆プロト= MH
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. It can be initialized to the home address before the mobile node has registered.
モバイルノードにホームエージェントからのセキュリティアソシエーションが宛先として現在の気付アドレスを使用しています。前述のように、このアドレスは、モバイルノードが移動するようにSADで更新されます。モバイルノードが登録されている前に、それはホームアドレスに初期化することができます。
In the following we describe some additional SPD and SAD entries to protect prefix discovery. Note that the SPDs described above protect all ICMPv6 traffic between the mobile node and the home agent, as IPsec may not have the ability to distinguish between different ICMPv6 types.
以下では、プレフィックスの発見を保護するためにいくつかの追加SPDとSADのエントリを記述します。 IPsecが異なるのICMPv6タイプを区別する能力を持っていないかもしれないとして、前述のSPDは、モバイルノードとホームエージェント間のすべてのICMPv6トラフィックを保護することに注意してください。
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA SA5.
モバイルノードSPD OUT： - ソース= home_address_1＆宛先= home_agent_1＆プロト= ICMPv6のTHEN USE SA SA5 IF。
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA SA6
モバイルノードSPD IN： - ソース= home_agent_1＆宛先= home_address_1＆プロト= ICMPv6のTHEN USE SA SA6 IF
mobile node SAD: - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = ICMPv6
モバイルノードSAD： - SA5（OUT、spi_e、home_agent_1、ESP、トランスポート）：ソース= home_address_1＆宛先= home_agent_1＆プロト=のICMPv6 - SA6（IN、spi_f、home_address_1、ESP、トランスポート）：ソース= home_agent_1＆宛先= home_address_1 ＆プロト=のICMPv6
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA SA6
ホームエージェントSPD OUT： - ソース= home_agent_1＆先= home_address_1＆プロト= ICMPv6のTHEN USE SA SA6 IF
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA SA5
ホームエージェントSPDの場合： - ソース= home_address_1＆先= home_agent_1＆プロト= ICMPv6のTHEN USE SA SA5 IF
home agent SAD: - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = ICMPv6
ホームエージェントSAD： - SA6（OUT、spi_f、home_address_1、ESP、トランスポート）：ソース= home_agent_1＆先= home_address_1＆プロト=のICMPv6 - SA5（IN、spi_e、home_agent_1、ESP、トランスポート）：ソース= home_address_1＆先= home_agent_1 ＆プロト=のICMPv6
It is also possible to perform some additional, optional, protection of tunneled payload packets. This protection takes place in a similar manner to the return routability protection above, but requires a different value for the protocol field. The necessary SPD and SAD entries are shown below. It is assumed that the entries for protecting Binding Updates and Acknowledgements, and the entries to protect Home Test Init and Home Test messages take precedence over these entries.
トンネルペイロードパケットのいくつかの追加、オプションで、保護を行うことも可能です。この保護は、上記のリターン・ルータビリティ保護と同様の方法で行われますが、プロトコルフィールドに異なる値が必要です。必要SPDとSADエントリを以下に示します。ホーム試験開始とホームテストメッセージを保護するためにバインディング更新と謝辞、およびエントリを保護するためのエントリがこれらのエントリに優先することが想定されます。
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7
モバイルノードSPD OUT： - home_agent_1へのインターフェース= IPv6トンネルIF＆ソース= home_address_1＆宛先=任意＆プロト= X THEN USE SA SA7
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
INモバイルノードSPD： - IF home_agent_1＆源からインターフェイス= IPv6トンネル=＆任意の宛先= home_address_1＆プロト= X THEN USE SA SA8
mobile node SAD: - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = X - SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = X
モバイルノードSAD： - SA7（OUT、spi_g、home_agent_1、ESPトンネル）：= Xソース= home_address_1＆宛先=任意＆プロト - SA8（IN、spi_h、care_of_address_1、ESPトンネル）：ソース=任意＆宛先= home_address_1 ＆プロト= X
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
ホームエージェントSPD OUT： - ホームアドレス1とソース=あらゆる＆先=ホームADDRESS_1＆プロト= X THEN USE SA SA8へのインターフェース= IPv6トンネルIF
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7
ホームエージェントSPDの場合： - IF home_address_1＆ソース= home_address_1＆先=あらゆる＆プロト= X THEN USE SA SA7からインターフェイス= IPv6トンネル
home agent SAD: - SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = X - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = X
ホームエージェントSAD： - SA8（OUT、spi_h、care_of_address_1、ESP、トンネル）：ソース=あらゆる＆先= home_address_1＆プロト= X - SA7（IN、spi_g、home_agent_1、ESP、トンネル）：ソース= home_address_1＆先=任意の＆プロト= X
If multicast group membership control protocols such as MLDv1 [9] or MLDv2 [11] need to be protected, these packets may use a link-local address rather than the home address of the mobile node. In this case the source and destination can be left as a wildcard and the SPD entries will work solely based on the used interface and the protocol, which is ICMPv6 for both MLDv1 and MLDv2.
このようなのMLDv1 [9]またはMLDv2の[11]などのマルチキャストグループメンバーシップ制御プロトコルを保護する必要がある場合、これらのパケットは、リンクローカルアドレスではなく、モバイルノードのホームアドレスを使用することができます。この場合、ソースとデスティネーションは、ワイルドカードとして残すことができ、SPDエントリが単独のMLDv1およびMLDv2の両方のためのICMPv6で使用されるインタフェースおよびプロトコルに基づいて動作します。
Similar problems are encountered when stateful address autoconfiguration protocols such as DHCPv6 [10] are used. The same approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP protocol.
そのようなDHCPv6の[10]などのステートフルアドレス自動設定プロトコルが使用される場合、同様の問題に直面します。同じアプローチは、同様にDHCPv6の適用です。 DHCPv6のは、UDPプロトコルを使用しています。
Support for multiple layers of encapsulation (such as ESP encapsulated in ESP) is not required by RFC 2401 [2] and is also otherwise often problematic. It is therefore useful to avoid setting the protocol X in the above entries to either AH or ESP.
（例えば、ESP内にカプセル化ESPなど）カプセル化の複数の層のための支持体は、RFC 2401によって必要とされていない[2]、そうでなければ、多くの場合も問題があります。 AHまたはESPのいずれかに上記のエントリのプロトコルXを設定避けるために有用です。
In this section we show an example configuration that uses IKE to negotiate security associations.
このセクションでは、セキュリティアソシエーションをネゴシエートするIKEを使用する構成例を示しています。
Here are the contents of the SPD for protecting Binding Updates and Acknowledgements:
ここではバインディング更新と謝辞を保護するためのSPDの内容は以下のとおりです。
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
モバイルノードSPD OUT： - IFソース= home_address_1＆先= home_agent_1＆プロト= MH THEN USE SA ESPトランスポート：ローカルフェーズ1つのID = USER_1
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
ソース= home_agent_1＆宛先= home_address_1＆プロト= MH THEN USE SA ESP輸送IF：局所相1人のアイデンティティ= USER_1 - ：INモバイルノードSPD
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームエージェントSPD OUT： - IFソース= home_agent_1＆先= home_address_1＆プロト= MHは、その後、使用SA ESP TRANSPORT：ピアフェーズ1つのID = USER_1
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームエージェントSPDの場合： - IFソース= home_address_1＆先= home_agent_1＆プロト= MHは、その後、使用SA ESP TRANSPORT：ピアフェーズ1つのID = USER_1
We have omitted details of the proposed transforms in the above, and all details related to the particular authentication method such as certificates beyond listing a specific identity that must be used.
私たちは、このような使用する必要があり、特定のIDをリスト越えた証明書として、上記で提案されている変換、および特定の認証方法に関連するすべての詳細の詳細を省略しています。
We require IKE version 1 to be run using the care-of addresses but still negotiate IPsec SAs that use home addresses. The extra conditions set by the home agent SPD for the peer phase 1 identity to be "user_1" must be verified by the home agent. The purpose of the condition is to ensure that the IKE phase 2 negotiation for a given user's home address can not be requested by another user. In the mobile node, we simply set our local identity to be "user_1".
私たちは、気付アドレスを使用して実行しますが、それでもホームアドレスを使用したIPsec SAをネゴシエートするIKEバージョン1が必要です。 「USER_1」となるピアのフェーズ1のアイデンティティのためのホームエージェントSPDによって設定された追加の条件は、ホームエージェントによって検証されなければなりません。条件の目的は、与えられたユーザーの自宅住所のためのIKEフェーズ2ネゴシエーションは別のユーザによって要求されないことを確実にするためです。モバイルノードでは、我々は単に「USER_1」であることを私たちの地元のIDを設定します。
These checks also imply that the configuration of the home agent is user-specific: every user or home address requires a specific configuration entry. It would be possible to alleviate the configuration tasks by using certificates that have home addresses in the Subject AltName field. However, it is not clear if all IKE implementations allow one address to be used for carrying the IKE negotiations when another address is mentioned in the used certificates. In any case, even this approach would have required user-specific tasks in the certification authority.
これらのチェックは、ホームエージェントの設定はユーザー固有であることを意味するもの：すべてのユーザーや自宅の住所は、特定の構成エントリが必要です。件名ALTNAMEフィールドにホームアドレスを持っている証明書を使用して設定作業を軽減することが可能であろう。すべてのIKEの実装は、1つのアドレスが別のアドレスが使用される証明書に記載されているとき、IKEネゴシエーションを実施するために使用することができるようにする場合は、それが明確ではありません。いずれにせよ、でもこのアプローチは、証明機関にユーザー固有のタスクを必要としました。
Protection for the return routability signaling can be configured in a similar manner as above.
リターン・ルータビリティ・シグナリングのための保護は、上記と同様に構成することができます。
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1
モバイルノードSPD OUT： - home_agent_1＆ソース= home_address_1＆宛先=任意＆プロト= MH THEN USE SA ESPトンネルにインタフェース= IPv6トンネルIF：外側の宛先= home_agent_1＆局所相1人のアイデンティティ= USER_1
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1
INモバイルノードSPD： - ：外側の宛先= home_agent_1＆局所相1人のアイデンティティ= USER_1任意＆宛先= home_address_1＆プロト= MH THEN USE SA ESP TUNNEL = home_agent_1＆源からインターフェイス= IPv6トンネルIF
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1
ホームエージェントSPD OUT： - home_address_1・ソースへのインタフェース= IPv6トンネルIF =任意＆宛先= home_address_1＆プロト= MH THEN USE SA ESPトンネル：外側の宛先= home_address_1＆ピアフェーズ1アイデンティティ= USER_1
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1
ホームエージェントSPD IN： - home_address_1＆ソース= home_address_1＆宛先=任意＆プロト= MH THEN USE SA ESPトンネルからインターフェイス= IPv6トンネルIF：外側の宛先= home_address_1＆ピアフェーズ1アイデンティティ= USER_1
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. The SPD entries can be written using the home address (as above), if the care-of address update in the SAD is also done upon the creation of security associations.
モバイルノードにホームエージェントからのセキュリティアソシエーションが宛先として現在の気付アドレスを使用しています。前述のように、このアドレスは、モバイルノードが移動するようにSADで更新されます。 SADでの気付アドレスの更新は、セキュリティアソシエーションの作成時に行われている場合はSPDエントリは、ホームアドレスを（上記のように）使用して書き込むことができます。
In the following we describe some additional SPD entries to protect prefix discovery with IKE. (Note that when actual new prefixes are discovered, there may be a need to enter new manually configured SPD entries to specify the authorization policy for the resulting new home addresses.)
以下では、IKEとプレフィックス発見を保護するためにいくつかの追加SPDエントリを記述します。 （実際の新しいプレフィックスが発見された場合、結果の新しいホームアドレスのための認可ポリシーを指定するには、新しい手動で構成されたSPDエントリを入力する必要があるかもしれないことに注意してください。）
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
モバイルノードSPD OUT： - ソース= home_address_1＆先= home_agent_1＆プロト= ICMPv6のTHEN USE SA ESP輸送IF：ローカルフェーズ1つのID = USER_1
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
ソース= home_agent_1＆宛先= home_address_1＆プロト= ICMPv6のTHEN USE SA ESP輸送IF：局所相1人のアイデンティティ= USER_1 - ：INモバイルノードSPD
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームエージェントSPD OUT： - IFソース= home_agent_1＆先= home_address_1＆プロト= ICMPv6のは、その後、使用SA ESP TRANSPORT：ピアフェーズ1つのID = USER_1
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
ホームエージェントSPDの場合： - IFソース= home_address_1＆先= home_agent_1＆プロト= ICMPv6のは、その後、使用SA ESP TRANSPORT：ピアフェーズ1つのID = USER_1
Protection for the payload packets happens similarly to the protection of return routability signaling. As in the manually keyed case, these SPD entries have lower priority than the above ones.
ペイロードパケットの保護は、リターン・ルータビリティ・シグナリングの保護と同様に起こります。手動でキー付きの場合のように、これらのSPDエントリは上記のものより低い優先度を有します。
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1
モバイルノードSPD OUT： - home_agent_1＆ソース= home_address_1＆宛先=任意＆プロト= X THEN USE SA ESPトンネルへのインタフェース= IPv6トンネルIF：外側の宛先= home_agent_1＆局所相1人のアイデンティティ= USER_1
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = X THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1
INモバイルノードSPD： - home_agent_1＆源からインターフェイス= IPv6トンネル=＆任意の宛先= home_address_1＆プロト= X THEN USE SA ESPトンネルIF：外側の宛先= home_agent_1＆局所相1アイデンティティ= USER_1
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1
ホームエージェントSPD OUT： - home_address_1・ソースへのインタフェース= IPv6トンネルIF =任意＆宛先= home_address_1＆プロト= X THEN USE SA ESPトンネル：外側の宛先= home_address_1＆ピアフェーズ1人のアイデンティティ= USER_1
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = X THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1
ホームエージェントSPD IN： - home_address_1からインタフェース= IPv6トンネルIF＆ソース= home_address_1＆宛先=任意＆プロト= X THEN USE SA ESPトンネル：外側の宛先= home_address_1＆ピアフェーズ1アイデンティティ= USER_1
Step 1. At the mobile node, Mobile IPv6 module first produces the following packet:
モバイルノードは、ステップ1は、モバイルIPv6モジュールは、第1次のパケットを生成します。
IPv6 header (source = home address, destination = home agent) Mobility header Binding Update
IPv6ヘッダ（ソース=ホームアドレス、宛先=ホームエージェント）の更新をモビリティバインディングヘッダ
Step 2. This packet is matched against the IPsec SPD on the mobile node and we make a note that IPsec must be applied.
ステップ2は、このパケットは、モバイルノード上のIPsec SPDと照合され、我々は、IPsecを適用しなければならないことをメモしておきます。
Step 3. Then, we add the necessary Mobile IPv6 options but do not change the addresses yet, as described in Section 11.3.2 of the base specification [7]. This results in:
基本仕様の11.3.2項で説明したようにステップ3 [7]は、その後、我々は必要なモバイルIPv6オプションを追加したが、まだアドレスを変更しないでください。これは、その結果：
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) Mobility header Binding Update
IPv6のヘッダ（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションは、アップデートをバインディングホームアドレスオプション（気付アドレス）モビリティヘッダヘッダ
Step 4. Finally, IPsec headers are added and the necessary authenticator values are calculated:
ステップ4.最後に、IPsecのヘッダーが追加され、必要な認証子値が計算されます。
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダ（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションは、アップデートをバインディングホームアドレスオプション（気付アドレス）ESPヘッダ（SPI = spi_a）モビリティヘッダヘッダ
Here spi_a is the SPI value that was either configured manually, or agreed upon in an earlier IKE negotiation.
ここspi_aは、手動で構成された、またはそれ以前のIKEネゴシエーションで合意されたSPI値です。
Step 5. Before sending the packet, the addresses in the IPv6 header and the Destination Options header are changed:
パケットを送信する前にステップ5は、IPv6ヘッダと宛先オプションヘッダー内のアドレスが変更されます。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）宛先オプションは、ヘッダーホームアドレスオプション（ホームアドレス）ESPヘッダ（SPI = spi_a）モビリティヘッダバインディング更新
Step 1. The following packet is received at the home agent:
ステップ1次のパケットは、ホームエージェントで受信されます。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）宛先オプションは、ヘッダーホームアドレスオプション（ホームアドレス）ESPヘッダ（SPI = spi_a）モビリティヘッダバインディング更新
Step 2. The home address option is processed first, which results in
ステップ2.ホームアドレスオプションは、その結果、最初に処理されます
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダ（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションは、アップデートをバインディングホームアドレスオプション（気付アドレス）ESPヘッダ（SPI = spi_a）モビリティヘッダヘッダ
Step 3. ESP header is processed next, resulting in
ステップ3. ESPヘッダは、次の処理で得られています
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
Step 4. This packet matches the policy required for this security association (source = home address, destination = home agent, proto = MH).
ステップ4：このパケットは、このセキュリティアソシエーション（ソース=ホームアドレス、宛先=ホームエージェント、プロト= MH）のために必要な政策と一致しました。
Step 5. Mobile IPv6 processes the Binding Update. The Binding Update is delivered to the Mobile IPv6 module.
ステップ5.モバイルIPv6バインディング更新を処理します。バインディングアップデートは、Mobile IPv6モジュールに配信されます。
Step 6. If there are any security associations in the security association database for the protection of return routability or payload packets for this mobile node, those security associations are updated with the new care-of address.
ステップ6いずれかのセキュリティアソシエーションは、このモバイルノードのためのリターン・ルータビリティやペイロードパケットの保護のためのセキュリティアソシエーションデータベースに存在する場合、それらのセキュリティアソシエーションは、新しい気付アドレスで更新されます。
Step 1. Mobile IPv6 produces the following packet:
ステップ1.モバイルIPv6は、次のパケットを生成します。
IPv6 header (source = home agent, destination = home address) Mobility header Binding Acknowledgement
謝辞結合IPv6ヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）モビリティヘッダ
Step 2. This packet matches the IPsec policy entries, and we remember that IPsec has to be applied.
ステップ2.このパケットは、IPsecポリシーエントリと一致し、我々は、IPsecを適用する必要があることを覚えておいてください。
Step 3. Then, we add the necessary Route Headers but do not change the addresses yet, as described in Section 9.5.4 of the base specification [7]. This results in:
そして、ステップ3は、我々は必要なルートヘッダを追加しますが、基本仕様[7]のセクション9.5.4で説明したように、まだアドレスを変更しないでください。これは、その結果：
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address Mobility header Binding Acknowledgement
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）ルーティングヘッダ（タイプ2）気付肯定応答バインディングアドレスモビリティヘッダ
Step 4. We apply IPsec:
ステップ4：私たちは、IPsecを適用します。
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）ルーティングヘッダ（タイプ2）肯定応答を結合気付アドレスのESPヘッダ（SPI = spi_b）モビリティヘッダ
Step 5. Finally, before sending the packet out we change the addresses in the IPv6 header and the Route header:
ステップ5：最後に、アウトパケットを送信する前に、我々はIPv6ヘッダおよびRouteヘッダ内のアドレスを変更します。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
謝辞結合IPv6ヘッダ（ソース=ホーム・エージェント、宛先=気付アドレス）ルーティングヘッダ（タイプ2）のホームアドレスESPヘッダ（SPI = spi_b）モビリティヘッダ
Step 1. The following packet is received at the mobile node
ステップ1.次のパケットは、移動ノードで受信されます
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
謝辞結合IPv6ヘッダ（ソース=ホーム・エージェント、宛先=気付アドレス）ルーティングヘッダ（タイプ2）のホームアドレスESPヘッダ（SPI = spi_b）モビリティヘッダ
Step 2. After the routing header is processed the packet becomes
ルーティングヘッダの後にステップ2パケットとなる処理され
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）ルーティングヘッダ（タイプ2）肯定応答を結合気付アドレスのESPヘッダ（SPI = spi_b）モビリティヘッダ
Step 3. ESP header is processed next, resulting in:
ステップ3. ESPヘッダは、次の処理で得られています。
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address Mobility header Binding Acknowledgement
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=ホームアドレス）ルーティングヘッダ（タイプ2）気付肯定応答バインディングアドレスモビリティヘッダ
Step 4. This packet matches the policy required for this security association (source = home agent, destination = home address, proto = MH).
ステップ4：このパケットは、このセキュリティアソシエーション（ソース=ホームエージェント、先=ホームアドレス、プロト= MH）のために必要な政策と一致しました。
Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 module.
ステップ5.結合確認は、モバイルIPv6モジュールに送達されます。
Step 1. The mobile node constructs a Home Test Init message:
ステップ1.モバイルノードはホーム試験開始メッセージを構築します。
IPv6 header (source = home address, destination = correspondent node) Mobility header Home Test Init
IPv6ヘッダ（ソース=ホームアドレス、宛先=コレスポンデントノード）モビリティヘッダホーム試験開始
Step 2. Mobile IPv6 determines that this packet should go to the tunnel to the home agent.
ステップ2.モバイルIPv6は、このパケットは、ホームエージェントへのトンネルに行く必要があると判断します。
Step 3. The packet is matched against IPsec policy entries for the interface, and we find that IPsec needs to be applied.
パケット3ステップは、インタフェースのためのIPsecポリシーエントリと照合され、そして私たちは、IPsecを適用する必要があることがわかります。
Step 4. IPsec tunnel mode headers are added. Note that we use a care-of address as a source address for the tunnel packet.
ステップ4. IPsecトンネルモードヘッダが追加されます。我々はトンネルパケットの送信元アドレスとして気付アドレスを使用することに注意してください。
IPv6 header (source = care-of address, destination = home agent) ESP header (SPI = spi_c) IPv6 header (source = home address,
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）ESPヘッダ（SPI = spi_c）IPv6ヘッダ（ソース=ホームアドレス、
destination = correspondent node) Mobility header Home Test Init
宛先=コレスポンデントノード）モビリティヘッダホーム試験開始
Step 5. The packet is sent directly to the home agent using IPsec encapsulation.
ステップ5.パケットはIPsecのカプセル化を使用して、ホームエージェントに直接送信されます。
Step 1. The home agent receives the following packet:
ステップ1は、ホームエージェントは、次のパケットを受信します。
IPv6 header (source = care-of address, destination = home agent) ESP header (SPI = spi_c) IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）ESPヘッダ（SPI = spi_c）IPv6ヘッダ（ソース=ホームアドレス、宛先=コレスポンデントノード）モビリティヘッダホーム試験開始
Step 2. IPsec processing is performed, resulting in:
ステップ2. IPsec処理は、結果として行われます。
IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6ヘッダ（ソース=ホームアドレス、宛先=コレスポンデントノード）モビリティヘッダホーム試験開始
Step 3. The resulting packet matches the policy required for this security association and the packet can be processed further.
ステップ3は、得られたパケットは、このセキュリティアソシエーションのために必要なポリシーと一致し、パケットをさらに処理することができます。
Step 4. The packet is then forwarded to the correspondent node.
ステップ4パケットは、コレスポンデントノードに転送されます。
Step 1. The home agent receives a Home Test packet from the correspondent node:
ステップ1は、ホームエージェントは、コレスポンデントノードからホームテストパケットを受信します。
IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダ（ソース=コレスポンデントノード、宛先=ホームアドレス）モビリティヘッダホーム試験開始
Step 2. The home agent determines that this packet is destined to a mobile node that is away from home, and decides to tunnel it.
ステップ2.ホームエージェントは、このパケットがホームから離れているモバイルノード宛であると判断し、トンネルそれに決定します。
Step 3. The packet matches the IPsec policy entries for the tunnel interface, and we note that IPsec needs to be applied.
ステップ3パケットがトンネルインターフェイスのIPsecポリシーエントリと一致し、我々は、IPsecを適用する必要があることに注意してください。
Step 4. IPsec is applied, resulting in a new packet. Note that the home agent must keep track of the location of the mobile node, and update the tunnel endpoint address in the security association(s) accordingly.
ステップ4のIPsecは、新たなパケットが得られ、適用されます。ホームエージェントは、モバイルノードの位置を追跡し、それに応じてセキュリティ・アソシエーション（S）におけるトンネル終点アドレスを更新しなければならないことに注意してください。
IPv6 header (source = home agent, destination = care-of address) ESP header (SPI = spi_d) IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=気付アドレス）ESPヘッダ（SPI = spi_d）IPv6ヘッダ（ソース=コレスポンデントノード、宛先=ホームアドレス）モビリティヘッダホーム試験開始
Step 5. The packet is sent directly to the care-of address using IPsec encapsulation.
ステップ5パケットが気付アドレス使用してIPsecのカプセル化に直接送信されます。
Step 1. The mobile node receives the following packet:
ステップ1は、モバイルノードは、次のパケットを受信します。
IPv6 header (source = home agent, destination = care-of address) ESP header (SPI = spi_d) IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダ（ソース=ホーム・エージェント、宛先=気付アドレス）ESPヘッダ（SPI = spi_d）IPv6ヘッダ（ソース=コレスポンデントノード、宛先=ホームアドレス）モビリティヘッダホーム試験開始
Step 2. IPsec is processed, resulting in:
ステップ2 IPsecが、その結果、処理されます。
IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダ（ソース=コレスポンデントノード、宛先=ホームアドレス）モビリティヘッダホーム試験開始
Step 3. This matches the policy required for this security association (source = any, destination = home address).
ステップ3.これは、このセキュリティアソシエーション（ソース=任意の、先=ホームアドレス）のために必要な政策と一致しました。
Step 4. The packet is given to Mobile IPv6 processing.
パケット4のステップは、モバイルIPv6処理に与えられます。
This procedure is similar to the one presented in Section 6.1.
この手順は、6.1節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.2.
この手順は、6.2節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.3.
この手順は、第6.3節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.4.
この手順は、6.4節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.5.
この手順は、6.5節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.6.
この手順は、6.6節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.7.
この手順は、6.7節で提示したものと同様です。
This procedure is similar to the one presented in Section 6.8.
この手順は、6.8節で提示したものと同様です。
Step 1. The mobile node wishes to send a Binding Update to the home agent.
ステップ1.モバイルノードは、ホームエージェントにバインディングアップデートを送信したいです。
IPv6 header (source = home address, destination = home agent) Mobility header Binding Update
IPv6ヘッダ（ソース=ホームアドレス、宛先=ホームエージェント）の更新をモビリティバインディングヘッダ
Step 2. There is no existing security association to protect the Binding Update, so the mobile node initiates IKE. The IKE packets are sent as shown in the following examples. The first packet is an example of an IKE packet sent from the mobile node, and the second one is from the home agent. The examples shows also that the phase 1 identity used for the mobile node is a FQDN.
ステップ2は、結合更新を保護するために既存のセキュリティアソシエーションはありませんので、モバイルノードは、IKEを開始します。以下の実施例に示すように、IKEパケットが送信されます。最初のパケットは、モバイルノードから送信されたIKEパケットの一例であり、2つ目は、ホームエージェントからのものです。例としては、モバイルノードのために使用される位相1アイデンティティがFQDNであることも示しています。
IPv6 header (source = care-of address, destination = home agent) UDP IKE ... IDii = ID_FQDN mn123.ha.net ...
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）UDP IKE ... IDii = ID_FQDN mn123.ha.net ...
IPv6 header (source = home agent destination = care-of address) UDP IKE ... IDir = ID_FQDN ha.net ...
IPv6ヘッダ（ソース=ホームエージェント先=気付アドレス）UDP IKE ... IDIR = ID_FQDN ha.net ...
Step 3. IKE phase 1 completes, and phase 2 is initiated to request security associations for protecting traffic between the mobile node's home address and the home agent. These addresses will be used as selectors. This involves sending and receiving additional IKE packets. The below example shows again one packet sent by the mobile node and another sent by the home agent. The example shows also that the phase 2 identity used for the mobile node is the mobile node's home address.
ステップ3 IKEのフェーズ1が完了し、フェーズ2は、モバイルノードのホームアドレスとホームエージェント間のトラフィックを保護するためのセキュリティアソシエーションを要求するために開始されます。これらのアドレスは、セレクタとして使用されます。これは、追加のIKEパケットの送受信が含まれます。以下の例では、再びホームエージェントによって送信されたモバイル・ノードと他によって送信された一つのパケットを示しています。一例では、移動ノードのために使用される位相2アイデンティティは、モバイルノードのホームアドレスであることも示しています。
IPv6 header (source = care-of address, destination = home agent) UDP IKE ... IDci = ID_IPV6_ADDR home address ...
IPv6ヘッダ（ソース=気付アドレス、宛先=ホームエージェント）UDP IKE ... IDci = ID_IPV6_ADDRホームアドレス...
IPv6 header (source = home agent, destination = care-of address) UDP IKE ... IDcr = ID_IPV6_ADDR home agent ...
IPv6ヘッダ（ソース=ホームエージェント、先=気付アドレス）UDP IKE ... IDCR = ID_IPV6_ADDRホームエージェント...
Step 4. The remaining steps are as shown in Section 6.1.
6.1節に示すように、ステップ4残りの手順は次のとおりです。
Step 1. The mobile node and the home agent have existing security associations. Either side may decide at any time that the security associations need to be rekeyed, for instance, because the specified lifetime is approaching.
ステップ1.モバイルノードとホームエージェントは、既存のセキュリティアソシエーションを持っています。どちらの側には、指定された寿命が近づいているので、セキュリティアソシエーションは、例えば、リキーする必要が任意の時点で決めることができます。
Step 2. Mobility header packets sent during rekey may be protected by the existing security associations.
キーの再生成時に送信され、ステップ2モビリティヘッダパケットが既存のセキュリティアソシエーションにより保護されていてもよいです。
Step 3. When the rekeying is finished, new security associations are established. In practice there is a time interval during which an old, about-to-expire security association and newly established security association will both exist. The new ones should be used as soon as they become available.
鍵の再生成が終了すると、ステップ3、新しいセキュリティアソシエーションが確立されています。実際には古い約-に期限切れとセキュリティアソシエーションと新たに設立されたセキュリティアソシエーションの両方が存在します、その間の時間間隔があります。新しいものが利用可能になると直ぐに使用すべきです。
Step 4. A notification of the deletion of the old security associations is received. After this, only the new security associations can be used.
ステップ4古いセキュリティアソシエーションの削除通知を受信します。この後、唯一の新しいセキュリティアソシエーションを使用することができます。
Note that there is no requirement that the existence of the IPsec and IKE security associations is tied to the existence of bindings. It is not necessary to delete a security association if a binding is removed, as a new binding may soon be established after this.
IPsecとIKEセキュリティアソシエーションの存在は、バインディングの存在に縛られる必要はないことに注意してください。結合が削除された場合はすぐにこの後に確立することができる新しいバインディングとして、セキュリティアソシエーションを削除する必要はありません。
Since cryptographic acceleration hardware may only be able to handle a limited number of active security associations, security associations may be deleted via IKE in order to keep the number of active cryptographic contexts to a minimum. Such deletions should not be interpreted as a sign of losing a contact to the peer or as a reason to remove a binding. Rather, if additional traffic needs to be sent, it is preferable to bring up another security association to protect it.
暗号加速ハードウェアのみアクティブなセキュリティアソシエーションの限られた数を扱うことができるかもしれないので、セキュリティアソシエーションを最小限に活性な暗号コンテキストの数を維持するためにIKEを介して削除することができます。このような欠失は、ピアへの接触を失うことの徴候として、または結合を除去する理由として解釈されるべきではありません。追加のトラフィックを送信する必要がある場合はむしろ、それを保護するために、別のセキュリティアソシエーションを起動することが好ましいです。
In this section we describe the sequence of events that relate to movement with IKE-based security associations. In the initial state, the mobile node is not registered in any location and has no security associations with the home agent. Depending on whether the peers will be able to move IKE endpoints to new care-of addresses, the actions taken in Step 9 and 10 are different.
このセクションでは、IKEベースのセキュリティアソシエーションと運動に関連する一連のイベントを記述します。初期状態では、モバイルノードは、任意の場所に登録されていないと、ホームエージェントに何のセキュリティアソシエーションを持っていません。ピアは、新たな気付アドレスにIKEのエンドポイントを移動することができるようになりますかどうかに応じて、ステップ9および10で撮影したアクションが異なります。
Step 1. Mobile node with the home address A moves to care-of address B.
ホームアドレスAとステップ1.モバイルノードが気付するアドレスBに移動します
Step 2. Mobile node runs IKE from care-of address B to the home agent, establishing a phase 1. The home agent can only act as the responder before it knows the current location of the mobile node.
ステップ2.モバイルノードは、移動ノードの現在の場所を知っている前に、ホームエージェント1相のみ応答としての役割を果たすことができます確立し、ホームエージェントに気付アドレスBからIKEを実行します。
Step 3. Protected by this phase 1, mobile node establishes a pair of security associations for protecting Mobility Header traffic to and from the home address A.
このフェーズ1で保護されたステップ3、モバイルノードはホームアドレスAにしてから、モビリティヘッダのトラフィックを保護するためのセキュリティアソシエーションのペアを確立します
Step 4. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3.
ステップ4.モバイルノードは、バインディングアップデートを送信し、ステップ3で作成したセキュリティアソシエーションを使用してバインディング確認を受けます。
Step 5. Mobile node establishes a pair of security associations for protecting return routability packets. These security associations are in tunnel mode and their endpoint in the mobile node side is care-of address B. For the purposes of our example, this step uses the phase 1 connection established in Step 2. Multiple phase 1 connections are also possible.
ステップ5モバイルノードは、リターン・ルータビリティ・パケットを保護するためのセキュリティアソシエーションのペアを確立します。これらのセキュリティアソシエーションがトンネルモードにある移動ノード側でのエンドポイントが気付アドレスB.この例の目的のためであり、このステップは1つの接続も可能である。ステップ2複数相で確立フェーズ1接続を使用します。
Step 6. The mobile node uses the security associations created in Step 5 to run return routability.
ステップ6.モバイルノードは、リターン・ルータビリティを実行するには、手順5で作成したセキュリティアソシエーションを使用しています。
Step 7. The mobile node moves to a new location and adopts a new care-of address C.
ステップ7は、モバイルノードが新しい場所に移動し、新しい気付アドレスCを採用しています
Step 8. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3. The home agent ensures that the next packets sent using the security associations created in Step 5 will have the new care-of address as their destination address, as if the outer header destination address in the security association had changed.
ステップ8.モバイルノードは、バインディングアップデートを送信し、ステップ3でホームエージェントを作成したセキュリティアソシエーションを使用してバインディング確認を受信手順5で作成したセキュリティアソシエーションを使用して送信される次のパケットがそのよう新しい気付アドレスを持っていることを保証しセキュリティアソシエーションにおける外部ヘッダの宛先アドレスが変化したかのように、宛先アドレス、。
Step 9. If the mobile node and the HA have the capability to change the IKE endpoints, they change the address to C. If they do not have the capability, both nodes remove their phase 1 connections created on top of the care-of address B and will establish a new IKE phase 1 on top of the care-of address C. This capability to change the IKE phase 1 end points is indicated through setting the Key Management Mobility Capability (K) flag [7] in the Binding Update and Binding Acknowledgement messages.
ステップ9.モバイルノードとHAはIKEのエンドポイントを変更する機能を持っている場合、彼らは能力を持っていない場合、彼らはC.にアドレスを変更し、両方のノードが気付アドレスの上に作成された彼らのフェーズ1つの接続を削除しますB及び気付アドレスのC.上にIKEフェーズ1のエンドポイントを変更するには、この能力を新しいIKEフェーズ1を確立する鍵管理モビリティ機能を設定により示されている（K）フラグ[7]バインディング更新および確認メッセージをバインディング。
Step 10. If a new IKE phase 1 connection was setup after movement, the MN will not be able to receive any notifications delivered on top of the old IKE phase 1 security association. Notifications delivered on top of the new security association are received and processed normally. If the mobile node and HA were able to update the IKE endpoints, they can continue using the same IKE phase 1 connection.
ステップ10.新しいIKEフェーズ1の接続は、移動後に設定した場合、MNは古いIKEフェーズ1セキュリティアソシエーションの上に配信任意の通知を受信することができません。新しいセキュリティアソシエーションの上に配信通知を受信し、正常に処理されます。モバイルノードとHAはIKEエンドポイントを更新することができた場合、それらは同一のIKEフェーズ1接続を使用し続けることができます。
Note that packet formats and header ordering discussed in Section 3 must be supported, but implementations may also support other formats. In general, the use of formats not required here may lead to incorrect processing of the packets by the peer (such as silently discarding them), unless support for these formats has been verified off-line. Such verification can take place at the same time the parameters of the security associations are agreed upon. In some cases, however, basic IPv6 specifications call for support of options not discussed here. In these cases, such a verification step might be unnecessary as long as the peer fully supports the relevant IPv6 specifications. However, no claims are made in this document about the validity of these other formats in the context of Mobile IPv6. It is also likely that systems that support Mobile IPv6 have been tested more extensively with the required formats.
第3節で説明しているパケットフォーマットとヘッダの順序をサポートする必要がありますが、実装はまた、他のフォーマットをサポートすることができます。これらのフォーマットのサポートがオフラインで検証されていない限り、一般的に、ここでは必要とされないフォーマットの使用は、（例えば、静かにそれらを捨てるような）ピアによってパケットの不正確な処理につながる可能性があります。このような検証は、セキュリティアソシエーションのパラメータが合意され、同時に行うことができます。いくつかのケースでは、しかし、基本的なIPv6の仕様は、ここで議論されていないオプションのサポートのために呼び出します。ピアは完全に関連したIPv6の仕様をサポートしているとして、これらのケースでは、このような検証ステップは限り不要かもしれません。しかし、何の主張は、モバイルIPv6のコンテキストでこれらの他の形式の妥当性については、この文書で行われていません。モバイルIPv6をサポートするシステムが必要なフォーマットで、より広範囲にテストされていることもありそうです。
We have chosen to require an encapsulation format for return routability and payload packet protection which can only be realized if the destination of the IPsec packets sent from the home agent can be changed as the mobile node moves. One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet. Such an overhead would not be significant for the protection of the return routability packets, but would create an additional overhead if IPsec is used to protect the tunneling of payload packets to the home agent. This overhead may be significant for real-time traffic. Given that the use of the shorter packet formats for any traffic requires the existence of suitable APIs, we have chosen to require support for the shorter packet formats both for payload and return routability packets.
私たちは、リターン・ルータビリティとホームエージェントから送信されたIPsecパケットの宛先は、移動ノードが移動するように変更することができた場合にのみ実現できるペイロードパケットの保護のためにカプセル化フォーマットを必要とすることを選択しました。そのようなフォーマットを選択するための主な理由の一つは、ホームアドレスオプション又はルーティングヘッダがトンネリングされたパケットに追加されたとき、それは24バイトのオーバーヘッドを除去することです。このようなオーバーヘッドは、リターン・ルータビリティパケットの保護のために重要ではないだろうが、IPsecは、ホームエージェントへのペイロードパケットのトンネリングを保護するために使用されている場合、追加のオーバーヘッドを作成します。このオーバーヘッドは、リアルタイムトラフィックのために重要である可能性があります。すべてのトラフィックのための短いパケットフォーマットの使用が適したAPIの存在が必要であることを考えると、我々は両方のペイロードの短いパケットフォーマットのサポートを必要とし、ルータビリティパケットを返すことを選択しました。
In order to support the care-of address as the destination address on the mobile node side, the home agent must act as if the outer header destination address in the security association to the mobile node would have changed upon movements. Implementations are free to choose any particular method to make this change, such as using an API to the IPsec implementation to change the parameters of the security association, removing the security association and installing a new one, or modification of the packet after it has gone through IPsec processing. The only requirement is that after registering a new binding at the home agent, the next IPsec packets sent on this security association will be addressed to the new care-of address.
モバイルノードへのセキュリティアソシエーションに外部ヘッダの宛先アドレスが移動時に変更されたかのようにモバイルノード側の宛先アドレスとして気付アドレスをサポートするために、ホームエージェントが行動しなければなりません。実装は、それがなくなった後に、このような、セキュリティ関連のパラメータを変更するためにIPsec実装にAPIを使用して、セキュリティ関連付けを削除し、パケットの新しいもの、または修正をインストールすると、この変更を行うために任意の特定の方法を自由に選択できますIPsec処理による。唯一の要件は、ホームエージェントで新しいバインディングを登録した後、このセキュリティアソシエーション上で送信され、次のIPsecパケットは、新たな気付アドレスに宛てされるということです。
We have chosen to require policy entries that are specific to a tunnel interface. This means that implementations have to regard the Home Agent - Mobile Node tunnel as a separate interface on which IPsec SPDs can be based. A further complication of the IPsec processing on a tunnel interface is that this requires access to the BITS implementation before the packet actually goes out.
私たちは、トンネルインターフェイスに固有のポリシーエントリを必要とすることを選択しました。 IPsecのSPDをベースとすることが可能な別のインタフェースとしてモバイルノードのトンネル - これは実装がホームエージェントを考えなければならないことを意味します。トンネルインタフェースでIPsec処理の更なる合併症は、パケットが実際に出る前に、これはBITS実装へのアクセスを必要とすることです。
We have chosen to require that a dynamic key management protocol must be able to make an authorization decision for IPsec security association creation with different addresses than with what the key management protocol is run. We expect this to be done typically by configuring the allowed combinations of phase 1 user identities and home addresses.
我々は、動的な鍵管理プロトコルは、鍵管理プロトコルが実行されているものとは異なるアドレスとのIPsecセキュリティアソシエーションを作成するための認可決定を行うことができなければならないことを要求することを選択しました。私たちは、これがフェーズ1ユーザーIDとホームアドレスの許可の組み合わせを設定することで、一般的に行われることを期待しています。
When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even with single certificates if they are large. Many firewalls do not handle fragments properly, and may drop them. Routers in the path may also discard fragments after the initial one, since they typically will not contain full IP headers that can be compared against an access list. Where fragmentation occurs, the endpoints will not always be able to establish a security association.
証明書認証を使用する場合、IKEの断片化が発生することができます。彼らが大きい場合、これは証明書チェーンが使用された場合に発生、または単一の証明書を持つことができます。多くのファイアウォールが適切に断片を処理していないし、それらをドロップすることがあります。彼らは通常、アクセスリストと比較することができ、完全なIPヘッダを含んでいますので、パス内のルータはまた、最初の1の後の断片を破棄してもよいです。断片化が発生した場合、エンドポイントは、常にセキュリティアソシエーションを確立することができません。
Fortunately, typical Mobile IPv6 deployment uses short certificate chains, as the mobile node is communicating directly with its home network. Where the problem appears, it may be difficult (at least away from home) to replace the firewalls or routers with equipment that can properly support fragments. It may help to store the peer certificates locally, or to obtain them through other means.
モバイルノードがそのホームネットワークと直接通信しているよう幸いなことに、典型的なモバイルIPv6の展開は、短い証明書チェーンを使用しています。問題が表示された場合は、それが適切に断片を支援することができる機器でファイアウォールやルータを交換するために（少なくとも自宅から離れて）難しいかもしれません。これは、ローカルピア証明書を保存するために、または他の手段を介してそれらを取得するのを助けることができます。
Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As Mobile IPv6 specific modifications of the packets are required before or after IPsec processing, the BITS implementation has to perform also some tasks related to mobility. This may increase the complexity of the implementation, even if it already performs some tasks of the IP layer (such as fragmentation).
モバイルIPv6は、IPsecのいわゆるバンプ・イン・ザ・スタック（BITS）実装モデルのための高い要求を設定します。パケットのモバイルIPv6特定の修正がIPsec処理の前または後に必要とされるように、BITS実装はまた、モビリティに関連するいくつかのタスクを実行しなければなりません。これは既に（例えば断片として）IP層のいくつかのタスクを実行しても、実装の複雑さを増加させることができます。
Specifically, Bump-in-the-Stack implementations may have to deal with the following issues:
具体的には、バンプ・イン・スタックの実装は、次の問題に対処しなければならないことがあります。
o Processing the Home Address destination option and Routing header type 2 to a form suitable for IPsec processing to take place. This is needed, among other things, for the security association and policy lookups. While relatively straightforward, the required processing may have a hardware effect in BITS implementations, if they use hardware support beyond the cryptographic operations.
Oホームアドレス宛先オプションを処理し、場所を取るためにIPsec処理に適した形式にヘッダタイプ2のルーティング。これは、セキュリティアソシエーションとポリシールックアップのために、とりわけ、必要とされています。比較的簡単ながら、彼らは暗号化操作を越えたハードウェアサポートを使用する場合、必要な処理は、BITS実装で、ハードウェアの効果を有することができます。
o Detecting packets sent between the mobile node and its home agent using IPv6 encapsulation.
IPv6のカプセル化を使用して、モバイルノードとそのホームエージェントとの間で送信されたパケットを検出するO。
o Offering the necessary APIs for updating the IPsec and IKE security association endpoints.
IPsecとIKEセキュリティアソシエーションのエンドポイントを更新するために必要なAPIを提供し、O。
No IANA actions are necessary based on this document. IANA actions for the Mobile IPv6 protocol itself have been covered in [7].
いいえIANAのアクションは、この文書に基づいて必要ありません。モバイルIPv6プロトコル自体のIANAのアクションは、[7]でカバーされています。
The Mobile IPv6 base specification [7] requires strong security between the mobile node and the home agent. This memo discusses how that security can be arranged in practice, using IPsec. The security considerations related to this are documented in the base specification, including a discussion of the implications of using either manual or dynamic keying.
モバイルIPv6ベース仕様[7]は、移動ノードとホームエージェントとの間の強力なセキュリティを必要とします。このメモは、そのセキュリティはIPsecを使用して、実際に配置することができる方法について説明します。これに関連したセキュリティ上の考慮事項は、手動または動的キーのいずれかを使用しての影響の議論を含め、基本仕様に記載されています。
[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] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[3]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[4]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[6]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[7]ジョンソン、D.、パーキンス、C.とJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[8]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9]デアリング、S.、フェナー、W.およびB.ハーバーマン、 "マルチキャストリスナ発見IPv6の（MLD）"、RFC 2710、1999年10月。
[10] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[10] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.及びM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、 2003年7月。
[11] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[11]ヴィーダ、R.とL.コスタ、編、 "マルチキャストリスナ発見バージョン2（MLDv2の）IPv6のため"、RFC 3810、2004年6月。
The authors would like to thank Greg O'Shea, Michael Thomas, Kevin Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel Montenegro, Steven Kent, and Santeri Paavolainen for interesting discussions in this problem space.
著者は、この問題空間で興味深い議論をグレッグ・オシェイ、マイケル・トーマス、ケビン・マイルズ、シェリルMadson、バーナードAboba、エリックNordmarkと、ガブリエルモンテネグロ、スティーブン・ケント、およびサンテリPaavolainenに感謝したいと思います。
Jari Arkko Ericsson 02420 Jorvas Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
ビジェイDevarapalliノキア・リサーチセンター313フェアチャイルドドライブマウンテンビューCA 94043 USA
EMail: vijayd@iprg.nokia.com
メールアドレス：vijayd@iprg.nokia.com
Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
フランシス・デュポンENSTブルターニュキャンパスレンヌ2、RUE・デ・ラ・Chataigneraie CS 17607 35576セッソンセビニェセデックスフランス
EMail: Francis.Dupont@enst-bretagne.fr
メールアドレス：Francis.Dupont@enst-bretagne.fr
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。