[要約] RFC 5177は、Mobile IPv4に対するネットワークモビリティ（NEMO）拡張の要約です。このRFCの目的は、モバイルノードがネットワーク内で移動する際に、ネットワークの移動性をサポートするための拡張機能を提供することです。
Network Working Group K. Leung
Request for Comments: 5177 G. Dommety
Category: Standards Track Cisco Systems
V. Narayanan
Qualcomm, Inc.
A. Petrescu
Motorola
April 2008
Network Mobility (NEMO) Extensions for Mobile IPv4
モバイルIPv4のネットワークモビリティ（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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.
このドキュメントでは、モバイルIPv4プロトコルを拡張することにより、モバイルルーターとホームエージェント間のモバイルネットワークをサポートするためのプロトコルについて説明します。モバイルルーターは、1つ以上のネットワークセグメントまたはサブネットが一緒に移動するモビリティを担当します。モバイルルーターは、モバイルネットワーク上のノードからモビリティを隠しています。モバイルネットワーク上のノードは、モバイルルーターとの関係で固定されている場合があり、モビリティ機能がない場合があります。
Extensions to Mobile IPv4 are introduced to support Mobile Networks.
モバイルIPv4への拡張は、モバイルネットワークをサポートするために導入されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Examples of Mobile Networks . . . . . . . . . . . . . . . 3
1.2. Overview of Protocol . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 8
4.1. Mobile Network Request Extension . . . . . . . . . . . . . 8
4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 9
5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 11
5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 12
5.2. Mobile Router Management . . . . . . . . . . . . . . . . . 12
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 13
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 14
6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 14
6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 14
6.4. Advertising Mobile Network Reachability . . . . . . . . . 16
6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 16
6.6. Sending Registration Replies . . . . . . . . . . . . . . . 17
6.7. Mobile Network Prefix Deregistration . . . . . . . . . . . 17
7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 17
8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 18
9. Routing Protocol between Mobile Router and Home Agent . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Security when Dynamic Routing Protocol Is Used . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
This document describes network mobility extensions to the Mobile IPv4 protocol. The goal of introducing these extensions is to accommodate mobility scenarios where groups of hosts and routers move homogeneously (as a whole). It is required that all hosts and routers in a Mobile Network be able to run applications connecting to the Internet, and be reachable from the Internet.
このドキュメントでは、モバイルIPv4プロトコルへのネットワークモビリティ拡張機能について説明しています。これらの拡張機能を導入するという目標は、ホストとルーターのグループが（全体として）均一に移動するモビリティシナリオに対応することです。モバイルネットワーク内のすべてのホストとルーターは、インターネットに接続してアプリケーションを実行し、インターネットからリーチできるようにする必要があります。
For details regarding terminology related to network mobility (NEMO), a quick read of RFC 4885 [RFC4885] is suggested.
ネットワークモビリティ（NEMO）に関連する用語に関する詳細については、RFC 4885 [RFC4885]をすばやく読み取ります。
A Mobile Network links together a set of hosts and routers. Connecting this Mobile Network to the Internet is ensured at two levels: first, a Mobile Router is connected on one side to the Mobile Network and on another side to a wireless access system; second, a Home Agent placed on the home link manages traffic between the Correspondent Node and a Local Fixed Node (LFN, a node in the Mobile Network) by means of encapsulating traffic.
モバイルネットワークは、ホストとルーターのセットをリンクします。このモバイルネットワークをインターネットに接続すると、2つのレベルで保証されます。まず、モバイルルーターが片側にモバイルネットワークに接続され、もう一方の側面がワイヤレスアクセスシステムに接続されています。第二に、ホームリンクに配置されたホームエージェントは、交通をカプセル化することにより、特派員ノードとローカル固定ノード（LFN、モバイルネットワークのノード）間のトラフィックを管理します。
A scenario of applicability for this Mobile Network is described next. A Mobile Network is formed by a wireless-enabled Personal Digital Assistant (PDA) and a portable photographic camera, linked together by Bluetooth wireless link-layer technology. This is sometimes referred to as a Personal Area Network (PAN). In the illustration below, one can notice the PDA playing the role of a Mobile Router and the camera the role of Local Fixed Node.
次に、このモバイルネットワークへの適用性のシナリオについて説明します。モバイルネットワークは、ワイヤレス対応のパーソナルデジタルアシスタント（PDA）と、Bluetoothワイヤレスリンク層テクノロジーによってリンクされたポータブル写真カメラによって形成されます。これは、個人エリアネットワーク（PAN）と呼ばれることもあります。以下の図では、PDAがモバイルルーターの役割を果たし、カメラがローカル固定ノードの役割を果たしていることに気付くことができます。
----
| HA |
---- --------
| / \ ----
-+--------| Internet |---------| CN |
\ / ----
--------
/ \
/ \
/ \
---- ----
| AR | | AR |
---- ----
|cellular |cellular
/ |cellular
| ---- ----
Mobile | | MR | |LFN | ---movement-->
Network < ---- ----
| | |
| -+-----------+-
\ Bluetooth
The camera (Local Fixed Node) uploads photographic content to a Correspondent Node (CN) server. When the Mobile Network moves away, the Mobile Router serving the Mobile Network changes its point of attachment from one cellular access (Access Router) to another, obtaining a new Care-of Address. The Home Agent (HA) encapsulates application traffic for the CN and LFN.
カメラ（ローカル固定ノード）は、写真コンテンツを特派員ノード（CN）サーバーにアップロードします。モバイルネットワークが移動すると、モバイルネットワークにサービスを提供するモバイルルーターが、あるセルラーアクセス（アクセスルーター）から別のセルラーへの添付ポイントを変更し、新しいアドレスを取得します。ホームエージェント（HA）は、CNおよびLFNのアプリケーショントラフィックをカプセル化します。
Whereas the illustration above is a very simple instantiation of the applicability of Mobile IP-based Mobile Networks, more complex Mobile Networks are easily accommodated by the Mobile IPv4 extensions presented in this document (NEMOv4). For example, laptop computers used by passengers in a bus, train, ship, or plane should all be considered as forming Mobile Networks, as long as they move together (homogeneously).
上記の図は、モバイルIPベースのモバイルネットワークの適用性の非常に簡単なインスタンス化ですが、このドキュメント（NEMOV4）に示されているモバイルIPv4拡張機能によって、より複雑なモバイルネットワークが簡単に対応できます。たとえば、バス、電車、船、または飛行機で乗客が使用するラップトップコンピューターはすべて、一緒に移動する限り、モバイルネットワークを形成するものと見なす必要があります（均一に）。
As introduced previously, this document presents extensions to the Mobile IPv4 protocol. The entities sending and receiving these extensions are the Mobile Router and the Home Agent. The Local Fixed Node is relieved from running Mobile IP software and, although it moves (together with the Mobile Network), its IP stack is not seeing any change in addressing.
前述のように、このドキュメントはモバイルIPv4プロトコルの拡張機能を示しています。これらの拡張機能を送信および受信するエンティティは、モバイルルーターとホームエージェントです。ローカル固定ノードは、モバイルIPソフトウェアの実行から解放され、（モバイルネットワークと一緒に）移動しますが、IPスタックではアドレス指定に変更がありません。
Mobility for the entire Mobile Network is supported by the Mobile Router registering its current point of attachment (Care-of Address) to its Home Agent: the Mobile Router sends an extended Registration Request to the Home Agent, which returns an extended Registration Reply. This signaling sets up the tunnel between the two entities, as illustrated in the following figure:
モバイルネットワーク全体のモビリティは、モバイルルーターがホームエージェントに現在のアタッチメントポイント（ケアオブアドレス）を登録することでサポートされています。モバイルルーターは、延長登録リクエストをホームエージェントに送信し、拡張登録返信を返します。このシグナル伝達は、次の図に示すように、2つのエンティティ間にトンネルを設定します。
LFN MR HA CN
| | | |
| | Extended Registration | |
| |---------------------->| |
| | Request | |
| | | |
| | | |
| | Extended Registration | |
| |<----------------------| |
| | Reply | |
| | | |
|<--------o=======================o-------->|
| | Encapsulated | |
| | Application Traffic | |
| | | |
The prefix(es) used within a Mobile Network (either implicitly configured on the Home Agent or explicitly identified by the Mobile Router in the Registration Request) is/are advertised by the Home Agent for route propagation in the home network. Traffic to and from nodes in the Mobile Network are tunneled by the Home Agent to the Mobile Router, and vice versa. Though packets from a Local Fixed Node placed in the Mobile Network can be forwarded by the Mobile Router directly without tunneling (if reverse tunneling were not used), these packets will be dropped if ingress filtering is turned on at the Access Router.
モバイルネットワーク内で使用される接頭辞（ES）（ホームエージェントで暗黙的に構成するか、登録リクエストでモバイルルーターによって明示的に識別される）は、ホームエージェントによってホームネットワークでのルート伝播のために宣伝されます。モバイルネットワークのノードとの間のトラフィックは、ホームエージェントによってモバイルルーターにトンネルされ、その逆も同様です。モバイルネットワークに配置されたローカル固定ノードからのパケットは、トンネルなしでモバイルルーターによって直接転送できますが（逆トンネリングが使用されていない場合）、アクセスルーターでイングレスフィルタリングをオンにすると、これらのパケットがドロップされます。
Extensively relating to Mobile IPv4 [RFC3344], this specification addresses mainly the co-located Care-of Address mode. Foreign Agent Care-of Address mode (with 'legacy' Foreign Agents [RFC3344]) is supported but without optimization, and with double encapsulation being used. For an optimization of this mode, the gentle reader is directed to an extension document [NEMOv4-FA].
モバイルIPv4 [RFC3344]に広く関連して、この仕様は主に共同配置されたアドレスモードモードにアドレス指定します。外国のエージェントケアオブアドレスモード（「レガシー」外国人エージェント[RFC3344]）はサポートされていますが、最適化なしで、二重カプセル化が使用されています。このモードを最適化するために、穏やかな読者は拡張ドキュメント[nemov4-fa]に向けられます。
Compared to Mobile IPv4, this document specifies an additional tunnel between a Mobile Router's Home Address and the Home Agent. This tunnel is encapsulated within the normal tunnel between the Care-of Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between the Mobile Router and Home Agent is needed to allow the Foreign Agent to direct the decapsulated packet to the proper visiting Mobile Router. However, in co-located CoA mode, the additional tunnel is not essential and could be eliminated because the Mobile Router is the recipient of the encapsulated packets for the Mobile Network; a proposal for this feature is in the extending document mentioned above [NEMOv4-FA].
モバイルIPv4と比較して、このドキュメントは、モバイルルーターのホームアドレスとホームエージェントの間に追加のトンネルを指定します。このトンネルは、ケアオブアドレス（COA）とホームエージェントの間の通常のトンネル内にカプセル化されています。外国のエージェントCOAモードでは、外国人エージェントが脱カプセル化パケットを適切な訪問モバイルルーターに向けるために、モバイルルーターとホームエージェントの間のトンネルが必要です。ただし、共同配置されたCOAモードでは、モバイルルーターがモバイルネットワーク用のカプセル化されたパケットの受信者であるため、追加のトンネルは必須ではなく、排除できます。この機能の提案は、上記の拡張文書[nemov4-fa]にあります。
All traffic between the nodes in the Mobile Network and the Correspondent Nodes passes through the Home Agent. This document does not touch on aspects related to route optimization of this traffic.
モバイルネットワークのノードと特派員ノード間のすべてのトラフィックは、ホームエージェントを通過します。このドキュメントは、このトラフィックのルート最適化に関連する側面に触れません。
A similar protocol has been documented in RFC 3963 [RFC3963] for supporting IPv6 Mobile Networks with Mobile IPv6 extensions.
同様のプロトコルが、モバイルIPv6拡張機能を備えたIPv6モバイルネットワークをサポートするために、RFC 3963 [RFC3963]で文書化されています。
Multihoming for Mobile Routers is outside the scope of this document.
モバイルルーター用のマルチホームは、このドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Terminology for Mobile IPv4 mobility support is defined in RFC 3344 [RFC3344]. Terminology for network mobility support (NEMO), from an IPv6 perspective, is described in RFC 4885 [RFC4885]. In addition, this document defines the following terms for NEMOv4.
モバイルIPv4モビリティサポートの用語は、RFC 3344 [RFC3344]で定義されています。IPv6の観点から、ネットワークモビリティサポート（NEMO）の用語は、RFC 4885 [RFC4885]で説明されています。さらに、このドキュメントでは、Nemov4の次の用語を定義しています。
Mobile Router
モバイルルーター
RFC 3344 [RFC3344] defines a Mobile Router as a mobile node that can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak.
RFC 3344 [RFC3344]は、おそらく飛行機、船、列車、自動車、自転車、自動車、自動車、1つ以上のネットワーク全体の移動性を担当するルーターとなるモバイルノードとしてモバイルルーターを定義します。またはカヤック。
Mobile Network Prefix
モバイルネットワークプレフィックス
The network prefix of the subnet delegated to a Mobile Router as the Mobile Network.
サブネットのネットワークプレフィックスは、モバイルネットワークとしてモバイルルーターに委任されました。
Prefix Table
プレフィックステーブル
A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses the Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router.
モバイルルーターのホームアドレスによってインデックス付けされたモバイルネットワークプレフィックスのリスト。ホームエージェントは、プレフィックステーブルを管理および使用して、特定のモバイルルーターに属するモバイルネットワークプレフィックスを決定します。
Local Fixed Node
ローカル固定ノード
RFC 4885 [RFC4885] defines a Local Fixed Node (LFN) to be a fixed node belonging to the Mobile Network and unable to change its point of attachment. This definition should not be confused with "Long, Fat Network, LFN" of RFC 1323 [RFC1323], at least because the latter is pronounced "elephan(t)" whereas a NEMO LFN is distinctively pronounced "elefen".
RFC 4885 [RFC4885]は、ローカル固定ノード（LFN）をモバイルネットワークに属する固定ノードと定義し、添付のポイントを変更できません。この定義は、少なくとも後者が「エレファン（t）」と発音されるのに対し、Nemo LFNは「エレフェン」とはっきりと発音されるため、RFC 1323 [RFC1323]の「長い脂肪ネットワーク、LFN」と混同しないでください。
Although the original Mobile IPv4 specifications stated that Mobile Networks can be supported by the Mobile Router and Home Agent using static configuration or running a routing protocol (see Section 4.5 of RFC 3344 [RFC3344]), there is no solution for explicit registration of the Mobile Networks served by the Mobile Router. A solution needs to provide the Home Agent a means to ensure that a Mobile Router claiming a certain Mobile Network Prefix is authorized to do so. A solution would also expose the Mobile Network Prefixes (and potentially other subnet-relevant information) in the exchanged messages, to aid in network debugging.
元のモバイルIPv4仕様は、静的構成またはルーティングプロトコルの実行を使用してモバイルルーターとホームエージェントによってモバイルネットワークがサポートできると述べていますが、モバイルの明示的な登録の解決策はありません。モバイルルーターが提供するネットワーク。ソリューションは、ホームエージェントに、特定のモバイルネットワークプレフィックスを主張するモバイルルーターが許可されるようにするための手段を提供する必要があります。また、ソリューションは、ネットワークのデバッグを支援するために、交換されたメッセージにモバイルネットワークのプレフィックス（および潜在的に他のサブネット関連情報）を公開します。
The following requirements for Mobile Network support are enumerated:
モバイルネットワークサポートの次の要件が列挙されています。
o A Mobile Router should be able to operate in explicit or implicit mode. A Mobile Router may explicitly inform the Home Agent which Mobile Network(s) need to be propagated via a routing protocol. A Mobile Router may also function in implicit mode, where the Home Agent may learn the Mobile Networks through other means, such as from the AAA server, via pre-configuration, or via a dynamic routing protocol.
o モバイルルーターは、明示的または暗黙的なモードで動作できる必要があります。モバイルルーターは、ルーティングプロトコルを介してどのモバイルネットワークを伝播する必要があるかをホームエージェントに明示的に通知する場合があります。モバイルルーターは暗黙的なモードでも機能する場合があります。ホームエージェントは、AAAサーバー、事前設定、または動的ルーティングプロトコルなどの他の手段を通じてモバイルネットワークを学習できます。
o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 [RFC3344] without any changes ('legacy' Foreign Agents).
o モバイルネットワークは、変更なしにRFC 3344 [RFC3344]に準拠した外国人エージェントを使用してサポートする必要があります（「レガシー」外国人エージェント）。
o The Mobile Network should allow Fixed Nodes, Mobile Nodes, or Mobile Routers to be on it.
o モバイルネットワークでは、固定ノード、モバイルノード、またはモバイルルーターを使用する必要があります。
o The Local Fixed Nodes on a Mobile Network should be able to execute their sessions without running Mobile IP stacks. The Mobile Router managing the LFNs' Mobile Network is 'hiding' mobility events like the changes of the Care-of Address from the Local Fixed Nodes in that Mobile Network.
o モバイルネットワーク上のローカル固定ノードは、モバイルIPスタックを実行せずにセッションを実行できる必要があります。LFNSのモバイルネットワークを管理するモバイルルーターは、そのモバイルネットワークのローカル固定ノードからのケアのケアの変更のようなモビリティイベントを「隠す」ことです。
For Explicit Mode, the Mobile Router informs the Home Agent about the Mobile Network Prefixes during registration. The Registration Request contains zero, one, or several Mobile Network Request extensions in addition to any other extensions defined by or in the context of RFC 3344 [RFC3344]. When several Mobile Networks need to be registered, each is included in a separate Mobile Network Request extension, with its own Type, Length, Sub-Type, Prefix Length, and Prefix. A Mobile Network Request extension is encoded in Type-Length-Value (TLV) format and respects the following ordering:
明示的なモードの場合、モバイルルーターは、登録中のモバイルネットワークのプレフィックスについてホームエージェントに通知します。登録要求には、RFC 3344 [RFC3344]によって定義された他の拡張機能に加えて、ゼロ、1つ、または複数のモバイルネットワーク要求拡張機能が含まれています。いくつかのモバイルネットワークを登録する必要がある場合、それぞれが独自のタイプ、長さ、サブタイプ、プレフィックスの長さ、プレフィックスを備えた別のモバイルネットワーク要求拡張機能に含まれています。モバイルネットワークリクエスト拡張機能は、Type-Length-Value（TLV）形式でエンコードされ、次の注文を尊重します。
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 | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
148 Mobile Network Extension
148モバイルネットワーク拡張機能
Length:
長さ：
Decimal 6.
10進6。
Sub-Type:
サブタイプ：
0 (Mobile Network Request)
0（モバイルネットワークリクエスト）
Prefix Length:
プレフィックスの長さ：
8-bit unsigned integer indicating the number of leftmost bits covering the network part of the address contained in the Prefix field.
プレフィックスフィールドに含まれるアドレスのネットワーク部分をカバーする左端ビットの数を示す8ビットの符号なし整数。
Prefix:
プレフィックス：
32-bit unsigned integer in network byte-order containing an IPv4 address whose leftmost Prefix Length bits make up the Mobile Network Prefix.
ネットワークバイトオーダーの32ビットの非署名整数は、モバイルネットワークのプレフィックスを構成する左端のプレフィックスの長さビットを含むIPv4アドレスを含む。
The Registration Reply contains zero, one or several Mobile Network Acknowledgement extensions in addition to any other extensions defined by or in the context of RFC 3344 [RFC3344]. For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile Router the prefixes for which the Home Agent sets up forwarding with respect to this Mobile Router. Policies such as permitting only traffic from these Mobile Networks to be tunneled to the Home Agent may be applied by the Mobile Router. For Explicit Mode, when several Mobile Networks need to be acknowledged explicitly, each is included in a separate Mobile Network Acknowledgement extension, with its own Type, Sub-Type, Length, Prefix, and Prefix Length fields. At least one Mobile Network Acknowledgement extension MUST be in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed, and therefore was not skipped by the Home Agent.
登録返信には、RFC 3344 [RFC3344]によって定義された他の拡張機能に加えて、ゼロ、1つまたは複数のモバイルネットワーク確認拡張機能が含まれています。暗黙的なモードの場合、モバイルネットワークの確認は、モバイルルーターに、このモバイルルーターに関してホームエージェントが転送を設定するプレフィックスを通知します。これらのモバイルネットワークからのトラフィックのみをホームエージェントにトンネル化することを許可するなどのポリシーは、モバイルルーターによって適用される場合があります。明示的なモードの場合、いくつかのモバイルネットワークを明示的に承認する必要がある場合、それぞれが独自のタイプ、サブタイプ、長さ、プレフィックス、およびプレフィックスの長さフィールドを備えた別のモバイルネットワーク確認拡張拡張機能に含まれています。少なくとも1つのモバイルネットワークの確認拡張機能は、モバイルネットワークリクエストの拡張機能が処理されたため、ホームエージェントによってスキップされなかったことをモバイルルーターに示すために、登録の成功している必要があります。
A Registration Reply may contain any non-zero number of Explicit Mode and Implicit Mode Acknowledgements sub-types. Both sub-types can be present in a single Registration Reply. A Mobile Network Acknowledgement extension is encoded in Type-Length-Value (TLV) format. When the registration is denied with Code HA_MOBNET_ERROR (Code field in the Registration Reply), the Code field in the included Mobile Network Extension provides the reason for the failure.
登録返信には、ゼロ以外の数の明示的なモードと暗黙的なモードの確認サブタイプを含めることができます。両方のサブタイプは、単一の登録返信に存在することができます。モバイルネットワークの確認拡張機能は、Type-Length-Value（TLV）形式でエンコードされています。登録がコードHA_MOBNET_ERROR（登録返信のコードフィールド）で拒否されると、含まれているモバイルネットワーク拡張機能のコードフィールドが障害の理由を提供します。
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 | Sub-Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
148 Mobile Network Extension
148モバイルネットワーク拡張機能
Length:
長さ：
Decimal 8.
小数8。
Sub-Type:
サブタイプ：
1 (Explicit Mode Acknowledgement)
1（明示的なモードの確認）
2 (Implicit Mode Acknowledgement)
2（暗黙的なモードの確認）
Code: Value indicating success or failure:
コード：成功または失敗を示す値：
0 Success
0成功
1 Invalid prefix (MOBNET_INVALID_PREFIX_LEN)
1無効なプレフィックス（mobnet_invalid_prefix_len）
2 Mobile Router is not authorized for prefix (MOBNET_UNAUTHORIZED)
2モバイルルーターはプレフィックスを許可されていません（mobnet_unauthorized）
3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED)
3転送セットアップが失敗しました（mobnet_fwding_setup_failed）
Prefix Length:
プレフィックスの長さ：
8-bit unsigned integer indicating the number of leftmost bits covering the network part of the address contained in the Prefix field.
プレフィックスフィールドに含まれるアドレスのネットワーク部分をカバーする左端ビットの数を示す8ビットの符号なし整数。
Reserved:
予約済み：
Sent as zero; ignored on reception.
ゼロとして送信。レセプションで無視されます。
Prefix:
プレフィックス：
32-bit unsigned integer in network byte-order containing an IPv4 address whose leftmost Prefix Length bits make up the Mobile Network Prefix.
ネットワークバイトオーダーの32ビットの非署名整数は、モバイルネットワークのプレフィックスを構成する左端のプレフィックスの長さビットを含むIPv4アドレスを含む。
A Mobile Router's operation is generally derived from the behavior of a Mobile Node, as set in RFC 3344 [RFC3344]. In addition to maintaining mobility bindings for its Home Address, the Mobile Router, together with the Home Agent, maintains forwarding information for the Mobile Network Prefix(es) assigned to the Mobile Router.
モバイルルーターの操作は、一般に、RFC 3344 [RFC3344]に設定されたモバイルノードの動作に由来します。ホームアドレスのモビリティバインディングを維持することに加えて、モバイルルーターはホームエージェントとともに、モバイルルーターに割り当てられたモバイルネットワークプレフィックス（ES）の転送情報を維持します。
A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages it sends to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, all the traffic from the Mobile Network will be subject to ingress filtering in the visited networks. Upon reception of a successful Registration Reply, the Mobile Router processes the registration in accordance to RFC 3344 [RFC3344]. In addition, the following steps are taken:
モバイルルーターは、すべてのトラフィックの逆トンネルの必要性を示すために送信するすべての登録要求メッセージで「T」ビットを1に設定する必要があります。逆トンネルがなければ、モバイルネットワークからのすべてのトラフィックは、訪問されたネットワークでのイングレスフィルタリングの対象となります。登録返信が成功すると、モバイルルーターはRFC 3344 [RFC3344]に従って登録を処理します。さらに、次の手順が取られます。
o Check for Mobile Network Acknowledgement extension(s) in Registration Reply.
o 登録返信でモバイルネットワークの確認拡張子を確認してください。
o Create tunnel to the Home Agent if the Mobile Router is registered in reverse tunneling mode.
o モバイルルーターが逆トンネルモードで登録されている場合は、ホームエージェントにトンネルを作成します。
o Set up default route via this tunnel or egress interface when the Mobile Router is registered with or without reverse tunneling, respectively.
o モバイルルーターがそれぞれ逆トンネルの有無にかかわらず登録されている場合、このトンネルまたは出口インターフェイスを介してデフォルトルートを設定します。
In accordance with this specification, a Mobile Router may operate in one of the following two modes: explicit and implicit. In explicit mode, the Mobile Router includes Mobile Network Prefix information in all Registration Requests (as Mobile Network Request extensions), while in implicit mode it does not include this information in any Registration Request. In the latter case, the Home Agent obtains the Mobile Network Prefixes by other means than Mobile IP. One example of obtaining the Mobile Network Prefix is through static configuration on the Home Agent.
この仕様に従って、モバイルルーターは、次の2つのモードのいずれかで動作する場合があります：明示的および暗黙的。明示的なモードでは、モバイルルーターには、すべての登録要求（モバイルネットワークリクエスト拡張機能など）にモバイルネットワークプレフィックス情報が含まれていますが、暗黙的なモードでは、登録要求にこの情報を含めません。後者の場合、ホームエージェントは、モバイルIP以外の他の手段でモバイルネットワークのプレフィックスを取得します。モバイルネットワークプレフィックスを取得する1つの例は、ホームエージェントの静的構成を使用することです。
A Mobile Router can obtain a co-located or Foreign Agent Care-of Address while operating in explicit or implicit modes.
モバイルルーターは、明示的または暗黙的なモードで動作しながら、コロアシーまたは外国のエージェントの住所を取得できます。
For deregistration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions.
規制緩和のために、モバイルルーターは、モバイルネットワークリクエスト拡張機能なしに、Lifetimeセットの登録リクエストをゼロに送信します。
In a Mobile IP Registration Reply message, there may be two Code fields: one proper to the Registration Reply header (the 'proper' Code) and one within the Mobile Network Acknowledgement Extension (simply the 'Code'). A Mobile Router interprets the values of the Code field in the Mobile Network Acknowledgement Extension of the Registration Reply in order to identify any error related to managing the Mobile Network Prefixes by the Home Agent. It also interprets the values of the Code field in the Registration Reply header (the proper Code).
モバイルIP登録返信メッセージには、2つのコードフィールドがあります。1つは登録応答ヘッダー（「適切な」コード）とモバイルネットワークの確認拡張子（単純な「コード」）内にある1つです。モバイルルーターは、ホームエージェントによるモバイルネットワークプレフィックスの管理に関連するエラーを特定するために、登録応答のモバイルネットワーク確認応答のコードフィールドの値を解釈します。また、登録返信ヘッダー（適切なコード）のコードフィールドの値を解釈します。
If the value of the Code field in the Registration Reply (the proper) is set to HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent.
登録返信のコードフィールドの値（適切な）がha_mobnet_disallowedに設定されている場合、モバイルルーターは、モバイルネットワークのプレフィックス拡張機能で登録要求をそのホームエージェントに送信するのを停止する必要があります。
If the value of the Code field in the Registration Reply (the proper) is set to HA_MOBNET_ERROR, then the Mobile Router MUST stop sending Registration Requests that contain any of the Mobile Network Prefixes that are defined by the values of the fields Prefix and Prefix Length in the Mobile Network Acknowledgement extension. Note that the registration is denied in this case, and no forwarding for any Mobile Network Prefixes would be set up by the Home Agent for the Mobile Router.
登録返信のコードフィールドの値（適切な）がha_mobnet_errorに設定されている場合、モバイルルーターは、フィールドプレフィックスとプレフィックスの長さによって定義されるモバイルネットワークプレフィックスのいずれかを含む登録要求の送信を停止する必要がありますモバイルネットワークの確認拡張機能で。この場合、登録は拒否されており、モバイルルーターのホームエージェントによってモバイルネットワークのプレフィックスの転送は設定されないことに注意してください。
It is possible that the Mobile Router receives a Registration Reply with no Mobile Network extensions if the registration was processed by a Mobile IPv4 Home Agent that does not support this specification at all. In that case, the absence of Mobile Network extensions must be interpreted by the Mobile Router as the case where the Home Agent does not support Mobile Networks.
この仕様をまったくサポートしていないモバイルIPv4ホームエージェントによって登録が処理された場合、モバイルルーターはモバイルネットワーク拡張機能のない登録返信を受信する可能性があります。その場合、モバイルネットワーク拡張機能の存在は、ホームエージェントがモバイルネットワークをサポートしていない場合として、モバイルルーターによって解釈する必要があります。
All the error code values have been assigned by IANA; see Section 11.
すべてのエラーコード値はIANAによって割り当てられています。セクション11を参照してください。
Operating a Mobile Router in a Mobile IPv4 environment has certain requirements on the management of the necessary initial configuration and supervision of the ongoing status information. Mobile Router maintenance indicators may need to be exposed in a manner consistent with other Mobile IPv4 indicators.
モバイルIPv4環境でモバイルルーターを操作するには、必要な初期構成の管理と進行中のステータス情報の監督に関する特定の要件があります。モバイルルーターメンテナンスインジケーターは、他のモバイルIPv4インジケーターと一致する方法で公開する必要がある場合があります。
The objects for the Management Information Base (MIB) for Mobile IPv4 are defined in RFC 2006 [RFC2006]. The structure of the basic model of Mobile IP protocol describes three entities: Mobile Node, Home Agent, and Foreign Agent. In addition to these entities, this document proposes a functional entity to be the Mobile Router.
モバイルIPv4の管理情報ベース（MIB）のオブジェクトは、RFC 2006 [RFC2006]で定義されています。モバイルIPプロトコルの基本モデルの構造は、モバイルノード、ホームエージェント、および外国人エージェントの3つのエンティティを記述しています。これらのエンティティに加えて、このドキュメントは、機能的なエンティティがモバイルルーターになることを提案しています。
The necessary initial configuration at a NEMOv4-enabled Home Agent includes, but is not limited to, the contents of the Prefix Table. The Mobile Router MAY need to store the Mobile Network Prefixes as the initial configuration.
Nemov4対応のホームエージェントでの必要な初期構成には、プレフィックステーブルの内容が含まれますが、これらに限定されません。モバイルルーターは、モバイルネットワークのプレフィックスを初期構成として保存する必要がある場合があります。
The definition of MIB objects related to the Mobile Router and to a NEMOv4-enabled Home Agent is outside the scope of this document.
モバイルルーターとNemov4対応のホームエージェントに関連するMIBオブジェクトの定義は、このドキュメントの範囲外です。
A Home Agent MUST support all the operations specified in RFC 3344 [RFC3344] for Mobile Node support. The Home Agent MUST support both implicit and explicit modes of operation for a Mobile Router.
ホームエージェントは、モバイルノードサポートのためにRFC 3344 [RFC3344]で指定されたすべての操作をサポートする必要があります。ホームエージェントは、モバイルルーターの暗黙的および明示的な動作モードの両方をサポートする必要があります。
The Home Agent processes the registration in accordance to RFC 3344 [RFC3344], which includes route setup to the Mobile Router's Home Address via the tunnel to the Care-of Address. In addition, for a Mobile Router registering in explicit mode, the following steps are taken:
ホームエージェントは、RFC 3344 [RFC3344]に従って登録を処理します。これには、トンネルを介してモバイルルーターのホームアドレスへのルートセットアップが含まれます。さらに、明示的なモードで登録するモバイルルーターの場合、次の手順が取られます。
1. Check that the Mobile Network Prefix information is valid.
1. モバイルネットワークのプレフィックス情報が有効であることを確認してください。
2. Ensure the Mobile Network Prefix(es) is/are authorized to be on the Mobile Router.
2. モバイルネットワークのプレフィックス（ES）がモバイルルーター上にあることが許可されていることを確認してください。
3. Create a tunnel to the Mobile Router if it does not already exist.
3. モバイルルーターがまだ存在しない場合は、モバイルルーターにトンネルを作成します。
4. Set up route for the Mobile Network Prefix via this tunnel.
4. このトンネルを介してモバイルネットワークプレフィックスのルートをセットアップします。
5. Propagate Mobile Network Prefix routes via routing protocol if necessary.
5. 必要に応じて、ルーティングプロトコルを介してモバイルネットワークプレフィックスルートを伝播します。
6. Send the Registration Reply with the Mobile Network Acknowledgement extension(s).
6. モバイルネットワークの確認拡張子を使用して登録返信を送信します。
If there are any subnet routes via the tunnel to the Mobile Router that are not specified in the Mobile Network extensions, these routes are removed.
モバイルネットワーク拡張機能で指定されていないモバイルルーターへのトンネルを介してサブネットルートがある場合、これらのルートは削除されます。
In the case where the Mobile Node is not permitted to act as a Mobile Router, the Home Agent sends a Registration Reply message whose Code field is HA_MOBNET_DISALLOWED (the proper Code field of the Registration Reply).
モバイルノードがモバイルルーターとして機能することが許可されていない場合、ホームエージェントはコードフィールドがha_mobnet_disallowed（登録返信の適切なコードフィールド）である登録返信メッセージを送信します。
For a Mobile Router registering in implicit mode, the Home Agent performs steps 3-6 above, once the registration request is processed successfully.
暗黙的なモードで登録するモバイルルーターの場合、ホームエージェントは登録要求が正常に処理されると、上記の3-6ステップを実行します。
For deregistration, the Home Agent removes the tunnel to the Mobile Router and all routes using this tunnel. The Mobile Network extensions are ignored.
解雇のために、ホームエージェントはこのトンネルを使用してトンネルをモバイルルーターとすべてのルートに除去します。モバイルネットワーク拡張機能は無視されます。
The Registration Table in the Home Agent, in accordance with RFC 3344 [RFC3344], contains binding information for every Mobile Node registered with it. RFC 3344 [RFC3344] defines the format of a Registration Table. In addition to all the parameters specified by RFC 3344 [RFC3344], the Home Agent MUST store the Mobile Network Prefixes associated with the Mobile Router in the corresponding registration entry, when the corresponding registration was performed in explicit mode. When the Home Agent is advertising reachability to Mobile Network Prefixes served by a Mobile Router, the information stored in the Registration Table can be used.
RFC 3344 [RFC3344]に従って、ホームエージェントの登録表には、登録されているすべてのモバイルノードの拘束力のある情報が含まれています。RFC 3344 [RFC3344]は、登録表の形式を定義します。RFC 3344 [RFC3344]で指定されたすべてのパラメーターに加えて、ホームエージェントは、対応する登録が明示的なモードで実行されたときに、対応する登録エントリでモバイルルーターに関連付けられたモバイルネットワークプレフィックスを保存する必要があります。ホームエージェントがモバイルルーターが提供するモバイルネットワークのプレフィックスに到達可能性を広告している場合、登録テーブルに保存されている情報を使用できます。
The Home Agent must be able to authorize a Mobile Router for use of Mobile Network Prefixes when the Mobile Router is operating in explicit mode. Also, when the Mobile Router operates in implicit mode, the Home Agent must be able to locate the Mobile Network Prefixes associated with that Mobile Router. The Home Agent may store the Home Address of the Mobile Router along with the Mobile Network prefixes associated with that Mobile Router. If the Mobile Router does not have a Home Address assigned, this table may store the Network Access Identifier (NAI) [RFC2794] of the Mobile Router that will be used in dynamic Home Address assignment.
ホームエージェントは、モバイルルーターが明示的なモードで動作しているときに、モバイルネットワークプレフィックスを使用するためにモバイルルーターを承認できる必要があります。また、モバイルルーターが暗黙的なモードで動作する場合、ホームエージェントはそのモバイルルーターに関連付けられたモバイルネットワークのプレフィックスを見つけることができなければなりません。ホームエージェントは、モバイルルーターのホームアドレスと、そのモバイルルーターに関連付けられたモバイルネットワークのプレフィックスを保存できます。モバイルルーターにホームアドレスが割り当てられていない場合、このテーブルは、動的ホームアドレスの割り当てで使用されるモバイルルーターのネットワークアクセス識別子（NAI）[RFC2794]を保存する場合があります。
The Home Agent must process Registration Requests coming from Mobile Routers in accordance with this section. RFC 3344 [RFC3344] specifies that the Home Address of a mobile node registering with a Home Agent must belong to a prefix advertised on the home network. In accordance with this specification, however, the Home Address must be configured from a prefix that is served by the Home Agent, not necessarily the one on the home network.
ホームエージェントは、このセクションに従ってモバイルルーターからの登録リクエストを処理する必要があります。RFC 3344 [RFC3344]は、ホームエージェントに登録するモバイルノードのホームアドレスが、ホームネットワークに宣伝されているプレフィックスに属している必要があることを指定しています。ただし、この仕様に従って、ホームエージェントが提供するプレフィックスからホームアドレスを構成する必要があります。必ずしもホームネットワーク上のエージェントではありません。
If the Registration Request is valid, the Home Agent checks to see if there are any Mobile Network Prefix extensions included in the Registration Request.
登録要求が有効な場合、ホームエージェントは登録リクエストに含まれるモバイルネットワークプレフィックス拡張機能があるかどうかを確認します。
If so, the Mobile Network Prefix information is obtained from the included extensions, and the Home Address from the Home Address field of the Registration Request. For every Mobile Network Prefix extension included in the registration request, the Home Agent MUST perform a check against the Prefix Table. If the Prefix Table does not contain at least one entry pairing that Home Address to that Mobile Network Prefix, then the check fails; otherwise, it succeeds.
その場合、モバイルネットワークのプレフィックス情報は、含まれている拡張機能から、および登録要求のホームアドレスフィールドからホームアドレスから取得されます。登録要求に含まれるすべてのモバイルネットワークプレフィックス拡張機能について、ホームエージェントはプレフィックステーブルに対してチェックを実行する必要があります。プレフィックステーブルに、そのモバイルネットワークプレフィックスのホームアドレスを組み合わせて少なくとも1つのエントリペアリングが含まれていない場合、チェックは失敗します。そうでなければ、それは成功します。
Following this check against the Prefix Table, the Home Agent MUST construct a Registration Reply containing Mobile Network Acknowledgement extensions. For a Mobile Network Prefix for which the check was unsuccessful, the Code field in the corresponding Mobile Network Acknowledgement extension should be set to MOBNET_UNAUTHORIZED.
プレフィックステーブルに対してこのチェックに続いて、ホームエージェントはモバイルネットワークの確認拡張機能を含む登録返信を作成する必要があります。チェックが失敗したモバイルネットワークのプレフィックスの場合、対応するモバイルネットワーク確認拡張機能のコードフィールドは、mobnet_unauthorizedに設定する必要があります。
For a Mobile Network Prefix for which the check was successful, the Code field in the respective Mobile Network Acknowledgement extensions should be set to 0.
チェックが成功したモバイルネットワークプレフィックスの場合、それぞれのモバイルネットワーク確認拡張機能のコードフィールドを0に設定する必要があります。
The Home Agent MUST attempt to set up forwarding for each Mobile Network Prefix extension for which the Prefix Table check was successful. If the forwarding setup fails for a particular Mobile Network Prefix (for reasons such as not enough memory available or not enough devices available), the Code field in the respective Mobile Network Acknowledgement extension should be set to MOBNET_FWDING_SETUP_FAILED.
ホームエージェントは、プレフィックステーブルチェックが成功した各モバイルネットワークプレフィックス拡張機能の転送を設定しようとする必要があります。特定のモバイルネットワークプレフィックスの転送セットアップが失敗した場合（使用可能なメモリが十分でないなどの理由で、使用可能なデバイスが十分でないなど）、それぞれのモバイルネットワーク承認拡張子のコードフィールドは、mobnet_fwding_setup_failedに設定する必要があります。
If forwarding and setup was successful for at least one Mobile Network Prefix, then the Code field (the proper) of the Registration Reply message should be set to 0. Otherwise, when forwarding and setup was unsuccessful for each and every Mobile Network Prefixes, that Code (the proper) should be HA_MOBNET_ERROR.
少なくとも1つのモバイルネットワークプレフィックスで転送とセットアップが成功した場合、登録応答メッセージのコードフィールド（適切な）を0に設定する必要があります。コード（適切）はha_mobnet_errorである必要があります。
If the Registration Request is sent in implicit mode, i.e., without any Mobile Network Request extension, the Home Agent may use pre-configured Mobile Network prefix information for the Mobile Router to set up forwarding.
登録要求が暗黙的なモードで送信された場合、つまりモバイルネットワークリクエスト拡張機能なしで、ホームエージェントは、モバイルルーターに事前に構成されたモバイルネットワークプレフィックス情報を使用して転送をセットアップすることができます。
If the Home Agent is updating an existing binding entry for the Mobile Router, it MUST check all the prefixes in the Registration Table against the prefixes included in the Registration Request. If one or more Mobile Network prefixes are missing from the included information in the registration request, the Home Agent MUST delete those prefixes from the registration table. Also, the Home Agent MUST disable forwarding for those prefixes.
ホームエージェントがモバイルルーターの既存のバインディングエントリを更新している場合、登録テーブル内のすべてのプレフィックスを登録リクエストに含まれるプレフィックスに対して確認する必要があります。登録リクエストに含まれる情報から1つ以上のモバイルネットワークプレフィックスが欠落している場合、ホームエージェントは登録テーブルからそれらのプレフィックスを削除する必要があります。また、ホームエージェントは、これらのプレフィックスの転送を無効にする必要があります。
If all checks are successful, the Home Agent either creates a new entry for the Mobile Router or updates an existing binding entry for it and returns a successful registration reply back to the Mobile Router or the Foreign Agent (if the Registration Request was received from a Foreign Agent).
すべてのチェックが成功した場合、ホームエージェントはモバイルルーターの新しいエントリを作成するか、既存のバインディングエントリを更新し、登録返信を成功させてモバイルルーターまたは外国人エージェントに戻します（登録要求が登録された場合外国人エージェント）。
In accordance with RFC 3344 [RFC3344], the Home Agent does proxy Address Resolution Protocol (ARP) for the Mobile Router Home Address when the Mobile Router Home Address is derived from the home network.
RFC 3344 [RFC3344]に従って、ホームエージェントは、モバイルルーターのホームアドレスがホームネットワークから派生したときに、モバイルルーターホームアドレスに対してプロキシアドレス解像度プロトコル（ARP）を行います。
If the 'T' bit is set, the Home Agent creates a bi-directional tunnel for the corresponding Mobile Network prefixes or updates the existing bi-directional tunnel. This tunnel is maintained independent of the reverse tunnel for the Mobile Router home address itself.
「t」ビットが設定されている場合、ホームエージェントは、対応するモバイルネットワークのプレフィックスのための双方向トンネルを作成するか、既存の双方向トンネルを更新します。このトンネルは、モバイルルーターのホームアドレス自体の逆トンネルとは無関係に維持されます。
If the Mobile Network prefixes served by the Home Agent are aggregated with the home network prefix and if the Home Agent is the default router on the home network, the Home Agent does not have to advertise the Mobile Network Prefixes. The routes for the Mobile Network Prefix are automatically aggregated into the home network prefix (it is assumed that the Mobile Network Prefixes are automatically aggregated into the home network prefix). If the Mobile Router updates the Mobile Network prefix routes via a dynamic routing protocol, the Home Agent SHOULD propagate the routes on the appropriate networks.
ホームエージェントが提供するモバイルネットワークのプレフィックスにホームネットワークのプレフィックスが集約されている場合、ホームエージェントがホームネットワークのデフォルトルーターである場合、ホームエージェントはモバイルネットワークのプレフィックスを宣伝する必要はありません。モバイルネットワークのプレフィックスのルートは、ホームネットワークプレフィックスに自動的に集約されます（モバイルネットワークプレフィックスが自動的にホームネットワークプレフィックスに集約されていると想定されています）。モバイルルーターが動的なルーティングプロトコルを介してモバイルネットワークプレフィックスルートを更新する場合、ホームエージェントは適切なネットワーク上のルートを伝播する必要があります。
The Home Agent creates and maintains a bi-directional tunnel for the Mobile Network prefixes of a Mobile Router registered with it. A Home Agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to the Mobile Network prefixes served by the Mobile Router to its Care-of Address. Also, the Home Agent MUST be able to accept packets tunneled by the Mobile Router with the source address of the outer header set to the Care-of Address of the Mobile Router and that of the inner header set to the Mobile Router's Home Address or an address from one of the registered Mobile Network prefixes.
ホームエージェントは、登録されているモバイルルーターのモバイルネットワークプレフィックスの双方向トンネルを作成および維持します。IPv4モバイルルーターの操作をサポートするホームエージェントは、モバイルルーターが提供するモバイルネットワークプレフィックスに運命づけられているパケットを転送することができなければなりません。また、ホームエージェントは、モバイルルーターのケアのケアにセットされた外側ヘッダーのソースアドレスと、モバイルルーターのホームアドレスまたは内側ヘッダーセットの外側ヘッダーのソースアドレスを使用して、モバイルルーターによってトンネルされたパケットを受け入れることができなければなりません。登録されたモバイルネットワークプレフィックスの1つからのアドレス。
The Home Agent MUST set the status code in the registration reply to 0 to indicate successful processing of the Registration Request and successful setup of forwarding for at least one Mobile Network prefix served by the Mobile Router. The Registration Reply MUST contain at least one Mobile Network Acknowledgement extension.
ホームエージェントは、登録応答のステータスコードを0に設定して、登録要求の処理の成功と、モバイルルーターが提供する少なくとも1つのモバイルネットワークプレフィックスの転送の成功を示す必要があります。登録返信には、少なくとも1つのモバイルネットワーク確認拡張機能が含まれている必要があります。
If the Home Agent is unable to set up forwarding for one or more Mobile Network prefixes served by the Mobile Router, it MUST set the Mobile Network Acknowledgement Extension status Code in the Registration Reply to MOBNET_FWDING_SETUP_FAILED. When the prefix length is zero or greater than decimal 32, the status Code MUST be set to MOBNET_INVALID_PREFIX_LEN.
ホームエージェントがモバイルルーターが提供する1つまたは複数のモバイルネットワークプレフィックスの転送を設定できない場合、登録にモバイルネットワーク確認拡張ステータスコードをMOBNET_FWDING_SETUP_FAILEDに設定する必要があります。接頭辞の長さが小数体32よりゼロ以下の場合、ステータスコードはbobnet_invalid_prefix_lenに設定する必要があります。
If the Mobile Router is not authorized to forward packets to a Mobile Network prefix included in the request, the Home Agent MUST set the Code to MOBNET_UNAUTHORIZED.
モバイルルーターがリクエストに含まれるモバイルネットワークのプレフィックスにパケットを転送する権限がない場合、ホームエージェントはコードをmobnet_unauthorizedに設定する必要があります。
If the received Registration Request is for deregistration of the Care-of Address, the Home Agent, upon successful processing of it, MUST delete the entry (or entries) from its Registration Table. The Home Agent tears down the bi-directional tunnel and stops forwarding any packets to/from the Mobile Router. The Home Agent MUST ignore any included Mobile Network Request extension in a deregistration request.
受信した登録要求が住所のケアの拒否のためにある場合、ホームエージェントは、それを成功させたときに、登録表からエントリ（またはエントリ）を削除する必要があります。ホームエージェントは、双方向トンネルを引き裂き、モバイルルーターへの任意のパケットの転送を停止します。ホームエージェントは、登録リクエストに含まれるモバイルネットワークリクエスト拡張機能を無視する必要があります。
For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent Care-of Address. In this case, the Home Agent MUST encapsulate the packet with the tunnel header (source IP address set to Home Agent, and destination IP address set to Mobile Router's Home Address) and then encapsulate one more time with the tunnel header (source IP address set to Home Agent, and destination IP address set to CoA).
モバイルネットワークのノードへのトラフィックの場合、モバイルルーターが外国のエージェントのケアオブアドレスに登録されていた場合、ホームエージェントはパケットの二重トンネリングを実行する必要があります。この場合、ホームエージェントは、トンネルヘッダー（ホームエージェントに設定されたソースIPアドレス、およびモバイルルーターのホームアドレスに設定されている宛先IPアドレスを設定）でパケットをカプセル化し、トンネルヘッダー（ソースIPアドレスセット）でもう1回カプセル化する必要がありますホームエージェント、および宛先IPアドレスがCOAに設定されます）。
For optimization, the Home Agent SHOULD only encapsulate the packet with the tunnel header (source IP address set to Home Agent, and destination IP address set to CoA) for co-located CoA mode.
最適化のために、ホームエージェントは、共同配置されたCOAモードのトンネルヘッダー（ホームエージェントに設定されたソースIPアドレス、および宛先IPアドレスがCOAに設定）のみを使用してパケットをカプセル化する必要があります。
When a Home Agent receives a packet from the Mobile Network prefix in the bi-directional tunnel, it MUST de-encapsulate the packet and route it as a normal IP packet. It MUST verify that the incoming packet has the source IP address set to the Care-of Address of the Mobile Router. The packet MUST be dropped if the source address is not set to the Care-of Address of the Mobile Router.
ホームエージェントが双方向トンネルのモバイルネットワークプレフィックスからパケットを受信する場合、パケットを除去して通常のIPパケットとしてルーティングする必要があります。受信パケットがソースIPアドレスがモバイルルーターのケアアドレスに設定されていることを確認する必要があります。ソースアドレスがモバイルルーターのケアアドレスに設定されていない場合は、パケットをドロップする必要があります。
For traffic from the nodes in the Mobile Network, the Mobile Router encapsulates the packet with a tunnel header (source IP address set to Mobile Router's Home Address, and destination IP address set to Home Agent) if reverse tunnel is enabled. Otherwise, the packet is routed directly to the Foreign Agent or access router.
モバイルネットワークのノードからのトラフィックの場合、モバイルルーターは、逆トンネルが有効になっている場合、トンネルヘッダー（モバイルルーターのホームアドレスに設定されたソースIPアドレス、および宛先IPアドレスがホームエージェントに設定）を使用してパケットをカプセル化します。それ以外の場合、パケットは外国のエージェントまたはアクセスルーターに直接ルーティングされます。
In co-located CoA mode, the Mobile Router MAY encapsulate one more time with a tunnel header (source IP address set to the CoA and destination IP address set to Home Agent).
共同配置COAモードでは、モバイルルーターはトンネルヘッダー（COAに設定されたソースIPアドレスとホームエージェントに設定された宛先IPアドレス）でもう1回カプセル化する場合があります。
Nested Network Mobility is 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. Two issues should be noted though. First, whenever physical loops occur in a nested aggregation of Mobile Networks, this protocol neither detects nor solves them -- datagram forwarding may be blocked. Second, Mobile Routers in a deep nested aggregation of Mobile Networks might introduce significant overhead on the data packets as each level of nesting introduces another tunnel header encapsulation. Applications that do not support MTU discovery are adversely affected by the additional header encapsulations because the usable MTU is reduced with each level of nesting.
ネストされたネットワークモビリティは、モバイルルーターが別のモバイルルーターがモバイルネットワークに接続できるようにするシナリオです。ネストされたモビリティには任意のレベルがある可能性があります。各モバイルルーターの操作は、モバイルルーターが別のモバイルルーターに取り付けられている場合でも、インターネット上の固定アクセスルーターに取り付けられている場合でも同じままです。ここで説明するソリューションは、ネストされたモビリティのレベル数に制限を課しません。ただし、2つの問題に注意する必要があります。第一に、モバイルネットワークのネストされた集約で物理ループが発生する場合はいつでも、このプロトコルはそれらを検出したり解決したりしません - データグラムの転送はブロックされる場合があります。第二に、モバイルネットワークの深いネストされた集約にあるモバイルルーターは、ネストの各レベルが別のトンネルヘッダーのカプセル化を導入するため、データパケットに大幅なオーバーヘッドを導入する可能性があります。MTUの発見をサポートしないアプリケーションは、使用可能なMTUがネストの各レベルで削減されるため、追加のヘッダーカプセルの影響を受けます。
There are several benefits of running a dynamic routing protocol between the Mobile Router and the Home Agent. If the Mobile Network is relatively large, including several wireless subnets, then the topology changes within the moving network can be exposed from the Mobile Router to the Home Agent by using a dynamic routing protocol. The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as defined in previous sections, is not to inform the Home Agent about these topology changes, but to manage the mobility of the Mobile Router.
モバイルルーターとホームエージェントの間で動的なルーティングプロトコルを実行することには、いくつかの利点があります。いくつかのワイヤレスサブネットを含むモバイルネットワークが比較的大きい場合、動きのネットワーク内のトポロジーの変化は、動的ルーティングプロトコルを使用してモバイルルーターからホームエージェントに公開することができます。以前のセクションで定義されているモバイルIPv4へのNemov4プロトコル拡張の目的は、これらのトポロジの変更についてホームエージェントに通知することではなく、モバイルルーターのモビリティを管理することです。
Similarly, topology changes in the home network can be exposed to the Mobile Router by using a dynamic routing protocol. This may be necessary when new fixed networks are added in the home network.
同様に、ホームネットワークのトポロジの変更は、動的ルーティングプロトコルを使用してモバイルルーターにさらされる可能性があります。これは、ホームネットワークに新しい固定ネットワークが追加されている場合に必要になる場合があります。
Here too, the purpose of NEMOv4 extensions is not to inform the Mobile Router about topology changes at home.
ここでも、Nemov4拡張機能の目的は、自宅でのトポロジの変化についてモバイルルーターに通知することではありません。
Examples of dynamic routing protocols include, but are not limited to, OSPF Version 2 [RFC2328], BGP [RFC4271], and RIP [RFC2453].
動的ルーティングプロトコルの例には、OSPFバージョン2 [RFC2328]、BGP [RFC4271]、およびRIP [RFC2453]が含まれますが、これらに限定されません。
The recommendations are related to how the routing protocol and the Mobile IPv4 implementation work in tandem on the Mobile Router and on the Home Agent (1) without creating incoherent states in the forwarding information bases at home and on the Mobile Router, (2) without introducing topologically incorrect addressing information in the visited domain, and (3) without duplicating sent data or over-provisioning security.
推奨事項は、ルーティングプロトコルとモバイルIPv4実装が、モバイルルーターおよびホームエージェント（1）でタンデムでどのように機能するかに関連しています。訪問されたドメインにトポロジカルな誤ったアドレス指定情報を導入し、（3）送信されたデータや過度のプロビジョニングセキュリティを複製することなく。
The information exchanged between the Mobile Router and the Home Agent is sent over the bi-directional tunnel established by the Mobile IPv4 exchange Registration Request - Registration Reply (see Section 6.5). If a network address and prefix of a subnet in the moving network is sent by the Mobile Router within a routing protocol message, then they SHOULD NOT be sent in the Mobile IPv4 Registration Request too. This avoids incoherencies in the forwarding information bases. The Mobile Router SHOULD use NEMOv4 implicit mode in this case (see Section 3).
モバイルルーターとホームエージェントとの間で交換される情報は、モバイルIPv4交換登録リクエスト - 登録返信によって確立された双方向トンネルを介して送信されます（セクション6.5を参照）。移動ネットワーク内のサブネットのネットワークアドレスとプレフィックスがルーティングプロトコルメッセージ内のモバイルルーターによって送信される場合、モバイルIPv4登録リクエストでも送信されないでください。これにより、転送情報ベースの一貫性が回避されます。モバイルルーターは、この場合にNemov4暗黙的モードを使用する必要があります（セクション3を参照）。
The Mobile Router SHOULD NOT send routing protocol information updates in the foreign network. The subnet addresses and prefixes valid in the moving network are topologically incorrect in the visited network.
モバイルルーターは、外国ネットワークでルーティングプロトコル情報の更新を送信しないでください。移動ネットワークで有効なサブネットアドレスと接頭辞は、訪問されたネットワークではトポロジカルに間違っています。
If the Mobile Router and the Home Agent use a dynamic routing protocol over the tunnel interface, and if that protocol offers security mechanisms to protect that protocol's messages, then the security recommendations in Section 10.1 apply.
モバイルルーターとホームエージェントがトンネルインターフェイス上で動的ルーティングプロトコルを使用し、そのプロトコルがそのプロトコルのメッセージを保護するためのセキュリティメカニズムを提供する場合、セクション10.1のセキュリティ推奨事項が適用されます。
The Mobile Network extension is protected by the same rules as for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344 [RFC3344].
モバイルネットワーク拡張機能は、登録メッセージのモバイルIP拡張機能と同じルールによって保護されています。RFC 3344 [RFC3344]のセキュリティに関する考慮事項セクションを参照してください。
The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the Registration Request, before anchoring these Mobile Network Prefixes on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be set up without successful authorization of the Mobile Router for those prefixes. The Mobile Router MUST be notified when there is a registration failure because it cannot be successfully authorized for prefixes it requested.
ホームエージェントは、モバイルルーターに代わってこれらのモバイルネットワークのプレフィックスを固定する前に、登録要求でモバイルネットワークにモバイルネットワークにモビリティサービスを提供することを許可されていることを確認できる必要があります。プレフィックスの転送は、それらのプレフィックスのモバイルルーターの承認を成功させなくても、セットアップしてはなりません。登録障害が発生したときにモバイルルーターに通知する必要があります。これは、要求されたプレフィックスに対して正常に承認できないためです。
All Registration Requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in RFC 3344 [RFC3344]. When the registration request is sent in explicit mode, i.e., with one or more Mobile Network Prefix extensions, all the Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension. Also, these extensions MUST be included in the calculation of the MN-HA authenticator value.
すべての登録要求と返信は、RFC 3344 [RFC3344]で指定されているMN-HA認証拡張機能によって認証される必要があります。登録要求が明示的なモード、つまり1つ以上のモバイルネットワークプレフィックス拡張機能を使用して送信される場合、MN-HA認証拡張の前にすべてのモバイルネットワークプレフィックス拡張機能を含める必要があります。また、これらの拡張機能は、MN-HA認証値の計算に含める必要があります。
The Mobile Router should perform ingress filtering on all the packets received on the Mobile Network prior to reverse tunneling them to the Home Agent. The Mobile Router MUST drop any packets that do not have a source address belonging to the Mobile Network.
モバイルルーターは、モバイルネットワークで受信したすべてのパケットでイングレスフィルタリングを実行する必要があります。モバイルルーターは、モバイルネットワークに属するソースアドレスがないパケットをドロップする必要があります。
The Mobile Router MUST also ensure that the source address of packets arriving on the Mobile Network is not the same as the Mobile Router's IP address on any interface. These checks will protect against nodes attempting to launch IP spoofing attacks through the bi-directional tunnel.
モバイルルーターは、モバイルネットワークに到着するパケットのソースアドレスが、インターフェイス上のモバイルルーターのIPアドレスと同じではないことを確認する必要があります。これらのチェックは、双方向トンネルを介してIPスプーフィング攻撃を起動しようとするノードから保護します。
The Home Agent, upon receiving packets through the bi-directional tunnel, MUST verify that the source addresses of the outer IP header of the packets are set to the Mobile Router's Care-of Address. Also, it MUST ensure that the source address of the inner IP header is a topologically correct address on the Mobile Network. This will prevent nodes from using the Home Agent to launch attacks inside the protected network.
ホームエージェントは、双方向トンネルを介してパケットを受信すると、パケットの外側IPヘッダーのソースアドレスがモバイルルーターのケアアドレスに設定されていることを確認する必要があります。また、内側のIPヘッダーのソースアドレスがモバイルネットワーク上のトポロジカルで正しいアドレスであることを確認する必要があります。これにより、ノードがホームエージェントを使用して保護されたネットワーク内で攻撃を起動することができなくなります。
If a dynamic routing protocol is used between the Mobile Router and the Home Agent to propagate the Mobile Network information into the home network, the routing updates SHOULD be protected with IPsec ESP confidentiality between the Mobile Router and Home Agent, to prevent information about home network topology from being visible to eavesdroppers.
モバイルルーターとホームエージェントの間で動的なルーティングプロトコルを使用してモバイルネットワーク情報をホームネットワークに伝播する場合、ルーティングの更新は、モバイルルーターとホームエージェント間のIPSEC ESP機密性で保護され、ホームネットワークに関する情報を防止する必要があります。トポロジーが盗聴者から見えるようになります。
IANA has assigned rules for the existing registry "Mobile IPv4 numbers - per RFC 3344". The numbering space for Extensions that may appear in Mobile IP control messages (those sent to and from UDP port number 434) should be modified.
IANAは、既存のレジストリ「モバイルIPv4番号-RFC 3344」にルールを割り当てました。モバイルIPコントロールメッセージ（UDPポート番号434に送信されるもの）に表示される拡張機能の番号付けスペースを変更する必要があります。
The new Values and Names for the Type for Extensions appearing in Mobile IP control messages are the following:
モバイルIPコントロールメッセージに表示される拡張機能のタイプの新しい値と名前は次のとおりです。
+-------+--------------------------+
| Value | Name |
+-------+--------------------------+
| 148 | Mobile Network Extension |
+-------+--------------------------+
Table 1: New Values and Names for Extensions in Mobile IP Control Messages
表1：モバイルIPコントロールメッセージの拡張機能の新しい値と名前
A new number space has been created for the Values and Names for the Sub-Type for Mobile Network Extensions. This number space is initially defined to hold the following entries, allocated by this document:
モバイルネットワークエクステンションのサブタイプの値と名前の新しい数字スペースが作成されました。この番号スペースは、最初に次のエントリを保持するために定義され、このドキュメントで割り当てられます。
+-------+-----------------------------------------+
| Value | Name |
+-------+-----------------------------------------+
| 0 | Mobile Network Request Extension |
| 1 | Explicit Mode Acknowledgement Extension |
| 2 | Implicit Mode Acknowledgement Extension |
+-------+-----------------------------------------+
Table 2: New Values and Names for the Sub-Type for Mobile Network Extensions
表2：モバイルネットワーク拡張機能のサブタイプの新しい値と名前
The policy of future assignments to this number space is following Standards Action or IESG Approval (see [RFC2434]).
この数のスペースに対する将来の割り当てのポリシーは、標準訴訟またはIESGの承認に従っています（[RFC2434]を参照）。
The new Code Values for Mobile IP Registration Reply messages are the following (for a registration denied by the Home Agent):
モバイルIP登録返信メッセージの新しいコード値は次のとおりです（ホームエージェントによって拒否された登録の場合）：
+-------+-----------------------------------------------------------+
| Value | Name |
+-------+-----------------------------------------------------------+
| 147 | Mobile Network Prefix operation error (HA_MOBNET_ERROR) |
| 148 | Mobile Router operation is not permitted |
| | (HA_MOBNET_DISALLOWED) |
+-------+-----------------------------------------------------------+
Table 3: New Code Values for Mobile IP Registration Reply
表3：モバイルIP登録返信の新しいコード値
A new number space has been created for the Code Values for the Mobile Network Acknowledgement Extension. This number space is initially defined to hold the following entries, allocated by this document (result of registration, as sent by the Home Agent):
モバイルネットワーク確認拡張のコード値に対して新しい番号スペースが作成されています。この番号スペースは、最初に次のエントリを保持するために定義されており、このドキュメント（ホームエージェントによって送信された登録の結果）によって割り当てられます。
+---+---------------------------------------------------------------+
| 0 | Success |
| 1 | Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) |
| 2 | Mobile Router is not authorized for prefix |
| | (MOBNET_UNAUTHORIZED) |
| 3 | Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) |
+---+---------------------------------------------------------------+
Table 4: New Code Values for Mobile Network Acknowledgement Extension
表4：モバイルネットワークの確認拡張機能の新しいコード値
The policy of future assignments to this number space is following Standards Action or IESG Approval (see [RFC2434]).
この数のスペースに対する将来の割り当てのポリシーは、標準訴訟またはIESGの承認に従っています（[RFC2434]を参照）。
The authors would like to thank Christophe Janneteau, George Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji Wakikawa, George Tsirtsis, and Henrik Levkowetz for their helpful discussions, reviews, and comments. Vijay Devarapalli extensively reviewed one of the later versions of the document. Hans Sjostrand identified the last clarifications with respect to Foreign Agent mode treatment. Pete McCann contributed necessary refinements of many statements.
著者は、クリストフ・ヤンネトー、ジョージ・ポポビッチ、タイ・ベキアレス、ガネーシュ・スリニバサン、アルペシュ・パテル、リュジ・ワキカワ、ジョージ・ツィルツシス、ヘンリック・レヴコウェッツに有益な議論、レビュー、コメントに感謝します。Vijay Devarapalliは、ドキュメントの後のバージョンの1つの1つを広範囲にレビューしました。Hans Sjostrandは、外国のエージェントモード治療に関する最後の説明を特定しました。ピート・マッキャンは、多くの声明の必要な改良を提供しました。
Mobile IPv4 versions as early as 1996 (RFC 2002 by Charles Perkins) described Mobile Networks and Mobile Routers support.
1996年には、モバイルIPv4バージョン（Charles PerkinsによるRFC 2002）は、モバイルネットワークとモバイルルーターのサポートについて説明しました。
Fred Templin indicated the potential confusion for the term "LFN".
フレッド・テンプリンは、「LFN」という用語の潜在的な混乱を示しました。
Amanda Baber of IANA agreed on the principles of allocating numbers for this specification and suggested improvements on the IANA section.
IanaのAmanda Baberは、この仕様に数値を割り当てる原則に同意し、IANAセクションでの改善を提案しました。
Tim Polk of the IESG identified a deeply entrenched error on managing the Code fields.
IESGのTim Polkは、コードフィールドの管理に関する深く定着したエラーを特定しました。
Lars Eggert of the IESG suggested the accommodation of the otherwise legal non-contiguous netmask fields, instead of simply prefix lengths.
IESGのLars Eggertは、単に接頭辞の長さではなく、法的でない非連続したネットマスクフィールドの収容を提案しました。
Dan Romascanu of the IESG indicated the necessity of manageability of Mobile Routers and NEMOv4-enabled Home Agents and their deployability in MIP4 environments.
IESGのDan Romascanuは、モバイルルーターとNemov4対応のホームエージェントの管理可能性の必要性と、MIP4環境での展開性を示していました。
David Borman of TSV-DIR reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. The implications of the growth of usable MTU adversely affecting applications deep in a Mobile Network were suggested.
TSV-DirのDavid Bormanは、主要なIETFドキュメントをレビューするための輸送エリア局の継続的な取り組みの一環として、この文書をレビューしました。使用可能なMTUの成長が、モバイルネットワークの深いアプリケーションに悪影響を与えることの意味が示唆されました。
Gonzalo Camarillo provided a generalist review by an additional set of eyes for documents as they are being considered for publication (General Area Review Team).
Gonzalo Camarilloは、公開とみなされているため、文書の追加の目を追加した一般主義者のレビューを提供しました（一般的なエリアレビューチーム）。
Jari Arkko of the IESG reviewed, suggested necessary improvements to, and diligently shepherded this document through IESG.
IESGのJari Arkkoがレビューし、必要な改善を提案し、IESGを介してこのドキュメントを熱心に阻止しました。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のためのTCP拡張」、RFC 1323、1992年5月。
[RFC2006] Cong, D., Hamlen, M., and C. Perkins, "The Definitions of Managed Objects for IP Mobility Support using SMIv2", RFC 2006, October 1996.
[RFC2006] Cong、D.、Hamlen、M。、およびC. Perkins、「SMIV2を使用したIPモビリティサポートの管理オブジェクトの定義」、RFC 2006、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[NEMOv4-FA] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA extensions to NEMOv4 Base", Work in Progress, February 2008.
[Nemov4-Fa] Tsirtsis、G.、Park、V.、Narayanan、V.、およびK. Leung、「FA拡張nemov4ベース」、2008年2月の作業進行中。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885] Ernst、T。およびH-Y。Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
Authors' Addresses
著者のアドレス
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
Phone: +1 408-525-1404
EMail: gdommety@cisco.com
Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA
Vidya Narayanan Qualcomm、Inc。5775 Morehouse Dr San Diego、CA米国
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette, Essonne 91140 France
Alexandru Petrescu Motorola Parc Les Algorithmes Saint Aubin Gif-Sur-Yvette、Essonne 91140 France
Phone: +33 169354827
EMail: alexandru.petrescu@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。