[要約] 要約：RFC 5555は、デュアルスタックホストとルーターのためのモバイルIPv6サポートに関する規格です。IPv6ネットワークでのモバイル通信をサポートするための手順と要件が定義されています。目的：このRFCの目的は、デュアルスタック環境でのモバイルIPv6通信を可能にするための標準化とガイドラインを提供することです。これにより、ユーザーはIPv6ネットワーク上でのモバイル通信をスムーズに行うことができます。
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
デュアルスタックホストとルーターのモバイルIPv6サポート
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
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パケットと、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.
この仕様を使用して、モバイルノードは、インターネット内で移動しながらモビリティを管理するためにモバイルIPv6と[RFC3963]のみを必要とするため、2つのモビリティ管理プロトコルを同時に実行する必要性を排除します。この仕様は、デュアルスタックモバイルノードが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つの例外を除いて、特定のタイプのホストとルーターサポートを拡張していません。（ii）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 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.
この仕様では、バインディングの更新および拘束力のある確認用に拡張機能が定義されています。これらのすべての拡張機能は、[RFC5380]で定義されているように、モバイルノードがモビリティアンカーポイント（MAP）と通信する場合に適用されることに注意する必要があります。マップ上の要件は、ホームエージェントに記載されている要件と同じです。ただし、同じアドレスドメインにあると予想されるため、MAPでNATトラバーサルが必要になる可能性は低いです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
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が提供する大きなアドレススペースの利点の1つは、モバイルノードがどこにいてもグローバルにユニークなケアオブアドレスを取得できることです。したがって、モバイルIPv4向けに設計されたネットワークアドレス翻訳者（NAT）トラバーサル技術は必要ありません。これにより、モバイルIPv6は大幅に単純で帯域幅効率の高いモビリティ管理プロトコルになります。同時に、IPv6への移行中に、既存のプライベートIPv4ネットワークのNATトラバーサルを考慮する必要があります。この仕様では、この目的のためにNAT Traversalを導入します。
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 Care-of Addressのみを構成できます。
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の問題を強調し、NATのパブリックIPアドレスを含む32ビットフィールドを書き換えることに注意する必要があります。この仕様はそのような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]に示すように）、このシナリオはモバイルIPv6にIPv4ホームアドレスをサポートする要件を追加します。
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 Care of Addressを使用することを好む必要があります。[RFC3775]で説明されているように、このシナリオでは、通常のIP-in-IPトンネルを使用する必要があります。まれな例外では、IPv6のIP-in-IPトンネルがモバイルノードがホームエージェントに到達することを許可しない場合、モバイルノードはセクション4.4.1で説明されている送信アルゴリズムに従います。IPv6ネットワークのUDPトンネルは、通常のIP-in-IPトンネリングで到達可能性を達成できない場合に、このドキュメントで最終リゾートメカニズムとして提案されています。通常の動作モードと見なされるべきではなく、最初のリゾートとして使用しないでください。
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]で定義されており、モバイルノードがホームリンクのプレフィックスによく知られているAnycastインターフェイス識別子を追加することにより、ホームエージェントを発見できるようにします。ただし、このメカニズムはIPv6-AnyCastルーティングに基づいています。モバイルノード（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を設定された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」である場合、モバイルノードはQNAMEセットを「_mip6._ipv6.example.com」にdnsリクエストを送信する必要があります。応答には、ホームエージェントのFQDN（S）が含まれている必要があり、対応する「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（つまり、IPv4のIPv6）にカプセル化された勧誘メッセージメッセージを送信する場合があります。これらのメッセージを保護するには、[RFC3775]および[RFC4877]で説明されているように、モバイルノードがIPSECを使用し、モバイルノードのIPv4ケアオブアドレスに基づいてホームエージェントとセキュリティ関連を持つ必要があります。
[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ホームアドレスオプションが含まれる場合があります。バインディングアップデートを受信した後、ホームエージェントは2つのバインディングキャッシュエントリを作成します。1つはモバイルノードのIPv4ホームアドレス用、もう1つはモバイルノードのIPv6ホームアドレス用です。両方のエントリは、モバイルノードのIPv6ケアオブアドレスを指します。したがって、パケットがモバイルノードのIPv4またはIPv6ホームアドレスにアドレス指定されるたびに、ホームエージェントは、バインディングアップデートに含まれるモバイルノードのIPv6ケアオブアドレスにIPv6でトンネルします。事実上、モバイルノードは2つの異なるトンネルを確立します。1つはIPv4トラフィック（IPv6のIPv4）と1つはIPv6トラフィック（IPv6のIPv6）用です。
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-in-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 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.
バインディングアップデートを受け入れ、対応するバインディングキャッシュエントリを作成した後、ホームエージェントは[RFC3775]で定義されているように、モバイルノードにバインディング確認を送信する必要があります。さらに、バインディングアップデートにIPv4ホームアドレスオプションが含まれている場合、拘束力のある確認には、セクション3.2.1で説明されているIPv4アドレス確認オプションを含める必要があります。このオプションは、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 Care-of Addressオプションで表されます。モバイルノードに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 Care of Addressを指す必要があります。したがって、モバイルノードのホームアドレス（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 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.
バインディングの更新を受け入れ、対応するエントリを作成した後、ホームエージェントは[RFC3775]で指定されているように拘束力のある承認を送信する必要があります。さらに、バインディングアップデートにIPv4ホームアドレスオプションが含まれている場合、拘束力のある確認には、セクション3.2.1で説明されているIPv4アドレス確認オプションを含める必要があります。バインディングの確認は、バインディングアップデートをカプセル化するIPv4ヘッダーのソースアドレスフィールドに含まれていたIPv4 Care of Addressにカプセル化されています。
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 Care-を含む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アドレス確認オプションを含める必要があります。バインディングの確認は、UDPでカプセル化され、IPv4では、ホームエージェントのIPv4アドレスがソースアドレスフィールドに、宛先フィールドにモバイルノードのIPv4ケアオブアドレスを使用してカプセル化されます。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.
[RFC3775]で指定されているルート最適化は、モバイルノードにIPv6アドレスを提供する訪問ネットワークに配置され、IPv6対応の特派員ノードと通信しながら、デュアルスタックモバイルノードと同じ方法で動作します。ただし、IPv4のみのネットワークに配置されている場合、またはIPv4ホームアドレスを使用してIPv4特派員ノードと通信する場合、Returnable-Routabilityテストを実行するのが難しいため、ルート最適化は不可能です。この仕様では、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アドレス確認オプションに含める必要があります。この場合、バインディングの寿命は、IPv6結合の寿命の最小値とIPv4ホームアドレスのリース時間に拘束されます。
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
29
Length
長さ
6
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.
モバイルノードに割り当てられたプレフィックスの長さ。単一のアドレスのみが割り当てられている場合、このフィールドは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つはアドレス（静的または動的）を要求するために2つの異なるオプションを使用し、もう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
32
Length
長さ
6
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カプセル化を使用する必要がある場合、モバイルノードによって設定される場合があります。このフラグは、セクション4.4.1に記載されているシナリオを除き、モバイルノードがIPv6ケアオブアドレスで構成されている場合は設定しないでください。
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
30
Length
長さ
6
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
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
o 130 IPv4ホームアドレスが誤っていません
o 131 Invalid IPv4 address o 132 Dynamic IPv4 home address assignment not available
o 131無効なIPv4アドレスo 132動的IPv4ホームアドレスの割り当ては利用できません
o 133 Prefix allocation unauthorized
o 133プレフィックス割り当ては許可されていません
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バインドリフレッシュタイムも含まれる場合があります。これは、モバイルノードがホームエージェントの管理ドメイン内で移動していることが知られているシナリオに役立つ可能性があります。[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
31
Length
長さ
6
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カプセル化を使用する必要があることを示しています。このフラグは、モバイルノードにIPv6のケアオブアドレスが割り当てられている場合は設定しないでください。セクション4.4.1で説明したシナリオに対応することを除きます。
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].
この仕様により、モバイルノードは、その場所と訪問されたネットワークの機能に応じて、さまざまなトンネル形式を使用できます。モバイルノードは、IPv4でIPv6、IPv6のIPv4をトンネルするか、UDPカプセル化を使用してIPv4でIPv6をトンネルします。当然のことながら、この仕様はIPv6 [RFC2473]のトンネリングIPv6もサポートしています。
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ベースのトンネルをモバイルノードとそのホームエージェントまたはマップ間で使用できます。UDPカプセル化形式は、次のヘッダーの順序を意味します。
IPv4/v6
IPv4/V6
UDP
UDP
IP (v4 or v6)
IPv4または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.
この形式を使用する場合、レシーバーはUDPヘッダーに続くバージョンフィールドを解析して、次のヘッダーがIPv4またはIPv6であるかどうかを判断します。残りのヘッダーは正常に処理されます。上記のヘッダーは、パケットのさまざまな部分に配置される可能性があるため、IPSECヘッダーを考慮しません。上記の形式は、この仕様のすべての実装によってサポートされる必要があり、バインディングアップデートメッセージの送信には常に使用する必要があります。
UDP tunnelling can also encapsulate an Encapsulating Security Payload (ESP) header as shown below:
UDPトンネリングは、以下に示すように、カプセル化セキュリティペイロード（ESP）ヘッダーをカプセル化することもできます。
IPv4/v6
IPv4/V6
UDP
UDP
ESP
特に
IP (v4 or v6)
IPv4または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トンネルの受信機は、使用されるUDPポートに基づいてESPヘッダーが存在するかどうかを検出します。
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 Discovery（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カプセル化を使用する場合、IP-in-IPカプセル化が使用される場合と同じ方法で、ライブ（TTL）フィールドを減らす必要があることに注意してください。
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は、IKEV2を使用して、モバイルノードとホームエージェントの間にIPSECセキュリティ協会（SA）を確立します。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 Care-ofアドレスオプションに比較します。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]
bu [ipv4 hao]
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) ESP header
IPv6ヘッダー（src = haaddr、dst = v6hoa）espヘッダー
Mobility header
モビリティヘッダー
BA ([IPv4 ACK], NAT DET)
BA（[IPv4 Ack]、Nat Det）
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アドレス確認オプションです。これは、IPv4ホームアドレスオプションがBUに存在する場合にのみ含まれています。NAT DETはNAT検出オプションであり、バインディングアップデートがUDPにカプセル化されている場合、バインディング確認メッセージに存在する必要があります。
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.
KeepAlivesは、UDPポート4500を介してIKEV2によっても必要であることに注意してください。これは、DSMIPV6 KeepAlivesによって処理されないIKE（Internet Key Exchange Protocol）Dead-Peer検出に必要です。
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のケアオブアドレスを好み、自宅の住所（ES）にバインドする必要があります。モバイルノードがIPv6のケアオブアドレスを自宅の住所（ES）にバインドしようとし、バインディングアップデートがタイムアウトしようとした場合、モバイルノードは次のとおりです。
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.
o 3回の試行の後、合計で拘束力のある承認が受信されなかった場合、モバイルノードはIPv4 Care of Addressを使用して新しいバインディングアップデートを送信する必要があります。[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 Care-of AddressとIP-in-IPカプセル化を使用する場合、モバイルノードの実装が永続的なパケット損失の上層層によって認識される場合、Fフラグセットでバインディングアップデートを再送信しようとする場合があり、UDPカプセルのリクエストを要求する場合があります。すべてのパケット。これにより、ローカルファイアウォールポリシーがIP-in-IPカプセル化の使用を妨げる状況によるパケット損失を回避する場合があります。
The effect of this address selection mechanism is to allow the following preferences in the absence of NAT:
このアドレス選択メカニズムの効果は、NATの非存在下で次の好みを可能にすることです。
1. IPv6
1. IPv6
2. IPv4 (using IP-in-IP or UDP encapsulation if a NAT is detected)
2. IPv4（NATが検出された場合のIP-in-IPまたはUDPカプセル化を使用）
3. UDP encapsulation when IP-in-IP is not allowed by the local domain.
3. IP-in-IPがローカルドメインによって許可されていない場合の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プレフィックスのリクエスト（つまり、Pフラグセット）に1つ以上のIPv4ホームアドレスオプションを含めることができます。
o If the mobile node wishes to use UDP encapsulation only, it must set the F flag in the binding update message.
o モバイルノードがUDPカプセル化のみを使用したい場合は、バインディングアップデートメッセージに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ホームアドレスがある場合、または必要な場合、モビリティヘッダーに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.
o ステータスフィールドがエラーコード144で障害を示した場合、モバイルノードは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.
o モビリティヘッダーが成功を示すIPv4アドレス確認オプションを含む場合、モバイルノードはバインディングアップデートリストに2つのエントリを作成する必要があります。1つはIPv6ホームアドレス用、もう1つはIPv4ホームアドレス用です。
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の将来のパケットをトンネルする必要があります。これは、バインディングアップデートリストに示す必要があります。
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.
o IPv4アドレスの確認オプションが存在しない場合、およびIPv4ホームアドレスオプションがバインディングアップデートに存在する場合、モバイルノードは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.
o IPv4アドレス確認オプションが存在し、IPv4ホームアドレスバインディングの障害を示す場合、モバイルノードはバインディングアップデートリストにそのアドレスのエントリを作成してはなりません。モバイルノードには、将来のバインディングアップデートに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.
このバインディングアップデートを受信すると、ホームエージェントは既存のキャッシュエントリを新しいメッセージのコンテンツに置き換えます。これにより、IPv4バインディングを維持しながら、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.
ここでは、UDPヘッダーは、モバイルノードとホームエージェント間でNATが検出された場合のみ、またはホームエージェントがUDPのカプセル化を強制した場合にのみ使用されます。V4COAは、訪問されたネットワークのモバイルノードによって構成されたIPv4 Care-of Addressです。
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.
ここでは、UDPヘッダーは、モバイルノードとホームエージェント間でNATが検出された場合のみ、またはホームエージェントが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]のすべての手順に従う必要があります。さらに、次のチェックを実行する必要があります。OIPv4COAオプションのIPv4ケアアドレスがIPv4ヘッダーのソースアドレスのIPv4アドレスと同じでない場合、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.
o バインディングアップデートのFフラグが設定されている場合、ホームエージェントは、UDPのカプセル化の強制を受け入れるかどうかを判断する必要があります。そうでない場合、バインディングの確認はエラーコード144で送信されます。UDPカプセル化は、セクション4.4.1で概説されているシナリオを除き、モバイルノードをIPv6対応リンクに配置している場合は使用しないでください。
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.
o IPv4ホームアドレスオプションに有効なユニキャストIPv4アドレスが含まれている場合、ホームエージェントは、このアドレスがホームアドレスオプションに含まれている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.
o IPv4ホームアドレスオプションに不特定のIPv4アドレスが含まれている場合、ホームエージェントはモバイルノードに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.
o IPv4ホームアドレスのバインディングアップデートが受け入れられた場合、ホームエージェントは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.
o IPv4とIPv6のホームアドレスの両方に対してバインディングアップデートが受け入れられている場合、ホームエージェントは、各ホームアドレスに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でカプセル化されます。それ以外の場合、Care of Addressが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.
ホームエージェントは、[RFC3775]で指定されたルールに従い、IPv6ネットワークにあるモバイルノードにIPv6パケットを送信します。IPv6ネットワークのモバイルノードにIPv4パケットを送信する場合、ホームエージェントはIPv6のIPv4パケットをカプセル化する必要があります。
When sending IPv6 packets to a mobile node located in an IPv4 network, the home agent uses the following format:
IPv6ネットワークにあるモバイルノードに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.
UDPヘッダーは、モバイルノードとホームエージェント間でNATが検出された場合、またはホームエージェントが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.
UDPヘッダーは、モバイルノードとホームエージェントの間でNATが検出された場合、またはホームエージェントが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]からのわずかな逸脱であり、自宅の住所ごとに1つのバインディングアップデートが必要です。ただし、[RFC3775]と同様に、バインディングアップデートを認証するために必要なIPSECセキュリティ協会は、モバイルノードのIPv6ホームアドレスに基づいています。したがって、モバイルノードのIPv4ホームアドレスバインディングを承認するために、ホームエージェントはモバイルノードに割り当てられたIPv6アドレスに対応するIPv4アドレスを保存する必要があります。したがって、ホームエージェントが、バインディングアップデートを含むパケットの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.
実際には、モバイルノードのIPv4ホームアドレスをIPv6ホームアドレスに関連付けると、IPv4アドレスのバインディングアップデートの承認がモバイルIPv6実装に移動します。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にカプセル化されます。ただし、モバイルノードがIPv6対応ネットワークに配置されている場合、UDPをバインディングアップデートメッセージをカプセル化するために使用しないでください。モバイルノードがIPv4のみのネットワークにあるときにペイロードトラフィックの保護が必要な場合、[RFC3948]で説明されているように、ポート4500を介してトンネルモードESPを使用してカプセル化が行われます。ホームエージェントとのIKE交渉中、モバイルノードとホームエージェントがポート4500の使用をサポートする場合、モバイルノードは、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ネットワーク内またはIPv6からIPv4ネットワークへの携帯電話は、モバイルノードとホームエージェントの間のセキュリティ関連に影響を与えます。次のセクションでは、これらの状況でのモバイルノードとホームエージェントの予想される動作を示します。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のみのネットワークにある場合、ルートの最適化をサポートできないため、特派員ノードのバインディングアップデートリストエントリを削除します。これは、リモート特派員ノードがそのような動きを認識していないため、インバウンドパケット損失を引き起こす可能性があります。特派員ノードでの混乱を避けるために、モバイルノードは、規制緩和バインディングアップデートを送信することにより、各特派員ノードとのバインディングを緩和する必要があります。Deregistration Binding Updateメッセージは、ホームエージェントと特派員ノードにトンネル化されています。これは、モバイルノードが以下で説明するように、新しい場所でホームエージェントを更新した後に行われます。
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ケアオブアドレスを使用する必要があります。。これは、モバイルノードが拘束力のある承認が受信されるまで、モバイルノードが古いアドレスのパケットを受信できるようにするために、モバイルノードの実装内のトンネルを永続的に更新せずに実行する必要があります。この効果を達成するために使用される方法は実装依存であり、この仕様の範囲外です。これは、IP転送機能（パケットが送信されるインターフェイスまたはトンネルを選択する）が宛先アドレスのみに基づいていないことを意味します。ホームエージェントに運命づけられている一部のIPv6パケットは既存のトンネルを介して送信され、バスは使用して送信されます。新しい住所。バスは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にカプセル化されたバインディングアップデートメッセージを受信すると、ホームエージェントは次のように処理します。ホームエージェントのDSMIPV6実装がモバイルノードへのパス上のNATの存在を検出できるようにするために、IPv4 Care-of Addressオプションの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）ビットがバインディングアップデートに設定され、ホームエージェントがこの機能をサポートしている場合、ホームエージェントはIKEセキュリティアソシエーションを更新して、モバイルノードのケアアドレスをピアアドレスとして、4500を含むポート番号。ホームエージェントは、IKE_SAのNATトラバーサルフィールドを変更して、認証されたIKEメッセージまたはトンネルモードESPを使用した認証パケットの受信に基づいて、IPアドレスとポート番号の動的な更新を可能にする必要がある場合があります。動的更新は、[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フラグがバインディング承認メッセージに設定された場合、モバイルノードは空の情報メッセージを送信する必要があります。その結果、ホームエージェントのIKEモジュールがSA情報を動的に更新します。この機能をサポートするには、ホームエージェントでの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.
バインディングアップデートを受信したときにホームエージェントのDSMIPV6モジュールで見られるモバイルノードのIPv4ケアオブアドレスは、IKEモジュールで見られるIPv4ケアオブアドレスと使用されるCare of Addressとは異なる場合があることに注意することが重要です。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トラバーサルの目的とKeepaliveの送信を目的として、発信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.
モバイルノードは、Mobike [RFC4555]を使用して、IKE SAをホームエージェントで更新する場合があります。Mobikeを使用するには、SAを確立する際にホームエージェントとこの機能を交渉する必要があります。この場合、このステップはMobikeによって実行されるため、モバイルノードとホームエージェントはIPSEC SASをローカルに更新してはなりません。さらに、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メッセージ交換を示します。2つの異なるIKE交渉が考慮されます。
o IKEv2 operation for securing DSMIPv6 signaling.
o DSMIPV6シグナル伝達を保護するためのIKEV2操作。
o IKEv2 operation for securing data over IPv4
o IPv4を介してデータを保護するためのIKEV2操作
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=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 &
local_address = home_address_1＆
remote_address = home_agent_1 &
remote_address = home_agent_1＆
proto = MH & local_mh_type = BU &
proto = mh＆local_mh_type = bu＆
remote_mh_type = BAck
Then use SA ESP transport mode
次に、SA ESP輸送モードを使用します
Initiate using IDi = user_1 to address home_agent_1
IDI = user_1を使用して開始して、HOME_AGENT_1に対応します
Home Agent SPD-S:
ホームエージェントSPD-S：
IF local_address = home_agent_1 &
local_address = home_agent_1＆
remote_address = home_address_1 &
remote_address = home_address_1＆
proto = MH &
proto = mh＆
local_mh_type = BAck &
local_mh_type = back＆
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ヘッダー（Sport = 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] IPv4 CoA option
bu [ipv4 hao] 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:
Homeエージェントでは、UDP脱カプセル化に続いて、以下に示すように、バインディングアップデートがIPSECモジュールに配信されます。
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6ヘッダー（src = v6hoa、dst = haaddr）
ESP header in transport mode
輸送モードのESPヘッダー
Mobility header
モビリティヘッダー
BU [IPv4 HAO]
bu [ipv4 hao]
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とSport（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]
bu [ipv4 hao]
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とSport（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 Det）
(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ヘッダー（sport = 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 Det）
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
特に
IP (source_addr=HoA, set_addr=CNAddr)
ip（source_addr = hoa、set_addr = cnaddr）
Upper_layer_HDR
apper_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 HOAまたはIPv6 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（sport = y、dport = 4500）
ESP
特に
IP (source_addr=HoA, set_addr=CNAddr)
ip（source_addr = hoa、set_addr = cnaddr）
Upper_layer_HDR
apper_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 &
local_address = home_address＆
remote_address != home_agent &
remote_address！= home_agent＆
proto=any
proto = any
Then use SA ESP tunnel mode
次に、sa espトンネルモードを使用します
Initiate using IDi = user_1 to address home_agent_1
IDI = user_1を使用して開始して、HOME_AGENT_1に対応します
home agent SPD-S:
ホームエージェントSPD-S：
IF local_address != home_agent &
local_address！= home_agent＆
remote_address = home_address &
remote_address = home_address＆
proto=any
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はホームエージェントのIPv6またはIPv4アドレスです。
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ワーキンググループの次のメンバー（アルファベット順）の貢献、ディスカッション、レビューのおかげで、Jari Arkko、Sri Gundavelli、Wassim Haddad、Alfred Hoenes、Conny Larsson、Acee Lindem、Ahmad Muhanna、Vidya Narayanan、カレン・ニールセンと清道縁。IKEV2の相互作用の問題を提起し、この文書に含まれるソリューションを提案してくれたKaren Nielsen、Pasi Eronen、およびChristian Kaas-Petersenに感謝します。この文書の多くの徹底的なレビューをしてくれたPasi 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.
セクション4.2で説明されているNATトラバーサルメカニズムにUDPポート（4191）が割り当てられています。
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ホームアドレスオプションには、値29が割り当てられています。このオプションは、[RFC3775]で説明されているモビリティヘッダーに含まれています。
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アドレス確認オプションには値29が割り当てられています。このオプションは、[RFC3775]で説明されているモビリティヘッダーに含まれています。
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検出オプションには、値31が割り当てられています。このオプションは、[RFC3775]で説明されているモビリティヘッダーに含まれています。
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].
セクション3.1.2で説明されているIPv4 Care-of Addressオプションには、値32が割り当てられています。このオプションは、[RFC3775]で説明されているモビリティヘッダーに含まれています。
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".
IPv4ホームアドレスオプションのステータスフィールドは、新しいレジストリ「DSMIPV6 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.
2. IETFの外部からの新しいオプションタイプの値割り当てのリクエストは、上記の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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「IPv4（DNAV4）のネットワークアタッチメントの検出」、RFC 4436、2006年3月。
[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.、Simpson、W。、およびH. Soliman、「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. Dupont、「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.、Ed。、Kempf、J。、およびV. Devarapalli、ed。、「SplitシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[CHOWDHURY] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[Chowdhury] Chowdhury、K。およびA. Yegin、「統合シナリオのMip6-Bootstrapping」、2008年4月、進行中の作業。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[RFC3519] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年4月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459] Savola、P。、「ネットワーク内トンネルに関するMTUおよび断片化の問題」、RFC 4459、2006年4月。
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844] Daigle、L.、ed。、およびInternet Architecture Board、「The RFC Series and RFC Editor」、RFC 4844、2007年7月。
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual Stack Mobility", RFC 4977, August 2007.
[RFC4977] Tsirtsis、G。およびH. Soliman、「問題ステートメント：デュアルスタックモビリティ」、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] Soliman、H.、Castelluccia、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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] Eggert、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
vijay devarapalli：vijay.devarapalli@azairenet.com
James Kempf: kempf@docomolabs-usa.com
James Kempf：kempf@docomolabs-usa.com
Henrik Levkowetz: henrik@levkowetz.com
Henrik Levkowetz：henrik@levkowetz.com
Pascal Thubert: pthubert@cisco.com
Pascal Thubert：pthubert@cisco.com
George Tsirtsis: G.Tsirtsis@Qualcomm.com
George Tsirtsis：g.tsirtsis@qualcomm.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
ワキカワRyuji：ryuji@sfc.wide.ad.jp
Author's Address
著者の連絡先
Hesham Soliman (editor) Elevate Technologies
Hesham Soliman（編集者）Elevate Technologies
EMail: hesham@elevatemobile.com