[要約] RFC 5454は、Dual-Stack Mobile IPv4プロトコルに関する要件と手順を提供するものであり、IPv4ネットワーク上でモバイルデバイスの移動性をサポートすることを目的としています。
Network Working Group G. Tsirtsis
Request for Comments: 5454 V. Park
Category: Standards Track Qualcomm
H. Soliman
Elevate Technologies
March 2009
Dual-Stack Mobile IPv4
デュアルスタックモバイルIPv4
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures.
この仕様は、モバイルIPv4プロトコルへのIPv6拡張機能を提供します。拡張機能により、デュアルスタックノードがIPv4およびIPv6ホームアドレスを使用し、IPv4とデュアルスタックネットワークインフラストラクチャ間を移動できます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
1.2. Goals ......................................................3
1.3. Non-Goals ..................................................4
1.4. Implicit and Explicit Modes ................................4
2. Extension Formats ...............................................4
2.1. IPv6 Prefix Request Extension ..............................4
2.2. IPv6 Prefix Reply Extension ................................5
2.3. IPv6 Tunneling Mode Extension ..............................7
3. Mobile IP Registrations .........................................8
3.1. Registration Request .......................................8
3.2. Registration Reply .........................................8
3.3. Home Agent Considerations ..................................9
3.3.1. IPv6 Reachability ..................................10
3.3.2. Processing Intercepted IPv6 Packets ................10
3.3.3. IPv6 Multicast Membership Control ..................12
3.4. Foreign Agent Considerations ..............................12
3.5. Mobile Node Considerations ................................12
3.6. Tunneling Impacts .........................................13
3.7. IPv6 Prefixes .............................................14
3.7.1. Dynamic IPv6 Prefix Delegation .....................14
3.8. Deregistration of IPv6 Prefix .............................15
3.9. Registration with a Private CoA ...........................15
4. Security Considerations ........................................15
5. IANA Considerations ............................................16
6. Acknowledgements ...............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to maintain communications while moving in an IPv4 network.
モバイルIPv4 [RFC3344]を使用すると、IPv4アドレスを備えたモバイルノードを使用して、IPv4ネットワークで移動しながら通信を維持できます。
Extensions defined in this document allow a node that has IPv4 and IPv6 addresses [RFC2460] to maintain communications through any of its addresses while moving in IPv4 or dual stack networks.
このドキュメントで定義されている拡張機能により、IPv4およびIPv6アドレス[RFC2460]を備えたノードが、IPv4またはデュアルスタックネットワークで移動しながら、アドレスのいずれかを通じて通信を維持できます。
Essentially, this specification separates the Mobile IPv4 signaling from the IP version of the traffic it tunnels. Mobile IPv4 with the present extensions remains a signaling protocol that runs over IPv4, and yet can set up both IPv4 and IPv6 tunnels over IPv4.
基本的に、この仕様は、モバイルIPv4シグナル伝達をトラフィックITトンネルのIPバージョンから分離します。現在の拡張機能を備えたモバイルIPv4は、IPv4を介して実行されるが、IPv4とIPv6トンネルの両方をIPv4に設定することができるシグナル伝達プロトコルのままです。
The aim is two-fold:
目的は2つあります：
On one hand, Mobile IPv4 with the present extensions becomes a useful transition mechanism, allowing automated but controlled tunneling of IPv6 traffic over IPv4 tunnels. Dual-stack nodes in dual-stack home networks can now roam to and from legacy IPv4 networks, while IPv4 mobile nodes and networks can migrate to IPv6 without changing mobility management, and without upgrading all network nodes to IPv6 at once.
一方では、現在の拡張機能を備えたモバイルIPv4が有用な遷移メカニズムになり、IPv4トンネル上のIPv6トラフィックの自動化されたが制御されたトンネルが可能になります。デュアルスタックホームネットワークのデュアルスタックノードは、Legacy IPv4 Networksとの間で往復できるようになりましたが、IPv4モバイルノードとネットワークはモビリティ管理を変更せずにIPv6に移行し、すべてのネットワークノードを一度にアップグレードすることなく移行できます。
On the other hand, and more importantly, it allows dual-stack mobile nodes and networks to utilize a single protocol for the movement of both IPv4 and IPv6 stacks in the network topology.
一方、さらに重要なことに、デュアルスタックのモバイルノードとネットワークは、ネットワークトポロジ内のIPv4スタックとIPv6スタックの両方を移動するための単一のプロトコルを利用できます。
Note that features like Mobile IPv6 [RFC3775] style route optimization will not be possible with this solution as it still relies on Mobile IPv4 signaling, which does not provide route optimization.
モバイルIPv6 [RFC3775]スタイルルートの最適化などの機能は、ルートの最適化を提供しないモバイルIPv4シグナル伝達に依然として依存しているため、このソリューションでは不可能です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
a. The solution supports the registration of IPv6 home prefix(es) in addition to regular IPv4 home address (HoA) registration.
a. このソリューションは、通常のIPv4ホームアドレス（HOA）登録に加えて、IPv6ホームプレフィックス（ES）の登録をサポートします。
b. The solution supports static and dynamic IPv6 prefix delegation.
b. このソリューションは、静的および動的IPv6プレフィックス委任をサポートします。
a. The solution does not provide support for IPv6 care-of address (CoA) registration.
a. このソリューションは、IPv6 Care-of Address（COA）登録のサポートを提供していません。
As defined in Network Mobility (NEMO) [RFC3963], this specification also supports two modes of operation; the implicit mode and the explicit mode.
ネットワークモビリティ（NEMO）[RFC3963]で定義されているように、この仕様は2つの動作モードもサポートしています。暗黙的なモードと明示的なモード。
In the implicit mode, the mobile node does not include any IPv6 prefix request extensions in the registration request. The home agent can use any mechanism (not defined in this document) to determine the IPv6 prefix(es) owned by the mobile node and to set up forwarding for these prefixes. In this mode of operation, all traffic to and from the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between the mobile node's IPv4 home address and the IPv4 address of the home agent, and as such, it is transparent to any foreign agent in the path. This IPv4 tunnel is established by mechanisms that are out of the scope of this document on both the mobile node and home agent when operating in the implicit mode.
暗黙的なモードでは、モバイルノードには登録要求にIPv6プレフィックスリクエスト拡張機能が含まれていません。ホームエージェントは、任意のメカニズム（このドキュメントで定義されていない）を使用して、モバイルノードが所有するIPv6プレフィックス（ES）を決定し、これらのプレフィックスの転送をセットアップできます。この動作モードでは、IPv6プレフィックスとのすべてのトラフィックは、モバイルノードのIPv4ホームアドレスとホームエージェントのIPv4アドレスの間のIPv4トンネルを介してカプセル化する必要があります。道。このIPv4トンネルは、暗黙的なモードで操作する際に、モバイルノードとホームエージェントの両方でこのドキュメントの範囲外のメカニズムによって確立されます。
In the explicit mode, IPv6 bindings are signaled explicitly. The mobile node includes one or more IPv6 prefix request extensions in the registration request, while the home agent returns corresponding IPv6 prefix reply extensions to accept/reject the IPv6 bindings.
明示的なモードでは、IPv6バインディングは明示的に信号を送られます。モバイルノードには、登録要求に1つ以上のIPv6プレフィックスリクエスト拡張機能が含まれ、ホームエージェントは対応するIPv6プレフィックス応答拡張機能を返し、IPv6バインディングを受け入れ/拒否します。
Additionally, in the explicit mode, the mobile node (when co-located mode of operation is used) can indicate whether IPv6 traffic should be tunneled to the care-of address or the home address of the mobile node.
さらに、明示的なモードでは、モバイルノード（コロアティングされた動作モードが使用される場合）は、IPv6トラフィックをモバイルノードのケアオブアドレスまたはホームアドレスにトンネルする必要があるかどうかを示します。
The rest of this specification is primarily defining the explicit mode.
この仕様の残りの部分は、主に明示的なモードを定義しています。
The following extensions are defined according to this specification.
次の拡張機能は、この仕様に従って定義されています。
A new skippable extension to the Mobile IPv4 registration request message in accordance to the short extension format of [RFC3344] is defined here.
[RFC3344]の短い拡張形式に従って、モバイルIPv4登録要求メッセージの新しいスキップ可能な拡張機能をここで定義します。
This extension contains a Mobile IPv6 network prefix and its prefix length.
この拡張機能には、モバイルIPv6ネットワークプレフィックスとそのプレフィックス長が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Prefix Request Extension
図1：IPv6プレフィックス要求拡張機能
Type
タイプ
152 (Dual-Stack Mobile IPv4 (DSMIPv4) Extension)
152（デュアルスタックモバイルIPv4（DSMIPV4）拡張）
Length
長さ
18
18
Subtype
サブタイプ
1 (IPv6 Prefix Request)
1（IPv6プレフィックスリクエスト）
Prefix Length
プレフィックスの長さ
A sixteen-byte field containing the Mobile IPv6 Network Prefix; all insignificant (low-order) bits (beyond the Prefix Length) MUST be set to 0 by the originator of the option and ignored by the receiver.
モバイルIPv6ネットワークプレフィックスを含む16バイトのフィールド。すべての取るに足らない（低次の）ビット（プレフィックスの長さを超えて）は、オプションのオリジネーターによって0に設定され、受信機によって無視する必要があります。
Mobile IPv6 Network Prefix
モバイルIPv6ネットワークプレフィックス
A sixteen-byte field containing the Mobile IPv6 Network Prefix
モバイルIPv6ネットワークプレフィックスを含む16バイトのフィールド
A new skippable extension to the Mobile IPv4 registration reply message in accordance to the short extension format of [RFC3344] is defined here.
[RFC3344]の短い拡張形式に従って、モバイルIPv4登録返信メッセージの新しいスキップ可能な拡張機能をここで定義します。
This extension defines a Mobile IPv6 Network Prefix and its prefix length, as well as a code.
この拡張機能は、モバイルIPv6ネットワークのプレフィックスとそのプレフィックスの長さ、およびコードを定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Prefix Reply Extension
図2：IPv6プレフィックス応答拡張機能
Type
タイプ
152 (DSMIPv4 Extension)
152（dsmipv4拡張）
Length
長さ
20
20
Subtype
サブタイプ
2 (IPv6 Prefix Reply)
2（IPv6プレフィックス返信）
Code
コード
A value indicating the result of the registration request with respect to the IPv6 home prefix registration. See below for currently defined Codes.
IPv6ホームプレフィックス登録に関する登録要求の結果を示す値。現在定義されているコードについては、以下を参照してください。
Prefix Length
プレフィックスの長さ
Indicates the prefix length of the prefix included in the Mobile IPv6 Network Prefix field. A value of 255 indicates that a link-local address is included in the Mobile IPv6 Network Prefix field.
モバイルIPv6ネットワークプレフィックスフィールドに含まれるプレフィックスのプレフィックスの長さを示します。255の値は、リンクローカルアドレスがモバイルIPv6ネットワークプレフィックスフィールドに含まれていることを示しています。
Reserved
予約済み
Set to 0 by the sender, ignored by the receiver
送信者によって0に設定され、受信機によって無視されます
Mobile IPv6 Network Prefix
モバイルIPv6ネットワークプレフィックス
A sixteen-byte field containing the Mobile IPv6 Network Prefix; all insignificant (low-order) bits (beyond the Prefix Length) MUST be set to 0 by the originator of the option and ignored by the receiver.
モバイルIPv6ネットワークプレフィックスを含む16バイトのフィールド。すべての取るに足らない（低次の）ビット（プレフィックスの長さを超えて）は、オプションのオリジネーターによって0に設定され、受信機によって無視する必要があります。
The following values are defined for use as a Code value in the above extension:
次の値は、上記の拡張子のコード値として使用するために定義されています。
0 registration accepted, IPv6 to be tunneled to HoA
0登録が受け入れられ、IPv6がHOAにトンネリングされる
1 registration accepted, IPv6 to be tunneled to CoA
1件の登録が受け入れられ、IPv6がCOAにトンネリングされます
8 registration rejected, reason unspecified
8登録が拒否された、理由が特定されていない理由
9 registration rejected, administratively prohibited
9登録が拒否され、管理上禁止されています
Note that a registration reply that does not include an IPv6 prefix reply extension, when received in response to a registration request carrying at least one instance of the IPv6 prefix request extension, indicates that the home agent does not support IPv6 extensions and thus has ignored such extensions in the registration request.
IPv6プレフィックスリクエスト拡張の少なくとも1つのインスタンスを運ぶ登録要求に応じて受信した場合、IPv6プレフィックス応答拡張機能を含めない登録応答は、ホームエージェントがIPv6拡張機能をサポートせず、したがってそのようなことを無視していることを示していることに注意してください。登録リクエストの拡張機能。
A new skippable extension to the Mobile IPv4 registration request message in accordance to the short extension format of [RFC3344] is defined here.
[RFC3344]の短い拡張形式に従って、モバイルIPv4登録要求メッセージの新しいスキップ可能な拡張機能をここで定義します。
By including this extension in a registration request, the sender indicates that IPv6 traffic can be tunneled to the mobile node's CoA.
この拡張機能を登録リクエストに含めることにより、送信者は、IPv6トラフィックをモバイルノードのCOAにトンネル化できることを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Tunneling Mode Extension
図3：IPv6トンネルモード拡張
Type
タイプ
152 (DSMIPv4 Extension)
152（dsmipv4拡張）
Length
長さ
2
2
Subtype
サブタイプ
3 (IPv6 Tunneling Mode)
3（IPv6トンネルモード）
Reserved
予約済み
Set to 0 by the sender, ignored by the receiver
送信者によって0に設定され、受信機によって無視されます
A mobile node MAY include in a registration request one or more IPv6 prefix request extensions defined in this specification.
モバイルノードには、登録要求に、この仕様で定義されている1つ以上のIPv6プレフィックスリクエスト拡張機能を含めることができます。
A mobile node MAY also include exactly one IPv6 tunneling mode extension when it uses the co-located care-of address mode of [RFC3344].
モバイルノードには、[RFC3344]の共同配置されたケアオブアドレスモードを使用する場合、正確に1つのIPv6トンネルモード拡張機能を含めることもできます。
When IPv6 prefix and/or IPv6 tunneling mode extensions are used by the mobile IP client, they MUST be placed after the registration request header and before the mobile -- home authentication extension so they MUST be included in the computation of any authentication extension.
IPv6プレフィックスおよび/またはIPv6トンネルモード拡張機能がモバイルIPクライアントによって使用される場合、登録要求ヘッダーの後、モバイル - ホーム認証拡張機能の前に配置する必要があります。
The mechanism described in this specification depends on skippable extensions. For that reason, a registration reply that does not include an IPv6 prefix reply extension, in response to a registration request including an IPv6 prefix request extension, indicates that the home agent does not support IPv6 extensions and has ignored the request.
この仕様で説明されているメカニズムは、スキップ可能な拡張機能に依存します。そのため、IPv6プレフィックスリクエスト拡張機能を含む登録要求に応じて、IPv6プレフィックス応答拡張機能を含む登録応答は、ホームエージェントがIPv6拡張機能をサポートせず、リクエストを無視していることを示します。
If an IPv6 prefix reply extension is included in a registration reply, then the extension indicates the success or failure of the IPv6 prefix registration. The IPv6 prefix reply extension does not affect, in any way, the code value in the registration reply header but it is superseded by it. In other words, if the code field in the registration reply header is set to a reject code, then all IPv6 prefix request extensions are also rejected. If the code field in the registration reply header, however, is set to an accept code, then an IPv6 prefix reply extension with a code field set to a reject code only rejects the binding for the specific IPv6 prefix indicated in the same extension.
IPv6プレフィックス返信拡張子が登録返信に含まれている場合、拡張機能はIPv6プレフィックス登録の成功または失敗を示します。IPv6プレフィックスの応答拡張機能は、登録応答ヘッダーのコード値には影響しませんが、それによって置き換えられます。つまり、登録返信ヘッダーのコードフィールドが拒否コードに設定されている場合、すべてのIPv6プレフィックスリクエスト拡張機能も拒否されます。ただし、登録応答ヘッダーのコードフィールドがAcceptコードに設定されている場合、拒否コードに設定されたコードフィールドを使用したIPv6プレフィックス応答拡張機能は、同じ拡張子に示されている特定のIPv6プレフィックスのバインディングのみを拒否します。
Note that a rejecting IPv6 prefix reply extension has the same effect as not including such an extension at all, in the sense that, in both cases, the mobile node must act as if the corresponding IPv6 prefix request extension included in the registration request was rejected. Of course, the inclusion of the IPv6 prefix reply extension allows the home agent to indicate why a given IPv6 prefix request extension was rejected. A detailed description of how the mobile node handles different IPv6 prefix reply extension code values and the absence of IPv6 prefix reply extensions is given in Section 3.5.
拒否IPv6プレフィックスの返信拡張機能は、どちらの場合も、モバイルノードが登録要求に含まれる対応するIPv6プレフィックスリクエスト拡張機能が拒否されたかのように動作する必要があるという意味で、そのような拡張機能をまったく含めないのと同じ効果があることに注意してください。。もちろん、IPv6プレフィックスの応答拡張機能を含めることで、ホームエージェントが特定のIPv6プレフィックスリクエスト拡張機能が拒否された理由を示すことができます。モバイルノードがさまざまなIPv6プレフィックス応答拡張コード値を処理する方法の詳細な説明とIPv6プレフィックス応答拡張機能の欠如は、セクション3.5に記載されています。
The dual-stack home agent defined in this specification is a Mobile IPv4 home agent in that, it MUST operate as defined in MIPv4 [RFC3344]. In addition to that, the following mechanisms are defined in this specification.
この仕様で定義されているデュアルスタックホームエージェントは、MIPV4 [RFC3344]で定義されているように動作する必要があるという点で、モバイルIPv4ホームエージェントです。それに加えて、この仕様では次のメカニズムが定義されています。
For each IPv6 prefix request extension included in a valid registration request, a home agent that supports this specification SHOULD include a corresponding IPv6 prefix reply extension in the registration reply message. The home agent MUST NOT include more than one IPv6 prefix reply extension for the same prefix. For each accepted IPv6 prefix, the home agent MUST decide the tunneling mode it is going to use and set the code field of the IPv6 prefix reply extension to the appropriate value. The IPv6 prefix field of each of the IPv6 prefix reply extensions included in the registration reply MUST match the IPv6 prefix field of an IPv6 prefix request extension included in the corresponding registration request message.
有効な登録要求に含まれる各IPv6プレフィックスリクエスト拡張機能について、この仕様をサポートするホームエージェントには、登録応答メッセージに対応するIPv6プレフィックス返信拡張機能を含める必要があります。ホームエージェントは、同じプレフィックスに複数のIPv6プレフィックスReply拡張子を含めてはなりません。受け入れられているIPv6プレフィックスごとに、ホームエージェントは、使用するトンネリングモードを決定し、IPv6プレフィックスのコードフィールドを適切な値に設定する必要があります。登録に含まれるIPv6プレフィックスの各プレフィックス応答拡張機能のIPv6プレフィックスフィールドは、対応する登録要求メッセージに含まれるIPv6プレフィックスリクエスト拡張機能のIPv6プレフィックスフィールドと一致する必要があります。
When the home agent sends a successful registration reply to the mobile node, with the code field of a corresponding IPv6 prefix reply extension set to one of the "registration accepted" values, the home agent indicates that the IPv6 prefix is registered for the lifetime granted for the binding. It also indicates the tunneling mode used i.e., tunneling to home address or care-of address, based on the value of the code field used in the IPv6 prefix reply extension.
ホームエージェントがモバイルノードに成功した登録返信を送信すると、対応するIPv6プレフィックス応答のコードフィールドが「登録が受け入れられた」値の1つに設定されている場合、ホームエージェントは、IPv6プレフィックスが付与された生涯に登録されていることを示します。バインディングのために。また、IPv6プレフィックス応答拡張機能で使用されているコードフィールドの値に基づいて、使用されたトンネルモード、つまり自宅の住所へのトンネリングまたはケアオブアドレスを示します。
Note that since only IPv6 prefixes (and not addresses) are supported by this specification, there is no need for Duplicate Address Detection. The home agent, however, MUST check that registered prefixes are not overlapping so that all addresses under each registered prefix belong to a single mobile node at any one time. These prefixes MUST NOT appear as on-link to any other node (e.g., via Router Advertisements).
この仕様ではIPv6プレフィックスのみ（アドレスではない）のみがサポートされているため、アドレスの重複検出は必要ありません。ただし、ホームエージェントは、登録されたプレフィックスが重複していないことを確認する必要があり、登録された各プレフィックスの下のすべてのアドレスが一度に単一のモバイルノードに属しているようにする必要があります。これらのプレフィックスは、他のノード（例えば、ルーター広告を介して）にオンリンクとして表示されてはなりません。
For each registered IPv6 prefix, the home agent MUST advertise its reachability as defined in NEMO Section 6.3 of [RFC3963].
登録されたIPv6プレフィックスごとに、ホームエージェントは[RFC3963]のNEMOセクション6.3で定義されているように、その到達可能性を宣伝する必要があります。
A dual-stack home agent that supports the IPv6 extensions defined in this specification MUST keep track of the following IPv6 related state for the mobile nodes it supports, in addition to the state defined in [RFC3344].
この仕様で定義されているIPv6拡張機能をサポートするデュアルスタックホームエージェントは、[RFC3344]で定義されている状態に加えて、サポートするモバイルノードの次のIPv6関連状態を追跡する必要があります。
- Registered IPv6 prefix(es) and prefix length(s).
- 登録されたIPv6プレフィックス（ES）とプレフィックスの長さ。
- Tunneling mode for IPv6 traffic:
- IPv6トラフィックのトンネルモード：
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA.
- IPv4 HOAへのトンネルとIPv4HOAからトンネルを掲載したIPv6を受け入れます。
- Tunnel to CoA and accept IPv6 tunneled from CoA.
- COAにトンネルし、COAからトンネルを受けたIPv6を受け入れます。
When IPv6 traffic is encapsulated over the tunnel between the home agent (HA) and the mobile node's care-of address, the tunneling mechanism used should be the same as the mechanism negotiated by the Mobile IP header as defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. Generic Routing Encapsulation (GRE) also allows tunneling of IPv6 packets by setting the Protocol Type [RFC2784] field, to the appropriate payload type defined for IPv6 by IANA. Minimal Encapsulation [RFC2004] cannot be used, since the second (inner) IP header is IPv6, which is not supported by [RFC2004].
IPv6のトラフィックがホームエージェント（HA）とモバイルノードのケアオブアドレスの間のトンネルにカプセル化されている場合、使用されるトンネリングメカニズムは、MIPV4 [RFC3344]で定義されているように、モバイルIPヘッダーによって交渉されたメカニズムと同じでなければなりません。その場合、IPINIPカプセル化が交渉されると、[RFC4213]に従ってIPv6がIPv4を介してトンネル化されます。ジェネリックルーティングカプセル化（GRE）により、IANAが定義された適切なペイロードタイプにプロトコルタイプ[RFC2784]フィールドを設定することにより、IPv6パケットのトンネルも可能になります。2番目の（内側の）IPヘッダーは[RFC2004]でサポートされていないため、最小限のカプセル化[RFC2004]は使用できません。
When IPv6 traffic is encapsulated over the tunnel between the HA and the mobile node's home address, IPv6 is always tunneled over IPv4 according to [RFC4213]. The resulting IPv4 packet is then delivered just like any other IPv4 packet addressed to the IPv4 HoA (using the tunneling for normal IPv4 traffic, possibly going via the foreign agent (FA)).
IPv6のトラフィックがHAとモバイルノードのホームアドレスの間のトンネルを介してカプセル化されると、[RFC4213]に従ってIPv6は常にIPv4を介してトンネル化されます。結果のIPv4パケットは、IPv4HOAにアドレス指定された他のIPv4パケットと同じように配信されます（通常のIPv4トラフィックのトンネルを使用して、おそらく外国人エージェント（FA）を介して進む）。
Tunneling mode selection for IPv6 traffic depends on the following parameters in a successful registration request:
IPv6トラフィックのトンネルモードの選択は、登録リクエストの成功した次のパラメーターに依存します。
1) A registration request is received with one or more IPv6 prefix request extensions. An IPv6 tunneling mode extension is not included.
1) 登録リクエストは、1つ以上のIPv6プレフィックスリクエスト拡張機能で受信されます。IPv6トンネルモード拡張は含まれていません。
All IPv6 packets destined to the registered IPv6 prefix(es) MUST be tunneled by the home agent to the registered IPv4 home address of the mobile node. The home agent first encapsulates the IPv6 packet, addressing it to the mobile node's IPv4 home address, and then tunnels this encapsulated packet to the foreign agent. This extra level of encapsulation is required so that IPv6 routing remains transparent to a foreign agent that does not support IPv6. When received by the foreign agent, the unicast encapsulated packet is de-tunneled and delivered to the mobile node in the same way as any other packet. The mobile node must decapsulate the received IPv4 packet in order to recover the original IPv6 packet.
登録されているIPv6プレフィックス（ES）に向けられたすべてのIPv6パケットは、ホームエージェントによってモバイルノードの登録されたIPv4ホームアドレスにトンネルを付ける必要があります。ホームエージェントは最初にIPv6パケットをカプセル化し、モバイルノードのIPv4ホームアドレスにアドレス指定し、次にこのカプセル化されたパケットを外国人エージェントにトンネルします。IPv6ルーティングは、IPv6をサポートしていない外国人エージェントに対して透明なままであるため、この余分なレベルのカプセル化が必要です。外国のエージェントが受信すると、ユニキャストのカプセル化されたパケットはターンネリングされ、他のパケットと同じ方法でモバイルノードに配信されます。モバイルノードは、元のIPv6パケットを回復するために、受信したIPv4パケットを脱カプセル化する必要があります。
Additionally, the home agent MUST be prepared to accept reverse-tunneled packets from the IPv4 home address of the mobile node encapsulating IPv6 packets sent by that mobile node.
さらに、ホームエージェントは、そのモバイルノードによって送信されたIPv6パケットをカプセル化するモバイルノードのIPv4ホームアドレスから逆タンネルパケットを受け入れる準備をする必要があります。
2) A registration request is received with one or more IPv6 prefix request extensions. An IPv6 tunneling mode extension is included.
2) 登録リクエストは、1つ以上のIPv6プレフィックスリクエスト拡張機能で受信されます。IPv6トンネルモード拡張機能が含まれています。
All IPv6 packets destined to the registered IPv6 prefix(es) SHOULD be tunneled by the home agent to the registered care-of address of the mobile node. Additionally, the home agent SHOULD be prepared to accept reverse-tunneled packets from the care-of address of the mobile node encapsulating IPv6 packets sent by that mobile node. The home agent MAY ignore the presence of the IPv6 tunneling mode extension and act as in case (1) above.
登録されているIPv6プレフィックス（ES）に導かれるすべてのIPv6パケットは、ホームエージェントによってモバイルノードの登録されたケアオブアドレスにトンネリングする必要があります。さらに、ホームエージェントは、そのモバイルノードによって送信されたIPv6パケットをカプセル化するモバイルノードのケアのケアから逆タンネルパケットを受け入れる準備をする必要があります。ホームエージェントは、IPv6トンネルモード拡張の存在を無視し、上記の場合のように機能する場合があります。
The home agent MUST check that all inner IPv6 packets received from the mobile node over a tunnel with the mobile node's home address or the care-of address as the outer source address, include a source address that falls under the registered IPv6 prefix(es) for that mobile node. If the source address of the outer header of a tunneled packet is not the registered IPv4 care-of address or the registered IPv4 home addresses, the packet SHOULD be dropped. If the source address of the inner header of an tunneled packet does not match any of the registered prefixes, the packet SHOULD be dropped.
ホームエージェントは、モバイルノードのホームアドレスを備えたトンネル上のモバイルノードから受信したすべての内側のIPv6パケットまたは外部ソースアドレスとしてのケアオブアドレスを含むことを確認する必要があります。そのモバイルノード用。トンネルパケットの外側ヘッダーのソースアドレスが登録されているIPv4のケアオブアドレスまたは登録されているIPv4ホームアドレスではない場合、パケットをドロップする必要があります。トンネルパケットの内側ヘッダーのソースアドレスが登録されたプレフィックスのいずれかと一致しない場合、パケットをドロップする必要があります。
Multicast packets addressed to a group to which the mobile node has successfully subscribed, MUST be tunneled to the mobile node.
モバイルノードが正常にサブスクライブされているグループに宛てられたマルチキャストパケットは、モバイルノードにトンネリングする必要があります。
IPv6 multicast membership control is provided as defined in MIPv6 [RFC3775], Section 10.4.3. The only clarification required for the purpose of this specification is that all Multicast Listener Discovery (MLD) [RFC2710] or MLDv2 [RFC3810] messages between the mobile node and the home agent MUST be tunneled over an IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address, bypassing the foreign agent. Note that if tunneling to the care-of address has been negotiated for other traffic, then the rest of the traffic continues using this tunnel.
IPv6マルチキャストメンバーシップコントロールは、MIPV6 [RFC3775]、セクション10.4.3で定義されているように提供されます。この仕様の目的に必要な唯一の明確化は、すべてのマルチキャストリスナーディスカバリー（MLD）[RFC2710]またはMLDV2 [RFC3810]モバイルノードとホームエージェントの間のメッセージが、モバイルノードのIPv4ホームアドレス間のIPv4トンネルの上にトンネリングする必要があることです。ホームエージェントのIPv4アドレスは、外国人エージェントをバイパスします。住所へのケアへのトンネリングが他のトラフィックについて交渉されている場合、残りのトラフィックはこのトンネルを使用して継続することに注意してください。
This specification does not affect the operation of the foreign agent.
この仕様は、外国人エージェントの運用に影響しません。
A dual-stack mobile node that supports the extensions described in this document MAY use these extensions to register its IPv6 prefix(es) while moving between access routers.
このドキュメントで説明されている拡張機能をサポートするデュアルスタックモバイルノードは、これらの拡張機能を使用して、アクセスルーター間を移動しながらIPv6プレフィックス（ES）を登録できます。
The mobile node MAY include one or more IPv6 prefix request extension(s) in the registration request.
モバイルノードには、登録要求に1つ以上のIPv6プレフィックスリクエスト拡張子を含めることができます。
In this case, the mobile node MUST take the following action depending on the extensions included in the registration reply it receives in response to the registration request:
この場合、モバイルノードは、登録リクエストに応じて受信する登録返信に含まれる拡張機能に応じて、次のアクションを実行する必要があります。
1) The registration reply does not include any IPv6 prefix reply extensions.
1) 登録返信には、IPv6プレフィックス応答拡張機能は含まれていません。
The mobile node MUST assume that the home agent does not support the extensions defined in this specification. The mobile node SHOULD continue to operate according to MIPv4 [RFC3344].
モバイルノードは、ホームエージェントがこの仕様で定義されている拡張機能をサポートしていないと想定する必要があります。モバイルノードは、MIPV4 [RFC3344]に従って動作し続ける必要があります。
2) The registration reply includes one or more IPv6 prefix reply extensions.
2) 登録返信には、1つ以上のIPv6プレフィックス返信拡張機能が含まれています。
The mobile node MUST match each IPv6 prefix reply extension with one of the IPv6 prefix request extensions included earlier in the corresponding registration request message.
モバイルノードは、各IPv6プレフィックスの返信拡張子を、対応する登録要求メッセージに前半に含まれるIPv6プレフィックスリクエスト拡張機能のいずれかと一致する必要があります。
If a matching IPv6 prefix reply extension is not included for one or more of corresponding IPv6 prefix request extensions included in the registration request message, the mobile node MUST assume that these IPv6 prefixes are rejected.
登録要求メッセージに含まれる対応するIPv6プレフィックスリクエスト拡張機能の1つ以上に一致するIPv6プレフィックス応答拡張機能が含まれていない場合、モバイルノードはこれらのIPv6プレフィックスが拒否されると仮定する必要があります。
For each matching IPv6 prefix reply extension, the mobile node MUST inspect the code field. If the field is set to a rejection code, then the corresponding IPv6 prefix registration has been rejected. If the code field is set to an acceptance code, then the corresponding IPv6 prefix registration has been accepted.
一致するIPv6プレフィックス応答拡張機能ごとに、モバイルノードはコードフィールドを検査する必要があります。フィールドが拒否コードに設定されている場合、対応するIPv6プレフィックス登録が拒否されました。コードフィールドが受け入れコードに設定されている場合、対応するIPv6プレフィックス登録が受け入れられています。
If the code field is set to "0", then the mobile node MUST be prepared to send/receive IPv6 packets encapsulated in the bidirectional tunnel between the home agent address and the registered IPv4 home address of the mobile node.
コードフィールドが「0」に設定されている場合、モバイルノードは、ホームエージェントアドレスとモバイルノードの登録されたIPv4ホームアドレスの間の双方向トンネルにカプセル化されたIPv6パケットを送信/受信するために準備する必要があります。
If the code field is set to "1", then the mobile node MUST act as follows:
コードフィールドが「1」に設定されている場合、モバイルノードは次のように機能する必要があります。
- Assuming the co-located care-of address mode is used, the mobile node MUST be prepared to send/receive IPv6 packets over the bidirectional tunnel between the home agent address and its co-located care-of address. Otherwise, the mobile node SHOULD act as in the case where the code field is set to "0".
- 共同配置された住所モードが使用されていると仮定すると、モバイルノードは、ホームエージェントアドレスとその共同住民のアドレスの間の双方向トンネル上にIPv6パケットを送信/受信するために準備する必要があります。それ以外の場合、モバイルノードは、コードフィールドが「0」に設定されている場合のように機能する必要があります。
The mobile node SHOULD include exactly one IPv6 tunneling mode extension if it uses the co-located care-of address model and it wants to request that IPv6 packets are tunneled to its co-located care-of address. If the mobile node uses the co-located care-of address model but it does not include the IPv6 tunneling mode extension, the home agent will tunnel IPv6 traffic to the mobile node's IPv4 home address. The mobile node MUST NOT include an IPv6 tunneling mode extension if it uses the foreign agent care-of address mode of operation. Note that if the mobile node includes an IPv6 tunneling mode extension in this case, IPv6 packets could be tunneled to the FA by the HA. The FA is then likely to drop them since it will not have appropriate state to process them.
モバイルノードには、Co-Located Care-of Addressモデルを使用し、IPv6パケットが共同住みのケアオブアドレスにトンネリングされるように要求する場合、正確に1つのIPv6トンネルモード拡張機能を含める必要があります。モバイルノードが共同配置されたアドレスモデルを使用しているが、IPv6トンネルモード拡張機能を含めない場合、ホームエージェントはモバイルノードのIPv4ホームアドレスにIPv6トラフィックをトンネルします。モバイルノードには、外国のエージェントケアオブアドレス操作モードを使用する場合、IPv6トンネルモード拡張機能を含めてはなりません。この場合、モバイルノードにIPv6トンネルモード拡張機能が含まれている場合、IPv6パケットはHAによってFAにトンネリングできることに注意してください。FAは、それらを処理するのに適切な状態がないため、それらを落とす可能性があります。
When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can treat the IPv4 tunnel as a single hop link as defined in [RFC4213]. The two tunnel endpoints, e.g., mobile node and home agent, MUST configure link-local IPv6 addresses as defined in Section 3.7 of
IPv6がIPv4トンネルを越えて実行すると、IPv6トンネルエンドポイントは[RFC4213]で定義されているように、IPv4トンネルを単一のホップリンクとして扱うことができます。2つのトンネルエンドポイント、例えばモバイルノードとホームエージェントは、リンクローカルIPv6アドレスを設定する必要があります。
[RFC4213], while they MUST also adhere to the neighbor discovery requirements of the same specification, Section 3.8, and the hop limit requirements of Section 3.3.
[RFC4213]、同じ仕様の近隣発見要件、セクション3.8、およびセクション3.3のホップ制限要件も遵守する必要があります。
With respect to the Tunnel MTU, an implementation MUST support the Static Tunnel MTU approach as defined in Section 3.2 of [RFC4213]. Implementation and use of the Dynamic Tunnel MTU method defined in the same section of [RFC4213] is OPTIONAL.
トンネルMTUに関しては、[RFC4213]のセクション3.2で定義されているように、実装は静的トンネルMTUアプローチをサポートする必要があります。[RFC4213]の同じセクションで定義された動的トンネルMTUメソッドの実装と使用はオプションです。
To accommodate traffic that uses Explicit Congestion Notification (ECN), it is RECOMMENDED that the ECN and Diffserv Code Point (DSCP) information is copied between the inner and outer header as defined in [RFC3168] and [RFC2983]. It is RECOMMENDED that the full-functionality option defined in Section 9.1.1 of [RFC3168] be used to deal with ECN.
明示的な混雑通知（ECN）を使用するトラフィックに対応するには、[RFC3168]および[RFC2983]で定義されているように、ECNおよびDiffServコードポイント（DSCP）情報を内側ヘッダーと外側ヘッダーの間にコピーすることをお勧めします。[RFC3168]のセクション9.1.1で定義されているフル機能性オプションを使用してECNを扱うことをお勧めします。
An implementation can use any number of mechanisms to allocate IPv6 prefixes to a mobile node. Once one or more IPv6 prefixes are allocated, they can be registered using the extensions and mechanism already described in this specification.
実装では、任意の数のメカニズムを使用して、IPv6プレフィックスをモバイルノードに割り当てることができます。1つ以上のIPv6プレフィックスが割り当てられると、この仕様で既に説明されている拡張機能とメカニズムを使用して登録できます。
How a home agent decides to accept an IPv6 prefix for a given mobile node is out of scope of this specification. Local configuration or external authorization via an authorization system, e.g., Diameter [RFC3588], or other mechanisms may be used to make such determination.
ホームエージェントが特定のモバイルノードのIPv6プレフィックスを受け入れることを決定する方法は、この仕様の範囲外です。承認システムを介したローカル構成または外部認証、たとえば、直径[RFC3588]、またはその他のメカニズムを使用してそのような決定を行うことができます。
A dual-stack mobile node MAY use prefix delegation as defined in DHCPv6 Prefix Delegation [RFC3633] to get access to IPv6 prefixes. In that case, if the mobile node is not directly attached to its home agent, the mobile node MUST first register its IPv4 home address as per MIPv4 [RFC3344]. When that is done, the mobile node can generate a link-local IPv6 address as per Section 3.7 of [RFC4213]. The mobile node then sends a registration request to its home agent, including an IPv6 prefix request extension with the prefix length field set to 255 and setting the Mobile IPv6 Network Prefix field to the locally generated link-local address. If the registration reply message includes an IPv6 prefix reply extension with the code field set to a success code, the mobile node can use the tunnel to send and receive IPv6 link-local packets. The mobile node can now send DHCPv6 messages according to [RFC3633]. All IPv6 messages at this stage MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address.
デュアルスタックのモバイルノードは、DHCPV6プレフィックス委任[RFC3633]で定義されているように、IPv6プレフィックスにアクセスするために、プレフィックス委任を使用してください。その場合、モバイルノードがホームエージェントに直接接続されていない場合、モバイルノードはMIPV4 [RFC3344]に従って最初にIPv4ホームアドレスを登録する必要があります。それが完了すると、[RFC4213]のセクション3.7に従って、モバイルノードはリンクローカルIPv6アドレスを生成できます。その後、モバイルノードは、登録要求をホームエージェントに送信します。これには、プレフィックス長さフィールドが255に設定され、モバイルIPv6ネットワークプレフィックスフィールドをローカルに生成されたLink-Localアドレスに設定するIPv6プレフィックスリクエスト拡張子が含まれます。登録応答メッセージにIPv6プレフィックスの返信拡張機能が含まれている場合、コードフィールドが成功コードに設定されている場合、モバイルノードはトンネルを使用してIPv6 Link-Localパケットを送信および受信できます。モバイルノードは、[RFC3633]に従ってDHCPV6メッセージを送信できるようになりました。この段階でのすべてのIPv6メッセージは、モバイルノードのIPv4ホームアドレスとホームエージェントのIPv4アドレスの間のIPv4トンネルの上にトンネリングする必要があります。
Once prefixes are delegated, and assuming explicit mode is used, the mobile node SHOULD send a registration request with the appropriate IPv6 prefix request extensions to the home agent to register the delegated prefixes.
プレフィックスが委任され、明示的なモードが使用されると仮定すると、モバイルノードは、適切なIPv6プレフィックスリクエスト拡張機能をホームエージェントに登録して、委任されたプレフィックスを登録するために登録要求を送信する必要があります。
The mobile IP registration lifetime included in the registration request header is valid for all the bindings created by the registration request, which may include bindings for IPv6 prefix(es).
登録要求ヘッダーに含まれるモバイルIP登録のライフタイムは、登録要求によって作成されたすべてのバインディングに対して有効です。これには、IPv6プレフィックス（ES）のバインディングが含まれます。
A registration request with a zero lifetime can be used to remove all bindings from the home agent.
ゼロライフタイムの登録要求を使用して、ホームエージェントからすべてのバインディングを削除できます。
A re-registration request with non-zero lifetime can be used to deregister some of the registered IPv6 prefixes by not including corresponding IPv6 prefix request extensions in the registration request message.
ゼロ以外の寿命を備えた再登録要求を使用して、登録要求メッセージに対応するIPv6プレフィックスリクエスト拡張機能を含まないことにより、登録されたIPv6プレフィックスの一部を登録できます。
If the care-of address is a private address, then Mobile IP NAT Traversal as [RFC3519] MAY be used in combination with the extensions described in this specification. In that case, to transport IPv6 packets, the next header field of the Mobile Tunnel Data message header [RFC3519] MUST be set to the value for IPv6. Note that in that case, the encapsulation field of the UDP Tunnel Request Extension defined in [RFC3519] MUST be set to zero.
アドレスのケアがプライベートアドレスである場合、[RFC3519]としてのモバイルIP NATトラバーサルは、この仕様で説明されている拡張機能と組み合わせて使用できます。その場合、IPv6パケットを輸送するには、モバイルトンネルデータメッセージヘッダーの次のヘッダーフィールド[RFC3519]をIPv6の値に設定する必要があります。その場合、[RFC3519]で定義されているUDPトンネル要求拡張のカプセル化フィールドはゼロに設定する必要があることに注意してください。
This specification operates in the security constraints and requirements of [RFC3344]. It extends the operations defined in [RFC3344] for IPv4 home addresses to cover home IPv6 prefixes and provides the same level of security for both IP address versions.
この仕様は、[RFC3344]のセキュリティの制約と要件で動作します。[RFC3344]で定義されている操作を、IPv4ホームアドレスのホームIPv6プレフィックスをカバーするために拡張し、両方のIPアドレスバージョンに同じレベルのセキュリティを提供します。
Home agents MUST perform appropriate checks for reverse-tunneled IPv6 packets similar to what is defined in [RFC3024] for IPv4 packets. The check defined in [RFC3024] requires that the outer header's source address is set to a registered care-of address for the mobile node and as such the same check protects from attacks whether the encapsulated (inner) header is IPv4 or IPv6.
ホームエージェントは、IPv4パケットの[rfc3024]で定義されているものと同様の逆誘惑IPv6パケットの適切なチェックを実行する必要があります。[RFC3024]で定義されているチェックでは、外側のヘッダーのソースアドレスがモバイルノードの登録されたケアオブアドレスに設定される必要があるため、同じチェックがカプセル化された（内側）ヘッダーがIPv4またはIPv6であるかどうかにかかわらず攻撃から保護します。
In addition to that, the home agent MUST check that the source address of the inner header is a registered IPv4 home address or IPv6 prefix for this mobile node. If that is not the case, the home agent SHOULD silently discard the packet and log the event as a security exception.
それに加えて、ホームエージェントは、内側ヘッダーのソースアドレスが、このモバイルノードの登録済みのIPv4ホームアドレスまたはIPv6プレフィックスであることを確認する必要があります。そうでない場合、ホームエージェントは静かにパケットを破棄し、セキュリティ例外としてイベントをログに記録する必要があります。
Security devices should look for IPv6 packets encapsulated over IPv4 either directly to the mobile node's care-of address or via double encapsulation first to the mobile node's IPv4 home address and then to the mobile node's care-of address. Interactions with Mobile IPv4 and IPsec have been covered elsewhere, for instance in [RFC5265] and [RFC5266].
セキュリティデバイスは、IPv4を介してカプセル化されたIPv6パケットをモバイルノードのケアオブアドレスに直接、またはモバイルノードのIPv4ホームアドレス、次にモバイルノードのケアアドレスにダブルカプセル化を介して探す必要があります。モバイルIPv4およびIPSECとの相互作用は、たとえば[RFC5265]および[RFC5266]で他の場所でカバーされています。
A new type number (152) for DSMIPv4 extensions has been registered from the space of numbers for skippable mobility extensions (i.e., 128-255), defined for Mobile IPv4 [RFC3344]. This registry is available from http://www.iana.org under "Extensions appearing in Mobile IP control messages".
DSMIPV4拡張機能の新しいタイプ数（152）は、モバイルIPv4 [RFC3344]用に定義されているスキップ可能なモビリティエクステンション（つまり、128-255）の数値のスペースから登録されています。このレジストリは、「モバイルIPコントロールメッセージに表示される拡張機能」の下でhttp://www.iana.orgから入手できます。
A new subtype space for the type number of this extension has been created: "DSMIPv4 Extension subtypes". The subtype values 1, 2, and 3 are defined in this specification, while the rest of the subtypes are reserved and available for allocation based on Expert Review.
この拡張機能のタイプ番号の新しいサブタイプスペースが作成されました：「DSMIPV4拡張サブタイプ」。サブタイプの値1、2、および3はこの仕様で定義されていますが、残りのサブタイプは予約されており、専門家のレビューに基づいて割り当てに使用できます。
Finally, a new space for the code field of the IPv6 prefix reply extension has been created: "IPv6 Prefix Reply Extension Codes". Values 0, 1, 8, and 9 are defined in this specification. Values 2-7 are reserved for accept codes, and values 10-255 are reserved for reject codes.
最後に、IPv6プレフィックスのコードフィールドの新しいスペースが作成されました：「IPv6プレフィックス応答拡張コード」。値0、1、8、および9は、この仕様で定義されています。値2-7は受け入れコードのために予約されており、値10-255は拒否コードのために予約されています。
Similar to the procedures specified for Mobile IPv4 [RFC3344] number spaces, future allocations from the two number spaces require Expert Review [RFC5226].
モバイルIPv4 [RFC3344]数スペースに指定された手順と同様に、2つの数値スペースからの将来の割り当てには、専門家のレビュー[RFC5226]が必要です。
Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller, and Pete McCann for earlier work on this subject. Thanks also to Alex Petrescu for various suggestions. Special thanks also to Sri Gundavelli and Kent Leung for their thorough review and suggestions.
パット・カルホーン、パール・エンゲルスタッド、トム・ヒラー、ピート・マッキャンに、この主題に関する以前の作業に感謝します。さまざまな提案をしてくれたAlex Petrescuにも感謝します。徹底的なレビューと提案をしてくれたSri GundavelliとKent Leungにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G。、「モバイルIPの逆トンネル、改訂版」、RFC 3024、2001年1月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[RFC3519] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年4月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265] Vaarala、S。およびE. Klovning、「IPSECベースのVPNゲートウェイ全体のモバイルIPv4トラバーサル」、RFC 5265、2008年6月。
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
[RFC5266] Devarapalli、V。およびP. Eronen、「モバイルIPv4およびIKEV2モビリティおよびマルチホミング（Mobike）を使用した安全な接続とモビリティ」、BCP 136、RFC 5266、2008年6月。
Authors' Addresses
著者のアドレス
George Tsirtsis Qualcomm
George Tsirtsis Qualcomm
EMail: tsirtsis@googlemail.com
Vincent Park Qualcomm
ヴィンセントパーククアルコム
Phone: +908-947-7084
EMail: vpark@qualcomm.com
Hesham Soliman Elevate Technologies
Hesham Soliman Elevate Technologies
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com