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
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.
このドキュメントはインターネットで異なるポイントに接続するモバイルネットワークを可能にするネットワークモビリティ（NEMO）基本サポートプロトコルを記述します。プロトコルは、モバイルIPv6の拡張であり、ネットワークが移動するようなモバイルネットワーク内のすべてのノードのセッション継続性を可能にします。また、周りに移動しながら、移動ネットワーク内のすべてのノードが到達可能にすることができます。インターネットにネットワークを接続するモバイルルータは、そのホームエージェントとのNEMOベーシックサポートプロトコルを実行します。プロトコルは、ネットワークモビリティモバイルネットワーク内のノードに透過的であるように設計されています。
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.
この文書では、[1]ネットワークモビリティのサポートを可能にするために、モバイルIPv6（MIPv6の）へのプロトコル拡張を記述しています。拡張子は、モバイル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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります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.
モバイルネットワークが移動し、ルーティングインフラストラクチャ内の任意の点に接続できるネットワークセグメントまたはサブネットです。モバイルネットワークは、その動きを管理するモバイルルータと呼ばれる特定のゲートウェイを介してアクセスすることができます。モバイルネットワークは、少なくとも一つのモバイルルータがそれらを提供しています。モバイルルータ（すなわち、訪問先ネットワークにおける）アタッチメントのそのポイントでインフラストラクチャにモバイルネットワークルートを配布しません。代わりに、インフラへのモバイルネットワークの集約をアドバタイズホームエージェントへの双方向トンネルを維持します。モバイルルータはまた、モバイルネットワークのデフォルトゲートウェイです。
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節で説明したモードのいずれかを使用してバインディングアップデートでのモバイルネットワークプレフィックスに関する情報を含むことができます。プレフィックス情報を運ぶための新しいモビリティヘッダオプションは、セクション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
ホームエージェントは、モバイルルータへの結合確認応答を送信することにより、バインディング更新を認めています。モバイルルータ旗（R）が設定された肯定応答は、ホームエージェントは、モバイルネットワークのための転送を設定していることを意味します。結合処理が終了すると、双方向トンネルは、ホームエージェントとモバイルルータとの間で確立されます。トンネルエンドポイントは、モバイルルータの気付アドレスとホームエージェントのアドレスです。モバイルネットワークプレフィックスに属する送信元アドレスを持つパケットは、モバイルネットワークから受信された場合、モバイルルータがこのトンネルを経由し、ホームエージェントへのパケットのトンネルを逆転します。この逆トンネリングは、IP-in-IPカプセル化[3]を使用して行われます。ホーム
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].
エージェントは、このパケットのカプセル化を解除し、相手ノードに転送します。 [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に設定されている場合は、ホームエージェントは、モバイルルータは、モバイルノードとして動作していることを前提としていて、それがモバイルルータへのモバイルネットワーク宛てのパケットを転送してはなりません。
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].
ゼロまたはそれ以上のモビリティオプションを含めることができ可変長フィールド。この文書では、[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.
この文書はまた、次の新しいバインディング応答ステータス値が導入されました。以下に示す値は、小数点以下の値です。
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.
モバイルネットワークプレフィックスオプションは、ホームエージェントにモバイルネットワークのプレフィックス情報を示すために、バインディングアップデートに含まれています。モバイルルータは、モバイルネットワーク内の1つの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
６
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].
モバイルルータの動作は、[1]ルータの[5]、及び移動ノードの、ホストの合成挙動から大きく誘導されます。
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).
ホームエージェントは、モバイルホストのホームアドレスに関連するプレフィックス情報を保持しませんが、モバイルホストのホームに関連するバインディングキャッシュエントリを維持しない、その場合には、モバイルホストとして（1）：モバイルノードは、2つの方法で行動することができますアドレス、及び（2）の場合には、モバイルルータのホームアドレスに対応するバインディング・キャッシュ・エントリを維持することに加えて、ホームエージェントは、モバイルネットワークに割り当てられたプレフィックスに関連する転送情報を維持するモバイルルータ、など。 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モバイルノードに対するすべての要件を実装しなければなりません。
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.
モバイルルータは、少なくとも一つのモードを実装しなければならないとの両方を実施することができます。後者の場合、モバイルルータのローカルコンフィギュレーションは、使用するモードを決定します。これはこの文書の範囲外です。
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）のためのバインディングキャッシュ内の値と同じ値を持つ必要があります。明示モードでは、モバイルルータは、それが対応するモバイルネットワークプレフィックスのために有効に転送したい場合、既存のバインディングキャッシュエントリをリフレッシュするために送られたものも含め、すべてのバインディングアップデートでプレフィックス情報を含まなければなりません。
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に設定されている場合（Updateが受け入れバインド）とモバイルルータフラグ（R）が1に設定されている、モバイルルータは、ホームエージェントが正常にバインディング更新を処理しており、モバイルネットワークのための転送を設定していることを前提としてい。モバイルルータは、次にモバイルネットワークからのトラフィックのトンネル逆に双方向トンネルを使用して開始することができます。モバイルルータフラグ（R）が設定されていない場合、モバイルルータは、現在のホームエージェントは、モバイルルータをサポートしていないと結論し、それがダイナミックホームエージェントが行うホームエージェントを発見するために、再度ディスカバリーアドレス実行します。モバイルルータは、別の登録をしようとする前にそれをサポートしていませんでしたホームエージェントに登録を解除しなければなりません。
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.
暗黙モードでは、モバイルルータのみにエラーが140ステータス解釈（モバイルルータの動作は許可されていない）および143（転送セットアップが失敗しました）。モバイルルータは、ステータス「141」と、彼らは暗黙のモードでホームエージェントによって送信されるべきではありませんので、「142」などの致命的なエラー、との結合謝辞を扱わなければなりません。
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を持っている場合は、モバイルルータは、同じホームリンクの上に別のホームエージェントにバインディングアップデートを送信すべきです。何のホームエージェントは、積極的に返信しない場合は、モバイルルータは、モバイルルータフラグがホームリンク上の任意のホームエージェントに設定してバインディングアップデートを送信することは控えなければならず、情報をログに記録しなければなりません。
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を持っている場合は、モバイルルータは、同じホームリンクの上に別のホームエージェントにバインディングアップデートを送信すべきです。何のホームエージェントは、積極的に返信しない場合は、モバイルルータは、ホームリンク上の任意のホームエージェントに、このバインディングアップデートを送信することを控えるべきである、と同じホームリンク上のホームエージェントに明示的なモードでのバインディングアップデートを送信することができます。
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」との結合謝辞を扱わなければなりません。
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を持っている場合は、モバイルルータは、同じホームリンクの上に別のホームエージェントにバインディングアップデートを送信すべきです。何のホームエージェントは、積極的に返信しない場合は、モバイルルータは、モバイルルータフラグがホームリンク上の任意のホームエージェントに設定してバインディングアップデートを送信することは控えなければならず、情報をログに記録しなければなりません。
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を持っている場合は、モバイルルータは、同じホームリンクの上に別のホームエージェントにバインディングアップデートを送信すべきです。何のホームエージェントは、積極的に返信しない場合は、モバイルルータは、ホームリンク上の任意のホームエージェントにバインディングアップデートを送信することを控えるべきです。モバイルルータはまた、モバイルネットワークのプレフィックスのアドバタイズを停止し、モバイルネットワークのための新しいIPv6プレフィックス情報を取得しようとする必要があります。それは最初に、現在のモバイルネットワークプレフィックスを割り当てられてしまった同じ手段でこれを行うだろう。また、モバイルルータは、同じホームリンク上のホームエージェントに暗黙モードでのバインディングアップデートを送信することができます。
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.
上記のすべての場合において、モバイルルータは、ホームエージェントは、モバイルルータのホームアドレスのバインディングキャッシュエントリを作成していないと結論しなければなりません。
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に記載されているように双方向トンネルは、2つの単方向トンネルをマージすることによって作成された[3]。ホームエージェントへのモバイルルータからトンネルは、トンネルエントリポイントとトンネル出口ポイントとしてホームエージェントのアドレスとして気付モバイルルータのアドレスを持っています。モバイルルータのホームエージェントからのトンネルは、ホームエージェントのアドレスとモバイルルータの気付アドレストンネルエントリポイントと出口ポイントとして、それぞれを持っています。移動ネットワークからのすべての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.
モバイルルータがホームにある場合は、ルータ広告を送信するには、ホームリンクに接続されたインターフェイス上のルータ要請に返答するように構成され得ます。ルータ寿命フィールドの値は、デフォルトルータとしてモバイルルータの設定から他のノードを防止するために0に設定されるべきです。
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.
モバイルルータは、迷惑ルータ広告を送るべきではありませんし、そのインターフェイスが訪れたリンクに接続されたときにすべての出力インターフェイス上のルータ要請に答えるべきではありません。しかし、モバイルルータは、近隣要請に近隣広告で応答すべきで訪問したリンク上で有効なアドレスについては、出力インターフェイスで受信しました。
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.
ルータは通常、リンク上の他のルータによって送信されたルータ広告を無視します。しかし、モバイルルータは、ルータ広告は出力インターフェイス上で受信無視してはいけません。受け取ったルータ広告は、アドレス設定、デフォルトルータの選択、または動き検出のために使用されるかもしれません。
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リンクローカルアドレスで。訪問先ネットワークに、モバイルルータは、対応するインターフェイス上で上記のマルチキャストグループに参加してはならないとき。
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:
モバイルルータは、それがそのホームリンクに戻ったことを検出すると、そのホームエージェントに登録解除しなければなりません。モバイルルータは、[1]内のモバイル・ノードに対して定義された戻り、ホーム・プロシージャを実装し、従わなければなりません。また、モバイルルータは、次のように、特に、その出力インターフェイス上のルータとして動作し始めることがあります：
- 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に設定する必要があります。
- The Mobile Router MAY join the All Routers Address multicast group on the home link.
- モバイルルータは、ホームリンク上のすべてのルータアドレスのマルチキャストグループに参加することができます。
- The Mobile Router MAY send routing protocol messages on its egress interface if it is configured to run a dynamic routing protocol.
- ダイナミックルーティングプロトコルを実行するように構成されている場合、モバイルルータは、出力インターフェイスにルーティングプロトコルメッセージを送信することができます。
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.
モバイルルータは、明示的なモードで登録解除バインディングアップデートを送信するときに、バインディングアップデートで任意のモバイルネットワークプレフィックスオプションを含めるべきではありません。ホームエージェントはバインディングキャッシュエントリを削除すると、それはすべての関連したモバイルネットワークプレフィックスのルートを削除します。
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で説明した両方のモードを実装しなければなりません。
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.
ホームエージェントはまた、Binding Cacheエントリーでモバイルルータフラグ（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.
ホームエージェントは、他のモバイルルータに属するモバイルネットワークプレフィックスを主張するモバイルルータを阻止することができるべきです。それはプレフィックステーブルを維持し、プレフィックステーブルエントリに対して、モバイルルータが提供するプレフィックス情報を確認する場合は、ホームエージェントは、このような攻撃を防ぐことができます。それが明示モードでのバインディングアップデートを処理するときに接頭辞表は、ホームエージェントによって使用されるべきです。ダイナミックルーティングプロトコルは、モバイルルータとホームエージェントとの間で実行されるときには必要ありません。
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に記載されているように、ホーム・エージェントは、結合更新を処理します。モバイルルータ（R）フラグが設定されている場合は、このセクションでは、バインディング更新の処理を説明します。ホームエージェントは、次のチェックを行います。
- 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.
- [1]モバイルIPv6仕様は、バインディングアップデートでホームアドレスはホームリンクで宣伝プレフィックスから構成されていることが必要です。そうでない場合は結合更新は、状態値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）を設定するバインディング更新している場合ならば、ホームエージェントはバインディングを拒絶しなければなりませんアップデートは、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).
- モバイルネットワークプレフィックスオプションバインディング更新中に存在する場合、モバイルネットワークプレフィックスのプレフィックス情報は、モバイルネットワークプレフィックスフィールドとオプションのプレフィックス長フィールドから取り出されます。バインディング更新が複数のオプションが含まれている場合は、ホームエージェントは、すべてのモバイルネットワークプレフィックスのための転送を設定する必要があります。ホームエージェントはバインディング・アップデートに記載されているすべてのプレフィックスへの転送設定に失敗した場合、それは、プレフィックスのいずれかにトラフィックを転送してはなりません。また、バインディングアップデートを拒否し、141（無効プレフィックス）に設定された状態との結合肯定応答を送信しなければなりません。
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に設定された状態との結合謝辞を送らなければなりません。
- 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に設定された状態でバインディング受信確認を送らなければなりません（転送の設定に失敗しました）。
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.
ホームエージェントは、モバイルルータのための有効なバインディングキャッシュエントリがある場合、それは、バインディングキャッシュエントリに保存されたプレフィックスに対するバインディングアップデートにプレフィックスのリストを比較する必要があります。バインディングキャッシュエントリがバインディングアップデートに表示されていない接頭辞が含まれている場合は、ホームエージェントは、これらのモバイルネットワークプレフィックスの転送を無効にする必要があります。
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.
すべてのチェックが渡された場合は、ホームエージェントは、モバイルルータのホームアドレスのバインディングキャッシュエントリを作成するか、それが既に存在する場合は、エントリを更新します。それ以外の場合は、ホームエージェントは、モバイルルータのホームアドレスのバインディングを登録してはなりません。
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.
ホームエージェントは、モバイルネットワーク宛のデータパケットを受信すると、双方向トンネルを通じてモバイルルータにパケットを転送しなければなりません。ホームエージェントは、ルーティングテーブル、バインディングキャッシュ、またはモバイルネットワークにパケットをルーティングする組み合わせのいずれかを使用しています。これは実装固有のものです。 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.ホームエージェントは、ホーム・エージェントとモバイルルータとの間の双方向トンネルインターフェイスに設定発信インターフェイスとモバイルネットワークプレフィックスへのルートを維持します。この目的のために、ホームエージェントは、トンネルインターフェースと、このトンネルを扱わなければなりません。パケットがトンネルインターフェースを介して転送される場合、それらはそれぞれ、ホームエージェントのアドレスと、モバイルルータの気付アドレスに設定され、外側の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.
一の以上のプレフィックスは、バインディングアップデートで受信した場合は無効であり、ホームエージェントはプレフィックスのための転送を設定することはできません、ホームエージェントは、モバイルルータにこれを示すために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.
明示的なモードでは、ホームエージェントは、登録解除バインディングアップデートで任意のモバイルネットワークプレフィックスオプション存在を無視しなければなりません。
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]で定義されたディスカバリー（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）（モバイルルータのサポートは）で定義され、DHAAD要求メッセージに導入された[1]。モバイルルータは、モバイルルータをサポートするホームエージェントを発見したいことを示すために、このフラグを設定します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 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）（モバイルルータのサポートは）で定義され、DHAAD応答メッセージに導入されている[1]。ホームエージェントは、モバイルルータサポート旗セットでダイナミックなホームエージェント発見要求メッセージを受信した場合、それはモバイルルータをサポートするホームエージェントのリストで返答しなければなりません。モバイルルータをサポートしている少なくとも一つのホームエージェントがある場合はモバイルルータサポート旗を設定しなければなりません。ホームエージェントのいずれもモバイルルータをサポートしていない場合は、ホームエージェントは、モバイルIPv6モバイルノードをサポートするホームエージェントのリストで応答することができます。この場合、モバイルルータサポート旗は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.
新しいフラグ（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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ヘッダのためのリンクローカルアドレスを使用することができます。しかし、これらはモバイルルータまたはホームエージェントのいずれかによって別のリンクに転送してはなりません。
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.
場合モバイルルータとホームエージェント交換ルート動的ルーティングプロトコルを介して、モバイルルータは、ホームエージェントに結合更新にモバイルネットワークプレフィックスを含むべきではありません。その構成に応じて、ホームエージェントはバインディングアップデートにプレフィックス情報に基づいてルートを追加していない可能性があり、唯一のルーティングプロトコルのアップデートを使用する場合があります。また、結合更新とルーティングプロトコルの更新の両方を含めプレフィックス情報は冗長です。
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]で定義された適切な認証および機密保護機構は、使用しなければなりません。 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]。モバイル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送信元アドレスがモバイルネットワークプレフィックスに属し、モバイルルータによって使用されるアドレスのいずれかと同じではないことを確認する必要があります。モバイルルータは、モバイルネットワーク内のノードからIPインIPトンネル化パケットを受信し、デカプセル化パケットを転送する必要がある場合は、上記インナパケットの送信元アドレスにチェックを挙げる実行する必要があります。
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プレフィックスに対してトポロジー的に正しくなければなりません。
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つまたは複数のモバイルネットワークプレフィックスオプションを使用してバインディングアップデートを送信した場合、ホームエージェントは、プレフィックスの転送を設定する前に、モバイルルータがプレフィックスのために認可されていることを確認することができなければなりません。
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を介して機密保護を使用すべきです。モバイルルータとホームエージェントとの間の双方向トンネルはESPによって保護されている場合は、すべてのIPトラフィック用のトンネルモードでは、ルーティングプロトコルに固有の追加の機密保護が必要とされません。
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]で定義されたモビリティ・オプションで使用されるのと同じ空間から割り当てられなければなりません。
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]に応答ステータス値をバインドするために使用されるのと同じ空間から割り当てられなければなりません。
- 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.
私たちは、ルドビクBellier、クロードカステルッシア、ティエリーエルンスト[15]、ミゲル・カタリナ・ガジェゴ、クリストフJanneteau、T.J.を確認したいと思いますKniveton、ホン・ヨンLACH、ヤリT. Malinen、幸四郎三ツ矢、アレクシスOlivereau、チャールズE.パーキンス、および啓介上原ネットワークモビリティのための以前の提案に自分の仕事のために。この文書では、これらの提案からたくさんのアイデアを継承しています。
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.
私たちは、NEMOワーキンググループのすべてのメンバーに感謝し、そして前のMONETのBoFの、メーリングリストで実りある議論のためとIETF会合で。
Kent Leung, Marco Molteni, and Patrick Wetterwald are acknowledged for their work on Network Mobility for IPv4 and IPv6.
ケントレオン、マルコMolteni、とパトリックWetterwaldは、IPv4とIPv6のネットワークモビリティ上の自分の仕事のために認めています。
Tim Leinmueller is acknowledged for many insightful remarks and for section 7.
ティムLeinmuellerは、多くの洞察に満ちた発言のためとセクション7のために認められています。
Jari Arkko, James Kempf, Chan-Wah Ng, and Erik Nordmark are acknowledged for their thorough review and comments.
ヤリArkko、ジェームズ・ケンプ、チャン・ワウン、およびエリック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.
Souhwanユング、ファン趙、S.フェリックス・ウー、HyunGonキム、そしてSungWon孫は、モバイルネットワークとホームエージェント間のトンネルに関連する脅威を識別するために認めています。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] 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.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月を。
[3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[3]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5]デアリング、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.シンプソン、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[9] Manner, J. and M. Kojo, Eds., "Mobility Related Terminology", RFC 3753, June 2004.
[9]マナー、J.とM.古城、編、 "モビリティ関連用語"、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、「ネットワークモビリティサポート用語」、進歩、2004年10月に作業。
[11] Ernst, T., "Network Mobility Support Goals and Requirements", Work in Progress, October 2004.
エルンスト、T.、「ネットワークモビリティサポートの目標と要件」、進歩、2004年10月に作業[11]。
[12] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[12]マルキン、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.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[14] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", Work in Progress, December 2004.
[14]グプタ、M.およびN.メラム、 "OSPFv3のための認証/機密性"、進歩、2004年12月に作業。
[15] Ernst, T., "Network Mobility Support in IPv6", PhD Thesis, University Joseph Fourier, Grenoble, France. October 2001.
[15]エルンスト、T.、「IPv6におけるネットワークモビリティサポート」、博士論文、大学のジョセフ・フーリエ、グルノーブル、フランス。 2001年10月。
[16] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[16]モイ、J.、RFC 1793、1995年4月 "オンデマンド・サーキットをサポートするためのOSPFの拡張"。
[17] Thubert, P., et al., "NEMO Home Network models", Work in Progress, October 2004.
[17] Thubert、P.ら、 "NEMOホームネットワークモデル"、進歩、2004年10月に作業。
Appendix A. Examples of NEMO Basic Support Operation
NEMOベーシックサポート操作の付録A.例
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.
モバイルルータは、ホームリンクから離れて移動し、訪れたリンクに接続します。これは、モバイルルータは、それが訪問したリンクに接続するときHA_MRするバインディングアップデートを送信し、気付アドレス設定し、図2に示されています。 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
Appendix B. Running Link State Routing Protocol with NEMO Basic Support
NEMOベーシックサポートとリンクステートルーティングプロトコルを実行付録B.
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.
モバイルルータとホームエージェントとの間の双方向トンネルは、ルーティング・プロトコル・メッセージが交換され、その上の仮想インターフェースとして使用されます。リンクステートルーティングプロトコルを実行すると、以下の推奨事項に従ってください。
B.1. Tunnel Interface Considerations
B.1。トンネルインターフェイスの考慮事項
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].
- インターフェイスの多数で、ハローパケットの処理が負担になることができます。したがって、トンネルインターフェイスはOSPF [16]のためのオンデマンド回路として扱われるべきです。
B.2. OSPF Area Considerations
B.2。 OSPFエリアの考慮事項
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.
- ホームエージェントは、モバイルルータをサポートしている場合、全体のホームドメインは、単一の領域として設定しないでください。少なくとも、ホームネットワークは、独立した領域として設定する必要があります。
- 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を実行しているの一つの欠点は、モバイルネットワークは、すべての固定およびモバイルルータを含む、ホームネットワーク全体のトポロジを告げてしまう可能性があります。モバイルルータが本当に必要な場合があります唯一の事はホームエージェント経由のデフォルトルートです。
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.
別のオプションは、各エリアにホームリンクとグループでモバイルルータの数を複数の領域を設定することです。これは、ホームエージェントがサポートする必要がある領域の数を減らすだけでなく、モバイルルータは、受信したルーティングプロトコルトラフィックの量を減らすことができます。
Authors' Addresses
著者のアドレス
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
ビジェイDevarapalliノキア・リサーチセンター313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
EMail: vijay.devarapalli@nokia.com
メールアドレス：vijay.devarapalli@nokia.com
Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan
りゅじ わきかわ けいお うにゔぇｒしｔｙ あんｄ うぃで ５３２２ えんど ふじさわ かながわ ２５２ー８５２０ じゃぱん
EMail: ryuji@sfc.wide.ad.jp
メールアドレス：ryuji@sfc.wide.ad.jp
Alexandru Petrescu Motorola Labs Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France
アレクサンドル・ペトレスクモトローラLabsの公園アルゴリズムサントーバンジフ=シュル=イヴェット91193フランス
EMail: Alexandru.Petrescu@motorola.com
メールアドレス：Alexandru.Petrescu@motorola.com
Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 France
パスカルThubertシスコシステムズ技術センターヴィレッジグリーン企業サイド400アベニューRoumanilleビオ - ソフィアアンティポリス、フランス06410
EMail: pthubert@cisco.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。