[要約] RFC 5844は、Proxy Mobile IPv6にIPv4サポートを追加するための仕様です。その目的は、IPv6ネットワーク上でのモバイルノードのIPv4通信をサポートすることです。
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
プロキシモバイルIPv6のIPv4サポート
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プロトコルサポートの範囲は2つあります。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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ドメインのモバイルノードは、IPv4-のみ、IPv6のみ、またはデュアルスタックモードで動作し、モバイルアクセスゲートウェイとローカルモビリティアンカーの間のネットワークで動作する可能性があると想定するのが妥当です。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]は、プロキシモバイル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アドレスを取得し、そのプロキシモバイル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トランスポートネットワークとIPv4対応のモバイルノードを備えた典型的なプロキシモバイルIPv6ドメインを示しています。この図で使用されている用語は、用語セクションで説明されています。
+----+ +----+
|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.
o IPv4ホームアドレスのモバイルノードへのモビリティサポートを有効にするには、IPv6ホームアドレスモビリティサポートを有効にする必要はありません。ただし、IPv4やIPv6パケット転送などのそれぞれのプロトコルサポートは、モバイルノードとモバイルアクセスゲートウェイの間のアクセスリンクで有効にする必要があります。
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）[RFC1332]などの標準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ホームサブネットは、通常、共有アドレススペースです。1つのモバイルノードを排他的に使用するためではありません。同じサブネットから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]で指定されています。このドキュメントは、ネットワークベースのモビリティモデルをサポートする明らかな理由でいくつかの側面の偏差を除いて、IPv4サポートをプロキシモバイルIPv6に拡張するためにそのドキュメントで定義されているアプローチ、メッセージングオプション、および処理ロジックの一部を活用しています。以下は、関連する考慮事項の一部です。
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 [RFC5555]のセクション3.1.3および3.2.2で定義されているバインディングアップデートメッセージフラグ「F」とNAT検出オプションは、この仕様でプロキシバインディングアップデートおよびプロキシバインド確認メッセージで使用されます。彼らの唯一の目的は、[RFC5555]のセクション4.1および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セキュリティアソシエーション（SAS）は単一のモバイルノードに固有です。彼らは、トラフィックセレクターとして上層層プロトコル（HOA/IPv4-HOA）に見える識別子を使用します。また、モバイルノードが移動するときにIKE/IPSEC SASを更新する必要があります。
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 SASはモバイルアクセスゲートウェイに固有です（および潜在的に多数のモバイルノードに使用されます）。彼らは、ルーティングに使用されるロケーター（Proxy-Coa/IPv4-Proxy-Coa）をトラフィックセレクターとして使用します。また、モバイルノードが移動するときに更新されません。
This means the IPsec processing for Mobile IPv6 and Proxy Mobile IPv6 (whether IPv6-only or dual-stack) is very different.
これは、モバイルIPv6およびプロキシモバイルIPv6のIPSEC処理（IPv6のみまたはデュアルスタック）が非常に異なることを意味します。
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-Proxy-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.
1つのアドレスファミリに属するすべてのアドレスの部分的な登録の手順、つまりIPv4ホームアドレスまたは割り当てられたIPv6ホームネットワークのプレフィックスの1つ以上の登録解除。
Encapsulation Modes
カプセル化モード
This document uses the following terms when referring to the different encapsulation modes.
このドキュメントは、異なるカプセル化モードを参照するときに次の用語を使用します。
IPv4-or-IPv6-over-IPv6
IPv4-Or-IPv6-over-IPv6
IPv4 or IPv6 packet carried as a payload of an IPv6 packet
IPv6パケットのIPv4パケットまたはIPv6パケットとして携帯するパケット
IPv4-or-IPv6-over-IPv4
IPv4-Or-IPv6-over-IPv4
IPv4 or IPv6 packet carried as a payload of an IPv4 packet
IPv4パケットまたはIPv4パケットのペイロードとして運ばれるIPv6パケット
IPv4-or-IPv6-over-IPv4-UDP
IPv4-Or-IPV6-Over-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-Or-IPV6-Over-IPV4-UUDP-TLV
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with UDP and TLV headers
UDPおよびTLVヘッダーを備えたIPv4パケットでペイロードとして運ばれるIPv4またはIPv6パケット
IPv4-or-IPv6-over-IPv4-GRE
IPv4-Or-IPv6-over-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)
IPv4またはIPv6パケットは、一般的なルーティングカプセル化（GRE）ヘッダー（ただし、UDPまたはTLVヘッダーはありません）を備えたIPv4パケットのペイロードとして運ばれました。
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ホームアドレスモビリティサポートは、基本的にプロキシモバイルIPv6ドメイン内のモバイルノードを有効にして、添付のインターフェイスのIPv4ホームアドレス構成を取得し、プロキシモバイル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ホームアドレスモビリティサポートに依存していません。IPv4ホームアドレスのモビリティサポートを有効にする必要がある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ホームアドレスを取得します。このようなシナリオでは、ローカルモビリティアンカーにモバイルノードの複数のバインディングキャッシュエントリがあります。特定のインターフェイスに割り当てられたすべてのアドレス（IPv4/IPv6）は、[RFC5213]のセクション5.4で指定されているように、1つのモビリティセッションの一部として管理されます。
To support this feature, the conceptual Binding Cache entry data structure maintained by the local mobility anchor needs to include the following parameters.
この機能をサポートするには、ローカルモビリティアンカーによって維持される概念バインディングキャッシュ入力データ構造には、次のパラメーターを含める必要があります。
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.
o モバイルノードのインターフェイスに割り当てられ、モバイルアクセスゲートウェイによって登録されたIPv4ホームアドレス。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で指定された処理ルールは、受信したプロキシバインディングアップデートメッセージの処理に適用されます。ただし、受信したプロキシバインディングアップデートメッセージに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].
o 受信したプロキシバインディングアップデートメッセージに存在するIPv4ホームアドレスリクエストオプション（セクション3.3.1）がありますが、受信したプロキシバインディングアップデートメッセージに存在するホームネットワークプレフィックスオプション[RFC5213]が存在しない場合、ローカルモビリティアンカーは拒否してはなりません[RFC5213]のセクション5.3.1で指定された要求。IPv4ホームアドレス要求オプションまたはホームネットワークプレフィックスオプションのいずれかのこれら2つのオプションのいずれかの少なくとも1つのインスタンスが存在する必要があります。リクエストに存在するこれらの2つのオプションのいずれかのいずれかの単一のインスタンスがない場合、ローカルモビリティアンカーはリクエストを拒否し、[Missing_home_network_prefix_optionに設定されたステータス]フィールドを使用してプロキシバインディング承認メッセージを送信する必要があります（モバイルノードのホームネットワークプレフィックスオプションがありません）[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 受信したプロキシバインディングアップデートメッセージに存在するホームネットワークプレフィックスオプション[RFC5213]の少なくとも1つのインスタンスがあるが、モバイルノードのポリシープロファイルからは、IPv6サービスまたはIPv6ルーティングを承認していないことがわかっています。ホームネットワークでは有効にされていないため、ローカルモビリティアンカーはリクエストを拒否し、[not_authorized_for_ipv6_mobility_serviceに設定されたステータスフィールドを使用してプロキシバインディング確認メッセージを送信する必要があります。
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).
o 受信したプロキシバインディングアップデートメッセージに存在するIPv4ホームアドレスリクエストオプションがあるが、モバイルノードのポリシープロファイルから、モバイルノードがIPv4サービスで許可されていない、または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 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).
o リクエストに存在するIPv4ホームアドレスリクエストオプションに複数のインスタンスがある場合、ローカルモビリティアンカーはリクエストを拒否し、マルチ_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 受信したプロキシバインディングアップデートメッセージを既存のモビリティセッションに関連付けるには、ローカルモビリティアンカーは、以下の考慮事項を適用して、バインディングキャッシュ入力の存在テストを実行する必要があります。
* 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.
* Home Network Prefix Option [RFC5213]の少なくとも1つのインスタンスがnon_zeroプレフィックス値を持つ場合、またはOptionに設定されたIPv4アドレスのIPv4アドレスがALL_ZEROに設定されたIPv4ホームアドレスリクエストオプションがある場合、セクション5.4.1からの考慮事項[RFC5213]を適用する必要があります。
* 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.
* IPv4ホームアドレスリクエストオプションが存在する場合は、non_zero値に設定されているオプションに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.
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.
o IPv4ホームアドレスリクエストオプションがALL_ZEROに設定されたオプションのIPv4アドレス値を持つプロキシバインディングアップデートメッセージに存在する場合、ローカルモビリティアンカーは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).
o Option non_Zero値に設定されたOptionのIPv4アドレスを使用したIPv4ホームアドレスリクエストオプションがある場合、ローカルモビリティアンカーは、リクエストを受け入れる前に、アドレスがローカルモビリティアンカーにトポロジカルに固定されていることを確認する必要があり、さらにモバイルがモバイルであることを確認する必要があります。ノードは、そのアドレスを使用する権限があります。）。また、IPv4ホームアドレス返信オプション（セクション3.3.2）も含める必要があります。129に設定されたオプションのステータスフィールド値を使用した返信で（管理上禁止）。
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).
o ローカルモビリティアンカーがリソース不足のためにIPv4アドレスを割り当てることができない場合、リクエストを拒否し、ステータスフィールドを130に設定してプロキシバインディング確認メッセージを送信する必要があります（リソースが不十分です）。また、128に設定されたオプションのステータスフィールド値を使用して、返信に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 リクエストを受け入れると、ローカルモビリティアンカーは、このモビリティセッションのバインディングキャッシュエントリを作成する必要があります。ただし、リクエストに1つ以上のホームネットワークプレフィックスオプション[RFC5213]も含まれている場合、このモビリティセッションに作成する必要があるバインディングキャッシュエントリは1つだけである必要があります。作成されたバインディングキャッシュエントリは、IPv4とIPv6ホームアドレスバインディングの両方を管理するために使用する必要があります。バインディングキャッシュエントリのフィールドは、そのセッションの受け入れられた値で更新する必要があります。
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-Or-IPV6-Over-IPV6（IPv4またはIPv6パケットのペイロードとして運ばれた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に設定してプロキシバインディング確認メッセージを送信する必要があります（プロキシバインディングアップデートが受け入れられます）。メッセージは、セクション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ホームネットワークプレフィックスの両方がある場合。
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.
o [RFC5213]のセクション5.3.6で特定された必要な転送状態は、IPv6ペイロードトラフィック用です。これらの考慮事項は、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ホームネットワークプレフィックス）の場合、バインディングキャッシュエントリを削除する必要はありません。これらのアドレスに関連するそれぞれの状態のみを削除する必要があります。
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.
o [RFC5213]のセクション5.3.6では、ローカルモビリティアンカーが、モバイルアクセスゲートウェイに送信するプロキシバインド確認メッセージにホームネットワークプレフィックスオプション[RFC5213]の少なくとも1つのインスタンスを含める必要があります。ただし、受信したプロキシバインディングアップデートメッセージには、IPv4ホームアドレスリクエストオプションのみがあり、ホームネットワークプレフィックスオプションが含まれていない場合、ローカルモビリティアンカーには、返信にホームネットワークのプレフィックスオプションを含めてはなりません。ただし、ホームネットワークプレフィックスオプション[RFC5213]またはプロキシバインディング確認メッセージに存在するIPv4ホームアドレス返信オプションのいずれかのインスタンスが少なくとも1つある必要があります。
o The IPv4 Home Address Reply option MUST be present in the Proxy Binding Acknowledgement message.
o IPv4ホームアドレス返信オプションは、プロキシバインディング確認メッセージに存在する必要があります。
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ホームアドレス返信オプションが必要です。IPv4アドレス値と、リクエストの対応する値に設定されたオプションのプレフィックス長さフィールド。オプションのステータスフィールド値は、特定のエラーコードに設定する必要があります。
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ホームネットワークのプレフィックス長に設定する必要があります。オプションのステータスフィールド値は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.
o プロキシバインディング承認メッセージのステータスフィールド値が0に設定されている場合、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で指定されているバインディングキャッシュ入力の検討の考慮事項は、ホームネットワークプレフィックスオプション[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.
o [RFC5213]のセクション5.4.1.1で指定されている検索ルールは、主に検索キーとしてIPv6ホームネットワークセットを使用しているため、単一のIPv4ホームアドレスをキーとして使用する場合に等しく有効です。これらの考慮事項を適用する場合、IPv6ホームネットワークプレフィックスの代わりに、リクエストに存在する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：ローカルモビリティアンカー（LMA）からモバイルアクセスゲートウェイ（MAG）までのトンネルパケット
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.
o モバイルノードのIPv4デフォルトルーターアドレス。これは、受信したプロキシバインディング確認メッセージを介して、モバイルノードのローカルモビリティアンカーから取得されます。
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ホームアドレスリクエストオプションは、プロキシバインディングアップデートメッセージに存在する必要があります。
* 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ホームアドレスリクエストオプションの正確な1つのインスタンスを含む1つのインスタンスを含むことにより、ローカルモビリティアンカーにその特定のアドレスを割り当てるように依頼する場合があります。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ホームアドレスを備えたIPv4ホームアドレスオプションの1つのインスタンスと、All_Zero値に設定されたオプションのプレフィックス長さフィールドを含めることができます。さらに、オプションの（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.
o プロキシバインディングアップデートメッセージは、[RFC5213]のセクション6.9.1.5で指定されているように構築する必要があります。ただし、IPv6ホームアドレスモビリティサポートもモバイルノードで有効にする必要がある場合にのみ、プロキシバインディングアップデートにホームネットワークプレフィックスオプション[RFC5213]が存在する必要があります。それ以外の場合、ホームネットワークのプレフィックスオプションが存在してはなりません。
o When using IPv4 transport to carry the signaling messages, the related considerations from Section 4 MUST be applied additionally.
o IPv4トランスポートを使用して信号メッセージを伝達する場合、セクション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.
o 受信したプロキシバインディング承認メッセージのステータスフィールド値がNOT_AUTHORIZED_POR_IPV4_MOBILITY_SERVICEに設定されている場合（モバイルノードはIPv4モビリティサービスでは許可されていません）、モバイルアクセスゲートウェイは、IPV4ホームアドレスリクエストオプションを含むプロキシバインドアップデートメッセージを管理するまで送信してはなりません。アクションが実行されます。
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 受信したプロキシバインディング承認メッセージのステータスフィールド値がnot_authorized_for_ipv4_home_addressに設定されている場合（モバイルノードは要求のIPv4ホームアドレスに対して許可されていません）、モバイルアクセスゲートウェイは同じIPv4アドレスを再度要求する必要はありませんが、ローカルモビリティアンカーを要求する場合があります。IPv4ホームアドレスリクエストオプションの正確に1つのインスタンスをIPv4ホームアドレスとオプションのプレフィックス長さフィールドをALL_ZERO値に含めることにより、アドレス割り当てを実行します。
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.
o 受信したプロキシバインディング承認メッセージのステータスフィールド値がnot_authorized_por_ipv6_mobility_serviceに設定されている場合（モバイルノードはIPv6モビリティサービスでは許可されていません）、モバイルアクセスゲートウェイはホームネットワークのプレフィックスオプションを含むプロキシバインドアップデートメッセージを送信してはなりません。管理措置が取られます。
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.
o 受信したプロキシバインディング確認メッセージに存在するIPv4ホームアドレス返信オプションがない場合、モバイルアクセスゲートウェイはモバイルノードの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.
o 受信したプロキシバインディングの確認メッセージにIPv4ホームアドレスのステータスフィールド値がある場合、リクエストがローカルモビリティアンカーによって拒否されたことを示す値に設定されている場合、モバイルアクセスゲートウェイは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.
o 受信したプロキシバインド確認メッセージのステータスフィールド値が0に設定されている場合（プロキシバインディングアップデートが受け入れられます）、モバイルアクセスゲートウェイは、そのモバイルノードのバインディングアップデートリストエントリを更新する必要があります。エントリは、割り当てられた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 受信したプロキシバインディング承認メッセージのステータスフィールド値が0に設定されている場合（プロキシバインディングアップデートが受け入れられます）、IPv4ホームアドレス返信オプションがローカルモビリティアンカー、モバイルアクセスゲートウェイによって受け入れられたことを示す値に設定した場合ローカルモビリティアンカーへの双方向トンネルを確立する必要があります（そのローカルモビリティアンカーへの既存の双方向トンネルがない場合）。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 デフォルトのルーターアドレスは、受信したプロキシバインディング確認メッセージに存在する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.
o 受信したプロキシバインディング確認メッセージに存在するIPv4 DHCPサポートモードオプション（セクション3.3.4）があり、オプションの（s）フラグが（1）の値に設定されている場合、モバイルアクセスゲートウェイは機能する必要がありますモバイルノードの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.
o モビリティセッションに割り当てられたIPv4ホームアドレスがある場合、プロキシバインディングアップデートメッセージに存在するIPv4ホームアドレスリクエストオプションのインスタンスが正確に1つある必要があります。オプションの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ホームアドレスは、all_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ホームアドレスリクエストオプションの1つのインスタンスと、登録されている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.
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.
o モバイルアクセスゲートウェイが、モバイルノードのIPv4アドレスのローカルモビリティアンカーでバインディングライフタイムを延長できない場合、モバイルノードの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 [RFC0925]を使用して、モバイルノードのホームサブネットの宛先のアドレス解像度を求めるモバイルノードから受信するARPリクエストに返信する必要があります。ARPリクエストを受信するとき、モバイルアクセスゲートウェイはリクエストのターゲットIPアドレスを調べる必要があり、このIPアドレスがモバイルノードのIPv4ホームサブネットと一致する場合、プロキシARP応答を送信する必要があります。ただし、特定の種類のリンクでは、モバイルノードはアドレス解像度にARPを使用せず、代わりにすべてのパケットをモバイルアクセスゲートウェイに転送します。このようなタイプのリンクでは、プロキシ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ホームアドレスリクエストオプションは、モバイルアクセスゲートウェイからローカルモビリティアンカーに送信されたプロキシバインディングアップデートメッセージで使用するために定義されます。このオプションは、モバイルノードの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
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
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までの値は成功を示します。高い値（128〜255）は故障を示します。現在、次のステータス値はこのドキュメントによって割り当てられています。
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デフォルトルーターアドレスオプションは、ローカルモビリティアンカーによってMobile Access Gatewayに送信されたプロキシバインディング確認メッセージで使用するために定義されます。このオプションは、モバイルノードの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
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サポートモードオプションは、ローカルモビリティアンカーによってMobile Access Gatewayに送信されたプロキシバインディング確認メッセージで使用するために定義されます。このオプションは、添付のモバイルノードの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
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サポートモード
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].
このドキュメントでは、プロキシバインディング確認メッセージで使用するための次の新しいステータス値を定義します。これらの値は、[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
Multhip_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.
このセクションでは、プロキシモバイルIPv6ドメインのモバイルノードでDHCPベースのアドレス構成サポートを有効にする方法について説明します。プロトコル操作、サポートされた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.
o DHCPサーバーは、[RFC2131]で指定されている場合、存在する場合、またはクライアントハードウェアアドレス（Chaddr）の場合、DHCP「クライアントIDENTIFIER」オプション[RFC2132]のコンテンツからDHCPインターフェイスを識別します。「Client-Identifier」という名前は、クライアントではなくインターフェイスを実際に識別するため、誤称であることに注意してください。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サーバーはそれらの各インターフェイスを一意に識別し、アドレス割り当てを実行します。DHCPサーバーは、RFC 2131で指定されているインターフェイスを識別します。モバイルノードは、[RFC4361]に従って、各物理インターフェイスの「クライアントIDENDIER」を生成および使用する必要があります。モバイルノードが異なるモバイルアクセスゲートウェイへの物理インターフェイスのハンドオフを実行するたびに、同じインターフェイスを使用して、DHCPサーバーは常に提示された識別子を使用してバインディングを識別できます。提示された識別子（「クライアントIdentifier」またはハードウェアアドレスのいずれか）は、バインディングキャッシュエントリでどのようにユニークであるかだけでなく、各バインディングの主要なキーとして残ります。
* 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]に従って、モバイルノードがインターフェイス間でハンドオフを実行できる場合、物理インターフェイスのいずれにも結び付けられていないアタッチメントポイントには、「クライアント識別子」値を使用する必要があります。識別子は[RFC4361]に従って生成する必要があります。これは、識別子がプロキシモバイルIPv6ドメインで使用されているすべての「クライアント識別子」値にわたって安定して一意であることを保証します。
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サーバーなど）で構成できます。そのプロキシモバイル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.
o モバイルアクセスゲートウェイが、ローカルモビリティアンカーでプロキシモバイルIPv6シグナル伝達をすでに完了している可能性があります。IPv6ホームネットワークプレフィックス（ES）とIPv4ホームアドレスの両方のステップ1の両方を要求します。このようなイベントでは、プロキシモバイルで上記の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.
o ローカルモビリティアンカーからモバイルノードのIPv4ホームアドレスを取得するために、モバイルアクセスゲートウェイは、ローカルモビリティアンカーでプロキシモバイル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メッセージには、サブネットマスクオプション[RFC2132]およびルーターオプション[RFC2132]もあり、それらのオプションの値はそれぞれモバイルノードのIPv4ホームサブネットマスクとデフォルトのルーターアドレスに設定されています。さらに、サーバー識別子オプションが含まれ、オプションの値がデフォルトのルーターアドレスに設定されます。
o If the mobile node sends the DHCPREQUEST message, the DHCP server will send DHCPACK message, as per [RFC2131].
o モバイルノードがDHCPRequestメッセージを送信すると、DHCPサーバーは[RFC2131]に従ってDHCPackメッセージを送信します。
IPv4 Home Address Renewal with the DHCP Server (No Handoff):
IPv4ホームアドレスDHCPサーバーによる更新（ハンドオフなし）：
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.
o モバイルノードがDHCP更新状態[RFC2131]に入るときはいつでも、「要求された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サーバーは、DHCPACKをモバイルノードに送信して、コミットされたIPv4アドレスの割り当てを確認します。
IPv4 Home Address Renewal with the DHCP Server (after Handoff):
IPv4ホームアドレスDHCPサーバーによる更新（ハンドオフ後）：
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更新状態[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.
o DHCPサーバー識別子がモバイルノードによって送信されるDHCPRequestメッセージがアドレスを更新することを保証するため、モバイルノードのIPv4デフォルトルーターアドレスまたはそのプロキシモバイルIPv6ドメインで共通する固定IPv4アドレスの安定したアドレスの使用添付のリンクの新しいモバイルアクセスゲートウェイで受信されます。
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 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.
o モバイルアクセスゲートウェイプロキシモバイルIPv6シグナリングを完了した後、モバイルノードのIPv4ホームアドレスを取得した後、DHCPackメッセージのアドレスを返します。ただし、モバイルアクセスゲートウェイがプロキシモバイルIPv6シグナリングを完了できない場合、またはモバイルノードで要求されたのと同じIPv4アドレスを取得できない場合、図に示すようにモバイルノードにDHCPNACKメッセージ[RFC2131]を送信します。8。
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シグナル伝達（ステップ1から開始）およびDHCPアドレス構成（ステップ4から始まる）は、任意の順序で開始できます。ただし、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.
o ローカルモビリティアンカーからモバイルノードのIPv4ホームアドレスを取得するために、モバイルアクセスゲートウェイは、ローカルモビリティアンカーでプロキシモバイル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リレーエージェントは、DHCPリレーエージェント情報オプション[RFC3046]をDHCPDISCOVERメッセージに追加します。割り当てられたIPv4ホームアドレスは、DHCPリレーエージェント情報オプションのエージェントリモートIDサブオプションに含まれます。このサブオプションは、DHCPサーバーにその特定のIPv4アドレスを割り当てるように要求するためのヒントとして使用されます。
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.
o DHCPメッセージが管理境界を介して送信される場合、オペレーターはこれらのメッセージが確実に保護されることを確認する必要があります。モバイルアクセスゲートウェイによって中継されたすべてのDHCPメッセージは、必要に応じてローカルモビリティアンカーにトンネリングできます。または、プロキシモバイルIPv6ドメインのネットワークが十分に安全である場合、モバイルアクセスゲートウェイはDHCPメッセージをサーバーに中継するだけです。これを実現するには、すべてのモバイルアクセスゲートウェイには、DHCPサーバーに向かうルートが必要です。
IPv4 Home Address Renewal to the same DHCP Server: (No Handoff)
IPv4ホームアドレス同じDHCPサーバーへの更新：（ハンドオフなし）
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.
o DHCPクライアントがDHCP更新状態[RFC2131]に入ると、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サーバー識別子オーバーライドサブオプション[RFC5107]を使用して、すべてのDHCPメッセージフローのパスになります。DHCPクライアントは、DHCPリレーアドレスによってオーバーライドされたDHCPサーバーアドレスをDHCPRequestの宛先アドレスとして使用します。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.
o ただし、DHCPサーバーがローカルモビリティアンカーと共同住宅されている場合、DHCPリレーエージェントは、モバイルノードとDHCPサーバー間のユニキャストDHCPメッセージを傍受する必要はありません。これは、ローカルモビリティアンカーがDHCP状態がIPv4アドレスに存在するプロキシモバイルIPv6バインディングと一致することを保証するためです。
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.
o モバイルアクセスゲートウェイがモバイルノードからDHCPサーバーへのDHCPメッセージをインターセプトすると、モバイルノードがそのモバイルノードに割り当てられたローカルモビリティアンカーと同じIPv4アドレスをネゴシエートしているかどうかを確認できます。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アドレスをリリースしたことを検出すると、ローカルモビリティアンカーにプロキシバインディングアップデートを送信し、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.
o モバイルノードがDHCPDISCOVERメッセージ[RFC2131]を送信すると、モバイルアクセスゲートウェイと共同住宅された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.
o モバイルノードは、[RFC5213]のセクション6.6で指定されているように、MN-IDENIDEFIERによって識別する必要があります。この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.
o モバイルアクセスゲートウェイは、プロキシモバイルIPv6シグナリングが完了するまで、すべての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.
o プロキシモバイルIPv6シグナリングを開始するためのトリガーは、以前のモバイルアクセスゲートウェイからのコンテキスト転送の一部としてモバイルアクセスゲートウェイに配信することも、ラジオネットワークの他のネットワーク要素から配信されることもできます。その詳細は範囲外ですこのドキュメントの。
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 モバイルノードが1つのモバイルアクセスゲートウェイから別のモバイルへのゲートウェイへのハンドオフを実行すると、新しいリンクのモバイルアクセスゲートウェイがローカルモビリティアンカーでプロキシモバイルIPv6シグナル伝達を開始します。プロキシモバイルIPv6シグナル伝達を完了すると、モバイルアクセスゲートウェイには、ローカルモビリティアンカーがモバイルノードに割り当てられ、そのリンクのDHCPベースのアドレス構成をサポートするために使用できる適切なIPv4アドレスの状態があります。
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ホームネットワークプレフィックスをリリースしてはなりません。
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アドレスをモバイルのケアのケアとして登録できます。ノードのバインディングキャッシュエントリ。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]は、IPv4を介したプロキシモバイルIPv6シグナル伝達に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.
o モバイルノードは、IPv6、IPv4、またはデュアルIPv4/IPv6ノードであり、このセクションで指定されているIPv4トランスポートサポートは、そのモバイルノードで有効化されたアドレスモビリティのタイプに不可知論されます。
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またはIPv6ペイロードパケットがIPv4パケットで運ばれました）。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-UUDP（Payload Packetは、UDPヘッダーを備えたIPv4パケットに掲載されており、プロキシモバイルIPv6データにUDPポート番号を使用しています。これは、シグナリングに使用されるのとは異なるポートです）。IPSECを使用したペイロード保護が有効になっている場合、ESPヘッダーは、セクション4.3で説明されているように、外側の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-UDP-TLV（UDPとTLVヘッダーを備えたIPv4パケットに搭載されたペイロードパケット）およびIPv4-GRE（GREヘッダー付きIPv4パケットで運ばれるペイロードパケット）。[Grekey]を参照してください。IPSECを使用したペイロード保護が有効になっている場合、ESPヘッダーは、セクション4.3で説明されているように、外側の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プロキシケアオブアドレス。アドレスは、プロキシバインディングアップデートメッセージを含む受信したIPv4パケットのソースアドレスと同じでなければなりません。ただし、受信したプロキシバインディングアップデートメッセージがIPv4パケットとして送信されない場合、つまりIPv6トランスポートを使用する場合、バインディングキャッシュエントリのこのフィールドをALL_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).
o ローカルモビリティアンカー（IPv4-LMAA）のIPv4アドレス。
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.
o プロキシバインディングアップデートメッセージがIPSEC ESPで保護されている場合、IPSEC処理はパケットがプロキシモバイルIPv6に渡される前に行われます。
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 [RFC5213]のセクション5.3.1からのすべての考慮事項は、ステップ1（IPSECについて）を除くすべての考慮事項を、カプセル化されたプロキシバインディングアップデートメッセージに適用する必要があります。モビリティヘッダーのチェックサムフィールドは無視する必要があることに注意してください。
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-Proxy-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).
* 受信したプロキシバインディングアップデートメッセージの（f）フラグが（1）の値に設定されているが、構成フラグ、Acceptcedipv4udpencapsulationRequestが（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）フラグが（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）に設定してプロキシバインディング確認メッセージを送信する必要があります（プロキシバインディングアップデートは受け入れられます）。メッセージは、セクション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で指定されているようにメッセージを構築する必要があります。ただし、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ヘッダーが削除され、プロキシバインディングの確認を含むモビリティヘッダーがUDPにカプセル化されます（ソースポートが5436に設定され、宛先ポートが受信プロキシバインディングアップデートメッセージのソースポートに設定されています）。モビリティヘッダーチェックサムフィールドはゼロに設定する必要があります（代わりに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.
o IPSEC ESPを使用してシグナル伝達を保護する場合、セクション4.3で説明されているように、パケットはトランスポートモードESPを使用して処理されます。
o Figure 11 shows the format of the Proxy Binding Acknowledgement message sent over IPv4 and protected using ESP.
o 図11は、IPv4を介して送信され、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ヘッダー（Sport = 5436、DPort = 5436）モビリティヘッダー（PBA）
Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over IPv4
図11：IPv4を介して送信されたプロキシバインディング確認（PBA）メッセージ
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)
図12：LMAからMAGからTunneled IPv4パケット（IPv4またはIPv4-UUDPカプセル化モード）
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輸送トンネルにも適用されますが、カプセル化モードが異なるという違いは1つだけです。
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.
o ローカルモビリティアンカーのIPv4アドレス。このアドレスは、モバイルノードのポリシープロファイルから取得できます。
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で指定されているようにメッセージを構築する必要があります。ただし、モバイルアクセスゲートウェイがIPv4のみのアクセスネットワークにある場合、次の追加の考慮事項を適用する必要があります。
o The Proxy Binding Update message MUST be sent over IPv4 as described in Section 4.2.2.1.
o セクション4.2.2.1で説明されているように、プロキシバインディングアップデートメッセージはIPv4を介して送信する必要があります。
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]で指定されているように、現在既存のモビリティセッションの寿命を延長するためにプロキシバインディングアップデートメッセージを送信するとき、またはモビリティセッションを解除するために、プロキシバインド更新メッセージを最初のリクエストとして構築する必要があります。
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.
o 受信したプロキシバインド確認メッセージがIPSEC ESPで保護されている場合、IPSEC処理はパケットがプロキシモバイルIPv6に渡される前に行われます。[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からのすべての考慮事項は、カプセル化されたプロキシバインディング確認メッセージに適用する必要があります。モビリティヘッダーのチェックサムフィールドは無視する必要があることに注意してください。
o If the Status field indicates Success, the mobile access gateway MUST set up a bidirectional tunnel to the local mobility anchor.
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-Proxy-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]がある場合、（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ヘッダーが削除され、プロキシバインディングアップデートメッセージを含むモビリティヘッダーがUDPにカプセル化されています（宛先ポートが5436に設定されています）。モビリティヘッダーチェックサムフィールドはゼロに設定する必要があります（代わりに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-Proxy-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).
o 構成変数forceipv4udpencapsulationsupportが（1）の値に設定されている場合、プロキシバインディング更新メッセージの（f）フラグは（1）の値に設定する必要があります。
o If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3.
o IPSEC ESPを使用してシグナル伝達を保護する場合、セクション4.3で説明されているように、パケットはトランスポートモードESPを使用して処理されます。
o Figure 13 shows the format of the Proxy Binding Update message sent over IPv4 and protected using ESP.
o 図13は、IPv4を介して送信され、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-Proxy-Coa、DST = IPv4-LMAA）ESPヘッダー（輸送モード）UDPヘッダー（Sport = 5436、DPort = 5436）モビリティヘッダー（PBU）
Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4
図13：IPv4を介して送信されたプロキシバインディングアップデート（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.
o モバイルノードから任意の宛先までのIPv4またはIPv6パケットを受信すると、モバイルアクセスゲートウェイはパケットをローカルモビリティアンカーにトンネルする必要があります。トンネルパケットの形式を以下に示します。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)
図14：MAGからLMAへのトンネリングIPv4パケット（IPv4またはIPv4-UUDPカプセル化モード）
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.
次のセクションでは、IPv4トランスポートを使用する際のローカルモビリティアンカーとモバイルアクセスゲートウェイの間の信号メッセージとデータパケットを保護するためにIPSECを使用する方法について説明します。
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
mag spd-s：-local_address = ipv4-proxy-coa_1＆remote_address = ipv4-lmaa_1＆proto = udp＆remote_port = 5436を使用して、sa espトランスポートモードを使用します
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：-Local_Address = IPv4-LMAA_1＆REMOTE_ADDRESS = IPv4-Proxy-Coa_1＆Proto = 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
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
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カプセル化要求を受け入れるべきかどうかを示します。このフラグのデフォルト値は（0）に設定されており、プレーンIPv4カプセル化（UDPなし）がデータトラフィックに使用されていることを示しています。
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
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-UUDPカプセル化モードを使用するかどうかを示します。このフラグのデフォルト値は（0）に設定されており、プレーンIPv4カプセル化（UDPなし）がデータトラフィックに使用されていることを示しています。
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].
このドキュメントでは、4つの新しいモビリティヘッダーオプションを定義します。IPv4ホームアドレスリクエストオプション、IPv4ホームアドレス返信オプション、IPv4デフォルトルーターアドレスオプション、およびIPv4 DHCPサポートモードオプションです。これらのオプションは、それぞれセクション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 Expert Reviewを通じて行われます。
o 0 Success
o 0成功
o 128 Failure, Reason Unspecified
o 128失敗、理由が不特定
o 129 Administratively prohibited
o 129管理上禁止
o 130 Incorrect IPv4 home address
o 130 IPv4ホームアドレスが誤っていません
o 131 Invalid IPv4 address
o 131無効なIPv4アドレス
o 132 Dynamic IPv4 home address assignment not available
o 132動的IPv4ホームアドレスの割り当ては利用できません
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
Multhip_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-DATA」に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 Chowdhury
kchowdhury@starentnetworks.com
kchowdhury@starentnetworks.com
Vijay Devarapalli
Vijay Devarapalli
vijay.devarapalli@azairenet.com
vijay.devarapalli@azairenet.com
Pasi Eronen
Pasi Eronen
Pasi.Eronen@nokia.com
pasi.eronen@nokia.com
Sangjin Jeong
サンジン・ジョン
sjjeong@etri.re.kr
sjjeong@etri.re.kr
Basavaraj Patil
Basavaraj Patil
basavaraj.patil@nokia.com
basavaraj.patil@nokia.com
Myungki Shin
Myungki Shin
myungki.shin@gmail.com
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.
Alper Yegin、Behcet Sarikaya、Bernard Aboba、Charles Perkins、Damic Damjan、Jari Arkko、Joel Hortelius、Jonne Soinnen、Julien Laganier、Mohana Jeyatharan、Niklas Nuemann、Pasi Eron、Prec Domagoj、ralph drama、ralph dr myati、Yingzhe Wu、およびZu Qiangは、この文書の有益なレビューをしてくれました。
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レビュープロセスの一部としてこの文書のレビューについて、スペンサードーキンス、ティムポーク、メナケムドッジ、エイドリアンファレル、ペッカサボラに感謝します。最後に、Jouni KorohonenにIPSECの問題に対処することを支持してくれたことに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Alexander、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] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361] Lemon、T。およびB. Sommerfeld、「動的ホスト構成プロトコルバージョン4（DHCPV4）のノード固有のクライアント識別子」、RFC 4361、2006年2月。
[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
[RFC5107] Johnson、R.、Kumarasamy、J.、Kinnear、K。、およびM. Stapp、「DHCP Server Identifier Override Suboption」、RFC 5107、2008年2月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555] Soliman、H。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC0925] Postel、J。、「マルチローアドレス解決」、RFC 925、1984年10月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Kaufman、C。、「Internet Key Exchange（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.、Carlson、J。、およびS. Cheshire、「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. Soliman、「問題ステートメント：デュアルスタックモビリティ」、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.、Khalil、M.、Gundavelli、S。、およびK. Leung、「Proxy Mobile IPv6のGREキーオプション」、2009年5月、進行中の作業。
Authors' Addresses
著者のアドレス
Ryuji Wakikawa TOYOTA InfoTechnology Center, U.S.A., Inc. 465 Bernardo Avenue Mountain View, CA 94043 USA
Ryuji Wakikawa Toyota Infotechnology Center、U.S.A.、Inc。465 Bernardo Avenue Mountain View、CA 94043 USA
EMail: ryuji@us.toyota-itc.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com