[要約] RFC 5380は、Hierarchical Mobile IPv6（HMIPv6）の移動管理に関する規格であり、モバイルノードの移動性を改善するためのネットワークプロトコルを提供します。目的は、モバイルノードの移動性を効率的に管理し、ネットワークのパフォーマンスを向上させることです。
Network Working Group H. Soliman
Request for Comments: 5380 Elevate Technologies
Obsoletes: 4140 C. Castelluccia
Category: Standards Track INRIA
K. ElMalki
Athonet
L. Bellier
INRIA
October 2008
Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
階層モバイルIPv6（hmipv6）モビリティ管理
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.
このドキュメントでは、モバイルIPv6およびIPv6の近隣発見に拡張機能を紹介して、ローカルモビリティの取り扱いを可能にします。モバイルIPv6の階層モビリティ管理は、モバイルノード、その特派員ノード、およびホームエージェントの間のシグナリング量を減らすように設計されています。このドキュメントで説明されているモビリティアンカーポイント（MAP）は、ハンドオーバー速度の観点からモバイルIPv6のパフォーマンスを改善するためにも使用できます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operations ..........................................6
4. Mobile IPv6 Extension - Local Binding Update ....................9
5. Neighbour Discovery Extension: The MAP Option ...................9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................11
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................13
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................14
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................15
7.1. Mobile Node Operation .....................................15
8. Updating Previous MAPs .........................................16
9. Note on MAP Selection by the Mobile Node .......................16
9.1. MAP Selection in Distributed MAP Environment ..............17
9.2. MAP Selection in a Flat Mobility Architecture .............18
10. Detection and Recovery from MAP Failures ......................18
11. Tunelling Impacts on MTU ......................................19
12. Security Considerations .......................................19
12.1. Mobile Node - MAP Security ...............................20
12.2. Mobile Node - Correspondent Node Security ................22
12.3. Mobile Node - Home Agent Security ........................22
13. IANA Considerations ...........................................22
14. Acknowledgements ..............................................22
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
Appendix A. Changes from RFC 4140 .................................24
This specification introduces the concept of a hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).
この仕様では、モビリティアンカーポイント（MAP）と呼ばれる新しいノードを使用して、階層モバイルIPv6ネットワークの概念を紹介します。
Mobile IPv6 [RFC3775] allows nodes to move within the Internet topology while maintaining reachability and ongoing connections between mobile and correspondent nodes. To do this, a mobile node sends binding updates (BUs) to its home agent (HA) every time it moves.
モバイルIPv6 [RFC3775]により、ノードはインターネットトポロジ内で移動しながら、到達可能性とモバイルノードと特派員ノードの間の継続的な接続を維持します。これを行うために、モバイルノードは、移動するたびにバインディングアップデート（バス）をホームエージェント（HA）に送信します。
The mobile node may send data packets via its home agent immediately after sending the binding update, but the home agent will not be able to route traffic back to the mobile node before it receives the binding update. This incurs at least half a round-trip delay before packets are again forwarded to the right place. There is an additional delay for sending data packets if the mobile node chooses to wait for a binding acknowledgement (BA). The round-trip times can be relatively long if the mobile node and its home agent are in different parts of the world.
モバイルノードは、バインディングアップデートを送信した直後にホームエージェントを介してデータパケットを送信する場合がありますが、ホームエージェントは、バインディングアップデートを受信する前にトラフィックをモバイルノードに戻すことができません。これにより、パケットが再び適切な場所に転送される前に、少なくとも半分の往復遅延が発生します。モバイルノードが拘束力のある確認（BA）を待つことを選択した場合、データパケットを送信するための追加の遅延があります。モバイルノードとそのホームエージェントが世界のさまざまな地域にある場合、往復時間は比較的長くなる可能性があります。
Additional delay is also incurred if the mobile node employs route optimisation. Authenticating binding updates requires approximately 1.5 round-trip times between the mobile node and each correspondent node (for the entire return routability procedure in a best-case scenario, i.e., no packet loss). This can be done in parallel with sending binding updates to the home agent, and there are further optimisations that reduce the required 1.5 round-trips [RFC4449] [RFC4651] [RFC4866].
モバイルノードがルートの最適化を使用している場合、追加の遅延も発生します。バインディングの更新を認証するには、モバイルノードと各特派員ノードの間で約1.5回の往復時間が必要です（ベストケースシナリオでの返品ルー上の手順全体、つまりパケット損失はありません）。これは、ホームエージェントにバインディングアップデートを送信することと並行して実行でき、必要な1.5ラウンドトリップ[RFC4449] [RFC4651] [RFC4866]を減らす最適化がさらにあります。
Nevertheless, the signalling exchanges required to update your location will always cause some disruption to active connections. Some packets will be lost. Together with link layer and IP layer connection setup delays, there may be effects to upper-layer protocols. Reducing these delays during the time-critical handover period will improve the performance of Mobile IPv6.
それにもかかわらず、あなたの場所を更新するために必要なシグナル交換は、常にアクティブな接続にある程度の混乱を引き起こします。一部のパケットは失われます。リンクレイヤーおよびIPレイヤー接続のセットアップの遅延とともに、上層層プロトコルに効果がある可能性があります。タイムクリティカルなハンドオーバー期間中にこれらの遅延を削減すると、モバイルIPv6のパフォーマンスが向上します。
Moreover, in the case of wireless links, such a solution reduces the number of messages sent over the air interface to all correspondent nodes and the home agent. A local anchor point will also allow Mobile IPv6 to benefit from reduced mobility signalling with external networks.
さらに、ワイヤレスリンクの場合、このようなソリューションは、すべての特派員ノードとホームエージェントにエアインターフェイスを介して送信されるメッセージの数を減らします。また、ローカルアンカーポイントにより、モバイルIPv6は、外部ネットワークを使用したモビリティシグナル伝達の削減から利益を得ることができます。
For these reasons, a new Mobile IPv6 node, called the Mobility Anchor Point, is used and can be located at any level in a hierarchical network of routers, including the Access Router (AR). The MAP will limit the amount of Mobile IPv6 signalling outside the local domain.
これらの理由により、モビリティアンカーポイントと呼ばれる新しいモバイルIPv6ノードが使用され、アクセスルーター（AR）を含むルーターの階層ネットワークの任意のレベルに配置できます。マップは、ローカルドメインの外側のモバイルIPv6信号の量を制限します。
The introduction of the MAP provides a solution to the issues outlined earlier, in the following way:
マップの導入は、以前に概説した問題の解決策を次のように提供します。
o The mobile node sends binding updates to the local MAP rather than the home agent (HA) (which is typically further away) and correspondent nodes (CNs).
o モバイルノードは、ホームエージェント（HA）（通常は遠く離れている）および特派員ノード（CNS）ではなく、ローカルマップにバインディングアップデートを送信します。
o Only one binding update message needs to be transmitted by the mobile node (MN) before traffic from the HA and all CNs is re-routed to its new location. This is independent of the number of CNs with which the MN is communicating.
o HAとすべてのCNSが新しい場所に再ルーティングされる前に、モバイルノード（MN）によって1つのバインディングアップデートメッセージを送信する必要があります。これは、MNが通信しているCNの数とは無関係です。
A MAP is essentially a local home agent. The aim of introducing the hierarchical mobility management model in Mobile IPv6 is to enhance the performance of Mobile IPv6 while minimising the impact on Mobile IPv6 or other IPv6 protocols. Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and home agents, while using Mobile IPv6 route optimisation. The security differences between the MAP and the home agent are described in Section 12.
マップは本質的に地元のホームエージェントです。モバイルIPv6に階層モビリティ管理モデルを導入する目的は、モバイルIPv6または他のIPv6プロトコルへの影響を最小限に抑えながら、モバイルIPv6のパフォーマンスを向上させることです。さらに、HMIPv6を使用すると、モバイルIPv6ルートの最適化を使用しながら、モバイルノードが特派員ノードとホームエージェントから位置を隠すことができます。マップとホームエージェントのセキュリティの違いは、セクション12で説明されています。
It is pertinent to note that the use of the MAP does not rely on, or assume the presence of, a permanent home agent. In other words, a mobile node need not have a permanent home address or home agent in order to be HMIPv6-aware or use the features in this specification. A MAP may be used by a mobile node in a nomadic manner to achieve mobility management within a local domain. Section 6.5 describes such a scenario.
マップの使用は、恒久的なホームエージェントに依存している、または存在することを想定していないことに注意することは適切です。言い換えれば、モバイルノードには、hmipv6-awareになったり、この仕様の機能を使用したりするために、永続的なホームアドレスやホームエージェントを持つ必要はありません。マップは、ローカルドメイン内のモビリティ管理を実現するために、遊牧的な方法でモバイルノードで使用できます。セクション6.5では、このようなシナリオについて説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In addition, the following terms are introduced:
さらに、次の用語が紹介されます。
Access Router (AR)
アクセスルーター（AR）
The AR is the mobile node's default router. The AR aggregates the outbound traffic of mobile nodes.
ARはモバイルノードのデフォルトルーターです。ARは、モバイルノードのアウトバウンドトラフィックを集約します。
Mobility Anchor Point (MAP)
モビリティアンカーポイント（マップ）
A Mobility Anchor Point is a router located in a network visited by the mobile node. The MAP is used by the MN as a local HA. One or more MAPs can exist within a visited network.
モビリティアンカーポイントは、モバイルノードが訪れるネットワークにあるルーターです。マップは、MNによってローカルHAとして使用されます。訪問されたネットワーク内に1つ以上のマップが存在する可能性があります。
Regional Care-of Address (RCoA)
地域のケアオブアドレス（RCOA）
An RCoA is an address allocated by the MAP to the mobile node.
RCOAは、マップによってモバイルノードに割り当てられたアドレスです。
HMIPv6-Aware Mobile Node
hmipv6-awareモバイルノード
An HMIPv6-aware mobile node is a mobile node that can receive and process the MAP option received from its default router. An HMIPv6-aware mobile node must also be able to send local binding updates (binding update with the M flag set).
HMIPV6-AWAREモバイルノードは、デフォルトのルーターから受信したマップオプションを受信および処理できるモバイルノードです。HMIPV6を使用するモバイルノードは、ローカルバインディングアップデート（M FLAGセットによるバインディングアップデート）を送信することもできなければなりません。
On-Link Care-of Address
オンリンクのケアオブアドレス
The LCoA is the on-link CoA configured on a mobile node's interface based on the prefix advertised by its default router. In [RFC3775], this is simply referred to as the care-of address. However, in this memo LCoA is used to distinguish it from the RCoA.
LCOAは、デフォルトのルーターによって宣伝されているプレフィックスに基づいて、モバイルノードのインターフェイスで構成されたオンリンクCOAです。[RFC3775]では、これは単にケアオブアドレスと呼ばれます。ただし、このメモでは、LCOAを使用してRCOAと区別します。
Local Binding Update
ローカルバインディングアップデート
The MN sends a local binding update to the MAP in order to establish a binding between the RCoA and LCoA.
MNは、RCOAとLCOAの間にバインディングを確立するために、ローカルバインディングアップデートをマップに送信します。
This hierarchical Mobile IPv6 scheme introduces a new function, the MAP, and minor extensions to the mobile node operation. The correspondent node and home agent operations will not be affected.
この階層的なモバイルIPv6スキームは、モバイルノード操作に新しい機能、マップ、およびマイナーな拡張機能を導入します。特派員ノードとホームエージェントの操作は影響を受けません。
Just like Mobile IPv6, this solution is independent of the underlying access technology, allowing mobility within or between different types of access networks.
モバイルIPv6と同様に、このソリューションは基礎となるアクセステクノロジーに依存しないため、さまざまな種類のアクセスネットワーク内または間のモビリティが可能になります。
A mobile node entering a MAP domain will receive Router Advertisements containing information about one or more local MAPs. The MN can bind its current location (on-link CoA) with an address on the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all packets on behalf of the mobile node it is serving and will encapsulate and forward them directly to the mobile node's current address. If the mobile node changes its current address within a local MAP domain (LCoA), it only needs to register the new address with the MAP. Hence, only the Regional CoA (RCoA) needs to be registered with correspondent nodes and the HA. The RCoA does not change as long as the MN moves within a MAP domain (see below for definition). This makes the mobile node's mobility transparent to correspondent nodes it communicates with.
マップドメインに入るモバイルノードは、1つ以上のローカルマップに関する情報を含むルーター広告を受け取ります。MNは、現在の位置（オンリンクCOA）をマップのサブネット（RCOA）のアドレスと結合できます。ローカルHAとして機能するマップは、提供されているモバイルノードに代わってすべてのパケットを受信し、モバイルノードの現在のアドレスに直接転送します。モバイルノードがローカルマップドメイン（LCOA）内の現在のアドレスを変更する場合、新しいアドレスをマップに登録するだけです。したがって、地域COA（RCOA）のみを、特派員ノードとHAに登録する必要があります。RCOAは、MNがMAPドメイン内で移動する限り、変更されません（定義については以下を参照）。これにより、モバイルノードのモビリティが通信する特派員ノードに対して透明になります。
A MAP domain's boundaries are defined by the Access Routers (ARs) advertising the MAP information to the attached mobile nodes. The detailed extensions to Mobile IPv6 and operations of the different nodes will be explained later in this document.
マップドメインの境界は、添付のモバイルノードにマップ情報を宣伝するアクセスルーター（ARS）によって定義されます。モバイルIPv6への詳細な拡張機能とさまざまなノードの操作については、このドキュメントの後半で説明します。
It should be noted that the HMIPv6 concept is simply an extension to the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an implementation of Mobile IPv6 SHOULD choose to use the MAP when discovering such capability in a visited network. However, in some cases the mobile node may prefer to simply use the standard Mobile IPv6 implementation. For instance, the mobile node may be located in a visited network within its home site. In this case, the HA is located near the visited network and could be used instead of a MAP. In this scenario, the mobile node would only update the HA whenever it moves. The method to determine whether the HA is in the vicinity of the MN (e.g., same site) is outside the scope of this document.
HMIPV6コンセプトは、単にモバイルIPv6プロトコルの拡張機能であることに注意する必要があります。モバイルIPv6の実装を備えたHMIPV6対応のモバイルノードは、訪問されたネットワークでそのような機能を発見するときにマップを使用することを選択する必要があります。ただし、場合によっては、モバイルノードは、標準のモバイルIPv6実装を単純に使用することを好む場合があります。たとえば、モバイルノードは、ホームサイト内の訪問されたネットワークに配置される場合があります。この場合、HAは訪問されたネットワークの近くにあり、マップの代わりに使用できます。このシナリオでは、モバイルノードは移動するたびにHAを更新します。HAがMNの近くにあるかどうか（たとえば、同じサイト）がこのドキュメントの範囲外であるかどうかを判断する方法。
The network architecture shown in Figure 1 illustrates an example of the use of the MAP in a visited network.
図1に示すネットワークアーキテクチャは、訪問されたネットワークでのマップの使用の例を示しています。
In Figure 1, the MAP can help in providing seamless mobility for the mobile node as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), while communicating with the correspondent node. A multi-level hierarchy is not required for a higher handover performance. Hence, it is sufficient to locate one or more MAPs (possibly covering the same domain) at any position in the operator's network.
図1では、マップは、アクセスルーター1（AR1）から、クレスコンテントノードと通信しながら、ルーター2（AR2）にアクセスするように移動するため、モバイルノードのシームレスなモビリティを提供するのに役立ちます。ハンドオーバーパフォーマンスの向上には、マルチレベルの階層は必要ありません。したがって、オペレーターのネットワーク内の任意の位置に1つ以上のマップ（おそらく同じドメインをカバーする）を見つけるだけで十分です。
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Hierarchical Mobile IPv6 domain
図1：階層モバイルIPv6ドメイン
Upon arrival in a visited network, the mobile node will discover the global address of the MAP. This address is stored in the Access Routers and communicated to the mobile node via Router Advertisements (RAs). A new option for RAs is defined later in this specification. This is needed to inform mobile nodes about the presence of the MAP (MAP Discovery). The discovery phase will also inform the mobile node of the distance of the MAP from the mobile node. For example, the MAP function could be implemented as shown in Figure 1, and, at the same time, also be implemented in AR1 and AR2. In this case, the mobile node can choose the first hop MAP or one further up in the hierarchy of routers. The details on how to choose a MAP are provided in Section 10.
訪問されたネットワークに到着すると、モバイルノードはマップのグローバルアドレスを発見します。このアドレスはアクセスルーターに保存され、ルーター広告（RAS）を介してモバイルノードに通信されます。RASの新しいオプションは、この仕様の後半で定義されています。これは、マップの存在についてモバイルノードに通知するために必要です（マップ発見）。ディスカバリーフェーズは、モバイルノードからのマップの距離のモバイルノードにも通知します。たとえば、図1に示すようにマップ関数を実装することができ、同時にAR1とAR2にも実装されます。この場合、モバイルノードは、最初のホップマップを選択するか、ルーターの階層でさらに1つを選択できます。マップを選択する方法の詳細は、セクション10に記載されています。
The process of MAP Discovery continues as the mobile node moves from one subnet to the next. Every time the mobile node detects movement, it will also detect whether it is still in the same MAP domain. The Router Advertisement used to detect movement will also inform the mobile node, through Neighbour Discovery [RFC4861] and the MAP option, whether it is still in the same MAP domain. As the mobile node roams within a MAP domain, it will continue to receive the same MAP option included in Router Advertisements from its AR. If a change in the advertised MAP's address is received, the mobile node MUST act on the change by sending binding updates to its HA and correspondent nodes.
モバイルノードが1つのサブネットから次のサブネットに移動するにつれて、マップディスカバリーのプロセスが継続されます。モバイルノードが動きを検出するたびに、同じマップドメインにまだあるかどうかも検出されます。動きを検出するために使用されるルーター広告は、近隣発見[RFC4861]とマップオプションを介してモバイルノードを通知します。モバイルノードがMAPドメイン内でローミングするため、ARからルーター広告に含まれる同じマップオプションを引き続き受信します。広告されたマップのアドレスの変更が受信された場合、モバイルノードは、HAおよび特派員ノードにバインディングアップデートを送信することにより、変更に対応する必要があります。
If the mobile node is not HMIPv6-aware, then no MAP Discovery will be performed, resulting in the mobile node using the Mobile IPv6 [RFC3775] protocol for its mobility management. On the other hand, if the mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 implementation. If so, the mobile node will first need to register with a MAP by sending it a BU containing its home address and on-link address (LCoA). The home address used in the BU is the RCoA, which the mobile node acquires via RFC 4877 [RFC4877] Section 9 mechanisms when it first contacts a given MAP. The MAP MUST store this information in its binding cache to be able to forward packets to their final destination when received from the different correspondent nodes or HAs.
モバイルノードがhmipv6-awareでない場合、マップの発見は実行されず、モバイルIPv6 [RFC3775]プロトコルを使用してモバイルノードがモビリティ管理のためにプロトコルを使用します。一方、モバイルノードがhmipv6-awareである場合、hmipv6実装を使用することを選択する必要があります。その場合、モバイルノードは、最初に自宅の住所とオンリンクアドレス（LCOA）を含むBUを送信して、マップに登録する必要があります。BUで使用されるホームアドレスはRCOAであり、モバイルノードはRFC 4877 [RFC4877]セクション9メカニズムを介して取得し、特定のマップに最初に接触します。マップは、この情報をバインディングキャッシュに保存して、異なる特派員ノードまたは持っている場合に最終的な宛先にパケットを転送できるようにする必要があります。
The mobile node will always need to know the original sender of any received packets to determine if route optimisation is required. This information will be available to the mobile node because the MAP does not modify the contents of the original packet. Normal processing of the received packets (as described in [RFC3775]) will give the mobile node the necessary information.
モバイルノードは、ルートの最適化が必要かどうかを判断するために、受信したパケットの元の送信者を常に知る必要があります。この情報は、マップが元のパケットの内容を変更しないため、モバイルノードで利用できます。受信したパケットの通常の処理（[RFC3775]で説明されている）は、モバイルノードに必要な情報を提供します。
To use the network bandwidth in a more efficient manner, a mobile node may decide to register with more than one MAP simultaneously and to use each MAP address for a specific group of correspondent nodes. For example, in Figure 1, if the correspondent node happens to exist on the same link as the mobile node, it would be more efficient to use the first hop MAP (in this case assume it is AR1) for communication between them. This will avoid sending all packets via the "highest" MAP in the hierarchy and thus will result in more efficient usage of network bandwidth. The mobile node can also use its current on-link address (LCoA) as a CoA, as specified in [RFC3775]. Note that the mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a binding update sent to another MAP. The LCoA included in the binding update MUST be the mobile node's address, derived from the prefix advertised on its link.
ネットワークの帯域幅をより効率的に使用するために、モバイルノードは複数のマップに同時に登録し、特派員ノードの特定のグループに各マップアドレスを使用することを決定する場合があります。たとえば、図1では、特派員ノードがモバイルノードと同じリンクにたまたま存在する場合、それらの間の通信に最初のホップマップ（この場合はAR1であると仮定）を使用する方が効率的です。これにより、階層内の「最高の」マップを介してすべてのパケットが送信されないため、ネットワーク帯域幅をより効率的に使用することになります。モバイルノードは、[RFC3775]で指定されているように、現在のオンリンクアドレス（LCOA）をCOAとして使用することもできます。モバイルノードは、別のマップに送信されたバインディングアップデートで、マップのサブネットからRCOAをLCOAとして提示しないでください。バインディングアップデートに含まれるLCOAは、リンクに宣伝されているプレフィックスから派生したモバイルノードのアドレスでなければなりません。
This section outlines the extensions proposed to the binding update specified in [RFC3775].
このセクションでは、[RFC3775]で指定されたバインディングアップデートに提案されている拡張機能の概要を説明します。
A new flag is added: the M flag, which indicates MAP registration. When a mobile node registers with the MAP, the M and A flags MUST be set to distinguish this registration from a BU being sent to the HA or a correspondent node.
新しいフラグが追加されています：Mフラグは、マップ登録を示しています。モバイルノードがマップを使用して登録する場合、この登録をHAまたは特派員ノードに送信するBUと区別するために、MとAフラグを設定する必要があります。
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| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Binding Update
図2：ローカルバインディングアップデート
M
m
If set to 1, it indicates a MAP registration.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MAP option
図3：マップオプション
Type
タイプ
IPv6 Neighbour Discovery option. Its value is 23.
IPv6ネイバーディスカバリーオプション。その値は23です。
Length
長さ
8-bit unsigned integer. The length of the option and MUST be set to 3.
8ビットの符号なし整数。オプションの長さと3に設定する必要があります。
Dist
区別
A 4-bit unsigned integer identifying the distance between MAP and the receiver of the advertisement, measure in the number of hops and starting from 1 if the MAP is on the same link as the mobile node. A distance value of zero MUST NOT be used.
マップと広告の受信機の間の距離を識別する4ビットの署名されていない整数は、ホップ数を測定し、マップがモバイルノードと同じリンクにある場合は1から始まります。ゼロの距離値を使用しないでください。
Pref
pref
The preference field, used as an indicator of operator preference. A 4-bit unsigned integer. A decimal value of 15 indicates the highest preference. When comparing two potential MAPs, the mobile node SHOULD inspect this field as a tie-breaker for MAPs that have equal Dist values.
オペレーターの好みの指標として使用される優先フィールド。4ビットの符号なし整数。15の小数値は、最高の優先度を示します。2つの潜在的なマップを比較する場合、モバイルノードは、等しい値を持つマップのタイブレーカーとしてこのフィールドを検査する必要があります。
R
r
When set to 1, it indicates that the mobile node is allocated the RCoA by the MAP based on Section 9 of [RFC4877].
1に設定すると、[RFC4877]のセクション9に基づいて、モバイルノードがマップによってRCOAに割り当てられていることを示します。
Valid Lifetime
有効な寿命
The minimum value (in seconds) of both the valid lifetime of the prefix used to form the MAP's address and that used to form the RCoA. This value indicates the validity of the MAP's address and the RCoA.
マップのアドレスを形成するために使用されるプレフィックスの有効な寿命と、RCOAの形成に使用される最小値（秒単位）。この値は、マップのアドレスとRCOAの有効性を示しています。
Global Address
グローバルアドレス
One of the MAP's global addresses.
マップのグローバルアドレスの1つ。
This section describes the HMIPv6 protocol. In HMIPv6, the mobile node has two addresses, an RCoA on the MAP's link and an on-link CoA (LCoA). This RCoA is formed in a stateless manner by combining the mobile node's interface identifier and the subnet prefix received in the MAP option.
このセクションでは、HMIPv6プロトコルについて説明します。HMIPv6では、モバイルノードには2つのアドレスがあります。マップのリンク上のRCOAとオンリンクCOA（LCOA）です。このRCOAは、モバイルノードのインターフェイス識別子とMAPオプションで受信したサブネットプレフィックスを組み合わせることにより、ステートレスの方法で形成されます。
As illustrated in this section, this protocol requires updating the mobile nodes' implementation only. The HA and correspondent node are unchanged. The MAP performs the function of a "local" HA that binds the mobile node's RCoA to an LCoA.
このセクションに示すように、このプロトコルでは、モバイルノードの実装のみを更新する必要があります。HAと特派員ノードは変更されていません。マップは、モバイルノードのRCOAをLCOAに結合する「ローカル」HAの機能を実行します。
When a mobile node moves into a new MAP domain (i.e., its MAP changes), it needs to configure two CoAs: an RCoA on the MAP's link and an on-link CoA (LCoA). After employing [RFC4877] to acquire an RCoA, the mobile node sends a local BU to the MAP with the A and M flags set. The local BU is a BU defined in [RFC3775] and includes the mobile node's RCoA in the Home Address option. No alternate-CoA option is needed in this message. The LCoA is used as the source address of the BU. This BU will bind the mobile node's RCoA (similar to a home address) to its LCoA. The MAP (acting as an HA) will then return a binding acknowledgement to the MN. This acknowledgement either identifies the binding as successful or contains the appropriate fault code. No new error codes need to be supported by the mobile node for this operation. The mobile node MUST silently ignore binding acknowledgements that do not contain a routing header type 2, which includes the mobile node's RCoA.
モバイルノードが新しいマップドメインに移動する場合（つまり、マップが変更されます）、マップのリンク上のRCOAとリンクCOA（LCOA）の2つのCOAを構成する必要があります。[RFC4877]を使用してRCOAを取得した後、モバイルノードはAフラグセットを使用してローカルBUをマップに送信します。ローカルBUは[RFC3775]で定義されているBUであり、モバイルノードのRCOAにホームアドレスオプションが含まれています。このメッセージでは、代替COAオプションは必要ありません。LCOAは、BUのソースアドレスとして使用されます。このBUは、モバイルノードのRCOA（自宅の住所と同様）をLCOAに結合します。マップ（HAとして機能する）は、MNに拘束力のある承認を返します。この承認は、バインディングを成功として識別するか、適切な障害コードを含むかのいずれかです。この操作のために、モバイルノードで新しいエラーコードをサポートする必要はありません。モバイルノードは、モバイルノードのRCOAを含むルーティングヘッダータイプ2を含まないバインディング承認を静かに無視する必要があります。
Following a successful registration with the MAP, a bi-directional tunnel between the mobile node and the MAP is established. All packets sent by the mobile node are tunnelled to the MAP. The outer header contains the mobile node's LCoA in the source address field, and the MAP's address in the destination address field. The inner header contains the mobile node's RCoA in the source address field, and the peer's address in the destination address field. Similarly, all packets addressed to the mobile node's RCoA are intercepted by the MAP and tunnelled to the mobile node's LCoA.
マップへの登録が成功した後、モバイルノードとマップの間の双方向トンネルが確立されます。モバイルノードから送信されたすべてのパケットは、マップにトンネルされています。外側のヘッダーには、ソースアドレスフィールドにモバイルノードのLCOAと、宛先アドレスフィールドにマップのアドレスが含まれています。内側のヘッダーには、ソースアドレスフィールドにモバイルノードのRCOAと、宛先アドレスフィールドにピアのアドレスが含まれています。同様に、モバイルノードのRCOAにアドレス指定されたすべてのパケットは、マップによって傍受され、モバイルノードのLCOAにトンネルされています。
This specification allows a mobile node to use more than one RCoA if it received more than one MAP option. In this case, the mobile node MAY perform the binding update procedure for each RCoA. In addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a MAP's prefix (e.g., MAP1) as a care-of address in its binding update to another MAP (e.g., MAP2). This would force packets to be encapsulated several times (twice in this example) on their path to the mobile node. This form of multi-level hierarchy will reduce the protocol's efficiency and performance.
この仕様により、モバイルノードが複数のマップオプションを受け取った場合、モバイルノードを複数のRCOAを使用できます。この場合、モバイルノードは、各RCOAのバインディングアップデート手順を実行できます。さらに、モバイルノードは、別のMAPへのバインディングアップデート（例：MAP2）で、MAPのプレフィックス（例：MAP1）から派生した1つのRCOA（例：RCOA1）を使用してはなりません。これにより、パケットはモバイルノードへのパスで数回（この例で2回）カプセル化されます。この形式のマルチレベルの階層は、プロトコルの効率とパフォーマンスを低下させます。
After registering with the MAP, the mobile node MUST register its new RCoA with its HA by sending a BU that specifies the binding (RCoA, home address), as in Mobile IPv6. The mobile node's home address is used in the Home Address option and the RCoA is used as the care-of address in the source address field. The mobile node may also send a similar BU (i.e., that specifies the binding between the home address and the RCoA) to its current correspondent nodes.
マップに登録した後、モバイルノードは、モバイルIPv6のようにバインディング（RCOA、自宅の住所）を指定するBUを送信して、新しいRCOAをHAに登録する必要があります。モバイルノードのホームアドレスはホームアドレスオプションで使用され、RCOAはソースアドレスフィールドのケアオブアドレスとして使用されます。また、モバイルノードは、現在の特派員ノードに同様のBU（つまり、ホームアドレスとRCOAの間のバインディングを指定する）を送信する場合があります。
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering the RCoA with other nodes (e.g., CN or HA, if available). It should be noted that when binding the RCoA with the HA and correspondent nodes, the binding lifetime MUST NOT be larger than the mobile node's binding lifetime with the MAP, which is received in the binding acknowledgement.
モバイルノードは、RCOAを他のノードに登録する前に、マップからのバインディングの確認を待つ必要があります（たとえば、CNまたはHA、利用可能な場合）。RCOAをHAおよび特派員ノードでバインドする場合、バインドされた寿命は、バインディングの確認で受信されるMAPでモバイルノードの結合寿命よりも大きくなければならないことに注意してください。
In order to speed up the handover between MAPs and reduce packet loss, a mobile node SHOULD send a local BU to its previous MAP, specifying its new LCoA. Packets in transit that reach the previous MAP are then forwarded to the new LCoA.
マップ間のハンドオーバーをスピードアップしてパケット損失を減らすために、モバイルノードはローカルBUを以前のマップに送信して、新しいLCOAを指定する必要があります。以前のマップに到達する輸送中のパケットは、新しいLCOAに転送されます。
The MAP will receive packets addressed to the mobile node's RCoA (from the HA or correspondent nodes). Packets will be tunnelled from the MAP to the mobile node's LCoA. The mobile node will de-capsulate the packets and process them in the normal manner.
マップは、モバイルノードのRCOA（HAまたは特派員ノードから）に宛てられたパケットを受け取ります。パケットは、マップからモバイルノードのLCOAにトンネル化されます。モバイルノードは、パケットをカプセル化し、通常の方法で処理します。
When the mobile node moves within the same MAP domain, it should only register its new LCoA with its MAP. In this case, the RCoA remains unchanged.
モバイルノードが同じマップドメイン内で移動する場合、新しいLCOAのみをマップに登録する必要があります。この場合、RCOAは変更されていません。
Note that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes. If these nodes are connected to the same link, packets will then be routed directly, without going through the MAP.
モバイルノードは、（RCOAの代わりに）LCOAを含むBUを特派員ノードに送信する場合があることに注意してください。これらのノードが同じリンクに接続されている場合、マップを通過せずにパケットが直接ルーティングされます。
The mobile node can communicate with a correspondent node through the HA, or in a route-optimised manner, as described in [RFC3775]. When communicating through the HA, the message formats in [RFC3775] are used.
[RFC3775]で説明されているように、モバイルノードは、HAを介して、またはルートを最適化した方法で通信型ノードと通信できます。HAを介して通信する場合、[RFC3775]のメッセージ形式が使用されます。
If the mobile node communicates directly with the correspondent node (i.e., the CN has a binding cache entry for the mobile node), the mobile node MUST use the same care-of address used to create a binding cache entry in the correspondent node (RCoA) as a source address. According to [RFC3775], the mobile node MUST also include a Home Address option in outgoing packets. The Home Address option MUST contain the mobile node's home address.
モバイルノードが特派員ノード（つまり、CNがモバイルノードのバインディングキャッシュエントリがある）と直接通信する場合、モバイルノードは、クレENTENTノード（RCOAのバインディングキャッシュエントリを作成するために使用される同じケアオブアドレスを使用する必要があります。）ソースアドレスとして。[RFC3775]によると、モバイルノードには、発信パケットにホームアドレスオプションも含める必要があります。ホームアドレスオプションには、モバイルノードのホームアドレスが含まれている必要があります。
The MAP acts like an HA; it intercepts all packets addressed to registered mobile nodes and tunnels them to the corresponding LCoA, which is stored in its binding cache.
マップはHAのように機能します。登録されたモバイルノードにアドレス指定されたすべてのパケットをインターセプトし、それらをバインディングキャッシュに保存する対応するLCOAにトンネルをトンネルします。
A MAP has no knowledge of the mobile node's home address. The mobile node will send a local BU to the MAP with the M and A flags set. The aim of this BU is to bind the RCoA (contained in the BU as a home address) to the mobile node's LCoA. If successful, the MAP MUST return a binding acknowledgement to the mobile node, indicating a successful registration. This is identical to the HA operation in [RFC3775]. No new error codes are introduced for HMIPv6. The binding acknowledgement MUST include a routing header type 2 that contains the mobile node's RCoA.
マップには、モバイルノードの自宅の住所に関する知識がありません。モバイルノードは、Mとフラグセットを使用してローカルBUをマップに送信します。このBUの目的は、RCOA（自宅の住所としてBUに含まれる）をモバイルノードのLCOAに結合することです。成功した場合、マップはモバイルノードに拘束力のある承認を返す必要があり、登録が成功したことを示しています。これは、[RFC3775]のHA操作と同じです。hmipv6には新しいエラーコードは導入されていません。バインディングの承認には、モバイルノードのRCOAを含むルーティングヘッダータイプ2を含める必要があります。
The MAP MUST be able to accept packets tunnelled from the mobile node, with the mobile node being the tunnel entry point and the MAP being the tunnel exit point.
マップは、モバイルノードからトンネルに登録されたパケットを受け入れることができなければなりません。モバイルノードはトンネルのエントリポイントであり、マップはトンネル出口ポイントです。
The MAP employs [RFC4877] Section 9 procedures for the allocation of RCoA, and subsequently acts as an HA for the RCoA. Packets addressed to the RCoA are intercepted by the MAP, using proxy Neighbour Advertisement, and then encapsulated and routed to the mobile node's LCoA. This operation is identical to that of the HA described in [RFC3775].
マップは、[RFC4877]セクション9 RCOAの割り当ての手順を採用し、その後RCOAのHAとして機能します。RCOAにアドレス指定されたパケットは、プロキシNeighbor広告を使用してマップによって傍受され、カプセル化されてモバイルノードのLCOAにルーティングされます。この操作は、[RFC3775]に記載されているHAの操作と同じです。
A MAP MAY be configured with the list of valid on-link prefixes that mobile nodes can use to derive LCoAs. This is useful for network operators that need to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile
マップは、モバイルノードがLCOAを導出するために使用できる有効なオンリンクプレフィックスのリストで構成できます。これは、モバイルノードが別の管理ドメインに移動した後もマップの使用を継続するのを止める必要があるネットワークオペレーターに役立ちます。モバイルの場合
node sent a binding update containing an LCoA that is not in the MAP's "valid on-link prefixes" list, the MAP could reject the binding update using existing error code 129 (administratively prohibited).
ノードは、マップの「有効なオンリンクプレフィックス」リストにないLCOAを含むバインディングアップデートを送信しました。マップは、既存のエラーコード129（管理上禁止）を使用してバインディングアップデートを拒否できます。
The support of HMIPv6 is completely transparent to the HA's operation. Packets addressed to a mobile node's home address will be forwarded by the HA to its RCoA, as described in [RFC3775].
HMIPV6のサポートは、HAの操作に対して完全に透明です。[RFC3775]に記載されているように、モバイルノードのホームアドレスにアドレス指定されたパケットは、HAによってRCOAに転送されます。
HMIPv6 is completely transparent to correspondent nodes.
HMIPV6は、特派員ノードに対して完全に透明です。
In [RFC3775], it is stated that for short-term communication, particularly communication that may easily be retried upon failure, the mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, thus not requiring the use of a Home Address option in the packet. Such use of the CoA will reduce the overhead of sending each packet due to the absence of additional options. In addition, it will provide an optimal route between the mobile node and correspondent node.
[RFC3775]では、短期通信、特に障害時に簡単に再試行する可能性のある通信のために、モバイルノードはパケットのソースとしてそのケアアドレスの1つを直接使用することを選択できるため、パケットでのホームアドレスオプションの使用。このようなCOAを使用すると、追加のオプションがないため、各パケットの送信のオーバーヘッドが減少します。さらに、モバイルノードと特派員ノードの間に最適なルートが提供されます。
HMIPv6-aware mobile nodes can use their RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a source address for upper layers. Using this feature, the mobile node will be seen by the correspondent node as a fixed node while moving within a MAP domain.
HMIPV6-AWAREモバイルノードは、ホームアドレスオプションを使用せずにRCOAをソースアドレスとして使用できます。言い換えれば、RCOAは上層のソースアドレスとして使用できます。この機能を使用して、モバイルノードは、MAPドメイン内を移動する際に、特派員ノードによって固定ノードとして表示されます。
This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., no bindings or Home Address options are sent over the Internet), but still provides local mobility management to the mobile nodes with near-optimal routing. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile node changes its RCoA), it would be useful for several applications (e.g., web browsing). The validity of the RCoA as a source address used by applications will depend on the size of a MAP domain and the speed of the mobile node. Furthermore, because the support for BU processing in correspondent nodes is not mandated in [RFC3775], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.
RCOAのこの使用には、モバイルIPv6のコストはありません（つまり、インターネットを介してバインディングやホームアドレスオプションは送信されません）が、最適に近いルーティングでモバイルノードにローカルモビリティ管理を提供します。このようなRCOAの使用はグローバルなモビリティを提供しませんが（つまり、モバイルノードがRCOAを変更すると通信が壊れます）、いくつかのアプリケーション（例：Webブラウジング）に役立ちます。アプリケーションで使用されるソースアドレスとしてのRCOAの有効性は、マップドメインのサイズとモバイルノードの速度によって異なります。さらに、特派員ノードでのBU処理のサポートは[RFC3775]で義務付けられていないため、このメカニズムは、通信員ノードにバスを送ることなくルートの最適化を取得する方法を提供できます。
Enabling this mechanism can be done by presenting the RCoA as a temporary home address for the mobile node. This may require an implementation to augment its source address selection algorithm with the knowledge of the RCoA in order to use it for the appropriate applications.
このメカニズムを有効にすることは、RCOAをモバイルノードの一時的なホームアドレスとして提示することで実行できます。これには、適切なアプリケーションに使用するために、RCOAの知識を持ってソースアドレス選択アルゴリズムを強化するための実装が必要になる場合があります。
In HMIPv6, a mobile node hides its LCoA from its correspondent nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, address-based location tracking of a mobile node by its correspondent nodes or its home agent is more difficult because they only know its RCoA and not its LCoA.
HMIPv6では、モバイルノードが、送信するパケットのソースフィールドにRCOAを使用することにより、その特派員ノードとホームエージェントからLCOAを隠します。その結果、特派員ノードまたはホームエージェントによるモバイルノードのアドレスベースの位置追跡は、rcoAではなくRCOAのみを知っているため、より困難です。
This section describes how a mobile node obtains the MAP address and subnet prefix, and how ARs in a domain discover MAPs.
このセクションでは、モバイルノードがマップアドレスとサブネットのプレフィックスを取得する方法と、ドメイン内のARがマップを発見する方法について説明します。
This specification requires network administrators to manually configure the MAP option information in ARs; future mechanisms may be defined to allow MAPs to be discovered dynamically.
この仕様では、ネットワーク管理者がARSでマップオプション情報を手動で構成する必要があります。将来のメカニズムは、マップを動的に発見できるように定義される場合があります。
When an HMIPv6-aware mobile node receives a Router Advertisement, it should search for the MAP option. One or more options may be found for different MAP IP addresses. A mobile node SHOULD register with the MAP having the highest preference value. A MAP with a preference value of zero SHOULD NOT be used for new local BUs (i.e., the mobile node can refresh existing bindings but cannot create new ones). However, a mobile node MAY choose to register with one MAP over another, depending on the value received in the distance field, provided that the preference value is above zero.
HMIPV6を意識したモバイルノードがルーター広告を受信した場合、マップオプションを検索する必要があります。さまざまなマップIPアドレスに対して1つ以上のオプションが見つかる場合があります。モバイルノードは、最高の優先値を持つマップに登録する必要があります。ゼロの優先値を持つマップは、新しいローカルバスに使用しないでください（つまり、モバイルノードは既存のバインディングを更新できますが、新しいバインディングを作成できません）。ただし、設定値がゼロを超えている場合、モバイルノードは、距離フィールドで受信した値に応じて、あるマップに別のマップよりも登録することを選択できます。
A MAP option containing a valid lifetime value of zero means that this MAP MUST NOT be selected by the MN. A valid lifetime of zero indicates a MAP failure. When this option is received, a mobile node MUST choose another MAP and create new bindings. Any existing bindings with this MAP can be assumed to be lost. If no other MAP is available, the mobile node MUST NOT attempt to use HMIPv6.
ゼロの有効な生涯値を含むマップオプションは、このマップをMNによって選択してはならないことを意味します。ゼロの有効な寿命は、マップの障害を示します。このオプションを受信した場合、モバイルノードは別のマップを選択し、新しいバインディングを作成する必要があります。このマップを備えた既存のバインディングは、失われると想定できます。他のマップが使用できない場合、モバイルノードはhmipv6を使用しようとしてはなりません。
If a multi-homed mobile node has access to several ARs simultaneously (on different interfaces), it SHOULD use an LCoA on the link defined by the AR that advertises its current MAP.
マルチホームのモバイルノードが複数のARに同時に（異なるインターフェイスで）アクセスできる場合、現在のマップを宣伝するARで定義されたリンクでLCOAを使用する必要があります。
A mobile node MUST store the received option(s) in order to choose at least one MAP to register with. Storing the options is essential, as they will be compared to other options received later for the purpose of the movement detection algorithm.
モバイルノードは、登録する少なくとも1つのマップを選択するために、受信オプションを保存する必要があります。オプションを保存することは不可欠です。移動検出アルゴリズムの目的で、後で受信した他のオプションと比較されるためです。
If the R flag is set, the mobile node MUST place its RCoA in place of the home address in the binding update message. This causes the RCoA to be bound to the LCoA in the MAP's binding cache.
Rフラグが設定されている場合、モバイルノードは、バインディングアップデートメッセージにRCOAをホームアドレスの代わりに配置する必要があります。これにより、RCOAはマップのバインディングキャッシュでLCOAにバインドされます。
A mobile node MAY choose to register with more than one MAP simultaneously, or use both the RCoA and its LCoA as care-of addresses simultaneously with different correspondent nodes.
モバイルノードは、複数のマップを同時に登録するか、RCOAとそのLCOAの両方を異なる特派員ノードと同時にアドレスと同時に使用することを選択できます。
When a mobile node moves into a new MAP domain, the mobile node may send a BU to the previous MAP requesting it to forward packets addressed to the mobile node's new CoA. An administrator MAY restrict the MAP from forwarding packets to LCoAs outside the MAP's domain. However, it is RECOMMENDED that MAPs be allowed to forward packets to LCoAs associated with some of the ARs in neighbouring MAP domains, provided that they are located within the same administrative domain.
モバイルノードが新しいマップドメインに移動すると、モバイルノードは、モバイルノードの新しいCOAにアドレス指定された転送パケットを要求する前のマップにBUを送信する場合があります。管理者は、マップのパケットをマップのドメインの外側のLCOASに転送から制限する場合があります。ただし、同じ管理ドメイン内にある場合、マップは、隣接するマップドメインの一部のARSに関連付けられたLCOASにパケットを転送することをお勧めします。
For instance, a MAP could be configured to forward packets to LCoAs associated with ARs that are geographically adjacent to ARs on the boundary of its domain. This will allow for a smooth inter-MAP handover as it allows the mobile node to continue to receive packets while updating the new MAP, its HA and, potentially, correspondent nodes.
たとえば、マップは、ドメインの境界上のARSに地理的に隣接するARSに関連付けられたLCOASにパケットを転送するように構成できます。これにより、新しいマップ、HA、および潜在的に特派員ノードを更新しながら、モバイルノードがパケットを受信し続けることができるため、スムーズなインターマップハンドオーバーが可能になります。
HMIPv6 provides a flexible mechanism for local mobility management within a visited network. As explained earlier, a MAP can exist anywhere in the operator's network (including the AR). Several MAPs can be located within the same domain independently of each other. In addition, overlapping MAP domains are also allowed and recommended. Both static and dynamic hierarchies are supported.
HMIPV6は、訪問されたネットワーク内でローカルモビリティ管理のための柔軟なメカニズムを提供します。前に説明したように、マップはオペレーターのネットワーク（ARを含む）内のどこにでも存在できます。いくつかのマップは、互いに独立して同じドメイン内に配置できます。さらに、重複するMAPドメインも許可され、推奨されます。静的階層と動的階層の両方がサポートされています。
When the mobile node receives a Router Advertisement including a MAP option, it should perform actions according to the following movement detection mechanisms. In a hierarchical Mobile IP network, such as the one described in this document, the mobile node should be:
モバイルノードがマップオプションを含むルーター広告を受信する場合、次の動き検出メカニズムに従ってアクションを実行する必要があります。このドキュメントで説明されているような階層的なモバイルIPネットワークでは、モバイルノードは次のようにする必要があります。
o "Eager" to perform new bindings.
o 新しいバインディングを実行する「熱心」。
o "Lazy" in releasing existing bindings.
o 既存のバインディングのリリースにおける「怠zy」。
The above means that the mobile node should register with any "new" MAP advertised by the AR (Eager). The method by which the mobile node determines whether the MAP is a "new" MAP is described in Section 9.1. The mobile node should not release existing bindings until it no longer receives the MAP option (or receives it with a lifetime of zero) or the lifetime of its existing binding expires (Lazy). This Eager-Lazy approach, described above, will assist in providing a fallback mechanism in case of the failure of one of the MAP routers, as it will reduce the time it takes for a mobile node to inform its correspondent nodes and HA about its new care-of address.
上記は、モバイルノードがAR（熱心）によって宣伝されている「新しい」マップに登録することを意味します。モバイルノードがマップが「新しい」マップであるかどうかを決定する方法は、セクション9.1で説明されています。モバイルノードは、マップオプションを受信しない（またはゼロの寿命で受信する）または既存のバインディングの有効期限（怠zy）の寿命をかけるまで、既存のバインディングをリリースしないでください。上記のこの熱心なアプローチは、MAPルーターの1つが障害の場合にフォールバックメカニズムを提供するのに役立ちます。これは、モバイルノードが特派員ノードとHAに新しいノードとHAを通知するのにかかる時間を短縮するためです。住所の世話。
The mobile node needs to consider several factors to optimally select one or more MAPs, where several MAPs are available in the same domain.
モバイルノードは、同じドメインでいくつかのマップが利用可能な1つ以上のマップを最適に選択するために、いくつかの要因を考慮する必要があります。
There are no benefits foreseen in selecting more than one MAP and forcing packets to be sent from the higher MAP down through a hierarchy of MAPs. This approach may add forwarding delays and eliminate the robustness of IP routing between the highest MAP and the mobile node; therefore, it is prohibited by this specification. Allowing more than one MAP ("above" the AR) within a network should not imply that the mobile node forces packets to be routed down the hierarchy of MAPs. However, placing more than one MAP "above" the AR can be used for redundancy and as an optimisation for the different mobility scenarios experienced by mobile nodes. The MAPs are used independently of each other by the MN (e.g., each MAP is used for communication to a certain set of CNs).
複数のマップを選択し、マップの階層を介してより高いマップからパケットを送信することを強制することには、予測される利点はありません。このアプローチは、下向きの遅延を追加し、最高のマップとモバイルノードの間のIPルーティングの堅牢性を排除する可能性があります。したがって、この仕様により禁止されています。ネットワーク内の複数のマップ（ "上記のAR）を許可することは、モバイルノードの強制パケットがマップの階層を下にルーティングすることを意味するものではありません。ただし、ARを「上」に「上」に配置すると、モバイルノードが経験するさまざまなモビリティシナリオの最適化にARを使用できます。マップはMNによって互いに独立して使用されます（たとえば、各マップは、特定のCNSセットへの通信に使用されます）。
In terms of the distance-based selection in a network with several MAPs, a mobile node may choose to register with the furthest MAP to avoid frequent re-registrations. This is particularly important for fast mobile nodes that will perform frequent handoffs. In this scenario, the choice of a more distant MAP would reduce the probability of having to change a MAP and informing all correspondent nodes and the HA.
複数のマップを備えたネットワーク内の距離ベースの選択に関して、モバイルノードは、頻繁に再登録されないように、最も遠いマップに登録することを選択できます。これは、頻繁なハンドオフを実行する高速モバイルノードにとって特に重要です。このシナリオでは、より遠いマップを選択すると、マップを変更し、すべての特派員ノードとHAを通知する確率が低下します。
In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need sophisticated algorithms to be able to select the appropriate MAP. These algorithms would have the mobile node speed as an input (for distance-based selection) combined with the preference field in the MAP option. However, this specification proposes that the mobile node use the following algorithm as a default, where other optimised algorithms are not available. The following algorithm is simply based on selecting the MAP that is most distant, provided that its preference value did not reach a value of zero. The mobile node operation is shown below:
1つのドメイン内のモバイルノードによっていくつかのマップが発見されるシナリオでは、モバイルノードが適切なマップを選択できるように洗練されたアルゴリズムが必要になる場合があります。これらのアルゴリズムは、MAPオプションの設定フィールドと組み合わせて、入力（距離ベースの選択）としてモバイルノード速度を使用します。ただし、この仕様は、モバイルノードが次のアルゴリズムをデフォルトとして使用し、他の最適化されたアルゴリズムが使用できないことを提案しています。次のアルゴリズムは、その優先値がゼロの値に達していない限り、最も遠いマップの選択に基づいています。モバイルノード操作を以下に示します。
1. Receive and parse all MAP options.
1. すべてのマップオプションを受信して解析します。
2. Arrange MAPs in a descending order, starting with the furthest MAP (i.e., MAP option having largest Dist field).
2. 最も遠いマップ（つまり、最大のdistフィールドを持つマップオプション）から始まる下降順序でマップを配置します。
3. Select first MAP in list.
3. リストの最初のマップを選択します。
4. If either the preference value or the valid lifetime fields are set to zero, select the following MAP in the list.
4. 優先値または有効な生涯フィールドがゼロに設定されている場合は、リスト内の次のマップを選択します。
5. Repeat step (4) while new MAP options still exist, until a MAP is found with a non-zero preference value and a non-zero valid lifetime.
5. ステップ（4）を繰り返し、新しいマップオプションがまだ存在している間、非ゼロ優先値と非ゼロ有効な寿命でマップが見つかるまで。
Implementing the steps above would result in mobile nodes selecting, by default, the most distant or furthest available MAP. This will continue until the preference value reduces to zero. Following this, mobile nodes will start selecting another MAP.
上記の手順を実装すると、モバイルノードがデフォルトで最も遠いまたは最も遠くのマップを選択します。これは、優先値がゼロに減少するまで続きます。これに続いて、モバイルノードは別のマップの選択を開始します。
Network operators may choose a flat architecture in some cases where a Mobile IPv6 handover may be considered a rare event. In these scenarios, operators may choose to include the MAP function in ARs only. The inclusion of the MAP function in ARs can still be useful to reduce the time required to update all correspondent nodes and the HA. In this scenario, a mobile node may choose a MAP (in the AR) as an anchor point when performing a handoff. This kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR movement is not frequent.
ネットワークオペレーターは、モバイルIPv6のハンドオーバーがまれなイベントと見なされる場合がある場合に、フラットアーキテクチャを選択する場合があります。これらのシナリオでは、オペレーターはARSのみにマップ機能を含めることを選択できます。ARSにマップ関数を含めることは、すべての特派員ノードとHAを更新するのに必要な時間を短縮するのに役立ちます。このシナリオでは、モバイルノードがハンドオフを実行するときにアンカーポイントとしてマップ（AR）を選択する場合があります。この種の動的な階層（または固定）は、AR間の動きが頻繁ではない場合にのみ推奨されます。
This specification introduces a MAP that can be seen as a local home agent in a visited network. A MAP, like a home agent, is a single point of failure. If a MAP fails, its binding cache content will be lost, resulting in loss of communication between mobile and correspondent nodes. This situation may be avoided by using more than one MAP on the same link and by utilising a form of context transfer protocol between them. However, MAP redundancy is outside the scope of this document.
この仕様では、訪問されたネットワークでローカルホームエージェントと見なすことができるマップを紹介します。ホームエージェントのような地図は、単一の失敗ポイントです。マップが故障した場合、バインディングキャッシュコンテンツが失われ、モバイルノードと特派員ノード間の通信が失われます。この状況は、同じリンクで複数のマップを使用し、それらの間にコンテキスト転送プロトコルの形式を使用することにより、回避できます。ただし、MAP冗長性はこのドキュメントの範囲外です。
In cases where such protocols are not supported, the mobile node would need to detect MAP failures. The mobile node can detect this situation when it receives a Router Advertisement containing a MAP option with a lifetime of zero. The mobile node should then start the MAP Discovery process and attempt to register with another MAP. After it has selected and registered with another MAP, it will also need to inform correspondent nodes and the home agent if its RCoA has changed. Note that in the presence of a protocol that transfers binding cache entries between MAPs for redundancy purposes, a new MAP may be able to provide the same RCoA to the mobile node (e.g., if both MAPs advertise the same prefix in the MAP option). This would save the mobile node from updating correspondent nodes and the home agent.
このようなプロトコルがサポートされていない場合、モバイルノードはマップ障害を検出する必要があります。モバイルノードは、生涯ゼロのマップオプションを含むルーター広告を受信すると、この状況を検出できます。モバイルノードは、マップディスカバリープロセスを開始し、別のマップに登録しようとする必要があります。別のマップに選択して登録した後、RCOAが変更された場合は、特派員ノードとホームエージェントに通知する必要があります。冗長性のためにマップ間でバインディングされたキャッシュエントリを転送するプロトコルが存在する場合、新しいマップはモバイルノードに同じRCOAを提供できる場合があります（たとえば、両方のマップがマップオプションで同じプレフィックスを宣伝する場合）。これにより、モバイルノードが特派員ノードとホームエージェントの更新から節約されます。
Access Routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:
アクセスルーターをトリガーして、さまざまな方法でゼロ（マップ障害を示す）でマップオプションを宣伝することができます。
o By manual intervention.
o 手動介入による。
o In a dynamic manner.
o 動的な方法で。
One way of performing dynamic detection of MAP failure can be done by probing the MAP regularly (e.g., every 10 seconds). If no response is received, an AR MAY try to aggressively probe the MAP for a short period of time (e.g., once every 5 seconds for 15 seconds); if no reply is received, a MAP option may be sent with a valid lifetime value of zero. The exact mechanisms for probing MAPs is outside the scope of this document. The above text simply shows one example of detecting failures.
マップ障害の動的検出を実行する1つの方法は、定期的にマップを調査することで実行できます（たとえば、10秒ごと）。応答がない場合、ARは短期間マップを積極的にプローブしようとする場合があります（たとえば、15秒間5秒ごとに1回）。返信がない場合、有効な生涯値がゼロでマップオプションが送信される場合があります。マップを調査するための正確なメカニズムは、このドキュメントの範囲外です。上記のテキストは、単に障害の検出の一例を示しています。
This specification does not mandate a particular recovery mechanism. However, any mechanism between the MAP and an AR SHOULD be secure to allow for message authentication, integrity protection, and protection against replay attacks.
この仕様は、特定の回復メカニズムを義務付けるものではありません。ただし、MAPとARの間のメカニズムは、メッセージ認証、整合性の保護、およびリプレイ攻撃に対する保護を可能にするために安全でなければなりません。
Note that the above suggestion for detecting MAP failure may not detect MAP failures that might take place between probes, i.e.,if a MAP reboots between probes.
マップの障害を検出するための上記の提案は、プローブ間で行われる可能性のあるマップ障害を検出しない場合があることに注意してください。つまり、マップがプローブ間で再起動する場合です。
This specification requires the mobile node to tunnel outgoing traffic to the MAP. Similarly, the MAP tunnels inbound packets to the mobile node. If the mobile node has a home agent elsewhere on the Internet, this will result in double encapsulations of inbound and outbound packets. This may have impacts on the mobile node's path MTU. Hence, mobile nodes MUST consider the encapsulation of traffic between the node and the MAP when calculating the available MTU for upper layers.
この仕様では、マップへの発信トラフィックをトンネルするためのモバイルノードが必要です。同様に、マップトンネルは、モバイルノードにパケットをインバウンドします。モバイルノードにインターネット上の他の場所にホームエージェントがある場合、これにより、インバウンドとアウトバウンドパケットの二重のカプセルが生じます。これは、モバイルノードのPath MTUに影響を与える可能性があります。したがって、モバイルノードは、上層層で使用可能なMTUを計算する際に、ノードとマップ間のトラフィックのカプセル化を考慮する必要があります。
This specification introduces a new concept to Mobile IPv6, namely, a Mobility Anchor Point that acts as a local home agent. It is crucial that the security relationship between the mobile node and the MAP is strong; it MUST involve mutual authentication, integrity protection, and protection against replay attacks. Confidentiality may be needed for payload traffic, such as when the mobile node is unwilling to reveal any traffic to the access network beyond what is needed for the mobile node to attach to the network and communicate with a MAP. Confidentiality is not required for binding updates to the MAP. The absence of any of these protections may lead to malicious mobile nodes impersonating other legitimate ones or impersonating a MAP. Any of these attacks will undoubtedly cause undesirable impacts to the mobile node's communication with all correspondent nodes having knowledge of the mobile node's RCoA.
この仕様では、モバイルIPv6に新しい概念を紹介します。つまり、ローカルホームエージェントとして機能するモビリティアンカーポイントです。モバイルノードとマップのセキュリティ関係が強力であることが重要です。相互認証、整合性の保護、およびリプレイ攻撃に対する保護が必要です。モバイルノードがネットワークに接続してマップと通信するために必要なものを超えてアクセスネットワークへのトラフィックを明らかにしたくない場合など、ペイロードトラフィックには機密性が必要になる場合があります。マップへの更新をバインドするためには、機密性は必要ありません。これらの保護のいずれかがないと、他の正当なものになりすましたり、地図になりすましている悪意のあるモバイルノードにつながる可能性があります。これらの攻撃のいずれかは、モバイルノードのRCOAの知識を持つすべての特派員ノードとのモバイルノードの通信に間違いなく望ましくない影響を引き起こします。
Three different relationships (related to securing binding updates) need to be considered:
3つの異なる関係（拘束力のある更新の確保に関連）を考慮する必要があります。
1. The mobile node - MAP
1. モバイルノード - マップ
2. The mobile node - correspondent node
2. モバイルノード - 特派員ノード
3. The mobile node - home agent
3. モバイルノード - ホームエージェント
In order to allow a mobile node to use the MAP's forwarding service, initial authorisation (specifically for the service, not for the RCoA) MAY be needed. Authorising a mobile node to use the MAP service can be done based on the identity of the mobile node exchanged during the security association (SA) negotiation process. The authorisation may be granted based on the mobile node's identity or based on the identity of a Certificate Authority (CA) that the MAP trusts. For instance, if the mobile node presents a certificate signed by a trusted entity (e.g., a CA that belongs to the same administrative domain, or another trusted roaming partner), it would be sufficient for the MAP to authorise the use of its service. Note that this level of authorisation is independent of authorising the use of a particular RCoA. Similarly, the mobile node trusts the MAP if it presents a certificate signed by the same CA or by another CA that the mobile node is configured to trust (e.g., a roaming partner). It is likely that some deployments would be satisfied with the use of self-signed certificates for either the mobile node or the MAP or both. This guarantees that the mobile node and the MAP are authenticated for address allocation and future binding updates without the need for identity authentication. Hence, the use of trusted third-party certificates is not required by this specification.
モバイルノードがマップの転送サービスを使用できるようにするには、初期認証（特にRCOA用ではなくサービス専用）が必要になる場合があります。マップサービスを使用するモバイルノードの許可は、セキュリティ協会（SA）交渉プロセス中に交換されたモバイルノードのIDに基づいて実行できます。承認は、モバイルノードの身元に基づいて、またはマップが信頼する証明書当局（CA）の身元に基づいて付与される場合があります。たとえば、モバイルノードが信頼できるエンティティ（たとえば、同じ管理ドメインに属するCA、または別の信頼できるローミングパートナーに属するCA）によって署名された証明書を提示する場合、マップがサービスの使用を許可するのに十分です。このレベルの承認は、特定のRCOAの使用を承認することとは無関係であることに注意してください。同様に、モバイルノードは、同じCAまたはモバイルノードが信頼できるように構成されている別のCAによって署名された証明書を提示する場合、マップを信頼します（たとえば、ローミングパートナー）。一部の展開は、モバイルノード、マップ、またはその両方に自己署名された証明書を使用することに満足する可能性があります。これにより、モバイルノードとマップが、アイデンティティ認証を必要とせずにアドレス割り当てと将来のバインディングアップデートに対して認証されていることが保証されます。したがって、この仕様では、信頼できるサードパーティ証明書の使用は必要ありません。
It is important to note that in this specification, authentication and authorisation are effectively the same thing. All the MAP needs in order to allocate the mobile node an RCoA is to authenticate the mobile node and verify that it belongs to a trusted group (based on its certificate).
この仕様では、認証と承認が事実上同じものであることに注意することが重要です。すべてのマップは、モバイルノードを割り当てるために必要ですRCOAは、モバイルノードを認証し、それが信頼できるグループに属していることを確認することです（証明書に基づいて）。
IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows the use of Extensible Authentication Protocol (EAP) as a mechanism to bootstrap the security association between the communicating peers.
IKEV2は、モバイルノードとマップでサポートする必要があります。IKEV2では、通信ピア間のセキュリティ関連をブートストラップするメカニズムとして、拡張可能な認証プロトコル（EAP）を使用できます。
Hence, EAP can be used with IKEv2 to leverage the Authentication, Authorization, and Accounting (AAA) infrastructure to bootstrap the SA between the mobile node and the MAP. Such a mechanism is useful in scenarios where an administrator wishes to avoid the configuration and management of certificates on mobile nodes. A MAP MAY support the use of EAP over IKEv2.
したがって、EAPをIKEV2で使用して、モバイルノードとマップ間でSAをブートストラップするために、認証、承認、および会計（AAA）インフラストラクチャを活用できます。このようなメカニズムは、管理者がモバイルノード上の証明書の構成と管理を回避したいシナリオで役立ちます。マップは、IKEV2を介したEAPの使用をサポートする場合があります。
If EAP is used with IKEv2, the EAP method runs between the mobile node and a AAA server. Following a successful authentication, the resulting keying material can be used to bootstrap IKEv2 between the MAP and the mobile node. The specification of which EAP methods should be used or how keys are transported between the MAP and the AAA server is outside the scope of this document.
EAPがIKEV2で使用される場合、EAPメソッドはモバイルノードとAAAサーバーの間で実行されます。認証が成功した後、結果のキーイング材料を使用して、マップとモバイルノードの間でIKEV2をブートストラップすることができます。どのEAPメソッドを使用するか、またはマップとAAAサーバー間でキーをどのように輸送するかの仕様は、このドキュメントの範囲外です。
HMIPv6 uses an additional registration between the mobile node and its current MAP. As explained in this document, when a mobile node moves into a new domain (i.e., served by a new MAP), it obtains an RCoA and an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies the BU and creates a binding cache entry with the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to send a new BU that specifies the binding between its RCoA and its new LCoA. This BU needs to be authenticated; otherwise, any host could send a BU for the mobile node's RCoA and hijack the mobile node's packets.
HMIPV6は、モバイルノードとその現在のマップの間に追加の登録を使用します。このドキュメントで説明したように、モバイルノードが新しいドメインに移動すると（つまり、新しいマップで提供される）、RCOAとLCOAを取得し、新しいマップでこれら2つのアドレス間のバインディングを登録します。次に、マップはBUを検証し、RCOAおよびLCOAを使用してバインディングキャッシュエントリを作成します。モバイルノードが新しいLCOAを取得するたびに、RCOAと新しいLCOAの間のバインディングを指定する新しいBUを送信する必要があります。このBUは認証する必要があります。それ以外の場合、どのホストもモバイルノードのRCOAにBUを送信し、モバイルノードのパケットをハイジャックできます。
The MAP does not need to have prior knowledge of the identity of the mobile node or its home address. As a result, the SA between the mobile node and the MAP can be established using any key establishment protocols such as IKEv2. A return routability test is not necessary.
マップは、モバイルノードまたはその自宅の住所のIDの事前の知識を持つ必要はありません。その結果、IKEV2などの主要な確立プロトコルを使用して、モバイルノードとマップ間のSAを確立できます。返品ルー上のテストは必要ありません。
The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKEv2 [RFC4306]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA.
マップは、RCOA（LCOAではなく）にSAを設定する必要があります。これは、IKEV2 [RFC4306]で実行できます。モバイルノードはLCOAをソースアドレスとして使用しますが、RCOAをSAで使用する必要があることを指定します。
This is achieved by using the RCoA as the identity in the IKE CHILD_SA negotiation. This step is identical to the use of the home address in IKE CHILD_SA when negotiating with the home agent.
これは、RCOAをIKE Child_Sa交渉のアイデンティティとして使用することによって達成されます。このステップは、ホームエージェントと交渉する際のIKE Child_SAのホームアドレスの使用と同じです。
The IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] for allocating dynamic home addresses SHOULD be used by the MAP to allocate the RCoA for mobile nodes. Binding updates between the MAP and the mobile node MUST be protected with either Authentication Header (AH) or Encapsulating Security Payload (ESP) in transport mode. When ESP is used, a non-null authentication algorithm MUST be used.
[RFC4877]に記載されているIPSEC PEER AUTHORIZINGデータベース（PAD）エントリと構成ペイロードは、動的ホームアドレスを割り当てるためにMAPで使用して、モバイルノードにRCOAを割り当てる必要があります。マップとモバイルノード間のバインディングの更新は、輸送モードで認証ヘッダー（AH）またはセキュリティペイロード（ESP）をカプセル化することで保護する必要があります。ESPを使用する場合、非ヌル認証アルゴリズムを使用する必要があります。
The Security Policy Database (SPD) entries in both the home agent and the mobile node are identical to those set up for the home agent and mobile node, respectively, as outlined in [RFC4877].
[RFC4877]で概説されているように、ホームエージェントとモバイルノードの両方のセキュリティポリシーデータベース（SPD）エントリは、それぞれホームエージェントとモバイルノードに設定されたエントリと同じです。
Mobile IPv6 [RFC3775] defines a return routability procedure that allows mobile and correspondent nodes to authenticate binding updates and acknowledgements. This specification does not impact the return routability test defined in [RFC3775]. However, it is important to note that mobile node implementers need to be careful when selecting the source address of the HoTI and CoTI messages, defined in [RFC3775]. The source address used in HoTI messages SHOULD be the mobile node's home address unless the mobile node wishes to use the RCoA for route optimisation. The packet containing the HoTI message is encapsulated twice. The inner encapsulating header contains the RCoA in the source address field and the home agent's address in the destination address field. The outer encapsulating header contains the mobile node's LCoA in the source address field and the MAP's address in the destination field.
モバイルIPv6 [RFC3775]は、モバイルおよび特派員のノードがバインディングの更新と謝辞を認証できるようにするリターンルー上のルー上の手順を定義します。この仕様は、[RFC3775]で定義されている返品ルー上のテストには影響しません。ただし、[RFC3775]で定義されているHOTIおよびCOTIメッセージのソースアドレスを選択する際には、モバイルノードの実装者が注意する必要があることに注意することが重要です。HOTIメッセージで使用されるソースアドレスは、モバイルノードがRCOAを使用してルートの最適化に使用したい場合を除き、モバイルノードのホームアドレスである必要があります。hotiメッセージを含むパケットは2回カプセル化されています。内側のカプセル化ヘッダーには、ソースアドレスフィールドにRCOAと宛先アドレスフィールドにホームエージェントのアドレスが含まれています。外側のカプセル化ヘッダーには、ソースアドレスフィールドにモバイルノードのLCOAと宛先フィールドにマップのアドレスが含まれています。
The security relationship between the mobile node and its home agent, as discussed in [RFC3775], is not impacted by this specification.
[RFC3775]で説明したように、モバイルノードとそのホームエージェントのセキュリティ関係は、この仕様の影響を受けません。
The relationship between the MAP and the mobile node is not impacted by the presence of a home agent.
マップとモバイルノードの関係は、ホームエージェントの存在によって影響を受けません。
Both the MAP option and M flag were allocated for RFC 4140 and will continue to be used by this specification.
MAPオプションとMフラグの両方がRFC 4140に割り当てられ、この仕様では引き続き使用されます。
The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this document. The authors would also like to thank the members of the French RNRT MobiSecV6 project (BULL, France Telecom, and INRIA) for testing the first implementation and for their valuable feedback. The INRIA HMIPv6 project is partially funded by the French government.
著者は、この文書への貴重な入力について、Conny Larsson（Ericsson）とMattias Pettersson（Ericsson）に感謝したいと思います。著者はまた、最初の実装のテストと貴重なフィードバックについて、フランスのRNRT MobiseCv6プロジェクト（Bull、France Telecom、およびInRIA）のメンバーに感謝したいと思います。INRIA HMIPV6プロジェクトは、フランス政府によって部分的に資金提供されています。
In addition, the authors would like to thank the following members of the working group, in alphabetical order: Samita Chakrabarti (Sun), Gregory Daley, Gopal Dommety (Cisco), Francis Dupont (GET/Enst Bretagne), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti Kuparinen (Ericsson), Fergal Ladley, Gabriel Montenegro (Microsoft), Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt, and Alper Yegin (Samsung) for their comments on the document.
さらに、著者は、アルファベット順に、以下のワーキンググループのメンバーに感謝したいと思います。サミタ・チャクラバルティ（太陽）、グレゴリー・デイリー、ゴパル・ドメティ（シスコ）、フランシス・デュポン（get/enst bretagne）、エヴァ・ガスタフソン（エリクソン）、デイブ・ジョンソン（ライス大学）、アニカ・ジョンソン（エリクソン）、ジェームズ・ケンプフ（ドココ・ラボ）、マルティ・クパリネン（エリクソン）、ファーガル・ラドリー、ガブリエル・モンテネグロ（マイクロソフト）、ニック・「ムーア」（Sun）、Basavaraj Patil（Nokia）、Brett Pentland（NEC）、Thomas Schmidt、およびAlper Yegin（Samsung）の文書に関するコメントについて。
[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月。
[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月。
[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月。
[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月。
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.
[RFC4449] Perkins、C。、「静的共有キーを使用したモバイルIPv6ルート最適化の保護」、RFC 4449、2006年6月。
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[RFC4651] Vogt、C。およびJ. Arkko、「モバイルIPv6ルート最適化の強化の分類と分析」、RFC 4651、2007年2月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866] Arkko、J.、Vogt、C。、およびW. Haddad、「モバイルIPv6の拡張ルート最適化」、RFC 4866、2007年5月。
o Dynamic MAP Discovery was removed.
o 動的マップの発見が削除されました。
o Updated the security section to use IKEv2 instead of IKEv1.
o IKEV1の代わりにIKEV2を使用するようにセキュリティセクションを更新しました。
o The document clarified that HMIPv6 can be used without the need for a home agent.
o このドキュメントは、HMIPV6をホームエージェントを必要とせずに使用できることを明らかにしました。
o Several editorials throughout the document.
o ドキュメント全体のいくつかの社説。
o IKEv2 only is now used to allocate the RCoA.
o IKEV2のみがRCOAの割り当てに使用されるようになりました。
RFC 4140 was implemented and interop tested by at least two different organisations. A test suite including test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP Discovery, defined in RFC 4140, was seen as inappropriate for large-scale deployments and prone to loops. It was removed from this specification.
RFC 4140が実装され、少なくとも2つの異なる組織によってインタープットテストが行われました。RFC 4140のテストケースを含むテストスイートもEricssonによって開発され、両方の実装に反して実行されました。大きな問題は見つかりませんでした。RFC 4140で定義されている動的マップ発見のスケーラビリティは、大規模な展開には不適切であり、ループが発生しやすいと見なされていました。この仕様から削除されました。
At this time, there is no publicly known deployment of this specification.
現時点では、この仕様の公開展開はありません。
Authors' Addresses
著者のアドレス
Hesham Soliman Elevate Technologies
Hesham Soliman Elevate Technologies
EMail: hesham@elevatemobile.com
Claude Castelluccia INRIA
Claude Castelluccia inria
Phone: +33 4 76 61 52 15
EMail: claude.castelluccia@inria.fr
Karim ElMalki Athonet
Karim Elmalki Athonet
EMail: karim@elmalki.homeip.net
Ludovic Bellier INRIA
Ludovic Bellier Inria
EMail: ludovic.bellier@inria.fr
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。