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