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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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またはデュアルスタックのネットワークに移動しながら、IPv4およびIPv6アドレス[RFC2460]を持つノードは、そのアドレスのいずれかを介して通信を維持することを可能にします。
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.
本質的に、この仕様は、トンネルトラフィックのIPバージョンからモバイルIPv4シグナリングを分離します。本拡張機能を有するモバイルIPv4は、IPv4上で動作するシグナリングプロトコルのままであり、まだIPv4の上にIPv4とIPv6の両方のトンネルを設定することができます。
The aim is two-fold:
目的は二つあります：
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トラフィックの自動化が、制御されたトンネリングを可能にする、有用な遷移機構となります。 IPv4のモバイルノードとネットワークが、一度にIPv6へのすべてのネットワークノードをアップグレードすることなく、モビリティ管理を変更することなく、IPv6へ移行することができながら、デュアルスタックホームネットワークでデュアルスタックノードは今、にし、従来のIPv4ネットワークからローミングすることができます。
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.
それはまだルート最適化を提供していないモバイルIPv4シグナリングに依存しているとして、モバイルIPv6 [RFC3775]スタイルのルートの最適化などの機能（注）このソリューションでは不可能だろう。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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気付アドレス（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プレフィックス（複数可）を決定するために、任意のメカニズム（この文書で定義されていない）を使用することができ、これらのプレフィックスのための転送を設定します。この動作モードでは、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のバインディングを明示的にシグナリングされています。ホームエージェントは、IPv6プレフィックス返信拡張を対応するIPv6のバインディングを拒否/承諾に戻りながら、モバイルノードは、登録要求内の1つまたは複数の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
１８
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
２０
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
HoAにトンネリングすることが認められた0登録、IPv6の
1 registration accepted, IPv6 to be tunneled to CoA
アシルCoAにトンネルすることが認められた1件の登録、IPv6の
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
２
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プレフィックス要求拡張も拒否されます。登録応答ヘッダ内のコードフィールドが、しかし、受け入れコードに設定されている場合、拒否コードに設定されたコード・フィールドとの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プレフィックス返信拡張を含んではいけません。各受け入れられた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プレフィックス応答拡張のコードフィールドに、モバイルノードに成功した登録応答を送信すると、ホームエージェントは、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].
[RFC3963]のNEMOセクション6.3で定義されている各登録IPv6プレフィックスの場合は、ホームエージェントは、その到達可能性をアドバタイズする必要があります。
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）とプレフィックス長（S）。
- Tunneling mode for IPv6 traffic:
- IPv6トラフィックのトンネリングモード：
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA.
- IPv4のHoAとのトンネルとIPv4のHoAからトンネル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カプセル化がネゴシエートされたときにその場合、IPv6は[RFC4213]に記載のIPv4上にトンネリングされます。汎用ルーティングカプセル化（GRE）は、IANAによってIPv6のために定義された適切なペイロードタイプには、プロトコルタイプ[RFC2784]フィールドを設定することにより、IPv6パケットのトンネリングを可能にします。第二（内側）IPヘッダは[RFC2004]でサポートされていないIPv6の、あるので最小限のカプセル化[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とモバイルノードのホームアドレス間のトンネルを介してカプセル化されている場合、IPv6は常に[RFC4213]によるIPv4の上でトンネリングされます。結果としてIPv4パケットは、その後、他のIPv4パケットは、（おそらく外部エージェント（FA）を経由、通常のIPv4トラフィックのためのトンネリングを使用して）はIPv4のHoA宛同じように配信されます。
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）登録要求は、一つ以上の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.
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）登録要求は、一つ以上の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.
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パケットがモバイルノードから受信したことを確認し、登録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.
MIPv6の[RFC3775]、セクション10.4.3に定義されているIPv6マルチキャストメンバシップの制御が提供されます。本明細書の目的のために必要な唯一の明確化は、モバイルノードとホームエージェントとの間のすべてのマルチキャストリスナー発見（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プレフィックス（複数可）を登録するには、これらの拡張機能を使用するかもしれません。
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].
2) The registration reply includes one or more IPv6 prefix reply extensions.
2）登録応答は、一の以上の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.
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プレフィックス応答拡張は、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.
それは同じ場所に配置さ気付アドレスモデルを使用し、それが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トンネル上で動作するとき、[RFC4213]で定義されるように、IPv6トンネルエンドポイントは、シングルホップリンクとしてIPv4トンネルを治療することができます。セクション3.7で定義されるように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.
[RFC4213]のセクション3.2で定義されるようにトンネルMTUに関しては、実装は、静的トンネル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）を使用してトラフィックを収容するために、ECNとDiffservコードポイント（DSCP）情報は、内側と外側の[RFC3168]で定義されるように、ヘッダと[RFC2983]の間でコピーすることが推奨されます。 [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プレフィックスを割り当てるためのメカニズムの任意の数を使用することができます。一つ以上の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.
IPv6プレフィックスへのアクセスを得るために、DHCPv6のプレフィックス委譲[RFC3633]で定義されているデュアルスタックモバイルノードは、プレフィックス委任を使用するかもしれません。モバイルノードが直接そのホームエージェントに接続されていない場合この場合、移動ノードは最初のMIPv4 [RFC3344]に従ってそののIPv4ホームアドレスを登録しなければなりません。それが完了すると、モバイルノードは、[RFC4213]のセクション3.7に従ってリンクローカルIPv6アドレスを生成することができます。モバイルノードは、255に設定し、プレフィックス長さフィールドを持つIPv6プレフィックス要求拡張子を含む、ローカルに生成されたリンクローカルアドレスにモバイルIPv6ネットワークプレフィックス]フィールドを設定し、そのホームエージェントに登録要求を送信します。登録応答メッセージは、成功コードに設定されたコード・フィールドとIPv6プレフィックス応答拡張が含まれている場合、モバイルノードは、IPv6リンクローカルパケットを送信及び受信するためにトンネルを使用することができます。モバイルノードは現在、[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]の要件で動作します。これは、ホームIPv6プレフィックスをカバーするのIPv4ホームアドレスのために[RFC3344]で定義された動作を拡張し、両方の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ホーム・アドレスへ直接移動ノードの気付アドレスまたはダブルカプセル化のいずれかを介したIPv4上でカプセル化されたIPv6パケットを探し、その後、移動ノードの気付アドレスにする必要があります。モバイル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）はスキップ可能モビリティ拡張のために数値の空間から登録されている（すなわち、128-255）、モバイルIPv4 [RFC3344]のために定義されました。このレジストリは、「モバイル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.
このテーマに関する以前の仕事のためのパットカルフーン、PAALエンゲルスタッド、トム・ヒラー、そしてピートマッキャンに感謝します。様々な提案のためにもアレックスペトレスクに感謝します。彼らの徹底的な見直しと提案のためのスリGundavelliとケントレオンにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G.は、RFC 3024、2001年1月、 "モバイルIPのためのリバーストンネリングは、改訂されました"。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、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.
、RFC 3519、2003年4月、 "ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル" [RFC3519] Levkowetz、H.とS. Vaarala、。
[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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.、ペトレスク、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.ギリガン、 "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]パーキンス、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
"IPSecベースのVPNゲートウェイを横切るモバイルIPv4トラバーサル" [RFC5265] Vaarala、S.及びE. Klovning、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
ジョージTsirtsisクアルコム
EMail: tsirtsis@googlemail.com
メールアドレス：tsirtsis@googlemail.com
Vincent Park Qualcomm
ヴィンセントパーククアルコム
Phone: +908-947-7084 EMail: vpark@qualcomm.com
電話：+ 908-947-7084 Eメール：vpark@qualcomm.com
Hesham Soliman Elevate Technologies
ヒシャムスレイマン・テクノロジーズペスト
Phone: +614-111-410-445 EMail: hesham@elevatemobile.com
電話：+ 614-111-410-445 Eメール：hesham@elevatemobile.com