[要約] RFC 4140は、Hierarchical Mobile IPv6 Mobility Management（HMIPv6）プロトコルに関するものであり、モバイルノードの移動管理を改善することを目的としています。HMIPv6は、モバイルノードの移動におけるハンドオーバーの効率化とネットワークの負荷軽減を実現します。
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)
階層モバイルIPv6モビリティ管理（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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）と呼ばれる新しいノードを使用して、階層モバイル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の外国人エージェントとは異なり、各サブネットにマップは必要ありません。マップは、ローカルドメインの外側のモバイルIPv6信号の量を制限します。マップの導入は、以前に概説した問題の解決策を提供します。
- The mobile node sends Binding Updates to the local MAP rather than the HA (which is typically further away) and CNs
- モバイルノードは、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.
- HAおよびすべてのCNSからのトラフィックが新しい場所に再ルーティングされる前に、MNによって1つのバインディングアップデートメッセージを送信する必要があります。これは、MNが通信しているCNSの数とは無関係です。
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 Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and Home Agents while using Mobile IPv6 route optimisation.
マップは本質的に地元のホームエージェントです。モバイルIPv6に階層モビリティ管理モデルを導入する目的は、モバイルIPv6または他のIPv6プロトコルへの影響を最小限に抑えながら、モバイルIPv6のパフォーマンスを向上させることです。また、モバイルノードがシームレスなモビリティを達成できるように、高速モバイルIPv6ハンドオーバーをサポートしています（付録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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
モビリティアンカーポイントモビリティアンカーポイントは、モバイルノードが訪れるネットワークにあるルーター（MAP）です。マップは、MNによってローカルHAとして使用されます。訪問されたネットワーク内に1つ以上のマップが存在する可能性があります。
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は、マップのサブネット上のアドレスです。マップオプションを受信するときに、モバイルノードによって自動構成されます。
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).
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の間にバインディングを確立するために、ローカルバインディングアップデートをマップに送信します。
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.
この階層的なモバイル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 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.
マップドメインに入るモバイルノードは、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（AR1）からアクセスするため、モバイルノードのシームレスなモビリティを提供するのに役立ちます。ハンドオーバーパフォーマンスの向上には、マルチレベルの階層は必要ありません。したがって、オペレーターのネットワーク内の任意の位置に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 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つのサブネットから次のサブネットに移動するにつれて、マップディスカバリーのプロセスが継続されます。モバイルノードが動きを検出するたびに、同じマップドメインにまだあるかどうかも検出されます。動きを検出するために使用されるルーター広告は、マップオプションを介して、同じマップドメインにあるかどうかを介してモバイルノードにも通知します。モバイルノードが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 [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-awareでない場合、マップの発見は実行されないため、モバイルIPv6 [1]プロトコルを使用してモバイルノードがモバイルノードを使用してモバイルノードを使用します。一方、モバイルノードがhmipv6-awareである場合、hmipv6実装を使用することを選択する必要があります。その場合、モバイルノードは、最初に自宅の住所とオンリンクアドレス（LCOA）を含むBUを送信して、マップに登録する必要があります。BUで使用されるホームアドレスはRCOAです。マップは、この情報をバインディングキャッシュに保存して、異なる特派員ノードまたは持っている場合に最終的な宛先にパケットを転送できるようにする必要があります。
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.
モバイルノードは、ルートの最適化が必要かどうかを判断するために、受信したパケットの元の送信者を常に知る必要があります。この情報は、マップが元のパケットの内容を変更しないため、モバイルノードで利用できます。受信したパケットの通常の処理（[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.
ネットワークの帯域幅をより効率的に使用するために、モバイルノードは複数のマップに同時に登録し、特派員ノードの特定のグループに各マップアドレスを使用することを決定する場合があります。たとえば、図1では、特派員ノードがモバイルノードと同じリンクにたまたま存在する場合、それらの間の通信に最初のホップマップ（この場合はAR1であると仮定）を使用する方が効率的です。これにより、階層内の「最高の」マップを介してすべてのパケットが送信されないため、ネットワーク帯域幅をより効率的に使用することになります。モバイルノードは、[1]で指定されているように、現在のオンリンクアドレス（LCOA）をCOAとして使用することもできます。モバイルノードは、別のマップに送信されたバインディングアップデートで、マップのサブネットからRCOAをLCOAとして提示しないでください。バインディングアップデートに含まれる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ドメインに属するすべてのARは、マップのIPアドレスを宣伝する必要があります。同じ概念（ドメイン内でマップの存在を宣伝する）を使用する必要があります。
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フラグは、マップ登録を示しています。モバイルノードがマップを使用して登録する場合、この登録を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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description of extensions to the binding update:
バインディングアップデートへの拡張機能の説明：
M If set to 1 it indicates a MAP registration.
mに設定されている場合、マップ登録を示します。
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 Neighbor Discoveryオプションを入力します。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.
MAPと広告の受信機との間の距離を識別する4ビットの署名されていない整数を区別します。動的マップ発見が使用される場合は、デフォルト値を1に設定する必要があります。マップがモバイルノードと同じリンクにある場合、距離は1に設定する必要があります。このフィールドは、マップとモバイルノードの間のホップ数として解釈する必要はありません。唯一の要件は、距離フィールドの意味が1つのドメイン内で一貫して解釈されることです。ゼロの距離値を使用しないでください。
Pref The preference of a MAP. A 4-bit unsigned integer. A decimal value of 15 indicates the highest availability.
マップの好みをプレイしてください。4ビットの符号なし整数。15の小数値は、最高の可用性を示しています。
R When set to 1, it indicates that the mobile node MUST form an RCoA based on the prefix in the MAP option.
r 1に設定すると、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.
有効な寿命マップのサブネットに割り当てられたプレフィックスの優先寿命と有効な寿命の両方の最小値（秒単位）。この値は、マップのアドレスの有効性を示し、その結果、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.
グローバルアドレスマップのグローバルアドレスの1つ。このアドレスから抽出された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.
マップオプションに明示的に含まれていませんが、マップのグローバルIPアドレスのプレフィックス長は64でなければなりません。このプレフィックスは、プレフィックスに64ビット識別子を追加することにより、RCOAを形成するためにモバイルノードで使用されるものです。したがって、マップのサブネットの静的プレフィックスの長さが必要です。
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). 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.
モバイルノードが新しいマップドメインに移動する場合（つまり、マップが変更されます）、マップのリンク上のRCOAとリンクCOA（LCOA）の2つのCOAを構成する必要があります。RCOAは、無国籍方法で形成されます。MAPオプションで受信したプレフィックスに基づいてRCOAを形成した後、モバイルノードはAフラグセットとMフラグを使用してローカルBUをマップに送信します。ローカルBUは[1]で定義されているBUで、モバイルノードのRCOAにホームアドレスオプションが含まれています。このメッセージでは、代替COAオプションは必要ありません。LCOAは、BUのソースアドレスとして使用されます。このBUは、モバイルノードのRCOA（自宅の住所と同様）をLCOAに結合します。マップ（HAとして機能する）は、モバイルノードの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.
マップへの登録が成功した後、モバイルノードとマップの間の双方向トンネルが確立されます。モバイルノードから送信されたすべてのパケットは、マップにトンネルされています。外側のヘッダーには、ソースアドレスフィールドにモバイルノードの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 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.
この仕様により、モバイルノードが複数のマップオプションを受け取った場合、モバイルノードを複数の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を送信することにより、HAで新しいRCOAを登録する必要があります。モバイルノードのホームアドレスはホームアドレスオプションで使用され、RCOAはソースアドレスフィールドのケアオブアドレスとして使用されます。また、モバイルノードは、現在の特派員ノードに同様のBU（つまり、ホームアドレスとRCOAの間のバインディングを指定する）を送信する場合があります。
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に登録する前に、マップからのバインディングの確認を待つ必要があります。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, which are connected to its 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 [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.
モバイルノードが特派員ノード（つまり、CNがモバイルノードのバインディングキャッシュエントリがある）と直接通信する場合、モバイルノードは、クレENTENTノード（RCOAのバインディングキャッシュエントリを作成するために使用される同じケアオブアドレスを使用する必要があります。）ソースアドレスとして。[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.
マップは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.
マップには、モバイルノードの自宅の住所に関する知識がありません。モバイルノードは、Mとフラグセットを使用してローカルBUをマップに送信します。このBUの目的は、モバイルノードがRCOA（自宅の住所としてBUに含まれる）を形成したことをマップに通知することです。成功した場合、マップはモバイルノードに拘束力のある承認を返す必要があり、登録が成功したことを示しています。これは、[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.
マップは、モバイルノードからトンネルに登録されたパケットを受け入れることができなければなりません。モバイルノードはトンネルのエントリポイントであり、マップはトンネル出口ポイントです。
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].
マップはRCOAのHAとして機能します。RCOAにアドレス指定されたパケットは、プロキシNeighbor広告を使用してマップによって傍受され、カプセル化されてモバイルノードのLCOAにルーティングされます。この操作は、[1]に記載されている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 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).
マップは、モバイルノードがLCOAを導出するために使用できる有効なオンリンクプレフィックスのリストで構成できます。これは、ネットワークオペレーターがモバイルノードが別の管理ドメインに移動した後もマップの使用を継続しないようにするのに役立ちます。モバイルノードが、マップの「有効なオンリンクプレフィックス」リストにない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 [1].
HMIPV6のサポートは、HAの操作に対して完全に透明です。モバイルノードのホームアドレスにアドレス指定されたパケットは、[1]に記載されているように、HAによってRCOAに転送されます。
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]では、短期通信、特に障害時に簡単に再試行する可能性がある短期通信の場合、モバイルノードはパケットのソースとしてそのケアアドレスの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の使用は、グローバルなモビリティを提供しません（つまり、モバイルホストが新しいマップに移動すると通信が壊れます）、いくつかのアプリケーション（例：Webブラウジング）に役立ちます。アプリケーションで使用されるソースアドレスとしてのRCOAの有効性は、マップドメインのサイズとモバイルノードの速度によって異なります。さらに、特派員ノードでの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を隠します。その結果、対応するノードまたはホームエージェントによるモバイルノードの位置追跡は、RCOAではなく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.
このセクションでは、モバイルノードがマップアドレスとサブネットのプレフィックスを取得する方法と、ドメイン内のARがマップを発見する方法について説明します。マップ発見のための2つの異なる方法を以下に定義します。
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.
動的マップの発見は、オペレーターのネットワーク内のルーター内の特定の（構成された）ルーターインターフェイスを介して、マップからモバイルノードへのルーター広告のマップオプションを伝播することに基づいています。これには、マップの手動構成が必要であり、マップオプションを受信するルーターが特定のインターフェイスでオプションを伝播できることも必要です。ルーター間の安全な通信を確保するには、動的マップ発見のためにルーター間で送信されるルーター広告を認証する必要があります（AH、ESP、または送信など）。この認証が不可能な場合（たとえば、マップとARSの間にサードパーティのルーターが存在する場合）、ネットワークオペレーターは、このドキュメントで説明されているように、すべての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.
ARSおよび同じドメインのその他のマップのMAPオプション情報の手動構成は、デフォルトのメカニズムです。また、MAP発見の動的メカニズムを有効にするためにARSとマップを構成することも可能です。
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
マップディスカバリーのプロセスは、さまざまな方法で実行できます。ルーター広告は、新しいオプションを導入することにより、動的マップの発見に使用されます。アクセスルーターは、ルーター広告にマップオプションを送信するために必要です。このオプションには、モバイルノードからの距離ベクトル（ホップ数に関して実際の距離を意味しない場合があります）、この特定のマップ、マップのグローバル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ドメイン内のARSは、マップオプションに関連する情報を使用して動的に構成できます。ARSは、MAPオプションを使用してRASをリッスンすることにより、この情報を取得する場合があります。ネットワーク内の各マップは、デフォルトの設定、このオプションを送信するための適切なインターフェイス、および送信される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.
マップオプションを使用してルーター広告を受信すると、受信ルーターはオプションをコピーして、距離フィールドを1つずつ増やした後に再センドする必要があります。受信ルーターもマップである場合、同じ広告で、受信オプションとともに独自のオプションを送信する必要があります。ルーターが同じマップに対して複数のマップオプションを受信した場合（つまり、マップオプションの同じIPアドレス）、2つの異なるインターフェイスから、最小距離フィールドのオプションを選択する必要があります。
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.
この方法で、1つ以上のマップに関する情報をモバイルノードに動的に渡すことができます。さらに、このように発見フェーズを実行することにより、さまざまなマップノードが、ローカルポリシー、ノード過負荷、または使用されているその他の負荷シェアリングプロトコルに基づいて、好みを動的に変更できます。
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.
マップは、他のマップに属するオプションまたはリレーマップオプションを特定のインターフェイスに送信するように構成されます。インターフェイスの選択は、ネットワーク管理者（つまり、手動構成）によって行われ、ネットワークトポロジに依存します。10のデフォルト設定値を各マップに割り当てることができます。さまざまな理由（ノードの過負荷または負荷共有など）により、マップはいつでも選好値を変更できることに注意してください。ゼロの優先値は、新しいモバイルノードによってマップを選択しないことを意味します。この値は、ノードの過負荷または部分ノードの障害の場合に到達できます。
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).
マップオプションは、そのドメイン内のARSに向かって伝播されます。ARへのパスに沿った各ルーターは、距離フィールドを1つずつ増加させます。マップであるルーターが他のマップから広告を受信する場合、独自のマップオプションを追加し、次のルーターまたはARに両方のオプションを伝播する必要があります（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を意識したモバイルノードがルーター広告を受信した場合、マップオプションを検索する必要があります。さまざまなマップIPアドレスに対して1つ以上のオプションが見つかる場合があります。
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.
モバイルノードは、最高の優先値を持つマップに登録する必要があります。ゼロの優先値を持つマップは、新しいローカルバスに使用しないでください（つまり、モバイルノードは既存のバインディングを更新できますが、新しいバインディングを作成できません）。ただし、設定値がゼロを超えている場合、モバイルノードは、距離フィールドで受信した値に応じて、あるマップに別のマップよりも登録することを選択できます。
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].
ゼロの有効な生涯値を含むマップオプションは、このマップをMNによって選択してはならないことを意味します。ゼロの有効な寿命は、マップの障害を示します。このオプションを受信した場合、モバイルノードは別のマップを選択し、新しいバインディングを作成する必要があります。このマップを備えた既存のバインディングは、失われると想定できます。他のマップが使用できない場合、[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に同時にアクセスできる場合（異なるインターフェイスで）、現在のマップを宣伝する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 no MAP options are found in the router advertisement, the mobile node MUST use the Mobile IPv6 protocol, as specified in [1].
ルーター広告にマップオプションが見つからない場合、[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フラグが設定されている場合、モバイルノードは、マップ登録を実行するときに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ネットワークでは、モバイルノードは次のようにする必要があります。
- "Eager" to perform new bindings - "Lazy" in releasing existing bindings
- 新しいバインディングを実行しようとする「熱心」 - 既存のバインディングをリリースする際に「怠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. 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.
複数のマップを備えたネットワーク内の距離ベースの選択に関して、モバイルノードは、頻繁に再登録されないように、最も遠いマップに登録することを選択できます。これは、頻繁なハンドオフを実行する高速モバイルノードにとって特に重要です。このシナリオでは、より遠いマップを選択すると、マップを変更し、すべての特派員ノードとHAを通知する確率が低下します。この仕様は、距離ベースのマップ選択のアルゴリズムを提供しません。ただし、このようなアルゴリズムは、下層からの移動速度に関する情報を利用して、将来の拡張機能で導入される場合があります。
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オプションの設定フィールドと組み合わせて、入力（距離ベースの選択）としてモバイルノード速度を使用します。ただし、この仕様は、モバイルノードが次のアルゴリズムをデフォルトとして使用していることを提案しており、他の最適化されたアルゴリズムが利用できない場合があります。次のアルゴリズムは、その優先値がゼロの値に達していない限り、最も遠いマップの選択に基づいています。モバイルノード操作を以下に示します。
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. すべてのマップオプションを受信して解析する2.最も遠いアウェイマップ（つまり、最大のDISTフィールドを持つマップオプション）から始めて、マップを降順で配置します。3。リスト4の最初のマップを選択します。ゼロに設定されており、リスト内の次のマップを選択します。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 u0movement is not frequent.
ネットワークオペレーターは、モバイルIPv6のハンドオーバーがまれなイベントと見なされる場合がある場合に、フラットアーキテクチャを選択する場合があります。これらのシナリオでは、オペレーターはARSのみにマップ機能を含めることを選択できます。ARSにマップ関数を含めることは、すべての特派員ノードとHAを更新するのに必要な時間を短縮するのに役立ちます。このシナリオでは、モバイルノードがハンドオフを実行するときにアンカーポイントとしてマップ（AR）を選択する場合があります。この種の動的な階層（または固定）は、AR間のU0モーブメントが頻繁ではない場合にのみ推奨されます。
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.
この仕様では、訪問されたネットワークでローカルホームエージェントと見なすことができるマップを紹介します。ホームエージェントのような地図は、単一の失敗ポイントです。マップが故障した場合、バインディングキャッシュコンテンツが失われ、モバイルノードと特派員ノード間の通信が失われます。この状況は、同じリンクで複数のマップを使用し、それらの間に何らかの形のコンテキスト転送プロトコルを利用することにより、回避される場合があります。あるいは、仮想ルーター冗長プロトコル[4]またはHA冗長プロトコルの将来のバージョンでは、ネットワークがマップ障害から回復できる場合があります。
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.
このようなプロトコルがサポートされていない場合、モバイルノードはマップ障害を検出する必要があります。モバイルノードは、生涯ゼロのマップオプションを含むルーター広告を受信すると、この状況を検出できます。モバイルノードは、マップ発見プロセスを開始し、別のマップに登録しようとする必要があります。別のマップに選択して登録した後、RCOAが変更された場合は、特派員ノードとホームエージェントに通知する必要があります。冗長性のためにマップ間でバインディングされたキャッシュエントリを転送するプロトコルが存在する場合、新しいマップはモバイルノードに同じRCOAを提供できる場合があります（たとえば、両方のマップがマップオプションで同じプレフィックスを宣伝する場合）。これにより、モバイルノードが特派員ノードとホームエージェントの更新から節約されます。
Access routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:
アクセスルーターをトリガーして、さまざまな方法でゼロ（マップ障害を示す）でマップオプションを宣伝することができます。
- 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は、ICMPエコーリクエストメッセージを定期的に（たとえば、10秒ごとに）マップにエコーリクエストメッセージを送信することにより、マップ障害の動的検出を実行できます。応答がない場合、ARはエコーリクエストを短期間（たとえば、15秒間5秒ごとに1回）マップに積極的に送信しようとする場合があります。返信がない場合、有効な生涯値がゼロでマップオプションが送信される場合があります。
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.
この仕様は、特定の回復メカニズムを義務付けるものではありません。ただし、メッセージ認証、整合性の保護、およびリプレイ攻撃に対する保護を可能にするために、マップと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 Neighter Discoveryオプションを紹介します。IANAは、IPv6ネイバーディスカバリーメッセージのスペースを番号付けするオプション番号内のマップオプションにオプションタイプ値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に新しい概念を紹介します。つまり、ローカルホームエージェントとして機能するモビリティアンカーポイントです。モバイルノードとマップのセキュリティ関係が強力であることが重要です。相互認証、整合性の保護、およびリプレイ攻撃に対する保護が必要です。ペイロードトラフィックには機密性が必要になる場合がありますが、マップへの更新をバインドするためには必要ありません。これらの保護のいずれかがないと、他の正当なものになりすましたり、地図になりすましている悪意のあるモバイルノードにつながる可能性があります。これらの攻撃のいずれかは、モバイルノードのRCOAの知識を持つすべての特派員ノードとのモバイルノードの通信に間違いなく望ましくない影響を引き起こします。
Three different relationships (related to securing binding updates) need to be considered:
3つの異なる関係（拘束力のある更新の確保に関連）を考慮する必要があります。
1) The mobile node - MAP 2) The mobile node - Home Agent 3) The mobile node - correspondent node
1) モバイルノード - マップ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).
モバイルノードがマップの転送サービスを使用できるようにするには、初期認証（特にRCOA用ではなくサービス専用）が必要になる場合があります。MAPサービスを使用するモバイルノードの許可は、SA交渉プロセス中に交換されたモバイルノードのIDに基づいて実行できます。承認は、モバイルノードの身元に基づいて、またはマップが信頼する証明書当局（CA）の身元に基づいて付与される場合があります。たとえば、モバイルノードが信頼できるエンティティ（たとえば、同じ管理ドメインに属するCA、または別の信頼できるローミングパートナーに属するCA）によって署名された証明書を提示する場合、マップがサービスの使用を許可するのに十分です。このレベルの承認は、特定のRCOAの使用を承認することとは無関係であることに注意してください。同様に、モバイルノードは、同じCAまたはモバイルノードが信頼できるように構成されている別のCAによって署名された証明書を提示する場合、マップを信頼します（たとえば、ローミングパートナー）。
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は、モバイルノードとその現在のマップの間に追加の登録を使用します。このドキュメントで説明したように、モバイルノードが新しいドメインに移動すると（つまり、新しいマップで提供される）、RCOA、LCOAを取得し、新しいマップでこれら2つのアドレス間のバインディングを登録します。次に、このマップは、RCOAがまだ登録されていないかどうかを確認し、もしそうなら、RCOAおよびLCOAを使用したバインディングキャッシュエントリを作成します。モバイルノードが新しいLCOAを取得するたびに、RCOAとその新しいLCOAの間のバインディングを指定する新しいBUを送信する必要があります。このBUは認証する必要があります。そうしないと、どのホストもモバイルノードのRCOAにBUを送信し、モバイルノードのパケットをハイジャックできます。ただし、RCOAは一時的で特定のノードに拘束されていないため、モバイルノードは最初に（最初のバインディングアップデートの前に）RCOAを所有していることを証明する必要はありません（モバイルIPv6のホームアドレスの要件とは異なります）マップとセキュリティ関連を確立します。マップは、特定の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.
マップは、モバイルノードのIDや自宅の住所について事前に知る必要はありません。その結果、IKEなどの主要な確立プロトコルを使用して、モバイルノードとマップ間のSAを確立できます。返品ルー上のテストは必要ありません。
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.
マップは、RCOA（LCOAではなく）にSAを設定する必要があります。これは、IKE [2]で実行できます。モバイルノードはLCOAをソースアドレスとして使用しますが、RCOAをSAで使用する必要があることを指定します。これは、RCOAをIKEフェーズ2ネゴシエーションのアイデンティティとして使用することによって達成されます。このステップは、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 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.
特定のRCOAに対してバインディングキャッシュエントリが存在する場合、マップのIKEポリシーチェックは、エントリのインストールに使用されるSAを指す必要があります。既存のSAに保存されているモバイルノードの資格情報が、現在の交渉で提供されているものと一致しない場合、マップは無効なID情報通知でそのようなRCOAの新しいSA設立要求を拒否する必要があります[2]。これは、2つの異なるモバイルノードが同じRCOAを（意図的に）登録するのを防ぐためです。この通知を受信すると、モバイルノードは新しいRCOAを生成し、IKEネゴシエーションを再起動する必要があります。あるいは、地図は、特定の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.
マップとモバイルノード間のバインディングの更新は、AHまたはESPのいずれかで輸送モードで保護する必要があります。ESPを使用する場合、非ヌル認証アルゴリズムを使用する必要があります。
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メッセージを含むパケットは2回カプセル化されています。内側のカプセル化ヘッダーには、ソースアドレスフィールドにRCOAと宛先アドレスフィールドにホームエージェントのアドレスが含まれています。外側のカプセル化ヘッダーには、ソースアドレスフィールドにモバイルノードのLCOAと宛先フィールドにマップのアドレスが含まれています。
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.
著者は、この文書への貴重な入力について、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 (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.
さらに、著者は、以下のワーキンググループのメンバーにアルファベット順に感謝したいと思います。サミタ・チャクラバルティ（太陽）、グレゴリー・デイリー（モナッシュ大学）、フランシス・デュポン（Get/Enst Bretagne）、Gopal Dommety（Cisco）、Eva Gustaffsonson（エリクソン）、デイブ・ジョンソン（ライス大学）、アニカ・ジョンソン（エリクソン）、ジェームズ・ケンプフ（ドコモ・ラボ）、マルティ・クパリネン（エリクソン）フェルガル・ラドリー、ガブリエル・モンテネグロ（サン）、ニック・「シャルキー」ムーア（モナッシュ大学）エリック・ノルドマーク（Sun）、Basavaraj Patil（Nokia）、Brett Pentland（Monash University）、およびAlper Yegin（Samsung）文書に関するコメントについて。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[2] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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.
レイヤー3（モバイルIP）のハンドオーバー遅延が最小化されることを保証するために、高速ハンドオーバーは、モバイルノードが2つのARの間で移動するときに通常発生するサービス中断の期間を最小限に抑え、場合によっては排除するために必要です。このサービスの中断期間は、通常、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.
1) PARに接続されている間、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.
2) NARケースで使用する新しいCOA：モバイルノードでF-BU（Fast BU）を以前のアンカーポイント（つまりPAR）に送信して、PARに取り付けられながらモバイルノードの新しいCOAでバインディングキャッシュを更新します。
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が該当しない場合はNARにトンネルが付けられた古いCOA）。
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.
4) NARケースで使用する古いCOA：モバイルノードは、NARに移動して接続した後、以前のアンカーポイント（すなわち、PAR）にF-BU（高速BU）を送信します。モバイルノードの新しい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は、Handover Initiate（HI）メッセージをNARに送信することにより、モバイルノードの新しい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]では、ARSはローカルホームエージェントとして機能し、モバイルノードのバインディングキャッシュを保持し、バインディングアップデートを受け取ります。これにより、これらのARSは、このドキュメントで指定されたマップのように機能します。また、ARSが直接接続されていないが、集約ルーターを介して通信する可能性は十分にあります。したがって、このような集約ルーターは、マップ機能にとって理想的な位置でもあります。これらは、HMIPv6と高速ハンドオーバーメカニズムを統合する2つの方法です。1つ目は、ARSの代わりにマップを配置することです。これは自然なステップです。2番目のシナリオでは、ARSの上に「上に「上記」の集約ルーターにマップを配置することが含まれます。この場合、[5]は、PARとNARの間のパケットの転送を指定します。これは、パケットがMap-Parリンクを2回横断し、パケットがモバイルノードで順番に到着するため、遅延と帯域幅の効率の点では非効率的である可能性があります。集約ルーターでマップを使用すると、高速の拳銃の効率が向上し、マップを使用してトラフィックをリダイレクトできるため、集約ルーターとPARの間の遅延と帯域幅を節約できます。
+---------+
| 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：HMIPv6を使用した高速モバイルIPv6ハンドオーバープロトコル
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/ハックメッセージがマップとNARの間に発生するようになりました。したがって、高速ハンドオーバー手順の同じ機能が保持されますが、アンカーポイントは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.
以前の高速ハンドオーバー手順と同様に、ネットワーク決定されたケースでは、PARのレイヤー2「トリガー」により、PARはマップオプションを使用してモバイルノードにプロキシルーター広告を送信します。モバイル決定されたケースでは、これにはモバイルノードからのプロキシルーターの勧誘が前にあります。ネットワーク決定されたケースのPARで同じレイヤー2トリガーを使用して、PARとNARの間のコンテキスト転送（QOSなど）を独立して開始することができます。モバイル決定されたケースでは、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ハンドオフを予測できるため、データトラフィックを移動する前にモバイルノードの新しい場所に効率的にリダイレクトできます。ただし、マップからモバイルノードの新しい場所へのトラフィックの転送を開始する正しい時間を判断するのは簡単ではありません。これは、ハンドオフのスムーズに影響を与えます。PARとNAR間の転送をいつ開始するかに関して、[5]で同じ問題が発生します。これが、モバイルノードがPARから剥離してNARに付着する時間に関して、これが遅すぎるか早すぎるとパケットの損失が発生します。このようなパケットの損失は、モバイルノードがいつモバイルノードを実行するかをNARに実行または完了する時期が正確にわからないため、予想されるF-BUを受信したときにマップがバインディングキャッシュを更新する場合に発生する可能性があります。F-Buを送信します。また、モバイルノードのレイヤー-2ハンドオーバーが予期せずに失敗する場合（高速ハンドオーバーが開始された後）、またはモバイルノードがARS（Ping-Pong）の間で迅速に移動する場合（Ping-Pong）をサポートするには、ある程度の尺度が必要です。同時バインディング[6]は、これらの問題の解決策を提供します。[6]では、高速バインディングアップデート（F-BU）メッセージに新しい同時バインディングフラグが追加され、高速バインディング確認（Fバック）メッセージに対して新しい同時バインディングサブオプションが定義されます。この強化されたメカニズムを使用して、レイヤー-3ハンドオーバー時に、モバイルノードのトラフィックが特定の期間マップからPARとNARの両方に送信されるため、ハンドオーバータイミング、ping-pongなどのレイヤー2効果からモバイルノードを分離します。、またはハンドオーバーの障害とモバイルノードに途切れないレイヤー3接続を提供します。
Authors' Addresses
著者のアドレス
Hesham Soliman Flarion Technologies
Hesham Soliman Flarion Technologies
EMail: h.soliman@flarion.com
Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
Claude Castelluccia Inria Rhone-Alpes 655 Avenue de L'Europe 38330 Montbonnot Saint-Martin France
EMail: claude.castelluccia@inria.fr
Phone: +33 4 76 61 52 15
Karim El Malki Ericsson AB LM Ericssons Vag. 8 126 25 Stockholm Sweden
Karim El Malki Ericsson Ab Lm Ericsons vag。8 126 25ストックホルムスウェーデン
EMail: karim@elmalki.homeip.net
Ludovic Bellier INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
Ludovic Bellier Inria Rhone-Alpes 655 Avenue de L'Europe 38330 Montbonnot Saint-Martin France
EMail: ludovic.bellier@inria.fr
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。