Network Working Group H. Soliman
Request for Comments: 4140 Flarion
Category: Experimental C. Castelluccia
INRIA
K. El Malki
Ericsson
L. Bellier
INRIA
August 2005
Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 Operation ...........................................6
4. Mobile IPv6 Extensions ..........................................8
4.1. Local Binding Update .......................................8
5. Neighbour Discovery Extension: The MAP Option Message Format ....9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................10
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................12
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................13
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................14
7.1. Dynamic MAP Discovery .....................................14
7.1.1. Router Operation for Dynamic MAP Discovery .........15
7.1.2. MAP Operation for Dynamic MAP Discovery ............15
7.2. Mobile Node Operation .....................................16
8. Updating Previous MAPs .........................................16
9. Notes on MAP Selection by the Mobile Node ......................17
9.1. MAP Selection in a Distributed-MAP Environment ............17
9.2. MAP Selection in a Flat Mobility Management Architecture ..19
10. Detection and Recovery from MAP Failures ......................19
11. IANA Considerations ...........................................20
12. Security Considerations .......................................20
12.1. Mobile Node-MAP Security ................................20
12.2. Mobile Node-Correspondent Node Security .................22
12.3. Mobile Node-Home Agent Security .........................22
13. Acknowledgments ...............................................22
14. References ....................................................23
14.1. Normative References ....................................23
14.2. Informative References ..................................23
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................24
This memo introduces the concept of a Hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).
このメモは、モビリティアンカーポイント（MAP）と呼ばれる新しいノードを利用し、階層化Mobile IPv6ネットワークの概念を導入しています。
Mobile IPv6 [1] allows nodes to move within the Internet topology while maintaining reachability and on-going connections between mobile and correspondent nodes. To do this a mobile node sends Binding Updates (BUs) to its Home Agent (HA) and all Correspondent Nodes (CNs) it communicates with, every time it moves. 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). In addition, one round-trip time is needed to update the Home Agent; this can be done simultaneously while updating correspondent nodes. The re-use of the home cookie (i.e., eliminating HOTI/HOT) will not reduce the number of round trip times needed to update correspondent nodes. These round trip delays will disrupt active connections every time a handoff to a new AR is performed. Eliminating this additional delay element from the time-critical handover period will significantly improve the performance of Mobile 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 [1]到達可能とモバイルとコレスポンデントノードとの間で進行中の接続を維持しながら、ノードがインターネットトポロジ内で移動することを可能にします。これを行うために、モバイルノードは、そのホームエージェント（HA）と、それが通信するすべての対応ノード（CNS）、それが動くたびに結合更新（バス）を送信します。バインディング更新を認証する（最良の場合のシナリオ、すなわち、パケットロス全体リターン・ルータビリティ手順のための）モバイルノードと各コレスポンデントノードとの間に約1.5往復時間を必要とします。また、1ラウンドトリップ時間は、ホームエージェントを更新するために必要とされています。コレスポンデントノードを更新しながら、これを同時に行うことができます。ホームクッキー（すなわち、のHoTI / HOTを排除する）の再利用は、通信員ノードを更新するために必要な往復回数を減らすことはありません。これらの往復遅延は、アクティブな接続に新しいARへのハンドオフが実行されるたびに中断されます。タイムクリティカルなハンドオーバ期間からこの追加の遅延要素を排除すると、大幅にモバイルIPv6のパフォーマンスが向上します。また、無線リンクの場合には、そのような解決策は、すべての対応ノードとホーム・エージェントへのエアインタフェースを介して送信されたメッセージの数を減らします。ローカルのアンカーポイントもモバイル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). Unlike Foreign Agents in IPv4, a MAP is not required on each subnet. The MAP will limit the amount of Mobile IPv6 signalling outside the local domain. The introduction of the MAP provides a solution to the issues outlined earlier in the following way:
これらの理由から新しいモバイルIPv6ノードのために、モビリティ・アンカー・ポイントと呼ばれ、使用され、アクセスルータ（AR）を含むルータの階層ネットワーク内の任意のレベルに配置することができます。 IPv4の外国人のエージェントとは異なり、MAPは、各サブネット上で必要とされていません。 MAPは、ローカルドメイン外のモバイルIPv6シグナリングの量を制限します。 MAPの導入は、次のように前に述べた問題への解決策を提供します。
- The mobile node sends Binding Updates to the local MAP rather than the HA (which is typically further away) and CNs
- モバイルノードは、ローカルMAPなく（さらに離れて、典型的に）HAおよびCNSへの結合更新を送信します
- Only one Binding Update message needs to be transmitted by the MN before traffic from the HA and all CNs is re-routed to its new location. This is independent of the number of CNs that the MN is communicating with.
- 一つだけBinding Updateメッセージは、HAとすべてのCNからのトラフィックは、その新しい場所に再ルーティングされる前に、MNによって送信される必要があります。これは、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. It also supports Fast Mobile IPv6 Handovers to help Mobile Nodes achieve seamless mobility (see
MAPは、基本的にローカルホームエージェントです。モバイルIPv6における階層的モビリティ管理モデルを導入する目的は、モバイルIPv6、または他のIPv6プロトコルへの影響を最小限に抑えながら、モバイルIPv6の性能を向上することです。また、モバイルノードは、シームレスなモビリティを達成するのを助けるために、高速モバイルIPv6ハンドオーバをサポートしています（参照
Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and Home Agents while using Mobile IPv6 route optimisation.
付録A）。また、HMIPv6のはモバイルIPv6ルート最適化を使用しながら、モバイルノードがコレスポンデント・ノードとホーム・エージェントから自分の位置を隠すことを可能にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。
In addition, new terms are defined below:
また、新しい用語を以下に定義されています。
Access Router (AR) The AR is the Mobile Node's default router. The AR aggregates the outbound traffic of mobile nodes.
アクセスルータ（AR）ARは、モバイルノードのデフォルトルータです。 ARは、モバイルノードのアウトバウンドトラフィックを集約します。
Mobility Anchor Point A Mobility Anchor Point is a router located (MAP) 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.
モビリティアンカーポイントAモビリティ・アンカー・ポイントは、モバイルノードが訪問先ネットワークに位置するルータ（MAP）です。 MAPは、ローカルHAとしてMNによって使用されます。一つ以上のMAPは、訪問先ネットワーク内に存在することができます。
Regional Care-of An RCoA is an address obtained by the Address (RCoA) mobile node from the visited network. An RCoA is an address on the MAP's subnet. It is auto-configured by the mobile node when receiving the MAP option.
リージョナル気付のRCoAは、訪問先ネットワークからのアドレス（RCoAを）移動ノードによって得られたアドレスです。 RCoAをは、MAPのサブネット上のアドレスです。これは、自動設定MAPオプションを受信したとき、移動ノードです。
HMIPv6-aware An HMIPv6-aware mobile node is a mobile Mobile Node 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の認識アンのHMIPv6対応のモバイルノードは、受信したMAPオプションがデフォルトのルータから受信し処理することができますモバイルモバイルノードのノードです。 HMIPv6の対応モバイルノードは、（Mフラグが設定されたバインディング更新）、ローカルバインディングアップデートを送信することができなければなりません。
On-link Care-of The LCoA is the on-link CoA configured on Address (LCoA) a mobile node's interface based on the prefix advertised by its default router. In [1], this is simply referred to as the Care-of-address. However, in this memo LCoA is used to distinguish it from the RCoA.
オンリンクのLCoA気付アドレス（のLCoA）そのデフォルトルータによってアドバタイズプレフィックスに基づいて、移動ノードのインターフェイスに設定されたオンリンクのCoAです。 [1]において、これは単に気付アドレスと呼ばれます。しかし、このメモでの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の間の結合を確立するために、MAPにローカルバインディングアップデートを送信します。
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 operation will not be affected.
この階層化Mobile IPv6の方式は、モバイルノードの操作に新しい機能、MAP、およびマイナーの拡張機能を紹介します。コレスポンデントノードとホームエージェントの動作には影響しません。
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 on 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 the correspondent nodes it is communicating with.
MAPドメインに入るモバイルノードは、1つのまたは複数のローカルマップの情報を含むルータ広告を受信することになります。 MNは、MAPのサブネット（RCoAを）上のアドレスと現在の場所（オンリンクCoA）をバインドすることができます。ローカルHAとして動作し、MAPは、それがサービスを提供しているモバイルノードの代わりにすべてのパケットを受信すると、移動ノードの現在のアドレスに直接それらをカプセル化して転送します。モバイルノードがローカルMAPドメイン（のLCoA）中の現在のアドレスを変更した場合、それが唯一のMAPに新しいアドレスを登録する必要があります。したがって、唯一の地域の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.
MAPドメインの境界は、添付のモバイルノードにMAP情報を広告するアクセスルータ（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対応のモバイルノードは、訪問先ネットワークにそのような機能を発見したときにMAPを使用することを選択する必要があります。しかし、いくつかのケースでは、モバイルノードは、単に標準のモバイルIPv6の実装を使用することを好むかもしれません。例えば、モバイルノードは、そのホームサイト内の訪問先ネットワーク内に配置することができます。この場合、HAは、訪問先ネットワークのそばに位置し、代わりにMAPを使用することができます。それが移動するたびに、このシナリオでは、モバイルノードは、HAを更新することになります。 HAは、MN（例えば、同じ部位）の近傍にあるかどうかを決定するための方法は、この文書の範囲外です。
The network architecture shown in Figure 1 illustrates an example of the use of the MAP in a visited network.
図1に示されるネットワークアーキテクチャは、訪問先ネットワーク内のMAPの使用の例を示す図です。
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では、MAPは、コレスポンデントノードとの通信中に、それは、アクセスルータ2（AR2）へのアクセスルータ1（AR1）から移動するモバイルノードのためのシームレスな移動性を提供するのに役立つことができます。マルチレベル階層は、より高いハンドオーバ性能のために必要とされません。したがって、オペレータのネットワーク内の任意の位置に1つの以上のMAP（おそらく同じ領域をカバーする）を見つけるのに十分です。
+-------+
| 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.
訪問先ネットワークで到着すると、移動ノードは、MAPのグローバルアドレスを発見するでしょう。このアドレスは、アクセスルータに記憶され、ルータ広告（RAS）を介してモバイルノードに伝達されます。 RAのための新しいオプションが、後に、この仕様で定義されています。これは、MAP（MAPディスカバリ）の存在についてモバイルノードに通知するために必要とされます。発見フェーズは、モバイルノードからのMAPの距離の移動ノードに通知します。図1に示すように、例えば、MAPの機能を実現することができ、そして、同時に、また、AR1及びAR2内に実装されます。この場合、モバイルノードは、最初のホップマップまたはルータの階層にアップさらに、1つを選択することができます。 MAPを選択する方法についての詳細はセクション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 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.
MAP発見のプロセスは、次の1つのサブネットから移動ノードが移動するように継続します。モバイルノードが移動を検出するたびに、それはまた、同じMAPドメインにまだあるかどうかを検出します。動きを検出するために使用されるルータ広告も、それは同じMAPドメインにまだあるかどうか、MAPオプションを使用して、モバイルノードに通知します。モバイルノードがMAPドメイン内でローミングすると、それはそのARからのルータアドバタイズメントに含まれ、同じMAPオプションを受信し続けます。アドバタイズされたMAPのアドレスの変更を受信した場合、モバイルノードは、その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 [1] 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. 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の対応ではない場合、何のMAP検出は、移動性管理のためのモバイルIPv6 [1]のプロトコルを使用してモバイルノードに得られ、実行されません。一方、モバイルノードがHMIPv6の-認識している場合には、そのHMIPv6の実装を使用することを選択する必要があります。もしそうなら、モバイルノードは、最初にそのホームアドレスとオンリンクのアドレス（のLCoA）を含むBUを送信することにより、MAPに登録する必要があります。 BUで使用されるホームアドレスはRCoAをです。 MAPは、異なる対応ノードから受信した、またはしたときに、それらの最終的な宛先にパケットを転送することができるように、そのバインディングキャッシュにこの情報を格納しなければなりません。
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 [1]) will give the mobile node the necessary information.
モバイルノードは、常に、ルート最適化が必要かどうかを判断するために任意の受信したパケットの元の送信者を知っておく必要があります。 MAPは、元のパケットの内容を変更していないため、この情報は、移動ノードに利用できるようになります。モバイルノードに必要な情報を与える（[1]に記載のように）受信したパケットの通常の処理。
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 Fig 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 [1]. 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.
より効率的な方法でネットワーク帯域幅を使用するように、モバイルノードは、同時に複数のマップに登録し、相手ノードの特定のグループのそれぞれのMAPアドレスを使用することを決定することができます。コレスポンデントノードは、モバイルノードと同じリンク上に存在するように発生した場合、例えば、図1に、それらの間の通信のために（この場合、それはAR1であると仮定する）最初のホップ・マップを使用する方が効率的であろう。これは、階層内で「最高」MAP経由ですべてのパケットを送信しないようになるため、ネットワーク帯域幅のより効率的な使用になります。モバイルノードは、[1]で指定されるように、CoAとしてその現在のオンリンクアドレス（のLCoA）を使用することができます。モバイルノードが別のMAPに送信されたバインディング更新中のLCoAとしてMAPのサブネットからのRCoAが存在しない必要があります。バインディングアップデートに含まれてのLCoAは、そのリンクで宣伝接頭語に由来し、移動ノードのアドレスであるに違いありません。
If a router advertisement is used for MAP discovery, as described in this document, all ARs belonging to the MAP domain MUST advertise the MAP's IP address. The same concept (advertising the MAP's presence within its domain) should be used if other methods of MAP discovery are introduced in future.
ルータ広告は、MAPの発見のために使用されている場合は、この文書で説明したように、MAPドメインに属するすべてのARはMAPのIPアドレスをアドバタイズする必要があります。 MAP発見の他の方法は、将来的に導入されている場合（そのドメイン内のMAPの存在を宣伝する）同じ概念を使用する必要があります。
This section outlines the extensions proposed to the binding update specified in [1].
このセクションでは、[1]で指定されたバインディング更新に提案された拡張機能の概要を示します。
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フラグを、MAP登録を指示します。移動ノードがMAPに登録する場合、Mおよびフラグは、HA又はコレスポンデントノードに送信されるBUから、この登録を区別するために設定しなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description of extensions to the binding update:
バインディングアップデートの拡張機能の説明：
M If set to 1 it indicates a MAP registration.
1に設定した場合Mは、それがMAP登録を示します。
It should be noted that this is an extension to the Binding update specified in [1].
[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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Type IPv6 Neighbor Discovery option. 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. Its default value SHOULD be set to 1 if Dynamic MAP discovery is used. The Distance MUST be set to 1 if the MAP is on the same link as the mobile node. This field need not be interpreted as the number of hops between MAP and the mobile node. The only requirement is that the meaning of the Distance field is consistently interpreted within one Domain. A Distance value of Zero MUST NOT be used.
DIST A MAP及び広告の受信機との間の距離を特定する4ビットの符号なし整数。動的MAP探索が使用されている場合は、そのデフォルト値が1に設定する必要があります。 MAPは、移動ノードと同じリンク上にある場合の距離は1に設定しなければなりません。このフィールドは、MAPと移動ノード間のホップの数として解釈される必要はありません。唯一の要件は、距離フィールドの意味は一貫して1つのドメイン内で解釈されていることです。ゼロの距離値を使用してはいけません。
Pref The preference of a MAP. A 4-bit unsigned integer. A decimal value of 15 indicates the highest availability.
県MAPの好み。 4ビットの符号なし整数。 15の10進値は、最高の可用性を示します。
R When set to 1, it indicates that the mobile node MUST form an RCoA based on the prefix in the MAP option.
1に設定すると、Rは、移動ノードがMAPオプションでプレフィックスに基づいたRCoAを形成しなければならないことを示しています。
Valid Lifetime The minimum value (in seconds) of both the preferred and valid lifetimes of the prefix assigned to the MAP's subnet. This value indicates the validity of the MAP's address and consequently the time for which the RCoA is valid.
MAPのサブネットに割り当てられたプレフィックスの優先及び有効寿命の両方の有効期間（秒）最小値。この値は、MAPのアドレスとRCoAをが有効であるために、結果として時間の有効性を示します。
Global Address One of the MAP's global addresses. The 64-bit prefix extracted from this address MUST be configured in the MAP to be used for RCoA construction by the mobile node.
グローバルアドレスMAPのグローバルアドレスの一つ。このアドレスから抽出された64ビットのプレフィックスは、モバイルノードによってRCoAを構築するために使用されるマップで構成されなければなりません。
Although not explicitly included in the MAP option, the prefix length of the MAP's Global IP address MUST be 64. This prefix is the one used by the mobile node to form an RCoA, by appending a 64-bit identifier to the prefix. Thus, it necessitates a static prefix length for the MAP's subnet.
明示的MAPオプションに含まれていないが、MAPのグローバルIPアドレスのプレフィックス長は64でなければなりませんこのプレフィックスは、プレフィックスと64ビットの識別子を付加することにより、RCoAを形成するためにモバイルノードによって使用されるものです。したがって、MAPのサブネットの静的プレフィックス長が必要となります。
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のでは、モバイルノードは二つのアドレス、MAPのリンク上の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とコレスポンデントノードは変更されません。 MAPはのLCoAに、モバイルノードのRCoAを特異的に結合する「ローカル」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). The RCoA is formed in a stateless manner. After forming the RCoA based on the prefix received in the MAP option, 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 [1] 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 a HA) will then perform DAD (when a new binding is being created) for the mobile node's RCoA on its link and return a Binding Acknowledgement to the MN. This acknowledgement 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.
MAPのリンク上のRCoAとオンリンクのCoA（のLCoA）：モバイルノードが新しいMAPドメイン（すなわち、そのMAPの変更）に移動すると、それは2つのCoAを設定する必要があります。 RCoAはステートレスように形成されています。 MAPオプションで受信されたプレフィックスに基づいたRCoAを形成した後、モバイルノードは、セットAとMフラグをMAPにローカルBUを送信します。ローカルBUは、[1]で定義されたBUで、ホームアドレスオプションでモバイルノードのRCoAをを含んでいます。いいえ代替-CoAのオプションは、このメッセージには必要ありません。 LCoAのは、BUの送信元アドレスとして使用されています。このBUは、そののLCoAにモバイルノードのRCoAを（ホームアドレスに類似）に結合します。 （HAとして動作する）MAPは、そのリンク上のモバイルノードのRCoAをするために（新しいバインディングが作成されている）DADを実行し、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.
MAPとの登録が成功した後、モバイルノードとMAPとの間の双方向トンネルが確立されます。モバイルノードによって送信されたすべてのパケットはMAPにトンネリングされます。外部ヘッダは、ソースアドレスフィールド内のモバイルノードののLCoA及び宛先アドレスフィールド内のMAPのアドレスを含んでいます。インナーヘッダは、ソースアドレスフィールド内のモバイルノードのRCoAを宛先アドレスフィールド内のピアのアドレスを含みます。 MAPによってインターセプトされ、モバイルノードののLCoAにトンネリングされる。同様に、すべてのパケットは、モバイルノードのRCoAを宛。
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 MUST 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.
この仕様は、それが複数のMAPオプションを受け取った場合、移動ノードが複数のRCoAを使用することができます。この場合、移動ノードは、それぞれのRCoAに対する結合更新手順を実行する必要があります。加えて、移動ノードは気付アドレスのバインディング更新中の別のMAP（例えば、MAP2）のようなマップの接頭辞（例えば、MAP1）由来のものの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.
MAPに登録した後、モバイルノードは、モバイルIPv6のように結合（RCoAを、ホームアドレス）を指定BUを送信することによって、そのHAとの新しいのRCoAを登録する必要があります。モバイルノードのホームアドレスはホームアドレスオプションで使用されたRCoAを気付アドレス送信元アドレスフィールドのように使用されています。モバイルノードは、その現在のコレスポンデントノードへ（すなわち、そのホームアドレスとRCoAを間の結合を指定する）同様のBUを送信することができます。
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering with its HA. 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.
モバイルノードは、そのHAに登録する前に、MAPからバインディング確認応答を待つ必要があります。 HAとコレスポンデントノードとのRCoAを結合するとき、結合寿命が結合確認に受信される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.
MAP間のハンドオーバをスピードアップし、パケットロスを低減させるために、モバイルノードは、その新しいのLCoAを指定して、その前のMAPにローカルBUを送るべきです。前のMAPに到達輸送中のパケットは、新しいの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.
パケットを受信するMAPは、（HA又はコレスポンデントノードからの）モバイルノードのRCoAを宛て。パケットは、モバイルノードののLCoAにMAPからトンネルされます。モバイルノードは、パケットを脱capsulateれ、それらは通常の方法で処理します。
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.
モバイルノードが同じMAPドメイン内を移動すると、それだけでそのMAPとの新しいのLCoAを登録する必要があります。この場合、RCoAをは変わりません。
Note that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes, which are connected to its same link. Packets will then be routed directly without going through the MAP.
モバイルノードが同じリンクに接続されているコレスポンデントノードに（代わりに、そのRCoAをの）そののLCoAを含むBUを送信することができることに留意されたいです。パケットはその後、MAPを経由せずに直接ルーティングされます。
The mobile node can communicate with a correspondent node through the HA, or in a route-optimised manner, as described in [1]. When communicating through the HA, the message formats in [1] can be re-used.
[1]に記載されているように、モバイルノードは、HAを介して、または経路最適化方法で通信相手ノードと通信することができます。 HAを介して通信する場合、メッセージ・フォーマットは、[1]に再使用することができます。
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 [1], 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.
モバイルノードは、コレスポンデントノードと直接通信する場合、同じ気付けコレスポンデント・ノードにおけるバインディングキャッシュエントリを作成するために使用されるアドレス（RCoAをし、モバイルノードが使用しなければならない（すなわち、CNは、モバイルノードの結合キャッシュエントリがあります） ）送信元アドレスとして。 [1]によると、モバイルノードは、発信パケットでホームアドレスオプションを含まなければなりません。ホームアドレスオプションは、モバイルノードのホームアドレスを含まなければなりません。
The MAP acts like a HA; it intercepts all packets addressed to registered mobile nodes and tunnels them to the corresponding LCoA, which is stored in its binding cache.
MAPは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 inform the MAP that the mobile node has formed an RCoA (contained in the BU as a Home address). 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 [1]. 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.
MAPは、モバイルノードのホームアドレスの知識を持ちません。モバイルノードは、Mと設定されたフラグとMAPにローカルBUを送信します。このBUの目的は、モバイルノードが（ホームアドレスとしてBUに含まれる）のRCoAを形成したことをMAPに通知することです。成功した場合、MAPは、成功した登録を示す、モバイルノードに結合肯定応答を返さなければなりません。これは、[1]における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.
MAPは、移動ノードがトンネルエントリポイントであるとMAPは、トンネル出口ポイントであると、モバイルノードからトンネルパケットを受け入れることができなければなりません。
The MAP acts as a 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 [1].
MAPは、RCoAをのためのHAとして機能します。プロキシ近隣広告を使用して、MAPによって傍受した後、カプセル化され、モバイルノードののLCoAにルーティングされたパケットは、RCoA宛。この動作は、HAの[1]に記載のと同じです。
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 to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile 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).
MAPは、モバイルノードがのLCoAを導出するために使用できる有効なオンリンクプレフィックスのリストを用いて構成することができます。ネットワークオペレータが異なる管理ドメインに移動した後、MAPを使用し続けることから、移動ノードを停止するのに便利です。モバイルノードは、MAPの「有効なオンリンクプレフィックス」リストにないのLCoAを含むバインディングアップデートを送信した場合、MAPは、既存のエラーコード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 [1].
HMIPv6のサポートは、HAの操作に対して完全に透過的です。パケットは、モバイルノードのホームアドレス宛に記載されているように、[1]、そのRCoAをするHAによって転送されます。
HMIPv6 is completely transparent to correspondent nodes.
HMIPv6のは、コレスポンデントノードに対して完全に透過的です。
In [1], 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.
[1]、容易に故障の際に再試行することができる短期の通信、特に通信のために、モバイルノードは、このように必要としない、直接パケットのソースとしての気付アドレスのいずれかを使用することを選択するかもしれないことに記載されているにパケット内のホームアドレスオプションを使用します。 CoAをこのような使用は、追加オプションが存在しないために、各パケットを送信するのオーバーヘッドを削減します。また、モバイルノードとコレスポンデントノードとの間の最適経路を提供します。
In HMIPv6, a mobile node can use its RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a potential 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のでは、モバイルノードはホームアドレスオプションを使用せずに、送信元アドレスとして、その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. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile host moves to a new MAP), 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 [1], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.
RCoAのこの用法は、モバイルIPv6のコスト（すなわち、何のバインディングやホームアドレスオプションは、インターネット経由で送信されていない）を持っているが、それでもモバイルノードにローカルモビリティ管理を提供しません。 RCoAをそのような使用は、（新しいMAPへときにモバイルホストが移動する、すなわち、通信が切断された）グローバルモビリティを提供していないが、いくつかのアプリケーション（例えば、ウェブブラウジング）のために有用であろう。アプリケーションによって使用される送信元アドレスとしてのRCoAの有効性は、MAPドメインのサイズおよび移動ノードの速度に依存するであろう。コレスポンデントノードにBU処理のためのサポートは、[1]に義務付けられていないので、さらに、この機構は、コレスポンデントノードへのバスを送信せずに経路最適化を得る方法を提供することができます。
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 corresponding nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, the location tracking of a mobile node by its corresponding nodes or its home agent is difficult because they only know its RCoA and not its LCoA.
HMIPv6のでは、モバイルノードは、それが送信するパケットの送信元フィールドに、そのRCoAをを使用して、その対応するノードとそのホームエージェントからそののLCoAを隠し。彼らは唯一ののLCoAがそのRCoAを知っているとしないため、結果として、対応するノードまたはホームエージェントによってモバイル・ノードの位置を追跡することは困難です。
This section describes how a mobile node obtains the MAP address and subnet prefix, and how ARs in a domain discover MAPs. Two different methods for MAP discovery are defined below.
このセクションでは、モバイルノードがMAPアドレスとサブネットプレフィックスを取得する方法について説明し、どのようにドメイン内のARはMAPのを発見します。 MAP発見のための二つの異なる方法を以下のように定義されています。
Dynamic MAP Discovery is based on propagating the MAP option in Router Advertisements from the MAP to the mobile node through certain (configured) router interfaces within the routers in an operator's network. This requires manual configuration of the MAP and also that the routers receiving the MAP option allow them to propagate the option on certain interfaces. To ensure a secure communication between routers, router advertisements that are sent between routers for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH, ESP, or SEND). In the case where this authentication is not possible (e.g., third party routers exist between the MAP and ARs), a network operator may prefer to manually configure all the ARs to send the MAP option, as described in this document.
動的MAP探索は、オペレータのネットワーク内のルータ内の特定（構成）ルータインターフェイスを介してモバイルノードにMAPからルータ広告内のMAPオプションを伝播に基づいています。これは、MAPの手動設定を必要とし、また、MAPオプションを受信したルータは、それらが特定のインターフェイス上のオプションを伝播することを可能にすること。ルータ間の安全な通信を確保するために、動的MAP探索のためにルータ間で送信されるルータ広告（例えば、ESP、AH使用して、またはSEND）認証されるべきです。この認証ができない場合には（例えば、サードパーティのルータがMAPとのARの間に存在する）、ネットワークオペレータは、手動で、この文書に記載されているように、MAPオプションを送信するすべてのARを構成することを好むことができます。
Manual configuration of the MAP option information in ARs and other MAPs in the same domain is the default mechanism. It should also be possible to configure ARs and MAPs to enable dynamic mechanisms for MAP Discovery.
同じドメイン内のARや他のマップでMAPオプション情報の手動設定はデフォルトのメカニズムです。また、MAP発見のための動的なメカニズムを有効にするのARとマップを設定することが可能です。
The process of MAP discovery can be performed in different ways. Router advertisements are used for Dynamic MAP Discovery by introducing a new option. The access router is required to send the MAP option in its router advertisements. This option includes the distance vector from the mobile node (which may not imply the real distance in terms of the number of hops), the preference for this particular MAP, the MAP's global IP address and subnet prefix
MAP発見のプロセスは、様々な方法で行うことができます。ルーター通知には、新しいオプションを導入することにより、ダイナミックMAP発見のために使用されています。アクセスルータは、そのルータ広告でMAPオプションを送信するために必要とされます。このオプションは、（ホップ数の観点から実際の距離を意味するものでなくてもよい）モバイルノードからの距離ベクトルは、この特定のMAP、MAPのグローバルIPアドレスとサブネット・プレフィックスのプリファレンスを含みます
The ARs within a MAP domain may be configured dynamically with the information related to the MAP options. ARs may obtain this information by listening for RAs with MAP options. Each MAP in the network needs to be configured with a default preference, the right interfaces to send this option on, and the IP address to be sent. The initial value of the "Distance" field MAY be set to a default value of 1 and MUST NOT be set to zero. Routers in the MAP domain should be configured to re-send the MAP option on certain interfaces.
MAPドメイン内のARは、MAPオプションに関連する情報を動的に構成することができます。 ARはMAPのオプションでのRAのために聞くことによって、この情報を得ることができます。ネットワーク内の各MAPには、このオプションを送信するには、デフォルトの優先順位を設定する権利のインターフェースを必要とし、IPアドレスが送信されます。 「距離」フィールドの初期値は、1のデフォルト値に設定することができ、ゼロに設定してはいけません。 MAPドメイン内のルータは、特定のインターフェイス上のMAPオプションを再送信するように構成されるべきです。
Upon reception of a router advertisement with the MAP option, the receiving router MUST copy the option and re-send it after incrementing the Distance field by one. If the receiving router was also a MAP, it MUST send its own option, together with the received option, in the same advertisement. If a router receives more than one MAP option for the same MAP (i.e., the same IP address in the MAP option), from two different interfaces, it MUST choose the option with the smallest distance field.
MAPオプション付きのルータ広告を受信すると、受信ルータは、オプションをコピーしなければなりませんし、1で距離フィールドをインクリメントした後、それを再送信します。受信ルータはまた、MAPだった場合、それは同じ広告では、一緒に受け取ったオプションを使用して、独自のオプションを送らなければなりません。ルータは、2つの異なるインターフェースから、同じMAP（MAPオプションで、すなわち、同一のIPアドレス）に複数のMAPオプションを受信した場合、それは、最小距離フィールドでオプションを選択しなければなりません。
In this manner, information about one or more MAPs can be dynamically passed to a mobile node. Furthermore, by performing the discovery phase in this way, different MAP nodes are able to change their preferences dynamically based on the local policies, node overload or other load-sharing protocols being used.
このように、一つまたは複数のマップに関する情報が動的モバイルノードに渡すことができます。また、このようにして発見フェーズを実行することによって、異なるMAPノードはローカルポリシー、ノードの過負荷または使用されている他の負荷分散プロトコルに基づいて動的に設定を変更することができます。
A MAP will be configured to send its option or relay MAP options belonging to other MAPs onto certain interfaces. The choice of interfaces is done by the network administrator (i.e., manual configuration) and depends on the network topology. A default preference value of 10 may be assigned to each MAP. It should be noted that a MAP can change its preference value at any time due to various reasons (e.g., node overload or load sharing). A preference value of zero means the MAP SHOULD NOT be chosen by new mobile nodes. This value could be reached in cases of node overload or partial node failures.
MAPは、特定のインターフェイスに他のマップに属するそのオプションまたは中継MAPオプションを送信するように構成されます。インターフェースの選択は、ネットワーク管理者（即ち、手動設定）することによって行われ、ネットワークトポロジに依存しています。 10のデフォルトの優先値は、各MAPに割り当てることができます。 MAPは、種々の理由（例えば、ノードの過負荷または負荷分散）にいつでもその嗜好値を変更することができることに留意すべきです。ゼロの優先値は、MAPは、新しいモバイルノードによって選択されるべきではないことを意味します。この値は、ノードの過負荷または部分的なノード障害の場合に到達することができます。
The MAP option is propagated towards ARs in its domain. Each router along the path to an AR will increment the Distance field by one. If a router that is also a MAP receives advertisements from other MAPs, it MUST add its own MAP option and propagate both options to the next router or to the AR (if it has direct connectivity with the AR).
MAPオプションは、そのドメインのARに向けて伝播されます。 ARへのパスに沿った各ルータは1で距離フィールドをインクリメントします。また、MAPであるルータが他のMAPからの広告を受信した場合（それはARと直接接続していれば）、それは自身のMAPオプションを追加し、次のルータやARに両方のオプションを伝播する必要があります。
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.
HMIPv6の認識モバイルノードはルータ広告を受信すると、MAPオプションを検索する必要があります。 1つまたは複数のオプションが異なるMAPのIPアドレスのために見つけることができます。
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.
モバイルノードは、最も高い優先値を有するMAPで登録する必要があります。ゼロの優先値を有するMAP（すなわち、モバイルノードは、既存のバインディングをリフレッシュすることができるが、新しいものを作成することができない）新しいローカルバスには使用しないでください。しかしながら、モバイルノードが他の上に1つのMAPに登録することを選ぶかもしれ、距離フィールドに受信した値に応じて、嗜好値がゼロ以上であることを条件とします。
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 revert to using the Mobile IPv6 protocol, as specified in [1].
ゼロの有効期間値を含むMAPオプションは、このMAPは、MNによって選択されてはならないことを意味します。ゼロの有効期間は、MAPの障害を示しています。このオプションが受信されると、移動ノードは、他のMAPを選択して、新しいバインディングを作成する必要があります。このMAPを持つ既存のバインディングが失われると仮定することができます。他のMAPが利用できない場合、モバイルノード[1]で指定されるように、モバイルIPv6プロトコルを使用して元に戻す必要があります。
If a multihomed 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へのアクセスを有する場合、それは、現在のMAPをアドバタイズ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つのMAPを選択するために、受信されたオプション（複数可）を格納しなければなりません。彼らは動き検出アルゴリズムの目的のために、後に受信した他のオプションと比較されるようにオプションを保存することは、必要不可欠です。
If no MAP options are found in the router advertisement, the mobile node MUST use the Mobile IPv6 protocol, as specified in [1].
何MAPオプションがルータ広告で発見されていない場合、[1]で指定されるように、モバイルノードは、モバイルIPv6プロトコルを使用しなければなりません。
If the R flag is set, the mobile node MUST use its RCoA as the Home Address when performing the MAP registration. RCoA is then bound to the LCoA in the MAP's Binding Cache.
Rフラグが設定されている場合、MAP登録を行う場合、移動ノードは、ホーム・アドレスとしてそのRCoAをを使用しなければなりません。 RCoAをその後、MAPのバインディングキャッシュにの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.
モバイルノードは、新しいMAPドメインに移動すると、移動ノードは、パケットを転送することを要求する前のMAPにBUを送信することができ、移動ノードの新たなCoA宛。管理者は、MAPのドメイン外のLCoAにパケットを転送するからMAPを制限することができます。しかし、MAPは、隣接するMAPドメイン内のARの一部に関連付けられているのLCoAにパケットを転送することができ、それらは同一の管理ドメイン内に位置することが提供されることが推奨されます。
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.
例えば、MAPは、そのドメインの境界上のARに地理的に隣接したアクセスルータに関連付けられているのLCoAへパケットを転送するように構成することができます。それはモバイルノードが新しいMAP、そのHAと、潜在的に、コレスポンデント・ノードの更新中にパケットを受信し続けることができ、これは平滑間MAPハンドオーバを可能にします。
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のは、訪問先ネットワーク内のローカルモビリティ管理のための柔軟なメカニズムを提供します。先に説明したように、MAPは、（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:
モバイルノードがMAPオプションを含むルータ広告を受信すると、次の動き検出メカニズムに応じたアクションを実行する必要があります。例えば、この文書に記載されたものと階層化モバイルIPネットワークでは、モバイルノードがなければなりません。
- "Eager" to perform new bindings - "Lazy" in releasing existing bindings
既存のバインディングを解放するには、「レイジー」 - - 新しいバインディングを実行するために「イーガー」
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によって通知任意の「新しい」MAP（イーガー）に登録しなければならないことを意味します。移動ノードがMAPを「新しい」MAPであるか否かを判断する方法は、セクション9.1に記載されています。それはもはやMAPオプションを受信しない（またはゼロの生涯とそれを受けた）またはその既存のバインディングの寿命は（レイジー）が満了するまで、モバイルノードは、既存のバインディングを解放してはいけません。それは、その新しいについてその対応ノードとHAに通知するために、モバイルノードにかかる時間を削減するように、上述の本イーガー・レイジーアプローチは、MAPルータの1つが故障した場合に、フォールバック機構を提供するのに役立ちます気付アドレス。
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).
複数のMAPを選択するとマップの階層を下り高いMAPから送信されるパケットを強制的に予見されるメリットがありません。このアプローチは、転送遅延を追加し、最高MAPと移動ノード間のIPルーティングのロバスト性を排除することができます。そのため、それがこの仕様で禁止されています。ネットワーク内の複数のマップ（「上方」AR）を可能にするモバイルノード力パケットはMAPの階層を下にルーティングすることを意味してはなりません。しかし、置く複数のMAP「上」ARは、冗長性を確保するために、モバイルノードが経験したさまざまなモビリティのシナリオのための最適化として使用することができます。 MAPは、（例えば、各MAPがCNSの特定のセットへの通信のために使用される）MNによって互いに独立して使用されます。
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. This specification does not provide an algorithm for the distance-based MAP selection. However, such an algorithm may be introduced in future extensions utilising information about the speed of mobility from lower layers.
複数のマップで、ネットワーク内の距離ベースの選択に関しては、移動ノードは、頻繁な再登録を避けるために遠いMAPに登録することもできます。これは、頻繁にハンドオフを実行します、高速モバイルノードのために特に重要です。このシナリオでは、より遠くのMAPの選択は、MAPを変更することや、すべての通信員ノードとHAを通知する確率を低減するであろう。この仕様は、距離ベースのMAPの選択のためのアルゴリズムを提供していません。しかしながら、このようなアルゴリズムは、下位層から移動度の速度についての情報を利用して将来の拡張で導入することができます。
In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need some 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 uses 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を選択できるようにするには、いくつかの高度なアルゴリズムを必要とするかもしれません。これらのアルゴリズムは、MAPオプションで優先フィールドと組み合わせる（距離ベースの選択のための）入力としてモバイルノードの速度を有するであろう。しかしながら、この仕様は、モバイルノードが他の最適化アルゴリズムが利用できないデフォルトとして以下のアルゴリズムを使用することを提案しています。次のアルゴリズムは、単に最も遠いMAPを選択するに基づいており、その優先値がゼロの値に到達しなかったことを条件とします。移動ノードの動作を以下に示します。
1. Receive and parse all MAP options 2. Arrange MAPs in a descending order, starting with the furthest away MAP (i.e., MAP option having largest Dist field) 3. Select first MAP in list 4. If either the preference value or the valid lifetime fields are set to zero, select the following MAP in the list. 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.
1.すべてのMAPオプション2.優先値または有効のいずれか場合は、リスト4の最初のMAPを選択します遠いMAP（最大Distのフィールドを持つ、すなわち、MAPオプション）で始まる、降順でのMAPを配置受信して解析します寿命フィールドがゼロに設定されている、リスト内の次のMAPを選択します。前記繰り返しステップ（4）新しいMAPオプションが依然として存在している間、MAPは、非ゼロの優先値と非ゼロの有効寿命を発見するまで。
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.
上記の手順を実装することは、デフォルトでは、モバイルノードの選択で最も遠いか遠い可能なMAPをもたらすであろう。優先度の値がゼロに減少するまでこれが継続されます。これに続いて、モバイルノードが別の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 u0movement is not frequent.
ネットワークオペレータは、モバイルIPv6ハンドオーバが稀な事象と考えることができるいくつかのケースではフラットなアーキテクチャを選択することができます。これらのシナリオでは、事業者は、唯一のARにMAP機能を含めるように選択することができます。アクセスルータでMAP機能を含めることは、依然としてすべてのコレスポンデントノードとHAを更新するのに必要な時間を減少させるのに有用であり得ます。ハンドオフを実行するときこのシナリオでは、モバイルノードは、アンカーポイントとして（ARで）MAPを選択することができます。動的階層（またはアンカー）のこの種のみインターARのu0movementが頻繁でない場合に推奨されます。
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 some form of context transfer protocol between them. Alternatively, future versions of the Virtual Router Redundancy Protocol [4] or HA redundancy protocols may allow networks to recover from MAP failures.
この仕様は、訪問先ネットワーク内のローカルホームエージェントとして見ることができるMAPを紹介します。 MAPは、ホームエージェントのように、単一障害点です。 MAPが失敗した場合、その結合キャッシュの内容は、モバイルと通信員ノード間の通信が失われ、失われます。この状況は、同じリンク上に複数のMAPを使用することによって、それらの間のコンテキスト転送プロトコルのいくつかのフォームを利用することによって回避することができます。あるいは、仮想ルータ冗長プロトコルの将来のバージョンは、[4]またはHA冗長プロトコルは、ネットワークが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 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.
そのようなプロトコルがサポートされていない場合には、移動ノードがMAP障害を検出する必要があります。それがゼロの生涯とMAPオプションを含むルータ広告を受信したときに、移動ノードは、この状況を検出することができます。モバイルノードは、MAP検出プロセスを開始し、別のMAPに登録することを試みる必要があります。それが選択され、別のMAPに登録した後は、それはまた、そのRCoAをが変更された場合通信員ノードとホームエージェントに通知する必要があります。冗長性のためにマップ間のキャッシュエントリを結合する転送プロトコルの存在下でなお、新たなMAPは、移動ノードに同一のRCoAを提供することができる（例えば、両方ともMAPはMAPオプションに同じプレフィックスを広告する場合）。これは、更新通信員ノードとホームエージェントからモバイルノードを保存します。
Access routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:
アクセスルータは、様々な方法で（MAP失敗を示す）ゼロの寿命のMAPオプションを通知するトリガすることができます。
- By manual intervention. - In a dynamic manner.
- 手動の介入によって。 - 動的な方法で。
ARs can perform Dynamic detection of MAP failure by sending ICMP Echo request messages to the MAP regularly (e.g., every ten seconds). If no response is received, an AR may try to aggressively send echo requests to 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.
ARSが定期的にMAP（例えば、10秒ごと）にICMPエコー要求メッセージを送信することにより、MAPの障害の動的検出を行うことができます。応答がない場合は、ARは、積極的に（例えば、一回15秒ごとに5秒）短時間のMAPにエコー要求を送信しようとするかもしれません。返事が受信されない場合は、MAPオプションがゼロの有効な寿命値を用いて送信することができます。
This specification does not mandate a particular recovery mechanism. However, any similar mechanism between the MAP and an AR SHOULD be secure to allow for message authentication, integrity protection, and protection against replay attacks.
この仕様は、特定の回復メカニズムを強制しません。しかし、MAPとAR間の任意の同様のメカニズムは、メッセージ認証、完全性保護、およびリプレイ攻撃に対する保護を可能にするために安全であるべきです。
Section 4 introduces a new flag (M) to the Binding Update specified in RFC 3775.
セクション4は、RFC 3775で指定されたバインディング更新に新しいフラグ（M）を導入します。
Section 5 introduces a new IPv6 Neighbour Discovery Option called the MAP Option. IANA has assigned the Option Type value 23 for the MAP Option within the option numbering space for IPv6 Neighbour Discovery messages.
第5節では、MAPオプションと呼ばれる新しいIPv6近隣探索オプションを紹介します。 IANAは、IPv6近隣探索メッセージのオプション番号スペース内のMAPオプションのためのオプションタイプ値23を割り当てています。
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, but 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、つまり、モビリティアンカーポイントに新しい概念を導入しています。モバイルノードとMAP間のセキュリティ関係が強いことが重要です。それは、相互認証、完全性保護、およびリプレイ攻撃に対する保護を必要とする必要があります。機密性は、ペイロードトラフィックのために必要とされるが、MAPへの更新を結合するために必要とされていません。これらの保護のいずれかの不在は、他の合法的なものになりすますか、MAPになりすます悪質なモバイルノードにつながる可能性があります。これらの攻撃はどれも間違いなくモバイルノードのRCoAをの知識を持つすべての通信員ノードとモバイルノードの通信への望ましくない影響が発生します。
Three different relationships (related to securing binding updates) need to be considered:
（バインディングアップデートの確保に関連した）三つの異なる関係を考慮する必要があります。
1) The mobile node - MAP 2) The mobile node - Home Agent 3) The mobile node - correspondent node
1）モバイルノード - MAP 2）モバイルノード - ホームエージェント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 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 would trust 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).
MAPの転送サービスを利用するには、モバイルノードを可能にするためには、（特にサービスのための、ないのRCoAのための）最初の承認が必要になることがあります。 MAPサービスを使用するために、モバイルノードを許可することはSAネゴシエーションプロセス中に交換、移動ノードの識別情報に基づいて行うことができます。承認は、モバイルノードのアイデンティティに基づいて付与された、またはMAPが信頼する認証局（CA）のアイデンティティに基づくことができます。モバイルノードは、信頼できるエンティティによって署名された証明書を提示した場合、MAPはそのサービスの利用を許可するために例えば、（例えば、同じ管理ドメイン、または別の信頼できるローミングパートナーに属しCA）は、それが十分であろう。承認のこのレベルは、特定のRCoAの使用を許可する独立していることに注意してください。それはモバイルノードが（例えば、ローミングパートナー）を信頼するように構成されているのと同じCAまたは別のCAによって署名された証明書を提示する場合も同様に、移動ノードがMAPを信頼することになります。
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, an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies whether the RCoA has not been registered yet and, if so, it 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 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. However, because the RCoA is temporary and is not bound to a particular node, a mobile node does not have to initially (before the first binding update) prove that it owns its RCoA (unlike the requirement on home addresses in Mobile IPv6) when it establishes a Security Association with its MAP. A MAP only needs to ensure that a BU for a particular RCoA was issued by the same mobile node that established the Security Association for that RCoA.
HMIPv6のは、モバイルノードとその現在のMAP間の追加登録を使用します。本書で説明したように、モバイルノードは、新しいドメインに移動したとき、（すなわち、新たなMAPによってサービス）は、RCoAを、のLCoAを取得し、新たなMAPと、これら二つのアドレス間のバインディング登録します。 MAPは、RCoAをまだ登録されていないと、もしそうなら、それはのRCoAとLCoAのとバインディングキャッシュエントリを作成するかどうかを検証します。モバイルノードが新しいのLCoAを取得するたびに、それはのRCoAとその新しいのLCoAとの間の結合を指定する新しいBUを送信する必要があります。このBUは、そうでない場合は、任意のホストは、モバイルノードのRCoAをのためのBUを送信して、モバイルノードのパケットを乗っ取ることができ、認証される必要があります。しかし、RCoAを、一時的であるため、特定のノードにバインドされていない、モバイルノードは、ときに最初に（最初のバインディング更新前）（モバイルIPv6におけるホームアドレスの要件とは違って）それはそのRCoAをを所有していることを証明する必要はありません。そのMAPとのセキュリティアソシエーションが確立されます。 MAPは、特定のRCoAのためのBUは、そのRCoAをのためのセキュリティアソシエーションを確立し、同じモバイルノードによって発行されたことを確認する必要があります。
The MAP does not need to have prior knowledge of the identity of the mobile node nor 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 IKE. A return routability test is not necessary.
MAPは、移動ノードもそのホームアドレスのアイデンティティの予備知識を持っている必要はありません。その結果、モバイルノードとMAP間のSAは、IKEなどの任意の鍵確立プロトコルを用いて確立することができます。リターン・ルータビリティ・テストは必要ありません。
The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKE [2]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA. This is achieved by using the RCoA as the identity in IKE Phase 2 negotiation. This step is identical to the use of the home address in IKE phase 2.
MAPは、RCoAを（ないのLCoA）のためにSAを設定する必要があります。これは、IKE [2]を用いて行うことができます。モバイルノードは、送信元アドレスとしてそののLCoAを使用して、しかしのRCoAがSAで使用されるべきであることを指定します。これは、IKEフェーズ2のネゴシエーションにおけるアイデンティティとしてのRCoAを使用することによって達成されます。このステップでは、IKEフェーズ2でのホームアドレスを使用することと同じです。
If a binding cache entry exists for a given RCoA, the MAP's IKE policy check MUST point to the SA used to install the entry. If the mobile node's credentials stored in the existing SA do not match the ones provided in the current negotiation, the MAP MUST reject the new
バインディングキャッシュエントリが与えられたRCoAのために存在する場合は、MAPのIKEポリシーのチェックはSAエントリをインストールするために使用を指している必要があります。既存のSAに保存されているモバイルノードの資格情報が現在の交渉で提供するものと一致しない場合は、MAPは、新しいを拒絶しなければなりません
SA establishment request for such RCoA with an INVALID-ID-INFORMATION notification [2]. This is to prevent two different mobile nodes from registering (intentionally or not) the same RCoA. Upon receiving this notification, the mobile node SHOULD generate a new RCoA and restart the IKE negotiation. Alternatively, a MAP may decide that, if a binding cache entry already exists for a particular RCoA, no new security association should be established for such RCoA; this is independent of the mobile node credentials. This prevents the mobile node from being able to re-establish a security association for the same RCoA (i.e., to change session keys). However, this is not a major problem because the SA will typically only be used to protect signalling traffic when a MN moves, and not for the actual data traffic sent to arbitrary nodes.
INVALID-ID情報の通知にかかるのRCoA用SA確立要求[2]。これは、（意図的かどうか）が同じのRCoAを登録するから、二つの異なるモバイルノードを防止することです。この通知を受信すると、移動ノードは、新しいのRCoAを生成し、IKEネゴシエーションを再起動する必要があります。また、MAPは、バインディングキャッシュエントリがすでに特定のRCoAのために存在している場合、新しいセキュリティアソシエーションは、このようなRCoAをするために確立すべきではない、と判断するかもしれ。これは、移動ノードの資格情報とは無関係です。これは、同一のRCoAのセキュリティアソシエーションを再確立することができることから、移動ノードを防止する（すなわち、セッションキーを変更します）。 SAは、一般的にだけではなく、実際のデータトラフィックのためのMNが移動し、任意のノードに送信されたときにシグナリングトラフィックを保護するために使用されますので、しかし、これは大きな問題ではありません。
Binding updates between the MAP and the mobile node MUST be protected with either AH or ESP in transport mode. When ESP is used, a non-null authentication algorithm MUST be used.
MAPと移動ノードとの間のバインディングアップデートは、トランスポートモードAHまたはESPのいずれかで保護されなければなりません。 ESPを使用する場合は、null以外の認証アルゴリズムを使用しなければなりません。
Mobile IPv6 [1] 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 [1]. 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 [1]. The source address used in HOTI messages MUST be the mobile node's home address. 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 [1]モバイルと対応ノードがバインディング更新及び確認を認証することを可能にするリターン・ルータビリティ手順を定義します。この仕様は、[1]で定義されたリターン・ルータビリティ・テストに影響を与えません。しかし、モバイルノードの実装は、[1]で定義されたHoTIおよびCOTIメッセージの送信元アドレスを選択する際に注意する必要があることに注意することが重要です。 HoTIメッセージで使用されるソースアドレスは、モバイルノードのホームアドレスであるに違いありません。 HoTiメッセージを含むパケットが二度カプセル化されています。内側のカプセル化ヘッダは、送信元アドレスフィールドと宛先アドレスフィールドにホームエージェントのアドレスでのRCoAが含まれています。外側のカプセル化ヘッダは、ソースアドレスフィールド内のモバイルノードののLCoA及び宛先フィールドのMAPのアドレスを含んでいます。
The security relationship between the mobile node and its Home Agent, as discussed in [1], is not impacted by this specification.
で説明したように、モバイルノードとホームエージェントの間のセキュリティ関係、[1]、本明細書によって影響されません。
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.
作者はこのドキュメントへの彼らの貴重な入力のためにコニーラーション（エリクソン）とマティアス・ペターソン（エリクソン）を感謝したいと思います。著者らはまた、最初の実装をテストするため、その貴重なフィードバックのためにフランスのRNRT MobiSecV6プロジェクト（BULL、フランステレコムと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 (Monash University), Francis Dupont (GET/Enst Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash University), and Alper Yegin (Samsung) for their comments on the document.
また、著者は、アルファベット順にワーキンググループのメンバーは以下のとおりに感謝したいと思います：Samita Chakrabarti（日）、グレゴリー・デイリー（モナシュ大学）、フランシス・デュポン（/ EnstブルターニュをGET）、GopalのDommety（シスコ）、エヴァGustaffson （エリクソン）、デイヴ・ジョンソン（ライス大学）、アニカ・ヨンソン（エリクソン）、ジェームズ・ケンプ（ドコモラボ）、マルッティKuparinenが（エリクソン）Fergal Ladley、ガブリエル・モンテネグロ（日）、ニック "シャーキー" ムーア（モナッシュ大学）エリックNordmarkと（日）、Basavarajパティル（ノキア）、ブレット・ペントランド（モナシュ大学）、およびドキュメントの彼らのコメントのためのアルパースYegin（サムスン）。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[2]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[4] Koodli、R.、 "モバイルIPv6の高速ハンドオーバ"、RFC 4068、2005年7月。
[5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[5]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikanderを、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6
付録A：高速モバイルIPv6ハンドオーバとのHMIPv6
Fast Handovers are required to ensure that the layer 3 (Mobile IP) handover delay is minimised, thus also minimising, and possibly eliminating, the period of service disruption which normally occurs when a mobile node moves between two ARs. This period of service disruption usually occurs due to the time required by the mobile node to update its HA using Binding Updates after it moves between ARs. During this time period the mobile node cannot resume or continue communications. The mechanism to achieve Fast Handovers with Mobile IPv6 is described in [5] and is briefly summarised here. This mechanism allows the anticipation of the layer 3 handover, such that data traffic can be redirected to the mobile node's new location before it moves there.
高速ハンドオーバは、モバイルノードは、2つのAR間を移動するときに通常発生するサービスの中断の期間、ひいては最小化、およびおそらくは排除、レイヤ3（モバイルIP）ハンドオーバ遅延が最小化されることを確実にするために必要とされます。サービス中断のこの期間は通常起因それのAR間を移動した後、結合更新を使用して、そのHAを更新するためにモバイルノードによって必要とされる時間に発生します。この期間中、モバイルノードが通信を再開するか、続行することはできません。モバイルIPv6での高速ハンドオーバを実現するためのメカニズムは、[5]に記載されており、ここでは簡単に要約されています。このメカニズムは、それが移動する前に、データトラフィックがモバイルノードの新しい場所にリダイレクトすることができるように、レイヤ3ハンドオーバの予想を可能にします。
While the mobile node is connected to its previous Access Router (PAR) and is about to move to a new Access Router (NAR), the Fast Handovers in Mobile IPv6 requires in sequence:
モバイルノードは、その前のアクセスルータ（PAR）に接続されており、新たなアクセスルータ（NAR）に移動しようとしている間に、モバイルIPv6における高速ハンドオーバは配列に必要です。
1) The mobile node to obtain a new care-of address at the NAR while connected to the PAR.
PARに接続しながら、1）モバイルノードがNARに新たな気付アドレスを取得します。
2) New CoA to be used at NAR case: the mobile node to send a F-BU (Fast BU) to its previous anchor point (i.e., PAR) to update its binding cache with the mobile node's new CoA while still attached to PAR.
まだPARに接続しながら、モバイルノードの新たなCoAとその結合キャッシュを更新する（すなわち、PAR）その前のアンカーポイントにF-BU（高速BU）を送信するために、モバイルノード：2）新CoAがNARのケースで使用されます。
3) The previous anchor point (i.e., PAR) to start forwarding packets destined for the mobile node to the mobile node's new CoA at NAR (or old CoA tunnelled to NAR, if new CoA is not applicable).
3）前のアンカーポイント（すなわち、PAR）を移動ノードのNARに新たなCoA（または古いCoAのためにモバイルノード宛てのパケット転送を開始するために）新たなCoAが適用されない場合、NARにトンネリング。
4) Old CoA to be used at NAR case: the mobile node to send a F-BU (Fast BU) to its previous anchor point (i.e., PAR), after it has moved and attached to NAR, in order to update its binding cache with the mobile node's new CoA.
それはその結合を更新するために、NARに移動して付着した後に、その前のアンカーポイント（すなわち、PAR）にF-BU（高速BU）を送信するモバイルノード：NARの場合に使用される4）古いCoAをモバイルノードの新しいCoAを持つキャッシュ。
The mobile node or PAR may initiate the Fast Handover procedure by using wireless link-layer information or link-layer triggers that inform that the mobile node will soon be handed off between two wireless access points respectively attached to PAR and NAR. If the "trigger" is received at the mobile node, the mobile node will initiate the layer-3 handover process by sending a Proxy Router Solicitation message to PAR. Instead, if the "trigger" is received at PAR, then it will transmit a Proxy Router Advertisement to the appropriate mobile node, without the need for solicitations. The basic Fast Handover message exchanges are illustrated in Figure A.1.
モバイルノードまたはPARは、無線リンク層情報または移動ノードがすぐそれぞれPARとNARに取り付けられた2つの無線アクセスポイント間でハンドオフされることを通知するリンク層トリガを使用することによって、高速ハンドオーバ手順を開始することができます。 「トリガー」は、移動ノードで受信される場合、モバイルノードは、PARにプロキシルータ要請メッセージを送信することにより、レイヤ3ハンドオーバ処理を開始します。 「トリガが」PARで受信された場合に代わりに、それは勧誘を必要とせずに、適切なモバイルノードにプロキシルータ通知を送信します。基本的な高速ハンドオーバメッセージの交換は、図A.1に示されています。
+-----------+ 1a. HI +-----+
| | ---------------->| NAR |
| PAR | 1b. HAck | |
+-----------+ <--------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
Figure A.1: Fast Mobile IPv6 Handover Protocol
図A.1：高速モバイルIPv6ハンドオーバープロトコル
The mobile node obtains a new care-of address while connected to PAR by means of router advertisements containing information from the NAR (Proxy Router Advertisement, which may be sent due to a Proxy Router Solicitation). The PAR will validate the mobile node's new CoA by sending a Handover Initiate (HI) message to the NAR. The new CoA sent in the HI message is formed by appending the mobile node's current interface identifier to the NAR's prefix. Based on the response generated in the Handover Acknowledge (HAck) message, the PAR will either generate a tunnel to the mobile node's new CoA (if the address was valid) or generate a tunnel to the NAR's address (if the address was already in use on the new subnet). If the address was already in use on the new subnet, it is assumed that there will be no time to perform another attempt to configure the mobile node with a CoA on the new link. Therefore, the NAR will generate a host route for the mobile node using its old CoA. Note that message 1a may precede message 2b or occur at the same time.
（これはプロキシルータ要請を送信することができるプロキシルータ広告）NARからの情報を含むルータ広告によりPARに接続している間、移動ノードは新しい気付アドレスを取得します。 PARはNARに開始（HI）メッセージハンドオーバを送信することにより、モバイルノードの新しいCoAを検証します。 HIメッセージで送信される新たなCoAがNARのプレフィックスに移動ノードの現在のインターフェース識別子を付加することにより形成されています。ハンドオーバ肯定応答（上記ハンドオフ）メッセージで生成された応答に基づいて、PARは、モバイルノードの新たなCoAにトンネルを生成するか（アドレスが有効であった場合）、またはアドレスが既に使用中であった場合（NARのアドレスにトンネルを生成します新しいサブネット上）。アドレスが新しいサブネット上ですでに使用されていた場合は、新しいリンク上のCoAとモバイルノードを構成するための別の試みを実行する時間がないことを想定しています。したがって、NARは古いCoAを使用して、モバイルノードのホストルートを生成します。そのメッセージ1aが同時にメッセージ2Bを前または発生する可能性があります。
In [5], the ARs act as local Home Agents, which hold binding caches for the mobile nodes and receive Binding Updates. This makes these ARs function like the MAP specified in this document. Also, it is quite possible that the ARs are not directly connected, but communicate through an aggregation router. Therefore, such an aggregation router is also an ideal position for the MAP functionality. These are two ways of integrating the HMIPv6 and Fast Handover mechanisms. The first involves placing MAPs in place of the ARs, which is a natural step. The second scenario involves placing the MAP in an aggregation router "above" the ARs. In this case, [5] specifies forwarding of packets between PAR and NAR. This could be inefficient in terms of delay and bandwidth efficiency because packets will traverse the MAP-PAR link twice and packets will arrive out of order at the mobile node. Using the MAP in the aggregation router would improve the efficiency of Fast Handovers, which could make use of the MAP to redirect traffic, thus saving delay and bandwidth between the aggregation router and the PAR.
[5]、アクセスルータは、モバイルノードのためのバインディングキャッシュを保持し、バインディング更新を受信し、ローカルホームエージェントとして働きます。これは、これらのARは、この文書で指定されたMAPのように機能します。また、アクセスルータに直接接続されていないが、集約ルータを介して通信することはかなり可能です。したがって、そのような集約ルータはまた、MAP機能のための理想的な位置です。これらは、HMIPv6のと高速ハンドオーバメカニズムを統合する2つの方法があります。最初は自然なステップであるのARの代わりにのMAPを配置することを含みます。第2のシナリオは、のAR「とは、上記」集約ルータでMAPを配置することを含みます。この場合、[5] PARとNARとの間のパケットの転送を指定します。パケットが二回MAP-PARのリンクを横断し、パケットがモバイルノードに順不同で到着するので、これは、遅延と帯域幅効率の点で非効率的であり得ます。集約ルータでのMAPを使用すると、このように集約ルータとPARの間の遅延と帯域幅を節約し、トラフィックをリダイレクトするようにMAPを利用することができ、高速ハンドオーバ、の効率を改善します。
+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | NAR |
| PAR | | | |
+---------+ | +---------+
^ | |
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->
Figure A.2: Fast Mobile IPv6 Handover Protocol using HMIPv6
図A.2：高速モバイルIPv6ハンドオーバープロトコルのHMIPv6を使用して
In Figure A.2, the HI/HAck messages now occur between the MAP and NAR in order to check the validity of the newly requested care-of address and to establish a temporary tunnel should the new care-of address not be valid. Therefore, the same functionality of the Fast Handover procedure is kept, but the anchor point is moved from the PAR to the MAP.
図A.2では、HI /ハックメッセージは今、新たに気付アドレスを要求の有効性を確認するために、MAPとNARとの間で発生し、新しい気付アドレスが有効ではありません一時的なトンネルを確立します。そのため、高速ハンドオーバ手順の同じ機能が保たれているが、アンカーポイントがMAPにPARから移動されます。
As in the previous Fast Handover procedure, in the network-determined case the layer-2 "triggers" at the PAR will cause the PAR to send a Proxy Router Advertisement to the mobile node with the MAP option. In the mobile-determined case, this is preceded by a Proxy Router Solicitation from the mobile node. The same layer-2 trigger at PAR in the network-determined case could be used to independently initiate Context Transfer (e.g., QoS) between PAR and NAR. In the mobile-determined case, the trigger at PAR could be replaced by the reception of a Proxy Router Solicitation or F-BU. Context Transfer is being worked on in the IETF Seamoby WG.
前回の高速ハンドオーバ手順のように、ネットワーク・決定ケース層-2には、PARで「トリガー」MAPオプション付きのモバイルノードにプロキシルータ通知を送信するためにPARが発生します。モバイル決定場合、これは、モバイルノードからプロキシルータ要請によって先行されます。ネットワーク決定場合PARで同じレイヤ2トリガは、独立してコンテキスト転送を開始するために使用することができる（例えば、QoS）のPARとNARとの間。モバイル決定場合、PARでトリガープロキシルータ要請またはF-BUの受信に置き換えることができます。コンテキスト転送は、IETF Seamoby WGで作業中です。
The combination of Fast Handover and HMIPv6 allows the anticipation of the layer 3 handoff, such that data traffic can be efficiently redirected to the mobile node's new location before it moves there. However, it is not easy to determine the correct time to start forwarding traffic from the MAP to the mobile node's new location, which has an impact on how smooth the handoff will be. The same issues arise in [5] with respect to when to start forwarding between PAR and NAR. Packet loss will occur if this is performed too late or too early with respect to the time in which the mobile node detaches from PAR and attaches to NAR. Such packet loss is likely to occur if the MAP updates its binding cache upon receiving the anticipated F-BU, because it is not known exactly when the mobile node will perform or complete the layer-2 handover to NAR, relative to when the mobile node transmits the F-BU. Also, some measure is needed to support the case in which the mobile node's layer-2 handover unexpectedly fails (after Fast Handover has been initiated) or when the mobile node moves quickly back-and-forth between ARs (ping-pong). Simultaneous bindings [6] provide a solution to these issues. In [6], a new Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) message and a new Simultaneous Bindings suboption is defined for the Fast Binding Acknowledgement (F-BAck) message. Using this enhanced mechanism, upon layer-3 handover, traffic for the mobile node will be sent from the MAP to both PAR and NAR for a certain period, thus isolating the mobile node from layer-2 effects such as handover timing, ping-pong, or handover failure and providing the mobile node with uninterrupted layer-3 connectivity.
高速ハンドオーバーとのHMIPv6の組み合わせは、それが移動する前に、データ・トラフィックを効率的にモバイルノードの新しい場所にリダイレクトすることができるように、レイヤ3ハンドオフの予想を可能にします。しかし、ハンドオフがものになるかどうか滑らかに影響を与えているモバイルノードの新しい場所へのMAPからのトラフィックの転送を開始するには、正しい時間を決定することは容易ではありません。同じ問題は、PARとNARとの間の転送を開始する場合に対して[5]に生じます。これはあまりにも早く、モバイルノードはPARから切り離し、NARにアタッチした時間に対して遅すぎる行われたりした場合、パケットロスが発生します。モバイルノードが場合、モバイルノードに対してNARにレイヤ2ハンドオーバーを実行するか、または完了したときに、それが正確に知られていないので、このようなパケット損失は、MAPが予想されるF-BUを受信すると、そのバインディング・キャッシュを更新する場合に発生する可能性がありますF-BUを送信します。また、いくつかの尺度はルータ間の移動ノードのレイヤ2ハンドオーバが予期せず（高速ハンドオーバーが開始された後に）失敗した場合や、移動ノードの移動が素早く前後に（ピンポン）をサポートするために必要です。同時バインディングは、[6]、これらの問題に対する解決策を提供します。 [6]、新しい同時バインディングフラグがファストバインディングアップデート（F-BU）メッセージおよび新たな同時バインディングサブオプションに追加されたファースト結合確認（Fバック）メッセージのために定義されています。この拡張メカニズムを使用して、レイヤ3ハンドオーバ時、移動ノード用のトラフィックは、このように、このようなハンドオーバタイミング、ピンポンのようなレイヤ2の効果からモバイルノードを単離する、一定期間MAPからPARとNARとの両方に送信されます、あるいはハンドオーバ失敗と中断されないレイヤ3接続性を有するモバイルノードを提供します。
Authors' Addresses
著者のアドレス
Hesham Soliman Flarion Technologies
ヒシャムスレイマン・テクノロジーズフライヤー
EMail: h.soliman@flarion.com
メールアドレス：h.soliman@flarion.com
Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
クロード・モンテシノスINRIAローヌ・アルプ655アベニュードゥヨーロッパ38330 Montbonnotサンマルタン
EMail: claude.castelluccia@inria.fr Phone: +33 4 76 61 52 15
電子メール：claude.castelluccia@inria.fr電話：+33 4 76 61 52 15
Karim El Malki Ericsson AB LM Ericssons Vag. 8 126 25 Stockholm Sweden
カリム・エルMalki、エリクソンAB LM Ericssonのパス。 8 126 25ストックホルム、スウェーデン
EMail: karim@elmalki.homeip.net
メールアドレス：karim@elmalki.homeip.net
Ludovic Bellier INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
ルドビクBellier INRIAローヌ・アルプ655アベニュードゥヨーロッパ38330 Montbonnotサンマルタンフランス
EMail: ludovic.bellier@inria.fr
メールアドレス：ludovic.bellier@inria.fr
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。