Network Working Group H. Soliman, Ed.
Request for Comments: 5555 Elevate Technologies
Category: Standards Track June 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent.
現在のモバイルIPv6およびネットワークモビリティ（NEMO）の仕様は、IPv6のみをサポートしています。この仕様は、それぞれのIPv4アドレスとプレフィックスの登録、及びホームエージェントにトンネルを介してIPv4とIPv6の両方のパケットの輸送を可能にするために、これらの規格を拡張します。この仕様は、モバイルノードは、ネットワークアドレス変換は、モバイルノードとホームエージェントとの間の経路上に存在する場合など、IPv6とIPv4の両方にわたってローミングすることを可能にします。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Motivation for Using Mobile IPv6 Only ......................4
1.3. Scenarios Considered by This Specification .................4
2. Solution Overview ...............................................6
2.1. Home Agent Address Discovery ...............................6
2.2. Mobile Prefix Solicitation and Advertisement ...............7
2.3. Binding Management .........................................8
2.3.1. Foreign Network Supports IPv6 .......................8
2.3.2. Foreign Network Supports IPv4 Only ..................9
2.4. Route Optimization ........................................11
2.5. Dynamic IPv4 Home Address Allocation ......................11
3. Extensions and Modifications to Mobile IPv6 ....................11
3.1. Binding Update Extensions .................................11
3.1.1. IPv4 Home Address Option ...........................11
3.1.2. The IPv4 Care-of Address Option ....................13
3.1.3. The Binding Update Message Extensions ..............13
3.2. Binding Acknowledgement Extensions ........................14
3.2.1. IPv4 Address Acknowledgement Option ................14
3.2.2. The NAT Detection Option ...........................16
4. Protocol Operation .............................................17
4.1. Tunnelling Formats ........................................17
4.1.1. Tunnelling Impacts on Transport and MTU ............18
4.2. NAT Detection .............................................19
4.3. NAT Keepalives ............................................21
4.4. Mobile Node Operation .....................................22
4.4.1. Selecting a Care-of Address ........................22
4.4.2. Sending Binding Updates ............................23
4.4.3. Sending Packets from a Visited Network .............25
4.4.4. Movement Detection in IPv4-Only Networks ...........26
4.5. Home Agent Operation ......................................26
4.5.1. Sending Packets to the Mobile Node .................28
4.6. Correspondent Node Operation ..............................29
5. Security Considerations ........................................29
5.1. Handover Interactions for IPsec and IKE ...................30
5.2. IKE Negotiation Messages between the Mobile Node
and Home Agent ............................................33
5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling .....33
5.2.2. IKEv2 Operation for Securing Data over IPv4 ........36
6. Protocol Constants .............................................38
7. Acknowledgements ...............................................38
8. IANA Considerations ............................................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................40
10. Contributors ..................................................41
Mobile IPv6 [RFC3775] and NEMO [RFC3963] allow mobile nodes to move within the Internet while maintaining reachability and ongoing sessions, using an IPv6 home address or prefix. However, since IPv6 is not widely deployed, it is unlikely that mobile nodes will initially use only IPv6 addresses for their connections. It is reasonable to assume that mobile nodes will, for a long time, need an IPv4 home address that can be used by upper layers. It is also reasonable to assume that mobile nodes will move to networks that might not support IPv6 and would therefore need the capability to support an IPv4 care-of address. Hence, this specification extends Mobile IPv6 capabilities to allow dual stack mobile nodes to request that their home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, as well as IPv4/IPv6 care-of address(es).
モバイルIPv6 [RFC3775]及びNEMO [RFC3963]はIPv6のホームアドレスまたはプレフィックスを使用して、到達可能性および進行中のセッションを維持しながら、モバイルノードが、インターネット内で移動することを可能にします。 IPv6が広く展開されていないので、しかし、モバイルノードが最初にその接続のためのIPv6アドレスのみを使用することはほとんどありません。モバイルノードは、長い時間のために、上位層で使用することができたIPv4ホームアドレスを必要とすると仮定することは合理的です。また、モバイルノードがIPv6をサポートしていない可能性がありますネットワークに移動すると仮定するのが妥当であるためのIPv4気付アドレスをサポートするための機能が必要になります。したがって、この仕様はモバイルIPv6機能は、IPv4 / IPv6ののと同様に、デュアルスタックモバイルノードがホームエージェント（デュアル積層）トンネルのIPv4 / IPv6パケットは、それらのホームアドレス宛てことを要求することを可能にする気付アドレス（ES）延びています。
Using this specification, mobile nodes would only need Mobile IPv6 and [RFC3963] to manage mobility while moving within the Internet, hence eliminating the need to run two mobility management protocols simultaneously. This specification provides the extensions needed in order to allow dual stack mobile nodes to use IPv6 mobility only.
したがって、同時に2つのモビリティ管理プロトコルを実行する必要がなくなり、インターネット内で移動しながら、本明細書を使用して、モバイルノードは、モビリティを管理するためにモバイルIPv6と[RFC3963]を必要とするであろう。この仕様は、デュアルスタックモバイルノードが唯一のIPv6モビリティを使用することを可能にするために必要な拡張機能を提供します。
This specification will also consider cases where a mobile node moves into a private IPv4 network and gets configured with a private IPv4 care-of address. In these scenarios, the mobile node needs to be able to traverse the IPv4 NAT in order to communicate with the home agent. IPv4 NAT traversal for Mobile IPv6 is presented in this specification.
また、この仕様は、モバイルノードがプライベートIPv4ネットワークに移動し、プライベートIPv4気付アドレスが設定されます例を検討します。これらのシナリオでは、モバイルノードは、ホームエージェントと通信するためにIPv4のNATをトラバースすることができる必要があります。モバイルIPv6のIPv4 NATトラバーサルは、本明細書に提示されています。
In this specification, the term "mobile node" refers to both a mobile host and a mobile router unless the discussion is specific to either hosts or routers. Similarly, we use the term "home address" to reflect an address/prefix format. Note that both mobile host and router functionality have already been defined in [RFC3775] and [RFC3963], respectively. This specification does not change those already defined behaviors, nor does it extend the specific types of hosts and router support already defined, with the following two exceptions: (i) allowing the mobile node to communicate with its home agent even over IPv4 networks, and (ii) allowing the use of IPv4 home addresses and prefixes.
議論は、ホスト又はルータのいずれかに特異的でない限り、本明細書において、用語「モバイル・ノード」はモバイルホストとモバイルルータの両方を指します。同様に、我々は、アドレス/プレフィックス形式を反映するために、用語「自宅住所」を使用します。両方のモバイルホスト及びルータの機能は既に、それぞれ、[RFC3775]及び[RFC3963]で定義されていることに留意されたいです。この仕様は、これらのすでに定義されて動作を変更しません。また、次の2つの例外を除いて、すでに定義されたホストとルータのサポートの特定の種類を拡張しない：（ⅰ）モバイルノードもIPv4ネットワーク上でそのホームエージェントと通信できるようにする、と（ⅱ）のIPv4ホームアドレスとプレフィックスの使用を可能にします。
In this specification, extensions are defined for the binding update and binding acknowledgement. It should be noted that all these extensions apply to cases where the mobile node communicates with a Mobility Anchor Point (MAP) as defined in [RFC5380]. The
この仕様では、拡張子が結合更新と結合確認のために定義されています。 [RFC5380]で定義されるように、これらすべての拡張機能は、モバイルノードがモビリティ・アンカー・ポイント（MAP）と通信を行う場合に適用されることに留意すべきです。ザ・
requirements on the MAP are identical to those stated for the home agent; however, it is unlikely that NAT traversal would be needed with a MAP, as it is expected to be in the same address domain.
MAP上の要件は、ホームエージェントのために述べたものと同一です。しかし、同じアドレスのドメインであることが予想されるとして、NATトラバーサルは、MAPで必要とされることはほとんどありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
IPv6 offers a number of improvements over today's IPv4, primarily due to its large address space. Mobile IPv6 offers a number of improvements over Mobile IPv4 [RFC3344], mainly due to capabilities inherited from IPv6. For instance, route optimization and dynamic home agent discovery can only be achieved with Mobile IPv6.
IPv6は、主として、その大規模なアドレス空間に、今日のIPv4の上に多くの改良を提供しています。モバイルIPv6は主にIPv6のから継承された機能に、モバイルIPv4 [RFC3344]を超える多くの改良を提供します。たとえば、ルート最適化とダイナミックなホームエージェント発見はモバイルIPv6で達成することができます。
One of the advantages of the large address space provided by IPv6 is that it allows mobile nodes to obtain a globally unique care-of address wherever they are. Hence, there is no need for Network Address Translator (NAT) traversal techniques designed for Mobile IPv4. This allows Mobile IPv6 to be a significantly simpler and more bandwidth-efficient mobility management protocol. At the same time, during the transition towards IPv6, NAT traversal for existing private IPv4 networks needs to be considered. This specification introduces NAT traversal for this purpose.
IPv6のが提供する大規模なアドレス空間の利点の一つは、それがどこにいてもモバイルノードがグローバルに一意の気付アドレスを取得することを可能にするということです。したがって、モバイルIPv4のために設計されたネットワークアドレス変換（NAT）トラバーサル技術は必要ありません。これは、モバイルIPv6はかなり簡単でより帯域幅効率の良いモビリティ管理プロトコルにすることができます。同時に、IPv6のへの移行時に、既存のプライベートIPv4ネットワークのためのNATトラバーサルを考慮する必要があります。この仕様では、この目的のためにNATトラバーサルを紹介します。
The above benefits make the case for using only Mobile IPv6 for dual stack mobile nodes, as it allows for a long-lasting mobility solution. The use of Mobile IPv6 for dual stack mobility eliminates the need for changing the mobility solution due to the introduction of IPv6 within a deployed network.
それは長期的なモビリティソリューションを可能として、上記の利点は、デュアルスタックモバイルノードに対してのみモバイルIPv6を使用するためのケースを作ります。デュアルスタックのモビリティのためのモバイルIPv6の使用は、展開され、ネットワーク内のIPv6の導入にモビリティ・ソリューションを変更する必要がなくなります。
There are several scenarios that illustrate potential incompatibilities for mobile nodes using Mobile IPv6. Some of the problems associated with mobility and transition issues were presented in [RFC4977]. This specification considers the scenarios that address all the problems discussed in [RFC4977]. The scenarios considered in this specification are listed below.
モバイルIPv6を用いた移動ノードのための潜在的な非互換性を説明するいくつかのシナリオがあります。機動性と移行の問題に関連した問題のいくつかは、[RFC4977]に提示されました。この仕様は、[RFC4977]で説明したすべての問題に対処シナリオを検討します。この仕様で考慮シナリオは以下のとおりです。
All of the following scenarios assume that both the mobile node and the home agent are IPv4- and IPv6-enabled and that only Mobile IPv6 is used between the mobile node and the home agent. We also assume that the home agent is always reachable through a globally unique IPv4 address. Finally, it's important to note that the following scenarios are not mutually exclusive.
次のシナリオのすべては、モバイルノードとホームエージェントの両方がIPv4-およびIPv6対応していることを前提とし、唯一のモバイルIPv6がモバイルノードとホームエージェントとの間で使用されています。また、ホームエージェントは、グローバルにユニークなIPv4アドレスを通じて常に到達可能であることを前提としています。最後に、次のシナリオは、相互に排他的ではないことに注意することが重要です。
Scenario 1: IPv4-only foreign network
シナリオ1：IPv4のみの外部ネットワーク
In this scenario, a mobile node is connected to an IPv4-only foreign network. The mobile node can only configure an IPv4 care-of address.
このシナリオでは、モバイルノードは、IPv4のみの外部ネットワークに接続されています。モバイルノードは、IPv4のみの気付アドレスを設定することができます。
Scenario 2: Mobile node behind a NAT
シナリオ2：NATの背後にあるモバイルノード
In this scenario, the mobile node is in a private IPv4 foreign network that has a NAT device connecting it to the Internet. If the home agent is located outside the NAT device, the mobile node will need a NAT traversal mechanism to communicate with the home agent.
このシナリオでは、モバイルノードは、インターネットに接続するNATデバイスを持っているプライベートIPv4外部ネットワークです。ホームエージェントがNATデバイスの外側に配置されている場合は、モバイルノードは、ホームエージェントと通信するためにNATトラバーサルメカニズムが必要になります。
It should be noted that [RFC5389] highlights issues with some types of NATs that act as generic Application Level Gateways (ALGs) and rewrite any 32-bit field containing the NAT's public IP addresses. This specification will not support such NATs.
[RFC5389]は、一般的なアプリケーションレベルゲートウェイ（のALG）として機能し、NATのパブリックIPアドレスを含む任意の32ビットのフィールドを書き換えるNATのいくつかの種類の問題を強調ことに留意すべきです。この仕様は、このようなNATのをサポートしていません。
Scenario 3: Home agent behind a NAT
シナリオ3：NATの背後にあるホーム・エージェント
In this scenario, the communication between the mobile node and the home agent is further complicated by the fact that the home agent is located within a private IPv4 network. However, in this scenario, we assume that the home agent is allocated a globally unique IPv4 address. The address might not be physically configured on the home agent interface. Instead, it is associated with the home agent on the Network Address Port Translation (NAPT) device, which allows the home agent to be reachable through address or port mapping.
このシナリオでは、モバイルノードとホームエージェント間の通信は、さらに、ホームエージェントは、プライベートIPv4ネットワーク内に配置されているという事実によって複雑になります。ただし、このシナリオでは、我々はホームエージェントは、グローバルにユニークなIPv4アドレスを割り当てられていることを前提としています。アドレスは、物理的にホームエージェントインターフェイスに設定されない場合があります。その代わりに、ホームエージェントは、アドレスやポートマッピングを介して到達可能なことを可能にするネットワークアドレスポート変換（NAPT）デバイス、上のホームエージェントに関連付けられています。
Scenario 4: Use of IPv4-only applications
シナリオ4：IPv4のみのアプリケーションの使用
In this scenario, the mobile node may be located in an IPv4, IPv6, or dual network. However, the mobile node might be communicating with an IPv4-only node. In this case, the mobile node would need a stable IPv4 address for its application. The alternative to using an IPv4 address is to use protocol translators; however, end-to-end communication with IPv4 is preferred to the use of protocol translators.
このシナリオでは、モバイルノードは、IPv4、IPv6の、またはデュアルネットワークに配置することができます。しかしながら、モバイルノードは、IPv4専用ノードと通信されるかもしれません。この場合、モバイルノードは、そのアプリケーションのための安定したIPv4アドレスを必要とします。 IPv4アドレスを使用する代わりに、プロトコルトランスレータを使用することです。しかし、IPv4のとエンド・ツー・エンドの通信は、プロトコルトランスレータを使用することが好ましいです。
The mobile node may also be communicating with an IPv4-only application that requires an IPv4 address.
モバイルノードは、IPv4アドレスを必要とIPv4専用アプリケーションと通信することができます。
The cases above illustrate the need for the allocation of a stable IPv4 home address to the mobile node. This is done using an IPv4 home address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is problematic (as illustrated in [RFC4977]), this scenario adds a requirement on Mobile IPv6 to support IPv4 home addresses.
場合によっては、上記移動ノードに対して安定のIPv4ホームアドレスの割り当ての必要性を示しています。これは、IPv4のホームアドレスを使用して行われます。同時にモバイルIPv4及びモバイルIPv6を実行する（[RFC4977]に示されるように）問題があるので、このシナリオでは、IPv4ホームアドレスをサポートするために、モバイルIPv6に対する要件を追加します。
Scenario 5: IPv6 and IPv4-enabled networks
シナリオ5：IPv6とIPv4対応ネットワーク
In this scenario, the mobile node should prefer the use of an IPv6 care-of address for either its IPv6 or IPv4 home address. Normal IP-in-IP tunnelling should be used in this scenario as described in [RFC3775]. Under rare exceptions, where IP-in-IP tunnelling for IPv6 does not allow the mobile node to reach the home agent, the mobile node follows the sending algorithm described in Section 4.4.1. UDP tunnelling in IPv6 networks is proposed in this document as a last-resort mechanism when reachability cannot be achieved through normal IP-in-IP tunnelling. It should not be viewed as a normal mode of operation and should not be used as a first resort.
このシナリオでは、モバイルノードは、いずれかのIPv6とIPv4のホームアドレスのIPv6気付アドレスを使用することを好む必要があります。 [RFC3775]に記載されているように、通常のIPインIPトンネルは、このシナリオで使用されるべきです。 IPv6のIP内IPトンネリングは、モバイルノードがホームエージェントに到達することはできませんまれな例外は、下では、モバイルノードは、セクション4.4.1で説明した送信アルゴリズムに従います。到達可能性は、通常のIP内IPトンネリングを通じて達成することができないとき、IPv6ネットワークでのUDPトンネリングは最後の手段メカニズムとして、この文書で提案されています。これは、通常の動作モードとして見るべきではないと最初のリゾート地として使用すべきではありません。
In order to allow Mobile IPv6 to be used by dual stack mobile nodes, the following needs to be done:
モバイルIPv6のデュアルスタックモバイルノードによって使用されることを可能にするために、次のように行われる必要があります：
o Mobile nodes should be able to use IPv4 and IPv6 home or care-of addresses simultaneously and to update their home agents accordingly.
Oモバイルノードは、ホームIPv4とIPv6を使用するか、気付アドレスを同時にし、それに応じてホームエージェントを更新することができるはずです。
o Mobile nodes need to be able to know the IPv4 address of the home agent as well as its IPv6 address. There is no need for IPv4 prefix discovery, however.
Oモバイルノードは、ホームエージェントのIPv4アドレスだけでなく、そのIPv6アドレスを知ることができるようにする必要があります。 IPv4のプレフィックスの発見の必要はただし、ありません。
o Mobile nodes need to be able to detect the presence of a NAT device and traverse it in order to communicate with the home agent.
Oモバイルノードは、NATデバイスの存在を検出し、ホームエージェントと通信するためにそれを通過できるようにする必要があります。
This section presents an overview of the extensions required in order to allow mobile nodes to use only Mobile IPv6 for IP mobility management.
このセクションでは、モバイルノードがIPモビリティ管理のためにのみ、モバイルIPv6を使用できるようにするために必要な機能拡張の概要を説明します。
Dynamic Home Agent Address Discovery (DHAAD) is defined in [RFC3775] to allow mobile nodes to discover their home agents by appending a well-known anycast interface identifier to their home link's prefix. However, this mechanism is based on IPv6-anycast routing. If a mobile node (MN) is located in an IPv4-only foreign network, it cannot rely on native IPv6 routing. In this scenario, the solution for discovering the home agent's IPv4 address is through the Domain Name System (DNS). If the MN is attached to an IPv6-only or dual stack network, it may also use procedures defined in [CHOWDHURY] to discover home agent information. Note that the use of [CHOWDHURY] cannot give the mobile node information that allows it to communicate with the home agent if the mobile node is located in an IPv4-only network. In this scenario, the mobile node needs to discover the IPv4 address of its home agent through the DNS.
ダイナミックホームエージェントは、ディスカバリー（DHAAD）は、モバイルノードがホームリンクの接頭辞にはよく知られているエニーキャストインタフェース識別子を付加することによって、彼らのホームエージェントを発見できるようにするために[RFC3775]で定義されているアドレス。しかしながら、このメカニズムは、IPv6-エニーキャストルーティングに基づいています。モバイルノード（MN）がIPv4のみの外部ネットワークに位置している場合、それはネイティブのIPv6ルーティングに頼ることはできません。このシナリオでは、ホームエージェントのIPv4アドレスを発見するための解決策は、ドメインネームシステム（DNS）を介してです。 MNがIPv6のみ、またはデュアルスタックネットワークに接続されている場合、それはまた、ホームエージェント情報を発見するために、[CHOWDHURY]で定義された手順を使用することができます。 【CHOWDHURY]の使用は、移動ノードがIPv4のみのネットワーク内に配置されている場合、それはホームエージェントと通信することを可能にするモバイルノードの情報を与えることができないことに留意されたいです。このシナリオでは、モバイルノードは、DNSを通じてホームエージェントのIPv4アドレスを発見する必要があります。
For DNS lookup by name, the mobile node should be configured with the name of the home agent. When the mobile node needs to discover a home agent, it sends a DNS request with QNAME set to the configured name. An example is "ha1.example.com". If a home agent has an IPv4 and IPv6 address, the corresponding DNS record should be configured with both 'AAAA' and 'A' records. Accordingly, the DNS reply will contain 'AAAA' and 'A' records.
名前でDNSルックアップのために、モバイルノードは、ホームエージェントの名で設定する必要があります。モバイルノードがホームエージェントを発見する必要がある場合、設定された名前に設定QNAMEとDNS要求を送信します。例では、「ha1.example.com」です。ホームエージェントは、IPv4とIPv6のアドレスを持っている場合は、対応するDNSレコードは「AAAA」と「A」レコードの両方で設定する必要があります。したがって、DNS応答は「AAAA」と「A」レコードが含まれています。
For DNS lookup by service, the SRV record defined in [RFC5026] is reused. For instance, if the service name is "mip6" and the protocol name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS request with the QNAME set to "_mip6._ipv6.example.com". The response should contain the home agent's FQDN(s) and may include the corresponding 'AAAA' and 'A' records as well.
サービスによってDNSルックアップの場合は、[RFC5026]で定義されたSRVレコードが再利用されます。サービス名は「MIP6」で、プロトコル名はSRVレコードでの「IPv6」であれば例えば、モバイルノードは、「_mip6._ipv6.example.com」に設定QNAMEとDNSリクエストを送るべきです。応答は、ホームエージェントのFQDN（複数可）を含める必要がありますし、同様に対応する「AAAA」と「A」レコードを含んでいてもよいです。
If multiple home agents reside on the home link, each configured with a public IPv4 address, then the operation above applies. The correct DNS entries can be configured accordingly.
複数のホームエージェントがホームリンク上に存在する場合は、それぞれがパブリックIPv4アドレスを使用して設定、操作は上記適用されます。正しいDNSエントリは、それに応じて構成することができます。
According to [RFC3775], the mobile node can send a Mobile Prefix Solicitation and receive a Mobile Prefix Advertisement containing all prefixes advertised on the home link.
[RFC3775]によれば、移動ノードはモバイルプレフィックス要請を送信し、ホームリンクにアドバタイズされたすべてのプレフィックスを含むモバイルプレフィックス広告を受け取ることができます。
A dual stack mobile node MAY send a Mobile Prefix Solicitation message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where the mobile node has no access to IPv6 within the local network. Securing these messages requires the mobile node to have a security association with the home agent, using IPsec and based on the mobile node's IPv4 care-of address as described in [RFC3775] and [RFC4877].
デュアルスタックモバイルノードは、モバイルノードがローカルネットワーク内のIPv6へのアクセスを有していない場合には（IPv4の即ち、IPv6）のIPv4の中にカプセル化モバイルプレフィックス要請メッセージを送信することができます。これらのメッセージを確保することはIPsecを使用して、ホームエージェントとのセキュリティアソシエーションを持つように、モバイルノードを必要とし、モバイルノードのIPv4気付アドレス[RFC3775]と[RFC4877]で説明したように基づきます。
[RFC3775] requires the mobile node to include the home address option in the solicitation message sent to the home agent. If the mobile node is located in an IPv4 network, it will not be assigned an IPv6 address to include in the source address. In this case, the mobile node MUST use its home address in the source address field of the IPv6 packet, in addition to using the home address option as expected by [RFC3775].
[RFC3775]は、ホームエージェントに送信された要請メッセージにホームアドレスオプションが含まれるように、モバイルノードが必要です。移動ノードがIPv4ネットワークに位置している場合は、送信元アドレスに含まれるようにIPv6アドレスを割り当てられません。この場合、移動ノードは、[RFC3775]によって予想されるようにホームアドレスオプションを使用することに加えて、IPv6パケットの送信元アドレスフィールドにそのホームアドレスを使用しなければなりません。
A dual stack mobile node will need to update its home agent with its care-of address. If a mobile node has an IPv4 and an IPv6 home address, it will need to create a binding cache entry for each address. The format of the IP packet carrying the binding update and acknowledgement messages will vary depending on whether the mobile node has access to IPv6 in the visited network. There are three different scenarios to consider with respect to the visited network:
デュアルスタックモバイルノードはその気付アドレスをそのホームエージェントを更新する必要があります。モバイルノードは、IPv4とIPv6のホームアドレスを持っている場合、それは各アドレスのバインディングキャッシュエントリを作成する必要があります。バインディング更新と受信確認メッセージを運ぶIPパケットのフォーマットは、移動ノードが訪問先ネットワークにおけるIPv6へのアクセス権を持っているかどうかによって異なります。訪問先ネットワークに関して考慮すべき3つの異なるシナリオがあります。
o The visited network has IPv6 connectivity and provides the mobile node with a care-of address (in a stateful or stateless manner).
訪問先ネットワークoをIPv6接続を有し、気付アドレス（ステートフルまたはステートレスな方法で）とモバイルノードを提供します。
o The mobile node can only configure a globally unique IPv4 address in the visited network.
Oモバイルノードは、訪問先ネットワークにグローバルに一意のIPv4アドレスを設定することができます。
o The mobile node can only configure a private IPv4 address in the visited network.
Oモバイルノードは、訪問先ネットワーク内のプライベートIPv4アドレスを設定することができます。
In this case, the mobile node is able to configure a globally unique IPv6 address. The mobile node will send a binding update to the IPv6 address of its home agent, as defined in [RFC3775]. The binding update MAY include the IPv4 home address option introduced in this document. After receiving the binding update, the home agent creates two binding cache entries: one for the mobile node's IPv4 home address and another for the mobile node's IPv6 home address. Both entries will point to the mobile node's IPv6 care-of address. Hence, whenever a packet is addressed to the mobile node's IPv4 or IPv6 home address, the home agent will tunnel it in IPv6 to the mobile node's IPv6 care-of address that is included in the binding update. Effectively, the mobile node establishes two different tunnels, one for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6), with a single binding update.
この場合、移動ノードは、グローバルにユニークなIPv6アドレスを設定することができます。 [RFC3775]で定義されているモバイルノードは、そのホームエージェントのIPv6アドレスへのバインディングアップデートを送信します。バインディングアップデートは、本書で紹介したIPv4ホームアドレスオプションを含むかもしれません。モバイルノードのIPv4ホーム・アドレス用とモバイルノードのIPv6ホームアドレスのための別：バインディングアップデートを受信した後、ホームエージェントは、二つの結合キャッシュエントリを作成します。両方のエントリは、モバイルノードのIPv6気付アドレスを指します。パケットがモバイルノードのIPv4またはIPv6ホームアドレスにアドレス指定されるときはいつでもしたがって、ホームエージェントは、モバイルノードのIPv6気付アドレスバインディング更新に含まれているに対するIPv6トンネルをします。効果的に、モバイルノードは、単一のバインディングアップデートを持つ2つの異なるトンネル、そのIPv4トラフィックのための1つの（IPv6におけるIPv4）とそのIPv6トラフィック（IPv6におけるIPv6）のための1つを確立します。
In this scenario, this document extends [RFC3775] by including the IPv4 home address option in the binding update message. Furthermore, if the network supports both IPv4 and IPv6, or if the mobile node is experiencing problems with IP-in-IP tunnelling, this document proposes some mitigating actions as described in Section 4.4.1.
このシナリオでは、この文書には、バインディング更新メッセージ内のIPv4ホームアドレスオプションを含めることによって、[RFC3775]を延びています。さらに、ネットワークはIPv4とIPv6の両方をサポートしている場合、またはモバイルノードがIP内IPトンネリングで問題が発生している場合は、セクション4.4.1で説明したように、このドキュメントは、いくつかの緩和措置を提案しています。
After accepting the binding update and creating the corresponding binding cache entries, the home agent MUST send a binding acknowledgement to the mobile node as defined in [RFC3775]. In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described in Section 3.2.1. This option
[RFC3775]で定義されるようにバインディング更新を受け入れ、対応するバインディングキャッシュエントリを作成した後、ホームエージェントは、モバイルノードに結合肯定応答を送信しなければなりません。バインディングアップデートは、IPv4ホームアドレスオプションが含まれている場合、セクション3.2.1で説明したように加えて、結合確認は、IPv4アドレスの確認オプションを含まなければなりません。このオプション
informs the mobile node whether the binding was accepted for the IPv4 home address. If this option is not included in the binding acknowledgement and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address.
バインディングは、IPv4のホームアドレスのために受け入れられたかどうかをモバイルノードが通知します。このオプションは、バインディング確認に含まれていないとIPv4ホームアドレスオプションは、バインディングアップデートに含まれている場合は、モバイルノードは、ホームエージェントが結合将来のオプションを含めるべきではありませんので、IPv4のホームアドレスオプションをサポートしていないと仮定しなければなりませんそのホームエージェントアドレスへの更新。
When a mobile node acquires both IPv4 and IPv6 care-of addresses at the foreign network, it SHOULD prioritize the IPv6 care-of address for its MIPv6 binding as described in Section 4.4.1.
モバイルノードが外部ネットワークでIPv4とIPv6の両方の気付アドレスを取得すると、それは、セクション4.4.1に記載したように、そのMIPv6のバインディングのIPv6気付アドレスを優先すべきです。
If the mobile node is in a foreign network that only supports IPv4, it needs to detect whether a NAT is in its communication path to the home agent. This is done while exchanging the binding update and acknowledgement messages as shown later in this document. NAT detection is needed for the purposes of the signaling presented in this specification.
モバイルノードは、IPv4のみをサポートしている外部ネットワーク内にある場合、それはNATは、ホームエージェントへの通信パスであるかどうかを検出する必要があります。このドキュメントに示すように、バインディング更新肯定応答メッセージを交換している間に行われます。 NATの検出は、本明細書で提示シグナリングの目的のために必要とされます。
In this scenario, the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. The mobile node uses the IPv4 address it gets from the foreign network as a source address in the outer header. The binding update will contain the mobile node's IPv6 home address. However, since the care-of address in this scenario is the mobile node's IPv4 address, the mobile node MUST include its IPv4 care-of address in the IPv6 packet. The IPv4 address is represented in the IPv4 care-of address option defined in this specification. If the mobile node had an IPv4 home address, it MUST also include the IPv4 home address option described in this specification.
このシナリオでは、モバイルノードは、ホームエージェントのIPv4アドレスへのバインディングアップデートを含むトンネルIPv6パケットにする必要があります。モバイルノードは、それが外部ヘッダのソースアドレスとして外部ネットワークから取得したIPv4アドレスを使用します。バインディングアップデートは、モバイルノードのIPv6ホームアドレスが含まれています。気付アドレス、このシナリオでは、モバイルノードのIPv4アドレスであるので、移動ノードは、IPv6パケットにそののIPv4気付アドレスを含まなければなりません。 IPv4アドレスは、この仕様で定義されているIPv4アドレスのケア - のオプションで表されます。モバイルノードがIPv4ホームアドレスを持っていた場合、それはまた、本明細書に記載されたIPv4のホームアドレスオプションを含まなければなりません。
After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option is included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address. Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination address field.
バインディングアップデートを受け入れた後、ホームエージェントは、モバイルノードのIPv6ホームアドレスのための新しいバインディングキャッシュエントリを作成する必要があります。 IPv4のホームアドレスオプションが含まれている場合、ホームエージェントは、そのアドレスの別のエントリを作成する必要があります。すべてのエントリは、モバイルノードのIPv4気付アドレスを指している必要があります。したがって、すべてのパケットは、モバイルノードのホームアドレス（ES）（IPv4またはIPv6）先ソースアドレスフィールド内のホームエージェントのIPv4アドレスとモバイルノードのIPv4気付アドレスを含むIPv4ヘッダ内にカプセル化される宛てアドレスフィールド。
After accepting the binding updates and creating the corresponding entries, the home agent MUST send a binding acknowledgement as specified in [RFC3775]. In addition, if the binding update included
[RFC3775]で指定されるようにバインディング更新を受け入れ、対応するエントリを作成した後、ホームエージェントはバインディング肯定応答を送信しなければなりません。また、バインディングアップデートが含まれている場合
an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described in Section 3.2.1. The binding acknowledgement is encapsulated to the IPv4 care-of address, which was included in the source address field of the IPv4 header encapsulating the binding update.
IPv4のホームアドレスオプション3.2.1節で説明したように、バインディング確認は、IPv4アドレスの確認オプションを含まなければなりません。バインディング確認はのIPv4気付アドレス、バインディング更新をカプセル化IPv4ヘッダーのソースアドレスフィールドに含まれていたに封入されています。
In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. In order to traverse the NAT device, IPv6 packets are tunneled using UDP and IPv4. The UDP port allocated for the home agent is 4191 (dsmipv6).
このシナリオでは、モバイルノードは、ホームエージェントのIPv4アドレスへのバインディングアップデートを含むトンネルIPv6パケットにする必要があります。 NATデバイスをトラバースするために、IPv6パケットはUDPとIPv4を使用してトンネリングされます。ホームエージェントに割り当てられたUDPポートは4191（dsmipv6）です。
The mobile node uses the IPv4 address it gets from the visited network as a source address in the IPv4 header. The binding update will contain the mobile node's IPv6 home address.
モバイルノードは、IPv4ヘッダーのソースアドレスとして訪問先ネットワークから取得したIPv4アドレスを使用します。バインディングアップデートは、モバイルノードのIPv6ホームアドレスが含まれています。
After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option is included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address included in the source address of the IPv4 header that encapsulated the binding update message. In addition, the tunnel used MUST indicate UDP encapsulation for NAT traversal. Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in UDP and then encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination address field. Note that the home agent MUST store the source UDP port numbers contained in the packet carrying the binding update in order to be able to forward packets to the mobile node.
バインディングアップデートを受け入れた後、ホームエージェントは、モバイルノードのIPv6ホームアドレスのための新しいバインディングキャッシュエントリを作成する必要があります。 IPv4のホームアドレスオプションが含まれている場合、ホームエージェントは、そのアドレスの別のエントリを作成する必要があります。すべてのエントリは、モバイルノードのIPv4気付アドレスのバインディング更新メッセージをカプセル化されたIPv4ヘッダの送信元アドレスに含まを指していなければなりません。加えて、使用されるトンネルは、NATトラバーサルのためのUDPカプセル化を示さなければなりません。したがって、すべてのパケットは、モバイルノードのホームアドレス（ES）（IPv4またはIPv6）UDPにカプセル化され、次いで、ソースアドレスフィールドと、移動ノードのIPv4気付におけるホームエージェントのIPv4アドレスを含むIPv4ヘッダ内にカプセル化される宛て宛先アドレスフィールド内のアドレスの。ホームエージェントは、モバイルノードにパケットを転送することができるようにするために、バインディングアップデートを運ぶパケットに含まれる送信元UDPポート番号を格納しなければならないことに留意されたいです。
After accepting the binding updates and creating the corresponding entries, the home agent MUST send a binding acknowledgement as specified in [RFC3775]. In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described later in this specification. The binding acknowledgement is encapsulated in UDP and then in IPv4 with the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination field. The IPv4 address in the destination field of the IPv4 packet is the source address that was received in the IPv4 header containing the binding update message. The inner IPv6 packet will contain the home agent's IPv6 address as a source address and the mobile node's IPv6 home address in the destination address field.
[RFC3775]で指定されるようにバインディング更新を受け入れ、対応するエントリを作成した後、ホームエージェントはバインディング肯定応答を送信しなければなりません。バインディング更新がIPv4ホームアドレスオプションが含まれている場合は、この仕様書で後述するように加えて、結合確認は、IPv4アドレスの確認オプションを含まなければなりません。バインディング受信確認は、送信元アドレスフィールドにホームエージェントのIPv4アドレスと、移動ノードのIPv4気付アドレス宛先フィールド内でIPv4のUDPで、その後、カプセル化されています。 IPv4パケットの宛先フィールドのIPv4アドレスは、バインディング更新メッセージを含むIPv4ヘッダに受信された送信元アドレスです。インナーIPv6パケットは、送信元アドレスと宛先アドレスフィールド内のモバイルノードのIPv6ホームアドレスとホームエージェントのIPv6アドレスが含まれています。
The mobile node needs to maintain the NAT bindings for its current IPv4 care-of address. This is done through sending the binding update regularly to the home agent.
モバイルノードは、その現在のIPv4気付アドレスをNATバインディングを維持する必要があります。これは、ホームエージェントに定期的にバインディングアップデートを送信することによって行われます。
Route optimization, as specified in [RFC3775], will operate in an identical manner for dual stack mobile nodes when they are located in a visited network that provides IPv6 addresses to the mobile node and while communicating with an IPv6-enabled correspondent node. However, when located in an IPv4-only network, or when using the IPv4 home address to communicate with an IPv4 correspondent node, route optimization will not be possible due to the difficulty of performing the return-routability test. In this specification, UDP encapsulation is only used between the mobile node and its home agent. Therefore, mobile nodes will need to communicate through the home agent.
それらはモバイルノードとIPv6対応のコレスポンデント・ノードとの通信中にIPv6アドレスを提供する訪問先ネットワークに配置されている場合、ルート最適化は、[RFC3775]で指定されるように、デュアルスタックモバイルノードについて同じように動作します。 IPv4のみのネットワークに配置する場合、またはIPv4のコレスポンデントノードと通信するためのIPv4ホームアドレスを使用している場合しかし、ルート最適化が原因リターン・ルータビリティ・テストを実行することの難しすることはできません。本明細書では、UDPカプセル化は、モバイルノードとそのホームエージェントとの間でのみ使用されます。したがって、モバイルノードは、ホームエージェントを介して通信する必要があります。
Route optimization will not be possible for IPv4 traffic -- that is, traffic addressed to the mobile node's IPv4 home address. This is similar to using Mobile IPv4; therefore, there is no reduction of features resulting from using this specification.
ルート最適化は、IPv4トラフィックに対して行うことはできません - つまり、トラフィックは、モバイルノードのIPv4ホームアドレス宛。これは、モバイルIPv4を使用することに類似しています。従って、本明細書の使用から得られる機能の減少はありません。
It is possible to allow for the mobile node's IPv4 home address to be allocated dynamically. This is done by including 0.0.0.0 in the IPv4 home address option that is included in the binding update. The home agent SHOULD allocate an IPv4 address to the mobile node and include it in the IPv4 address acknowledgement option sent to the mobile node. In this case, the lifetime of the binding is bound to the minimum of the lifetimes of the IPv6 binding and the lease time of the IPv4 home address.
移動ノードのIPv4ホーム・アドレスが動的に割り当てられるためにできるようにすることが可能です。これは、バインディングアップデートに含まれているIPv4のホームアドレスオプションで0.0.0.0を含むことによって行われます。ホームエージェントは、モバイルノードにIPv4アドレスを割り当て、モバイルノードに送信されたIPv4アドレスの確認オプションに含めるべきです。この場合、結合の寿命は、IPv4のホームアドレスのリース時間を結合およびIPv6の寿命の最小値にバインドされています。
This section highlights the protocol and implementation additions required to support this specification.
このセクションでは、この仕様をサポートするために必要なプロトコルと実装追加を強調しています。
This option is included in the mobility header, including the binding update message sent from the mobile node to a home agent or Mobility Anchor Point. The alignment requirement for this option is 4n.
このオプションは、ホームエージェントまたはモビリティアンカーポイントに移動ノードから送信されたバインディング更新メッセージを含む、モビリティヘッダに含まれています。このオプションのアライメント要件は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 |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 Home Address Option
図1：IPv4のホームアドレスオプション
Type
タイプ
29
２９
Length
長さ
6
６
Prefix-len
プレフィックスのみ
The length of the prefix allocated to the mobile node. If only a single address is allocated, this field MUST be set to 32. In the first binding update requesting a prefix, the field contains the prefix length requested. However, in the following binding updates, this field must contain the length of the prefix allocated. A value of zero is invalid and MUST be considered an error.
モバイルノードに割り当てられたプレフィックスの長さ。単一のアドレスが割り当てられている場合、このフィールドはプレフィックスを要求する第1のバインディング更新で32に設定しなければなりません、フィールドは、要求されたプレフィックス長を含んでいます。ただし、以下のバインディングアップデートでは、このフィールドには、割り当てられたプレフィックスの長さが含まれている必要があります。ゼロの値は無効であり、エラーと見なされなければなりません。
P
P
A flag indicating, when set, that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes.
モバイルノードがモバイルネットワークプレフィックスを要求することを、設定されている場合、を示すフラグ。このフラグは、新しい要求にのみ関連して、リフレッシュを結合するために、無視されなければなりません。
Reserved
予約済み
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver.
このフィールドは、将来の使用のために予約されています。これは、送信者によってゼロに設定し、受信機で無視しなければなりません。
IPv4 Home Address
IPv4のホームアドレス
The mobile node's IPv4 home address that should be defended by the home agent. This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. The value 0.0.0.0 is used to request an IPv4 home address from the home agent. A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the P flag. The mobile node could then form an IPv4 home address based on the allocated prefix. Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a prefix.
ホームエージェントによって守られるべきモバイルノードのIPv4ホーム・アドレス。このフィールドは、モバイルノードに割り当てられていた（パブリックまたはプライベート）の任意のユニキャストIPv4アドレスを含めることができます。値0.0.0.0は、ホームエージェントからのIPv4ホームアドレスを要求するために使用されます。モバイルノードは、すべてゼロにアドレスを設定し、Pフラグを設定することで、プレフィックスを要求するために、このオプションを使用することもできます。モバイルノードは、割り当てられたプレフィックスに基づいたIPv4ホーム・アドレスを形成することができます。代替的に、モバイルノードは、二つの異なるオプション、（静的または動的）アドレスを要求するための1つの接頭辞を要求するための別のものを使用することができます。
This option is included in the mobility header, including the binding update message sent from the mobile node to a home agent or Mobility Anchor Point. The alignment requirement for this option is 4n.
このオプションは、ホームエージェントまたはモビリティアンカーポイントに移動ノードから送信されたバインディング更新メッセージを含む、モビリティヘッダに含まれています。このオプションのアライメント要件は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv4 CoA Option
図2：IPv4のCoAオプション
Type
タイプ
32
３２
Length
長さ
6
６
Reserved
予約済み
This field is set to zero by the sender and ignored by the receiver.
このフィールドは、送信者によってゼロに設定し、受信側では無視されます。
IPv4 Care-of Address
IPv4のアドレス気付
This field contains the mobile node's IPv4 care-of address. The IPv4 care-of address is used when the mobile node is located in an IPv4-only network.
このフィールドは、モバイルノードのIPv4気付アドレスが含まれています。移動ノードがIPv4のみのネットワーク内に位置する場合のIPv4気付アドレスが使用されます。
This specification extends the binding update message with one new flag. The flag is shown and described below.
本明細書には、1つの新しいフラグをバインディング更新メッセージを拡張します。フラグが示され、以下に説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Binding Update Message
図3：バインディング更新メッセージ
F
F
When set, this flag indicates a request for forcing UDP encapsulation regardless of whether a NAT is present on the path between the mobile node and the home agent. This flag may be set by the mobile node if it is required to use UDP encapsulation regardless of the presence of a NAT. This flag SHOULD NOT be set when the mobile node is configured with an IPv6 care-of address -- with the exception of the scenario mentioned in Section 4.4.1.
セットは、このフラグは関係なく、NATは、モバイルノードとホームエージェントとの間の経路上に存在するか否かのUDPカプセル化を強制するための要求を示す場合。関係なく、NATの存在のUDPカプセル化を使用する必要がある場合、このフラグは、モバイルノードによって設定されてもよいです。移動ノードがIPv6気付アドレスで構成されている場合、このフラグは設定しないでください - セクション4.4.1で述べたシナリオを除いて。
This option is included in the mobility header, including the binding acknowledgement message sent from the home agent or Mobility Anchor Point to the mobile node. This option indicates whether a binding cache entry was created for the mobile node's IPv4 address. Additionally, this option includes an IPv4 home address in the case of dynamic IPv4 home address configuration (i.e., if the unspecified IPv4 address was included in the binding update). The alignment requirement for this option is 4n.
このオプションは、モバイルノードにホームエージェントまたはモビリティアンカーポイントから送信されたバインディング受信確認メッセージを含む、モビリティヘッダに含まれています。このオプションは、バインディングキャッシュエントリがモバイルノードのIPv4アドレス用に作成されたかどうかを示します。また、このオプションは動的IPv4のホームアドレス構成の場合のIPv4ホームアドレスを含む（すなわち、不特定の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 Address Acknowledgement Option
図4：IPv4のアドレスの確認応答オプション
Type
タイプ
30
３０
Length
長さ
6
６
Status
状態
Indicates success or failure for the IPv4 home address binding. Values from 0 to 127 indicate success. Higher values indicate failure.
バインディングのIPv4ホームアドレスのための成功または失敗を示します。 0から127までの値は、成功を示します。より高い値は失敗を示しています。
Pref-len
前のみ
The prefix length of the address allocated. This field is only valid in case of success and MUST be set to zero and ignored in case of failure. This field overrides what the mobile node requested (if not equal to the requested length).
割り当てられたアドレスのプレフィックス長。このフィールドは、成功の場合にのみ有効であり、ゼロに設定し、障害が発生した場合に無視しなければなりません。このフィールドは、モバイルノードが（要求された長さと等しくない場合）、要求されたものを上書きします。
Res
真に
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver
このフィールドは、将来の使用のために予約されています。これは、送信者によってゼロに設定し、受信機で無視しなければなりません
IPv4 Home Address
IPv4のホームアドレス
The IPv4 home address that the home agent will use in the binding cache entry. This could be a public or private address. This field MUST contain the mobile node's IPv4 home address. If the address were dynamically allocated, the home agent will add the address to inform the mobile node. Otherwise, if the address is statically allocated to the mobile node, the home agent will copy it from the binding update message.
ホームエージェントはバインディングキャッシュエントリで使用するのIPv4ホーム・アドレス。これは、パブリックまたはプライベートアドレスである可能性があります。このフィールドは、モバイルノードのIPv4ホームアドレスを含まなければなりません。アドレスが動的に割り当てられた場合は、ホームエージェントは、モバイルノードに通知するためにアドレスを追加します。アドレスは静的にモバイルノードに割り当てられている場合はそうでない場合は、ホームエージェントはバインディング更新メッセージからコピーされます。
The following values are allocated for the status field:
次の値は、ステータスフィールドに割り当てられています：
o 0 Success
O 0成功
o 128 Failure, reason unspecified
O 128失敗、詳細不明の理由
o 129 Administratively prohibited
O 129は、管理上禁止します
o 130 Incorrect IPv4 home address
130の誤ったのIPv4ホーム・アドレスO
o 131 Invalid IPv4 address o 132 Dynamic IPv4 home address assignment not available
132ダイナミックIPv4のホームアドレスの割り当ては利用できませんO 131の無効なIPv4アドレスO
o 133 Prefix allocation unauthorized
133プレフィックス割り当て不正O
This option is sent from the home agent to the mobile node to indicate whether a NAT was in the path. This option MAY also include a suggested NAT binding refresh time for the mobile node. This might be useful for scenarios where the mobile node is known to be moving within the home agent's administrative domain and, therefore, the NAT timeout is known (through configuration) to the home agent. Section 3.5 of [RFC5405] discusses issues with NAT timeout in some detail.
このオプションは、NATがパスにあったかどうかを示すために、モバイルノードにホームエージェントから送信されます。このオプションは、モバイルノードのための提案NATバインディングリフレッシュ時間を含むかもしれません。これは、モバイルノードがホームエージェントの管理ドメイン内で移動することが知られており、そのため、NATタイムアウトがホームエージェントに（構成によって）知られているシナリオのために役に立つかもしれません。 [RFC5405]のセクション3.5は、いくつかの詳細にNATタイムアウトの問題について説明します。
The alignment requirement for this option is 4n. If a NAT is detected, this option MUST be sent by the home agent.
このオプションのアライメント要件は4Nです。 NATが検出された場合、このオプションは、ホームエージェントによって送らなければなりません。
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 |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The NAT Detection Option
図5：NAT検出オプション
Type
タイプ
31
３１
Length
長さ
6
６
F
F
This flag indicates to the mobile node that UDP encapsulation is required. When set, this flag indicates that the mobile node MUST use UDP encapsulation even if a NAT is not located between the mobile node and home agent. This flag SHOULD NOT be set when the mobile node is assigned an IPv6 care-of address -- with the exception of accommodating the scenarios discussed in Section 4.4.1.
このフラグはUDPカプセル化が必要とされているモバイルノードに指示します。設定されている場合、このフラグは、NATは、モバイルノードとホームエージェントの間に位置されていない場合でも、モバイルノードは、UDPカプセル化を使用しなければならないことを示しています。 4.4.1項で説明したシナリオを収容除いて - モバイルノードがIPv6気付アドレスを割り当てられている場合、このフラグは設定しないでください。
Reserved
予約済み
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver.
このフィールドは、将来の使用のために予約されています。これは、送信者によってゼロに設定し、受信機で無視しなければなりません。
Refresh Time
リフレッシュタイム
A suggested time (in seconds) for the mobile node to refresh the NAT binding. If set to zero, it is ignored. If this field is set to all 1s, it means that keepalives are not needed, i.e., no NAT was detected. The home agent MUST be configured with a default value for the refresh time. The recommended value is outlined in Section 6.
結合NATをリフレッシュするために、モバイルノードのために提案された時間（秒単位）。ゼロに設定した場合、それは無視されます。このフィールドがすべて1に設定されている場合、それはつまり、何のNATが検出されなかった、キープアライブが必要とされていないことを意味します。ホームエージェントは、リフレッシュ時間のデフォルト値を設定する必要があります。推奨値は、第6節に概説されています。
This section presents the protocol operation and processing for the messages presented above. In addition, this section introduces the NAT detection and traversal mechanism used by this specification.
このセクションでは、上記のメッセージのためのプロトコルの動作や処理を提示します。加えて、このセクションでは、本明細書で使用されるNAT検出とトラバース機構を導入します。
This specification allows the mobile node to use various tunnelling formats depending on its location and the visited network's capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6, or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this specification also supports tunnelling IPv6 in IPv6 [RFC2473].
この仕様は、移動ノードがその場所と訪問先ネットワークの能力に応じて様々なトンネリング・フォーマットを使用することができます。モバイルノードは、IPv6でのIPv4、IPv4のトンネルIPv6の、またはIPv4トンネルIPv6へのUDPカプセル化を使用することができます。当然のことながら、この仕様では、IPv6でのトンネリングのIPv6 [RFC2473]をサポートしています。
This specification allows UDP-based tunnelling to be used between the mobile node and its home agent or MAP. A UDP encapsulation format means the following order of headers:
この仕様は、UDPベースのトンネリングは、モバイルノードとそのホームエージェントまたはMAPの間で使用することができます。 UDPカプセル化フォーマットは、ヘッダの次の順序を意味します。
IPv4/v6
IPv4の/ B6
UDP
UDP
IP (v4 or v6)
IP（V4またはV6）
Other headers
その他のヘッダー
Note that the use of UDP encapsulation for IPv6 care-of addresses SHOULD NOT be done except in the circumstances highlighted in Section 4.4.1.
IPv6気付アドレスのためのUDPカプセル化の使用は、4.4.1項で強調表示状況を除いて行われるべきではないことに注意してください。
When using this format, the receiver parses the version field following the UDP header in order to determine whether the following header is IPv4 or IPv6. The rest of the headers are processed normally. The above order of headers does not take IPsec headers into account as they may be placed in different parts of the packet. The above format MUST be supported by all implementations of this specification and MUST always be used to send the binding update message.
この形式を使用する場合、受信機は、次のヘッダはIPv4またはIPv6であるかどうかを決定するためにUDPヘッダを次のバージョンフィールドを解析します。ヘッダの残りの部分は正常に処理されます。それらはパケットの異なる部分に配置することができるようにヘッダの上記順序は考慮のIPsecヘッダを取りません。上記フォーマットは、本明細書のすべての実装によってサポートされなければならないと常にバインディング更新メッセージを送信するために使用されなければなりません。
UDP tunnelling can also encapsulate an Encapsulating Security Payload (ESP) header as shown below:
以下に示すようにUDPトンネルはまた、カプセル化セキュリティペイロード（ESP）ヘッダをカプセル化することができます。
IPv4/v6
IPv4の/ B6
UDP
UDP
ESP
ESP
IP (v4 or v6)
IP（V4またはV6）
Other headers
その他のヘッダー
The negotiation of the secure tunnel format described above is discussed in Section 5.2. The receiver of a UDP tunnel detects whether or not an ESP header is present based on the UDP port used.
上述したセキュアトンネル・フォーマットのネゴシエーションは、セクション5.2で議論されています。 UDPトンネルの受信機は、ESPヘッダが使用されるUDPポートに基づいて存在しているか否かを検出します。
Changing the tunnel format may occur due to movement of the mobile node from one network to another. This can impact the link and path MTU, which may affect the amount of bandwidth available to the applications. The mobile node may use Path MTU Discovery (PMTUD) as specified in [RFC4459].
トンネル形式を変更すると、別のネットワークから移動ノードの移動に起因する起こり得ます。これは、アプリケーションに利用可能な帯域幅の量に影響を与える可能性があり、リンクおよびパスMTUを、影響を与えることができます。 [RFC4459]で指定されるように、モバイルノードは、Path MTUディスカバリ（PMTUD）を使用することができます。
To accommodate traffic that uses Explicit Congestion Notification (ECN), it is RECOMMENDED that the ECN and Differentiated Services Code Point (DSCP) information be copied between the inner and outer header as defined in [RFC3168] and [RFC2983]. It is RECOMMENDED that the full-functionality option defined in Section 9.1.1 of [RFC3168] be used to deal with ECN.
明示的輻輳通知（ECN）を使用してトラフィックを収容するために、[RFC3168]及び[RFC2983]で定義されるようにECNと差別化サービスコードポイント（DSCP）情報は、内側と外側のヘッダーとの間にコピーされることが推奨されます。 [RFC3168]のセクション9.1.1で定義されたフル機能のオプションは、ECNに対処するために使用することをお勧めします。
Note that some implementations may not be able to use ECN over the UDP tunnel. This is due to the lack of access to ECN bits in the UDP API on most platforms. However, this issue can be avoided if UDP encapsulation is done in the kernel.
いくつかの実装は、UDPトンネルを介しECNを使用することができないかもしれないことに留意されたいです。これは、ほとんどのプラットフォーム上のUDP APIでECNビットへのアクセスの欠如によるものです。 UDPカプセル化がカーネルで行われている場合は、この問題を回避することができます。
Note that, when using UDP encapsulation, the Time to Live (TTL) field must be decremented in the same manner as when IP-in-IP encapsulation is used.
UDPカプセル化を使用する場合、生存時間（TTL）のフィールドはIP-in-IPカプセル化を使用した場合と同様にデクリメントされなければならないことに留意されたいです。
This section deals with NAT detection for the purpose of encapsulating packets between the mobile node and the home agent when the mobile node is present in a private IPv4 network. Mobile IPv6 uses IKEv2 to establish the IPsec security association (SA) between the mobile node and the home agent. IKEv2 has its own NAT detection mechanism. However, IKEv2's NAT detection is only used for the purpose of setting up the IPsec SA for secure traffic. The interactions between the two NAT traversal mechanisms are described in Section 5.
モバイルノードがプライベートIPv4ネットワーク内に存在する場合、モバイルノードとホームエージェント間でパケットをカプセル化するために、NATの検出このセクションで扱っています。モバイルIPv6は、モバイルノードとホームエージェント間のIPsecセキュリティアソシエーション（SA）を確立するためのIKEv2を使用しています。 IKEv2のは、独自のNAT検出機構を備えています。しかし、IKEv2ののNATの検出は、安全な交通のためのIPsec SAを設定する目的でのみ使用されます。 2つのNATトラバーサル機構との間の相互作用は、セクション5に記載されています。
NAT detection is done when the initial binding update message is sent from the mobile node to the home agent. When located in an IPv4-only foreign link, the mobile node sends the binding update message encapsulated in UDP and IPv4. The source address of the IPv6 packet is the mobile node's IPv6 home address. The destination address is the IPv6 address of the home agent. The IPv4 header contains the IPv4 care-of address in the source address field and the IPv4 address of the home agent in the destination address field.
初期結合更新メッセージがホームエージェントにモバイルノードから送信されたときにNAT検出が行われます。 IPv4のみの外部リンクに位置するとき、モバイルノードはUDPとIPv4にカプセル化されたバインディング更新メッセージを送信します。 IPv6パケットの送信元アドレスは、移動ノードのIPv6ホームアドレスです。送信先アドレスは、ホームエージェントのIPv6アドレスです。 IPv4ヘッダは、送信元アドレスフィールドと宛先アドレスフィールドにホームエージェントのIPv4アドレスでのIPv4気付アドレスが含まれています。
When the home agent receives the encapsulated binding update, it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address included in the IPv4 care-of address option. If the two addresses match, no NAT device was in the path. Otherwise, a NAT was in the path and the NAT detection option is included in the binding acknowledgement. The binding acknowledgement and all future packets are then encapsulated in UDP and IPv4. The source address in the IPv4 header is the IPv4 address of the home agent. The destination address is the IPv4 address received in the IPv4 header encapsulating the binding update (this address will be different from the IPv4 care-of address when a NAT is in the path). The source port in the packet is the home agent's source port. The destination port is the source port received in the binding update message. Note that the home agent stores the port numbers and associates them with the mobile node's tunnel in order to forward future packets.
ホームエージェントは、カプセル化されたバインディング更新を受信すると、それは、IPv4気付アドレスオプションに含まれたIPv4アドレスとIPv4ヘッダーのソースアドレスフィールドのIPv4アドレスとを比較します。 2つのアドレスが一致していれば、何のNATデバイスは、パスではなかったです。それ以外の場合は、NATは、パスにあったとNATの検出オプションは、バインディング確認に含まれています。バインディング確認および将来のすべてのパケットはUDPとIPv4でカプセル化されています。 IPv4ヘッダの送信元アドレスは、ホームエージェントのIPv4アドレスです。宛先アドレスがバインディングアップデートを封入IPv4ヘッダで受信したIPv4アドレス（NATがパスである場合、このアドレスは、IPv4気付アドレスとは異なるであろう）。パケットの送信元ポートは、ホームエージェントのソースポートです。宛先ポートは、バインディング更新メッセージで受信した送信元ポートです。ホームエージェントはポート番号を格納および将来のパケットを転送するために、移動ノードのトンネルでそれらを関連付けることに注意してください。
Upon receiving the binding acknowledgement with the NAT detection option, the mobile node sets the tunnel to the home agent to UDP encapsulation. Hence, all future packets to the home agent are tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source address in the IPv6 header is the mobile node's IPv6 home address and the destination address is the correspondent node's IPv6 address. All tunneled IPv4 packets will contain the mobile node's IPv4 home address in the source address field of the inner IPv4 packet and the correspondent node's IPv4 address in the destination address field. The outer IPv4 header is the same whether the inner packet is IPv4 or IPv6.
NATの検出オプションを使用して、バインディング確認を受信すると、移動ノードは、UDPカプセル化にホームエージェントへのトンネルを設定します。したがって、ホームエージェントへのすべての将来のパケットはUDPとIPv4にトンネリングされます。すべてのトンネリングIPv6パケットの場合は、IPv6ヘッダーの送信元アドレスは、移動ノードのIPv6ホームアドレスであり、宛先アドレスは、通信相手ノードのIPv6アドレスです。すべてのトンネリングされたIPv4パケットは、内側のIPv4パケットの送信元アドレスフィールドと宛先アドレスフィールドに対応するノードのIPv4アドレスにモバイルノードのIPv4ホームアドレスが含まれています。外側IPv4ヘッダは、内部パケットはIPv4またはIPv6であるかどうかと同じです。
If no NAT device was detected in the path between the mobile node and the home agent, then IPv6 packets are tunneled in an IPv4 header unless the home agent forces UDP encapsulation using the F flag. The content of the inner and outer headers are identical to the UDP encapsulation case.
いかなるNATデバイスは、モバイルノードとホームエージェントとの間の経路で検出されなかった場合、ホームエージェントは、Fフラグを使用してUDPカプセル化を強制しない限り、次にIPv6パケットは、IPv4ヘッダにトンネルされます。内側と外側のヘッダの内容は、UDPカプセル化の場合と同じです。
A mobile node MUST always tunnel binding updates in UDP when located in an IPv4-only network. Essentially, this process allows for perpetual NAT detection. Similarly, the home agent MUST encapsulate binding acknowledgements in a UDP header whenever the binding update is encapsulated in UDP.
IPv4のみのネットワーク内に位置するとき、モバイルノードは常にトンネルがUDPで更新を結合しなければなりません。基本的に、このプロセスは永久NATの検出を可能にします。同様に、ホームエージェントはバインディング更新がUDPでカプセル化されるたびにUDPヘッダに結合肯定応答をカプセル化しなければなりません。
In conclusion, the packet formats for the binding update and acknowledgement messages are shown below:
結論として、バインディング更新と受信確認メッセージに対するパケットフォーマットは以下の通りです：
Binding update received by the home agent:
ホームエージェントが受信したバインディングアップデート：
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
IPv4ヘッダ（SRC = V4ADDR、DST = HA_V4ADDR）
UDP header
UDPヘッダ
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6ヘッダ（SRC = V6HOA、DST = HAADDR）
ESP header
ESPヘッダ
Mobility header
モビリティヘッダ
BU [IPv4 HAO]
B U [IP V4 HA O]
IPv4 CoA option
IPv4のCoAオプション
Where V4ADDR is either the IPv4 care-of address or the address provided by the NAT device. V6HOA is the IPv6 home address of the mobile node. The binding update MAY also contain the IPv4 home address option, IPv4 HAO.
V4ADDRは、アドレスのIPv4のケア、またはNATデバイスによって提供されたアドレスのいずれかです。 V6HOAは、モバイルノードのIPv6ホームアドレスです。バインディングアップデートは、IPv4ホームアドレスオプション、IPv4のHAOをも含むかもしれません。
Binding acknowledgement sent by the home agent:
ホームエージェントによって送信されたバインディング確認応答：
IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
IPv4ヘッダ（SRC = HA_V4ADDR、DST = V4ADDR）
UDP header
UDPヘッダ
IPv6 header (src=HAADDR, dst=V6HOA)
IPv6ヘッダ（SRC = HAADDR、DST = V6HOA）
ESP header
ESPヘッダ
Mobility header
モビリティヘッダ
BA ([IPv4 ACK], NAT DET)
BA（[IPv4のACK]、NAT）
Where V6HOA is the IPv6 home address of the mobile node. The IPv4 ACK is the IPv4 address acknowledgement option, which is only included if the IPv4 home address option is present in the BU. The NAT DET is the NAT detection option, which MUST be present in the binding acknowledgement message if the binding update was encapsulated in UDP.
V6HOAは、モバイルノードのIPv6ホームアドレスです。 IPv4のACKは、IPv4ホームアドレスオプションは、BU内に存在する場合にのみ含まれているIPv4アドレスの確認オプションです。 NAT DETは、バインディング更新がUDPにカプセル化された場合、バインディング確認メッセージ内に存在していなければなりませんNAT検出オプションです。
If a NAT is detected, the mobile node will need to refresh the NAT bindings in order to be reachable from the home agent. NAT bindings can be refreshed through sending and receiving traffic encapsulated in UDP. However, if the mobile node is not active, it will need to periodically send a message to the home agent in order to refresh the NAT binding. This can be done using the binding update message. The binding update/acknowledgement pair will ensure that the NAT bindings are refreshed in a reliable manner. There is no way for the mobile node to know the exact time of the NAT binding. The default time suggested in this specification is NATKATIMEOUT (see Section 6). If the home agent suggests a different refresh period in the binding acknowledgement, the mobile node SHOULD use the value suggested by the home agent.
NATが検出された場合、モバイルノードは、ホームエージェントから到達可能にするために、NATバインディングをリフレッシュする必要があります。 NATバインディングはUDPでカプセル化されたトラフィックを送受信を通じてリフレッシュすることができます。モバイルノードがアクティブでない場合は、それが定期的に結合NATをリフレッシュするために、ホームエージェントにメッセージを送信する必要があります。これは、バインディング更新メッセージを使用して行うことができます。バインディング更新/確認のペアは、NATバインディングが確実にリフレッシュされることを保証します。モバイルノードは、バインディングNATの正確な時刻を知るための方法はありません。この仕様で提案されているデフォルトの時間はNATKATIMEOUT（セクション6を参照）です。ホームエージェントは、バインディング確認で異なるリフレッシュ周期を示唆している場合、モバイルノードは、ホームエージェントによって提案された値を使用する必要があります。
If the refresh time in the NAT detection option in the binding acknowledgement is set to all 1s, the mobile node need not send messages to refresh the NAT binding. However, the mobile node may still be required to encapsulate traffic in UDP. This scenario may take place when a NAT is not detected but the home agent still requires the mobile node to use UDP encapsulation.
バインディング確認でNAT検出オプションでリフレッシュ時間はすべて1に設定されている場合、モバイルノードは、バインディングNATをリフレッシュするためにメッセージを送信する必要はありません。しかし、モバイルノードは、まだUDPのトラフィックをカプセル化するために必要な場合があります。 NATが検出されない場合は、このシナリオが起こり得るが、ホームエージェントは、まだUDPカプセル化を使用するために、モバイルノードが必要です。
It should be noted that a mobile node that does not need to be reachable (i.e., one that only cares about the session continuity aspect of Mobile IP) does not need to refresh the NAT binding. In this case, the mobile node would only be able to initiate communication with other nodes. However, this is likely to imply that the mobile node will need to send a binding update before initiating communication after a long idle period as it is likely to be assigned a different port and IPv4 address by the NAT when it initiates communication. Hence, an implementation may choose, for the sake of simplicity, to always maintain the NAT bindings even when it does not need reachability.
到達可能である必要はなく、モバイルノード（すなわち、唯一のモバイルIPセッションの継続性の観点気つ）結合NATを更新する必要がないことに留意すべきです。この場合、移動ノードは、他のノードとの通信を開始することができるであろう。しかし、これは、モバイルノードが、通信を開始するときに、NATによって異なるポートおよびIPv4アドレスを割り当てられる可能性があるとして、長いアイドル期間の後に通信を開始する前にバインディングアップデートを送信する必要があることを暗示する可能性があります。したがって、実装は、それが到達可能性を必要としない場合でも、常にNATバインディングを維持するために、簡略化のために、選択することができます。
Note that keepalives are also needed by IKEv2 over UDP port 4500. This is needed for IKE (Internet Key Exchange Protocol) dead-peer detection, which is not handled by DSMIPv6 keepalives.
キープアライブがまたこれは、DSMIPv6のキープアライブによって処理されていないIKE（インターネット鍵交換プロトコル）デッドピア検出のために必要とされるUDPポート4500上でのIKEv2によって必要とされていることに注意してください。
In addition to the operations specified in [RFC3775] and [RFC3963], this specification requires mobile nodes to be able to support an IPv4 home address. This specification also requires the mobile node to choose an IPv4 or an IPv6 care-of address. We first discuss care-of address selection, then continue with binding management and transmission of normal traffic.
[RFC3775]及び[RFC3963]で指定された動作に加えて、この仕様は、IPv4ホームアドレスをサポートすることができるようにモバイルノードを必要とします。また、この仕様はIPv4またはIPv6の気付アドレスを選択するために、モバイルノードが必要です。私たちは、第一の結合管理と通常のトラフィックの送信を続け、その後、気付アドレスの選択を議論します。
When a mobile node is in a dual stacked, visited network, it will have a choice between an IPv4 and an IPv6 care-of address. The mobile node SHOULD prefer the IPv6 care-of address and bind it to its home address(es). If a mobile node attempted to bind the IPv6 care-of address to its home address(es) and the binding update timed out, the mobile node SHOULD:
モバイルノードは、デュアルスタック、訪問先ネットワークである場合、それは、IPv4とIPv6の気付アドレス間の選択肢があります。モバイルノードは、IPv6気付アドレスを好むとそのホームアドレス（複数可）にバインドすべきです。モバイルノードがそのホームアドレス（複数可）へのIPv6気付アドレスをバインドしようとしましたし、バインディング更新がタイムアウトした場合、移動ノードは、必要があります。
o Resend the binding update using the exponential back-off algorithm described in [RFC3775].
O [RFC3775]に記載の指数バックオフアルゴリズムを使用してバインディングアップデートを再送信。
o If after three attempts, in total, a binding acknowledgement was not received, the mobile node SHOULD send a new binding update using the IPv4 care-of address. The exponential backoff algorithm described in [RFC3775] should be used for re-transmission of the binding update if needed.
3回の試行の後、合計で、バインディング確認が受信されなかった場合はO、モバイルノードは、IPv4気付アドレスを使用して新しいバインディング更新を送信すべきです。必要に応じて、[RFC3775]に記載の指数バックオフアルゴリズムは、バインディング更新の再送信のために使用されるべきです。
This procedure should be used to avoid scenarios where IPv6 connectivity may not be as reliable as IPv4. This unreliability may take place during early deployments of IPv6 or may simply be due to temporary outages affecting IPv6 routing.
この手順では、IPv6接続がIPv4のように信頼性がないかもしれないシナリオを回避するために使用する必要があります。この信頼性の欠如は、IPv6の早期展開の際に起こり得るか、単にIPv6ルーティングに影響を与える一時的な停止に起因する可能性があります。
It is RECOMMENDED that upon movement, the mobile node not change the IP address family chosen for the previous binding update unless the mobile node is aware that it has moved to a different administrative domain where previous problems with IPv6 routing may not be present. Repeating the above procedure upon every movement can cause significant degradation of the mobile node's applications' performance due to extended periods of packet losses after handover, if the routing outage is still in effect.
移動ノードがIPv6ルーティングを用いた以前の問題は存在しないかもしれない異なる管理ドメインに移動したことを認識していない限り、移動の際に、モバイルノードが前のバインディング更新のために選択されたIPアドレスファミリを変更しないことをお勧めします。ルーティング停止がまだ有効である場合、すべての移動の際に上記の手順を繰り返すと、ハンドオーバ後に起因するパケットロスの長時間に、移動ノードのアプリケーションのパフォーマンスの大幅な低下を引き起こす可能性があります。
When using an IPv4 care-of address and IP-in-IP encapsulation, if the mobile node implementation is made aware by upper layers of persistent packet losses, it may attempt to resend the binding update with the F flag set, requesting UDP encapsulation for all packets. This may avoid packet losses due to situations where local firewalling policies prevent the use of IP-in-IP encapsulation.
IPv4気付アドレスとIP-in-IPカプセル化を使用する場合は、モバイルノードの実装が永続パケット損失の上位レイヤによって認識された場合、それはのためのUDPカプセル化を要求し、Fフラグが設定されたバインディング更新を再送信しようと試みることができますすべてのパケット。これは、ローカルファイアウォールポリシーは、IP-in-IPカプセル化の使用を妨げる状況に起因するパケットロスを回避することができます。
The effect of this address selection mechanism is to allow the following preferences in the absence of NAT:
このアドレス選択メカニズムの効果は、NATが存在しない場合に、以下の設定をできるようにすることです：
3. UDP encapsulation when IP-in-IP is not allowed by the local domain.
IP-IPでは、ローカルドメインで許可されていない3 UDPカプセル化。
When sending an IPv6 packet containing a binding update while connected to an IPv4-only access network, mobile nodes MUST ensure the following:
IPv4専用アクセスネットワークに接続されている間バインディングアップデートを含むIPv6パケットを送信するとき、モバイルノードは、次のことを確認する必要があります。
o The IPv6 packet is encapsulated in UDP.
O IPv6パケットをUDPでカプセル化されています。
o The source address in the IPv4 header is the mobile node's IPv4 care-of address.
O IPv4ヘッダーのソースアドレスは、移動ノードのIPv4気付アドレスです。
o The destination address in the IPv4 header is the home agent's IPv4 address.
O IPv4ヘッダの宛先アドレスは、ホームエージェントのIPv4アドレスです。
o The source address in the IPv6 header is the mobile node's IPv6 home address.
O IPv6ヘッダの送信元アドレスは、移動ノードのIPv6ホームアドレスです。
o The IPv4 home address option MAY be included in the mobility header. This option contains the IPv4 home address. If the mobile node did not have a static home address, it MAY include the unspecified IPv4 address, which acts as a request for a dynamic IPv4 home address. Alternatively, one or more IPv4 home address options may be included with requests for IPv4 prefixes (i.e., with the P flag set).
OのIPv4ホームアドレスオプションは、モビリティヘッダに含まれるかもしれません。このオプションは、IPv4ホームアドレスが含まれています。モバイルノードは、静的なホームアドレスを持っていなかった場合、それはダイナミックのIPv4ホーム・アドレスに対する要求として機能し、不特定のIPv4アドレスを含むことができます。あるいは、一の以上のIPv4ホームアドレスオプションは、IPv4のプレフィックス（すなわち、Pフラグが設定されている）の要求に含まれてもよいです。
o If the mobile node wishes to use UDP encapsulation only, it must set the F flag in the binding update message.
モバイルノードのみUDPカプセル化を使用したい場合、Oは、バインディング更新メッセージでFフラグを設定する必要があります。
o The IPv6 packet MUST be authenticated as per [RFC3775], based on the mobile node's IPv6 home address.
O IPv6パケットは、モバイルノードのIPv6ホームアドレスに基づいて、[RFC3775]あたりとして認証されなければなりません。
When sending a binding update from a visited network that supports IPv6, the mobile node MUST follow the rules specified in [RFC3775]. In addition, if the mobile node has an IPv4 home address or needs one, it MUST include the IPv4 home address option in the mobility header. If the mobile node already has a static IPv4 home address, this address MUST be included in the IPv4 home address option. Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST include the IPv4 0.0.0.0 address in the IPv4 home address option.
IPv6をサポートする訪問先ネットワークからバインディングアップデートを送信するとき、モバイルノードは、[RFC3775]で指定された規則に従わなければなりません。モバイルノードがIPv4ホームアドレスを持っている、または1つを必要とする場合また、それは、モビリティヘッダ内のIPv4ホームアドレスオプションを含まなければなりません。モバイルノードがすでに静的IPv4ホームアドレスを持っている場合、このアドレスは、IPv4ホームアドレスオプションに含まれなければなりません。モバイルノードが動的IPv4アドレスを必要とする場合それ以外の場合、それは、IPv4ホームアドレスオプションでIPv4の0.0.0.0のアドレスを含まなければなりません。
In addition to the rules in [RFC3775], the mobile node should follow the care-of address selection guidelines in Section 4.4.1.
[RFC3775]のルールに加えて、移動ノードは、セクション4.4.1に気付アドレス選択ガイドラインに従うべきです。
When the mobile node receives a binding acknowledgement from the home agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, the following actions MUST be made:
モバイルノードがホームエージェントから結合肯定応答を受信すると、それは[RFC3775]及び[RFC3963]のルールに従います。また、次のアクションを行う必要があります。
o If the status field indicated failure with error code 144, the mobile node MAY resend the binding update without setting the F flag.
ステータスフィールドはエラーコード144で失敗を示す場合、O、モバイルノードは、Fフラグを設定せずにバインディング更新を再送信することができます。
o If the mobility header includes an IPv4 address acknowledgement option indicating success, the mobile node should create two entries in its binding update list: one for the IPv6 home address and another for the IPv4 home address.
IPv4のホームアドレスのIPv6ホームアドレス用と別：モビリティヘッダは、成功を示すのIPv4アドレスの確認オプションが含まれている場合は、O、モバイルノードは、そのバインディングアップデートリスト内の2つのエントリを作成する必要があります。
o If the NAT detection option is present, the mobile node MUST tunnel future packets in UDP and IPv4. This MUST be indicated in the binding update list.
O NAT検出オプションが存在する場合、UDPおよびIPv4の移動ノードMUSTトンネル将来のパケット。これは、バインディングアップデートリストに示されなければなりません。
o If no IPv4 address acknowledgement option is present, and an IPv4 home address option was present in the binding update, the mobile node MUST only create one binding update list entry for its IPv6 home address. The mobile node MAY include the IPv4 home address option in future binding updates.
何のIPv4アドレスの確認オプションが存在しない、とIPv4ホームアドレスオプションは、バインディングアップデート中に存在していた場合は、O、モバイルノードは、そのIPv6のホームアドレスに対して1つのバインディングアップデートリストのエントリを作成する必要があります。モバイルノードは、将来のバインディングアップデートでのIPv4ホームアドレスオプションを含むかもしれません。
o If an IPv4 address acknowledgement option is present and it indicates failure for the IPv4 home address binding, the mobile node MUST NOT create an entry for that address in its binding update list. The mobile node MAY include the IPv4 home address option in future binding updates.
IPv4のアドレス確認オプションが存在し、それが結合のIPv4ホームアドレスのために失敗したことを示している場合は、O、モバイルノードは、そのバインディングアップデートリストにそのアドレスのエントリを作成してはいけません。モバイルノードは、将来のバインディングアップデートでのIPv4ホームアドレスオプションを含むかもしれません。
Mobile nodes will remove bindings from the home agent's binding cache whenever they move to the home link, or simply when mobility support is not needed.
モビリティサポートが必要とされていない場合、モバイルノードは、単に彼らがホームリンクに移動するたびにホームエージェントのバインディングキャッシュからバインディングを削除、またはます。
Deregistering the IPv6 home address is described in [RFC3775]. The same mechanism applies in this specification. Mobile nodes may remove the binding for only the IPv4 home address by sending a binding update that does not include the IPv4 home address option.
登録解除は、IPv6ホームアドレスは、[RFC3775]に記述されています。同じメカニズムがこの仕様に適用されます。モバイルノードは、IPv4ホームアドレスオプションが含まれていないバインディングアップデートを送信することにより、IPv4だけのホームアドレスのバインディングを削除することがあります。
Upon receiving this binding update, the home agent will replace the existing cache entries with the content of the new message. This ensures that the IPv4 home address binding is removed while maintaining an IPv6 binding.
このバインディングアップデートを受信すると、ホームエージェントは、新しいメッセージの内容と既存のキャッシュエントリに置き換えられます。これは、結合IPv6を維持しながら、結合のIPv4ホームアドレスが削除されることを保証します。
Note that the mobile node cannot remove the IPv6 home address binding while maintaining an IPv4 home address binding.
モバイルノードは、バインディングのIPv4ホームアドレスを維持しながら、結合のIPv6ホームアドレスを削除できないことに注意してください。
A binding update message with a lifetime of zero will remove all bindings for the mobile node.
ゼロの存続期間を有するバインディング更新メッセージは、移動ノードのすべてのバインディングを削除します。
When the mobile node is located in an IPv6-enabled network, it sends and receives IPv6 packets as described in [RFC3775]. In cases where IP-in-IP encapsulation is not providing connectivity to the home agent, the mobile node may choose to encapsulate in UDP as suggested in Section 4.4.1. However, this encapsulation of IPv6 traffic should be used as a last resort, as described. IPv4 traffic is encapsulated in IPv6 packets to the home agent.
移動ノードがIPv6対応ネットワークに存在する場合、それは[RFC3775]に記載されているようにIPv6パケットを送受信します。 IP-in-IPカプセル化は、ホームエージェントへの接続を提供していない場合には、モバイルノードは、4.4.1項で提案されているようにUDPでカプセル化することもできます。説明したようしかし、IPv6トラフィックのこのカプセル化は、最後の手段として使用されるべきです。 IPv4トラフィックは、ホームエージェントにIPv6パケットにカプセル化されます。
When the mobile node is located in an IPv4-only network, it will send IPv6 packets to its home agent according to the following format:
移動ノードがIPv4のみのネットワークに配置されている場合、それは次のような形式に応じてそのホームエージェントにIPv6パケットを送信します。
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
IPv4ヘッダ（SRC = V4CoA、DST = HA_V4ADDR）
[UDP header]
[UDPヘッダ]
IPv6 header (src=V6HoA, dst=CN)
IPv6ヘッダ（SRC = V6HoA、DST = CN）
Upper layer protocols
上位層プロトコル
Here, the UDP header is only used if a NAT has been detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. V4CoA is the IPv4 care-of address configured by the mobile node in the visited network.
ここでは、NATは、モバイルノードとホームエージェントとの間で検出された場合、UDPヘッダにのみ使用される、またはホームエージェントは、UDPカプセル化を強制場合。 V4CoAは、IPv4気付アドレス訪問先ネットワーク内の移動ノードで構成されています。
Similarly, IPv4 packets are sent according to the following format:
同様に、IPv4パケットは、次の形式に応じて送信されます。
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
IPv4ヘッダ（SRC = V4CoA、DST = HA_V4ADDR）
[UDP header]
[UDPヘッダ]
IPv4 header (src=V4HoA, dst=V4CN)
IPv4ヘッダ（SRC = V4HoA、DST = V4CN）
Upper Layer protocols
上位層プロトコル
Here, the UDP header is only used if a NAT has been detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation.
ここでは、NATは、モバイルノードとホームエージェントとの間で検出された場合、UDPヘッダにのみ使用される、またはホームエージェントは、UDPカプセル化を強制場合。
[RFC3775] describes movement detection mostly based on IPv6-specific triggers and Neighbor Discovery [RFC4861] information. These triggers are not available in an IPv4-only network. Hence, a mobile node located in an IPv4-only network SHOULD use [RFC4436] for guidance on movement-detection mechanisms in IPv4-only networks.
[RFC3775]は主にIPv6固有のトリガと近隣探索[RFC4861]の情報に基づいて動き検出を記載します。これらのトリガーは、IPv4のみのネットワークでは使用できません。したがって、IPv4のみのネットワーク内に位置する移動ノードがIPv4のみのネットワークにおける移動検出機構に関するガイダンスのために[RFC4436]を使用すべきです。
The mobile node detects that it's in an IPv4-only network when the IPv6 movement-detection algorithm fails to configure an IPv6 address.
モバイルノードは、IPv6動き検出アルゴリズムは、IPv6アドレスを設定するには、失敗したとき、それはIPv4のみのネットワークでいたことを検出します。
This specification does not support mobile nodes returning home while using IPv4. That is, the IPv4 support is only defined for mobile nodes that are in a visited network.
この仕様はIPv4を使用しながら帰宅モバイルノードをサポートしていません。すなわち、IPv4サポートのみ訪問先ネットワーク内にあるモバイルノードのために定義されています。
In addition to the home agent specification in [RFC3775] and [RFC3963], the home agent needs to be able to process the IPv4 home address option and generate the IPv4 address acknowledgement option. Both options are included in the mobility header. Furthermore, the home agent MUST be able to detect the presence of a NAT device and indicate that presence in the NAT detection option included in the binding acknowledgement.
[RFC3775]と[RFC3963]でホームエージェントの仕様に加えて、ホームエージェントは、IPv4ホームアドレスオプションを処理し、IPv4アドレスの確認オプションを生成できるようにする必要があります。両方のオプションは、モビリティヘッダに含まれています。さらに、ホームエージェントは、NATデバイスの存在を検出することが可能とNAT検出オプションでの存在は、バインディング確認に含まれていることを示している必要があります。
A home agent must also act as a proxy for address resolution in IPv4 for the registered IPv4 home addresses of mobile nodes it is serving. Moreover, the administrative domain of the home agent is responsible for advertising the routing information of registered IPv4 mobile-network prefixes of the mobile nodes.
ホームエージェントは、それがサービスを提供しているモバイルノードの登録のIPv4ホームアドレスのためのIPv4のアドレス解決のためのプロキシとして動作しなければなりません。また、ホームエージェントの管理ドメインは、モバイルノードの登録IPv4の移動ネットワークプレフィックスのルーティング情報を広告するための責任があります。
In order to comply with this specification, the home agent MUST be able to find the IPv4 home address of a mobile node when given the IPv6 home address. That is, given an IPv6 home address, the home agent MUST store the corresponding IPv4 home address if a static one is present. If a dynamic address is requested by the mobile node, the home agent MUST store that address (associated with the IPv6 home address) after it's allocated to the mobile node.
IPv6のホームアドレスが与えられたときに、この仕様に準拠するためには、ホームエージェントは、モバイルノードのIPv4のホームアドレスを見つけることができなければなりません。静的なものが存在する場合には、IPv6のホームアドレスが与えられると、ホームエージェントは、対応のIPv4ホームアドレスを格納する必要があります。ダイナミックアドレスは、モバイルノードによって要求された場合、それがモバイルノードに割り当てられていた後、ホームエージェントは、（IPv6のホームアドレスに関連付けられている）、そのアドレスを保存しなければなりません。
When the home agent receives a binding update encapsulated in UDP and containing the IPv4 home address option, it needs to follow all the steps in [RFC3775] and [RFC3963]. In addition, the following checks MUST be done: o If the IPv4 care-of address in the IPv4 CoA option is not the same as the IPv4 address in the source address in the IPv4 header, then a NAT was in the path. This information should be flagged for the binding acknowledgement.
ホームエージェントはUDPでカプセル化されたバインディングアップデートを受信し、IPv4ホームアドレスオプションを含む場合は、[RFC3775]と[RFC3963]のすべての手順を実行する必要があります。加えて、以下のチェックが行われなければならない：のIPv4気付IPv4のCoAオプション内のアドレスは、IPv4ヘッダーのソースアドレスにIPv4アドレスと同じでないO場合、NATは、パスにありました。この情報は、バインディング受信確認のためにフラグを立てることが必要があります。
o If the F flag in the binding update is set, the home agent needs to determine whether it accepts forcing UDP encapsulation. If it does not, the binding acknowledgement is sent with error code 144. UDP encapsulation SHOULD NOT be used when the mobile node is located in an IPv6-enabled link, with the exception of the scenarios outlined in Section 4.4.1.
バインディングアップデートでFフラグが設定されている場合は、O、ホームエージェントは、UDPカプセル化を強制的に受け入れるかどうかを判断する必要があります。そうでない場合は、バインディング受信確認を移動ノードがIPv6対応リンクに位置しているとき、セクション4.4.1に概説されたシナリオを除いて、使用されるべきではないエラーコード144 UDPカプセル化して送信されます。
o If the IPv4 home address option contains a valid unicast IPv4 address, the home agent MUST check that this address is allocated to the mobile node that has the IPv6 home address included in the home address option. The same MUST be done for an IPv4 prefix.
IPv4のホームアドレスオプションが有効なユニキャストIPv4アドレスが含まれている場合は、O、ホームエージェントは、このアドレスはホームアドレスオプションに含まれたIPv6ホームアドレスを持つモバイルノードに割り当てられていることをチェックしなければなりません。同じは、IPv4プレフィックスのために行われなければなりません。
o If the IPv4 home address option contained the unspecified IPv4 address, the home agent SHOULD dynamically allocate an IPv4 home address to the mobile node. If none is available, the home agent MUST return error code 132 in the status field of the IPv4 address acknowledgement option. If a prefix is requested, the home agent SHOULD allocate a prefix with the requested length; if prefix allocation (of any length) is not possible, the home agent MUST indicate failure of the operation with the appropriate error code.
IPv4のホームアドレスオプションが指定されていないIPv4アドレスが含まれていた場合、O、ホームエージェントは、動的にモバイルノードへのIPv4ホームアドレスを割り当てる必要があります。どれも使用できない場合は、ホームエージェントは、IPv4アドレスの確認オプションのステータスフィールドにエラーコード132を返さなければなりません。接頭辞が要求された場合、ホームエージェントは、要求された長さのプレフィックスを割り当てる必要があります。 （任意の長さの）プレフィックスの割り当てができない場合、ホームエージェントは適切なエラーコードで操作が失敗したことを示さなければなりません。
o If the binding update is accepted for the IPv4 home address, the home agent creates a binding cache entry for the IPv4 home address/prefix. The home agent MUST include an IPv4 acknowledgement option in the mobility header containing the binding acknowledgement.
バインディング更新がIPv4ホームアドレスのために受理された場合、O、ホームエージェントは、IPv4ホームアドレス/プレフィックスのバインディングキャッシュエントリを作成します。ホームエージェントは、バインディング確認を含むモビリティヘッダ内のIPv4確認オプションを含まなければなりません。
o If the binding update is accepted for both IPv4 and IPv6 home addresses, the home agent creates separate binding cache entries, one for each home address. The care-of address is the one included in the binding update. If the care-of address is an IPv4 address, the home agent MUST set up a tunnel to the IPv4 care-of address of the mobile node.
バインディング更新がIPv4とIPv6の両方のホームアドレスのために受理された場合、O、ホームエージェントは、各ホームアドレスに対して1つ、別のバインディングキャッシュエントリを作成します。気付アドレスがバインディングアップデートに含まれる1つです。気付けアドレスは、IPv4アドレスの場合は、ホームエージェントは、IPv4気付モバイルノードのアドレスにトンネルを設定する必要があります。
When sending a binding acknowledgement to the mobile node, the home agent constructs the message according to [RFC3775] and [RFC3963]. Note that the routing header MUST always contain the IPv6 home address as specified in [RFC3775].
モバイルノードにバインディング確認を送信する場合、ホームエージェントは、[RFC3775]及び[RFC3963]に従ってメッセージを構築します。 [RFC3775]で指定されるようにルーティングヘッダは、IPv6ホームアドレスを常に含まなければならないことに留意されたいです。
If the care-of address of the mobile node is an IPv4 address, the home agent includes the mobile node's IPv6 home address in the destination address field in the IPv6 header. If a NAT is detected, the home agent MUST then encapsulate the packet in UDP and in an IPv4 header. The source address is set to the home agent's IPv4 address and the destination address is set to the address received in the source address of the IPv4 header encapsulating the binding update.
気付モバイルノードのアドレスがIPv4アドレスである場合、ホームエージェントは、IPv6ヘッダーの宛先アドレスフィールド内のモバイルノードのIPv6ホームアドレスを含みます。 NATが検出された場合、ホームエージェントは、UDPにし、IPv4ヘッダでパケットをカプセル化しなければなりません。送信元アドレスは、ホームエージェントのIPv4アドレスに設定され、宛先アドレスがバインディングアップデートを封入IPv4ヘッダの送信元アドレスで受信したアドレスに設定されています。
After creating a binding cache entry for the mobile node's home addresses, all packets sent to the mobile node's home addresses are tunneled by the home agent to the mobile node's care-of address. If a NAT is detected, packets are encapsulated in UDP and IPv4. Otherwise, if the care-of address is an IPv4 address and no NAT is detected, packets are encapsulated in an IPv4 header unless UDP encapsulation is forced by the home agent.
モバイルノードのホームアドレスのバインディングキャッシュエントリを作成した後、移動ノードのホームアドレスに送信されたすべてのパケットは、移動ノードの気付アドレスにホームエージェントによってトンネリングされます。 NATが検出された場合、パケットはUDPとIPv4でカプセル化されています。気付アドレスはIPv4アドレスとNATなしが検出された場合、UDPカプセル化がホームエージェントによって強制されない限り、そうでない場合、パケットはIPv4ヘッダでカプセル化されています。
The home agent follows the rules specified in [RFC3775] for sending IPv6 packets to mobile nodes located in IPv6 networks. When sending IPv4 packets to mobile nodes in an IPv6 network, the home agent must encapsulate the IPv4 packets in IPv6.
ホームエージェントは、IPv6ネットワーク内に位置する移動ノードにIPv6パケットを送信するために[RFC3775]で指定された規則に従います。 IPv6ネットワーク内の移動ノードにIPv4パケットを送信する場合、ホームエージェントは、IPv6でのIPv4パケットをカプセル化する必要があります。
When sending IPv6 packets to a mobile node located in an IPv4 network, the home agent uses the following format:
IPv4ネットワークに位置する移動ノードにIPv6パケットを送信する場合、ホームエージェントは、次の形式を使用します。
IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
IPv4ヘッダ（SRC = HA_V4ADDR、DST = V4ADDR）
[UDP header]
[UDPヘッダ]
IPv6 header (src=CN, dst= V6HoA)
IPv6ヘッダ（SRC = CN、DST = V6HoA）
Upper layer protocols
上位層プロトコル
Where the UDP header is only included if a NAT is detected between the mobile node and the home agent or if the home agent forced UDP encapsulation. V4ADDR is the IPv4 address received in the source address field of the IPv4 packet containing the binding update.
NATは、モバイルノードとホームエージェントの間、またはあれば検出された場合、UDPヘッダにのみ含まれている場合は、ホームエージェントは、UDPカプセル化を余儀なくされました。 V4ADDRはバインディングアップデートを含むIPv4パケットのソースアドレスフィールドで受信したIPv4アドレスです。
When sending IPv4 packets to a mobile node located in an IPv4 network, the home agent must follow the format negotiated in the binding update/acknowledgement exchange. In the absence of a negotiated format, the default format that MUST be supported by all implementations is:
IPv4ネットワークに位置する移動ノードにIPv4パケットを送信する場合、ホームエージェントはバインディングアップデイト/アクノリッジメント交換で交渉フォーマットに従わなければなりません。ネゴシエートされた形式の非存在下で、すべての実装によってサポートされなければならないデフォルトのフォーマットは次のとおりです。
IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
IPv4ヘッダ（SRC = HA_V4ADDR、DST = V4ADDR）
[UDP header]
[UDPヘッダ]
IPv4 header (src=V4CN, dst= V4HoA)
IPv4ヘッダ（SRC = V4CN、DST = V4HoA）
Upper layer protocols
上位層プロトコル
Where the UDP header is only included if a NAT is detected between the mobile node and home agent or if the home agent forced UDP encapsulation.
NATは、モバイルノードとホームエージェントの間、またはあれば検出された場合、UDPヘッダにのみ含まれている場合は、ホームエージェントは、UDPカプセル化を余儀なくされました。
This specification has no impact on IPv4 or IPv6 correspondent nodes.
この仕様は、IPv4またはIPv6対応のノードに影響を及ぼしません。
This specification allows a mobile node to send one binding update for its IPv6 and IPv4 home addresses. This is a slight deviation from [RFC3775], which requires one binding update per home address. However, like [RFC3775], the IPsec security association needed to authenticate the binding update is still based on the mobile node's IPv6 home address. Therefore, in order to authorize the mobile node's IPv4 home address binding, the home agent MUST store the IPv4 address corresponding to the IPv6 address that is allocated to a mobile node. Therefore, it is sufficient for the home agent to know that the IPsec verification for the packet containing the binding update was valid, provided that it knows which IPv4 home address is associated with which IPv6 home address. Hence, the security of the IPv4 home address binding is the same as the IPv6 binding.
この仕様は、モバイルノードがそのIPv6とIPv4のホームアドレスに対して1つのバインディングアップデートを送信することができます。これは、ホームアドレスごとにバインディング更新を必要とする[RFC3775]、から若干のずれです。ただし、[RFC3775]のように、バインディング更新を認証するために必要なIPsecセキュリティアソシエーションがまだモバイルノードのIPv6ホームアドレスに基づいています。したがって、結合モバイルノードのIPv4ホームアドレスを認証するために、ホームエージェントは、モバイルノードに割り当てられたIPv6アドレスに対応するIPv4アドレスを格納しなければなりません。したがって、IPv4のホームアドレスがどのIPv6のホームアドレスに関連付けられているかを知っていることを提供し、バインディングアップデートを含むパケットのIPsec検証が有効であったことを知ってホームエージェントのために十分です。したがって、結合のIPv4ホームアドレスのセキュリティはIPv6のバインディングと同じです。
In effect, associating the mobile node's IPv4 home address with its IPv6 home address moves the authorization of the binding update for the IPv4 address to the Mobile IPv6 implementation, which infers it from the fact that the mobile node has an IPv6 home address and the right credentials for sending an authentic binding update for the IPv6 address.
実際には、そのIPv6のホームアドレスとモバイルノードのIPv4ホームアドレスを関連付けることは、モバイルノードがIPv6ホームアドレスと権利を持っていることから、それを推測モバイルIPv6の実装にIPv4アドレスのためのバインディングアップデートの承認を移動しますIPv6アドレスのための本格的なバインディングアップデートを送信するための資格情報。
This specification requires the use of IKEv2 as the default mechanism for dynamic keying.
この仕様は、動的キーのデフォルトのメカニズムとしてのIKEv2を使用する必要があります。
In cases where this specification is used for NAT traversal, it is important to note that it has the same vulnerabilities associated with [RFC3519]. An attacker is able to hijack the mobile node's session with the home agent if it can modify the contents of the outer IPv4 header. The contents of the header are not authenticated and there is no way for the home agent to verify their validity. Hence, a man in the middle attack, where a change in the contents of the IPv4 header can cause a legitimate mobile node's traffic to be diverted to an illegitimate receiver independently of the authenticity of the binding update message, is possible.
この仕様は、NATトラバーサルのために使用される場合には、[RFC3519]に関連付けられた同じ脆弱性を有することに留意することが重要です。攻撃者は、それが外側のIPv4ヘッダの内容を変更することができれば、ホームエージェントとモバイルノードのセッションをハイジャックすることができます。ヘッダの内容は、認証されていないと、その有効性を検証するために、ホームエージェントのための方法はありません。したがって、IPv4ヘッダの内容に変更が正当なモバイルノードのトラフィックを引き起こす可能性が中間者攻撃は、独立して、バインディングアップデートメッセージの真正性の不正受信機に転用することが可能です。
In this specification, the binding update message MUST be protected using ESP transport mode. When the mobile node is located in an IPv4-only network, the binding update message is encapsulated in UDP as described earlier in Section 4.2. However, UDP SHOULD NOT be used to encapsulate the binding update message when the mobile node is located in an IPv6-enabled network. If protection of payload traffic is needed when the mobile node is located in an IPv4-only network, encapsulation is done using tunnel mode ESP over port 4500 as described in [RFC3948]. During the IKE negotiation with the home agent, if the mobile node and home agent support the use of port 4500, the mobile node MUST establish the security association over port 4500, regardless of the presence of a NAT. This is done to avoid switching between ports 500 and 4500 and the potential traffic disruption resulting from this switch.
本明細書では、バインディングアップデートメッセージは、ESP転送モードを使用して保護されなければなりません。移動ノードがIPv4のみのネットワーク内に位置する場合、セクション4.2で前述したように、バインディングアップデートメッセージは、UDPにカプセル化されます。しかし、UDPは、移動ノードがIPv6対応ネットワークに位置するバインディングアップデートメッセージをカプセル化するために用いるべきではありません。移動ノードがIPv4のみのネットワーク内に位置しているときにペイロードトラフィックの保護が必要な場合は、[RFC3948]に記載されているように、カプセル化は、ポート4500上ESPトンネルモードを使用して行われます。モバイルノードとホームエージェントは、ポート4500の使用をサポートしている場合、ホームエージェントとのIKEネゴシエーションの間、移動ノードは、NATの有無に関係なく、ポート4500上でセキュリティアソシエーションを確立する必要があります。これは、ポート500および4500と、このスイッチに起因する潜在的なトラフィックの中断の切り替えを避けるために行われます。
Handovers within private IPv4 networks or from IPv6 to IPv4 networks will impact the security association between the mobile node and the home agent. The following section presents the expected behaviour of the mobile node and home agent in those situations. The details of the IKE negotiations and messages are illustrated in Section 5.2.
プライベートIPv4ネットワーク内またはIPv4ネットワークへのIPv6のハンドオーバは、モバイルノードとホームエージェント間のセキュリティアソシエーションに影響を与えます。次のセクションでは、これらの状況では、モバイルノードとホームエージェントの予想される動作を示しています。 IKE交渉やメッセージの詳細は、5.2節に示されています。
After the mobile node detects movement, it configures a new care-of address. If the mobile node is in an IPv4-only network, it removes binding update list entries for correspondent nodes, since route optimisation cannot be supported. This may cause inbound packet losses, as remote correspondent nodes are unaware of such movement. To avoid confusion in the correspondent node, the mobile node SHOULD deregister its binding with each correspondent node by sending a deregistration binding update. The deregistration binding update message is tunnelled to the home agent and onto the correspondent node. This is done after the mobile node updates the home agent with its new location as discussed below.
モバイルノードが移動を検出した後、それは新しい気付アドレスを設定します。移動ノードがIPv4のみのネットワーク内にある場合、ルート最適化をサポートすることができないので、それは、コレスポンデントノードのバインディング更新リストのエントリを削除します。リモート通信員ノードは、このような動きに気づいていないので、これは、インバウンドパケットロスが発生することがあります。コレスポンデント・ノードにおける混乱を避けるために、モバイルノードは、登録解除バインディングアップデートを送信することにより、その各コレスポンデントノードとの結合の登録を解除すべきです。登録解除バインディング更新メッセージがホームエージェントにとコレスポンデントノードへトンネルされます。これは、以下に述べるように、移動ノードがその新しい場所でホームエージェントを更新した後に行われます。
The mobile node sends the binding update message to the home agent. If the mobile node is in an IPv6-enabled network, the binding update SHOULD be sent without IPv4/UDP encapsulation, unless UDP encapsulation is needed as described in Section 4.4.1. If the mobile node is in an IPv4-only network, then -- after IPsec processing of the binding update (BU) message -- it encapsulates the BU in UDP/IPv4 as discussed in Sections 4.2 and 4.4. In order to be able to send the binding update while in an IPv4-only network, the mobile node needs to use the new IPv4 care-of address in the outer header, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel within the mobile node's implementation in order to allow the mobile node to receive packets on the old care-of address until the binding acknowledgement is received. The method used to achieve this effect is implementation dependent and is outside the scope of this specification. This implies that the IP forwarding function (which selects the interface or tunnel through which a packet is sent) is not based solely on the destination address: some IPv6 packets destined to the home agent are sent via the existing tunnel, while BUs are sent using the new care-of address. Since BUs are protected by IPsec, the forwarding function cannot necessarily determine the correct treatment from the packet headers. Thus, the DSMIPv6 implementation has to attach additional information to BUs, and this information has to be preserved after IPsec processing and made available to the forwarding function or to DSMIP extensions included in the forwarding function. Depending on the mobile node's implementation, meeting this requirement may require changes to the IPsec implementation.
モバイルノードは、ホームエージェントにバインディング更新メッセージを送信します。モバイルノードは、IPv6対応のネットワーク内にある場合、セクション4.4.1に記載したようにUDPカプセル化が必要とされない限り、バインディング更新は、のIPv4 / UDPカプセル化なしで送信されるべきです。移動ノードがIPv4のみのネットワーク内にある場合は、 - バインディング更新（BU）メッセージのIPsec処理後 - セクション4.2および4.4で説明したように、それは、UDP / IPv4のBUをカプセル化します。 IPv4のみのネットワークでは、モバイルノードが気付アドレス既存のトンネルに使用される異なる外部ヘッダに新しいのIPv4気付アドレスを使用する必要がありながら、バインディング更新を送信できるようにするために。これは恒久的に結合肯定応答が受信されるまで、移動ノードが古い気付けアドレスにパケットを受信できるようにするために、モバイルノードの実装の中にトンネルを更新せずに行われる必要があります。この効果を達成するために使用される方法は実装依存であり、本明細書の範囲外です。バスが使用して送信されている間、既存のトンネルを介して送信されたホームエージェントに宛て一部IPv6パケット：これはIP転送機能を（パケットを送信するためのインターフェイスまたはトンネルを選択する）、宛先アドレスのみに基づいていないことを意味します新気付けアドレス。バスがIPSecで保護されているので、転送機能は、必ずしもパケットヘッダから正しい治療を決定することができません。したがって、DSMIPv6の実装では、バスに追加情報を添付する必要があり、この情報は、IPsec処理後に保存する必要があり、転送機能に含まれる拡張子をDSMIPする転送機能を利用可能または。モバイルノードの実装によっては、この要件を満たすことがIPsec実装への変更が必要な場合があります。
Upon receiving the binding update message encapsulated in UDP/IPv4, the home agent processes it as follows. In order to allow the DSMIPv6 implementation in the home agent to detect the presence of a NAT on the path to the mobile node, it needs to compare the outer IPv4 source address with the IPv4 address in the IPv4 care-of address option. This implies that the information in the outer header will be preserved after IPsec processing and made available to the DSMIPv6 implementation in the home agent. Depending on the home agent's implementation, meeting this requirement may require changes to the IPsec implementation.
UDP / IPv4の中に封入バインディング更新メッセージを受信すると、次のように、ホーム・エージェントは、それを処理します。モバイルノードへのパス上のNATの存在を検出するために、ホームエージェントでDSMIPv6の実装を可能にするために、それは、IPv4気付アドレスオプションでIPv4アドレスを持つ外側のIPv4ソースアドレスを比較する必要があります。これは、外部ヘッダ内の情報は、IPsec処理後に保存とホームエージェントでDSMIPv6実装に利用可能となることを意味します。ホームエージェントの実装によっては、この要件を満たすことがIPsec実装への変更が必要な場合があります。
The home agent updates its tunnel mode security association to include the mobile node's care-of address as the remote-tunnel header address and 4500 as the port number. The IPv4 address and port number are likely to be wrong; the mobile node provides the correct information in a separate exchange as described below. When the mobile node is located in a private IPv4 network (which is detected as described above), the new address and port number are allocated by the NAT. The home agent will also enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal.
ホームエージェントは、リモートトンネルヘッダアドレスとポート番号として4500としてモバイルノードの気付アドレスを含むように、そのトンネルモードのセキュリティアソシエーションを更新します。 IPv4アドレスとポート番号が間違っている可能性が高いです。以下に説明するように、モバイルノードは、別々の交換に正しい情報を提供します。モバイルノードは、（上記のように検出される）は、プライベートIPv4ネットワークに位置する場合、新しいアドレスとポート番号は、NATによって割り当てられています。ホームエージェントは、NATトラバーサルの目的のために、発信ESPパケットのUDPカプセル化を有効または無効にします。
If the Key Management Mobility Capability (K) bit was set in the binding update, and the home agent supports this feature, the home agent updates its IKE security associations to include the mobile node's care-of address as the peer address and 4500 as the port number. The home agent may also need to change NAT traversal fields in the IKE_SA to enable the dynamic update of the IP address and port number, based on the reception of authenticated IKE messages or authenticated packets using tunnel mode ESP. The dynamic updates are described in Section 2.23 of [RFC4306]. As described above, when the mobile node is located in a private IPv4 network, the address and port number used for IPsec and IKE traffic is not yet known by the home agent at this point.
キー管理モビリティ機能（K）ビットがバインディングアップデートに設定され、ホームエージェントは、この機能をサポートしていた場合、ホームエージェントは、ピアアドレスや4500などのように、移動ノードの気付アドレスが含まれるようにそのIKEセキュリティアソシエーションを更新しますポート番号。ホームエージェントはまた、トンネルモードESPを使用して認証IKEメッセージまたは認証されたパケットの受信に基づいて、IPアドレスとポート番号の動的更新を有効にするには、IKE_SAでNATトラバーサルのフィールドを変更する必要があります。動的更新は、[RFC4306]のセクション2.23に記載されています。上記のように、モバイルノードは、プライベートIPv4ネットワークに位置する場合、IPsecとIKEトラフィックに使用されるアドレスとポート番号は、まだこの時点では、ホームエージェントによって知られていません。
The mobile node updates the IKE SA in one of two ways. If the K flag was set in the binding acknowledgement message, the mobile node SHOULD send an empty informational message, which results in the IKE module in the home agent dynamically updating the SA information. The IKE implementation in the home agent is REQUIRED to support this feature. Alternatively, the IKE SA should be re-negotiated. Note that updating the IKE SA MUST take place after the mobile node has sent the binding update and received the acknowledgement from the home agent.
モバイルノードは、2つの方法のいずれかでIKE SAを更新します。 Kフラグがバインディング肯定応答メッセージに設定されている場合、モバイルノードは、動的にSA情報を更新するホームエージェントでIKEモジュールもたらす空情報メッセージを送信すべきです。ホームエージェントでのIKEの実装は、この機能をサポートするために必要です。また、IKE SAは再交渉されるべきです。モバイルノードは、バインディングアップデートを送信し、ホームエージェントからの確認を受けた後にIKE SAの更新が行われなければならないことに注意してください。
It is important to note that the mobile node's IPv4 care-of address seen by the DSMIPv6 module in the home agent upon receiving the binding update may differ from the IPv4 care-of address seen by the IKE module and the care-of address used for forwarding IPsec tunnel mode traffic. Hence, it is probable that different modules in the home agent will have a different care-of address that should be used for encapsulating traffic to the mobile node.
注意することが重要であるモバイルノードのIPv4気付IKEモジュールと気付アドレスに使用さから見たアドレスのIPv4-のケアとは異なる場合がバインディングアップデートを受信すると、ホームエージェントでDSMIPv6モジュールから見たアドレスIPsecトンネルモードのトラフィックを転送します。したがって、ホームエージェントで異なるモジュールが異なる気付アドレスモバイルノードへのトラフィックをカプセル化するために使用されなければならない必要があります可能性が高いです。
After successfully processing the binding update, the home agent sends the binding acknowledgement to the mobile node's care-of address as received in the outer header of the packet containing the binding update. Note that if the BU was rejected, the binding acknowledgement (BAck) is sent to the same address from which the BU was received. This may require special treatment in IP forwarding and/or IPsec processing that resembles the sending of BUs in the mobile node (described above).
バインディングアップデートを含むパケットの外部ヘッダで受信した正常バインディング更新を処理した後、ホームエージェントは、モバイルノードの気付アドレスにバインディング確認を送信します。 BUが拒否された場合、バインディング肯定応答（バック）BUが受信された同一のアドレスに送信されることに注意してください。これは、IP転送、および/または（上述の）モバイルノード内のバスの送信に似IPsec処理に特別な処理を必要とするかもしれません。
Upon receiving the binding acknowledgement, the mobile node updates its local tunnel mode security association information to include the tunnel header IP source address, which is the mobile node's address, and the tunnel header IP destination, which is the home agent's address. The mobile node may also need to enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal and the sending of keepalives.
バインディング確認を受信すると、モバイルノードは、ホームエージェントのアドレスである移動ノードのアドレスであるトンネルヘッダIPソースアドレス、トンネルヘッダIP宛先を含むようにそのローカルトンネルモードのセキュリティアソシエーション情報を更新します。モバイルノードは、NATトラバーサルのために、発信ESPパケットのUDPカプセル化を有効または無効にする必要があり、キープアライブを送信します。
The mobile node MAY use MOBIKE [RFC4555] to update its IKE SA with the home agent. Using MOBIKE requires negotiating this capability with the home agent when establishing the SA. In this case, the mobile node and the home agent MUST NOT update their IPsec SAs locally, as this step is performed by MOBIKE. Furthermore, the use of MOBIKE allows the mobile node to update the SA independently of the binding update exchange. Hence, there is no need for the mobile node to wait for a binding acknowledgement before performing MOBIKE. The use of MOBIKE is OPTIONAL in this specification.
モバイルノードは、ホームエージェントとのIKE SAを更新するためにMOBIKE [RFC4555]を使用するかもしれません。 MOBIKEを使用すると、SAを確立する際にホームエージェントにこの能力を交渉が必要です。このステップは、MOBIKEによって行われるように、この場合、移動ノードとホームエージェントは、ローカルに自分のIPsec SAを更新してはなりません。さらに、MOBIKEを使用すると、モバイルノードは、独立して、バインディング更新の交換のSAを更新することを可能にします。したがって、MOBIKEを実行する前に、バインディング確認応答を待つために、移動ノードのための必要はありません。 MOBIKEの使用は、この仕様ではオプションです。
This specification defines a number of possible data encapsulation formats, depending on the mobile node's connectivity to the visited network. When connected to an IPv6-enabled network, the tunnelling formats are clear. However, when connected to an IPv4-only network, care should be taken when negotiating the IKE association and the consequential tunnelling formats used for secure and insecure traffic. This section illustrates the IKE message exchange between the mobile node and home agent when the mobile node is located in an IPv4-only network. Two different IKE negotiations are considered:
この仕様は、訪問先ネットワークへのモバイルノードの接続性に応じて、可能なデータのカプセル化フォーマットの数を定義します。 IPv6対応のネットワークに接続すると、トンネリングフォーマットは明確です。 IPv4のみのネットワークに接続されている場合、IKEの関連付けと安全かつ安全でないトラフィックに使用必然トンネリングフォーマットをネゴシエートするときしかし、注意しなければなりません。このセクションでは、移動ノードがIPv4のみのネットワークに配置されているモバイルノードとホームエージェントとの間のIKEメッセージ交換を示します。二つの異なるIKEネゴシエーションが考慮されています。
o IKEv2 operation for securing DSMIPv6 signaling.
DSMIPv6シグナル伝達を確保するためのOのIKEv2操作。
o IKEv2 operation for securing data over IPv4
IPv4の上でデータを保護するためのIKEv2 O操作
A mobile node connected to an IPv4-only network SHOULD follow the procedures described below in order to establish an SA for the protection of binding update and binding acknowledgement messages. Note that V4ADDR refers to either the mobile node's care-of address in the visited link or the public address allocated to the mobile node by the NAT.
IPv4のみのネットワークに接続されたモバイルノードは、バインディングアップデート肯定応答メッセージを結合の保護のためにSAを確立するために、以下の手順に従うべきです。 V4ADDRは、モバイルノードの訪問済みリンクのアドレスのケア、またはNATにより、モバイルノードに割り当てられたパブリックアドレスのいずれかを意味することに注意してください。
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (500, 500) HDR, SAi1, KEi, Ni
NAT-D, NAT-D -->
<- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
NAT-D, NAT-D
IPv4(source_addr=V4ADDR, dest_addr=HAADDR) UDP (4500,4500) <non-ESP Marker > HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), SAi2, TSi, TSr} -->
IPv4の（SOURCE_ADDR = V4ADDR、dest_addrは= HAADDR）UDP（4500,4500）<非ESPマーカー> HDR、SK {IDI、[CERT、] [CERTREQ、] [IDR、】AUTH、N（USE_TRANSPORT_MODE）、SAI2、をTSi TSR} - >
<-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) <non-ESP Marker > HDR, SK
{IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
SAr2, TSi, TSr}
The corresponding Security Policy Database (SPD) entries are shown below.
対応するセキュリティポリシーデータベース（SPD）エントリを以下に示します。
Mobile node SPD-S:
モバイルノードSPD-S：
IF local_address = home_address_1 &
IF local_address = home_address_1＆
remote_address = home_agent_1 &
REMOTE_ADDRESS = home_agent_1＆
proto = MH & local_mh_type = BU &
プロト= MH＆local_mh_type = BU＆
remote_mh_type = BAck
remote_mh_type =のBAck
Then use SA ESP transport mode
そして、SA ESPトランスポートモードを使用します
Initiate using IDi = user_1 to address home_agent_1
home_agent_1に対処するためにIDiと= USER_1を使用して開始
Home Agent SPD-S:
ホームエージェントSPD-S：
IF local_address = home_agent_1 &
IF local_address = home_agent_1＆
remote_address = home_address_1 &
REMOTE_ADDRESS = home_address_1＆
proto = MH &
したがって= MH＆
local_mh_type = BAck &
local_mh_type =バック＆
remote_mh_type = BU
remote_mh_type = BU
Then use SA ESP transport mode
そして、SA ESPトランスポートモードを使用します
Where home_address_1 is the mobile node's registered IPv6 home address and home_agent_1 is the IP address of the home agent.
home_address_1は、モバイルノードの登録のIPv6ホームアドレスがあるとhome_agent_1は、ホームエージェントのIPアドレスです。
The above should result in BU/BA messages with the following BU received by the home agent:
上記ホームエージェントが受信し、次のBUでBU / BAメッセージが表示されるはずです。
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
IPv4ヘッダ（SRC = V4ADDR、DST = HA_V4ADDR）
UDP header (sport=Z, dport=DSMIPv6)
UDPヘッダ（スポーツ= Z、DPORT = DSMIPv6）
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6ヘッダ（SRC = V6HOA、DST = HAADDR）
ESP header in transport mode
トランスポート・モードでESPヘッダ
Mobility header
モビリティヘッダ
BU [IPv4 HAO]
B U [IP V4 HA O]
IPv4 CoA option
IPv4のCoAオプション
(and others as needed)
（その他必要に応じて）
At the home agent, following UDP de-capsulation, the binding update is delivered to the IPsec module as shown below:
以下に示すように、ホームエージェントでは、UDPデカプセル以下、バインディングアップデートは、IPsecモジュールに配信されます。
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6ヘッダ（SRC = V6HOA、DST = HAADDR）
ESP header in transport mode
トランスポート・モードでESPヘッダ
Mobility header
モビリティヘッダ
BU [IPv4 HAO]
B U [IP V4 HA O]
IPv4 CoA option
IPv4のCoAオプション
(and others as needed)
（その他必要に応じて）
In addition, V4ADDR and the sport (Z) need to be passed with the packet to ensure correct processing.
また、V4ADDR及びスポーツ（Z）が正しい処理を確実にするために、パケットに渡される必要があります。
Following IPsec processing, the binding update is delivered to the DSMIPv6 home agent module as follows:
次のようにIPsec処理に続いて、バインディングアップデートは、DSMIPv6ホームエージェントモジュールに配信されます。
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6ヘッダ（SRC = V6HOA、DST = HAADDR）
Mobility header
モビリティヘッダ
BU [IPv4 HAO]
B U [IP V4 HA O]
IPv4 CoA option
IPv4のCoAオプション
(and others as needed)
（その他必要に応じて）
In addition, V4ADDR and the sport (Z) need to be passed with the packet to ensure correct processing.
また、V4ADDR及びスポーツ（Z）が正しい処理を確実にするために、パケットに渡される必要があります。
The binding acknowledgement sent by the home agent module to the IPsec module is as follows:
次のようにIPsecモジュールにホームエージェントモジュールによって送信されたバインディング確認は次のとおりです。
IPv6 header (src=HAADDR, dst=V6HOA)
IPv6ヘッダ（SRC = HAADDR、DST = V6HOA）
Mobility header
モビリティヘッダ
BA ([IPv4 ACK], NAT DET)
BA（[IPv4のACK]、NAT）
(and others as needed)
（その他必要に応じて）
In addition, V4ADDR, the sport from the BU (Z), and an indication that UDP encapsulation must be used need to be passed with the packet to ensure correct processing.
また、V4ADDR、BU（Z）からスポーツ、およびUDPカプセル化が正しい処理を確実にするために、パケットに渡される必要が使用されなければならないことを示します。
The binding acknowledgement sent by the home agent to the mobile node is as follows:
次のようにモバイルノードにホームエージェントによって送信されたバインディング確認は次のとおりです。
IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
IPv4ヘッダ（SRC = HA_V4ADDR、DST = V4ADDR）
UDP header (sport=DSMIPv6, dport=Z)
UDPヘッダ（スポーツ= DSMIPv6、DPORT = Z）
IPv6 header (src=HAADDR, dst=V6HOA)
IPv6ヘッダ（SRC = HAADDR、DST = V6HOA）
ESP header in transport mode
トランスポート・モードでESPヘッダ
Mobility header
モビリティヘッダ
BA ([IPv4 ACK], NAT DET)
BA（[IPv4のACK]、NAT）
To secure data traffic when the mobile node is located in an IPv4- only network, the mobile node MUST establish a child_SA for that purpose. Note that V4ADDR refers to either the mobile node's care-of address in the visited link or the public address allocated to the mobile node by the NAT. The procedure is as follows:
モバイルノードがIPv4-のみネットワークに配置されたデータトラフィックを保護するために、モバイルノードは、その目的のためのCHILD_SAを確立する必要があります。 V4ADDRは、モバイルノードの訪問済みリンクのアドレスのケア、またはNATにより、モバイルノードに割り当てられたパブリックアドレスのいずれかを意味することに注意してください。手順は以下の通りです。
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) < non-ESP Marker > HDR, SK
{[N], SA, Ni, [KEi], TSi, TSr} -->
<--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) < non-ESP Marker > HDR, SK
SA, Nr, [KEr], TSi, TSr}
If no NAT is detected, the encapsulation used will be:
何NATが検出されない場合、使用されるカプセル化は次のようになります。
IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
IPv4の（SOURCE_ADDR = v4CoA、dest_addrは= HAAddr）
ESP
ESP
IP (source_addr=HoA, set_addr=CNAddr)
IP（SOURCE_ADDR = HoAと、set_addr = CNAddr）
Upper_layer_HDR
Upper_layer_HDR
Where IP is either IPv4 or IPv6 and HoA is either the IPv4 HoA or the IPv6 HoA.
どこIPはIPv4またはIPv6とのHoAは、IPv4またはIPv6 HoAをHoAでどちらかのいずれかです。
If a NAT is detected, the encapsulation used will be:
NATが検出された場合、使用されるカプセル化は次のようになります。
IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
IPv4の（SOURCE_ADDR = V4ADDR、dest_addrは= HAAddr）
UDP (sport=Y, dport=4500)
UDP（スポーツ= Y、DPORT = 4500）
ESP
ESP
IP (source_addr=HoA, set_addr=CNAddr)
IP（SOURCE_ADDR = HoAと、set_addr = CNAddr）
Upper_layer_HDR
Upper_layer_HDR
Where v4CoA may be the external IPv4 address of the NAT, IP is either an IPv4 or IPv6 header, and HoA is either the IPv4 or the IPv6 HoA. The above format shows the packet as seen by the home agent.
v4CoAがNATの外部IPv4アドレスであってもよい場合、IPは、IPv4またはIPv6ヘッダのいずれかであり、そしてHoAがIPv4またはIPv6のHoAのいずれかです。上記の形式は、ホームエージェントで見られるようなパケットを示しています。
The SPD, whether a NAT is detected or not, is set as follows. Note that this rule is designed to match all data from the MN to nodes other than the home agent. This is done so that this rule does not overlap with the earlier rule securing BU/BA signaling between the MN and the HA.
次のようにSPDは、NATが検出されたか否かを、設定されています。このルールは、ホームエージェント以外のノードにMNからのすべてのデータを一致させるように設計されていることに注意してください。このルールは、MNとHAの間のBU / BAシグナル伝達を確保する以前のルールと重複しないように行われます。
Mobile Node SPD-S:
モバイルノードSPD-S：
IF local_address = home_address &
IF local_address = home_address＆
remote_address != home_agent &
REMOTE_ADDRESS！= home_agent＆
proto=any
プロト=任意の
Then use SA ESP tunnel mode
そして、SA ESPトンネルモードを使用します
Initiate using IDi = user_1 to address home_agent_1
home_agent_1に対処するためにIDiと= USER_1を使用して開始
home agent SPD-S:
ホームエージェントSPD-S：
IF local_address != home_agent &
local_address！= home_agent＆IF
remote_address = home_address &
REMOTE_ADDRESS = home_address＆
proto=any
プロト=任意の
Then use SA ESP tunnel mode
そして、SA ESPトンネルモードを使用します
Where home_address is the MN's registered IPv6 or IPv4 home address and home_agent is the IPv6 or the IPv4 address of the home agent.
home_address MNの登録のIPv6またはIPv4ホームアドレスとhome_agentは、ホームエージェントのIPv4またはIPv6アドレスですされている場合。
NATKATIMEOUT = 110 seconds.
NATKATIMEOUT = 110秒。
Thanks to the following members (in alphabetical order) of the MIP6 and NEMO Working Groups for their contributions, discussions, and reviews: Jari Arkko, Sri Gundavelli, Wassim Haddad, Alfred Hoenes, Conny Larsson, Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen, and Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen, and Christian Kaas-Petersen for raising the issue of IKEv2 interactions and proposing the solution included in this document. Thanks to Pasi Eronen for many thorough reviews of this document.
彼らの貢献、議論、およびレビューのためのMIP6とNEMOワーキンググループのメンバーは以下のとおり（アルファベット順）に感謝：ヤリArkko、スリGundavelli、ワッシムハダッド、アルフレッドHoenes、コニーラーション、ACEE Lindem、アフマドMuhanna、Vidyaナラヤナン、カレン・ニールセン、圭一志摩。 IKEv2の相互作用の問題を提起し、解決策を提案するためのカレン・ニールセン、パシEronen、およびキリスト教のカース・ピーターセンのおかげで、この文書に含まれています。このドキュメントの多くの徹底的なレビューのためのパシEronenに感謝します。
IANA has made the following allocations according to this specification:
IANAは、この仕様に応じて、次の割り当てを行っています。
A UDP port (4191) has been assigned for the NAT traversal mechanism described in Section 4.2.
UDPポート（4191）は、セクション4.2に記載のNATトラバーサル機構に割り当てられています。
The IPv4 home address option described in Section 3.1.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775].
3.1.1項で説明したIPv4ホームアドレスオプションは、このオプションは[RFC3775]で説明モビリティヘッダに含まれている値29が割り当てられています。
The IPv4 address acknowledgement option described in Section 3.2.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775].
セクション3.2.1に記載のIPv4アドレス確認オプションは、このオプションは[RFC3775]で説明モビリティヘッダに含まれている値29が割り当てられています。
The NAT detection option described in Section 3.2.2 has been assigned a value 31. This option is included in the mobility header described in [RFC3775].
セクション3.2.2に記載NAT検出オプションは、このオプションは[RFC3775]で説明モビリティヘッダに含まれている値31が割り当てられています。
The IPv4 care-of address option described in Section 3.1.2 has been assigned value 32. This option is included in the mobility header described in [RFC3775].
IPv4気付アドレスオプションセクション3.1.2で説明このオプションは、[RFC3775]で説明モビリティヘッダに含まれている値32が割り当てられています。
The status field in the IPv4 home address option has been allocated by IANA under the new registry: "DSMIPv6 IPv4 Home Address Option Status Codes".
「DSMIPv6のIPv4ホームアドレスオプションのステータス・コード」：IPv4のホームアドレスオプションのステータス・フィールドは、新しいレジストリの下でIANAによって割り当てられています。
The status field values are allocated using the following procedure:
ステータスフィールドの値は、次の手順を使用して割り当てられます。
1. New status field values are allocated through IETF review. This is for all RFC types including standards track, informational, and experimental status that originate from the IETF and have been approved by the IESG for publication.
1.新しいステータスフィールドの値がIETFレビューを通じて割り当てられています。これは、標準化トラック、情報、およびIETFに由来し、公表のためにIESGによって承認されている実験的なステータスなど、すべてのRFCタイプのためです。
2. Requests for new option type value assignments from outside the IETF are only made through the publication of an IETF document, per 1 above. Note also that documents published as Independent "RFC Editor contributions" [RFC4844] are not considered to be IETF documents.
IETF外部から新しいオプションタイプ値の割り当て2.リクエストは、上記1あたり、IETF文書の公開を介して行われます。注また、独立した「RFCエディタ貢献」として公表された文書[RFC4844]はIETFのドキュメントと見なされていないこと。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、カールソン、J.、およびS.チェシャー、 "IPv4の（DNAv4）で検出ネットワーク接続"、RFC 4436、2006年3月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026] Giaretta、G.、エド。、ケンプ、J.、およびV. Devarapalli、エド。、 "分割シナリオにおけるモバイルIPv6ブートストラップ"、RFC 5026、2007年10月。
[CHOWDHURY] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[CHOWDHURY]チョードリー、K.とA. Yegin、 "統合シナリオのためのMIP6-ブートストラップ"、進歩、2008年4月の作業。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
、RFC 3519、2003年4月、 "ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル" [RFC3519] Levkowetz、H.とS. Vaarala、。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]、RFC 4459 Savola、P.、 "イン・ネットワークのトンネリングを使用したMTUと断片化の問題"、2006年4月。
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844] Daigle氏、L.、エド。、およびインターネットアーキテクチャ委員会、 "RFCシリーズとRFCエディタ"、RFC 4844、2007年7月。
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual Stack Mobility", RFC 4977, August 2007.
[RFC4977] Tsirtsis、G.およびH.ソリマン、 "問題文：デュアルスタックモビリティ"、RFC 4977、2007年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]ソリマン、H.、カステルッシア、C.、ElMalki、K.、およびL. Bellier、 "階層モバイルIPv6（HMIPv6の）モビリティ・マネジメント"、RFC 5380、2008年10月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのユニキャストUDPの使用上の注意事項"、BCP 145、RFC 5405、2008年11月。
This document reflects discussions and contributions from several people including (in alphabetical order):
この文書は、（アルファベット順）を含むいくつかの人々からの議論と貢献を反映しています：
Vijay Devarapalli: vijay.devarapalli@azairenet.com
ビジェイのdevarapalli：విజయ్.దేవరపల్లి@అజయరెన్ట్.కం
James Kempf: kempf@docomolabs-usa.com
ジェームズ・ケンプ：kempf@docomolabs-usa.com
Henrik Levkowetz: henrik@levkowetz.com
ヘンリクLevkowetz：henrik@levkowetz.com
Pascal Thubert: pthubert@cisco.com
パスカルThubert：pthubert@cisco.com
George Tsirtsis: G.Tsirtsis@Qualcomm.com
ジョージTsirtsis：G.Tsirtsis@Qualcomm.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
りゅじ わきかわ： りゅじ＠ｓｆｃ。うぃで。あｄ。ｊｐ
Author's Address
著者のアドレス
Hesham Soliman (editor) Elevate Technologies
ヒシャムスレイマン（強制）テクノロジーズ害虫
EMail: hesham@elevatemobile.com
メールアドレス：hesham@elevatemobile.com