Internet Engineering Task Force (IETF) R. Wakikawa
Request for Comments: 5844 Toyota ITC
Category: Standards Track S. Gundavelli
ISSN: 2070-1721 Cisco
May 2010
IPv4 Support for Proxy Mobile IPv6
Abstract
抽象
This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network.
この文書では、IPv4プロトコルのサポートを追加するためのプロキシモバイルIPv6プロトコルへの拡張を指定します。 IPv4プロトコルのサポートの範囲は二重である：1）モバイルノードへのIPv4ホームアドレスモビリティサポートを有効にし、2）プロキシモバイルIPv6ドメイン内のモビリティエンティティがIPv4トランスポートネットワーク上でシグナリングメッセージを交換することを可能にします。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5844.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5844で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 4
1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 9
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 9
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 10
3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4. ECN and Payload Fragmentation Considerations . . . . . 16
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 17
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17
3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 22
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 23
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25
3.3.4. IPv4 DHCP Support Mode Option . . . . . . . . . . . . 25
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 26
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 27
3.4.1. DHCP Server Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2. DHCP Relay Agent Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 33
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 35
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 37
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 37
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 37
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 37
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40
4.2.1. Extensions to Binding Update List Entry . . . . . . . 40
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 43
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 43
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 43
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44
5.1. Local Mobility Anchor - Configuration Variables . . . . . 44
5.2. Mobile Access Gateway - Configuration Variables . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 48
The transition from IPv4 to IPv6 is a long process, and during this period of transition, both the protocols will be enabled over the same network infrastructure. Thus, it is reasonable to assume that a mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4- only, IPv6-only, or dual-stack mode, and the network between the mobile access gateway and a local mobility anchor may be an IPv4 or an IPv6 network. It is also reasonable to expect the same mobility infrastructure in the Proxy Mobile IPv6 domain to provide mobility to the mobile nodes operating in IPv4, IPv6, or in dual mode and whether the transport network is IPv4 or IPv6 network. The motivation and scope of IPv4 support in Mobile IPv6 is summarized in [RFC4977], and all those requirements apply to Proxy Mobile IPv6 protocol as well.
IPv4からIPv6への移行は、長いプロセスであり、遷移のこの期間中、両方のプロトコルは、同一のネットワークインフラストラクチャ上で有効であろう。したがって、プロキシ・モバイルIPv6ドメイン内のモバイルノードのみ、IPv6のみ、またはデュアルスタックモードIPv4-で動作することができると仮定することは合理的であり、モバイルアクセスゲートウェイとローカル・モビリティ・アンカーとの間のネットワークであってもよいですIPv4またはIPv6ネットワーク。また、プロキシモバイルIPv6ドメインの同じモビリティインフラストラクチャは、IPv4、IPv6の、またはデュアルモードとトランスポートネットワークはIPv4またはIPv6ネットワークであるかどうかを操作するモバイルノードにモビリティを提供することを期待するのが妥当です。モバイルIPv6内IPv4サポートの動機及び範囲は、[RFC4977]に要約されており、これらすべての要件は、同様に、プロキシモバイルIPv6プロトコルに適用されます。
The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for providing IPv6 home address mobility support to a mobile node in a Proxy Mobile IPv6 domain. The protocol requires IPv6 transport network between the mobility entities. The extensions defined in this document specify IPv4 support to the Proxy Mobile IPv6 protocol [RFC5213].
プロキシモバイルIPv6プロトコル[RFC5213]はProxyのモバイルIPv6ドメインのモバイルノードへのIPv6ホームアドレスモビリティサポートを提供するためのメカニズムを指定します。プロトコルは、モビリティエンティティ間のIPv6トランスポートネットワークが必要です。この文書で定義された拡張はプロキシモバイルIPv6プロトコル[RFC5213]にIPv4サポートを指定します。
The scope of IPv4 support in Proxy Mobile IPv6 includes the support for the following two features:
プロキシモバイルIPv6におけるIPv4サポートの範囲は、以下の2つの機能のサポートを含みます。
o IPv4 Home Address Mobility Support: A mobile node that is dual-stack or IPv4-only enabled will be able to obtain an IPv4 address and be able to use that address from any of the access networks in that Proxy Mobile IPv6 domain. The mobile node is not required to be allocated or assigned an IPv6 address to enable IPv4 home address support.
OのIPv4ホームアドレスモビリティサポート：デュアルスタックまたはIPv4専用のIPv4アドレスを取得し、そのProxyのモバイルIPv6ドメインのアクセスネットワークのいずれかからそのアドレスを使用することができるようすることができるようになります有効になっているモバイルノード。モバイルノードは、IPv4のホームアドレスのサポートを有効にするために割り当てられたか、IPv6アドレスを割り当てることが必要とされていません。
o IPv4 Transport Network Support: The mobility entities in the Proxy Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling messages over an IPv4 transport.
OのIPv4トランスポートネットワークのサポート：プロキシモバイルIPv6ドメインの移動性実体は、IPv4トランスポート上でプロキシモバイルIPv6のシグナリングメッセージを交換することができるようになります。
These two features, the IPv4 home address mobility support and the IPv4 transport support features, are independent of each other, and deployments may choose to enable either one or both of these features as required.
これらの2つの機能、IPv4のホームアドレスモビリティサポートとIPv4トランスポート・サポート機能は、互いに独立しており、および展開は、必要に応じて、これらの機能のいずれか一方または両方を有効にすることもできます。
Figure 1 shows a typical Proxy Mobile IPv6 domain with an IPv4 transport network and with IPv4 enabled mobile nodes. The terms used in this illustration are explained in the Terminology section.
図1は、IPv4トランスポートネットワークを有する典型的なプロキシ・モバイルIPv6ドメインを示すとIPv4とモバイルノードを可能にしました。この例で使用される用語は、用語のセクションで説明されています。
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
IPv4-Proxy-CoA --> | | <-- Proxy-CoA
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
(MN-HoA) | | | <-- (MN-HoA)
(IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA)
{MN1} {MN3}
Figure 1: IPv4 Support for Proxy Mobile IPv6
図1：プロキシモバイルIPv6のIPv4のサポート
The following are the system and configuration requirements from the mobility entities in the Proxy Mobile IPv6 domain for supporting the extensions defined in this document.
この文書で定義された拡張をサポートするためのプロキシモバイルIPv6ドメインの移動性実体からシステムおよび構成の要件は次のとおり。
o Both the mobility entities, the local mobility anchor and the mobile access gateway are dual-stack (IPv4/IPv6) enabled. Irrespective of the type of transport network (IPv4 or IPv6) separating these two entities, the mobility signaling is always based on Proxy Mobile IPv6 protocol [RFC5213].
Oモビリティエンティティ、地元の移動性アンカーとモバイルアクセスゲートウェイの両方がデュアルスタック（IPv4の/ IPv6）が有効になっています。かかわらず、これら2つのエンティティを分離するトランスポートネットワーク（IPv4またはIPv6）のタイプの、モビリティシグナリングは、常にプロキシモバイルIPv6プロトコル[RFC5213]に基づいています。
o A deployment where a mobile access gateway uses an IPv4 private address with NAT [RFC3022] translation devices in the path to a local mobility anchor is not supported by this specification.
Oモバイルアクセスゲートウェイがローカル・モビリティ・アンカーへのパスでNAT [RFC3022]変換デバイスでのIPv4プライベートアドレスを使用して、展開はこの仕様でサポートされていません。
o The mobile node can be operating in IPv4-only, IPv6-only or in dual mode. Based on the enabled configuration for a mobile node, the mobile node should be able to obtain IPv4-only, IPv6-only, or both IPv4 and IPv6 addresses for its interface and furthermore achieve mobility support for those addresses.
Oモバイルノードは、IPv4のみ、IPv6のみ、またはデュアルモードで動作することができます。モバイルノードのための有効な構成に基づいて、モバイルノードは、そのインターフェイスのIPv4のみ、IPv6のみ、またはIPv4とIPv6の両方のアドレスを取得し、さらに、それらのアドレスのためのモビリティ・サポートを達成することができなければなりません。
o For enabling IPv4 home address mobility support to a mobile node, it is not required that the IPv6 home address mobility support need be enabled. However, the respective protocol(s) support, such as IPv4 or IPv6 packet forwarding, must be enabled on the access link between the mobile node and the mobile access gateway.
モバイルノードへのIPv4ホームアドレスモビリティサポートを有効にするためのO、IPv6ホームアドレスモビリティサポートを有効にする必要がある必要はありません。しかしながら、このようなIPv4またはIPv6パケット転送等の各プロトコル（S）サポートは、モバイルノードとモバイルアクセスゲートウェイとの間のアクセスリンク上で有効にされなければなりません。
o The mobile node can obtain an IPv4 address for its attached interface. Based on the type of link, it may be able to acquire its IPv4 address configuration using standard IPv4 address configuration mechanisms such as DHCP [RFC2131], IP Control Protocol (IPCP) [RFC1332], Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], or static address configuration. However, the details on how IPCP or IKEv2 can be used for address delivery are outside the scope of this document.
Oモバイルノードは、その取り付けインターフェイスのIPv4アドレスを取得することができます。リンクのタイプに基づいて、そのようなDHCP [RFC2131]、IP制御プロトコル（IPCP）[RFC1332]、インターネット鍵交換プロトコルバージョン2（IKEv2の）などの標準的なIPv4アドレス構成メカニズムを使用してIPv4アドレス構成を取得することができるかもしれませんRFC4306]、または静的アドレスの設定。しかし、IPCPまたはIKEv2のがアドレスの配信のために使用することができる方法についての詳細は、このドキュメントの範囲外です。
o The mobile node's IPv4 home subnet is typically a shared address space. It is not for the exclusive use of any one mobile node. There can be multiple mobile nodes that are assigned IPv4 addresses from the same subnet.
OモバイルノードのIPv4ホームサブネットは、通常、共有アドレススペースです。これは、任意の一つの移動ノードの排他的使用のためではありません。同じサブネットからのIPv4アドレスが割り当てられている複数のモバイル・ノードが存在する場合があります。
o The mobile access gateway is the IPv4 default router for the mobile node on its access link. It will be in the forwarding path for the mobile node's data traffic. Additionally, as specified in Section 6.9.3 of [RFC5213], all the mobile access gateways in the Proxy Mobile IPv6 domain MUST use the same link-layer address on any of the access links wherever the mobile node attaches.
Oモバイル・アクセス・ゲートウェイは、アクセスリンク上のモバイルノードのIPv4デフォルトルータです。これは、モバイルノードのデータトラフィックの転送パスになります。 [RFC5213]のセクション6.9.3で指定されるようにまた、プロキシモバイルIPv6ドメイン内のすべてのモバイル・アクセス・ゲートウェイは、モバイルノードがアタッチどこアクセスリンクのいずれかで同じリンク層アドレスを使用しなければなりません。
IPv4 support for Mobile IPv6 is specified in the Dual-Stack Mobile IPv6 specification [RFC5555]. This document leverages some of the approaches, messaging options, and processing logic defined in that document for extending IPv4 support to Proxy Mobile IPv6, except with deviation in some aspects for obvious reasons of supporting a network-based mobility model. The following are some of the related considerations.
モバイルIPv6のIPv4サポートは、デュアルスタックモバイルIPv6仕様[RFC5555]で指定されています。この文書では、ネットワーク・ベースのモビリティ・モデルをサポートする明白な理由のためにいくつかの局面の偏差を除いて、プロキシモバイルIPv6をIPv4サポートを拡張するためのそのドキュメントで定義されたアプローチ、メッセージング・オプション、および処理ロジックの一部を活用します。以下は関連する考慮事項の一部です。
o The Binding Update message flag 'F' and the NAT Detection Option defined in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this specification in Proxy Binding Update and Proxy Binding Acknowledgement messages. Their sole purpose is to allow forcing of UDP encapsulation between a mobile access gateway and a local mobility anchor in situations similar to those discussed in Sections 4.1 and 4.4.1 of [RFC5555].
oをBinding Updateメッセージフラグ「F」と[RFC5555]のセクション3.1.3及び3.2.2で定義されたNAT検知オプションは、応答メッセージをバインディング更新及びプロキシ・バインディングプロキシに本明細書で使用されます。彼らの唯一の目的は、モバイルアクセスゲートウェイとセクション4.1と[RFC5555]の4.4.1で説明したものと同様の状況でローカル・モビリティ・アンカー間のUDPカプセル化の強制できるようにすることです。
o The necessary extensions to the conceptual data structures, Binding Cache entry and Binding Update List entry, for storing the state related to the IPv4 support defined in [RFC5555], will all be needed and relevant for this document.
概念的なデータ構造に必要な拡張O、キャッシュエントリと結合更新リストエントリのバインド、[RFC5555]で定義されたIPv4サポートに関連する状態を保存するために、すべてのこのドキュメントのために必要と関連されます。
o In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555], IPsec security associations (SAs) are specific to a single mobile node; they use the identifier visible to upper-layer protocols (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to be updated when the mobile node moves.
OモバイルIPv6 [RFC3775]とデュアルスタックモバイルIPv6における[RFC5555]で、IPsecセキュリティアソシエーション（SA）は、単一の移動ノードに固有です。彼らは、トラフィックセレクタとして上位層プロトコルに対して可視識別子（のHoA / IPv4の-のHoA）を使用します。およびIKE / IPsecのSAがするとき、移動ノードの移動を更新する必要があります。
In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec SAs are specific to the mobile access gateway (and used for a potentially large number of mobile nodes); they use the locators used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selectors; and they are not updated when the mobile node moves.
プロキシモバイルIPv6（[RFC5213]の両方とこの文書）において、IPsecのSAは、モバイル・アクセス・ゲートウェイに特定（及びモバイルノードの潜在的に大きな数のために使用される）です。彼らは、トラフィックセレクタとして（プロキシブチリル-CoA / IPv4のプロキシ-CoA）をルーティングするために使用されるロケータを使用します。モバイルノードが移動したとき、彼らは更新されません。
This means the IPsec processing for Mobile IPv6 and Proxy Mobile IPv6 (whether IPv6-only or dual-stack) is very different.
これは、モバイルIPv6とプロキシモバイルIPv6（IPv6のみ、またはデュアルスタックかどうか）のためにIPsec処理は非常に異なっていることを意味します。
o The tunneling considerations specified in [RFC5555] for supporting IPv4 transport are relevant for this document as well.
O IPv4トランスポートをサポートするために[RFC5555]で指定されたトンネルの考慮事項が同様にこのドキュメントに関連します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC3775] and Proxy Mobile IPv6 specification [RFC5213]. In addition, this document introduces the following terms.
本書で使用されるすべてのモビリティ関連する用語は、モバイルIPv6仕様[RFC3775]及びプロキシモバイルIPv6仕様[RFC5213]で定義されるように解釈されるべきです。また、このドキュメントでは、次の用語を紹介します。
IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)
IPv4のプロキシ気付アドレス（IPv4のプロキシ-COA）
The IPv4 address that is configured on the egress-interface of the mobile access gateway. When using IPv4 transport, this address will be the registered care-of address in the mobile node's Binding Cache entry and will also be the transport-endpoint of the tunnel between the local mobility anchor and a mobile access gateway.
モバイル・アクセス・ゲートウェイの出力インタフェース上で設定されたIPv4アドレス。 IPv4トランスポートを使用する場合、このアドレスは、登録気付アドレスモバイルノードのバインディングキャッシュエントリになり、また、ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイとの間のトンネルのトランスポートエンドポイントであろう。
IPv4 Local Mobility Anchor Address (IPv4-LMAA)
IPv4のローカルモビリティアンカーアドレス（IPv4-LMAA）
The IPv4 address that is configured on the egress-interface of the local mobility anchor. When using IPv4 transport, the mobile access gateway sends the Proxy Binding Update messages to this address and will be the transport-endpoint of the tunnel between the local mobility anchor and the mobile access gateway.
ローカル・モビリティ・アンカーの出口インターフェイス上で設定されたIPv4アドレス。 IPv4トランスポートを使用する場合、モバイル・アクセス・ゲートウェイは、このアドレスへのプロキシバインディング更新メッセージを送信し、ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイとの間のトンネルのトランスポートエンドポイントであろう。
Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
モバイルノードのIPv4ホームアドレス（IPv4-MN-HoAで）
The IPv4 home address assigned to the mobile node's attached interface. This address is topologically anchored at the mobile node's local mobility anchor. The mobile node configures this address on its attached interface. If the mobile node connects to the Proxy Mobile IPv6 domain via multiple interfaces each of the interfaces are assigned a unique IPv4 address. All the IPv6 home network prefixes and the IPv4 home address assigned to a given interface of a mobile node will be managed under one mobility session.
モバイルノードの接続インタフェースに割り当てられたIPv4ホーム・アドレス。このアドレスは、トポロジー的にモバイルノードのローカル・モビリティ・アンカーで固定されています。モバイルノードは、その取り付けインターフェースにこのアドレスを設定します。モバイルノードが複数のインタフェースを介して、プロキシモバイルIPv6ドメインに接続する場合インターフェイスの各々は、固有のIPv4アドレスを割り当てられています。すべてのIPv6ホームネットワークプレフィックスと、移動ノードの特定のインターフェイスに割り当てられたIPv4ホームアドレスが1つのモビリティセッションで管理されます。
Selective De-registration
選択登録解除
A procedure for partial de-registration of all the addresses that belong to one address family, i.e., de-registration of either the IPv4 home address or one or more of the assigned IPv6 home network prefixes.
一つのアドレスファミリはIPv4ホームアドレスまたは割り当てられたIPv6ホームネットワークプレフィックスの一つ以上のいずれかの、すなわち、登録解除に属しているすべてのアドレスの部分的な登録解除するための手順。
Encapsulation Modes
カプセル化モード
This document uses the following terms when referring to the different encapsulation modes.
異なるカプセル化モードを参照するときにこのドキュメントでは、次の用語を使用しています。
IPv4-or-IPv6-over-IPv6
IPv4の-または-IPv6のオーバーのIPv6
IPv4 or IPv6 packet carried as a payload of an IPv6 packet
IPv4またはIPv6パケットは、IPv6パケットのペイロードとして運ば
IPv4-or-IPv6-over-IPv4
IPv4の-または-のIPv6-IPv4のオーバー
IPv4 or IPv6 packet carried as a payload of an IPv4 packet
IPv4またはIPv6パケットは、IPv4パケットのペイロードとして運ば
IPv4-or-IPv6-over-IPv4-UDP
IPv4の-または-IPv6のオーバーのIPv4 UDP
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with a UDP header
UDPヘッダとIPv4パケットにペイロードとして運ばIPv4またはIPv6パケット
IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4の-または-IPv6のオーバーのIPv4 UDP-TLV
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with UDP and TLV headers
IPv4またはIPv6パケットは、UDP及びTLVヘッダをIPv4パケットにペイロードとして運ば
IPv4-or-IPv6-over-IPv4-GRE
IPv4の-または-IPv6のオーバーのIPv4 GRE
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with a Generic Routing Encapsulation (GRE) header (but no UDP or TLV header)
総称ルーティングカプセル化（GRE）ヘッダ（ただしないUDPまたはTLVヘッダ）とIPv4パケットにペイロードとして運ばIPv4またはIPv6パケット
The IPv4 home address mobility support essentially enables a mobile node in a Proxy Mobile IPv6 domain to obtain IPv4 home address configuration for its attached interfaces and be able to retain that address configuration even after performing a handoff anywhere within that Proxy Mobile IPv6 domain. This section describes the protocol operation and the required extensions to Proxy Mobile IPv6 protocol for extending IPv4 home address mobility support.
IPv4ホームアドレスモビリティサポートは、本質的にその取り付けインターフェイスのIPv4ホームアドレス設定を取得しても、そのプロキシモバイルIPv6ドメイン内の任意の場所にハンドオフを実行した後、そのアドレスの設定を保持することができるように、プロキシモバイルIPv6ドメイン内のモバイルノードを可能にします。このセクションでは、プロトコルの動作とIPv4ホームアドレスモビリティサポートを拡張するためのプロキシモバイルIPv6プロトコルに必要な拡張機能について説明します。
When an IPv4-enabled or a dual-stack-enabled mobile node attaches to the Proxy Mobile IPv6 domain, the mobile access gateway on the access link where the mobile node is attached will identify the mobile node and will initiate the Proxy Mobile IPv6 signaling with the mobile node's local mobility anchor. The mobile access gateway will follow the signaling considerations specified in Section 3.2 for requesting IPv4 home address mobility support. Upon the completion of the signaling, the local mobility anchor and the mobile access gateway will establish the required routing states for allowing the mobile node to use its IPv4 home address from its current point of attachment.
IPv4の対応またはデュアルスタック対応のモバイルノードがプロキシ・モバイルIPv6ドメインにアタッチするとき、モバイルノードが接続されているアクセスリンク上のモバイル・アクセス・ゲートウェイは、モバイルノードを識別し、でシグナリングプロキシモバイルIPv6を開始しますモバイルノードのローカル・モビリティ・アンカー。モバイル・アクセス・ゲートウェイは、IPv4ホームアドレスモビリティサポートを要求するため、3.2節で指定されたシグナリングの考慮事項に従います。シグナリングが完了すると、ローカル・モビリティ・アンカーとモバイル・アクセス・ゲートウェイは、モバイルノードがアタッチメントのその現在の位置からそののIPv4ホームアドレスを使用することを可能にするために必要なルーティング状態を確立します。
The mobile node on the access link using any of the standard IPv4 address configuration mechanisms supported on that access link, such as IPCP [RFC1332], IKEv2 [RFC4306], or DHCP [RFC2131], will be able to obtain an IPv4 home address (IPv4-MN-HoA) for its attached interface. Although the address configuration mechanisms for delivering the address configuration to the mobile node is independent of the Proxy Mobile IPv6 protocol operation, there needs to be some interaction between these two protocol flows. Section 3.4 identifies these interactions for supporting DHCP-based address configuration.
そのようなIPCP [RFC1332]のIKEv2 [RFC4306]、またはDHCP [RFC2131]としてそのアクセスリンク上でサポートされる標準のIPv4アドレス構成メカニズムのいずれかを用いてアクセスリンク上のモバイルノードが、IPv4のホーム・アドレスを取得することができるであろう（その取り付けインターフェイスのIPv4-MN-のHoA）。モバイルノードにアドレス構成を送達するためのアドレス構成メカニズムはプロキシモバイルIPv6プロトコルの動作から独立しているが、これら2つのプロトコルの流れの間の何らかの相互作用が必要です。 3.4節では、DHCPベースのアドレス設定をサポートするため、これらの相互作用を識別します。
The support for IPv4 home address mobility is not dependent on the IPv6 home address mobility support. It is not required that the IPv6 home address mobility support needs to be enabled for providing IPv4 home address mobility support. A mobile node will be able to obtain IPv4-only, IPv6-only, or dual IPv4/IPv6 address configuration for its attached interface. The mobile node's policy profile will determine if the mobile node is entitled to both the protocol versions or a single protocol version. Based on the policy, only those protocols will be enabled on the access link. Furthermore, if the mobile node, after obtaining the address configuration on its interface, performs a handoff, either by changing its point of attachment over the same interface or to a different interface, the network will ensure the mobile node will be able to use the same IPv4 address configuration after the handoff.
IPv4のホームアドレスのモビリティのためのサポートは、IPv6ホームアドレスモビリティサポートに依存しません。 IPv6ホームアドレスモビリティサポートは、IPv4ホームアドレスモビリティサポートを提供するために有効にする必要があることが必要とされていません。モバイルノードは、添付のインターフェイスのIPv4のみ、IPv6のみ、またはデュアルIPv4 / IPv6アドレス構成を取得することができるであろう。モバイルノードは、プロトコルバージョンまたは単一プロトコル・バージョンの両方を受ける資格がある場合、モバイルノードのポリシプロファイルが決定します。方針に基づき、唯一のこれらのプロトコルは、アクセスリンク上で有効になります。また、モバイルノードと、そのインタフェース上のアドレス設定を取得した後、ハンドオフを実行し、いずれかの同じインタフェースを介して、または異なるインタフェースへの接続点を変更することにより、ネットワークは、モバイルノードが使用することができるであろうようになりますハンドオフ後に同じIPv4アドレスの設定。
Additionally, if the mobile node connects to the Proxy Mobile IPv6 domain, through multiple interfaces and simultaneously through different access networks, each of the connected interfaces will obtain a unique IPv4 home address. In such a scenario, there will be multiple Binding Cache entries for the mobile node on the local mobility anchor. All the addresses (IPv4/IPv6) assigned to a given interface will be managed as part of one mobility session, as specified in Section 5.4 of [RFC5213].
モバイルノードがプロキシ・モバイルIPv6ドメインに接続する場合に加えて、複数のインタフェースを介して、同時に、異なるアクセスネットワークを介して、接続されたインターフェイスの各々は、一意のIPv4ホームアドレスを取得します。このようなシナリオでは、ローカル・モビリティ・アンカーのモバイルノードに対して複数のバインディングキャッシュエントリが存在します。 [RFC5213]のセクション5.4で指定されるように所定のインターフェイスに割り当てられたすべてのアドレス（のIPv4 / IPv6）は、1つのモビリティセッションの一部として管理されます。
To support this feature, the conceptual Binding Cache entry data structure maintained by the local mobility anchor needs to include the following parameters.
この機能をサポートするために、ローカル・モビリティ・アンカーによって維持概念のBinding Cacheエントリーのデータ構造は、次のパラメータを含める必要があります。
o The IPv4 home address assigned to the mobile node's interface and registered by the mobile access gateway. The IPv4 home address entry also includes the corresponding subnet mask. It is to be noted that this parameter is defined in [RFC5555] and is presented here for completeness.
IPv4のホームアドレスはモバイルノードのインターフェイスに割り当てられ、モバイル・アクセス・ゲートウェイによって登録O。 IPv4のホームアドレスのエントリは、対応するサブネットマスクを含んでいます。これは、このパラメータは、[RFC5555]で定義されており、完全を期すために、ここで提示されることに留意すべきです。
o The IPv4 default router address assigned to the mobile node.
O IPv4のデフォルトルータアドレスは、移動ノードに割り当てられています。
The processing rules specified in Section 5.3 of [RFC5213] are applied for processing the received Proxy Binding Update message. However, if the received Proxy Binding Update message has an IPv4 Home Address Request option, the following considerations MUST be applied additionally.
[RFC5213]のセクション5.3で指定された処理ルールは、受信されたProxy Binding Updateメッセージを処理するために適用されます。受信されたProxy Binding Updateメッセージは、IPv4ホームアドレス・リクエスト・オプションを持っている場合は、次の考慮事項がさらに適用されなければなりません。
o If there is an IPv4 Home Address Request option (Section 3.3.1) present in the received Proxy Binding Update message, but no Home Network Prefix option [RFC5213] present in the received Proxy Binding Update message, the local mobility anchor MUST NOT reject the request as specified in Section 5.3.1 of [RFC5213]. At least one instance of either of these two options, either the IPv4 Home Address Request option or the Home Network Prefix option, MUST be present. If there is not a single instance of either of these two options present in the request, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (missing the mobile node's home network prefix option) [RFC5213].
受信されたProxy Binding Updateメッセージが、受信されたProxy Binding Updateメッセージに存在していないホームネットワークプレフィックスオプション[RFC5213]に存在するIPv4のホームアドレス要求オプション（3.3.1）がある場合は、O、ローカル・モビリティ・アンカーは拒否してはなりません[RFC5213]のセクション5.3.1で指定されるように要求。これらの2つのオプションのいずれかの少なくとも1つのインスタンスのIPv4ホームアドレス・リクエスト・オプションまたはホームネットワークプレフィックスのいずれかのオプションでは、存在しなければなりません。リクエストに存在するこれらの2つのオプションのいずれかの単一のインスタンスが存在しない場合には、ローカル・モビリティ・アンカーは、要求を拒否し、（モバイルノードのホームネットワークプレフィックスオプションの欠落）MISSING_HOME_NETWORK_PREFIX_OPTIONに設定されたステータス・フィールドとProxy Binding Acknowledgementメッセージを送らなければなりません。 [RFC5213]。
o If there is at least one instance of the Home Network Prefix option [RFC5213] present in the received Proxy Binding Update message, but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv6 service, or IPv6 routing in not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not authorized for IPv6 mobility service; see Section 3.3.5).
Oが受信されたProxy Binding Updateメッセージに存在するホーム・ネットワーク・プレフィックス・オプション、[RFC5213]の少なくとも1つのインスタンスであり、移動ノードがIPv6サービス、またはIPv6ルーティングのために認可されていないことをモバイルノードのポリシプロファイルから知られている場合ホームネットワークで有効になっていないで、ローカル・モビリティ・アンカーは、要求を拒否し、NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICEに設定ステータス・フィールドとProxy Binding Acknowledgementメッセージを送らなければなら（モバイルノードのIPv6モビリティサービスのために許可されていません。3.3.5項を参照してください）。
o If there is an IPv4 Home Address Request option present in the received Proxy Binding Update message, but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv4 service, or if IPv4 routing is not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node not authorized for IPv4 mobility service; see Section 3.3.5).
そこに受信されたProxy Binding Updateメッセージに存在するIPv4のホームアドレス要求オプションがあるが、それは、モバイルノードは、IPv4サービスのために許可されていないモバイルノードのポリシープロファイルから知られている場合は、O、またはIPv4ルーティングはホームで有効になっていない場合ネットワークは、ローカル・モビリティ・アンカーは、要求を拒否しNOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICEに設定された状態のフィールドにプロキシバインディング肯定応答メッセージを送らなければなりません（IPv4のモビリティサービスのために認可されていないモバイルノード、セクション3.3.5を参照します）。
o If there is more than one instance of the IPv4 Home Address Request option present in the request, then the local mobility anchor MUST reject the request and send a Proxy Binding
リクエストに存在するIPv4のホームアドレス要求オプションの複数のインスタンスがある場合は、O、その後、ローカル・モビリティ・アンカーは、要求を拒否し、プロキシバインディングを送らなければなりません
Acknowledgement message with the Status field set to MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 home address assignments not supported; see Section 3.3.5).
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTEDに設定されたステータス・フィールドで確認応答メッセージ（複数のIPv4ホームアドレスの割り当てがサポートされていません。3.3.5項を参照してください）。
o For associating the received Proxy Binding Update message to an existing mobility session, the local mobility anchor MUST perform the Binding Cache entry existence test by applying the following considerations.
O既存のモビリティセッションに更新メッセージを受信されたProxy Bindingを関連付けるために、ローカル・モビリティ・アンカーは、以下の考慮事項を適用することによって、バインディングキャッシュエントリ存在のテストを実行しなければなりません。
* If there is at least one instance of the Home Network Prefix option [RFC5213] with a NON_ZERO prefix value, or, if there is an IPv4 Home Address Request option with the IPv4 address in the option set to ALL_ZERO, considerations from Section 5.4.1 of [RFC5213] MUST be applied.
* NON_ZEROプレフィックス値、またはとホームネットワークプレフィックスオプション[RFC5213]の少なくとも1つのインスタンスがある場合は、すべての_ZEROに設定オプション、5.4節からの問題でIPv4アドレスとIPv4のホームアドレス・リクエスト・オプションがある場合。 [RFC5213]の1が適用されなければなりません。
* If there is an IPv4 Home Address Request option present in the request with the IPv4 address value in the option set to a NON_ZERO value, considerations from Section 3.1.2.7 MUST be applied.
NON_ZERO値に設定オプションでのIPv4アドレスの値を持つリクエストに存在するIPv4のホームアドレス要求オプションがある場合は*、セクション3.1.2.7からの考慮事項が適用されなければなりません。
o If there is no existing Binding Cache entry that can be associated with the request, the local mobility anchor MUST consider this request as an initial binding registration request, and considerations from Section 3.1.2.2 MUST be applied. Additionally, if there are one or more Home Network Prefix options [RFC5213] present in the request, considerations from Section 5.3.2 of [RFC5213] MUST also be applied.
要求に関連付けることができます既存のバインディングキャッシュエントリが存在しない場合は、O、ローカル・モビリティ・アンカーは、初期結合登録要求として、この要求を考慮しなければならない、とセクション3.1.2.2からの考慮事項が適用されなければなりません。リクエスト中に存在する1つ以上のホームネットワークプレフィックスオプション[RFC5213]がある場合はさらに、[RFC5213]のセクション5.3.2からの配慮も適用されなければなりません。
o If there exists a Binding Cache entry that can be associated with the request, the local mobility anchor MUST apply considerations from Section 5.3.1 of [RFC5213], (point 13), to determine if the request is a re-registration or a de-registration request. If the request is a re-registration request, considerations from Section 3.1.2.3 MUST be applied, and if it is a de-registration request, considerations from Section 3.1.2.5 MUST be applied.
要求が再登録またはAであるかどうかを決定するために、O要求に関連付けることができるバインディングキャッシュエントリが存在する場合、ローカル・モビリティ・アンカーは、[RFC5213]のセクション5.3.1からの問題を適用しなければならない、（点13）登録解除要求。リクエストは再登録要求である場合、セクション3.1.2.3からの考慮事項が適用されなければならない、そしてそれは登録解除要求である場合、セクション3.1.2.5からの考慮事項が適用されなければなりません。
o If there exists a Binding Cache entry that can be associated with the request and if it is determined that the request is a re-registration request for extending an IPv4 home address mobility support to the existing IPv6-only mobility session, considerations from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
O要求に関連付けることができる結合キャッシュ項目が存在する場合、リクエストが既存のIPv6のみの移動性セッションへのIPv4ホームアドレスモビリティサポートを拡張するための再登録要求であると判断された場合、3.1節からの考察.2.2は、IPv4支持体に対して適用されなければなりません。
o If there is an IPv4 Home Address Request option present in the Proxy Binding Update message with the IPv4 address value in the option set to ALL_ZERO, the local mobility anchor MUST allocate an IPv4 home address to the mobile node and associate it with the new mobility session created for that mobile node.
すべての_ZEROに設定オプションでのIPv4アドレスの値とされたProxy Binding Updateメッセージに存在するIPv4のホームアドレス要求オプションがある場合は、O、ローカル・モビリティ・アンカーは、モバイルノードへのIPv4ホームアドレスを割り当て、新しいモビリティとそれを関連付ける必要がありますセッションは、そのモバイルノードのために作成しました。
o If there is an IPv4 Home Address Request option with the IPv4 address in the option set to a NON_ZERO value, the local mobility anchor, before accepting the request, MUST ensure that the address is topologically anchored on the local mobility anchor and furthermore that the mobile node is authorized to use that address. If the mobile node is not authorized for that specific address, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized for the requesting IPv4 address; see Section 3.3.5). It MUST also include the IPv4 Home Address Reply option (Section 3.3.2). in the reply with the Status field value in the option set to 129 (Administratively prohibited).
NON_ZERO値に設定オプションでのIPv4アドレスとIPv4のホームアドレス・リクエスト・オプションがある場合は、O、ローカル・モビリティ・アンカーは、要求を受け入れる前に、アドレスがトポロジー的にローカル・モビリティ・アンカーに固定され、さらにそのことを確認する必要がありますモバイルノードは、そのアドレスの使用を許可されています。モバイルノードは、その特定のアドレスのために許可されていない場合は、ローカル・モビリティ・アンカーは、要求を拒否し、NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS（モバイルノード要求のIPv4アドレスを許可しないように設定StatusフィールドとProxy Binding Acknowledgementメッセージを送らなければなりません。3.3.5項を参照してください）。また、IPv4のホームアドレスに返信オプション（3.3.2）を含まなければなりません。 129に設定するオプションのStatusフィールドの値を持つ応答で（管理上禁止）。
o If the local mobility anchor is unable to allocate an IPv4 address due to lack of resources, it MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to 130 (Insufficient resources). It MUST also include the IPv4 Home Address Reply option in the reply with the Status field value in the option set to 128 (Failure, reason unspecified).
ローカル・モビリティ・アンカーは、リソース不足にIPv4アドレスを割り当てることができない場合は、O、それは要求を拒否し、130（リソースが不足）に設定されたステータス・フィールドでのプロキシBinding Acknowledgementメッセージを送らなければなりません。また、128（失敗、詳細不明の理由）に設定するオプションのStatusフィールドの値を持つ応答でのIPv4ホームアドレス返信オプションを含まなければなりません。
o Upon accepting the request, the local mobility anchor MUST create a Binding Cache entry for this mobility session. However, if the request also contains one or more Home Network Prefix options [RFC5213], there should still be only one Binding Cache entry that should be created for this mobility session. The created Binding Cache entry MUST be used for managing both IPv4 and IPv6 home address bindings. The fields in the Binding Cache entry MUST be updated with the accepted values for that session.
O要求を受け付けると、ローカル・モビリティ・アンカーは、この移動性セッションのためのBinding Cacheエントリーを作成する必要があります。リクエストは、1つ以上のホームネットワークプレフィックスオプション[RFC5213]を含んでいる場合は、まだこの移動性セッションのために作成されなければならない唯一のBinding Cacheエントリーがあるはずです。作成されたバインディングキャッシュエントリは、IPv4とIPv6のホームアドレスのバインディングの両方を管理するために使用しなければなりません。 Binding Cacheエントリーのフィールドは、そのセッションのために受け入れられた値で更新されなければなりません。
o The local mobility anchor MUST establish a bidirectional tunnel to the mobile access gateway with the encapsulation mode set to the negotiated mode for carrying the IPv4 payload traffic. When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet). When using IPv4 transport, the encapsulation mode is as specified in Section 4.
Oローカル・モビリティ・アンカーは、IPv4ペイロードトラフィックを搬送するためのネゴシエートモードに設定カプセル化モードとモバイルアクセスゲートウェイに双方向トンネルを確立しなければなりません。 IPv6トランスポートを使用する場合、カプセル化モードは、IPv4またはIPv6の-オーバーのIPv6（IPv6パケットのペイロードとして運ばIPv4またはIPv6パケット）です。 IPv4トランスポートを使用する場合、セクション4で指定されるように、カプセル化モードです。
o The local mobility anchor MUST create an IPv4 host route (or a platform-specific equivalent function that sets up the forwarding) for tunneling the packets received for the mobile node's home address associated with this mobility session.
Oローカル・モビリティ・アンカーは、パケットがこのモビリティ・セッションに関連付けられたモバイルノードのホームアドレスを受信トンネリングのIPv4ホストルート（または転送を設定し、プラットフォーム固有の同等の機能）を作成する必要があります。
o The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update accepted). The message MUST be constructed as specified in Section 3.1.2.6.
Oローカル・モビリティ・アンカーは0に設定されたステータス・フィールド（受理されたProxy Binding Update）でのプロキシBinding Acknowledgementメッセージを送らなければなりません。セクション3.1.2.6で指定されるようにメッセージを構成しなければなりません。
All the considerations from Section 5.3.3 of [RFC5213] MUST be applied.
[RFC5213]のセクション5.3.3からのすべての考慮事項が適用されなければなりません。
o If there is no Home Network Prefix option [RFC5213] present in the request, but if the Binding Cache entry associated with this request has IPv6 home network prefix(es), the local mobility anchor MUST consider this as a request to extend lifetime only for the IPv4 home address and not for the IPv6 home network prefix(es). Hence, the local mobility anchor SHOULD release all the IPv6 home network prefix(es) assigned to that mobile node and for that specific attached interface. Similar considerations apply for the case where there is no IPv4 Home Address Request option present in the request, but if the Binding Cache entry associated with that request has both IPv4 home address and IPv6 home network prefix(es).
Oがリクエストに存在するいかなるホームネットワークプレフィックスオプション[RFC5213]はありませんが、このリクエストに関連付けられているバインディングキャッシュエントリがIPv6ホームネットワーク接頭語（es）を持っている場合は、ローカル・モビリティ・アンカーは寿命を延長するための要求としてこれを考慮しなければならない場合IPv4のホームアドレスのためではなくIPv6のホームネットワーク接頭語（es）のために。したがって、ローカル・モビリティ・アンカーはそのモバイルノードに、その特定の接続インターフェイスに割り当てられたすべてのIPv6ホームネットワーク接頭語（es）を解放する必要があります。同様の考察は、要求に存在する一切のIPv4ホームアドレス要求オプションが存在しない場合に適用されますが、その要求に関連した結合キャッシュ項目は、IPv4ホームアドレスとIPv6ホームネットワーク接頭語（es）の両方を持っている場合。
o The local mobility anchor MUST remove the previously created IPv4 host route (or the forwarding state) and the dynamically created bidirectional tunnel for carrying the IPv4 payload traffic (if there are no other mobile nodes for which the tunnel is being used). This will remove the routing state towards the mobile access gateway where the mobile node was anchored prior to the handoff.
Oローカル・モビリティ・アンカーは、以前に作成したIPv4ホストルート（または転送状態）と（トンネルが使用されているため、他の移動ノードが存在しない場合）のIPv4ペイロードトラフィックを搬送するための動的に作成された双方向トンネルを削除しなければなりません。これは、モバイルノードがハンドオフの前に固定されたモバイル・アクセス・ゲートウェイに向けてルーティング状態を削除します。
o The local mobility anchor MUST create a bidirectional tunnel to the mobile access gateway that sent the request (if there is no existing bidirectional tunnel) and with the encapsulation mode set to the negotiated mode for carrying the IPv4 payload traffic. An IPv4 host route for tunneling the packets received for the mobile node's IPv4 home address MUST also be added.
Oローカル・モビリティ・アンカーは、（既存の双方向トンネルが存在しない場合）要求を送信したモバイル・アクセス・ゲートウェイへの双方向トンネルを作成し、IPv4ペイロードトラフィックを搬送するためのネゴシエートモードに設定カプセル化モードにしなければなりません。モバイルノードのIPv4ホームアドレスに対して受信したパケットをトンネリングするためのIPv4ホストルートも加えなければなりません。
o The required forwarding state identified in Section 5.3.6 of [RFC5213] is for IPv6 payload traffic. Those considerations apply for IPv4 payload traffic as well. However, if IPv4 transport is in use, considerations from Section 4 MUST be applied.
[RFC5213]のセクション5.3.6において同定に必要な転送状態は、IPv6ペイロードトラフィックのためのものであるO。これらの考慮事項は、同様のIPv4ペイロードトラフィックに適用されます。 IPv4トランスポートが使用中である場合は、第4章からの考察が適用されなければなりません。
All the considerations from Section 5.3.5 of [RFC5213] MUST be applied. Additionally, to remove the IPv4 state as part of the Binding Cache entry deletion, the IPv4 host route and the dynamically created bidirectional tunnel for carrying the IPv4 payload traffic (if there are no other mobile nodes for which the tunnel is being used) MUST be removed. However, if the request is for a selective de-registration (IPv4 home address only, or all the IPv6 home network prefixes), the Binding Cache entry MUST NOT be deleted, only the respective states related to those addresses MUST be deleted.
[RFC5213]のセクション5.3.5からのすべての考慮事項が適用されなければなりません。また、バインディングキャッシュエントリの削除の一部としてのIPv4状態を除去するために、IPv4のペイロードトラフィックを搬送するIPv4ホストルートと動的に作成された双方向トンネル（トンネルが使用されているため、他の移動ノードが存在しない場合）でなければなりません削除しました。要求は、選択、登録解除（IPv4のみのホームアドレス、またはすべてのIPv6ホームネットワーク接頭語）のためである場合は、Binding Cacheエントリーがそれらのアドレスに関連する唯一のそれぞれの状態を削除する必要があり、削除しないでください。
When sending the Proxy Binding Acknowledgement message to the mobile access gateway, the local mobility anchor MUST construct the message as specified in Section 5.3.6 of [RFC5213]. Additionally, the following considerations MUST be applied.
モバイル・アクセス・ゲートウェイにプロキシバインディング肯定応答メッセージを送信するときに、ローカル・モビリティ・アンカーは、[RFC5213]のセクション5.3.6で指定されたメッセージを作成しなければなりません。また、以下の考慮事項が適用されなければなりません。
o Section 5.3.6 of [RFC5213] requires the local mobility anchor to include at least one instance of the Home Network Prefix option [RFC5213] in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. However, if the received Proxy Binding Update message has only the IPv4 Home Address Request option and does not contain the Home Network Prefix option(s), then the local mobility anchor MUST NOT include any Home Network Prefix option(s) in the reply. However, there MUST be at least one instance of either the Home Network Prefix option [RFC5213] or the IPv4 Home Address Reply option present in the Proxy Binding Acknowledgement message.
[RFC5213]のOセクション5.3.6は、モバイルアクセスゲートウェイに送信するプロキシBinding Acknowledgementメッセージにおけるホームネットワークプレフィックスオプション[RFC5213]の少なくとも1つのインスタンスが含まれるようにローカル・モビリティ・アンカーが必要です。受信されたProxy Binding Updateメッセージは、IPv4のみホームアドレス・リクエスト・オプションを持っており、ホームネットワークプレフィックスオプション（複数可）が含まれていない場合は、その後、ローカル・モビリティ・アンカーは、回答に任意のホームネットワークプレフィックスオプション（複数可）を含んではいけません。しかし、ホームネットワークプレフィックスオプション[RFC5213]またはプロキシバインディング肯定応答メッセージ中に存在したIPv4ホームアドレス回答オプションのいずれかの少なくとも1つのインスタンスが存在しなければなりません。
o The IPv4 Home Address Reply option MUST be present in the Proxy Binding Acknowledgement message.
OのIPv4ホームアドレス返信オプションは、Proxy Binding Acknowledgementメッセージ中に存在しなければなりません。
1. If the Status field is set to a value greater than or equal to 128, i.e., if the Proxy Binding Update is rejected, then there MUST be an IPv4 Home Address Reply option corresponding to the IPv4 Home Address Request option present in the request and with the IPv4 address value and the prefix length fields in the option set to the corresponding values in the request. The Status field value in the option must be set to the specific error code.
1.ステータスフィールドが128以上の値に設定されている場合は、プロキシバインディング更新が拒否された場合、すなわち、その要求に存在するIPv4のホームアドレス要求オプションに対応したIPv4ホームアドレスに返信するオプションがなければならない（MUST）そしてIPv4アドレス値と要求に対応する値に設定オプションでプレフィックス長フィールドを持ちます。オプションのStatusフィールドの値が特定のエラーコードに設定する必要があります。
2. For all other cases, there MUST be an IPv4 Home Address Reply option to carry the IPv4 home address assigned for that mobility session and with the value in the option set to the allocated IPv4 address. The prefix length in the option MUST be set to the prefix length of the mobile node's IPv4 home network. The Status field value in the option must be set to 0 (Success).
2.他のすべてのケースでは、その移動性セッションのために、割り当てられたIPv4アドレスに設定オプションの値を割り当てられたIPv4ホームアドレスを運ぶためのIPv4ホームアドレスに返信オプションがあるに違いありません。オプションでのプレフィックス長は、モバイルノードのIPv4ホームネットワークのプレフィックス長を設定しなければなりません。オプションのStatusフィールドの値が0（成功）に設定する必要があります。
o The IPv4 Default-Router Address option (Section 3.3.3) MUST be present, if the Status field value in the Proxy Binding Acknowledgement message is set to 0 (Proxy Binding Update accepted) [RFC5213]. Otherwise, the option MUST NOT be present. If the option is present, the default router address in the option MUST be set to the mobile node's default router address.
プロキシバインディング肯定応答メッセージのStatusフィールドの値が（受け入れプロキシバインディング更新）0に設定されている場合、OのIPv4デフォルト・ルータ・アドレス・オプション（セクション3.3.3）[RFC5213]、存在しなければなりません。それ以外の場合は、オプションが存在してはなりません。オプションが存在する場合は、オプションでデフォルトルータアドレスは、モバイルノードのデフォルトルータアドレスに設定しなければなりません。
The Binding Cache entry lookup considerations specified in Section 5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as the key parameter for identifying the Binding Cache entry. However, when there is not a single Home Network Prefix option with a NON_ZERO value present in the request, but there is an IPv4 Home Address option with a NON_ZERO value present in the request, then the following considerations MUST be applied.
[RFC5213]のセクション5.4.1.1で指定されたバインディングキャッシュエントリのルックアップの考慮事項は、Binding Cacheエントリーを識別するための重要なパラメータとして、ホームネットワークプレフィックスオプション[RFC5213]を使用しています。リクエストに存在NON_ZERO値を持つ単一のホームネットワークプレフィックスオプションが存在しませんが、リクエストに存在NON_ZERO値を持つIPv4のホームアドレスオプションがあった場合しかし、その後、次の考慮事項が適用されなければなりません。
o The search rules specified in Section 5.4.1.1 of [RFC5213], which primarily uses IPv6 home network prefix set as the search key, are equally valid when using a single IPv4 home address as the key. When applying those considerations, instead of the IPv6 home network prefix(es), the IPv4 home address from the IPv4 Home Address option present in the request MUST be used as the search key.
キーとして単一のIPv4ホームアドレスを使用した場合、主に検索キーとして設定されたIPv6ホームネットワークプレフィックスを使用しています[RFC5213]の5.4.1.1項で指定した検索ルールO、同様に有効です。これらの考慮事項を適用する場合、代わりにIPv6のホームネットワーク接頭語（es）の、要求に存在するIPv4のホームアドレスオプションからのIPv4ホームアドレスが検索キーとして使用しなければなりません。
o The rules specified in Section 5.4.1.1 of [RFC5213] assume the presence of one or more IPv6 home network prefixes in the received request and also in the Binding Cache entry. But, when using the IPv4 home address as the search key, these considerations MUST always assume just one single IPv4 home address, both in the request and also in the Binding Cache entry.
O [RFC5213]のセクション5.4.1.1で指定された規則は、受信した要求に、また結合キャッシュ・エントリ内の1つのまたは複数のIPv6ホームネットワークプレフィックスの存在を前提としています。検索キーとしてのIPv4ホームアドレスを使用した場合でも、これらの考慮事項は、常に要求にも結合キャッシュ項目の両方で、ただ1つのIPv4のホームアドレスを仮定しなければなりません。
Intercepting Packets Sent to the Mobile Node's IPv4 Home Address:
モバイルノードのIPv4ホームアドレスに送信されたパケットを傍受：
o When the local mobility anchor is serving a mobile node, it MUST advertise a connected route into the Routing Infrastructure for the mobile node's IPv4 home address or for its home subnet, in order to receive packets that are sent to the mobile node's IPv4 home address. This essentially enables IPv4 routers in that network to detect the local mobility anchor as the last-hop router for that subnet.
ローカル・モビリティ・アンカーは、モバイルノードにサービスを提供している場合は、O、それはモバイルノードのIPv4ホームアドレスに送信されたパケットを受信するために、モバイルノードのIPv4ホーム・アドレスまたはそのホームサブネットのルーティングインフラストラクチャへの接続ルートをアドバタイズしなければなりません。これは、本質的にそのサブネットの最後のホップルータとしてローカル・モビリティ・アンカーを検出するために、そのネットワーク内のIPv4ルーターを可能にします。
Forwarding Packets to the Mobile Node:
モバイルノードにパケットを転送します：
o On receiving a packet from a corresponding node with the destination address matching the mobile node's IPv4 home address, the local mobility anchor MUST forward the packet through the bidirectional tunnel setup for that mobile node.
OモバイルノードのIPv4ホームアドレスに一致する宛先アドレスに対応するノードからパケットを受信すると、ローカル・モビリティ・アンカーは、モバイルノードのための双方向トンネルのセットアップを介してパケットを転送しなければなりません。
o The format of the tunneled packet when payload protection is not enabled:
ペイロード保護が有効になっていないトンネリングされたパケットのフォーマットO：
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper-layer protocols /* Packet Content*/
Figure 2: Tunneled Packets from the Local Mobility Anchor (LMA) to the Mobile Access Gateway (MAG)
図2：モバイル・アクセス・ゲートウェイ（MAG）とローカル・モビリティ・アンカー（LMA）からトンネルパケット
Forwarding Packets Sent by the Mobile Node:
モバイルノードによって送信されたパケットを転送します：
o All the reverse tunneled packets that the local mobility anchor receives from the mobile access gateway, after removing the tunnel header, MUST be routed to the destination specified in the inner IPv4 packet header. These routed packets will have the Source Address field set to the mobile node's IPv4 home address.
Oローカル・モビリティ・アンカーは、モバイル・アクセス・ゲートウェイから受信したすべての逆トンネルパケットは、トンネルヘッダを除去した後、内側のIPv4パケットヘッダに指定された宛先にルーティングされなければなりません。これらのルーティングされたパケットは、移動ノードのIPv4ホームアドレスに送信元アドレスフィールドが設定されています。
The Explicit Congestion Notification (ECN) considerations specified in Section 5.6.3 of [RFC5213] apply for the IPv4 payload packets as well. The mobility agents at the tunnel entry and exit points MUST handle ECN information as specified in that document.
[RFC5213]のセクション5.6.3で指定された明示的輻輳通知（ECN）の考慮事項は、同様のIPv4ペイロードパケットに適用します。その文書で指定されたトンネルの入口と出口点でのモビリティエージェントは、ECN情報を処理する必要があります。
The mobility agents at the tunnel entry and exit points MUST apply the IP packet fragmentation considerations as specified in Section 7 of [RFC2473]; additionally, they MUST apply the considerations related to tunnel error processing and reporting as specified in Section 8 of [RFC2473].
[RFC2473]のセクション7で指定されたトンネルの入口と出口点でのモビリティエージェントは、IPパケットの断片化の考慮事項を適用しなければなりません。 [RFC2473]のセクション8で指定され、さらに、それらはトンネルエラー処理および報告に関する考慮事項を適用する必要があります。
To support the IPv4 home address mobility feature, the conceptual Binding Update List entry data structure needs to be extended with the following additional fields.
IPv4のホームアドレスモビリティ機能をサポートするために、概念バインディング更新リストエントリのデータ構造には、以下の追加フィールドで拡張する必要があります。
o The IPv4 home address assigned to the mobile node's attached interface. This IPv4 home address may have been statically configured in the mobile node's policy profile, or, may have been dynamically allocated by the local mobility anchor. The IPv4 home address entry also includes the corresponding subnet mask.
OのIPv4ホームアドレスは、モバイルノードの接続インタフェースに割り当てられました。このIPv4のホームアドレスは静的に、モバイルノードの方針プロフィールで設定されている可能性があり、または、動的ローカル・モビリティ・アンカーによって割り当てられている場合があります。 IPv4のホームアドレスのエントリは、対応するサブネットマスクを含んでいます。
o The IPv4 default router address of the mobile node. This is acquired from the mobile node's local mobility anchor through the received Proxy Binding Acknowledgement message.
モバイルノードのIPv4のデフォルトルータアドレスO。これは、受信されたプロキシBinding Acknowledgementメッセージを介して移動ノードのローカル・モビリティ・アンカーから取得されます。
To support the IPv4 home address mobility support feature, the mobile node's policy profile, specified in Section 6.2 of [RFC5213], MUST be extended with the following additional fields.
IPv4のホームアドレスモビリティサポート機能をサポートするには、[RFC5213]のセクション6.2で指定されたモバイルノードの方針プロフィールは、以下の追加フィールドを拡張する必要があります。
Extensions to the mandatory section of the policy profile:
ポリシープロファイルの必須セクションへの拡張：
o This field identifies all the IP versions for which the home address mobility support needs to be extended to the mobile node. The supported modes are IPv4-only, IPv6-only, and dual IPv4/IPv6.
Oこのフィールドは、ホームアドレスモビリティサポートは、モバイルノードに拡張する必要があるため、すべてのIPのバージョンを識別します。サポートされているモードは、IPv4のみ、IPv6のみ、およびデュアルIPv4 / IPv6のです。
Extensions to the optional section of the policy profile:
ポリシープロファイルのオプションのセクションへの拡張：
o The IPv4 home address assigned to the mobile node's attached interface. The specific details on how the network maintains the association between the address and the attached interface is outside the scope of this document. This address field also includes the corresponding subnet mask.
OのIPv4ホームアドレスは、モバイルノードの接続インタフェースに割り当てられました。ネットワークアドレスおよび接続されているインターフェイスとの間の関連付けを維持する方法についての具体的な詳細は、この文書の範囲外です。このアドレスフィールドには、対応するサブネットマスクを含んでいます。
After detecting a new mobile node on its access link, the mobile access gateway on the access link MUST determine if IPv4 home address mobility support needs to be enabled for that mobile node. The mobile node's policy profile identifies the supported modes (IPv4- only, IPv6-only, or dual IPv4/IPv6) for that mobile node for which the mobile service needs to be enabled. Based on those policy considerations and from other triggers such as from the network, if it is determined that IPv4 home address mobility support needs to be enabled for the mobile node, considerations from Section 6.9.1.1 of [RFC5213] MUST be applied with the following exceptions.
IPv4のホームアドレスモビリティサポートは、そのモバイルノードのために有効にする必要がある場合、そのアクセスリンクの上に新たなモバイルノードを検出した後、アクセスリンクの上のモバイルアクセスゲートウェイを決定する必要があります。モバイルノードのポリシプロファイルは、モバイルサービスを有効にする必要があるため、そのモバイルノードのためにサポートされているモード（IPv4-のみ、IPv6のみ、またはデュアルIPv4 / IPv6）を識別する。それが決定された場合、それらの政策の検討に及び、ネットワークからなどの他のトリガから基づいて、IPv4のホームアドレスモビリティサポートは、モバイルノードのために有効にする必要があること、[RFC5213]のセクション6.9.1.1からの考慮事項は、次を適用しなければなりません例外。
o The IPv4 Home Address Request option MUST be present in the Proxy Binding Update message.
OのIPv4ホームアドレス要求オプションは、Proxy Binding Updateメッセージに存在しなければなりません。
* If the mobile access gateway learns the mobile node's IPv4 home address either from its policy profile or from other means, the mobile access gateway MAY ask the local mobility anchor to allocate that specific address by including exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to that specific IPv4 address and the prefix length of the corresponding home network.
*モバイルアクセスゲートウェイがそのポリシープロファイルから、または他の手段のいずれかから、移動ノードのIPv4ホームアドレスを学習した場合は、モバイル・アクセス・ゲートウェイは、IPv4ホームアドレス・リクエスト・オプションの正確に一つのインスタンスを含めることにより、その特定のアドレスを割り当てるために、ローカルモビリティアンカーを求めることができますIPv4のホームアドレスと、その特定のIPv4アドレスと対応するホームネットワークのプレフィックス長さに設定オプションでのプレフィックス長さフィールドを持ちます。
* The mobile access gateway MAY also ask the local mobility anchor for dynamic IPv4 home address allocation. It can include exactly one instance of the IPv4 Home Address option with the IPv4 home address and the prefix length fields in the option set to the ALL_ZERO value. Furthermore, the (P) flag in the option MUST be set to 0. This serves as a request to the local mobility anchor for the IPv4 home address allocation.
*モバイル・アクセス・ゲートウェイは、動的IPv4のホームアドレス割り当てのローカル・モビリティ・アンカーを求めることができます。これは、IPv4ホームアドレスとすべての_ZERO値に設定オプションでのプレフィックス長さフィールドを持つIPv4のホームアドレスオプションの正確に一つのインスタンスを含めることができます。また、オプションで（P）フラグを0に設定しなければなりませんこれは、IPv4ホームアドレス割り当てのためのローカル・モビリティ・アンカーへの要求として働きます。
o The Proxy Binding Update message MUST be constructed as specified in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix option(s) [RFC5213] MUST be present in the Proxy Binding Update only if IPv6 home address mobility support also needs to be enabled for the mobile node. Otherwise, the Home Network Prefix option(s) MUST NOT be present.
[RFC5213]のセクション6.9.1.5で指定されるようにO Proxy Binding Updateメッセージを構築しなければなりません。しかし、ホームネットワークプレフィックスオプション（S）[RFC5213]はIPv6のホームアドレスモビリティサポートもモバイルノードのために有効にする必要があります場合にのみ、プロキシ・バインディング更新に存在しなければなりません。それ以外の場合は、ホームネットワークプレフィックスオプション（複数可）存在してはなりません。
o When using IPv4 transport to carry the signaling messages, the related considerations from Section 4 MUST be applied additionally.
シグナリングメッセージを運ぶためにIPv4トランスポートを使用する場合、O、セクション4から関連する考慮事項がさらに適用されなければなりません。
All the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied with the following exceptions.
[RFC5213]のセクション6.9.1.2からのすべての考慮事項は、次の例外を除いて適用されなければなりません。
o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (The mobile node is not authorized for IPv4 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including a IPv4 Home Address Request option until an administrative action is taken.
受信プロキシBinding Acknowledgementメッセージは、（移動ノードがIPv4のモビリティサービスのために許可されていない）NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICEに設定されたステータス・フィールドの値を持っている場合は、O、モバイル・アクセス・ゲートウェイは、までのIPv4ホームアドレス要求オプションを含めたProxy Binding Updateメッセージを送るべきではありません行政措置がとられています。
o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (The mobile node is not authorized for the requesting IPv4 home address), the mobile access gateway SHOULD NOT request the same IPv4 address again, but MAY request the local mobility anchor to perform the address assignment by including exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to the ALL_ZERO value.
O受信プロキシBinding AcknowledgementメッセージはNOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS（モバイルノードが要求したIPv4ホームアドレスのために許可されていない）に設定されたステータス・フィールドの値を持っている場合は、再度、同じIPv4アドレスを要求するべきではありませんが、地元の移動性を要求することができるモバイルアクセスゲートウェイアンカーは正確にIPv4のホームアドレスとすべての_ZERO値に設定オプションでのプレフィックス長さフィールドを持つIPv4のホームアドレス・リクエスト・オプションの1つのインスタンスを含めることにより、アドレスの割り当てを実行します。
o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (The mobile node is not authorized for IPv6 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including any Home Network Prefix option(s) until an administrative action is taken.
受信プロキシBinding Acknowledgementメッセージは、（モバイルノードがIPv6モビリティサービスのために許可されていない）NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICEに設定されたステータス・フィールドの値を持っている場合は、O、モバイルアクセスゲートウェイは、任意のホームネットワークプレフィックスオプション（複数可）を含むプロキシバインディング更新メッセージを送るべきではありません行政措置が取られるまで。
o If there is no IPv4 Home Address Reply option present in the received Proxy Binding Acknowledgement message, the mobile access gateway MUST NOT enable IPv4 support for the mobile node and the rest of the considerations from this section can be skipped.
受信プロキシBinding Acknowledgementメッセージに存在する一切のIPv4ホームアドレス返信オプションがない場合は、O、モバイル・アクセス・ゲートウェイは、移動ノードのIPv4サポートを有効にしてはならないと、このセクションからの考察の残りの部分をスキップすることができます。
o If the received Proxy Binding Acknowledgement message has the Status field value in the IPv4 Home Address Reply option set to a value that indicates that the request was rejected by the local mobility anchor, the mobile access gateway MUST NOT enable IPv4 mobility support.
受信プロキシBinding Acknowledgementメッセージは、要求がローカル・モビリティ・アンカーによって拒否されたことを示す値に設定されたIPv4ホームアドレス返信オプションのStatusフィールドの値を持っている場合は、O、モバイル・アクセス・ゲートウェイは、IPv4モビリティサポートを有効にしないでください。
o If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST update a Binding Update List entry for that mobile node. The entry MUST be updated with the assigned IPv4 home address and other accepted registration values.
受信されたProxy Binding Acknowledgementメッセージを0（受け入れられたProxy Binding Update）に設定されたステータスフィールドの値を持つ場合、O、モバイル・アクセス・ゲートウェイは、モバイルノードのためのバインディング更新リストエントリを更新しなければなりません。エントリは、割り当てられたIPv4ホームアドレスおよびその他の承認された登録値で更新されなければなりません。
o If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted) and has the IPv4 Home Address Reply option set to a value that indicates that the request was accepted by the local mobility anchor, the mobile access gateway MUST establish a bidirectional tunnel to the local mobility anchor (if there is no existing bidirectional tunnel to that local mobility anchor) and with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (an IPv4 or IPv6 packet carried as a payload of an IPv6 packet). Considerations from Section 5.6.1 of [RFC5213] MUST be applied for managing the dynamically created bidirectional tunnel. However, when using IPv4 transport, the encapsulation mode MUST be set to the negotiated encapsulation mode, as specified in Section 4 of this document.
O受信プロキシBinding Acknowledgementメッセージは、モバイルアクセスを0に設定ステータス・フィールドの値を持っている（プロキシバインディング更新を受け入れ）、要求がローカル・モビリティ・アンカーによって受け入れられたことを示す値に設定されたIPv4ホームアドレス返信オプションを持っている場合ゲートウェイは、（そのローカル・モビリティ・アンカーへの既存の双方向トンネルが存在しない場合）、ローカル・モビリティ・アンカーに双方向トンネルを確立したように実施のIPv4または、IPv6のオーバーのIPv6（IPv4またはIPv6パケットに設定カプセル化モードにしなければなりませんIPv6パケットのペイロード）。 [RFC5213]のセクション5.6.1からの考察は、動的に作成された双方向トンネルを管理するために適用されなければなりません。 IPv4トランスポートを使用する場合、このドキュメントのセクション4で指定されるようしかし、カプセル化モードは、ネゴシエートされたカプセル化モードに設定しなければなりません。
o The mobile access gateway MUST set up the route for forwarding the IPv4 packets received from the mobile node (using its IPv4 home address) through the bidirectional tunnel set up for that mobile node.
Oモバイル・アクセス・ゲートウェイは、移動ノード用に設定双方向トンネルを介して（そのIPv4のホーム・アドレスを使用して）モバイルノードから受信したIPv4パケットを転送するためのルートを設定する必要があります。
o The default router address MUST be obtained from the IPv4 Default-Router Address option present in the received Proxy Binding Acknowledgement message. The mobile access gateway SHOULD configure this address on its interface and respond to any Address Resolution Protocol (ARP) requests sent by the mobile node to resolve the hardware address of the default router. However, since the link between the mobile access gateway and the mobile node is a point-to-point link, implementations will be able receive any packets sent to the default router address without having to explicitly configure the default router address on its interface. The mobile access gateway MAY also use the default router address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. It MUST also use this address in the DHCP Router option [RFC2132] in the DHCP messages.
Oデフォルトルータアドレスが受信プロキシBinding Acknowledgementメッセージに存在するIPv4のデフォルト・ルータのアドレスオプションから取得する必要があります。モバイル・アクセス・ゲートウェイは、そのインターフェイス上でこのアドレスを設定し、デフォルトルータのハードウェアアドレスを解決するために、モバイルノードによって送信されたアドレス解決プロトコル（ARP）要求に応答する必要があります。モバイル・アクセス・ゲートウェイと移動ノードの間のリンクは、ポイントツーポイントリンクであるので、実装は、明示的にそのインターフェース上のデフォルトルータアドレスを設定しなくても、デフォルトルータのアドレスに送信されたパケットを受信することができるであろう。モバイル・アクセス・ゲートウェイは、移動ノードに送信され、モバイル・アクセス・ゲートウェイ自身が発信されたデータグラムのソースアドレスとしてデフォルトルータのアドレスを使用してもよいです。また、DHCPメッセージでDHCPルーターオプション[RFC2132]でこのアドレスを使用する必要があります。
o If there is an IPv4 DHCP Support Mode option (Section 3.3.4) present in the received Proxy Binding Acknowledgement message and if the (S) flag in the option is set to a value of (1), then the mobile access gateway MUST function as a DHCP server for the mobile node. If either the (S) flag in the option is set to a value of (0), or if the option is not present in the request, then the mobile access gateway MUST function as a DHCP Relay for the mobile node.
しなければならないモバイル・アクセス・ゲートウェイ、受信されたProxy Binding Acknowledgementメッセージおよびオプションで（S）フラグが（1）の値に設定されている場合、本IPv4のDHCPサポートモードオプション（セクション3.3.4）がある場合にはOモバイルノードのためのDHCPサーバとして機能します。オプションで（S）フラグ（0）の値に設定されている、またはオプションが要求に存在しない場合、モバイル・アクセス・ゲートウェイは、移動ノードのためのDHCPリレーとして機能しなければならない。いずれかの場合
When sending a Proxy Binding Update either to extend the lifetime of a mobility session or to de-register the mobility session, the respective considerations from [RFC5213] MUST be applied. Furthermore, the following additional considerations MUST also be applied.
モビリティセッションの寿命を延長するか、モビリティセッションを登録解除するか、プロキシバインディング更新を送信する場合、[RFC5213]からのそれぞれの考慮が適用されなければなりません。さらに、以下の追加の考慮事項も適用する必要があります。
o If there is an IPv4 home address assigned to the mobility session, then there MUST be exactly one instance of the IPv4 Home Address Request option present in the Proxy Binding Update message. The IPv4 home address and the prefix length fields in the option MUST be set to that specific address and its corresponding subnet-mask length.
モビリティセッションに割り当てられたIPv4ホームアドレスがある場合は、O、その後、Proxy Binding Updateメッセージに存在IPv4のホームアドレス・リクエスト・オプションの正確に一つのインスタンスがあるに違いありません。オプションでのIPv4ホームアドレスとプレフィックス長フィールドは、その特定のアドレスと対応するサブネットマスクの長さに設定しなければなりません。
o If there was no IPv4 home address requested in the initial Proxy Binding Update message, but it is determined that the IPv4 home address MUST be requested subsequently, then there MUST be exactly one instance of the IPv4 Home Address Request option present in the Proxy Binding Update message. The IPv4 home address in the option MUST be set to either ALL_ZERO or to a specific address that is being requested.
O初期プロキシバインディング更新メッセージで要求なしのIPv4ホームアドレスがありませんでしたが、それはIPv4のホームアドレスがその後に要求しなければならないと判断され、その後、バインディングプロキシに存在するIPv4のホームアドレス要求オプションの正確に一つのインスタンスが存在しなければならない場合メッセージを更新します。オプションでのIPv4ホームアドレスがすべての_ZEROのいずれかに、または要求されている特定のアドレスに設定しなければなりません。
o For performing selective de-registration of IPv4 home address but still retaining the mobility session with all the IPv6 home network prefixes, the Proxy Binding Update message with the lifetime value of (0) MUST NOT include any IPv6 Home Network Prefix options [RFC5213]. It MUST include exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to the IPv4 home address that is being de-registered. Similarly, for selective de-registration of all the IPv6 home network prefixes, the Proxy Binding Update message MUST NOT include the IPv4 Home address option, it MUST include a Home Network Prefix option for each of the assigned home network prefixes assigned for that mobility session and with the prefix value in the option set to that respective prefix value.
OのIPv4ホームアドレスを選択的に登録解除を実行するが、それでもすべてのIPv6ホームネットワークプレフィックスとモビリティセッションを保持するために、（0）の任意のIPv6ホームネットワークプレフィックスオプションを含んではいけません[RFC5213]の生涯価値を持つプロキシバインディング更新メッセージ。これは、登録解除されたIPv4ホームアドレスとIPv4ホームアドレスに設定オプションでのプレフィックス長さフィールドを持つIPv4のホームアドレス要求オプションの正確に一つのインスタンスを含まなければなりません。同様に、すべてのIPv6ホームネットワークプレフィックスの選択登録解除のために、プロキシバインディング更新メッセージは、IPv4ホームアドレスオプションを含んではいけません、それはその移動性セッションのために割り当てられた割り当てられたホームネットワークプレフィックスの各ホームネットワークプレフィックスオプションを含まなければなりませんそしてそのそれぞれのプレフィックス値に設定オプションで接頭辞の値を持ちます。
o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if the same option(s) was not present in the initial Proxy Binding Update message. Otherwise, considerations from [RFC5213] with respect to this option MUST be applied.
同じオプション（s）は、最初のプロキシバインディング更新メッセージには存在しなかった場合はホームネットワークプレフィックスオプション（S）O [RFC5213]は存在してはなりません。そうでない場合は、このオプションに関しては、[RFC5213]からの考慮事項が適用されなければなりません。
o If at any point the mobile access gateway fails to extend the binding lifetime with the local mobility anchor for the mobile node's IPv4 address, it MUST remove any forwarding state set up for the mobile node's IPv4 home address.
任意の時点でのモバイル・アクセス・ゲートウェイは、移動ノードのIPv4アドレスのためのローカル・モビリティ・アンカーと結合寿命を延ばすために失敗した場合、O、それはモバイルノードのIPv4ホーム・アドレス用に設定されたすべての転送状態を削除する必要があります。
o On receiving a packet from the bidirectional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST remove the outer header before forwarding the packet to the mobile node.
Oモバイルノードのローカル・モビリティ・アンカーとの間で確立双方向トンネルからパケットを受信すると、モバイル・アクセス・ゲートウェイは、移動ノードにパケットを転送する前に外部ヘッダを削除する必要があります。
o On receiving a packet from a mobile node connected to its access link, the packet MUST be forwarded to the local mobility anchor through the bidirectional tunnel established with the local mobility anchor. However, when the EnableMAGLocalRouting flag is set, considerations from Section 6.10.3 of [RFC5213] MUST be applied with respect to local routing.
Oのアクセス・リンクに接続されたモバイルノードからパケットを受信すると、パケットがローカル・モビリティ・アンカーとの間で確立双方向トンネルを介してローカル・モビリティ・アンカーに転送されなければなりません。 EnableMAGLocalRoutingフラグが設定されている場合しかし、[RFC5213]のセクション6.10.3からの考察は、ローカルルーティングに対して適用されなければなりません。
o When forwarding the packet through the bidirectional tunnel, the encapsulation considerations as specified in Section 3.1.3 MUST be applied (except that the source and destination addresses fields in the outer encapsulation header are reversed). However, before forwarding the packet, the mobile access gateway MUST ensure the source address in the received packet is the address allocated for that mobile node and that there is an active binding on the local mobility anchor for that mobile node.
双方向トンネルを介してパケットを転送する場合、O、セクション3.1.3で指定されるようにカプセル化の考慮事項は、（外側のカプセル化ヘッダ内の送信元アドレスと宛先アドレスフィールドが逆になっていることを除いて）適用されなければなりません。しかし、パケットを転送する前に、モバイル・アクセス・ゲートウェイは、受信したパケットの送信元アドレスが、そのモバイルノードのために割り当てられたアドレスで、そのモバイルノードのローカル・モビリティ・アンカーに結合する活性があることを確実にしなければなりません。
o The mobile access gateway SHOULD use the Proxy ARP [RFC0925] to reply to ARP Requests that it receives from the mobile node seeking address resolutions for the destinations on the mobile node's home subnet. When receiving an ARP Request, the mobile access gateway SHOULD examine the target IP address of the Request, and if this IP address matches the mobile node's IPv4 home subnet, it SHOULD transmit a Proxy ARP Reply. However, on certain types of links, the mobile node does not use ARP for address resolutions, instead it forwards all the packets to the mobile access gateway. On such types of links, the mobile access gateway is not required to support the Proxy ARP function. At the same time, implementations not supporting the Proxy ARP function on links where the mobile node uses ARP for seeking address resolutions for the destinations on the mobile node's home subnet will result in communication failure.
O ARPに返信するプロキシARP [RFC0925]を使用すべきであるモバイル・アクセス・ゲートウェイは、モバイルノードのホームサブネット上の宛先のアドレス解決を求めて移動ノードから受け取るように要求します。 ARP要求を受信すると、モバイルアクセスゲートウェイは、要求のターゲットIPアドレスを調べる必要があり、このIPアドレスは、移動ノードのIPv4ホームサブネットと一致した場合、それはプロキシARP Replyを送信しなければなりません。ただし、リンクの特定の種類に、モバイルノードは、その代わりに、モバイルアクセスゲートウェイへのすべてのパケットを転送し、アドレス解決のためにARPを使用していません。リンクのようなタイプでは、モバイルアクセスゲートウェイは、プロキシARP機能をサポートする必要はありません。同時に、実装は、モバイルノードが通信障害になり、モバイルノードのホームサブネット上の宛先のアドレス解決を追求するためにARPを使用して、リンク上のプロキシARP機能をサポートしていません。
To support the IPv4 home address mobility feature, this specification defines the following new options and status codes.
IPv4のホームアドレスモビリティ機能をサポートするために、この仕様は、次の新しいオプションとステータスコードを定義します。
A new option, the IPv4 Home Address Request option, is defined for use with the Proxy Binding Update message sent by the mobile access gateway to the local mobility anchor. This option is used to request IPv4 home address assignment for the mobile node.
新しいオプション、IPv4のホームアドレス・リクエスト・オプションは、ローカル・モビリティ・アンカーへのモバイルアクセスゲートウェイによって送信されたProxy Binding Updateメッセージで使用するために定義されています。このオプションは、モバイルノードのIPv4ホームアドレスの割り当てを要求するために使用されます。
The IPv4 Home Address Request option has an alignment requirement of 4n. Its format is as follows:
IPv4のホームアドレス・リクエスト・オプションは、4Nの整列要求があります。形式は以下の通りです：
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 |Prefix-len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Home Address Request Option
図3：IPv4のホームアドレス要求オプション
Type
タイプ
36
３６
Length
長さ
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6).
タイプと長さフィールドを除いオクテット内のオプションの長さを示す8ビットの符号なし整数。このフィールドは、（6）に設定しなければなりません。
Prefix-len
プレフィックスのみ
This 6-bit unsigned integer indicating the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option.
オプションに含まれるのIPv4ホームアドレスに対応する移動ノードのIPv4ホームネットワークのプレフィックス長を示す、この6ビットの符号なし整数。
Reserved
予約済み
This 10-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
この10ビットのフィールドは今のところ未使用です。値は、送信者（0）に初期化しなければならなくて、受信機で無視しなければなりません。
IPv4 home address
IPv4のホームアドレス
This 4-byte field containing the IPv4 home address that is being requested. The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation.
要求されたIPv4ホームアドレスを含む4バイトのフィールド。 0.0.0.0の値は、ローカル・モビリティ・アンカーは、アドレスの割り当てを行うことを要求するために使用されます。
A new option, the IPv4 Home Address Reply option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be used to send the assigned mobile node's IPv4 home address.
新しいオプション、IPv4のホームアドレスに返信オプションは、モバイルアクセスゲートウェイにローカルモビリティ・アンカーによって送信され、プロキシバインディング確認メッセージでの使用のために定義されています。このオプションは、割り当てられたモバイルノードのIPv4ホームアドレスを送信するために使用することができます。
The IPv4 Home Address Reply option has an alignment requirement of 4n. Its format is as follows:
IPv4のホームアドレスに返信オプションは、4Nの整列要求があります。形式は以下の通りです：
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 | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Home Address Reply Option
図4：IPv4のホームアドレスに返信オプション
Type
タイプ
37
３７
Length
長さ
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6).
タイプと長さフィールドを除いオクテット内のオプションの長さを示す8ビットの符号なし整数。このフィールドは、（6）に設定しなければなりません。
Status
状態
Indicates success or failure for the IPv4 home address assignment. Values from 0 to 127 indicate success. Higher values (128 to 255) indicate failure. The following Status values are currently allocated by this document:
IPv4のホームアドレスの割り当てのための成功または失敗を示します。 0から127までの値は、成功を示します。より高い値（255から128）が失敗したことを示しています。以下のステータス値は、現在、このドキュメントによって割り当てられます。
0 Success
0成功
128 Failure, reason unspecified
128失敗、詳細不明の理由
129 Administratively prohibited
管理上禁止さ129
130 Incorrect IPv4 home address
130の誤ったのIPv4ホーム・アドレス
131 Invalid IPv4 address
131無効なIPv4アドレス
132 Dynamic IPv4 home address assignment not available
利用できない132の動的IPv4のホームアドレスの割り当て
Prefix-len
プレフィックスのみ
This 6-bit unsigned integer is used to carry the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option.
この6ビットの符号なし整数は、オプションに含まれるのIPv4ホームアドレスに対応する移動ノードのIPv4ホームネットワークのプレフィックス長を搬送するために使用されます。
Reserved (Res)
予約（RES）
This 2-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
この2ビットのフィールドは、今のところ未使用です。値は、送信者（0）に初期化しなければならなくて、受信機で無視しなければなりません。
IPv4 home address
IPv4のホームアドレス
This 4-byte field is used to carry the IPv4 home address assigned to the mobile node.
この4バイトのフィールドは、モバイルノードに割り当てられたIPv4ホームアドレスを運ぶために使用されます。
A new option, the IPv4 Default-Router Address option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be used to send the mobile node's IPv4 default router address.
新しいオプション、IPv4のデフォルト・ルータのアドレスオプションは、モバイルアクセスゲートウェイにローカルモビリティ・アンカーによって送られたプロキシBinding Acknowledgementメッセージでの使用のために定義されています。このオプションは、モバイルノードのIPv4のデフォルトルータアドレスを送信するために使用することができます。
The IPv4 Default-Router Address option has an alignment requirement of 4n. Its format is as follows:
IPv4のデフォルト・ルータのアドレスオプションは、4Nの整列要求があります。形式は以下の通りです：
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 | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default-Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv4 Default-Router Address Option
図5：IPv4のデフォルト・ルータのアドレスオプション
Type
タイプ
38
３８
Length
長さ
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6).
タイプと長さフィールドを除いオクテット内のオプションの長さを示す8ビットの符号なし整数。このフィールドは、（6）に設定しなければなりません。
Reserved (R)
予約済み（R）
This 16-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
この16ビットのフィールドは今のところ未使用です。値は、送信者（0）に初期化しなければならなくて、受信機で無視しなければなりません。
IPv4 Default-Router Address
IPv4のデフォルト・ルータアドレス
A 4-byte field containing the mobile node's default router address.
モバイルノードのデフォルトルータアドレスを含む4バイトのフィールド。
A new option, the IPv4 DHCP Support Mode option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be used to notify the mobile access gateway as to whether it should function as a DHCP Server or a DHCP Relay for the attached mobile node.
新しいオプション、IPv4のDHCPサポートモードオプションは、モバイルアクセスゲートウェイにローカルモビリティ・アンカーによって送られたプロキシBinding Acknowledgementメッセージでの使用のために定義されています。このオプションは、それが取り付けられたモバイルノードのためのDHCPサーバまたはDHCPリレーとして機能すべきかどうかのモバイルアクセスゲートウェイに通知するために使用することができます。
The IPv4 DHCP Support Mode option has no alignment requirement. Its format is as follows:
IPv4のDHCPサポートモードオプションには、アライメントの必要がありません。形式は以下の通りです：
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 | Reserved (R) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv4 DHCP Support Mode Option
図6：IPv4のDHCPサポートモードオプション
Type
タイプ
39
３９
Length
長さ
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to 2.
タイプと長さフィールドを除いオクテット内のオプションの長さを示す8ビットの符号なし整数。このフィールドは2に設定しなければなりません。
Reserved (R)
予約済み（R）
This 15-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
この15ビットのフィールドは今のところ未使用です。値は、送信者（0）に初期化しなければならなくて、受信機で無視しなければなりません。
DHCP Support Mode (S)
DHCPサポートモード（S）
A 1-bit field that specifies the DHCP support mode. This flag indicates whether the mobile access gateway should function as a DHCP Server or a DHCP Relay for the attached mobile node. The flag value of (0) indicates the mobile access gateway should act as a DHCP Relay, and the flag value of (1) indicates it should act as a DHCP Server.
DHCPサポートモードを指定する1ビットのフィールド。このフラグは、モバイル・アクセス・ゲートウェイは、添付のモバイルノードのためのDHCPサーバまたはDHCPリレーとして機能するかどうかを示します。 （0）モバイルアクセスゲートウェイはDHCPリレーとして作用する必要があることを示し、そして（1）のフラグ値のフラグ値は、DHCPサーバとして行動しなければならない示します。
This document defines the following new Status values for use in the Proxy Binding Acknowledgement message. These values are to be allocated from the same numbering space, as defined in Section 6.1.8 of [RFC3775].
この文書では、Proxy Binding Acknowledgementメッセージで使用するために、次の新しいステータス値を定義します。これらの値は、[RFC3775]のセクション6.1.8で定義されるように、同じ番号空間から割り当てが行われます。
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE：170
Mobile node not authorized for IPv4 mobility service.
モバイルノードは、IPv4モビリティサービスのために許可されていません。
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS：171
Mobile node not authorized for the requesting IPv4 home address.
モバイルノードは、要求のIPv4ホームアドレスで認証されていません。
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE：172
Mobile node not authorized for IPv6 mobility service.
モバイルノードは、IPv6モビリティサービスのために許可されていません。
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED：173
Multiple IPv4 home address assignments not supported.
複数のIPv4ホームアドレスの割り当てがサポートされていません。
This section explains how DHCP-based address configuration support can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It explains the protocol operation, supported DHCP server deployment configurations, and the protocol interactions between DHCP agents and mobility entities in each of the supported configurations.
このセクションでは、DHCPベースのアドレス設定のサポートは、プロキシモバイルIPv6ドメインのモバイルノードのために有効にすることができる方法を説明します。これは、プロトコル操作、サポートDHCPサーバの配置構成、およびサポートされる構成のそれぞれでDHCPエージェントおよびモビリティエンティティ間のプロトコルの相互作用を説明します。
This specification supports the following two DHCP deployment configurations.
この仕様は、次の2つのDHCPの展開構成をサポートしています。
o DHCP relay agent co-located with the mobile access gateway.
O DHCPリレーエージェントは、モバイル・アクセス・ゲートウェイと同じ場所に配置。
o DHCP server co-located in the mobile access gateway.
モバイルアクセスゲートウェイに同じ場所に配置OのDHCPサーバ。
The following are the configuration requirements:
以下では、構成要件は次のとおりです。
o The DHCP server or the DHCP relay agent configured on the mobile access gateway is required to have an IPv4 address for exchanging the DHCP messages with the mobile node. This address is the mobile node's default router address provided by the local mobility anchor. Optionally, all the DHCP servers co-located with the mobile access gateways in the Proxy Mobile IPv6 domain can be configured with a fixed IPv4 address. This fixed address can be an IPv4 private address [RFC1918] that can be used for the DHCP protocol communication on any of the access links. This address will be used as the server identifier in the DHCP messages.
O DHCPサーバまたはモバイル・アクセス・ゲートウェイに設定DHCPリレーエージェントは、モバイルノードとDHCPメッセージを交換するためのIPv4アドレスが要求されます。このアドレスはローカルモビリティアンカーが提供するモバイルノードのデフォルトルータアドレスです。必要に応じて、プロキシモバイルIPv6ドメインでモバイルアクセスゲートウェイと同じ場所に、すべてのDHCPサーバーは、固定されたIPv4アドレスを使用して設定することができます。この固定アドレスは、アクセスリンクのいずれかのDHCPプロトコル通信のために使用することができるのIPv4プライベートアドレス[RFC1918]することができます。このアドレスはDHCPメッセージでサーバ識別子として使用されます。
o A DHCP server identifies a DHCP interface from the contents of the DHCP "Client-identifier" option [RFC2132], if present, or from the client hardware address (chaddr), as specified in [RFC2131]. Note that the name "Client-identifier" is a misnomer as it actually identifies an interface and not the client. The DHCP server uses this identity to identify the interface for which the address is assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach to the network through multiple interfaces and can obtain address configuration for each of its interfaces. Additionally, it may perform handoffs between its interfaces. The following are the related considerations with respect to the identification presented to the DHCP server.
DHCPサーバO [RFC2131]で指定されるように、DHCP「クライアント識別子」オプション[RFC2132]の内容から、存在する場合、またはクライアントハードウェアアドレス（とchaddr）からDHCPインタフェースを識別する。それは実際にはインタフェースではなく、クライアントを識別するよう名前を「クライアント識別子」は誤った名称であることに注意してください。 DHCPサーバは、アドレスが割り当てられているためのインタフェースを識別するために、このIDを使用しています。プロキシ・モバイルIPv6ドメイン内のモバイルノードは、複数のインタフェースを介してネットワークに接続することができ、そのインターフェースのそれぞれのアドレス構成を得ることができます。また、そのインタフェース間のハンドオフを実行することができます。 DHCPサーバに提示識別に関して関連の考慮事項は次のとおり。
* If the mobile node attaches to the Proxy Mobile IPv6 domain through multiple physical interfaces, the DHCP server will uniquely identify each of those interfaces and will perform address assignment. The DHCP server will identify the interface as specified in RFC 2131. The mobile node SHOULD generate and use the "Client-identifier" for each physical interface according to [RFC4361]. Any time the mobile node performs a handoff of a physical interface to a different mobile access gateway, using the same interface, the DHCP server will always be able to identify the binding using the presented identifier. The presented identifier (either the "Client-identifier" or the hardware address) will remain as the primary key for each binding, just as how they are unique in a Binding Cache entry.
*モバイルノードが複数の物理インターフェイスを介してプロキシ・モバイルIPv6ドメインに付着している場合、DHCPサーバは一意にこれらのインタフェースの各々を識別し、アドレス割り当てを実行します。モバイルノードは、[RFC4361]によれば、各物理インターフェイスのための「クライアント識別子」を生成して使用すべきであるRFC 2131に指定されたDHCPサーバは、インタフェースを識別する。モバイルノードが同じインタフェースを使用して、異なるモバイル・アクセス・ゲートウェイに物理インターフェイスのハンドオフを実行する任意の時間は、DHCPサーバは常に提示された識別子を使用して結合を識別することができるであろう。提示された識別子（「クライアント識別子」またはハードウェアアドレスのどちらか）はちょうど彼らがバインディングキャッシュエントリ内で一意であるかのように、それぞれの結合のための主キーとして残ります。
* If the mobile node is capable of performing a handoff between interfaces, as per [RFC5213], a "Client-identifier" value MUST be used for the attachment point that is not tied to any of the physical interfaces. The identifier MUST be generated according to [RFC4361], which guarantees that the identifier is stable and unique across all "Client-identifier" values in use in the Proxy Mobile IPv6 domain.
* [RFC5213]あたり、「クライアント識別子」の値は、物理インターフェイスのいずれかに接続されていない接続ポイントのために使用されなければならないので、モバイルノードは、インタフェース間のハンドオフを行うことができる場合。識別子は、識別子が安定して、プロキシモバイルIPv6ドメイン内の使用中のすべての「クライアント識別子」の値全体で一意であることを保証する[RFC4361]に従って生成しなければなりません。
o All the DHCP servers co-located with the mobile access gateways in a Proxy Mobile IPv6 domain can be configured with the same set of DHCP option values (e.g., DNS Server, SIP Server, etc.) to ensure the mobile node receives the same configuration values on any of the access links in that Proxy Mobile IPv6 domain.
OプロキシモバイルIPv6ドメインでモバイルアクセスゲートウェイと同じ場所にすべてのDHCPサーバは、モバイルノードが同じを受け取る確保するためにDHCPオプションの値（例えば、DNSサーバ、SIPサーバなど）の同じセットを使用して設定することができますそのProxyのモバイルIPv6ドメインのアクセスリンクのいずれかの設定値。
This section explains the operational sequence of home address assignment operation when the DHCP server is co-located with the mobile access gateway.
DHCPサーバは、モバイル・アクセス・ゲートウェイと同じ場所に配置されたときにこのセクションでは、ホームアドレス割り当て操作の動作シーケンスを説明します。
MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK
| | |
Figure 7: Overview of DHCP Server Located at Mobile Access Gateway
図7：モバイルアクセスゲートウェイに位置DHCPサーバーの概要
o It is possible that the mobile access gateway may have already completed the Proxy Mobile IPv6 signaling with the local mobility anchor to request both IPv6 home network prefix(es) and IPv4 home address assignment prior to Step 1. In such an event, the Proxy Mobile IPv6 signaling steps (Steps 2 to 4) above are not relevant.
モバイル・アクセス・ゲートウェイが既にのIPv6ホームネットワークプレフィックス（ES）と、プロキシそのような場合には1ステップ前のIPv4ホームアドレス割り当ての両方を要求するローカル・モビリティ・アンカーとシグナリングプロキシモバイルIPv6を完了していることがOことが可能ですモバイルIPv6シグナリング手順は、（2~4段階）上記関係がありません。
o It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling prior to Step 1, but only for requesting IPv6 home network prefix(es), and it may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node as shown above.
Oモバイル・アクセス・ゲートウェイは、最初に1工程の前に、シグナリングプロキシモバイルIPv6を完了するが、IPv6のみホームネットワーク接頭語（es）の要求を持っているかもしれことができ、後でDHCPからトリガ検出後のIPv4ホームアドレスの割り当てを要求することができます上記のようにモバイルノード。
o The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node.
Oモバイル・アクセス・ゲートウェイは、プロキシモバイルIPv6シグナリングが正常に完了するまで、DHCPDISCOVERメッセージを無視することを選択することができる、またはそれはモバイルノードから新たなDHCPDISCOVERメッセージを待つ追加の遅延を低減するための遅延応答を送信することを選択することができます。
Initial IPv4 Home Address Assignment:
初期のIPv4ホームアドレス割り当て：
o To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor.
ローカル・モビリティ・アンカーからモバイルノードのIPv4ホームアドレスを取得するために、O、モバイルアクセスゲートウェイは、ローカルモビリティアンカーとシグナリングプロキシモバイルIPv6を開始します。
o After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the DHCP server on the mobile access gateway will send a DHCPOFFER message [RFC2131] to the mobile node. The offered address will be the mobile node's IPv4 home address, assigned by the local mobility anchor. The DHCPOFFER message will also have the Subnet Mask option [RFC2132] and Router option [RFC2132], with the values in those options set to the mobile node's IPv4 home subnet mask and default router address, respectively. Additionally, the Server Identifier option will be included and with the value in the option set to the default router address.
OプロキシモバイルIPv6のシグナリングのとローカル・モビリティ・アンカーからモバイルノードのIPv4ホームアドレスを取得すると正常に完了した後、モバイルアクセスゲートウェイ上のDHCPサーバは、モバイルノードにDHCPOFFERメッセージ[RFC2131]を送信します。提供されたアドレスは、ローカル・モビリティ・アンカーによって割り当てられたモバイルノードのIPv4ホーム・アドレスになります。 DHCPOFFERメッセージには、それぞれ、モバイルノードのIPv4ホームサブネットマスク、デフォルトルータアドレスに設定これらのオプションの値とサブネットマスクオプション[RFC2132]とルーターオプション[RFC2132]を、持っています。また、サーバ識別子オプションは含まれており、デフォルトルータアドレスに設定オプションの値を持つことになります。
o If the mobile node sends the DHCPREQUEST message, the DHCP server will send DHCPACK message, as per [RFC2131].
モバイルノードがDHCPREQUESTメッセージを送信する場合、O、DHCPサーバは、[RFC2131]に従って、DHCPACKメッセージを送信します。
IPv4 Home Address Renewal with the DHCP Server (No Handoff):
DHCPサーバー（ハンドオフ）とのIPv4ホームアドレスリニューアル：
o Any time the mobile node goes into the DHCP RENEWING state [RFC2131], it simply unicasts the DHCPREQUEST message including the assigned IPv4 home address in the 'Requested IP Address' option. The DHCPREQUEST is sent to the address specified in the Server Identifier option of the previously received DHCPOFFER and DHCPACK messages.
モバイルノードは、状態[RFC2131]をRENEWING DHCPに入るいつでもO、それは単に「要求されたIPアドレス」オプションで割り当てられたIPv4ホームアドレスを含むDHCPREQUESTメッセージをユニキャストします。 DHCPREQUESTは、以前に受信したDHCPOFFERとDHCPACKメッセージのサーバ識別子オプションで指定したアドレスに送信されます。
o The DHCP server will send a DHCPACK to the mobile node to acknowledge the assignment of the committed IPv4 address.
O DHCPサーバは、コミットIPv4アドレスの割り当てを確認するために、モバイルノードにDHCPACKを送信します。
IPv4 Home Address Renewal with the DHCP Server (after Handoff):
（ハンドオフ後）DHCPサーバーとのIPv4ホームアドレスリニューアル：
When the mobile node goes into the DHCP RENEWING state [RFC2131], it directly unicasts the DHCPREQUEST message to the DHCP server that currently provided the DHCP lease. However, if the mobile node changed its point of attachment and is attached to a new mobile access gateway, it is required that the mobile node update the DHCP server address and use the address of the DHCP server that is co-located with the new mobile access gateway. The following approach can be adopted to ensure the mobile node uses the DHCP server on the attached link.
モバイルノードは、DHCP RENEWING状態[RFC2131]になったとき、それは直接、現在のDHCPリースを提供したDHCPサーバにDHCPREQUESTメッセージをユニキャストします。モバイルノードが接続ポイントを変更して、新しいモバイル・アクセス・ゲートウェイに接続されている場合しかし、モバイルノードがDHCPサーバのアドレスを更新し、新しいモバイルと同じ場所に配置されているDHCPサーバのアドレスを使用することが必要ですアクセスゲートウェイ。以下のアプローチは、モバイルノードが取付けられたリンク上のDHCPサーバを使用して確実にするために採用することができます。
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : |
* The use of a fixed DHCP server address on all DHCP servers
Figure 8: Address Renewal with the DHCP Server
図8：DHCPサーバーと住所リニューアル
o The use of a stable address, either the IPv4 default router address of the mobile node or a fixed IPv4 address common in that Proxy Mobile IPv6 domain, as the DHCP Server Identifier will ensure the DHCPREQUEST message sent by the mobile node to renew the address will be received by the new mobile access gateway on the attached link.
いずれかの移動ノードのIPv4のデフォルトルータのアドレスまたはそのプロキシモバイルIPv6ドメインにおける共通固定IPv4アドレス安定したアドレスの使用、O、DHCPサーバ識別子アドレスを更新するためにモバイルノードによって送信されたDHCPREQUESTメッセージを確実にするように添付のリンク上の新しいモバイルアクセスゲートウェイによって受信されます。
o The mobile access gateway after completing the Proxy Mobile IPv6 signaling and upon acquiring the IPv4 home address of the mobile node will return the address in the DHCPACK message. However, if the mobile access gateway is unable to complete the Proxy Mobile
OプロキシモバイルIPv6シグナリングを完了した後、モバイルノードのIPv4ホームアドレスを取得すると、モバイル・アクセス・ゲートウェイは、DHCPACKメッセージにアドレスを返します。しかし、モバイル・アクセス・ゲートウェイは、プロキシモバイルを完了することができない場合
IPv6 signaling or is unable to acquire the same IPv4 address as requested by the mobile node, it will send a DHCPNACK message [RFC2131] to the mobile node, as shown in Figure 8.
図8に示すように、IPv6のシグナリングまたはモバイルノードによって要求されたのと同じIPv4アドレスを取得することができない、それは、移動ノードにDHCPNACKメッセージ[RFC2131]を送信します。
A DHCP relay agent is co-located with each mobile access gateway. A DHCP server is located somewhere in the Proxy Mobile IPv6 domain (e.g., is co-located with the local mobility anchor). Figure 9 shows the sequence of IPv4 home address assignment using DHCP Relay.
DHCPリレーエージェントは、各モバイル・アクセス・ゲートウェイと同じ場所に配置されています。 DHCPサーバはどこか（例えば、ローカル・モビリティ・アンカーと同じ場所に配置された）プロキシモバイルIPv6ドメインに位置しています。図9は、DHCPリレーを使用したIPv4ホームアドレスの割り当てのシーケンスを示しています。
MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | |
Figure 9: Overview of the DHCP Relay Located at Mobile Access Gateway
図9：モバイルアクセスゲートウェイに位置DHCPリレーの概要
o The Proxy Mobile IPv6 signaling (starting at Step 1) and the DHCP address configuration (starting at Step 4) may start in any order. However, the DHCPOFFER (Step 5) and the immediate steps following it will occur in the specified order and only after the Tunnel/ Route Setup (Step 3).
OプロキシモバイルIPv6のシグナリングとする（ステップ4から始まる）DHCPアドレス設定（ステップ1から始まる）は、任意の順序で開始してもよいです。しかし、DHCPOFFER（ステップ5）と指定された順序でのみトンネル/ルートの設定（ステップ3）の後に起こるであろうことを、次の即時手順。
o It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling with the local mobility anchor only to request IPv6 home network prefix(es) and may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node (after Step 4).
O（モバイル・アクセス・ゲートウェイは、最初だけのIPv6ホームネットワークプレフィックス（ES）を要求するローカル・モビリティ・アンカーとシグナリングプロキシモバイルIPv6を完了している場合があり、後でDHCPは、移動ノードからトリガ検出した後のIPv4ホームアドレスの割り当てを要求することが可能ですステップ4の後）。
o The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node.
Oモバイル・アクセス・ゲートウェイは、プロキシモバイルIPv6シグナリングが正常に完了するまで、DHCPDISCOVERメッセージを無視することを選択することができる、またはそれはモバイルノードから新たなDHCPDISCOVERメッセージを待つ追加の遅延を低減するための遅延応答を送信することを選択することができます。
Initial IPv4 Home Address Assignment:
初期のIPv4ホームアドレス割り当て：
o To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor.
ローカル・モビリティ・アンカーからモバイルノードのIPv4ホームアドレスを取得するために、O、モバイルアクセスゲートウェイは、ローカルモビリティアンカーとシグナリングプロキシモバイルIPv6を開始します。
o After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will enable forwarding for all the DHCP messages between the mobile node and the DHCP server.
OプロキシモバイルIPv6のシグナリングのとローカル・モビリティ・アンカーからモバイルノードのIPv4ホームアドレスを取得すると正常に完了した後、モバイルアクセスゲートウェイは、モバイルノードとDHCPサーバ間のすべてのDHCPメッセージの転送を可能にします。
o The DHCP relay agent on the mobile access gateway will add the DHCP Relay Agent Information option [RFC3046] to the DHCPDISCOVER message. The assigned IPv4 home address will be included in the Agent Remote ID Sub-option of the DHCP Relay Agent Information option. This sub-option is used as a hint for requesting the DHCP server to allocate that specific IPv4 address.
Oモバイルアクセスゲートウェイ上のDHCPリレーエージェントは、DHCPDISCOVERメッセージをDHCPリレーエージェント情報オプション[RFC3046]を追加します。割り当てられたIPv4ホームアドレスはDHCPリレーエージェント情報オプションのエージェントリモートIDサブオプションに含まれます。このサブオプションは、その特定のIPv4アドレスを割り当てるためにDHCPサーバーを要求するためのヒントとして使用されます。
o On receiving a DHCPOFFER message from the DHCP server, the mobile access gateway will ensure the assigned address is currently assigned by the local mobility anchor to that mobile node. If this address is different from what is assigned to the mobile node, then the mobile access gateway will drop the DHCPOFFER message and an administrative error message will be logged.
O DHCPサーバからのDHCPOFFERメッセージを受信すると、モバイル・アクセス・ゲートウェイは、割り当てられたアドレスが現在その移動ノードにローカル・モビリティ・アンカーによって割り当てられるようになります。このアドレスはモバイルノードに割り当てられているものと異なる場合は、モバイル・アクセス・ゲートウェイは、DHCPOFFERメッセージをドロップし、管理者にエラーメッセージが記録されます。
o When the DHCP messages are sent over administrative boundaries, the operators need to ensure these messages are secured. All the DHCP messages relayed by the mobile access gateway can be tunneled to the local mobility anchor if needed. Alternatively, if the network in the Proxy Mobile IPv6 domain is secure enough, the mobile access gateway can just relay the DHCP messages to the server. To achieve this, all the mobile access gateways need to have a route towards the DHCP server.
DHCPメッセージは管理境界を介して送信される場合には、O、オペレータは、これらのメッセージが固定されていることを確認する必要があります。必要に応じて、モバイルアクセスゲートウェイによって中継されたすべてのDHCPメッセージは、ローカル・モビリティ・アンカーにトンネリングすることができます。プロキシモバイルIPv6ドメインのネットワークが十分に安全である場合あるいは、モバイル・アクセス・ゲートウェイは、単にサーバにDHCPメッセージをリレーすることができます。これを実現するために、すべてのモバイル・アクセス・ゲートウェイは、DHCPサーバへのルートを持っている必要があります。
IPv4 Home Address Renewal to the same DHCP Server: (No Handoff)
同じDHCPサーバーへのIPv4ホームアドレスリニューアル：（ハンドオフ）
o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it directly unicasts DHCPREQUEST messages to the DHCP server. The DHCP relay agent may not detect any changes in the DHCP state. For example, if the mobile node releases the IPv4 address, the relay agent would not be aware of it. The following describes additional mechanisms for the mobile access gateway to detect any changes in the DHCP state.
DHCPクライアントがDHCPになるとO STATE [RFC2131]をRENEW、それが直接DHCPサーバにDHCPREQUESTメッセージをユニキャストします。 DHCPリレーエージェントは、DHCPの状態の変更を検出しないことがあります。モバイルノードは、IPv4アドレスを解放した場合、リレーエージェントはそれを認識していないでしょう。以下は、DHCPの状態の変化を検出するために、モバイル・アクセス・ゲートウェイのための追加のメカニズムを説明しています。
* The DHCP relay agent can intercept all IPv4 DHCP packets destined to the set of addresses used within the Proxy Mobile IPv6 domain as DHCP addresses. Since the link between a mobile node and a mobile access gateway is the point-to-point link, the mobile access gateway will be in path for all the messages.
* DHCPリレーエージェントは、DHCPアドレスなどのプロキシモバイルIPv6ドメイン内で使用されるアドレスのセットに宛てすべてのIPv4 DHCPパケットを傍受することができます。モバイルノードとモバイルアクセスゲートウェイの間のリンクは、ポイントツーポイントリンクであるため、モバイル・アクセス・ゲートウェイは、すべてのメッセージのパスになります。
* The DHCP relay agent can use the DHCP Server Identifier Override Sub-option [RFC5107] to be in path for all the DHCP message flows. The DHCP client uses the DHCP server address that is overridden by the DHCP relay agent address as a destination address of DHCPREQUEST. The DHCP Server Identifier Override Sub-option is recommended only when the fixed DHCP relay address is configured on all the mobile access gateways. Otherwise, the DHCP relay agent address is changed when the mobile node changes the attached mobile access gateway.
* DHCPリレーエージェントは、メッセージが流れるすべてのDHCPのパスであることをDHCPサーバ識別子上書きサブオプション[RFC5107]を使用することができます。 DHCPクライアントは、DHCPREQUESTの宛先アドレスとしてDHCPリレーエージェントアドレスで上書きされるDHCPサーバのアドレスを使用しています。固定DHCPリレーアドレスは、すべてのモバイルアクセスゲートウェイ上で設定されている場合にのみDHCPサーバー識別子上書きサブオプションが推奨されます。モバイルノードが接続しているモバイル・アクセス・ゲートウェイを変更した場合そうでない場合には、DHCPリレーエージェントアドレスが変更されます。
o However, if the DHCP server is co-located with the local mobility anchor, then the DHCP relay agent is not required to intercept the unicast DHCP messages between the mobile node and the DHCP server. This is because the local mobility anchor will ensure that the DHCP state is consistent with the Proxy Mobile IPv6 binding that exists for the IPv4 address.
DHCPサーバがローカル・モビリティ・アンカーと同じ場所に配置されている場合、Oしかし、その後、DHCPリレーエージェントは、モバイルノードとDHCPサーバ間のユニキャストDHCPメッセージを傍受するために必要とされていません。ローカル・モビリティ・アンカーは、DHCPの状態がプロキシモバイルIPv6はそのIPv4アドレスのために存在するバインディングと一致していることを確実にするためです。
o Once the mobile access gateway intercepts the DHCP message from the mobile node to the DHCP server, it can verify if the mobile node is negotiating the same IPv4 address that the local mobility anchor allocated for that mobile node. If the address in the DHCPREQUEST message does not match with the IPv4 address allocated for the mobile node, then the mobile access gateway SHOULD drop the DHCP message and an administrative error message can be logged.
モバイル・アクセス・ゲートウェイは、DHCPサーバに、移動ノードからのDHCPメッセージを傍受した後、モバイルノードは、ローカル・モビリティ・アンカーは、そのモバイルノードのために割り当てられた同一のIPv4アドレスをネゴシエートされた場合にO、それは検証することができます。 DHCPREQUESTメッセージ内のアドレスはモバイルノードのために割り当てられたIPv4アドレスと一致しない場合は、モバイル・アクセス・ゲートウェイは、DHCPメッセージをドロップする必要があり、管理者にエラーメッセージがログに記録することができます。
o Any time the mobile access gateway detects that the mobile node has released its IPv4 address, it can send a Proxy Binding Update to the local mobility anchor and de-register the IPv4 mobility session.
Oモバイルアクセスゲートウェイは、モバイルノードは、そのIPv4アドレスを解放したことを検出したときはいつでも、それは地元の移動性アンカーにProxy Binding Updateを送信することができますし、IPv4モビリティセッションを登録解除。
The following DHCP-related considerations are common to both the supported configuration modes, specified in Sections 3.4.1 and 3.4.2.
以下のDHCP関連の考慮事項は、セクション3.4.1と3.4.2で指定されたサポートコンフィギュレーションモード、両方に共通しています。
o When a mobile node sends a DHCPDISCOVER message [RFC2131], the DHCP server or the relay agent co-located with the mobile access gateway will trigger the mobile access gateway to complete the Proxy Mobile IPv6 signaling. This is the required interaction between these two protocols. The mobile access gateway, on receiving this trigger, will check if there is already an assigned IPv4 home address for the mobile node, from the local mobility anchor. If there is no assigned IPv4 home address assigned for that mobile node, the mobile access gateway will complete the Proxy Mobile IPv6 signaling with the local mobility anchor by sending a Proxy Binding Update message.
モバイルノードは、DHCPDISCOVERメッセージ[RFC2131]を送信するとき、O、DHCPサーバーまたはリレーエージェントモバイル・アクセス・ゲートウェイと同じ場所に配置プロキシモバイルIPv6シグナリングを完了するために、モバイル・アクセス・ゲートウェイをトリガします。これは、これら2つのプロトコルの間に必要な相互作用です。すでにモバイルノードのために割り当てられたIPv4ホーム・アドレスがある場合、モバイル・アクセス・ゲートウェイは、このトリガーを受けた上で、ローカル・モビリティ・アンカーから、チェックします。そのモバイルノードのために割り当てられた割り当てられたIPv4ホームアドレスが存在しない場合は、モバイル・アクセス・ゲートウェイは、プロキシバインディング更新メッセージを送信することにより、ローカルモビリティアンカーとシグナリングプロキシモバイルIPv6を完了します。
o The mobile node needs to be identified by the MN-Identifier, as specified in Section 6.6 of [RFC5213]. This identity should be associated to the DHCP messages sent by the mobile node.
[RFC5213]のセクション6.6で指定されるように、モバイルノードは、MN-識別子によって識別される必要があるO。このIDは、モバイルノードによって送信されたDHCPメッセージに関連付けられている必要があります。
o The mobile access gateway will drop all the DHCPDISCOVER messages until it completes the Proxy Mobile IPv6 signaling. If the mobile access gateway is unable to complete the Proxy Mobile IPv6 signaling, or, if the local mobility anchor does not assign an IPv4 address for the mobile node, the mobile access gateway MUST NOT enable IPv4 home address mobility support for the mobile node on that access link.
それはプロキシモバイルIPv6のシグナリングを完了するまで、Oモバイル・アクセス・ゲートウェイは、すべてのDHCPDISCOVERメッセージをドロップします。モバイルアクセスゲートウェイは、プロキシモバイルIPv6のシグナリングを完了することができない、または、ローカル・モビリティ・アンカーは、モバイルノードのIPv4アドレスを割り当てていない場合は、モバイル・アクセス・ゲートウェイは、上のモバイルノードのIPv4ホームアドレスモビリティサポートを有効にしていなければならない場合そのアクセスリンク。
o The trigger for initiating Proxy Mobile IPv6 signaling can also be delivered to the mobile access gateway as part of a context transfer from the previous mobile access gateway, or delivered from the other network elements in the radio network, the details of which are outside the scope of this document.
プロキシモバイルIPv6シグナリングを開始するためのトリガは、以前のモバイル・アクセス・ゲートウェイからコンテキスト転送の一部として、モバイル・アクセス・ゲートウェイに配信、又は無線ネットワーク内の他のネットワーク要素から送達することができるO、の詳細は外側にありますこのドキュメントの範囲。
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Subnet Mask option [RFC2132] and the Router option [RFC2132]. The values in the Subnet Mask option and Router option MUST be set to the mobile node's IPv4 home subnet mask and its default router address, respectively.
Oモバイルノードに送信されたDHCPOFFERメッセージ[RFC2131]はサブネットマスクオプション[RFC2132]とルータ・オプション[RFC2132]を含まなければなりません。サブネットマスクオプションとルーターオプションの値は、それぞれ、モバイルノードのIPv4ホームサブネットマスクとデフォルトルータアドレスに設定しなければなりません。
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Interface MTU option [RFC2132]. The DHCP servers in the Proxy Mobile IPv6 domain MUST be configured to include the Interface MTU option. The MTU value SHOULD reflect the tunnel MTU for the bidirectional tunnel between the mobile access gateway and the local mobility anchor.
Oモバイルノードに送信されたDHCPOFFERメッセージ[RFC2131]はインターフェイスMTUオプション[RFC2132]を含まなければなりません。プロキシモバイルIPv6ドメインのDHCPサーバは、インターフェイスのMTUオプションを含むように構成されなければなりません。 MTU値は、モバイルアクセスゲートウェイとローカル・モビリティ・アンカーとの間の双方向トンネルのトンネルMTUを反映すべきです。
o The DHCP lease length allocated to the mobile node's IPv4 home address may be different from the binding lifetime at the local mobility anchor for that mobile node's session. It is not possible to keep these lifetimes synchronized, and so its not required that the configured lifetimes should be kept same in both DHCP and Proxy Mobile IPv6.
OモバイルノードのIPv4ホームアドレスに割り当てられたDHCPリースの長さは、そのモバイルノードのセッションのローカル・モビリティ・アンカーに結合寿命とは異なる場合があります。同期され、これらの寿命を維持することは不可能であり、したがってその構成された寿命はDHCPおよびプロキシモバイルIPv6の両方で同じに保たれるべきであることは必要ありません。
o When the mobile node performs a handoff from one mobile access gateway to another, the mobile access gateway on the new link will initiate the Proxy Mobile IPv6 signaling with the local mobility anchor. On completing the Proxy Mobile IPv6 signaling, the mobile access gateway has the proper IPv4 address state that the local mobility anchor has allocated for the mobile node and that can be used for supporting DHCP based address configuration on that link.
モバイルノードが別のモバイルアクセスゲートウェイからハンドオフを実行するとき、O、新しいリンク上のモバイル・アクセス・ゲートウェイは、ローカルモビリティアンカーとプロキシモバイルIPv6シグナリングを開始します。プロキシモバイルIPv6シグナリングを完了するに、モバイル・アクセス・ゲートウェイは、ローカル・モビリティ・アンカーは、モバイルノードのために割り当てられた適切なIPv4アドレス状態を有し、それは、そのリンク上のDHCPベースのアドレスの設定をサポートするために使用することができます。
o Any time the mobile node detects a link change event due to handoff, or due to other reasons such as re-establishment of the link-layer, the following are the mobile node's considerations with respect to the DHCP protocol.
Oいつでもモバイルノードが、あるいはこのようなリンク層の再確立などの他の理由により、ハンドオフにリンク変更イベントを検出し、DHCPプロトコルに対してモバイルノードの考慮事項は次のとおり。
* If the mobile node is DNAv4-capable (Detecting Network Attachment version 4) [RFC4436] and if it performs DNAv4 procedures after receiving a link change event, it would always detect the same default router on any of the access links in that Proxy Mobile IPv6 domain, as the mobile access gateway configures a fixed link-layer address on all the access links, as per the base Proxy Mobile IPv6 specification [RFC5213]. The mobile node will not perform any DHCP operation specifically due to this event.
*モバイルノードはDNAv4可能な（検出ネットワーク接続バージョン4）[RFC4436]であり、それはリンク変更イベントを受信した後DNAv4手順を実行する場合、それは常にそのプロキシモバイルでアクセスリンクのいずれかで同じデフォルトルータを検出したい場合モバイル・アクセス・ゲートウェイとしてIPv6ドメインは、ベースプロキシモバイルIPv6仕様[RFC5213]に従って、すべてのアクセス・リンク上の固定されたリンク層アドレスを構成します。モバイルノードが原因このイベントに特異的に任意のDHCPの操作を実行しません。
* If the mobile node is not DNAv4-capable [RFC4436], after receiving the link change event it will enter INIT-REBOOT state [RFC2131] and will send a DHCPREQUEST message as specified in Section 3.7 of [RFC2131]. The mobile node will obtain the same address configuration as before, as the link change does not result in any change at the network layer.
*モバイルノードがDNAv4可能な[RFC4436]でない場合は、リンク変更イベントを受信した後、それはINIT-REBOOT状態[RFC2131]を入力し、[RFC2131]のセクション3.7で指定されるようにDHCPREQUESTメッセージを送信します。リンク変更は、ネットワーク層における任意の変化をもたらさないように、移動ノードは、前と同じアドレス構成を取得します。
o The mobile node may release its IPv4 home address at any time by sending the DHCPRELEASE message [RFC2131]. When the mobile access gateway detects the DHCPRELEASE message sent by the mobile node, it should consider this as a trigger for de-registering the mobile node's IPv4 home address. It will apply the considerations specified in Section 3.2.3.3 for performing the de-registration procedure. However, this operation MUST NOT release any IPv6 home network prefix(es) assigned to the mobile node.
OモバイルノードはDHCPRELEASEメッセージ[RFC2131]を送信することによって、いつでもたIPv4ホームアドレスを解放することができます。モバイル・アクセス・ゲートウェイは、モバイルノードによって送信されたDHCPRELEASEメッセージを検出すると、登録解除、移動ノードのIPv4ホーム・アドレスのためのトリガーとしてこれを考慮する必要があります。これは、登録解除の手続きを行うために、セクション3.2.3.3で指定された注意事項を適用します。しかし、この操作は、移動ノードに割り当てられたIPv6ホームネットワーク接頭語（es）を放出してはなりません。
The Proxy Mobile IPv6 specification [RFC5213] requires the signaling messages exchanged between the local mobility anchor and the mobile access gateway to be over an IPv6 transport. However, in some cases, the local mobility anchor and the mobile access gateway are separated by an IPv4 network.
プロキシモバイルIPv6仕様[RFC5213]は、シグナリングメッセージは、IPv6トランスポート上であることがローカル・モビリティ・アンカーとモバイルアクセスゲートウェイとの間で交換が必要です。しかし、いくつかのケースでは、ローカル・モビリティ・アンカーとモバイル・アクセス・ゲートウェイは、IPv4ネットワークによって分離されています。
The normal Proxy Mobile IPv6 specification [RFC5213] can be run over an IPv4 transport without any modifications by using a transition technology that allows IPv6 hosts to communicate over IPv4 networks. For example, the mobile access gateway and the local mobility anchor could have a simple configured IPv6-over-IPv4 tunnel. Instead of configured tunnels, various mechanisms for automatic tunneling could be used, too. To these tunnels, Proxy Mobile IPv6 would look just like any other application traffic running over IPv6.
通常のプロキシ・モバイルIPv6仕様[RFC5213]はIPv6をIPv4ネットワーク上で通信するためにホストすることができ、遷移技術を使用して変更せずIPv4トランスポート上で実行することができます。例えば、モバイルアクセスゲートウェイとローカル・モビリティ・アンカーは、単純な構成IPv6-over-IPv4トンネルを有することができます。代わりに、設定されたトンネルの、自動トンネリングのための様々な機構も、使用することができます。これらのトンネルに、プロキシモバイルIPv6はちょうどIPv6の上で実行されている他のアプリケーショントラフィックのようになります。
However, treating Proxy Mobile IPv6 just like any other IPv6 traffic would mean an extra layer of encapsulation for the mobile node's tunneled data traffic, adding 40 octets of overhead for each packet.
しかし、ただ、他のIPv6トラフィックのようにプロキシモバイルIPv6を処理して、各パケットのオーバーヘッドの40個のオクテットを追加して、モバイルノードのトンネリングされたデータトラフィックのカプセル化の余分な層を意味します。
The extensions defined in this section allow the mobile access gateway and the local mobility anchor to communicate over an IPv4 network without this overhead.
このセクションで定義された拡張はモバイルアクセスゲートウェイとローカル・モビリティ・アンカーは、このオーバーヘッドなしにIPv4ネットワークを介して通信することを可能にします。
IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + |
+--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+
+ - - - - - - +
Figure 10: IPv4 Transport Network
図10：IPv4のトランスポート・ネットワーク
When the local mobility anchor and the mobile access gateway are configured and reachable using only IPv4 addresses, the mobile access gateway serving a mobile node can potentially send the signaling messages over IPv4 transport and register its IPv4 address as the care-of address in the mobile node's Binding Cache entry. An IPv4 tunnel (with any of the supported encapsulation modes) can be used for tunneling the mobile node's data traffic. The following are the key aspects of this feature.
ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイがただIPv4アドレスを使用して設定し、到達している場合、モバイルノードにサービスを提供するモバイルアクセスゲートウェイは、潜在的にはIPv4トランスポートを介してシグナリングメッセージを送信し、気付アドレスモバイルのように、そのIPv4アドレスを登録することができますノードのBinding Cacheエントリー。 （サポートされているカプセル化モードのいずれかを有する）のIPv4トンネルは、モバイルノードのデータトラフィックをトンネリングするために使用することができます。以下では、この機能の重要な側面です。
o The local mobility anchor and the mobile access gateway are both configured and reachable using an IPv4 address of the same scope.
ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイoを両方が同じスコープのIPv4アドレスを使用して設定し、到達可能です。
o The IPv4 addresses used can be private IPv4 addresses, but it is assumed that there is no NAT between the local mobility anchor and the mobile access gateway. However, it is possible to use UDP encapsulation if other types of middleboxes are present.
oを使用したIPv4アドレスは、プライベートIPv4アドレスすることができますが、地元の移動性アンカーとモバイルアクセスゲートウェイの間にNATが存在しないと仮定されます。しかし、ミドルボックスの他のタイプが存在する場合、UDPカプセル化を使用することが可能です。
o The Mobility Header [RFC3775] is carried inside an IPv4 packet with UDP header (IPv4-UDP-MH), using a UDP port number for Proxy Mobile IPv6 signaling over IPv4.
oをモビリティヘッダ[RFC3775]はプロキシモバイルIPv6は、IPv4上でシグナリングのためのUDPポート番号を使用して、UDPヘッダ（IPv4の-UDP-MH）でIPv4パケット内部に搬送されます。
o The mobile node can be an IPv6, IPv4, or a dual IPv4/IPv6 node and the IPv4 transport support specified in this section is agnostic to the type of address mobility enabled for that mobile node.
モバイルノードは、IPv6、IPv4の、またはデュアルIPv4 / IPv6ノードであることができ、このセクションで指定されたIPv4トランスポートのサポートは、そのモバイルノードのための有効アドレスモビリティの種類にとらわれはO。
o The mobile node's data traffic will be tunneled between the local mobility anchor and the mobile access gateway. There are several encapsulation modes available:
Oモバイルノードのデータトラフィックは、地元の移動性アンカーとモバイルアクセスゲートウェイの間でトンネリングされます。利用可能ないくつかのカプセル化モードがあります。
* IPv4 (IPv4 or IPv6 payload packet carried in an IPv4 packet). If payload protection using IPsec is enabled for the tunneled traffic, the Encapsulating Security Payload (ESP) header follows the outer tunnel header.
*はIPv4（IPv4パケットで運ばれたIPv4またはIPv6ペイロードパケット）。 IPsecを使用して、ペイロード保護がトンネルトラフィックに対して有効になっている場合、カプセル化セキュリティペイロード（ESP）ヘッダは、外側トンネルヘッダに続きます。
* IPv4-UDP (payload packet carried in an IPv4 packet with UDP header, using a UDP port number for Proxy Mobile IPv6 data; this is different port than is used for signaling). If payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3.
*のIPv4-UDP（ペイロードパケットはプロキシモバイルIPv6データのUDPポート番号を使用して、UDPヘッダとIPv4パケットで運ばれた;これは、シグナリングのために使用されるものとは異なるポートです）。 IPsecを使用して、ペイロード保護が有効になっている場合は、セクション4.3で説明したように、ESPヘッダは、外側IPv4ヘッダの後に続きます。
* IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP and TLV header) and IPv4-GRE (Payload packet carried in an IPv4 packet with GRE header). Refer to [GREKEY]. If payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3.
*とIPv4 GRE（GREヘッダーを持つIPv4パケットで運ばれたペイロードパケット）のIPv4-UDP-TLV（UDP及びTLVヘッダとIPv4パケットで運ばれるペイロードパケット）。 [GREKEY]を参照してください。 IPsecを使用して、ペイロード保護が有効になっている場合は、セクション4.3で説明したように、ESPヘッダは、外側IPv4ヘッダの後に続きます。
To support this feature, the conceptual Binding Cache entry data structure maintained by the local mobility anchor [RFC5213] MUST be extended with the following additional parameters. It is to be noted that all of these parameters are specified in [RFC5555] and also required here in the present usage context, and are presented here only for completeness.
この機能をサポートするために、ローカル・モビリティ・アンカー[RFC5213]によって維持概念バインディングキャッシュエントリのデータ構造は、以下の追加パラメータを用いて拡張されなければなりません。これは、これらのパラメータの全ては、[RFC5555]で指定され、また現在利用文脈でここで必要とのみ完全性のためにここに提示されていることに留意すべきです。
o The IPv4 Proxy Care-of Address configured on the mobile access gateway that sent the Proxy Binding Update message. The address MUST be the same as the source address of the received IPv4 packet that contains the Proxy Binding Update message. However, if the received Proxy Binding Update message is not sent as an IPv4 packet, i.e., when using IPv6 transport, this field in the Binding Cache entry MUST be set to the ALL_ZERO value.
oをIPv4のプロキシ気付アドレスは、Proxy Binding Updateメッセージを送信したモバイル・アクセス・ゲートウェイに設定します。アドレスは、Proxy Binding Updateメッセージが含まれている受信したIPv4パケットのソースアドレスと同じでなければなりません。受信されたProxy Binding UpdateメッセージをIPv4パケットとして送信されていない場合、IPv6トランスポートを使用する場合しかし、すなわち、バインディングキャッシュエントリのこのフィールドは、すべての_ZERO値に設定しなければなりません。
To support the IPv4 Transport Support feature, the mobile node's policy profile, specified in Section 6.2 of [RFC5213], MUST be extended with the following additional fields. These are mandatory fields of the policy profile required for supporting this feature.
IPv4の交通サポート機能をサポートするには、[RFC5213]のセクション6.2で指定されたモバイルノードの方針プロフィールは、以下の追加フィールドを拡張する必要があります。これらは、この機能をサポートするために必要なポリシープロファイルの必須フィールドです。
o The IPv4 address of the local mobility anchor (IPv4-LMAA).
ローカル・モビリティ・アンカー（IPv4の-LMAA）のIPv4アドレスO。
This section provides the rules for processing the Proxy Mobile IPv6 signaling messages received over IPv4 transport.
このセクションでは、IPv4トランスポートを介して受信したメッセージをシグナリングプロキシモバイルIPv6を処理するためのルールを提供します。
o If the Proxy Binding Update message is protected with IPsec ESP, IPsec processing happens before the packet is passed to Proxy Mobile IPv6.
プロキシバインディング更新メッセージはIPsecのESPで保護されている場合、パケットは、プロキシモバイルIPv6に渡される前に、O、IPsec処理が行われます。
o All the considerations from Section 5.3.1 of [RFC5213] except Step 1 (about IPsec) MUST be applied on the encapsulated Proxy Binding Update message. Note that the Checksum field in Mobility Header MUST be ignored.
O（IPsecの約）ステップ1を除い[RFC5213]のセクション5.3.1からのすべての考慮事項は、カプセル化されたProxy Binding Updateメッセージに適用されなければなりません。モビリティヘッダのチェックサムフィールドは無視しなければなりませんので注意してください。
o Upon accepting the request, the local mobility anchor MUST set up an IPv4 bidirectional tunnel to the mobile access gateway. The tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. The encapsulation mode MUST be determined by applying the following considerations:
O要求を受け付けると、ローカル・モビリティ・アンカーは、モバイル・アクセス・ゲートウェイへのIPv4双方向トンネルを設定する必要があります。トンネルエンドポイントアドレスは、IPv4-LMAAとIPv4プロキシブチリル-CoAです。カプセル化モードは、以下の考慮事項を適用することにより決定されなければなりません。
* If the (F) flag in the received Proxy Binding Update message is set to the value of (1), but if the configuration flag, AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of (0), then the local mobility anchor MUST reject the request with the Status field value set to 129 (Administratively prohibited).
*受信されたProxy Binding Updateメッセージにおける（F）フラグの値に設定されている場合、設定フラグ、AcceptForcedIPv4UDPEncapsulationRequestは、の値に設定されている場合（1）が、（0）、次いで、ローカル・モビリティ・アンカーを拒絶しなければなりません129に設定されたステータス・フィールドの値を持つ要求（管理上禁止）。
* If the (T) flag is set to (1), or GRE Key option is included, see [GREKEY].
*（T）フラグ（1）に設定されている、またはGREキーオプションが含まれている場合、[GREKEY]参照。
* If the (F) flag in the received Proxy Binding Update message is set to the value of (1), then the encapsulation mode MUST be set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set to IPv4.
受信したプロキシに（F）フラグがBinding Updateメッセージは、（1）の値に設定されている場合*は、カプセル化モードは、IPv4 UDPに設定しなければなりません。それ以外の場合は、カプセル化モードは、IPv4に設定しなければなりません。
o The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field value set to (0) (Proxy Binding Update accepted). The message MUST be constructed as specified in Section 4.1.3.2.
Oローカル・モビリティ・アンカーは（0）（プロキシバインディング更新が受け入れ）に設定されたステータス・フィールドの値とProxy Binding Acknowledgementメッセージを送らなければなりません。セクション4.1.3.2で指定されるようにメッセージを構成しなければなりません。
The local mobility anchor when sending the Proxy Binding Acknowledgement message to the mobile access gateway MUST construct the message as specified in Section 5.3.6 of [RFC5213]. However, if the Proxy Binding Update message was received over IPv4, the following additional considerations MUST be applied.
[RFC5213]のセクション5.3.6で指定されるようにモバイルアクセスゲートウェイへプロキシバインディング肯定応答メッセージを送信するローカル・モビリティ・アンカーは、メッセージを構築しなければなりません。 Proxy Binding Updateメッセージは、IPv4を介して受信した場合は、次の追加の考慮事項が適用されなければなりません。
o The IPv6 Header is removed, and the Mobility Header containing the Proxy Binding Acknowledgement is encapsulated in UDP (with source port set to 5436 and destination port set to the source port of the received Proxy Binding Update message). The Mobility Header Checksum field MUST be set to zero (and the UDP checksum MUST be used instead).
OのIPv6ヘッダを除去し、プロキシバインディング肯定応答を含むモビリティヘッダ（5436に設定し、ソースポートと受信されたProxy Binding Updateメッセージの送信元ポートに設定された宛先ポートに）UDPにカプセル化されます。モビリティヘッダチェックサムフィールドがゼロに設定されなければならない（そしてUDPチェックサムが代わりに使用されなければなりません）。
o The source address in the IPv4 header of the message MUST be set to the destination IPv4 address of the received request.
OメッセージのIPv4ヘッダーのソースアドレスは、受信した要求の宛先IPv4アドレスに設定しなければなりません。
o If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3.
IPsecのESPは、シグナリングを保護するために使用されている場合は、セクション4.3で説明したように、O、パケットはESPトランスポートモードを使用して処理されます。
o Figure 11 shows the format of the Proxy Binding Acknowledgement message sent over IPv4 and protected using ESP.
O図11は、IPv4を介して送信されたProxy Binding Acknowledgementメッセージのフォーマットを示し、ESPを使用して保護しました。
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) ESP header (in transport mode) UDP header (sport=5436, dport=5436) Mobility Header (PBA)
IPv4ヘッダ（SRC = IPv4にLMAA、DST = pbu_src_address）（トランスポートモード）ESPヘッダ、UDPヘッダ（スポーツ= 5436、DPORT = 5436）モビリティヘッダ（PBA）
Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over IPv4
図11：プロキシは、肯定応答（PBA）メッセージは、IPv4を介して送信されるバインディング
Forwarding Packets to the Mobile Node:
モバイルノードにパケットを転送します：
o On receiving an IPv4 or an IPv6 packet from a correspondent node with the destination address matching any of the mobile node's IPv4 or IPv6 home addresses, the local mobility anchor MUST forward the packet through the bidirectional tunnel set up for that mobile node.
OモバイルノードのIPv4またはIPv6ホームアドレスのいずれかと一致する宛先アドレスを有する相手ノードからIPv4またはIPv6パケットを受信すると、ローカル・モビリティ・アンカーは、モバイルノードのために設定双方向トンネルを介してパケットを転送しなければなりません。
o The format of the tunneled packet is shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes are described in [GREKEY].
Oトンネリングされたパケットのフォーマットを以下に示します。 IPv4の-UDP-TLVとIPv4 GREカプセル化モードは[GREKEY]に記載されています。
IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */
[UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src=CN, dst=MN-HOA)
OR
IPv4 header (src=CN, dst=IPv4-MN-HoA)
Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP
Encapsulation Mode)
o Forwarding Packets Sent by the Mobile Node:
モバイルノードによって送信されたOパケット転送：
* All the reverse tunneled packets (IPv4 and IPv6) that the local mobility anchor receives from the mobile access gateway, after removing the tunnel header (i.e., the outer IPv4 header along with the UDP and TLV header, if negotiated) MUST be routed to the destination specified in the inner packet header. These routed packets will have the source address field set to the mobile node's home address.
*すべての逆トンネルパケット（IPv4とIPv6）ローカル・モビリティ・アンカーは、トンネルヘッダを除去した後、モバイル・アクセス・ゲートウェイから受信した（すなわち、UDP及びTLVヘッダと共に外側IPv4ヘッダは、ネゴシエートされた場合）にルーティングされなければなりません内部パケットのヘッダで指定された宛先。これらのルーティングされたパケットは、モバイルノードのホームアドレスに送信元アドレスフィールドが設定されています。
The ECN considerations specified in Section 5.6.3 of [RFC5213] apply for the IPv4 transport tunnels as well. The mobility agents at the tunnel entry and exit points MUST handle ECN information as specified in that document.
[RFC5213]のセクション5.6.3で指定されたECNの考慮もIPv4トランスポートトンネルに適用されます。その文書で指定されたトンネルの入口と出口点でのモビリティエージェントは、ECN情報を処理する必要があります。
The mobility agents at the tunnel entry and exit points MUST apply the IP packet fragmentation considerations as specified in [RFC4213]. Additionally, they MUST also apply the considerations related to tunnel error processing and reporting as specified in the same specification.
[RFC4213]で指定されるように、トンネルの入口と出口点でのモビリティエージェントは、IPパケットの断片化の考慮事項を適用する必要があります。さらに、それらはまた、同じ仕様で指定されたトンネルエラー処理および報告に関する考慮事項を適用する必要があります。
The Tunnel Management considerations specified in Section 5.6.1 of [RFC5213] apply for the IPv4 transport tunnels as well, with just one difference that the encapsulation mode is different.
[RFC5213]のセクション5.6.1で指定されたトンネル管理の考慮事項カプセル化モードが異なっていることに一つだけの違いで、同様にIPv4トランスポートトンネルに適用されます。
To support the IPv4 Transport Support feature, the conceptual Binding Update List entry data structure maintained by the mobile access gateway [RFC5213] MUST be extended with the following additional parameters.
IPv4のトランスポートサポート機能をサポートするために、モバイル・アクセス・ゲートウェイ[RFC5213]によって維持概念バインディング更新リストエントリのデータ構造は、以下の追加パラメータを用いて拡張されなければなりません。
o The IPv4 address of the local mobility anchor. This address can be obtained from the mobile node's policy profile.
ローカル・モビリティ・アンカーのIPv4アドレスO。このアドレスは、モバイルノードのポリシープロファイルから取得することができます。
The mobile access gateway, when sending a Proxy Binding Update message to the local mobility anchor, MUST construct the message as specified in Section 6.9.1.5 of [RFC5213]. However, if the mobile access gateway is in an IPv4-only access network, the following additional considerations MUST be applied.
[RFC5213]のセクション6.9.1.5で指定されるようにローカル・モビリティ・アンカーにProxy Binding Updateメッセージを送信するモバイル・アクセス・ゲートウェイは、メッセージを構築しなければなりません。モバイル・アクセス・ゲートウェイは、IPv4のみのアクセス・ネットワーク内にある場合は、次の追加の考慮事項が適用されなければなりません。
o The Proxy Binding Update message MUST be sent over IPv4 as described in Section 4.2.2.1.
セクション4.2.2.1に記載されるようにProxy Binding Updateメッセージは、IPv4を介して送信されなければならないO。
o Just as specified in [RFC5213], when sending a Proxy Binding Update message for extending the lifetime of a currently existing mobility session or to de-register the mobility session, the Proxy Binding Update message MUST be constructed just as the initial request.
現在、既存のモビリティセッションの寿命を延長または登録解除モビリティセッションへのプロキシバインディング更新メッセージを送信するときにO [RFC5213]で指定されたのと同じように、Proxy Binding Updateメッセージは、ちょうど最初の要求のように構成されなければなりません。
Receiving Proxy Binding Acknowledgement:
プロキシ・バインディング確認応答を受信：
o If the received Proxy Binding Acknowledgement message is protected with IPsec ESP, IPsec processing happens before the packet is passed to Proxy Mobile IPv6. Considerations from Section 4 of [RFC5213] MUST be applied to authenticate and authorize the message.
受信されたProxy Binding Acknowledgementメッセージは、IPsecのESPで保護されている場合、パケットがプロキシモバイルIPv6に渡される前にO、IPsec処理が起こります。 [RFC5213]のセクション4からの考察は、メッセージを認証および承認に適用されなければなりません。
o All the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied on the encapsulated Proxy Binding Acknowledgement message. Note that the Checksum field in Mobility Header MUST be ignored.
O [RFC5213]のセクション6.9.1.2からのすべての考慮事項は、カプセル化されたProxy Binding Acknowledgementメッセージに適用されなければなりません。モビリティヘッダのチェックサムフィールドは無視しなければなりませんので注意してください。
o If the Status field indicates Success, the mobile access gateway MUST set up a bidirectional tunnel to the local mobility anchor.
Statusフィールドには成功を示している場合は、O、モバイルアクセスゲートウェイは、ローカル・モビリティ・アンカーへの双方向トンネルを設定する必要があります。
o Upon accepting the request, the mobile access gateway MUST set up an IPv4 bidirectional tunnel to the local mobility anchor. The tunnel endpoint addresses are the IPv4-Proxy-CoA and the IPv4- LMAA. The encapsulation mode MUST be determined from the below considerations:
O要求を受け付けると、モバイル・アクセス・ゲートウェイは、ローカル・モビリティ・アンカーへのIPv4双方向トンネルを設定する必要があります。トンネルエンドポイントアドレスは、IPv4プロキシ-CoAおよびIPv4- LMAAあります。カプセル化モードは、以下の考察から決定されなければなりません。
* If the (T) flag is set to (1), or the GRE Key option is included, see [GREKEY].
*（T）フラグ（1）に設定されている、またはGREキーオプションが含まれている場合、[GREKEY]参照。
* If there is a NAT Detection option [RFC5555] in the received Proxy Binding Acknowledgement message, and the (F) flag is set to value of (1), the encapsulation mode for the tunnel MUST be set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set to IPv4.
そこNAT検出オプション[RFC5555]は受信されたProxy Binding Acknowledgementメッセージであり、（F）フラグが（1）の値に設定されている場合*、トンネルのカプセル化モードは、IPv4 UDPに設定しなければなりません。それ以外の場合は、カプセル化モードは、IPv4に設定しなければなりません。
o The IPv6 Header is removed, and the Mobility Header containing the Proxy Binding Update message is encapsulated in UDP (with the destination port set to 5436). The Mobility Header Checksum field MUST be set to zero (and UDP checksum MUST be used instead).
OのIPv6ヘッダを除去し、Proxy Binding Updateメッセージを含むモビリティヘッダ（5436に設定された宛先ポートに）UDPにカプセル化されます。モビリティヘッダチェックサムフィールドがゼロに設定されなければならない（そしてUDPチェックサムが代わりに使用されなければなりません）。
o The source address in the IPv4 header MUST be set to IPv4-Proxy-CoA of the mobile access gateway and the destination address MUST be set to the local mobility anchor's IPv4-LMAA.
O IPv4ヘッダーのソースアドレスは、モバイル・アクセス・ゲートウェイのIPv4にプロキシのCoAに設定しなければならなくて、宛先アドレスがローカル・モビリティ・アンカーのIPv4-LMAAに設定しなければなりません。
o If the configuration variable ForceIPv4UDPEncapsulationSupport is set to value of (1), then the (F) flag in the Proxy Binding Update message MUST be set to value of (1).
コンフィギュレーション変数ForceIPv4UDPEncapsulationSupportはProxy Binding Updateメッセージ（1）、次いで、（F）フラグの値に設定されている場合はO（1）の値に設定しなければなりません。
o If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3.
IPsecのESPは、シグナリングを保護するために使用されている場合は、セクション4.3で説明したように、O、パケットはESPトランスポートモードを使用して処理されます。
o Figure 13 shows the format of the Proxy Binding Update message sent over IPv4 and protected using ESP.
O図13は、IPv4を介して送信されたProxy Binding Updateメッセージのフォーマットを示し、ESPを使用して保護しました。
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) ESP header (in transport mode) UDP header (sport=5436, dport=5436) Mobility Header (PBU)
IPv4ヘッダ（SRC = IPv4にプロキシCoAを、DST = IPv4にLMAA）（トランスポートモード）ESPヘッダ、UDPヘッダ（スポーツ= 5436、DPORT = 5436）モビリティヘッダ（PBU）
Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4
図13：のIPv4を介して送信されたProxy Binding Update（PBU）メッセージ
Forwarding Packets Sent by the Mobile Node:
モバイルノードによって送信されたパケットを転送します：
o On receiving an IPv4 or an IPv6 packet from the mobile node to any destination, the mobile access gateway MUST tunnel the packet to the local mobility anchor. The format of the tunneled packet is shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes are described in [GREKEY]. However, considerations from Section 6.10.3 of [RFC5213] MUST be applied with respect the local routing and on the use of EnableMAGLocalRouting flag.
任意の宛先への移動ノードからIPv4またはIPv6パケットを受信すると、O、モバイル・アクセス・ゲートウェイMUSTトンネルローカル・モビリティ・アンカーにパケット。トンネリングされたパケットのフォーマットは以下の通りです。 IPv4の-UDP-TLVとIPv4 GREカプセル化モードは[GREKEY]に記載されています。しかしながら、[RFC5213]のセクション6.10.3からの考察は尊敬ローカルルーティングとのEnableMAGLocalRoutingフラグの使用にして適用されなければなりません。
IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src=MN-HOA, dst=CN)
OR
IPv4 header (src=IPv4-MN-HOA, dst=CN)
Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP
Encapsulation Mode)
Forwarding Packets Received from the Bidirectional Tunnel:
双方向トンネルから受信したパケットを転送します：
o On receiving a packet from the bidirectional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST remove the outer header before forwarding the packet to the mobile node.
Oモバイルノードのローカル・モビリティ・アンカーとの間で確立双方向トンネルからパケットを受信すると、モバイル・アクセス・ゲートウェイは、移動ノードにパケットを転送する前に外部ヘッダを削除する必要があります。
The following section describes how IPsec is used to protect the signaling messages and data packets between the local mobility anchor and mobile access gateway when using IPv4 transport.
次のセクションでは、IPsecは、IPv4トランスポートを使用するときにローカル・モビリティ・アンカーとモバイルアクセスゲートウェイ間のシグナリングメッセージ及びデータパケットを保護するために使用される方法について説明します。
The following are the Security Policy Database (SPD) example entries to protect PBU and PBA on the local mobility anchor and mobile access gateway.
以下は、地元の移動性アンカーとモバイルアクセスゲートウェイにPBU及びPBAを保護するためのセキュリティポリシーデータベース（SPD）の例エントリです。
MAG SPD-S:
- IF local_address = IPv4-Proxy-CoA_1 &
remote_address = IPv4-LMAA_1 & proto = UDP &
remote_port = 5436
Then use SA ESP transport mode
LMA SPD-S: - IF local_address = IPv4-LMAA_1 & remote_address = IPv4-Proxy-CoA_1 & proto = UDP & local_port = 5436 Then use SA ESP transport mode
LMA SPD-S： - IF local_address =のIPv4-LMAA_1＆REMOTE_ADDRESS =のIPv4-プロキシCoA_1＆プロト= UDP＆LOCAL_PORT = 5436次に使うSA ESPトランスポートモード
The following are the SPD example entries to protect payload packets on the local mobility anchor and mobile access gateway. Note that the example SPDs protect all payload packets sent to and from mobile nodes. If an operator needs to apply a different security mechanism per mobile node, they need to create a SPD and a SA entry per mobile node.
以下は、地元の移動性アンカーとモバイルアクセスゲートウェイ上のペイロードパケットを保護するために、SPDの例エントリです。例示のSPDは、モバイルノードにから送信されたすべてのペイロード・パケットを保護することに留意されたいです。オペレータは、モバイルノードごとに異なるセキュリティ・メカニズムを適用する必要がある場合、彼らはSPDとモバイルノードあたりのSAエントリを作成する必要があります。
MAG SPD-S:
- IF interface = tunnel to LMAA_1 &
local_address != Proxy-CoA_1 &
remote_address != LMAA_1 & proto=any
Then use SA ESP tunnel mode
LMA SPD-S: - IF interface = tunnel to Proxy-CoA_1 & local_address != LMAA_1 & remote_address != Proxy-CoA_1 & proto=any Then use SA ESP tunnel mode
LMA SPD-S：！ - プロキシCoA_1＆local_addressへのインタフェースは=トンネルIF = LMAA_1＆REMOTE_ADDRESS =プロキシCoA_1＆プロト=いずれかがその後SA ESPトンネルモードを使用します
When payload packets are protected by IPsec, payload packets matching the SPDs are passed to the IPsec module and encapsulated using the tunnel mode ESP. The tunnel mode ESP encapsulated payload packets are then directly sent to the peer mobile access gateway or local mobility anchor. If IPsec is not applied to payload packets, then they are encapsulated as shown in Figures 12 and 14.
ペイロードパケットがIPSecで保護されている場合、のSPDに一致するペイロード・パケットは、IPsecモジュールに渡され、トンネルモードでESPを使用してカプセル化されます。トンネルモードでESPカプセル化されたペイロードパケットは、直接ピア・モバイルアクセスゲートウェイまたはローカル・モビリティ・アンカーに送信されます。 IPsecはペイロードパケットに適用されていない場合は、図12及び図14に示すように、それらはカプセル化されます。
The local mobility anchor MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts.
ローカル・モビリティ・アンカーは、以下の変数は、システム管理で設定することを許可する必要があります。これらのプロトコル変数の設定された値は、サーバーが再起動し、サービスの再起動後も存続しなければなりません。
AcceptForcedIPv4UDPEncapsulationRequest
AcceptForcedIPv4UDPEncapsulationRequest
This flag indicates whether or not the local mobility anchor should accept IPv4 UDP encapsulation request for the mobile node's data traffic. The default value for this flag is set to (0), indicating that plain IPv4 encapsulation (without UDP) is used for data traffic.
このフラグは、ローカル・モビリティ・アンカーは、モバイルノードのデータトラフィックのIPv4 UDPカプセル化要求を受け入れるべきかどうかを示します。このフラグのデフォルト値は（UDPなしで）普通のIPv4カプセル化は、データトラフィックのために使用されることを示す（0）に設定されています。
The mobile access gateway MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts.
モバイル・アクセス・ゲートウェイは、以下の変数がシステム管理で構成されることを可能にしなければなりません。これらのプロトコル変数の設定された値は、サーバーが再起動し、サービスの再起動後も存続しなければなりません。
ForceIPv4UDPEncapsulationSupport
ForceIPv4UDPEncapsulationSupport
This flag indicates whether or not the mobile access gateway should request the mobile node's local mobility anchor to use IPv4-UDP encapsulation mode for the mobile node's data traffic. The default value for this flag is set to (0), indicating that plain IPv4 encapsulation (without UDP) is used for data traffic.
このフラグは、モバイル・アクセス・ゲートウェイは、移動ノードのデータトラフィックのIPv4-UDPカプセル化モードを使用するために、モバイルノードのローカル・モビリティ・アンカーを要求すべきか否かを示しています。このフラグのデフォルト値は（UDPなしで）普通のIPv4カプセル化は、データトラフィックのために使用されることを示す（0）に設定されています。
This document defines four new Mobility Header options: the IPv4 Home Address Request option, IPv4 Home Address Reply option, IPv4 Default Router Address option, and IPv4 DHCP Support Mode option. These options are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4, respectively. The Type value for these options has been assigned from the same number space as allocated for the other mobility options, as defined in [RFC3775].
IPv4のホームアドレス要求オプション、IPv4のホームアドレスに返信オプション、IPv4のデフォルトルータアドレスオプション、およびIPv4のDHCPサポートモードオプション：この文書は、4つの新しいモビリティヘッダオプションを定義します。これらのオプションは、セクションそれぞれ3.3.1、3.3.2、3.3.3および3.3.4に記載されています。他のモビリティオプションのために割り当てられ、これらのオプションのタイプ値は[RFC3775]で定義されるように、同じ数の空間から割り当てられています。
The IPv4 Home Address Reply option, described in Section 3.3.2 of this document, introduces a new number space, IPv4 Home Address Reply status codes. This document currently reserves the following values. Approval of any new status code values are to be made through IANA Expert Review.
このドキュメントのセクション3.3.2で説明したIPv4ホームアドレスに返信オプションは、新しい番号空間、IPv4のホームアドレスに返信ステータスコードを紹介します。このドキュメントでは、現在、以下の値を保有します。任意の新しいステータスコード値の承認は、IANAエキスパートレビューを通じて行われるべきです。
o 0 Success
O 0成功
o 128 Failure, Reason Unspecified
O 128失敗、未指定の理由
o 129 Administratively prohibited
O 129は、管理上禁止します
o 130 Incorrect IPv4 home address
130の誤ったのIPv4ホーム・アドレスO
o 131 Invalid IPv4 address
131 O無効なIPv4アドレス
o 132 Dynamic IPv4 home address assignment not available
132ダイナミックIPv4のホームアドレスの割り当ては利用できませんO
The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this document, introduces a new number space, IPv4 DHCP Support Mode Flags. This document reserves the value 0x1 for the (S) flag. Approval of flag values are to be made through IANA Expert Review. At this point in time, there are no thoughts on what the new flag allocations can be, and hence this document leaves this to the discretion of the Expert Review.
このドキュメントのセクション3.3.4で説明したIPv4 DHCPサポートモードオプションは、新しい番号空間、IPv4のDHCPサポートモードフラグを紹介します。この文書は、（S）フラグの値は0x1を予約します。フラグ値の承認は、IANAエキスパートレビューを通じて行われるべきです。この時点で、新しいフラグの割り当てをすることができるものには何の考えがない、ので、この文書は、専門家レビューの裁量にこれを残します。
This document also defines new Status values, used in Proxy Binding Acknowledgement message, as described in Section 3.3.5. These values have been assigned from the same number space as allocated for other status codes [RFC3775]. Each of these allocated values is greater than 128.
セクション3.3.5に記載したように、この文書はまた、プロキシバインディング肯定応答メッセージで使用される新しいステータス値を、定義します。他のステータスコード[RFC3775]のために割り当てられたこれらの値は、同一の番号空間から割り当てられています。これらの割り当てられた値のそれぞれは、128よりも大きいです。
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE：170
Mobile node not authorized for IPv4 mobility service.
モバイルノードは、IPv4モビリティサービスのために許可されていません。
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS：171
Mobile node not authorized for the requesting IPv4 home address.
モバイルノードは、要求のIPv4ホームアドレスで認証されていません。
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE：172
Mobile node not authorized for IPv6 mobility service.
モバイルノードは、IPv6モビリティサービスのために許可されていません。
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED：173
Multiple IPv4 home address assignment not supported.
複数のIPv4ホームアドレスの割り当てがサポートされていません。
IANA has assigned two UDP port numbers, 5436 and 5437, for "pmip6- cntl" and "pmip6-data", respectively.
IANAは、それぞれ、「pmip6- CNTL」と「PMIP6データ」のための2つのUDPポート番号、5436と5437を、割り当てられています。
All the security considerations from the base Proxy Mobile IPv6 [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6 [RFC5555] specifications apply when using the extensions defined in this document. Additionally, the following security considerations need to be applied.
この文書で定義された拡張機能を使用すると、すべてのベースプロキシモバイルIPv6 [RFC5213]からのセキュリティ上の考慮事項、モバイルIPv6 [RFC3775]、およびデュアルスタックモバイルIPv6 [RFC5555]の仕様が適用されます。また、次のセキュリティの考慮事項が適用される必要があります。
This document defines new mobility options for supporting the IPv4 Home Address assignment and IPv4 Transport Support features. These options are to be carried in Proxy Binding Update and Proxy Binding Acknowledgement messages. The required security mechanisms specified in the base Proxy Mobile IPv6 protocol for protecting these signaling messages are sufficient when carrying these mobility options.
この文書では、IPv4ホームアドレスの割り当てとIPv4トランスポートのサポート機能をサポートするための新しいモビリティオプションを定義します。これらのオプションは、プロキシバインディングアップデートで運ばれるべきであり、プロキシは、確認応答メッセージを結合します。これらモビリティオプションを搬送するときに、これらのシグナリングメッセージを保護するためのベースプロキシモバイルIPv6プロトコルで指定された必要なセキュリティメカニズムは十分です。
This specification describes the use of IPv4 transport for exchanging signaling messages between the local mobility anchor and the mobile access gateway. These can be protected using IPsec as described in Section 4.3.
この仕様は、ローカル・モビリティ・アンカーとモバイルアクセスゲートウェイ間のシグナリングメッセージを交換するためのIPv4トランスポートの使用を記載しています。 4.3節で説明したように、これらは、IPsecを使用して保護することができます。
This document reflects discussions and contributions from several people (in alphabetical order):
この文書では、いくつかの人々（アルファベット順）からの議論と貢献を反映しています：
Kuntal Chowdhury
Kuntalチョードリー
kchowdhury@starentnetworks.com
ｋちょｗでゅｒｙ＠ｓたれんｔねとぉｒｋｓ。こｍ
Vijay Devarapalli
ビジェイdevarapalli
vijay.devarapalli@azairenet.com
ゔぃじゃｙ。でゔぁらぱっぃ＠あざいれねｔ。こｍ
Pasi Eronen
パシEronen
Pasi.Eronen@nokia.com
ぱし。えろねん＠のきあ。こｍ
Sangjin Jeong
歌ったキム・Jああその
sjjeong@etri.re.kr
ｓっじぇおんｇ＠えｔり。れ。ｋｒ
Basavaraj Patil
Bsvrajパティル
basavaraj.patil@nokia.com
ばさゔぁらｊ。ぱちｌ＠のきあ。こｍ
Myungki Shin
みゅんｇき しん
myungki.shin@gmail.com
みゅんｇき。しん＠ｇまいｌ。こｍ
The IPv4 support for Proxy Mobile IPv6 was initially covered in "Proxy Mobile IPv6" (March 2007). We would like to thank all the authors of the document and acknowledge that initial work.
プロキシモバイルIPv6のIPv4サポートは、最初は「プロキシモバイルIPv6」（2007年3月）で覆われていました。私たちは、ドキュメントのすべての著者に感謝し、その最初の仕事を認めたいと思います。
Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu, and Zu Qiang for their helpful review of this document.
アルパースYegin、ベーチェットSarikaya、バーナードAboba、チャールズ・パーキンス、Damicダムヤン、ヤリArkko、ジョエルHortelius、Jonne Soinnen、ジュリアンLaganier、Mohana Jeyatharan、ニクラスNuemann、パシEronen、Premec Domagoj、ラルフDroms、サミーTouati、Vidyaナラヤナンのおかげで、このドキュメントの彼らの役に立つレビューのためYingzhe呉、および祖強。
Also, we would like to thank Spencer Dawkins, Tim Polk, Menachem Dodge, Adrian Farrel, and Pekka Savola for their reviews of this document as part of the IESG review process. Finally, special thanks to Jouni Korohonen for his support in addressing the IPsec issues.
また、我々はIESGレビュープロセスの一環として、このドキュメントの彼らのレビューのためにスペンサードーキンスティムポーク、メナヘムダッジ、エードリアンファレル、およびペッカSavolaに感謝したいと思います。最後に、IPsecの問題に対処する上で彼のサポートのためのJouni Korohonenに感謝します。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、2001年1月。
[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月。
[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月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361]レモン、T.とB.ゾンマーフェルト、RFC 4361、2006年2月「動的ホスト構成プロトコルバージョン四つ（のDHCPv4）のためのノード固有のクライアント識別子」。
[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
[RFC5107]ジョンソン、R.、Kumarasamy、J.、キニア、K.、およびM.スタップ、 "DHCPサーバ識別子overrideサブオプション"、RFC 5107、2008年2月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマン、H.、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。
[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC0925]ポステル、J.、 "マルチLANアドレス解決"、RFC 925、1984年10月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、カールソン、J.、およびS.チェシャー、 "IPv4の（DNAv4）で検出ネットワーク接続"、RFC 4436、2006年3月。
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual Stack Mobility", RFC 4977, August 2007.
[RFC4977] Tsirtsis、G.およびH.ソリマン、 "問題文：デュアルスタックモビリティ"、RFC 4977、2007年8月。
[GREKEY] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "GRE Key Option for Proxy Mobile IPv6", Work in Progress, May 2009.
[GREKEY] Muhanna、A.、カリル、M.、Gundavelli、S.、およびK.レオン、 "プロキシモバイルIPv6のためのGREキーオプション"、進歩、2009年5月での作業。
Authors' Addresses
著者のアドレス
Ryuji Wakikawa TOYOTA InfoTechnology Center, U.S.A., Inc. 465 Bernardo Avenue Mountain View, CA 94043 USA
りゅじ わきかわ とよた いんふぉてｃｈのぉｇｙ せんてｒ、 う。Ｓ。あ。、 いんｃ。 ４６５ べｒなｒど あゔぇぬえ もうんたいん ゔぃえｗ、 か ９４０４３ うさ
EMail: ryuji@us.toyota-itc.com
メールアドレス：ryuji@us.toyota-itc.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
スリGundavelliシスコ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: sgundave@cisco.com
メールアドレス：sgundave@cisco.com