Network Working Group                                         H. Soliman
Request for Comments: 5380                          Elevate Technologies
Obsoletes: 4140                                          C. Castelluccia
Category: Standards Track                                          INRIA
                                                              K. ElMalki
                                                              L. Bellier
                                                            October 2008
         Hierarchical Mobile IPv6 (HMIPv6) Mobility Management

Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。



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.


Table of Contents


   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Overview of HMIPv6 ..............................................5
      3.1. HMIPv6 Operations ..........................................6
   4. Mobile IPv6 Extension - Local Binding Update ....................9
   5. Neighbour Discovery Extension: The MAP Option ...................9
   6. Protocol Operation .............................................10
      6.1. Mobile Node Operation .....................................11
           6.1.1. Sending Packets to Correspondent Nodes .............12
      6.2. MAP Operations ............................................13
      6.3. Home Agent Operations .....................................13
      6.4. Correspondent Node Operations .............................13
      6.5. Local Mobility Management Optimisation within a
           MAP Domain ................................................14
      6.6. Location Privacy ..........................................14
   7. MAP Discovery ..................................................15
      7.1. Mobile Node Operation .....................................15
   8. Updating Previous MAPs .........................................16
   9. Note on MAP Selection by the Mobile Node .......................16
      9.1. MAP Selection in Distributed MAP Environment ..............17
      9.2. MAP Selection in a Flat Mobility Architecture .............18
   10. Detection and Recovery from MAP Failures ......................18
   11. Tunelling Impacts on MTU ......................................19
   12. Security Considerations .......................................19
      12.1. Mobile Node - MAP Security ...............................20
      12.2. Mobile Node - Correspondent Node Security ................22
      12.3. Mobile Node - Home Agent Security ........................22
   13. IANA Considerations ...........................................22
   14. Acknowledgements ..............................................22
   15. References ....................................................23
      15.1. Normative References .....................................23
      15.2. Informative References ...................................23
   Appendix A. Changes from RFC 4140 .................................24
1. Introduction
1. はじめに

This specification introduces the concept of a hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).


Mobile IPv6 [RFC3775] allows nodes to move within the Internet topology while maintaining reachability and ongoing connections between mobile and correspondent nodes. To do this, a mobile node sends binding updates (BUs) to its home agent (HA) every time it moves.

モバイルIPv6 [RFC3775]はモバイルとコレスポンデントノードとの間の到達可能性と継続的な接続を維持しながら、ノードがインターネットトポロジ内で移動することを可能にします。これを行うには、モバイルノードは、そのホームエージェント(HA)が移動するたびにバインディングアップデート(BUS)を送信します。

The mobile node may send data packets via its home agent immediately after sending the binding update, but the home agent will not be able to route traffic back to the mobile node before it receives the binding update. This incurs at least half a round-trip delay before packets are again forwarded to the right place. There is an additional delay for sending data packets if the mobile node chooses to wait for a binding acknowledgement (BA). The round-trip times can be relatively long if the mobile node and its home agent are in different parts of the world.


Additional delay is also incurred if the mobile node employs route optimisation. Authenticating binding updates requires approximately 1.5 round-trip times between the mobile node and each correspondent node (for the entire return routability procedure in a best-case scenario, i.e., no packet loss). This can be done in parallel with sending binding updates to the home agent, and there are further optimisations that reduce the required 1.5 round-trips [RFC4449] [RFC4651] [RFC4866].

モバイルノードは、ルート最適化を採用した場合、追加遅延も発生しています。バインディング更新を認証する(最良の場合のシナリオ、すなわち、パケットロス全体リターン・ルータビリティ手順のための)モバイルノードと各コレスポンデントノードとの間に約1.5往復時間を必要とします。これは、ホームエージェントにバインディングアップデートを送信と並行して行うことができ、かつ必要な1.5ラウンドトリップ[RFC4449] [RFC4651] [RFC4866]を減らす更なる最適化があります。

Nevertheless, the signalling exchanges required to update your location will always cause some disruption to active connections. Some packets will be lost. Together with link layer and IP layer connection setup delays, there may be effects to upper-layer protocols. Reducing these delays during the time-critical handover period will improve the performance of Mobile IPv6.


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.


For these reasons, a new Mobile IPv6 node, called the Mobility Anchor Point, is used and can be located at any level in a hierarchical network of routers, including the Access Router (AR). The MAP will limit the amount of Mobile IPv6 signalling outside the local domain.

これらの理由から、新たなモバイルIPv6ノードのために、使用され、モビリティアンカーポイントと呼ばれ、アクセスルータ(AR)を含むルータの階層ネットワーク内の任意のレベルに配置することができます。 MAPは、ローカルドメイン外のモバイルIPv6シグナリングの量を制限します。

The introduction of the MAP provides a solution to the issues outlined earlier, in the following way:


o The mobile node sends binding updates to the local MAP rather than the home agent (HA) (which is typically further away) and correspondent nodes (CNs).


o Only one binding update message needs to be transmitted by the mobile node (MN) before traffic from the HA and all CNs is re-routed to its new location. This is independent of the number of CNs with which the MN is communicating.


A MAP is essentially a local home agent. The aim of introducing the hierarchical mobility management model in Mobile IPv6 is to enhance the performance of Mobile IPv6 while minimising the impact on Mobile IPv6 or other IPv6 protocols. Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and home agents, while using Mobile IPv6 route optimisation. The security differences between the MAP and the home agent are described in Section 12.

MAPは、基本的にローカルホームエージェントです。モバイルIPv6における階層的モビリティ管理モデルを導入する目的は、モバイルIPv6、または他のIPv6プロトコルへの影響を最小限に抑えながら、モバイルIPv6の性能を向上することです。モバイルIPv6ルート最適化を使用しながら、また、HMIPv6のは、モバイルノードがコレスポンデント・ノードとホーム・エージェントから自分の位置を隠すことを可能にします。 MAPとホームエージェント間のセキュリティの違いは、セクション12で説明されています。

It is pertinent to note that the use of the MAP does not rely on, or assume the presence of, a permanent home agent. In other words, a mobile node need not have a permanent home address or home agent in order to be HMIPv6-aware or use the features in this specification. A MAP may be used by a mobile node in a nomadic manner to achieve mobility management within a local domain. Section 6.5 describes such a scenario.

MAPの使用はに依存している、または永久的なホームエージェントの存在を前提としないことに注意することは適切です。言い換えれば、移動ノードは、HMIPv6の認識であるか、またはこの仕様で機能を使用するために、恒久的なホームアドレスまたはホームエージェントを有する必要はありません。 MAPは、ローカルドメイン内のモビリティ管理を達成するためにノマディックようにモバイルノードによって使用されてもよいです。 6.5節では、このようなシナリオについて説明します。

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

In addition, the following terms are introduced:


Access Router (AR)


The AR is the mobile node's default router. The AR aggregates the outbound traffic of mobile nodes.

ARは、モバイルノードのデフォルトルータです。 ARは、モバイルノードのアウトバウンドトラフィックを集約します。

Mobility Anchor Point (MAP)


A Mobility Anchor Point is a router located in a network visited by the mobile node. The MAP is used by the MN as a local HA. One or more MAPs can exist within a visited network.

モビリティアンカーポイントは、モバイルノードによって訪問先ネットワークに位置してルータです。 MAPは、ローカルHAとしてMNによって使用されます。一つ以上のMAPは、訪問先ネットワーク内に存在することができます。

Regional Care-of Address (RCoA)


An RCoA is an address allocated by the MAP to the mobile node.


HMIPv6-Aware Mobile Node


An HMIPv6-aware mobile node is a mobile node that can receive and process the MAP option received from its default router. An HMIPv6-aware mobile node must also be able to send local binding updates (binding update with the M flag set).

HMIPv6の認識、移動ノードは、受信したMAPオプションがデフォルトのルータから受信し処理することができ、移動ノードです。 HMIPv6の対応のモバイルノードは、(Mフラグが設定されたバインディング更新)、ローカルバインディングアップデートを送信することができなければなりません。

On-Link Care-of Address


The LCoA is the on-link CoA configured on a mobile node's interface based on the prefix advertised by its default router. In [RFC3775], this is simply referred to as the care-of address. However, in this memo LCoA is used to distinguish it from the RCoA.

LCoAは、そのデフォルトルータによってアドバタイズプレフィックスに基づいて、移動ノードのインターフェイスに設定されたオンリンクのCoAです。 [RFC3775]では、これは単に気付アドレスと呼ばれます。しかし、このメモでのLCoAがRCoAを区別するために使用されています。

Local Binding Update


The MN sends a local binding update to the MAP in order to establish a binding between the RCoA and LCoA.


3. Overview of HMIPv6

This hierarchical Mobile IPv6 scheme introduces a new function, the MAP, and minor extensions to the mobile node operation. The correspondent node and home agent operations will not be affected.


Just like Mobile IPv6, this solution is independent of the underlying access technology, allowing mobility within or between different types of access networks.


A mobile node entering a MAP domain will receive Router Advertisements containing information about one or more local MAPs. The MN can bind its current location (on-link CoA) with an address on the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all packets on behalf of the mobile node it is serving and will encapsulate and forward them directly to the mobile node's current address. If the mobile node changes its current address within a local MAP domain (LCoA), it only needs to register the new address with the MAP. Hence, only the Regional CoA (RCoA) needs to be registered with correspondent nodes and the HA. The RCoA does not change as long as the MN moves within a MAP domain (see below for definition). This makes the mobile node's mobility transparent to correspondent nodes it communicates with.

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.


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(例えば、同じ部位)の近傍にあるかどうかを決定するための方法は、この文書の範囲外です。

3.1. HMIPv6 Operations
3.1. HMIPv6の操作

The network architecture shown in Figure 1 illustrates an example of the use of the MAP in a visited network.


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.


   |  HA   |
   +-------+       +----+
       |           | CN |
       |           +----+
       |             |
                 |  MAP  |
                 |      |
                 |      +--------+
                 |               |
                 |               |
               +-----+          +-----+
               | AR1 |          | AR2 |
               +-----+          +-----+
               LCoA1             LCoA2
               | MN |
               +----+   ------------>

Figure 1: Hierarchical Mobile IPv6 domain


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 Neighbour Discovery [RFC4861] and the MAP option, whether it is still in the same MAP domain. As the mobile node roams within a MAP domain, it will continue to receive the same


MAP option included in Router Advertisements from its AR. If a change in the advertised MAP's address is received, the mobile node MUST act on the change by sending binding updates to its HA and correspondent nodes.


If the mobile node is not HMIPv6-aware, then no MAP Discovery will be performed, resulting in the mobile node using the Mobile IPv6 [RFC3775] protocol for its mobility management. On the other hand, if the mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 implementation. If so, the mobile node will first need to register with a MAP by sending it a BU containing its home address and on-link address (LCoA). The home address used in the BU is the RCoA, which the mobile node acquires via RFC 4877 [RFC4877] Section 9 mechanisms when it first contacts a given MAP. The MAP MUST store this information in its binding cache to be able to forward packets to their final destination when received from the different correspondent nodes or HAs.

移動ノードがHMIPv6の対応ではない場合、何のMAP検出は、移動性管理のためのモバイルIPv6 [RFC3775]プロトコルを使用してモバイルノードに得られ、実行されません。一方、モバイルノードがHMIPv6の-認識している場合には、そのHMIPv6の実装を使用することを選択する必要があります。もしそうなら、モバイルノードは、最初にそのホームアドレスとオンリンクのアドレス(のLCoA)を含むBUを送信することにより、MAPに登録する必要があります。 BUで使用されるホームアドレスは、モバイルノードは、RFC 4877 [RFC4877]セクションを介し9つのメカニズムこれは、最初にコンタクト所与MAPを取得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 [RFC3775]) will give the mobile node the necessary information.

モバイルノードは、常に、ルート最適化が必要かどうかを判断するために任意の受信したパケットの元の送信者を知っておく必要があります。 MAPは、元のパケットの内容を変更していないため、この情報は、移動ノードに利用できるようになります。 ([RFC3775]に記載されているように)受信したパケットの通常の処理は、移動ノードに必要な情報を与えます。

To use the network bandwidth in a more efficient manner, a mobile node may decide to register with more than one MAP simultaneously and to use each MAP address for a specific group of correspondent nodes. For example, in Figure 1, if the correspondent node happens to exist on the same link as the mobile node, it would be more efficient to use the first hop MAP (in this case assume it is AR1) for communication between them. This will avoid sending all packets via the "highest" MAP in the hierarchy and thus will result in more efficient usage of network bandwidth. The mobile node can also use its current on-link address (LCoA) as a CoA, as specified in [RFC3775]. Note that the mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a binding update sent to another MAP. The LCoA included in the binding update MUST be the mobile node's address, derived from the prefix advertised on its link.

より効率的な方法でネットワーク帯域幅を使用するように、モバイルノードは、同時に複数のマップに登録し、相手ノードの特定のグループのそれぞれのMAPアドレスを使用することを決定することができます。コレスポンデントノードは、モバイルノードと同じリンク上に存在するように発生した場合、例えば、図1に、それらの間の通信のために(この場合、それはAR1であると仮定する)最初のホップ・マップを使用する方が効率的であろう。これは、階層内で「最高」MAP経由ですべてのパケットを送信しないようになるため、ネットワーク帯域幅のより効率的な使用になります。 [RFC3775]で指定されるように、モバイルノードは、CoAとしてその現在のオンリンクアドレス(のLCoA)を使用することができます。モバイルノードが別のMAPに送信されたバインディング更新中のLCoAとしてMAPのサブネットからのRCoAが存在しない必要があります。バインディングアップデートに含まれてのLCoAは、そのリンクで宣伝接頭語に由来し、移動ノードのアドレスでなければなりません。

4. Mobile IPv6 Extension - Local Binding Update
4.モバイルIPv6拡張 - ローカルバインディングアップデート

This section outlines the extensions proposed to the binding update specified in [RFC3775].


A new flag is added: the M flag, which indicates MAP registration. When a mobile node registers with the MAP, the M and A flags MUST be set to distinguish this registration from a BU being sent to the HA or a correspondent node.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |            Sequence #         |
   |A|H|L|K|M|      Reserved       |            Lifetime           |
   |                                                               |
   |                                                               |

Figure 2: Local Binding Update




If set to 1, it indicates a MAP registration.


5. Neighbour Discovery Extension: The MAP Option
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |     Type      |    Length     |  Dist |  Pref |R|  Reserved   |
   |                      Valid Lifetime                           |
   |                                                               |
   +                                                               +
   |                                                               |
   +                  Global IP Address for MAP                    +
   |                                                               |
   +                                                               +
   |                                                               |

Figure 3: The MAP option




IPv6 Neighbour Discovery option. Its value is 23.




8-bit unsigned integer. The length of the option and MUST be set to 3.




A 4-bit unsigned integer identifying the distance between MAP and the receiver of the advertisement, measure in the number of hops and starting from 1 if the MAP is on the same link as the mobile node. A distance value of zero MUST NOT be used.



The preference field, used as an indicator of operator preference. A 4-bit unsigned integer. A decimal value of 15 indicates the highest preference. When comparing two potential MAPs, the mobile node SHOULD inspect this field as a tie-breaker for MAPs that have equal Dist values.

オペレータ選好の指標として使用優先フィールド。 4ビットの符号なし整数。 15の10進値は、最高の優先度を示しています。二つの潜在的なマップを比較するとき、モバイルノードは、同じディスト値を持つマップのタイブレーカーとしてこのフィールドを検査するべきです。



When set to 1, it indicates that the mobile node is allocated the RCoA by the MAP based on Section 9 of [RFC4877].


Valid Lifetime


The minimum value (in seconds) of both the valid lifetime of the prefix used to form the MAP's address and that used to form the RCoA. This value indicates the validity of the MAP's address and the RCoA.


Global Address


One of the MAP's global addresses.


6. Protocol Operation

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の機能を実行します。

6.1. Mobile Node Operation
6.1. モバイルノードの操作

When a mobile node moves into a new MAP domain (i.e., its MAP changes), it needs to configure two CoAs: an RCoA on the MAP's link and an on-link CoA (LCoA). After employing [RFC4877] to acquire an RCoA, the mobile node sends a local BU to the MAP with the A and M flags set. The local BU is a BU defined in [RFC3775] and includes the mobile node's RCoA in the Home Address option. No alternate-CoA option is needed in this message. The LCoA is used as the source address of the BU. This BU will bind the mobile node's RCoA (similar to a home address) to its LCoA. The MAP (acting as an HA) will then return a binding acknowledgement to the MN. This acknowledgement either identifies the binding as successful or contains the appropriate fault code. No new error codes need to be supported by the mobile node for this operation. The mobile node MUST silently ignore binding acknowledgements that do not contain a routing header type 2, which includes the mobile node's RCoA.

MAPのリンク上のRCoAとオンリンクのCoA(のLCoA):モバイルノードが新しいMAPドメイン(すなわち、そのMAPの変更)に移動すると、それは2つのCoAを設定する必要があります。 RCoAを取得する[RFC4877]を使用した後、モバイルノードは、セットAとMフラグをMAPにローカルBUを送信します。ローカルBUは、[RFC3775]で定義されたBUで、ホームアドレスオプションでモバイルノードのRCoAをを含んでいます。いいえ代替-CoAのオプションは、このメッセージには必要ありません。 LCoAのは、BUの送信元アドレスとして使用されています。このBUは、そののLCoAにモバイルノードのRCoAを(ホームアドレスに類似)をバインドします。 MAP(HAとして動作)をMNへの結合確認を返されます。この承認は、結合のような成功を識別したり、適切な故障コードが含まれていますどちらか。新しいエラーコードは、この操作のためのモバイルノードによってサポートされる必要がありません。モバイルノードは静かに移動ノードのRCoAをを含むルーティングヘッダタイプ2を含まない結合肯定応答を無視しなければなりません。

Following a successful registration with the MAP, a bi-directional tunnel between the mobile node and the MAP is established. All packets sent by the mobile node are tunnelled to the MAP. The outer header contains the mobile node's LCoA in the source address field, and the MAP's address in the destination address field. The inner header contains the mobile node's RCoA in the source address field, and the peer's address in the destination address field. Similarly, all packets addressed to the mobile node's RCoA are intercepted by the MAP and tunnelled to the mobile node's LCoA.

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 MAY perform the binding update procedure for each RCoA. In addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a MAP's prefix (e.g., MAP1) as a care-of address in its binding update to another MAP (e.g., MAP2). This would force packets to be encapsulated several times (twice in this example) on their path to the mobile node. This form of multi-level hierarchy will reduce the protocol's efficiency and performance.


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.


The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering the RCoA with other nodes (e.g., CN or HA, if available). It should be noted that when binding the RCoA with the HA and correspondent nodes, the binding lifetime MUST NOT be larger than the mobile node's binding lifetime with the MAP, which is received in the binding acknowledgement.

モバイルノードは、他のノード(例えば、CN又はHA、利用可能な場合)とのRCoAを登録する前に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.


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.


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.


Note that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes. If these nodes are connected to the same link, packets will then be routed directly, without going through the MAP.


6.1.1. Sending Packets to Correspondent Nodes
6.1.1. 対応ノードにパケットを送信します

The mobile node can communicate with a correspondent node through the HA, or in a route-optimised manner, as described in [RFC3775]. When communicating through the HA, the message formats in [RFC3775] are used.

[RFC3775]に記載されているように、モバイルノードは、HAを介して、または経路最適化方法で通信相手ノードと通信することができます。 HAを介して通信する場合、[RFC3775]のメッセージフォーマットが使用されています。

If the mobile node communicates directly with the correspondent node (i.e., the CN has a binding cache entry for the mobile node), the mobile node MUST use the same care-of address used to create a binding cache entry in the correspondent node (RCoA) as a source address. According to [RFC3775], the mobile node MUST also include a Home Address option in outgoing packets. The Home Address option MUST contain the mobile node's home address.

モバイルノードは、コレスポンデントノードと直接通信する場合、同じ気付けコレスポンデント・ノードにおけるバインディングキャッシュエントリを作成するために使用されるアドレス(RCoAをし、モバイルノードが使用しなければならない(すなわち、CNは、モバイルノードの結合キャッシュエントリがあります) )送信元アドレスとして。 [RFC3775]によれば、移動ノードは、発信パケットでホームアドレスオプションを含まなければなりません。ホームアドレスオプションは、モバイルノードのホームアドレスを含まなければなりません。

6.2. MAP Operations
6.2. MAPオペレーション

The MAP acts like an HA; it intercepts all packets addressed to registered mobile nodes and tunnels them to the corresponding LCoA, which is stored in its binding cache.


A MAP has no knowledge of the mobile node's home address. The mobile node will send a local BU to the MAP with the M and A flags set. The aim of this BU is to bind the RCoA (contained in the BU as a home address) to the mobile node's LCoA. If successful, the MAP MUST return a binding acknowledgement to the mobile node, indicating a successful registration. This is identical to the HA operation in [RFC3775]. No new error codes are introduced for HMIPv6. The binding acknowledgement MUST include a routing header type 2 that contains the mobile node's RCoA.


The MAP MUST be able to accept packets tunnelled from the mobile node, with the mobile node being the tunnel entry point and the MAP being the tunnel exit point.


The MAP employs [RFC4877] Section 9 procedures for the allocation of RCoA, and subsequently acts as an HA for the RCoA. Packets addressed to the RCoA are intercepted by the MAP, using proxy Neighbour Advertisement, and then encapsulated and routed to the mobile node's LCoA. This operation is identical to that of the HA described in [RFC3775].


A MAP MAY be configured with the list of valid on-link prefixes that mobile nodes can use to derive LCoAs. This is useful for network operators that need to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile


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).


6.3. Home Agent Operations
6.3. ホームエージェントの操作

The support of HMIPv6 is completely transparent to the HA's operation. Packets addressed to a mobile node's home address will be forwarded by the HA to its RCoA, as described in [RFC3775].


6.4. Correspondent Node Operations
6.4. 通信相手ノードの操作

HMIPv6 is completely transparent to correspondent nodes.


6.5. Local Mobility Management Optimisation within a MAP Domain
6.5. MAPドメイン内のローカルモビリティ管理の最適化

In [RFC3775], it is stated that for short-term communication, particularly communication that may easily be retried upon failure, the mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, thus not requiring the use of a Home Address option in the packet. Such use of the CoA will reduce the overhead of sending each packet due to the absence of additional options. In addition, it will provide an optimal route between the mobile node and correspondent node.

[RFC3775]には、容易に故障時に再試行することができる短期の通信、特に通信のために、モバイルノードは、このように必要としない、直接パケットのソースとしての気付アドレスのいずれかを使用することを選択するかもしれないことに記載されていますパケット内のホームアドレスオプションを使用します。 CoAをこのような使用は、追加オプションが存在しないために、各パケットを送信するのオーバーヘッドを削減します。また、モバイルノードとコレスポンデントノードとの間の最適経路を提供します。

HMIPv6-aware mobile nodes can use their RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a source address for upper layers. Using this feature, the mobile node will be seen by the correspondent node as a fixed node while moving within a MAP domain.

HMIPv6の認識モバイルノードはホームアドレスオプションを使用せずに、送信元アドレスとして自分のRCoAを使用することができます。換言すれば、RCoAを、上位層の送信元アドレスとして使用することができます。 MAPドメイン内で移動させながら、この機能を使用して、モバイルノードは、固定ノードとコレスポンデントノードによって分かるであろう。

This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., no bindings or Home Address options are sent over the Internet), but still provides local mobility management to the mobile nodes with near-optimal routing. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile node changes its RCoA), it would be useful for several applications (e.g., web browsing). The validity of the RCoA as a source address used by applications will depend on the size of a MAP domain and the speed of the mobile node. Furthermore, because the support for BU processing in correspondent nodes is not mandated in [RFC3775], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.

RCoAのこの用法は、モバイルIPv6のコスト(すなわち、何のバインディングやホームアドレスオプションがインターネット経由で送信されていない)を持っているが、それでもほぼ最適なルーティングをモバイルノードにローカルモビリティ管理を提供しません。 RCoAをそのような使用は、グローバルモビリティを提供しないが、それはいくつかのアプリケーション(例えば、ウェブブラウジング)のために有用であろう(すなわち、通信は、モバイルノードがそのRCoAをを変更したとき破壊されます)。アプリケーションによって使用される送信元アドレスとしてのRCoAの有効性は、MAPドメインのサイズおよび移動ノードの速度に依存するであろう。コレスポンデントノードにBU処理のためのサポートは[RFC3775]で義務付けられていないので、さらに、この機構は、コレスポンデントノードへのバスを送信せずに経路最適化を得る方法を提供することができます。

Enabling this mechanism can be done by presenting the RCoA as a temporary home address for the mobile node. This may require an implementation to augment its source address selection algorithm with the knowledge of the RCoA in order to use it for the appropriate applications.


6.6. Location Privacy
6.6. 所在地プライバシー

In HMIPv6, a mobile node hides its LCoA from its correspondent nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, address-based location tracking of a mobile node by its correspondent nodes or its home agent is more difficult because they only know its RCoA and not its LCoA.


7. MAP Discovery
7. MAP発見

This section describes how a mobile node obtains the MAP address and subnet prefix, and how ARs in a domain discover MAPs.


This specification requires network administrators to manually configure the MAP option information in ARs; future mechanisms may be defined to allow MAPs to be discovered dynamically.


7.1. Mobile Node Operation
7.1. モバイルノードの操作

When an HMIPv6-aware mobile node receives a Router Advertisement, it should search for the MAP option. One or more options may be found for different MAP IP addresses. A mobile node SHOULD register with the MAP having the highest preference value. A MAP with a preference value of zero SHOULD NOT be used for new local BUs (i.e., the mobile node can refresh existing bindings but cannot create new ones). However, a mobile node MAY choose to register with one MAP over another, depending on the value received in the distance field, provided that the preference value is above zero.

HMIPv6の認識モバイルノードはルータ通知を受信すると、MAPオプションを検索する必要があります。 1つまたは複数のオプションが異なるMAPのIPアドレスのために見つけることができます。モバイルノードは、最も高い優先値を有する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 NOT attempt to use HMIPv6.


If a multi-homed mobile node has access to several ARs simultaneously (on different interfaces), it SHOULD use an LCoA on the link defined by the AR that advertises its current MAP.


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.


If the R flag is set, the mobile node MUST place its RCoA in place of the home address in the binding update message. This causes the RCoA to be bound to the LCoA in the MAP's binding cache.


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.


8. Updating Previous MAPs

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.


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.


9. Note on MAP Selection by the Mobile Node

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.


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:


o "Eager" to perform new bindings.


o "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.


9.1. MAP Selection in Distributed MAP Environment
9.1. 分散MAP環境でのMAPの選択

The mobile node needs to consider several factors to optimally select one or more MAPs, where several MAPs are available in the same domain.


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.


In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need sophisticated algorithms to be able to select the appropriate MAP. These algorithms would have the mobile node speed as an input (for distance-based selection) combined with the preference field in the MAP option. However, this specification proposes that the mobile node use the following algorithm as a default, where other optimised algorithms are not available. The following algorithm is simply based on selecting the MAP that is most distant, provided that its preference value did not reach a value of zero. The mobile node operation is shown below:


1. Receive and parse all MAP options.

2. Arrange MAPs in a descending order, starting with the furthest 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.


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.


9.2. MAP Selection in a Flat Mobility Architecture
9.2. フラットモビリティアーキテクチャにおけるMAP選択

Network operators may choose a flat architecture in some cases where a Mobile IPv6 handover may be considered a rare event. In these scenarios, operators may choose to include the MAP function in ARs only. The inclusion of the MAP function in ARs can still be useful to reduce the time required to update all correspondent nodes and the HA. In this scenario, a mobile node may choose a MAP (in the AR) as an anchor point when performing a handoff. This kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR movement is not frequent.


10. Detection and Recovery from MAP Failures

This specification introduces a MAP that can be seen as a local home agent in a visited network. A MAP, like a home agent, is a single point of failure. If a MAP fails, its binding cache content will be lost, resulting in loss of communication between mobile and correspondent nodes. This situation may be avoided by using more than one MAP on the same link and by utilising a form of context transfer protocol between them. However, MAP redundancy is outside the scope of this document.

この仕様は、訪問先ネットワーク内のローカルホームエージェントとして見ることができるMAPを紹介します。 MAPは、ホームエージェントのように、単一障害点です。 MAPが失敗した場合、その結合キャッシュの内容は、モバイルと通信員ノード間の通信が失われ、失われます。この状況は、同じリンク上に複数のMAPを使用することによって、それらの間のコンテキスト転送プロトコルの形式を利用することによって回避することができます。しかし、MAPの冗長性は、この文書の範囲外です。

In cases where such protocols are not supported, the mobile node would need to detect MAP failures. The mobile node can detect this situation when it receives a Router Advertisement containing a MAP option with a lifetime of zero. The mobile node should then start the MAP Discovery process and attempt to register with another MAP. After it has selected and registered with another MAP, it will also need to inform correspondent nodes and the home agent if its RCoA has changed. Note that in the presence of a protocol that transfers binding cache entries between MAPs for redundancy purposes, a new MAP may be able to provide the same RCoA to the mobile node (e.g., if both MAPs advertise the same prefix in the MAP option). This would save the mobile node from updating correspondent nodes and the home agent.


Access Routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:


o By manual intervention.


o In a dynamic manner.


One way of performing dynamic detection of MAP failure can be done by probing the MAP regularly (e.g., every 10 seconds). If no response is received, an AR MAY try to aggressively probe the MAP for a short period of time (e.g., once every 5 seconds for 15 seconds); if no reply is received, a MAP option may be sent with a valid lifetime value of zero. The exact mechanisms for probing MAPs is outside the scope of this document. The above text simply shows one example of detecting failures.

MAP障害の動的検出を行う一つの方法は、定期的に(例えば、10秒毎)MAPを探索することによって行うことができます。応答がない場合は、ARは、積極的に(例えば、一回15秒ごとに5秒)の時間の短い期間のためのMAPを調査しようとするかもしれません。返事が受信されない場合は、MAPオプションがゼロの有効な寿命値を用いて送信することができます。 MAPのプローブの正確なメカニズムはこの文書の範囲外です。上記テキストは、単に故障を検出する一例を示しています。

This specification does not mandate a particular recovery mechanism. However, any mechanism between the MAP and an AR SHOULD be secure to allow for message authentication, integrity protection, and protection against replay attacks.


Note that the above suggestion for detecting MAP failure may not detect MAP failures that might take place between probes, i.e.,if a MAP reboots between probes.


11. Tunelling Impacts on MTU
MTU 11. Tunellingの影響

This specification requires the mobile node to tunnel outgoing traffic to the MAP. Similarly, the MAP tunnels inbound packets to the mobile node. If the mobile node has a home agent elsewhere on the Internet, this will result in double encapsulations of inbound and outbound packets. This may have impacts on the mobile node's path MTU. Hence, mobile nodes MUST consider the encapsulation of traffic between the node and the MAP when calculating the available MTU for upper layers.


12. Security Considerations

This specification introduces a new concept to Mobile IPv6, namely, a Mobility Anchor Point that acts as a local home agent. It is crucial that the security relationship between the mobile node and the MAP is strong; it MUST involve mutual authentication, integrity protection, and protection against replay attacks. Confidentiality may be needed for payload traffic, such as when the mobile node is unwilling to reveal any traffic to the access network beyond what is needed for the mobile node to attach to the network and communicate with a MAP. Confidentiality is not required for binding updates to the MAP. The absence of any of these protections may lead to malicious mobile nodes impersonating other legitimate ones or impersonating a MAP. Any of these attacks will undoubtedly cause undesirable impacts to the mobile node's communication with all correspondent nodes having knowledge of the mobile node's RCoA.


Three different relationships (related to securing binding updates) need to be considered:


1. The mobile node - MAP
1.モバイルノード - MAP
2. The mobile node - correspondent node
2.モバイルノードを - コレスポンデントノード
3. The mobile node - home agent
3.モバイルノードを - ホームエージェント
12.1. Mobile Node - MAP Security
12.1. モバイルノード - MAPのセキュリティ

In order to allow a mobile node to use the MAP's forwarding service, initial authorisation (specifically for the service, not for the RCoA) MAY be needed. Authorising a mobile node to use the MAP service can be done based on the identity of the mobile node exchanged during the security association (SA) negotiation process. The authorisation may be granted based on the mobile node's identity or based on the identity of a Certificate Authority (CA) that the MAP trusts. For instance, if the mobile node presents a certificate signed by a trusted entity (e.g., a CA that belongs to the same administrative domain, or another trusted roaming partner), it would be sufficient for the MAP to authorise the use of its service. Note that this level of authorisation is independent of authorising the use of a particular RCoA. Similarly, the mobile node trusts the MAP if it presents a certificate signed by the same CA or by another CA that the mobile node is configured to trust (e.g., a roaming partner). It is likely that some deployments would be satisfied with the use of self-signed certificates for either the mobile node or the MAP or both. This guarantees that the mobile node and the MAP are authenticated for address allocation and future binding updates without the need for identity authentication. Hence, the use of trusted third-party certificates is not required by this specification.

MAPの転送サービスを利用するには、モバイルノードを可能にするためには、(特にサービスのための、ないのRCoAのための)最初の承認が必要になることがあります。 MAPサービスを使用するために、モバイルノードを許可することは、セキュリティアソシエーション(SA)のネゴシエーションプロセス中に交換、移動ノードの識別情報に基づいて行うことができます。許可は、移動ノードの識別情報に基づいてか、MAPが信頼する認証局(CA)のアイデンティティに基づいて付与することができます。モバイルノードは、信頼できるエンティティによって署名された証明書を提示した場合、MAPはそのサービスの利用を許可するために例えば、(例えば、同じ管理ドメイン、または別の信頼できるローミングパートナーに属しCA)は、それが十分であろう。承認のこのレベルは、特定のRCoAの使用を許可する独立していることに注意してください。それはモバイルノードが(例えば、ローミングパートナー)を信頼するように構成されているのと同じCAまたは別のCAによって署名された証明書を提示する場合も同様に、移動ノードがMAPを信頼します。いくつかの展開は、モバイルノードまたはMAPのいずれか、または両方のための自己署名証明書を使用して満足するだろうと思われます。これは、モバイルノードとMAPは、ID認証を必要とせずにアドレス割り当ておよび将来の結合更新のために認証されることを保証します。したがって、信頼できるサードパーティの証明書の使用は、本明細書で必要とされていません。

It is important to note that in this specification, authentication and authorisation are effectively the same thing. All the MAP needs in order to allocate the mobile node an RCoA is to authenticate the mobile node and verify that it belongs to a trusted group (based on its certificate).


IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows the use of Extensible Authentication Protocol (EAP) as a mechanism to bootstrap the security association between the communicating peers.

IKEv2のは、モバイルノードとMAPによってサポートされなければなりません。 IKEv2は、通信ピア間でセキュリティアソシエーションをブートストラップするための機構として拡張認証プロトコル(EAP)の使用を可能にします。

Hence, EAP can be used with IKEv2 to leverage the Authentication, Authorization, and Accounting (AAA) infrastructure to bootstrap the SA between the mobile node and the MAP. Such a mechanism is useful in scenarios where an administrator wishes to avoid the configuration and management of certificates on mobile nodes. A MAP MAY support the use of EAP over IKEv2.

したがって、EAPは、モバイルノードとMAPとの間にSAをブートストラップするために認証、許可、アカウンティング(AAA)インフラストラクチャを活用するのIKEv2と共に使用することができます。そのようなメカニズムは、管理者がモバイルノード上の証明書の設定と管理を回避することを望むシナリオで有用です。 MAPはIKEv2の上のEAPの使用をサポートするかもしれません。

If EAP is used with IKEv2, the EAP method runs between the mobile node and a AAA server. Following a successful authentication, the resulting keying material can be used to bootstrap IKEv2 between the MAP and the mobile node. The specification of which EAP methods should be used or how keys are transported between the MAP and the AAA server is outside the scope of this document.

EAPは、IKEv2のと共に使用される場合、EAP方法は、移動ノードとAAAサーバの間で実行されます。認証成功後、得られた鍵材料は、MAPと移動ノードとの間のIKEv2をブートストラップするために使用することができます。 EAPメソッドが使用されるべきか、キーがMAPとAAAサーバとの間で輸送される方法の仕様は、この文書の範囲外です。

HMIPv6 uses an additional registration between the mobile node and its current MAP. As explained in this document, when a mobile node moves into a new domain (i.e., served by a new MAP), it obtains an RCoA and an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies the BU and creates a binding cache entry with the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to send a new BU that specifies the binding between its RCoA and its new LCoA. This BU needs to be authenticated; otherwise, any host could send a BU for the mobile node's RCoA and hijack the mobile node's packets.

HMIPv6のは、モバイルノードとその現在のMAP間の追加登録を使用します。本書で説明したように、モバイルノードは、新しいドメインに移動したとき、(すなわち、新たなMAPによってサービス)、それのRCoAとのLCoAを取得し、新たなMAPと、これら二つのアドレス間のバインディング登録します。 MAPは、BUを検証したRCoAとLCoAのとバインディングキャッシュエントリを作成します。モバイルノードが新しいのLCoAを取得するたびに、そのRCoAをし、その新しいのLCoA間の結合を指定する新しいBUを送信する必要があります。このBUは、認証する必要があります。そうでない場合は、任意のホストは、モバイルノードのRCoAをのためのBUを送信して、モバイルノードのパケットを乗っ取ることができます。

The MAP does not need to have prior knowledge of the identity of the mobile node or its home address. As a result, the SA between the mobile node and the MAP can be established using any key establishment protocols such as IKEv2. A return routability test is not necessary.


The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKEv2 [RFC4306]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA.

MAPは、RCoAを(ないのLCoA)のためにSAを設定する必要があります。これは、のIKEv2 [RFC4306]を用いて行うことができます。モバイルノードは、送信元アドレスとしてそののLCoAを使用して、しかしのRCoAがSAで使用されるべきであることを指定します。

This is achieved by using the RCoA as the identity in the IKE CHILD_SA negotiation. This step is identical to the use of the home address in IKE CHILD_SA when negotiating with the home agent.

これは、IKE CHILD_SA交渉におけるアイデンティティとしてのRCoAを使用することによって達成されます。ホームエージェントと交渉する場合、このステップでは、IKE CHILD_SAでホームアドレスを使用することと同じです。

The IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] for allocating dynamic home addresses SHOULD be used by the MAP to allocate the RCoA for mobile nodes. Binding updates between the MAP and the mobile node MUST be protected with either Authentication Header (AH) or Encapsulating Security Payload (ESP) in transport mode. When ESP is used, a non-null authentication algorithm MUST be used.

動的ホームアドレスを割り当てるための[RFC4877]に記載のIPsecピア認証データベース(PAD)エントリと設定ペイロードは、モバイルノードのためのRCoAを割り当てるMAPによって使用されるべきです。 MAPと移動ノードとの間のバインディングアップデートは、トランスポートモードでは、認証ヘッダ(AH)またはカプセル化セキュリティペイロード(ESP)のいずれかで保護されなければなりません。 ESPを使用する場合は、null以外の認証アルゴリズムを使用しなければなりません。

The Security Policy Database (SPD) entries in both the home agent and the mobile node are identical to those set up for the home agent and mobile node, respectively, as outlined in [RFC4877].


12.2. Mobile Node - Correspondent Node Security
12.2. モバイルノード - 通信員ノードセキュリティ

Mobile IPv6 [RFC3775] defines a return routability procedure that allows mobile and correspondent nodes to authenticate binding updates and acknowledgements. This specification does not impact the return routability test defined in [RFC3775]. However, it is important to note that mobile node implementers need to be careful when selecting the source address of the HoTI and CoTI messages, defined in [RFC3775]. The source address used in HoTI messages SHOULD be the mobile node's home address unless the mobile node wishes to use the RCoA for route optimisation. The packet containing the HoTI message is encapsulated twice. The inner encapsulating header contains the RCoA in the source address field and the home agent's address in the destination address field. The outer encapsulating header contains the mobile node's LCoA in the source address field and the MAP's address in the destination field.

モバイルIPv6 [RFC3775]はモバイルと対応ノードがバインディング更新及び確認を認証することを可能にするリターン・ルータビリティ手順を定義します。この仕様は、[RFC3775]で定義されたリターン・ルータビリティ・テストに影響を与えません。しかし、モバイルノードの実装は、[RFC3775]で定義されたHoTIおよびCoTIのメッセージの送信元アドレスを選択する際に注意する必要があることに注意することが重要です。モバイルノードは、ルート最適化のためのRCoAを使用したい場合を除きたHoTIメッセージで使用される送信元アドレスは、モバイルノードのホームアドレスでなければなりません。 HoTIメッセージを含むパケットが二度カプセル化されています。内側のカプセル化ヘッダは、送信元アドレスフィールドと宛先アドレスフィールドにホームエージェントのアドレスでのRCoAが含まれています。外側のカプセル化ヘッダは、ソースアドレスフィールド内のモバイルノードののLCoA及び宛先フィールドのMAPのアドレスを含んでいます。

12.3. Mobile Node - Home Agent Security
12.3. モバイルノード - ホームエージェントセキュリティ

The security relationship between the mobile node and its home agent, as discussed in [RFC3775], is not impacted by this specification.


The relationship between the MAP and the mobile node is not impacted by the presence of a home agent.


13. IANA Considerations
13. IANAの考慮事項

Both the MAP option and M flag were allocated for RFC 4140 and will continue to be used by this specification.

MAPオプションとMフラグの両方が、RFC 4140のために割り当てられた、本明細書で使用され続けます。

14. Acknowledgements

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, Gopal Dommety (Cisco), Francis Dupont (GET/Enst Bretagne), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti

また、著者は、アルファベット順に、ワーキンググループのメンバーは以下のとおりに感謝したいと思います:Samita Chakrabarti(日)、グレゴリー・デイリー、GopalのDommety(シスコ)、フランシス・デュポン(/ EnstブルターニュをGET)、エヴァGustaffson(エリクソン) 、デーブ・ジョンソン(ライス大学)、アニカ・ヨンソン(エリクソン)、ジェームズ・ケンプ(ドコモラボ)、マルッティ

Kuparinen (Ericsson), Fergal Ladley, Gabriel Montenegro (Microsoft), Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt, and Alper Yegin (Samsung) for their comments on the document.

Kuparinenが(エリクソン)、Fergal Ladley、ガブリエル・モンテネグロ(マイクロソフト)、ニック "シャーキー" ムーア、Vidyaナラヤナン(クアルコム)、エリックNordmarkと(日)、Basavarajパティル(ノキア)、ブレット・ペントランド(NEC)、トーマス・シュミット、及びアルパースYegin文書上の彼らのコメントについて(サムスン)。

15. References
15.1. Normative References
15.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。

[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ(IKEv2の)プロトコル"、RFC 4306、2005年12月。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6(IPv6)のための近隣探索"、RFC 4861、2007年9月。

[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.

[RFC4877] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。

15.2. Informative References
15.2. 参考文献

[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.

[RFC4449]パーキンス、C.、RFC 4449、2006年6月 "静的共有キーを使用してセキュアなモバイルIPv6ルート最適化"。

[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.

[RFC4651]フォークト、C.とJ. Arkko、RFC 4651 "モバイルIPv6経路最適化の機能強化の分類と分析"、2007年2月。

[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.

[RFC4866] Arkko、J.、フォークト、C.、およびW.ハダッド、 "モバイルIPv6のためのルート最適化の強化"、RFC 4866、2007年5月。

Appendix A. Changes from


o Dynamic MAP Discovery was removed.


o Updated the security section to use IKEv2 instead of IKEv1.


o The document clarified that HMIPv6 can be used without the need for a home agent.


o Several editorials throughout the document.


o IKEv2 only is now used to allocate the RCoA.

O IKEv2のは今だけのRCoAを割り当てるために使用されます。

RFC 4140 was implemented and interop tested by at least two different organisations. A test suite including test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP Discovery, defined in RFC 4140, was seen as inappropriate for large-scale deployments and prone to loops. It was removed from this specification.

RFC 4140が実装され、相互運用機能は、少なくとも2つの異なる組織によってテストされています。 RFC 4140のためのテストケースを含むテストスイートはまたエリクソンによって開発され、両方の実装に対して実行しました。重大な問題は見つかりませんでした。 RFC 4140で定義された動的MAPディスカバリのスケーラビリティは、大規模な展開のために不適切とループしやすいと見られました。これは、この仕様書から削除されました。

At this time, there is no publicly known deployment of this specification.


Authors' Addresses


Hesham Soliman Elevate Technologies




Claude Castelluccia INRIA


Phone: +33 4 76 61 52 15 EMail:

電話:+33 4 76 61 52 15 Eメール

Karim ElMalki Athonet




Ludovic Bellier INRIA

ルドビクBellier INRIA



Full Copyright Statement


Copyright (C) The IETF Trust (2008).


This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。