[要約] RFC 3963は、ネットワークモビリティ（NEMO）の基本サポートプロトコルに関する仕様です。このRFCの目的は、モバイルノードがネットワーク内で移動する際に、通信の継続性を確保するためのプロトコルを提供することです。
Network Working Group V. Devarapalli
Request for Comments: 3963 Nokia
Category: Standards Track R. Wakikawa
Keio University
A. Petrescu
Motorola
P. Thubert
Cisco Systems
January 2005
Network Mobility (NEMO) Basic Support Protocol
ネットワーク モビリティ (NEMO) 基本サポート プロトコル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
Abstract
概要
This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network.
この文書では、モバイル ネットワークをインターネット上のさまざまなポイントに接続できるようにする Network Mobility (NEMO) Basic Support プロトコルについて説明します。このプロトコルはモバイル IPv6 の拡張であり、ネットワークの移動に応じてモバイル ネットワーク内のすべてのノードでセッションの継続を可能にします。また、移動中にモバイル ネットワーク内のすべてのノードに到達できるようになります。ネットワークをインターネットに接続するモバイル ルーターは、ホーム エージェントを使用して NEMO Basic Support プロトコルを実行します。このプロトコルは、ネットワーク モビリティがモバイル ネットワーク内のノードに対して透過的になるように設計されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the NEMO Protocol. . . . . . . . . . . . . . . . 4
4. Message Formats. . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Binding Update. . . . . . . . . . . . . . . . . . . . . 7
4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . 7
4.3. Mobile Network Prefix Option. . . . . . . . . . . . . . 8
5. Mobile Router Operation. . . . . . . . . . . . . . . . . . . 9
5.1. Data Structures . . . . . . . . . . . . . . . . . . . . 10
5.2. Sending Binding Updates . . . . . . . . . . . . . . . . 10
5.3. Receiving Binding Acknowledgements. . . . . . . . . . . 11
5.4. Error Processing . . . . . . . . . . . . . . . . . . . 12
5.4.1. Implicit Mode. . . . . . . . . . . . . . . . . . 12
5.4.2. Explicit Mode. . . . . . . . . . . . . . . . . . 12
5.5. Establishment of Bi-directional Tunnel . . . . . . . . 13
5.6. Neighbor Discovery for Mobile Router . . . . . . . . . 13
5.7. Multicast Groups for Mobile Router . . . . . . . . . . 14
5.8. Returning Home . . . . . . . . . . . . . . . . . . . . 14
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 15
6.1. Data Structures . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Binding Cache. . . . . . . . . . . . . . . . . . 15
6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 15
6.2. Mobile Network Prefix Registration . . . . . . . . . . 16
6.3. Advertising Mobile Network Reachability . . . . . . . . 17
6.4. Establishment of Bi-directional Tunnel . . . . . . . . 18
6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . 18
6.6. Sending Binding Acknowledgements . . . . . . . . . . . 19
6.7. Mobile Network Prefix De-Registration . . . . . . . . . 19
7. Modifications to Dynamic Home Agent Address Discovery. . . . 20
7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20
7.2. Modified Dynamic Home Agent Discovery Address Request . 20
7.3. Modified Home Agent Information Option . . . . . . . . 21
8. Support for Dynamic Routing Protocols. . . . . . . . . . . . 22
9. Security Considerations. . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A. Examples of NEMO Basic Support Operation. . . . . . . . . 27
B. Running Link State Routing Protocol with NEMO Basic
Support . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Tunnel Interface Considerations. . . . . . . . . . . 30
B.2. OSPF Area Considerations . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 33
This document describes protocol extensions to Mobile IPv6 (MIPv6) [1] to enable support for network mobility. The extensions are backward compatible with Mobile IPv6. In particular, a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent. The solution described here satisfies the goals and requirements identified in [11] for network mobility.
この文書では、ネットワーク モビリティのサポートを可能にするモバイル IPv6 (MIPv6) [1] のプロトコル拡張について説明します。拡張機能にはモバイル IPv6 との下位互換性があります。特に、NEMO 準拠のホーム エージェントは、モバイル IPv6 ホーム エージェントとして動作できます。ここで説明するソリューションは、[11] で特定されたネットワーク モビリティの目標と要件を満たします。
The NEMO Basic Support ensures session continuity for all the nodes in the Mobile Network, even as the Mobile Router changes its point of attachment to the Internet. It also provides connectivity and reachability for all nodes in the Mobile Network as it moves. The solution supports both mobile nodes and hosts that do not support mobility in the Mobile Network.
NEMO 基本サポートは、モバイル ルーターがインターネットへの接続点を変更した場合でも、モバイル ネットワーク内のすべてのノードのセッションの継続性を保証します。また、移動中のモバイル ネットワーク内のすべてのノードへの接続と到達可能性も提供します。このソリューションは、モバイル ネットワーク内のモビリティをサポートしないモバイル ノードとホストの両方をサポートします。
Within the context of this document, the definition of a Mobile Router extends that of a Mobile IPv6 [1] Mobile Node, by adding routing capability routing between its point of attachment (Care-of Address) and a subnet that moves with the Mobile Router.
この文書のコンテキスト内では、モバイル ルータの定義は、接続点 (気付アドレス) とモバイル ルータとともに移動するサブネットの間のルーティング機能を追加することにより、モバイル IPv6 [1] モバイル ノードの定義を拡張します。。
The solution described in this document proposes a bi-directional tunnel between the Mobile Router and its Home Agent. This tunnel is set up when the Mobile Router sends a successful Binding Update to its Home Agent, informing the Home Agent of its current point of attachment.
このドキュメントで説明するソリューションでは、モバイル ルーターとそのホーム エージェント間の双方向トンネルを提案します。このトンネルは、モバイル ルータがバインディング アップデートをホーム エージェントに正常に送信し、現在の接続ポイントをホーム エージェントに通知するときにセットアップされます。
All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not describe route optimization of this traffic.
モバイル ネットワーク内のノードと通信先ノード間のすべてのトラフィックは、ホーム エージェントを通過します。このドキュメントでは、このトラフィックのルート最適化については説明しません。
The terminology document [10] describes Nested Mobility as a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. But note that this might introduce significant overhead on the data packets as each level of nesting introduces another IPv6 header encapsulation.
用語文書 [10] では、ネストされたモビリティを、モバイル ルータが別のモバイル ルータをそのモバイル ネットワークに接続できるようにするシナリオとして説明しています。任意のレベルのネストされたモビリティが存在する可能性があります。各モバイル ルータの動作は、モバイル ルータが別のモバイル ルータに接続されていても、インターネット上の固定アクセス ルータに接続されていても同じです。ここで説明するソリューションでは、ネストされたモビリティのレベル数に制限はありません。ただし、ネストの各レベルで別の IPv6 ヘッダーのカプセル化が導入されるため、これによりデータ パケットに重大なオーバーヘッドが発生する可能性があることに注意してください。
This document does not discuss multihoming for Mobile Routers.
このドキュメントでは、モバイル ルーターのマルチホーミングについては説明しません。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [7].
この文書内のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [7] に記載されているように解釈されます。
Network Mobility - related terminology is defined in [9] and [10]. This document in addition defines the following terms.
ネットワーク モビリティ関連の用語は、[9] および [10] で定義されています。この文書ではさらに、次の用語を定義します。
Mobile Network Prefix
モバイルネットワークプレフィックス
An IPv6 prefix delegated to a Mobile Router and advertised in the Mobile Network. More than one Mobile Network Prefix could be advertised in a Mobile Network.
モバイル ルーターに委任され、モバイル ネットワークでアドバタイズされる IPv6 プレフィックス。モバイル ネットワークでは、複数のモバイル ネットワーク プレフィックスをアドバタイズできます。
Prefix Table
プレフィックステーブル
A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router.
モバイル ルーターのホーム アドレスによってインデックス付けされたモバイル ネットワーク プレフィックスのリスト。ホーム エージェントは、プレフィックス テーブルを管理および使用して、どのモバイル ネットワーク プレフィックスが特定のモバイル ルータに属するかを決定します。
A Mobile Network is a network segment or subnet that can move and attach to arbitrary points in the routing infrastructure. A Mobile Network can only be accessed via specific gateways called Mobile Routers that manage its movement. Mobile Networks have at least one Mobile Router serving them. A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network). Instead, it maintains a bi-directional tunnel to a Home Agent that advertises an aggregation of Mobile Networks to the infrastructure. The Mobile Router is also the default gateway for the Mobile Network.
モバイル ネットワークは、ルーティング インフラストラクチャ内の任意のポイントに移動して接続できるネットワーク セグメントまたはサブネットです。モバイル ネットワークには、その移動を管理するモバイル ルーターと呼ばれる特定のゲートウェイを介してのみアクセスできます。モバイル ネットワークには、サービスを提供する少なくとも 1 つのモバイル ルーターがあります。モバイル ルーターは、接続点 (つまり、訪問先ネットワーク) でインフラストラクチャにモバイル ネットワーク ルートを配布しません。代わりに、モバイル ネットワークの集合体をインフラストラクチャにアドバタイズするホーム エージェントへの双方向トンネルを維持します。モバイル ルーターは、モバイル ネットワークのデフォルト ゲートウェイでもあります。
A Mobile Network can also comprise of multiple and nested subnets. A router without mobility support may be permanently attached to a Mobile Network for local distribution. Also, Mobile Routers may be attached to Mobile Networks owned by different Mobile Routers and may form a graph. In particular, with Basic NEMO Support, each Mobile Router is attached to another Mobile Network by a single interface. If loops are avoided, the graph is a tree.
モバイル ネットワークは、複数のネストされたサブネットで構成することもできます。モビリティ サポートのないルータは、ローカル配布のためにモバイル ネットワークに永続的に接続される場合があります。また、モバイル ルーターは、異なるモバイル ルーターが所有するモバイル ネットワークに接続され、グラフを形成する場合があります。特に、基本 NEMO サポートでは、各モバイル ルーターは単一のインターフェイスによって別のモバイル ネットワークに接続されます。ループが回避されると、グラフはツリーになります。
A Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be either the prefix advertised on the home link or the prefix delegated to the Mobile Router. The Mobile Router can have more than one Home Address if there are multiple prefixes in the home link. The Mobile Router also advertises one or more prefixes in the Mobile Network attached to it. The actual mechanism for assigning these prefixes to a given Mobile Router is outside the scope of this specification.
モバイル ルーターには固有のホーム アドレスがあり、ホーム エージェントに登録されると、このアドレスを介してアクセスできます。ホーム アドレスは、ホーム エージェントによって集約およびアドバタイズされたプレフィックスから構成されます。プレフィックスは、ホーム リンク上でアドバタイズされたプレフィックス、またはモバイル ルータに委任されたプレフィックスのいずれかになります。ホーム リンクに複数のプレフィックスがある場合、モバイル ルータは複数のホーム アドレスを持つことができます。モバイル ルーターは、接続されているモバイル ネットワーク内の 1 つ以上のプレフィックスもアドバタイズします。これらのプレフィックスを特定のモバイル ルーターに割り当てる実際のメカニズムは、この仕様の範囲外です。
When the Mobile Router moves away from the home link and attaches to a new access router, it acquires a Care-of Address from the visited link. The Mobile Router can at any time act either as a Mobile Host or as a Mobile Router. It acts as a Mobile Host as defined in [1] for sessions it originates and provides connectivity to the Mobile Network. As soon as the Mobile Router acquires a Care-of Address, it immediately sends a Binding Update to its Home Agent as described in [1]. When the Home Agent receives this Binding Update, it creates a cache entry binding the Mobile Router's Home Address to its Care-of Address at the current point of attachment.
モバイル ルータがホーム リンクから離れて新しいアクセス ルータに接続すると、訪問先リンクから気付アドレスを取得します。モバイル ルーターは、いつでもモバイル ホストまたはモバイル ルーターとして機能できます。これは、[1] で定義されているように、開始するセッションに対してモバイル ホストとして機能し、モバイル ネットワークへの接続を提供します。モバイル ルータは気付アドレスを取得するとすぐに、[1] で説明されているようにバインディング アップデートをホーム エージェントに送信します。ホーム エージェントがこのバインディング アップデートを受信すると、モバイル ルータのホーム アドレスを現在の接続ポイントの気付アドレスにバインドするキャッシュ エントリを作成します。
If the Mobile Router seeks to act as a Mobile Router and provide connectivity to nodes in the Mobile Network, it indicates this to the Home Agent by setting a flag (R) in the Binding Update. It MAY also include information about the Mobile Network Prefix in the Binding Update by using one of the modes described in section 5.2, so that the Home Agent can forward packets meant for nodes in the Mobile Network to the Mobile Router. A new Mobility Header Option for carrying prefix information is described in section 4.3. If the Mobile Network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all of these prefixes, it includes multiple prefix information options in a single Binding Update. The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address. In some scenarios the Home Agent would already know which prefixes belong to a Mobile Router by an alternate mechanism such as static configuration. In these scenarios, the Mobile Router does not include any prefix information in the Binding Update. The Home Agent sets up forwarding for all prefixes owned by the Mobile Router when it receives a Binding Update from the Mobile Router with the Mobile Router Flag (R) set.
モバイル ルーターがモバイル ルーターとして機能し、モバイル ネットワーク内のノードへの接続を提供しようとする場合、バインディング アップデートにフラグ (R) を設定することでホーム エージェントにそのことを示します。また、ホーム エージェントがモバイル ネットワーク内のノード宛てのパケットをモバイル ルータに転送できるように、セクション 5.2 で説明されているモードの 1 つを使用して、バインディング アップデートにモバイル ネットワーク プレフィックスに関する情報を含めてもよい (MAY)。プレフィックス情報を伝送するための新しいモビリティ ヘッダー オプションについては、セクション 4.3 で説明します。モバイル ネットワークに複数の IPv6 プレフィックスがあり、ホーム エージェントがこれらすべてのプレフィックスに対して転送をセットアップすることを希望する場合、単一のバインディング アップデートに複数のプレフィックス情報オプションが含まれます。ホーム エージェントは、これらのプレフィックスのそれぞれについて、モバイル ルータの気付アドレスへの転送を設定します。一部のシナリオでは、ホーム エージェントは、静的構成などの代替メカニズムによって、どのプレフィックスがモバイル ルータに属しているかをすでに知っています。これらのシナリオでは、モバイル ルーターはバインディング アップデートにプレフィックス情報を含めません。ホーム エージェントは、モバイル ルータからモバイル ルータ フラグ (R) が設定されたバインディング アップデートを受信すると、モバイル ルータが所有するすべてのプレフィックスに対して転送を設定します。
The Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement to the Mobile Router. A positive acknowledgement with the Mobile Router Flag (R) set means that the Home Agent has set up forwarding for the Mobile Network. Once the binding process finishes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are the Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation [3]. The Home Agent decapsulates this packet and forwards it to the Correspondent Node. For traffic originated by itself, the Mobile Router can use either reverse tunneling or route optimization, as specified in [1].
ホーム エージェントは、バインディング確認応答をモバイル ルータに送信することでバインディング アップデートを確認します。モバイル ルータ フラグ (R) が設定された肯定的な応答は、ホーム エージェントがモバイル ネットワークの転送を設定したことを意味します。バインディング プロセスが完了すると、ホーム エージェントとモバイル ルーターの間に双方向トンネルが確立されます。トンネルのエンドポイントは、モバイル ルータの気付アドレスとホーム エージェントのアドレスです。モバイル ネットワーク プレフィックスに属する送信元アドレスを持つパケットがモバイル ネットワークから受信された場合、モバイル ルータはこのトンネルを通じてパケットをホーム エージェントに逆トンネルします。この逆方向トンネリングは、IP-in-IP カプセル化を使用して行われます [3]。ホーム エージェントはこのパケットのカプセル化を解除し、通信相手ノードに転送します。モバイル ルータ自体が発信したトラフィックの場合、[1] で指定されているように、モバイル ルータはリバース トンネリングまたはルート最適化のいずれかを使用できます。
When a Correspondent Node sends a data packet to a node in the Mobile Network, the packet is routed to the Home Agent that currently has the binding for the Mobile Router. The Mobile Router's network prefix would be aggregated at the Home Agent, which would advertise the resulting aggregation. Alternatively, the Home Agent may receive the data packets destined to the Mobile Network by advertising routes to the Mobile Network Prefix. The actual mechanism by which these routes are advertised is outside the scope of this document. When the Home Agent receives a data packet meant for a node in the Mobile Network, it tunnels the packet to the Mobile Router's current Care-of Address. The Mobile Router decapsulates the packet and forwards it onto the interface where the Mobile Network is connected. Before decapsulating the tunneled packet, the Mobile Router has to check whether the Source address on the outer IPv6 header is the Home Agent's address. This check is not necessary if the packet is protected by IPsec in tunnel mode. The Mobile Router also has to make sure that the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet to the Mobile Network. If it does not, the Mobile Router should drop the packet.
通信相手ノードがモバイル ネットワーク内のノードにデータ パケットを送信すると、そのパケットは現在モバイル ルーターのバインディングを持つホーム エージェントにルーティングされます。モバイル ルーターのネットワーク プレフィックスはホーム エージェントで集約され、ホーム エージェントは結果の集約をアドバタイズします。あるいは、ホーム エージェントは、モバイル ネットワーク プレフィックスへのルートをアドバタイズすることによって、モバイル ネットワーク宛てのデータ パケットを受信することもできます。これらのルートがアドバタイズされる実際のメカニズムは、このドキュメントの範囲外です。ホーム エージェントは、モバイル ネットワーク内のノード宛てのデータ パケットを受信すると、そのパケットをモバイル ルータの現在の気付アドレスにトンネリングします。モバイル ルーターはパケットのカプセル化を解除し、モバイル ネットワークが接続されているインターフェイスに転送します。トンネルされたパケットのカプセル化を解除する前に、モバイル ルータは、外側の IPv6 ヘッダーの送信元アドレスがホーム エージェントのアドレスであるかどうかを確認する必要があります。パケットがトンネル モードの IPsec によって保護されている場合、このチェックは必要ありません。モバイル ルーターは、パケットをモバイル ネットワークに転送する前に、内部 IPv6 ヘッダーの宛先アドレスがモバイル ネットワークで使用されるプレフィックスに属していることを確認する必要もあります。そうでない場合、モバイル ルーターはパケットをドロップする必要があります。
The Mobile Network could include nodes that do not support mobility and nodes that do. A node in the Mobile Network can also be a fixed or a Mobile Router. The protocol described here ensures complete transparency of network mobility to the nodes in the Mobile Network. Mobile Nodes that attach to the Mobile Network treat it as a normal IPv6 access network and run the Mobile IPv6 protocol.
モバイル ネットワークには、モビリティをサポートしないノードとモビリティをサポートするノードが含まれる可能性があります。モバイル ネットワーク内のノードは、固定ルーターまたはモバイル ルーターにすることもできます。ここで説明するプロトコルは、モバイル ネットワーク内のノードに対するネットワーク モビリティの完全な透過性を保証します。モバイル ネットワークに接続するモバイル ノードは、モバイル ネットワークを通常の IPv6 アクセス ネットワークとして扱い、モバイル IPv6 プロトコルを実行します。
The Mobile Router and the Home Agent can run a routing protocol through the bi-directional tunnel. In this case, the Mobile Router need not include prefix information in the Binding Update. Instead, the Home Agent uses the routing protocol updates to set up forwarding for the Mobile Network. When the routing protocol is running, the bi-directional tunnel must be treated as a tunnel interface. The tunnel interface is included in the list of interfaces on which routing protocol is active. The Mobile Router should be configured not to send any routing protocol messages on its egress interface when it is away from the home link and connected to a visited link.
モバイル ルーターとホーム エージェントは、双方向トンネルを介してルーティング プロトコルを実行できます。この場合、モバイルルータは、バインディングアップデートにプレフィックス情報を含める必要はない。代わりに、ホーム エージェントはルーティング プロトコルの更新を使用して、モバイル ネットワークの転送を設定します。ルーティング プロトコルが実行されている場合、双方向トンネルはトンネル インターフェイスとして扱われる必要があります。トンネル インターフェイスは、ルーティング プロトコルがアクティブなインターフェイスのリストに含まれています。モバイル ルータは、ホーム リンクから離れ、訪問先リンクに接続されている場合、出力インターフェイスでルーティング プロトコル メッセージを送信しないように設定する必要があります。
Finally, the Home Agent may be configured with static routes to the Mobile Network Prefix via the Mobile Router's Home Address. In this case, the routes are set independently of the binding flows and the returning home of a Mobile Router. The benefit is that such movement does not induce additional signalling in the form of routing updates in the home network. The drawback is that the routes are present even if the related Mobile Routers are not reachable (at home or bound) at a given point of time.
最後に、ホーム エージェントは、モバイル ルーターのホーム アドレスを介してモバイル ネットワーク プレフィックスへの静的ルートで構成できます。この場合、ルートはバインディング フローとモバイル ルータのリターン ホームとは独立して設定されます。利点は、そのような移動によって、ホーム ネットワーク内のルーティング更新の形で追加のシグナリングが誘発されないことです。欠点は、特定の時点で関連するモバイル ルーターが (自宅または外出先で) 到達できない場合でも、ルートが存在することです。
A new flag (R) is included in the Binding Update to indicate to the Home Agent whether the Binding Update is coming from a Mobile Router and not from a mobile node. The rest of the Binding Update format remains the same as defined in [1].
新しいフラグ (R) がバインディング アップデートに含まれており、バインディング アップデートがモバイル ノードからではなくモバイル ルーターから送信されているかどうかをホーム エージェントに示します。バインディング アップデート形式の残りの部分は、[1] で定義されたものと同じままです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R)
モバイルルータフラグ(R)
The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node, and it MUST NOT forward packets destined for the Mobile Network to the Mobile Router.
モバイル ルータ フラグは、バインディング アップデートがモバイル ルータからのものであることをホーム エージェントに示すために設定されます。フラグが 0 に設定されている場合、ホーム エージェントはモバイル ルータがモバイル ノードとして動作していると想定し、モバイル ネットワーク宛てのパケットをモバイル ルータに転送してはなりません (MUST NOT)。
Mobility Options
モビリティオプション
A variable length field that can include zero or more mobility options. This document defines a new mobility option in addition to what is defined in [1].
0 個以上のモビリティ オプションを含めることができる可変長フィールド。この文書は、[1] で定義されているものに加えて、新しいモビリティ オプションを定義します。
For descriptions of the other fields in the message, see [1].
メッセージの他のフィールドの説明については、[1] を参照してください。
A new flag (R) is included in the Binding Acknowledgement to indicate that the Home Agent that processed the corresponding Binding Update supports Mobile Routers. The flag is set only if the corresponding Binding Update had the Mobile Router Flag (R) set to 1. The rest of the Binding Acknowledgement format remains the same, as defined in [1].
新しいフラグ (R) がバインディング確認応答に含まれ、対応するバインディング アップデートを処理したホーム エージェントがモバイル ルータをサポートしていることを示します。このフラグは、対応するバインディング アップデートのモバイル ルータ フラグ (R) が 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R)
モバイルルータフラグ(R)
The Mobile Router Flag is set to indicate that the Home Agent that processed the Binding Update supports Mobile Routers. It is set to 1 only if the corresponding Binding Update had the Mobile Router Flag set to 1.
モバイル ルーター フラグは、バインディング アップデートを処理したホーム エージェントがモバイル ルーターをサポートしていることを示すために設定されます。対応するバインディング アップデートのモバイル ルーター フラグが 1 に設定されている場合にのみ、1 に設定されます。
For descriptions of the other fields in the message, see [1].
メッセージの他のフィールドの説明については、[1] を参照してください。
This document also introduces the following new Binding Acknowledgement status values. The values shown below are decimal values.
このドキュメントでは、次の新しいバインディング確認ステータス値も紹介します。以下に示す値は 10 進数値です。
140 Mobile Router Operation not permitted
140 モバイルルーターの操作は許可されていません
141 Invalid Prefix
141 無効なプレフィックス
142 Not Authorized for Prefix
142 プレフィックスは許可されていません
143 Forwarding Setup failed (prefixes missing)
143 転送セットアップに失敗しました (プレフィックスがありません)
Status values less than 128 indicate that the Binding Update was processed successfully by the receiving nodes. Values greater than 128 indicate that the Binding Update was rejected by the Home Agent.
128 未満のステータス値は、バインディング更新が受信ノードによって正常に処理されたことを示します。128 より大きい値は、バインディング アップデートがホーム エージェントによって拒否されたことを示します。
The Mobile Network Prefix Option is included in the Binding Update to indicate the prefix information for the Mobile Network to the Home Agent. There could be multiple Mobile Network Prefix Options if the Mobile Router has more than one IPv6 prefix in the Mobile Network and wants the Home Agent to forward packets for each of these prefixes to the Mobile Router's current location.
モバイル ネットワーク プレフィックス オプションは、モバイル ネットワークのプレフィックス情報をホーム エージェントに示すためにバインディング アップデートに含まれています。モバイル ルータがモバイル ネットワーク内に複数の IPv6 プレフィックスを持ち、ホーム エージェントがこれらの各プレフィックスのパケットをモバイル ルータの現在の場所に転送することを希望する場合、複数のモバイル ネットワーク プレフィックス オプションが存在する可能性があります。
The Mobile Network Prefix Option has an alignment requirement of 8n+4. Its format is as follows.
モバイル ネットワーク プレフィックス オプションには、8n 4 のアライメント要件があります。その形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6
6
Length
長さ
Eight-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. Set to 18.
タイプと長さのフィールドを除く、オプションの長さをオクテット単位で示す 8 ビットの符号なし整数。18に設定します。
Reserved
予約済み
This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
このフィールドは今のところ使用されていません。この値は送信者によって 0 に初期化されなければならず、受信者によって無視されなければなりません。
Prefix Length
プレフィックスの長さ
Eight-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option.
オプションに含まれる IPv6 プレフィックスのプレフィックス長を示す 8 ビットの符号なし整数。
Mobile Network Prefix
モバイルネットワークプレフィックス
A sixteen-byte field containing the Mobile Network Prefix
モバイル ネットワーク プレフィックスを含む 16 バイトのフィールド
Mobile Router operation is derived largely from the combined behaviors of a host, of a router [5], and of a Mobile Node [1].
モバイル ルーターの動作は主に、ホスト、ルーター [5]、およびモバイル ノード [1] の動作の組み合わせから派生します。
A Mobile Node can act in two ways: (1) as a Mobile Host, in which case the Home Agent doesn't maintain any prefix information related to the Mobile Host's Home Address but does maintain a binding cache entry related to the Mobile Host's Home Address, and (2) as a Mobile Router, in which case, in addition to maintaining the binding cache entry corresponding to the Mobile Router Home Address, the Home Agent maintains forwarding information related to prefixes assigned to the Mobile Network. The distinction between the two modes is represented by the value of the Mobile Router Flag (R).
モバイル ノードは 2 つの方法で動作できます。(1) モバイル ホストとして動作する。この場合、ホーム エージェントはモバイル ホストのホーム アドレスに関連するプレフィックス情報を維持しませんが、モバイル ホストのホームに関連するバインディング キャッシュ エントリを維持します。この場合、ホーム エージェントは、モバイル ルータのホーム アドレスに対応するバインディング キャッシュ エントリを維持することに加えて、モバイル ネットワークに割り当てられたプレフィックスに関連する転送情報を維持します。2 つのモードの区別は、モバイル ルーター フラグ (R) の値によって表されます。
A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes as described in section 8.5 of [1].
モバイル ルータは、[1] のセクション 8.5 で説明されているように、IPv6 モバイル ノードのすべての要件を実装しなければなりません (MUST)。
Like a Mobile Host, a Mobile Router also maintains a Binding Update List, described in section 11.1 of the Mobile IPv6 specification [1]. The Binding Update list is a conceptual data structure that records information sent in the Binding Updates. There is one entry per each destination to which the Mobile Router is currently sending Binding Updates.
モバイル ホストと同様に、モバイル ルータも、モバイル IPv6 仕様 [1] のセクション 11.1 で説明されているバインディング アップデート リストを維持します。バインディング アップデート リストは、バインディング アップデートで送信された情報を記録する概念的なデータ構造です。モバイル ルーターが現在バインディング アップデートを送信している宛先ごとに 1 つのエントリがあります。
This document introduces a new Prefix Information field in the Binding Update list structure. This field is used to store any prefix information that the Mobile Router includes in the Binding Update. If the Mobile Router sets the Mobile Router Flag (R) in the Binding Update but does not include any prefix information in it this field is set to null. The Mobile Router does not include prefix information in the Binding Update in the implicit mode or when it, runs a dynamic routing protocol with its Home Agent.
このドキュメントでは、バインディング アップデート リスト構造に新しいプレフィックス情報フィールドを導入します。このフィールドは、モバイル ルーターがバインディング アップデートに含めるプレフィックス情報を格納するために使用されます。モバイル ルータがバインディング アップデートでモバイル ルータ フラグ (R) を設定するが、その中にプレフィックス情報が含まれていない場合、このフィールドは null に設定されます。モバイル ルータは、暗黙的モードまたはホーム エージェントで動的ルーティング プロトコルを実行する場合、バインディング アップデートにプレフィックス情報を含めません。
As does a Mobile Host, a Mobile Router stores the information regarding status of flags of the Binding Update in the corresponding Binding Update List entry. This document introduces a new Mobile Router Flag (R) for this entry. The status of this flag is stored in the Binding Update list whenever a Binding Update is sent.
モバイル ホストと同様に、モバイル ルータは、バインディング アップデートのフラグのステータスに関する情報を、対応するバインディング アップデート リスト エントリに保存します。このドキュメントでは、このエントリに新しいモバイル ルーター フラグ (R) を導入します。このフラグのステータスは、バインディング アップデートが送信されるたびにバインディング アップデート リストに保存されます。
A Mobile Router also maintains a Home Agent list populated according to the same procedure as a Mobile Host.
モバイル ルータは、モバイル ホストと同じ手順に従って入力されたホーム エージェント リストも維持します。
A Mobile Router sends Binding Updates to its Home Agent, as described in [1]. If the Mobile Router is not running a routing protocol as described in section 8, it uses one of the following modes to tell the Home Agent to determine which prefixes belong to the Mobile Router. In both modes, the Mobile Router sets the Mobile Router Flag (R).
[1] で説明されているように、モバイル ルーターはバインディング アップデートをホーム エージェントに送信します。モバイル ルータがセクション 8 で説明されているルーティング プロトコルを実行していない場合、モバイル ルータは次のいずれかのモードを使用して、ホーム エージェントにどのプレフィックスがモバイル ルータに属するかを判断するように指示します。どちらのモードでも、モバイル ルータはモバイル ルータ フラグ (R) を設定します。
Implicit:
暗黙：
In this mode, the Mobile Router does not include a Mobile Network Prefix Option in the Binding Update. The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned by the Mobile Router and to set up forwarding for the Mobile Network. One example would be manual configuration at the Home Agent mapping the Mobile Router's Home Address to the information required for setting up forwarding for the Mobile Network.
このモードでは、モバイル ルーターにはバインディング アップデートにモバイル ネットワーク プレフィックス オプションが含まれません。ホーム エージェントは、モバイル ルータが所有するモバイル ネットワーク プレフィックスを決定し、モバイル ネットワークの転送を設定するために、任意のメカニズム (この文書では定義されていない) を使用できます。一例としては、モバイル ルータのホーム アドレスをモバイル ネットワークの転送設定に必要な情報にマッピングするホーム エージェントでの手動構成があります。
Explicit:
明示的:
In this mode, the Mobile Router includes one or more Mobile Network Prefix Options in the Binding Update. These options contain information about the Mobile Network Prefix(es) configured on the Mobile Network.
このモードでは、モバイル ルーターのバインディング アップデートに 1 つ以上のモバイル ネットワーク プレフィックス オプションが含まれます。これらのオプションには、モバイル ネットワーク上で構成されたモバイル ネットワーク プレフィックスに関する情報が含まれています。
A Mobile Router MUST implement at least one mode and MAY implement both. In the latter case, local configuration on the Mobile Router decides which mode to use. This is out of scope for this document.
モバイルルーターは少なくとも 1 つのモードを実装しなければならず、両方を実装してもよいです。後者の場合、モバイル ルーターのローカル設定によって、使用するモードが決まります。これはこのドキュメントの範囲外です。
If the Mobile Router Flag is set, the Home Registration Flag (H) MUST be set.
モバイルルーターフラグが設定されている場合は、ホーム登録フラグ (H) を設定する必要があります。
If the Mobile Router has a valid binding cache entry at the Home Agent, subsequent Binding Updates for the same Home Address should have the same value as the value in the binding cache for the Mobile Router Flag (R). In explicit mode, the Mobile Router MUST include prefix information in all Binding Updates, including those sent to refresh existing binding cache entries, if it wants forwarding enabled for the corresponding Mobile Network Prefixes.
モバイル ルータがホーム エージェントに有効なバインディング キャッシュ エントリを持っている場合、同じホーム アドレスに対する後続のバインディング アップデートは、モバイル ルータ フラグ (R) のバインディング キャッシュ内の値と同じ値を持つ必要があります。明示モードでは、モバイル ルータは、対応するモバイル ネットワーク プレフィックスに対して転送を有効にする場合、既存のバインディング キャッシュ エントリを更新するために送信されるものを含む、すべてのバインディング アップデートにプレフィックス情報を含めなければなりません (MUST)。
The Mobile Router receives Binding Acknowledgements from the Home Agent corresponding to the Binding Updates it sent. If the Binding Acknowledgement status is set to 0 (Binding Update accepted) and the Mobile Router Flag (R) is set to 1, the Mobile Router assumes that the Home Agent has successfully processed the Binding Update and has set up forwarding for the Mobile Network. The Mobile Router can then start using the bi-directional tunnel to reverse-tunnel traffic from the Mobile Network. If the Mobile Router Flag (R) is not set, then the Mobile Router concludes that its current Home Agent does not support Mobile Routers and it performs Dynamic Home Agent Address Discovery again to discover Home Agents that do. The Mobile Router MUST also de-register with the Home Agent that did not support it before attempting registration with another.
モバイル ルータは、送信したバインディング アップデートに対応するバインディング確認応答をホーム エージェントから受信します。バインディング確認ステータスが 0 (バインディング アップデートが受け入れられた) に設定され、モバイル ルータ フラグ (R) が 1 に設定されている場合、モバイル ルータは、ホーム エージェントがバインディング アップデートを正常に処理し、モバイル ネットワークへの転送を設定したと想定します。。その後、モバイル ルーターは双方向トンネルの使用を開始して、モバイル ネットワークからのトラフィックを逆方向にトンネルできるようになります。モバイル ルータ フラグ (R) が設定されていない場合、モバイル ルータは、現在のホーム エージェントがモバイル ルータをサポートしていないと判断し、動的ホーム エージェント アドレス検出を再度実行して、サポートしているホーム エージェントを検出します。モバイル ルータは、別のホーム エージェントに登録を試みる前に、サポートしていないホーム エージェントからも登録を解除しなければなりません (MUST)。
If the Binding Acknowledgement status is set to a value between 128 and 139, the Mobile Router takes necessary actions as described in the Mobile IPv6 specification [1]. For the Binding Acknowledgement status values defined in this document, the following sections explain the Mobile Router's behavior.
バインディング確認ステータスが 128 ～ 139 の値に設定されている場合、モバイル ルータはモバイル IPv6 仕様 [1] に記載されているように必要なアクションを実行します。このドキュメントで定義されているバインディング確認応答ステータス値については、次のセクションでモバイル ルータの動作について説明します。
In Implicit mode, the Mobile Router interprets only error statuses 140 (Mobile Router Operation not permitted) and 143 (Forwarding Setup failed). The Mobile Router MUST treat Binding Acknowledgements with statuses '141' and '142' as fatal errors, since they should not be sent by the Home Agent in implicit mode.
Implicit モードでは、モバイル ルータはエラー ステータス 140 (モバイル ルータの操作が許可されていない) と 143 (転送セットアップの失敗) のみを解釈します。モバイル ルータは、ステータス '141' および '142' のバインディング確認応答を致命的エラーとして扱わなければなりません (MUST)。これは、ホーム エージェントによって暗黙モードで送信されるべきではないためです。
If the Binding Acknowledgement from the Home Agent has the status 140, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, the Mobile Router MUST refrain from sending Binding Updates with the Mobile Router Flag set to any Home Agent on the home link, and it must log the information.
ホーム エージェントからのバインディング確認応答のステータスが 140 の場合、モバイル ルータは同じホーム リンク上の別のホーム エージェントにバインディング アップデートを送信する必要があります (SHOULD)。ホーム エージェントが肯定的に応答しない場合、モバイル ルータは、ホーム リンク上のホーム エージェントにモバイル ルータ フラグが設定されたバインディング アップデートを送信することを控えなければならず、情報をログに記録しなければなりません。
If the Binding Acknowledgement has the status 143, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, the Mobile Router SHOULD refrain from sending this Binding Update to any Home Agent on the home link, and MAY send Binding Updates in Explicit mode to a Home Agent on the same home link.
バインディング確認応答のステータスが 143 の場合、モバイル ルータは同じホーム リンク上の別のホーム エージェントにバインディング アップデートを送信する必要があります (SHOULD)。ホーム エージェントが肯定的に応答しない場合、モバイル ルータはこのバインディング アップデートをホーム リンク上のホーム エージェントに送信することを控えるべきであり、同じホーム リンク上のホーム エージェントにバインディング アップデートを明示モードで送信してもよい(MAY)。
If the Mobile Router sent a Binding Update to the Home Agent in explicit mode, then the Mobile Router interprets only error statuses 140 (Mobile Router Operation not permitted), 141 (Invalid Prefix), and 142 (Not Authorized for Prefix). The Mobile Router MUST treat Binding Acknowledgements with status '143' as a fatal error, since it should not be sent by the Home Agent in explicit mode.
モバイル ルータがホーム エージェントに明示的モードでバインディング アップデートを送信した場合、モバイル ルータはエラー ステータス 140 (モバイル ルータの操作が許可されていない)、141 (無効なプレフィックス)、および 142 (プレフィックスが許可されていない) のみを解釈します。モバイル ルータは、ステータス '143' のバインディング確認応答を致命的エラーとして扱わなければなりません (MUST)。これは、ホーム エージェントによって明示モードで送信されるべきではないためです。
If the Binding Acknowledgement from the Home Agent has the status 140, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, then the Mobile Router MUST refrain from sending Binding Updates with the Mobile Router Flag set to any Home Agent on the home link, and it must log the information.
ホーム エージェントからのバインディング確認応答のステータスが 140 の場合、モバイル ルータは同じホーム リンク上の別のホーム エージェントにバインディング アップデートを送信する必要があります (SHOULD)。ホーム エージェントが肯定的に応答しない場合、モバイル ルータは、ホーム リンク上のホーム エージェントにモバイル ルータ フラグが設定されたバインディング アップデートの送信を控えなければならず、情報をログに記録しなければなりません。
If the Binding Acknowledgement has the status 141 or 142, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, then the Mobile Router SHOULD refrain from sending Binding Updates to any Home Agent on the home link. The Mobile Router MUST also stop advertising the prefix in the Mobile Network and try to obtain new IPv6 prefix information for the Mobile Network. It would do this by the same means that it initially got assigned the current Mobile Network Prefix. Alternatively, the Mobile Router MAY send Binding Updates in Implicit mode to a Home Agent on the same home link.
バインディング確認応答のステータスが 141 または 142 の場合、モバイル ルータは同じホーム リンク上の別のホーム エージェントにバインディング アップデートを送信する必要があります (SHOULD)。ホーム エージェントが肯定的に応答しない場合、モバイル ルータはホーム リンク上のホーム エージェントにバインディング アップデートを送信することを控えるべきです(SHOULD)。モバイル ルータは、モバイル ネットワークでのプレフィックスのアドバタイズを停止し、モバイル ネットワークの新しい IPv6 プレフィックス情報の取得を試行しなければなりません (MUST)。これは、最初に現在のモバイル ネットワーク プレフィックスを割り当てたときと同じ方法で行われます。あるいは、モバイル ルータは、同じホーム リンク上のホーム エージェントに暗黙的モードでバインディング アップデートを送信してもよい(MAY)。
If by the end of this Error Processing procedure, as described in sections 5.4.1 and 5.4.2, the Mobile Router has tried every available mode and still has not received a positive Binding Acknowledgement, the Mobile Router MUST stop sending Binding Updates with the Mobile Router Flag set for this Home Address and it must log the information.
セクション 5.4.1 および 5.4.2 で説明されているように、このエラー処理手順が終了するまでに、モバイル ルータが利用可能なすべてのモードを試しても肯定的なバインディング確認応答を受信していない場合、モバイル ルータは、このホーム アドレスに対してモバイル ルーター フラグが設定されており、情報をログに記録する必要があります。
In all cases above, the Mobile Router MUST conclude that the Home Agent did not create a binding cache entry for the Mobile Router's Home Address.
上記のすべての場合において、モバイル ルータは、ホーム エージェントがモバイル ルータのホーム アドレスのバインディング キャッシュ エントリを作成しなかったと結論付けなければなりません (MUST)。
When a successful Binding Acknowledgement is received, the Mobile Router sets up its endpoint of the bi-directional tunnel.
成功したバインディング確認応答を受信すると、モバイル ルータは双方向トンネルのエンドポイントを設定します。
The bi-directional tunnel between the Mobile Router and the Home Agent allows packets to flow in both directions, while the Mobile Router is connected to a visited link. The bi-directional tunnel is created by merging two unidirectional tunnels, as described in RFC 2473 [3]. The tunnel from the Mobile Router to the Home Agent has the Care-of address of the Mobile Router as the tunnel entry point and the Home Agent's address as the tunnel exit point. The tunnel from the Home Agent to the Mobile Router has the Home Agent's address and the Mobile Router's Care-of Address as the tunnel entry point and exit point, respectively. All IPv6 traffic to and from the Mobile Network is sent through this bi-directional tunnel.
モバイル ルータとホーム エージェント間の双方向トンネルにより、モバイル ルータが訪問先リンクに接続されている間、パケットが両方向に流れることができます。双方向トンネルは、RFC 2473 [3] に記載されているように、2 つの単方向トンネルを結合することによって作成されます。モバイル ルータからホーム エージェントへのトンネルには、トンネルの入口点としてモバイル ルータの気付アドレスがあり、トンネルの出口点としてホーム エージェントのアドレスがあります。ホーム エージェントからモバイル ルータへのトンネルには、ホーム エージェントのアドレスとモバイル ルータの気付アドレスが、それぞれトンネルの入口点と出口点として含まれます。モバイル ネットワークとの間のすべての IPv6 トラフィックは、この双方向トンネルを通じて送信されます。
A Mobile Router uses the Tunnel Hop Limit normally assigned to routers (not to hosts). Please refer to [3] for more details.
モバイル ルーターは、通常 (ホストではなく) ルーターに割り当てられるトンネル ホップ制限を使用します。詳細については[3]を参照してください。
When the Mobile Router is at home, it MAY be configured to send Router Advertisements and to reply to Router Solicitations on the interface attached to the home link. The value of the Router Lifetime field SHOULD be set to 0 to prevent other nodes from configuring the Mobile Router as the default router.
モバイル ルーターがホームにある場合、ホーム リンクに接続されているインターフェイス上でルーター アドバタイズメントを送信し、ルーター要請に応答するように構成されてもよい(MAY)。他のノードがモバイル ルータをデフォルト ルータとして設定するのを防ぐために、Router Lifetime フィールドの値を 0 に設定する必要があります (SHOULD)。
A Mobile Router SHOULD NOT send unsolicited Router Advertisements and SHOULD NOT reply to Router Solicitations on any egress interface when that interface is attached to a visited link. However, the Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor Solicitations received on the egress interface, for addresses valid on the visited link.
モバイルルーターは、インターフェイスが訪問先リンクに接続されている場合、任意の出力インターフェイス上で一方的なルーター通知を送信してはならず、また、そのインターフェイス上でルーター要請に応答すべきではありません。ただし、モバイル ルータは、訪問先リンクで有効なアドレスについて、出力インターフェイスで受信した近隣要請に対して近隣広告で応答する必要があります (SHOULD)。
A router typically ignores Router Advertisements sent by other routers on a link. However, a Mobile Router MUST NOT ignore Router Advertisements received on the egress interface. The received Router Advertisements MAY be used for address configuration, default router selection, or movement detection.
ルーターは通常、リンク上の他のルーターによって送信されたルーター アドバタイズメントを無視します。ただし、モバイル ルーターは、出力インターフェイスで受信したルーター アドバタイズメントを無視してはなりません。受信したルーター アドバタイズメントは、アドレス設定、デフォルト ルーターの選択、または移動検出に使用できます (MAY)。
When at home, the Mobile Router joins the multicast group All Routers Address with scopes 1 interface-local (on the home-advertising interface), and 2 link-local, on any of its egress interfaces. When in a visited network, the Mobile Router MUST NOT join the above multicast groups on the corresponding interface.
自宅にいるとき、モバイル ルータは、その出力インターフェイスのいずれかで、スコープ 1 インターフェイス ローカル (ホーム アドバタイジング インターフェイス上) と 2 リンク ローカルを持つマルチキャスト グループ All Routers Address に参加します。訪問先ネットワークにいる場合、モバイル ルータは、対応するインターフェイス上の上記のマルチキャスト グループに参加してはなりません (MUST NOT)。
When the Mobile Router detects that it has returned to its home link, it MUST de-register with its Home Agent. The Mobile Router MUST implement and follow the returning-home procedures defined for a mobile node in [1]. In addition, the Mobile Router MAY start behaving as a router on its egress interface, especially as follows:
モバイル ルーターは、ホーム リンクに戻ったことを検出すると、ホーム エージェントから登録を解除しなければなりません (MUST)。モバイルルーターは、[1] でモバイルノードに対して定義された帰宅手順を実装し、従わなければなりません (MUST)。さらに、モバイル ルータは、特に次のように、出力インターフェイス上でルータとして動作し始めてもよい(MAY)。
- The Mobile Router MAY send Router Advertisements on its egress interfaces, but the router lifetime SHOULD be set to 0 so that hosts on the home link do not pick the Mobile Router as the default router.
- モバイル ルータは、その出力インターフェイスでルータ アドバタイズメントを送信してもよいですが、ホーム リンク上のホストがモバイル ルータをデフォルト ルータとして選択しないように、ルータのライフタイムを 0 に設定する必要があります (SHOULD)。
- The Mobile Router MAY join the All Routers Address multicast group on the home link.
- モバイル ルータは、ホーム リンク上の全ルータ アドレス マルチキャスト グループに参加してもよい(MAY)。
- The Mobile Router MAY send routing protocol messages on its egress interface if it is configured to run a dynamic routing protocol.
- モバイル ルータは、動的ルーティング プロトコルを実行するように設定されている場合、その出力インターフェイスでルーティング プロトコル メッセージを送信してもよい（MAY）。
When the Mobile Router sends a de-registration Binding Update in Explicit mode, it SHOULD NOT include any Mobile Network Prefix options in the Binding Update. When the Home Agent removes a binding cache entry, it deletes all associated Mobile Network Prefix routes.
モバイル ルータが登録解除バインディング アップデートを明示的モードで送信する場合、バインディング アップデートにモバイル ネットワーク プレフィックス オプションを含めるべきではありません（SHOULD NOT）。ホーム エージェントがバインディング キャッシュ エントリを削除すると、関連付けられているすべてのモバイル ネットワーク プレフィックス ルートが削除されます。
For a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in section 8.4 of [1]. The Home Agent MUST implement both modes described in section 5.2 of this document.
モバイル ルーターが正しく動作するには、ホーム エージェントが [1] のセクション 8.4 にリストされているすべての要件を満たさなければなりません。ホーム エージェントは、このドキュメントのセクション 5.2 で説明されている両方のモードを実装しなければなりません (MUST)。
The Home Agent maintains Binding Cache Entries for each Mobile Router currently registered with the Home Agent. The Binding Cache is a conceptual data structure described in detail in [1].
ホーム エージェントは、現在ホーム エージェントに登録されている各モバイル ルータのバインディング キャッシュ エントリを維持します。バインディング キャッシュは、[1] で詳細に説明されている概念的なデータ構造です。
The Home Agent might need to store the Mobile Network Prefixes associated with a Mobile Router in the corresponding Binding Cache Entry. This is required if the Binding Update that created the Binding Cache Entry contained explicit prefix information. This information can be used later to clean up routes installed in explicit mode, when the Binding Cache Entry is removed, and to maintain the routing table, for instance, should the routes be removed manually.
ホーム エージェントは、モバイル ルーターに関連付けられたモバイル ネットワーク プレフィックスを、対応するバインディング キャッシュ エントリに保存する必要がある場合があります。これは、バインディング キャッシュ エントリを作成したバインディング更新に明示的なプレフィックス情報が含まれている場合に必要です。この情報は、後でバインディング キャッシュ エントリが削除されるときに明示モードでインストールされたルートをクリーンアップしたり、ルートが手動で削除された場合などにルーティング テーブルを維持したりするために使用できます。
The Home Agent also stores the status of the Mobile Router Flag (R) in the Binding Cache entry.
ホーム エージェントは、モバイル ルータ フラグ (R) のステータスもバインディング キャッシュ エントリに保存します。
The Home Agent SHOULD be able to prevent a Mobile Router from claiming Mobile Network Prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains a Prefix Table and verifies the prefix information provided by the Mobile Router against Prefix Table entries. The Prefix Table SHOULD be used by the Home Agent when it processes a Binding Update in explicit mode. It is not required when a dynamic routing protocol is run between the Mobile Router and the Home Agent.
ホームエージェントは、モバイルルータが別のモバイルルータに属するモバイルネットワークプレフィックスを要求することを阻止できるべきである(SHOULD)。ホーム エージェントは、プレフィックス テーブルを維持し、モバイル ルータによって提供されたプレフィックス情報をプレフィックス テーブルのエントリと照合する場合、このような攻撃を防ぐことができます。プレフィックス テーブルは、ホーム エージェントが明示モードでバインディング アップデートを処理するときに使用する必要があります (SHOULD)。モバイル ルータとホーム エージェント間でダイナミック ルーティング プロトコルが実行されている場合は必要ありません。
Each entry in the Prefix Table contains the following fields:
プレフィックス テーブルの各エントリには、次のフィールドが含まれます。
- The Home Address of the Mobile Router. This field is used as the key for searching the pre-configured Prefix Table.
- モバイルルーターのホームアドレス。このフィールドは、事前設定されたプレフィックス テーブルを検索するためのキーとして使用されます。
- The Mobile Network Prefix of the Mobile Router associated with the Home Address.
- ホーム アドレスに関連付けられたモバイル ルーターのモバイル ネットワーク プレフィックス。
The Home Agent processes the Binding Update as described in section 10.3.1 of the Mobile IPv6 specification [1]. This section describes the processing of the Binding Update if the Mobile Router (R) Flag is set. The Home Agent performs the following check.
ホーム エージェントは、モバイル IPv6 仕様 [1] のセクション 10.3.1 で説明されているようにバインディング アップデートを処理します。ここでは、Mobile Router(R) Flag が設定されている場合の Binding Update の処理について説明します。ホーム エージェントは次のチェックを実行します。
- The Home Registration (H) Flag MUST be set. If it is not, the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 140. Note: The basic support does not allow sending a Binding Update for a Mobile Network Prefix to correspondent nodes (for route optimization).
- ホーム登録 (H) フラグを設定する必要があります。そうでない場合、ホーム エージェントはバインディング アップデートを拒否し、ステータスを 140 に設定してバインディング確認応答を送信しなければなりません。 注: 基本サポートでは、(ルート最適化のため) モバイル ネットワーク プレフィックスのバインディング アップデートをコレスポンデント ノードに送信することはできません。
- Mobile IPv6 specification [1] requires that the Home Address in the Binding Update be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specification relaxes this requirement so that the Home Agent rejects the Binding Update only if the Home Address does not belong to the prefix that the Home Agent is configured to serve.
- モバイル IPv6 仕様 [1] では、バインディング アップデートのホーム アドレスがホーム リンク上でアドバタイズされるプレフィックスから構成されることが要求されています。それ以外の場合、バインディング更新はステータス値 132 [1] で拒否されます。この仕様では、ホーム エージェントがサービスを提供するように設定されているプレフィックスにホーム アドレスが属していない場合にのみ、ホーム エージェントがバインディング アップデートを拒否するように、この要件が緩和されています。
If the Home Agent has a valid binding cache entry for the Mobile Router, and if the Binding Update has the Mobile Router Flag (R) set to a value different from that in the existing binding cache entry, then the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 139 (Registration type change disallowed). However, if the Binding Update is a de-registration Binding Update, the Home Agent ignores the value of the Mobile Router Flag (R).
ホーム エージェントがモバイル ルータ用の有効なバインディング キャッシュ エントリを持っており、バインディング アップデートのモバイル ルータ フラグ (R) が既存のバインディング キャッシュ エントリのものとは異なる値に設定されている場合、ホーム エージェントはバインディングを拒否しなければなりません(MUST)。ステータスを 139 に設定してバインディング確認応答を更新して送信します (登録タイプの変更は許可されません)。ただし、バインディング アップデートが登録解除バインディング アップデートの場合、ホーム エージェントはモバイル ルータ フラグ (R) の値を無視します。
If the Lifetime specified in the Binding Update is 0 or the specified Care-of address matches the Home Address in the Binding Update, then this is a request to delete the cached binding for the home address and specified Mobile Network Prefixes. The Binding Update is processed as described in section 6.7.
バインディング アップデートで指定されたライフタイムが 0 であるか、指定された気付アドレスがバインディング アップデートのホーム アドレスと一致する場合、これはホーム アドレスおよび指定されたモバイル ネットワーク プレフィックスのキャッシュされたバインディングを削除する要求です。バインディング更新はセクション 6.7 で説明されているように処理されます。
If the Home Agent does not reject the Binding Update as invalid, and if a dynamic routing protocol is not run between the Home Agent and the Mobile Router as described in section 8, then the Home Agent retrieves the Mobile Network Prefix information as described below.
ホーム エージェントがバインディング アップデートを無効として拒否せず、セクション 8 で説明されているようにホーム エージェントとモバイル ルータの間で動的ルーティング プロトコルが実行されていない場合、ホーム エージェントは以下で説明するようにモバイル ネットワーク プレフィックス情報を取得します。
- If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the Mobile Network Prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Binding Update contains more than one option, the Home Agent MUST set up forwarding for all the Mobile Network Prefixes. If the Home Agent fails to set up forwarding to all the prefixes listed in the Binding Update, then it MUST NOT forward traffic to any of the prefixes. Furthermore, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix).
- モバイル ネットワーク プレフィックス オプションがバインディング アップデートに存在する場合、モバイル ネットワーク プレフィックスのプレフィックス情報は、オプションのモバイル ネットワーク プレフィックス フィールドとプレフィックス長フィールドから取得されます。バインディング アップデートに複数のオプションが含まれている場合、ホーム エージェントはすべてのモバイル ネットワーク プレフィックスの転送を設定しなければなりません (MUST)。ホーム エージェントがバインディング アップデートにリストされているすべてのプレフィックスへの転送の設定に失敗した場合、どのプレフィックスにもトラフィックを転送してはなりません (MUST NOT)。さらに、バインディング更新を拒否し、ステータスを 141 (無効なプレフィックス) に設定したバインディング確認応答を送信しなければなりません (MUST)。
If the Home Agent verifies the prefix information with the Prefix Table and the check fails, the Home Agent MUST discard the Binding Update and send a Binding Acknowledgement with status set to 142 (Not Authorized for Prefix).
ホーム エージェントがプレフィックス テーブルを使用してプレフィックス情報を検証し、チェックが失敗した場合、ホーム エージェントはバインディング アップデートを破棄し、ステータスを 142 (プレフィックスに対して許可されていない) に設定したバインディング確認応答を送信しなければなりません (MUST)。
- If there is no option in the Binding Update carrying prefix information, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and to set up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed).
- プレフィックス情報を伝えるバインディング アップデートにオプションがない場合、ホーム エージェントは手動で事前設定された情報を使用して、モバイル ルータに割り当てられるプレフィックスを決定し、モバイル ネットワークの転送を設定します。ホーム エージェントが使用できる情報がない場合は、バインディング アップデートを拒否し、ステータスを 143 (転送セットアップ失敗) に設定してバインディング確認応答を送信しなければなりません (MUST)。
If the Home Agent has a valid binding cache entry for the Mobile Router, it should compare the list of prefixes in the Binding Update against the prefixes stored in the binding cache entry. If the binding cache entry contains prefixes that do not appear in the Binding Update, the Home Agent MUST disable forwarding for these Mobile Network Prefixes.
ホーム エージェントがモバイル ルータの有効なバインディング キャッシュ エントリを持っている場合、ホーム エージェントはバインディング アップデート内のプレフィックスのリストをバインディング キャッシュ エントリに保存されているプレフィックスと比較する必要があります。バインディング キャッシュ エントリにバインディング アップデートに表示されないプレフィックスが含まれている場合、ホーム エージェントはこれらのモバイル ネットワーク プレフィックスの転送を無効にしなければなりません (MUST)。
If all checks are passed, the Home Agent creates a binding cache entry for Mobile Router's Home Address or updates the entry if it already exists. Otherwise, the Home Agent MUST NOT register the binding of the Mobile Router's Home Address.
すべてのチェックに合格すると、ホーム エージェントはモバイル ルータのホーム アドレスのバインディング キャッシュ エントリを作成するか、エントリがすでに存在する場合は更新します。それ以外の場合、ホーム エージェントはモバイル ルータのホーム アドレスのバインディングを登録してはなりません (MUST NOT)。
The Home Agent defends the Mobile Router's Home Address through Proxy Neighbor Discovery by multicasting a Neighbor Advertisement message onto the home link on behalf of the Mobile Router. All fields in the Proxy Neighbor Advertisement message should be set the same way they would be by the Mobile Router if it sent this Neighbor Advertisement while at home, as described in [6]. There is an exception: If the Mobile Router (R) Flag has been set in the Binding Update, the Router (R) bit in the Advertisement MUST be set.
ホーム エージェントは、モバイル ルーターに代わって近隣広告メッセージをホーム リンク上にマルチキャストすることにより、プロキシ近隣探索を通じてモバイル ルーターのホーム アドレスを防御します。[6] で説明されているように、プロキシ近隣広告メッセージのすべてのフィールドは、モバイル ルーターが在宅中にこの近隣広告を送信する場合と同じように設定する必要があります。例外があります。バインディング アップデートでモバイル ルーター (R) フラグが設定されている場合、アドバタイズメントのルーター (R) ビットを設定しなければなりません。
The Home Agent also creates a bi-directional tunnel to the Mobile Router for the requested Mobile Network Prefix or updates an existing bi-directional tunnel as described in section 6.4.
ホーム エージェントはまた、セクション 6.4 で説明されているように、要求されたモバイル ネットワーク プレフィックスのモバイル ルーターへの双方向トンネルを作成するか、既存の双方向トンネルを更新します。
To receive packets meant for the Mobile Network, the Home Agent advertises reachability to the Mobile Network. If the Home Link is configured with an aggregated prefix and the Mobile Network Prefix is aggregated under that prefix, then the routing changes related to the Mobile Network may be restricted to the Home Link. If the Home Agent is the only default router on the Home Link, routes to the Mobile Network Prefix are aggregated naturally under the Home Agent, which does not have to do anything special.
モバイル ネットワーク宛てのパケットを受信するために、ホーム エージェントはモバイル ネットワークへの到達可能性をアドバタイズします。ホーム リンクが集約されたプレフィックスで構成され、モバイル ネットワーク プレフィックスがそのプレフィックスの下に集約されている場合、モバイル ネットワークに関連するルーティング変更はホーム リンクに制限される可能性があります。ホーム エージェントがホーム リンク上の唯一のデフォルト ルータである場合、モバイル ネットワーク プレフィックスへのルートはホーム エージェントの下に自然に集約されるため、特別なことを行う必要はありません。
If the Home Agent receives routing updates through a dynamic routing protocol from the Mobile Router, it can be configured to propagate those routes on the relevant interfaces.
ホーム エージェントがモバイル ルータからダイナミック ルーティング プロトコルを介してルーティング アップデートを受信した場合、それらのルートを関連するインターフェイス上に伝播するように設定できます。
The implementation of the bi-directional tunnels and the mechanism for attaching them to the IP stack are outside the scope of this specification. However, all implementations MUST be capable of the following operations:
双方向トンネルの実装と、それらを IP スタックに接続するメカニズムは、この仕様の範囲外です。ただし、すべての実装は次の操作が可能でなければなりません。
- The Home Agent can tunnel packets meant for the Mobile Network prefix to the Mobile Router's current location, the Care-of Address.
- ホーム エージェントは、モバイル ネットワーク プレフィックス宛てのパケットをモバイル ルータの現在の場所である気付アドレスにトンネリングできます。
- The Home Agent can accept packets tunneled by the Mobile Router with the source address of the outer IPv6 header set to the Mobile Router's Care-of Address.
- ホーム エージェントは、モバイル ルータの気付アドレスに設定された外部 IPv6 ヘッダーの送信元アドレスを使用して、モバイル ルータによってトンネリングされたパケットを受け入れることができます。
When the Home Agent receives a data packet destined for the Mobile Network, it MUST forward the packet to the Mobile Router through the bi-directional tunnel. The Home Agent uses either the routing table, the Binding Cache, or a combination to route packets to the Mobile Network. This is implementation specific. Two examples are shown below.
ホーム エージェントがモバイル ネットワーク宛てのデータ パケットを受信した場合、双方向トンネルを通じてそのパケットをモバイル ルーターに転送しなければなりません (MUST)。ホーム エージェントは、ルーティング テーブル、バインディング キャッシュ、またはそれらの組み合わせを使用して、パケットをモバイル ネットワークにルーティングします。これは実装固有のものです。以下に 2 つの例を示します。
1. The Home Agent maintains a route to the Mobile Network Prefix with the next hop set to the Mobile Router's Home Address. When the Home Agent tries to forward the packet to the next hop, it finds a binding cache entry for the home address. Then the Home Agent extracts the Mobile Router's Care-of address and tunnels the packet to the Care-of address.
1. ホーム エージェントは、モバイル ルータのホーム アドレスに設定されたネクスト ホップを使用して、モバイル ネットワーク プレフィックスへのルートを維持します。ホーム エージェントがパケットを次のホップに転送しようとすると、ホーム アドレスのバインディング キャッシュ エントリが見つかります。次に、ホーム エージェントはモバイル ルータの気付アドレスを抽出し、パケットを気付アドレスにトンネリングします。
2. The Home Agent maintains a route to the Mobile Network Prefix with the outgoing interface set to the bi-directional tunnel interface between the Home Agent and the Mobile Router. For this purpose, the Home Agent MUST treat this tunnel as a tunnel interface. When the packets are forwarded through the tunnel interface, they are encapsulated automatically, with the source address and destination address in the outer IPv6 header set to the Home Agent's address and the Mobile Router's Care-of address, respectively.
2. ホーム エージェントは、ホーム エージェントとモバイル ルーター間の双方向トンネル インターフェイスに設定された発信インターフェイスを使用して、モバイル ネットワーク プレフィックスへのルートを維持します。この目的のために、ホーム エージェントはこのトンネルをトンネル インターフェイスとして扱わなければなりません (MUST)。パケットがトンネル インターフェイスを介して転送されると、外側の IPv6 ヘッダーの送信元アドレスと宛先アドレスがそれぞれホーム エージェントのアドレスとモバイル ルータの気付アドレスに設定されて、自動的にカプセル化されます。
A Home Agent serving a Mobile Router sends Binding Acknowledgements with the same rules it uses for sending Binding Acknowledgements to Mobile Hosts [1], with the following enhancements.
モバイル ルータにサービスを提供するホーム エージェントは、モバイル ホストにバインディング確認応答を送信するために使用するのと同じルールでバインディング確認応答を送信します [1]。ただし、次の機能強化が加えられています。
The Home Agent sets the status code in the Binding Acknowledgement to 0 (Binding Update accepted) to indicate to the Mobile Router that it successfully processed the Binding Update. It also sets the Mobile Router Flag (R) to indicate to the Mobile Router that it has set up forwarding for the Mobile Network.
ホーム エージェントは、バインディング確認応答のステータス コードを 0 (バインディング アップデートが受け入れられた) に設定して、バインディング アップデートが正常に処理されたことをモバイル ルータに示します。また、モバイル ルータ フラグ (R) を設定して、モバイル ネットワークの転送が設定されていることをモバイル ルータに示します。
If the Home Agent is not configured to support Mobile Routers, it sets the status code in the Binding Acknowledgement to 140 (Mobile Router Operation not permitted).
ホーム エージェントがモバイル ルーターをサポートするように設定されていない場合、バインディング確認応答のステータス コードは 140 (モバイル ルーターの操作は許可されていません) に設定されます。
If one or more prefixes received in the Binding Update are invalid and the Home Agent cannot set up forwarding for the prefixes, the Home Agent sets the status code in the Binding Acknowledgement to 141 (Invalid Prefix) to indicate this to the Mobile Router.
バインディング アップデートで受信した 1 つ以上のプレフィックスが無効で、ホーム エージェントがプレフィックスの転送を設定できない場合、ホーム エージェントはバインディング確認応答のステータス コードを 141 (無効なプレフィックス) に設定して、これをモバイル ルータに示します。
If the Mobile Router is not authorized to use this Home Address to forward packets for one or more prefixes present in the Binding Update, the Home Agent sets the status code in the Binding Acknowledgement to 142 (Not Authorized for Prefix) to indicate this.
モバイル ルータが、このホーム アドレスを使用してバインディング アップデートに存在する 1 つ以上のプレフィックスのパケットを転送することを許可されていない場合、ホーム エージェントは、これを示すためにバインディング確認応答のステータス コードを 142 (プレフィックスに対して許可されていない) に設定します。
The Home Agent sets the status code to 143 (Forwarding Setup failed) if it is unable to determine the information needed to set up forwarding for the Mobile Network. This is used in the Implicit mode, in which the Mobile Router does not include any prefix information in the Binding Update.
ホーム エージェントは、モバイル ネットワークの転送を設定するために必要な情報を判断できない場合、ステータス コードを 143 (転送設定失敗) に設定します。これは、モバイル ルータがバインディング アップデートにプレフィックス情報を含まない暗黙モードで使用されます。
When the Home Agent successfully processes the de-registration BU, it deletes the Binding Cache Entry for the Mobile Router's Home Address and stops proxying the Home Address. This is described in detail in the Mobile IPv6 specification [1].
ホーム エージェントは登録解除 BU の処理に成功すると、モバイル ルータのホーム アドレスのバインディング キャッシュ エントリを削除し、ホーム アドレスのプロキシを停止します。これについては、モバイル IPv6 仕様 [1] で詳しく説明されています。
In addition, the Home Agent removes the bi-directional tunnel and stops forwarding packets to the Mobile Network. The Home Agent should keep all necessary information to clean up whichever routes it installed, whether they come from an implicit or explicit source.
さらに、ホーム エージェントは双方向トンネルを削除し、モバイル ネットワークへのパケットの転送を停止します。ホーム エージェントは、暗黙的なソースからのものか明示的なソースからのものかに関係なく、インストールしたルートをクリーンアップするために必要な情報をすべて保持する必要があります。
In Explicit mode, the Home Agent MUST ignore any Mobile Network Prefix Options present in the de-registration Binding Update.
Explicit モードでは、ホーム エージェントは登録解除バインディング アップデートに存在するモバイル ネットワーク プレフィックス オプションを無視しなければなりません (MUST)。
This document extends the Dynamic Home Agent Address Discovery (DHAAD) defined in [1] so that Mobile Routers only attempt registration with Home Agents that support them.
この文書は、参考文献 [1] で定義されている Dynamic Home Agent Address Discovery (DHAAD) を拡張し、モバイル ルータがサポートするホーム エージェントへの登録のみを試行するようにします。
A new flag (R) (Support for Mobile Routers) is introduced in the DHAAD Request message, defined in [1]. The Mobile Router sets this flag to indicate that it wants to discover Home Agents supporting Mobile Routers.
新しいフラグ (R) (モバイルルーターのサポート) が、[1] で定義された DHAAD 要求メッセージに導入されました。モバイル ルーターは、モバイル ルーターをサポートするホーム エージェントを検出したいことを示すためにこのフラグを設定します。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
モバイルルーターサポートフラグ(R)
A one-bit flag that when set indicates that the Mobile Router wants to discover Home Agents supporting Mobile Routers.
1 ビットのフラグ。設定すると、モバイル ルーターがモバイル ルーターをサポートするホーム エージェントを検出する必要があることを示します。
For a description of the other fields in the message, see [1].
メッセージの他のフィールドの説明については、[1] を参照してください。
A new flag (R) (Support for Mobile Routers) is introduced in the DHAAD Reply message, defined in [1]. If a Home Agent receives a Dynamic Home Agent Discovery request message with the Mobile Router Support Flag set, it MUST reply with a list of Home Agents supporting Mobile Routers. The Mobile Router Support Flag MUST be set if there is at least one Home Agent supporting Mobile Routers. If none of the Home Agents support Mobile Routers, the Home Agent MAY reply with a list of Home Agents that only support Mobile IPv6 Mobile Nodes. In this case, the Mobile Router Support Flag MUST be set to 0.
新しいフラグ (R) (モバイルルーターのサポート) が、[1] で定義された DHAAD 応答メッセージに導入されました。ホーム エージェントが、モバイル ルーター サポート フラグが設定された動的ホーム エージェント検出要求メッセージを受信した場合、モバイル ルーターをサポートするホーム エージェントのリストを返信しなければなりません (MUST)。モバイル ルーターをサポートするホーム エージェントが少なくとも 1 つある場合は、モバイル ルーター サポート フラグを設定しなければなりません。どのホーム エージェントもモバイル ルーターをサポートしていない場合、ホーム エージェントは、モバイル IPv6 モバイル ノードのみをサポートするホーム エージェントのリストで応答してもよい(MAY)。この場合、モバイル ルーター サポート フラグを 0 に設定する必要があります。
The modified message format is as follows.
変更後のメッセージフォーマットは以下の通りです。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
モバイルルーターサポートフラグ(R)
A one-bit flag that when set indicates that the Home Agents listed in this message support Mobile Routers.
1 ビットのフラグ。設定すると、このメッセージにリストされているホーム エージェントがモバイル ルーターをサポートしていることを示します。
For a description of the other fields in the message, see [1].
メッセージの他のフィールドの説明については、[1] を参照してください。
A new flag (R) (Support for Mobile Routers) is introduced in the Home Agent Information Option defined in [1]. If a Home Agent supports Mobile Routers, it SHOULD set the flag.
[1] で定義されたホーム エージェント情報オプションに新しいフラグ (R) (モバイル ルータのサポート) が導入されました。ホーム エージェントがモバイル ルーターをサポートする場合、フラグを設定する必要があります (SHOULD)。
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 |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
モバイルルーターサポートフラグ(R)
A one-bit flag that when set indicates that the Home Agent supports Mobile Routers.
1 ビットのフラグ。設定すると、ホーム エージェントがモバイル ルーターをサポートすることを示します。
For a description of the other fields in the message, see [1].
メッセージの他のフィールドの説明については、[1] を参照してください。
In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run an intra-domain routing protocol such as RIPng [12] and OSPF [13] through the bi-directional tunnel. The Mobile Router can continue running the same routing protocol that it ran when attached to the home link.
これまで説明したソリューションでは、ホーム エージェントがモバイル ルータからバインディング アップデートを受信したときに、ホーム エージェントでのモバイル ネットワークへの転送が設定されます。これに代わる方法は、ホーム エージェントとモバイル ルータが双方向トンネルを通じて RIPng [12] や OSPF [13] などのドメイン内ルーティング プロトコルを実行することです。モバイル ルーターは、ホーム リンクに接続されているときに実行したのと同じルーティング プロトコルを引き続き実行できます。
Support for running a intra-domain routing protocol is optional and is governed by the configuration on the Mobile Router and the Home Agent.
ドメイン内ルーティング プロトコルの実行のサポートはオプションであり、モバイル ルータとホーム エージェントの設定によって制御されます。
This feature is very useful when the Mobile Network is large with multiple subnets containing different IPv6 prefixes. Routing changes in the Mobile Network are quickly propagated to the Home Agent. Routing changes in the home link are quickly propagated to the Mobile Router.
この機能は、モバイル ネットワークが大規模で、異なる IPv6 プレフィックスを含む複数のサブネットがある場合に非常に役立ちます。モバイル ネットワークでのルーティングの変更は、すぐにホーム エージェントに伝達されます。ホーム リンクでのルーティングの変更は、すぐにモバイル ルーターに伝達されます。
When the Mobile Router is attached to the home link, it runs a routing protocol by sending routing updates through its egress interface. When the Mobile Router moves and attaches to a visited network, it should stop sending routing updates on the interface by which it attaches to the visited link. This reduces the chances that prefixes specific to the Mobile Network will be leaked to the visited network if routing protocol authentication is not enabled in the visited network and in the Mobile Network. It is expected that normal deployment practices will include proper authentication mechanisms to prevent unauthorized route announcements on both the home and visited networks. The Mobile Router then starts sending routing protocol messages through the bi-directional tunnel toward the Home Agent. Most routing protocols use link-local addresses as source addresses for the routing information messages. The Mobile Router is allowed to use link-local addresses for the inner IPv6 header of an encapsulated packet. But these MUST NOT be forwarded to another link by either the Mobile Router or the Home Agent.
モバイル ルータがホーム リンクに接続されている場合、その出力インターフェイスを介してルーティング アップデートを送信することにより、ルーティング プロトコルを実行します。モバイル ルータが移動して訪問先ネットワークに接続すると、訪問先リンクに接続するインターフェイスでのルーティング アップデートの送信を停止する必要があります。これにより、訪問先ネットワークおよびモバイル ネットワークでルーティング プロトコル認証が有効になっていない場合に、モバイル ネットワーク固有のプレフィックスが訪問先ネットワークに漏洩する可能性が低くなります。通常の展開方法には、ホーム ネットワークと訪問先ネットワークの両方での不正なルート アナウンスを防ぐための適切な認証メカニズムが含まれることが期待されます。次に、モバイル ルータは、双方向トンネルを介してホーム エージェントに向けてルーティング プロトコル メッセージの送信を開始します。ほとんどのルーティング プロトコルは、ルーティング情報メッセージの送信元アドレスとしてリンクローカル アドレスを使用します。モバイル ルータは、カプセル化されたパケットの内部 IPv6 ヘッダーにリンクローカル アドレスを使用できます。ただし、これらをモバイル ルータまたはホーム エージェントによって別のリンクに転送してはなりません (MUST NOT)。
When the Home Agent receives the inner packet, it processes the encapsulated routing protocol messages and updates its routing table accordingly. As part of normal routing protocol operation, the next hop information in these routing entries is filled with the Mobile Router's link-local address, with the outgoing interface set to the bi-directional tunnel.
ホーム エージェントは内部パケットを受信すると、カプセル化されたルーティング プロトコル メッセージを処理し、それに応じてルーティング テーブルを更新します。通常のルーティング プロトコル動作の一部として、これらのルーティング エントリのネクスト ホップ情報には、送信インターフェイスが双方向トンネルに設定されたモバイル ルータのリンクローカル アドレスが入力されます。
Similarly, the Home Agent sends routing updates through the bi-directional tunnel to the Mobile Router. The Mobile Router processes these routing protocol messages and updates its routing table. For all routes advertised by the Home Agent, the Mobile Router sets the outgoing interface to the bi-directional tunnel to the Home Agent.
同様に、ホーム エージェントはルーティング アップデートを双方向トンネル経由でモバイル ルーターに送信します。モバイル ルーターは、これらのルーティング プロトコル メッセージを処理し、ルーティング テーブルを更新します。ホーム エージェントによってアドバタイズされたすべてのルートについて、モバイル ルータは発信インターフェイスをホーム エージェントへの双方向トンネルに設定します。
When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router SHOULD NOT include Mobile Network Prefixes in the Binding Update to the Home Agent. Depending on its configuration, the Home Agent might not add routes based on the prefix information in the Binding Updates and might use only the routing protocol updates. Moreover, including prefix information in both the Binding Updates and the routing protocol updates is redundant.
モバイル ルータとホーム エージェントが動的ルーティング プロトコルを通じてルートを交換する場合、モバイル ルータはホーム エージェントへのバインディング アップデートにモバイル ネットワーク プレフィックスを含めるべきではありません (SHOULD NOT)。ホーム エージェントの設定によっては、バインディング アップデートのプレフィックス情報に基づいてルートを追加せず、ルーティング プロトコルのアップデートのみを使用する場合があります。さらに、バインディング アップデートとルーティング プロトコル アップデートの両方にプレフィックス情報を含めることは冗長です。
As the routing protocol messages from the Home Agent to the Mobile Router could potentially contain information about the internal routing structure of the home network, these messages require authentication and confidentiality protection. Appropriate authentication and confidentiality protection mechanisms, defined in [14], MUST be used. For protecting routing protocol messages by using IPsec ESP [4], the bi-directional tunnel between the Mobile Router and the Home Agent should be treated as the outgoing interface, with the Home Agent and Mobile Router's addresses as source and destination addresses for the inner encapsulated messages.
ホーム エージェントからモバイル ルーターへのルーティング プロトコル メッセージにはホーム ネットワークの内部ルーティング構造に関する情報が含まれる可能性があるため、これらのメッセージには認証と機密性の保護が必要です。[14] で定義されている適切な認証および機密性保護メカニズムを使用しなければなりません (MUST)。IPsec ESP [4] を使用してルーティング プロトコル メッセージを保護するには、モバイル ルータとホーム エージェント間の双方向トンネルを発信インターフェイスとして扱い、ホーム エージェントとモバイル ルータのアドレスを内部の送信元アドレスと宛先アドレスとして扱う必要があります。カプセル化されたメッセージ。
If a link state routing protocol such as OSPFv3 is run by the Mobile Router and the Home Agent, the recommendations in Appendix B should be followed.
OSPFv3 などのリンク ステート ルーティング プロトコルがモバイル ルータおよびホーム エージェントによって実行されている場合は、付録 B の推奨事項に従う必要があります。
All signaling messages between the Mobile Router and the Home Agent MUST be authenticated by IPsec [8]. The use of IPsec to protect Mobile IPv6 signaling messages is described in detail in the HA-MN IPsec specification [2]. The signaling messages described in this document extend Mobile IPv6 messages and do not require any changes to what is described in [2].
モバイル ルータとホーム エージェント間のすべてのシグナリング メッセージは、IPsec [8] によって認証されなければなりません (MUST)。モバイル IPv6 シグナリング メッセージを保護するための IPsec の使用については、HA-MN IPsec 仕様 [2] で詳細に説明されています。この文書で説明されているシグナリング メッセージはモバイル IPv6 メッセージを拡張したものであり、[2] で説明されているものを変更する必要はありません。
The Mobile Router has to perform ingress filtering on packets received from the Mobile Network to ensure that nodes in the Mobile Network do not use the bi-directional tunnel to launch IP spoofing attacks. In particular, the Mobile Router SHOULD check that the IP source addresses in the packets received belong to the Mobile Network Prefix and are not the same as one of the addresses used by the Mobile Router. If the Mobile Router receives an IP-in-IP tunneled packet from a node in the Mobile Network and it has to forward the decapsulated packet, it SHOULD perform the above mentioned checks on the source address of the inner packet.
モバイル ルーターは、モバイル ネットワーク内のノードが双方向トンネルを使用して IP スプーフィング攻撃を開始しないように、モバイル ネットワークから受信したパケットに対してイングレス フィルタリングを実行する必要があります。特に、モバイル ルータは、受信したパケット内の IP ソース アドレスがモバイル ネットワーク プレフィックスに属しており、モバイル ルータが使用するアドレスの 1 つと同じではないことを確認する必要があります (SHOULD)。モバイル ルータがモバイル ネットワーク内のノードから IP-in-IP トンネリングされたパケットを受信し、カプセル化解除されたパケットを転送する必要がある場合、内部パケットの送信元アドレスに対して上記のチェックを実行する必要があります (SHOULD)。
The Home Agent has to verify that packets received through the bi-directional tunnel belong to the Mobile Network. This check is necessary to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header MUST be set to the Mobile Router's current Care-of Address. The source address of the inner IPv6 header MUST be topologically correct with respect to the IPv6 prefixes used in the Mobile Network.
ホーム エージェントは、双方向トンネルを通じて受信したパケットがモバイル ネットワークに属していることを確認する必要があります。このチェックは、ノードがホーム エージェントを使用して攻撃を開始することを防ぐために必要です。このチェックは、そうでなければイングレス フィルタリングによって防止されるはずです。外側の IPv6 ヘッダーの送信元アドレスは、モバイル ルーターの現在の気付アドレスに設定する必要があります。内部 IPv6 ヘッダーのソース アドレスは、モバイル ネットワークで使用される IPv6 プレフィックスに関してトポロジー的に正しくなければなりません (MUST)。
If the Mobile Router sends a Binding Update with a one or more Mobile Network Prefix options, the Home Agent MUST be able to verify that the Mobile Router is authorized for the prefixes before setting up forwarding for the prefixes.
モバイル ルーターが 1 つ以上のモバイル ネットワーク プレフィックス オプションを含むバインディング アップデートを送信する場合、ホーム エージェントは、プレフィックスの転送を設定する前に、モバイル ルーターがそのプレフィックスに対して許可されていることを確認できなければなりません (MUST)。
When the Mobile Router runs a dynamic routing protocol as described in section 8, it injects routing update messages into the Home Link. As the routing protocol message could contain information about the internal routing structure of the home network, these messages require confidentiality protection. The Mobile Router SHOULD use confidentiality protection through IPsec ESP as described in [14]. If the bi-directional tunnel between the Mobile Router and the Home Agent is protected by ESP, in tunnel mode for all IP traffic, then no additional confidentiality protection specific to the routing protocol is required.
セクション 8 で説明されているように、モバイル ルータが動的ルーティング プロトコルを実行すると、ルーティング更新メッセージがホーム リンクに挿入されます。ルーティング プロトコル メッセージにはホーム ネットワークの内部ルーティング構造に関する情報が含まれる可能性があるため、これらのメッセージには機密性の保護が必要です。モバイルルーターは、[14] で説明されているように、IPsec ESP を介した機密保護を使用する必要があります (SHOULD)。モバイル ルータとホーム エージェント間の双方向トンネルが、すべての IP トラフィックのトンネル モードで ESP によって保護されている場合、ルーティング プロトコルに固有の追加の機密性保護は必要ありません。
Home Agents and Mobile Routers may use IPsec ESP to protect payload packets tunneled between themselves. This is useful to protect communications against attackers on the path of the tunnel.
ホーム エージェントとモバイル ルーターは、IPsec ESP を使用して、それらの間でトンネリングされるペイロード パケットを保護できます。これは、トンネルのパス上の攻撃者から通信を保護するのに役立ちます。
Please refer to the Mobile IPv6 specification [1] for security considerations when the Mobile Router operates as a Mobile Host.
モバイル ルータがモバイル ホストとして動作する場合のセキュリティに関する考慮事項については、モバイル IPv6 仕様 [1] を参照してください。
This document defines a new Mobility Header Option, the Mobile Network Prefix Option as described in section 4.3. The type value for this option MUST be assigned from the same space used by the mobility options defined in [1].
この文書は、セクション 4.3 で説明されているように、新しいモビリティ ヘッダー オプション、モバイル ネットワーク プレフィックス オプションを定義します。このオプションのタイプ値は、[1] で定義されたモビリティ オプションによって使用されるのと同じ空間から割り当てられなければなりません (MUST)。
This document also defines the following new Binding Acknowledgement status values. These status values are defined in section 4.2 and MUST be assigned from the same space used for Binding Acknowledgement status values in [1].
この文書では、次の新しいバインディング確認ステータス値も定義します。これらのステータス値はセクション 4.2 で定義されており、[1] のバインディング確認ステータス値に使用されるのと同じ空間から割り当てられなければなりません (MUST)。
- Mobile Router Operation not permitted - Invalid Prefix - Not Authorized for Prefix - Forwarding Setup failed (prefixes missing)
- モバイル ルーターの操作が許可されていません - 無効なプレフィックス - プレフィックスが許可されていません - 転送セットアップに失敗しました (プレフィックスがありません)
We would like to acknowledge Ludovic Bellier, Claude Castelluccia, Thierry Ernst [15], Miguel Catalina-Gallego, Christophe Janneteau, T.J. Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Alexis Olivereau, Charles E. Perkins, and Keisuke Uehara for their work on earlier proposals for Network Mobility. This document has inherited a lot of ideas from these proposals.
Ludovic Bellier、Claude Castelluccia、Thierry Ernst [15]、Miguel Catalina-Gallego、Christophe Janneteau、T.J. に感謝の意を表します。ネットワーク モビリティの以前の提案に関する取り組みについては、Kniveton、Hong-Yon Lach、Jari T. Malinen、Koshiro Mitoya、Alexis Olivereau、Charles E. Perkins、および Keisukeuehara に感謝します。この文書は、これらの提案から多くのアイデアを継承しています。
We thank all members of the NEMO Working Group, and of the preceding MONET BoF, for fruitful discussions on the mailing list and at IETF meetings.
メーリング リストや IETF 会議で有意義な議論をしていただいた NEMO ワーキング グループおよび前任の MONET BoF のメンバー全員に感謝します。
Kent Leung, Marco Molteni, and Patrick Wetterwald are acknowledged for their work on Network Mobility for IPv4 and IPv6.
Kent Leung、Marco Molteni、および Patrick Wetterwald は、IPv4 および IPv6 のネットワーク モビリティに関する業績で知られています。
Tim Leinmueller is acknowledged for many insightful remarks and for section 7.
ティム・ラインミュラーは、多くの洞察力に富んだ発言とセクション 7 で知られています。
Jari Arkko, James Kempf, Chan-Wah Ng, and Erik Nordmark are acknowledged for their thorough review and comments.
Jari Arkko 氏、James Kempf 氏、Chan-Wah Ng 氏、Erik Nordmark 氏の徹底的なレビューとコメントが認められています。
Souhwan Jung, Fan Zhao, S. Felix Wu, HyunGon Kim, and SungWon Sohn are acknowledged for identifying threats related to tunneling between the Mobile Network and the Home Agent.
Sohwan Jung、Fan Zhao、S. Felix Wu、HyunGon Kim、および SungWon Sohn は、モバイル ネットワークとホーム エージェント間のトンネリングに関連する脅威を特定したことで知られています。
[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] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[2] Arkko, J.、Devarapalli, V.、および F. Dupont、「Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents」、RFC 3776、2004 年 6 月。
[3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[3] Conta, A. および S. Deering、「IPv6 仕様における汎用パケット トンネリング」、RFC 2473、1998 年 12 月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] Kent, S. および R. Atkinson、「IP カプセル化セキュリティ ペイロード (ESP)」、RFC 2406、1998 年 11 月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering, S. および R. Hinden、「インターネット プロトコル バージョン 6 (IPv6) 仕様」、RFC 2460、1998 年 12 月。
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Narten, T.、Nordmark, E.、および W. Simpson、「IP バージョン 6 (IPv6) の近隣探索」、RFC 2461、1998 年 12 月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
[9] Manner, J. and M. Kojo, Eds., "Mobility Related Terminology", RFC 3753, June 2004.
[9] Manner, J. および M. Kojo 編、「モビリティ関連用語」、RFC 3753、2004 年 6 月。
[10] Ernst, T., and H.-Y. Lach, "Network Mobility Support Terminology", Work in Progress, October 2004.
[10] エルンスト、T.、H.-Y.Lach、「Network Mobility Support Terminology」、進行中の作業、2004 年 10 月。
[11] Ernst, T., "Network Mobility Support Goals and Requirements", Work in Progress, October 2004.
[11] Ernst, T.、「ネットワーク モビリティ サポートの目標と要件」、進行中の作業、2004 年 10 月。
[12] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[12] Malkin, G. および R. Minnear、「IPv6 の RIPng」、RFC 2080、1997 年 1 月。
[13] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[13] Coltun, R.、Ferguson, D.、および J. Moy、「IPv6 用の OSPF」、RFC 2740、1999 年 12 月。
[14] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", Work in Progress, December 2004.
[14] Gupta, M. および N. Melam、「OSPFv3 の認証/機密性」、進行中の作業、2004 年 12 月。
[15] Ernst, T., "Network Mobility Support in IPv6", PhD Thesis, University Joseph Fourier, Grenoble, France. October 2001.
[15] Ernst, T.、「IPv6 におけるネットワーク モビリティ サポート」、博士論文、ジョゼフ フーリエ大学、グルノーブル、フランス。2001 年 10 月。
[16] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[16] Moy, J.、「デマンド回線をサポートするための OSPF の拡張」、RFC 1793、1995 年 4 月。
[17] Thubert, P., et al., "NEMO Home Network models", Work in Progress, October 2004.
[17] Thubert, P. 他、「NEMO ホーム ネットワーク モデル」、進行中の作業、2004 年 10 月。
This section tries to illustrate the NEMO protocol by using a Mobile Router and a Mobile Node belonging to different administrative domains. The Mobile Router's Mobile Network consists of a Local Fixed Node (LFN) and a Local Fixed Router (LFR) [10]. The LFR has an access link to which other Mobile Nodes or Mobile Routers could attach.
このセクションでは、異なる管理ドメインに属するモバイル ルーターとモバイル ノードを使用して NEMO プロトコルを説明します。モバイル ルーターのモバイル ネットワークは、ローカル固定ノード (LFN) とローカル固定ルーター (LFR) で構成されます [10]。LFR には、他のモバイル ノードまたはモバイル ルーターが接続できるアクセス リンクがあります。
Figure 1 depicts the scenario where both the Mobile Router and the Mobile Node are at home.
図 1 は、モバイル ルーターとモバイル ノードの両方が自宅にあるシナリオを示しています。
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ +-------------------+ +-------+
4:: |
|
2+-------------+3
+--+-+ +---+---+
| MR | | HA_MR |
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------
Figure 1. Mobile Router and Mobile Node at home.
図 1. 自宅のモバイル ルーターとモバイル ノード。
The Mobile Router then moves away from the home link and attaches to a visited link. This is shown in Figure 2. The Mobile Router sends a Binding Update to HA_MR when it attaches to a visited link and configures a Care-of Address. HA_MR creates a binding cache entry for the Mobile Router's Home Address and also sets up forwarding for the prefixes on the Mobile Network.
その後、モバイル ルータはホーム リンクから離れ、訪問先リンクに接続します。これを図 2 に示します。モバイル ルータは、訪問先リンクに接続して気付アドレスを構成するときに、バインディング アップデートを HA_MR に送信します。HA_MR は、モバイル ルーターのホーム アドレスのバインディング キャッシュ エントリを作成し、モバイル ネットワーク上のプレフィックスの転送も設定します。
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
| 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------
Figure 2. Mobile Router on a visited link.
図 2. 訪問先リンク上のモバイル ルーター。
Figure 3 shows the Mobile Node moving away from its home link and attaching to the Mobile Router. The Mobile Node configures a Care-of Address from the prefix advertised on the Mobile Network and sends a Binding Update to its Home Agent (HA_MN) and to its Correspondent Node (CN_MN). Both HA_MN and CN_MN create binding cache entries for the Mobile Node's Home Address.
図 3 は、モバイル ノードがホーム リンクから離れ、モバイル ルーターに接続する様子を示しています。モバイル ノードは、モバイル ネットワーク上でアドバタイズされたプレフィックスから気付アドレスを構成し、バインディング アップデートをホーム エージェント (HA_MN) と通信先ノード (CN_MN) に送信します。HA_MN と CN_MN は両方とも、モバイル ノードのホーム アドレスのバインディング キャッシュ エントリを作成します。
+-------+
| HA_MN | 1::2->6::2
1:: +---+---+
---------|3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
1::2->6::2 | 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
--------+-
|2
+--+-+
| MN |
+----+
Figure 3. Mobile Node attached to Mobile Router on a visited link
図 3. 訪問先リンク上のモバイル ルーターに接続されたモバイル ノード
The bi-directional tunnel between the Mobile Router and the Home Agent is used as a virtual interface over which routing protocol messages are exchanged. When a link state routing protocol is run, the following recommendations should be followed.
モバイル ルータとホーム エージェント間の双方向トンネルは、ルーティング プロトコル メッセージが交換される仮想インターフェイスとして使用されます。リンク ステート ルーティング プロトコルを実行する場合は、次の推奨事項に従う必要があります。
If the tunnel interface goes up and down every time the Mobile Router moves to a new visited network with a high level of mobility and a sufficient number of Mobile Routers, the amount of interface state changes will adversely affect the Home Agent's performance. This also introduces a high level of instability in the home network. To avoid this, the following should be considered when the bi-directional tunnel is implemented:
モバイル ルータが高レベルのモビリティと十分な数のモバイル ルータを備えた新しい訪問先ネットワークに移動するたびにトンネル インターフェイスが上下する場合、インターフェイス状態の変化量がホーム エージェントのパフォーマンスに悪影響を及ぼします。これにより、ホーム ネットワークに高度な不安定性が生じます。これを回避するには、双方向トンネルを実装するときに次の点を考慮する必要があります。
- A tunnel interface is consistently assigned to each Mobile Router, as long as it has a valid binding cache at the Home Agent.
- トンネル インターフェイスは、ホーム エージェントに有効なバインディング キャッシュがある限り、各モバイル ルータに一貫して割り当てられます。
- Every time the Mobile Router moves and updates the binding cache entry, the bi-directional tunnel should not be torn down and set up again. The tunnel end points should be updated dynamically with the Mobile Router's current Care-of Address.
- モバイル ルータが移動してバインディング キャッシュ エントリを更新するたびに、双方向トンネルを破棄して再度セットアップする必要はありません。トンネルのエンドポイントは、モバイル ルータの現在の気付アドレスで動的に更新される必要があります。
- With a large number of interfaces, Hello packet processing may become a burden. Therefore, the tunnel interface should be treated as On-Demand circuits for OSPF [16].
- インターフェイスの数が多いと、Hello パケットの処理が負担になる場合があります。したがって、トンネル インターフェイスは OSPF のオンデマンド回線として扱う必要があります [16]。
The following should be considered when the Home Network is configured for running OSPF:
ホーム ネットワークが OSPF を実行するように構成されている場合は、次の点を考慮する必要があります。
- The entire Home domain SHOULD NOT be configured as a single area if a Home Agent supports Mobile Routers. At least the home network should be configured as a separate area.
- ホーム エージェントがモバイル ルーターをサポートする場合、ホーム ドメイン全体を単一のエリアとして設定すべきではありません (SHOULD NOT)。少なくともホーム ネットワークは別のエリアとして構成する必要があります。
- The bi-directional tunnel interfaces to the Mobile Routers should never be included in the same area as the backbone links.
- モバイル ルータへの双方向トンネル インターフェイスは、バックボーン リンクと同じエリアに含めないでください。
For a more detailed discussion on configuring a home network for NEMO Basic Support, please see [17].
NEMO 基本サポート用のホーム ネットワークの構成に関する詳細については、[17] を参照してください。
One disadvantage of running OSPFv3 with NEMO Basic Support is the possibility that the Mobile Networks will be told of the topology of the entire home network, including all the fixed and Mobile Routers. The only thing the Mobile Routers might really need is a default route through the Home Agent.
NEMO 基本サポートで OSPFv3 を実行する場合の欠点の 1 つは、すべての固定ルータとモバイル ルータを含むホーム ネットワーク全体のトポロジがモバイル ネットワークに通知される可能性があることです。モバイル ルーターが本当に必要とするのは、ホーム エージェントを経由するデフォルト ルートだけです。
To reduce the amount of routing protocol messages received by a Mobile Router, one can configure each bi-directional tunnel to a Mobile Router as a separate area. But this requires that the Home Agent support a large number of OSPF areas if it supports a large number of Mobile Routers, and it might not be possible with most router implementations.
モバイル ルーターが受信するルーティング プロトコル メッセージの量を減らすために、モバイル ルーターへの各双方向トンネルを個別のエリアとして設定できます。ただし、これには、ホーム エージェントが多数のモバイル ルーターをサポートする場合、多数の OSPF エリアをサポートする必要があり、ほとんどのルーター実装では不可能である可能性があります。
Another option is to configure multiple areas on the Home Link and group a number of Mobile Routers into each area. This reduces the number of areas that a Home Agent needs to support but also reduces the amount of routing protocol traffic that a Mobile Router receives.
もう 1 つのオプションは、ホーム リンク上に複数のエリアを設定し、多数のモバイル ルータを各エリアにグループ化することです。これにより、ホーム エージェントがサポートする必要があるエリアの数が減りますが、モバイル ルータが受信するルーティング プロトコル トラフィックの量も減ります。
Authors' Addresses
著者の住所
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
EMail: vijay.devarapalli@nokia.com
Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan
Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan
EMail: ryuji@sfc.wide.ad.jp
Alexandru Petrescu Motorola Labs Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France
Alexandru Petrescu Motorola Labs Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France
EMail: Alexandru.Petrescu@motorola.com
Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 France
Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 France
EMail: pthubert@cisco.com
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、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 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。