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
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.
モバイルネットワークは、ホストとルータのセットを一緒にリンクします。インターネットには、このモバイルネットワークの接続は、二つのレベルで確保されている：最初、モバイルルータは、モバイルネットワークに無線アクセスシステムへの別の側に一方の側に接続されています。二、ホームエージェントは、トラフィックをカプセル化によって、相手ノードとローカル固定ノード（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.
このモバイルネットワークのための適用のシナリオについて説明します。モバイルネットワークは、Bluetooth無線リンク層技術によって互いにリンクワイヤレス対応パーソナルデジタルアシスタント（PDA）や携帯写真カメラ、によって形成されます。これは、時々、パーソナルエリアネットワーク（PAN）と呼ばれています。以下の図では、1は、モバイルルータとカメラローカル固定ノードの役割の役割を果たして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
広範囲モバイルIPv4 [RFC3344]に関連し、本明細書では主に同じ場所に配置さ気付アドレスモードに対処します。外部エージェント気付アドレスモード（「レガシー」外国人のエージェント[RFC3344]で）です
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].
サポートされていますが、最適化せず、かつ使用されている二重のカプセル化。このモードの最適化のために、穏やかな読者は、拡張文書[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]で定義されています。ネットワークモビリティサポート（NEMO）のための用語は、IPv6の観点から、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.
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".
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仕様はモバイルネットワークは、（RFC 3344のセクション4.5 [RFC3344]を参照）静的な構成を使用して、またはルーティングプロトコルを実行しているモバイルルータとホームエージェントによってサポートすることができると述べているが、携帯電話の明示的な登録のための解決策は存在しませんモバイルルータが提供するネットワーク。ソリューションは、ホームエージェントに特定のモバイルネットワークプレフィックスを主張するモバイルルータがそうすることを許可されていることを確実にする手段を提供する必要があります。溶液はまた、ネットワークのデバッグを支援するために、交換されるメッセージにモバイルネットワークプレフィックス（及び潜在的に他のサブネットの関連情報）を露出させることになります。
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モバイルルータは、明示的または暗黙的なモードで動作することができなければなりません。モバイルルータは、明示的にモバイルネットワーク（s）は、ルーティングプロトコルを介して伝播する必要がホームエージェントに通知することができます。モバイルルータは、ホームエージェントは事前構成を介して、または動的ルーティングプロトコルを介して、AAAサーバからなど、他の手段を介してモバイルネットワークを学習することができる暗黙モードで機能することができます。
o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 [RFC3344] without any changes ('legacy' Foreign Agents).
モバイルネットワークは、すべての変更（「レガシー」外国人のエージェント）せずにRFC 3344 [RFC3344]に準拠している外国人のエージェントを使用してサポートする必要がありますoを。
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:
明示モードでは、モバイルルータは、登録時にモバイルネットワークプレフィックスについてのホーム・エージェントに通知します。登録要求には、0個、1個、または[RFC3344]によって、またはRFC 3344のコンテキストで定義された他の拡張機能に加えて、いくつかのモバイルネットワーク要求の拡張を含んでいます。いくつかのモバイルネットワークを登録する必要がある場合は、それぞれが独自のタイプ、長さ、サブタイプ、プレフィックス長、プレフィックスと、別のモバイルネットワーク・リクエスト・拡張に含まれています。モバイルネットワーク要求拡張は、タイプレングス値（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.
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.
Prefix:
接頭辞：
32-bit unsigned integer in network byte-order containing an
IPv4 address whose leftmost Prefix Length bits make up the
Mobile Network Prefix.
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つまたはいくつかのモバイルネットワーク肯定応答の拡張を含んでいます。暗黙モードの場合は、モバイルネットワーク謝辞モバイルルータにホームエージェントは、このモバイルルータに対する転送を設定しているためプレフィックスを通知します。そのようなホームエージェントにトンネリングするこれらのモバイルネットワークからのトラフィックのみを許可するようにポリシーがモバイルルータによって適用することができます。いくつかのモバイルネットワークを明示的に承認される必要がある明示モードについては、それぞれが独自のタイプ、サブタイプ、長さ、プレフィックス、およびプレフィックス長のフィールドで、別のモバイルネットワーク謝辞拡張に含まれています。少なくとも一つのモバイルネットワーク謝辞拡張は、モバイルネットワークの要求拡張が処理されたので、ホームエージェントによってスキップされていなかったモバイルルータに示すために、成功した登録応答でなければなりません。
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.
登録応答は明示モードと暗黙モード謝辞サブタイプのいずれかの非ゼロの数を含んでいてもよいです。両方のサブタイプは、単一の登録応答中に存在することができます。モバイルネットワーク肯定応答拡張は、タイプレングス値（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.
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.
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]に設定されたモバイルルータの動作は、一般的に、移動ノードの挙動に由来します。一緒にホームエージェントと、そのホームアドレス、モバイルルータのためのモビリティバインディングを維持することに加えて、モバイルルータに割り当てられたモバイルネットワークプレフィックス（複数可）についての情報を転送して保持しています。
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:
モバイルルータは、それがすべてのトラフィックのために逆方向トンネルの必要性を示すために送信するすべての登録要求メッセージで1に「T」ビットを設定する必要があります。逆方向トンネルがなければ、モバイルネットワークからのすべてのトラフィックは、訪問先ネットワーク内の入口フィルタリングの対象となります。成功した登録応答を受信すると、モバイルルータは、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以外の手段によって、モバイルネットワークプレフィックスを取得します。モバイルネットワークプレフィックスを得るための一つの例は、ホームエージェントの静的な構成を介して行われます。
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.
登録解除のために、モバイルルータは、任意のモバイルネットワーク・リクエスト・拡張することなく、ゼロに設定寿命の登録要求を送信します。
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つのコードフィールドがあってもよいです。モバイルルータは、ホームエージェントによってモバイルネットワークプレフィックスの管理に関連するすべてのエラーを特定するために、登録応答のモバイルネットワーク謝辞拡張内のコードフィールドの値を解釈します。それはまた、登録応答ヘッダ（適切なコード）のコードフィールドの値を解釈します。
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]に基づいて登録を処理します。また、モバイルルータは、明示モードで登録するために、以下のステップがとられます：
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.モバイルルータへのトンネルを作成します。
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.モバイルネットワーク謝辞拡張子（S）で登録応答を送信します。
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]はホームエージェントに登録するモバイルノードのホームアドレスは、ホームネットワーク上で公示プレフィックスに属していなければならないことを指定します。この仕様書に従い、しかし、ホームアドレスはホームエージェント、ホームネットワーク上必ずしも1によって提供されるプレフィックスから構成する必要があります。
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.
ホームエージェントは、モバイルルータのための既存のバインディングエントリを更新している場合は、登録要求に含まれるプレフィックスに対して登録テーブルにすべてのプレフィックスをチェックしなければなりません。一つ以上のモバイルネットワークプレフィックスは、登録要求に含まれる情報から欠落している場合は、ホームエージェントは、登録テーブルからこれらの接頭辞を削除しなければなりません。また、ホームエージェントは、これらの接頭辞の転送を無効にする必要があります。
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).
すべてのチェックが成功した場合、ホームエージェントは、モバイルルータのための新しいエントリを作成するか、またはそれのための既存のバインディングエントリを更新し、登録要求がAから受信された場合、バックモバイルルータまたは外部エージェント（に成功した登録応答を返すのいずれか外部エージェント）。
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.
ホームエージェントは、登録要求とモバイルルータによってサービス提供される少なくとも1つのモバイルネットワークプレフィックスの転送の成功セットアップの処理の成功を示すために0に登録応答のステータスコードを設定しなければなりません。登録応答は、少なくとも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進より大きい場合、ステータスコードがMOBNET_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アドレスを設定してもう一回をカプセル化ホームエージェント、とCoAに設定された宛先IPアドレス）へ。
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モードのトンネルヘッダ（COAに設定ホームエージェントに設定されたソースIPアドレス、宛先IPアドレス）を持つパケットをカプセル化するべきです。
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アドレス）と、ワンより多くの時間をカプセル化することができます。
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]及び[RFC2453]をRIP。
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.
勧告はどのように関連しているかのルーティングプロトコルと自宅やモバイルルータに転送情報ベースにインコヒーレント状態を作成せずに、モバイルルータとホームエージェント（1）上のタンデムでのモバイルIPv4の実装作業、（2）なし訪問ドメインにトポロジー的に正しく対処する情報を導入し、（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登録要求に送るべきではありません。これは、転送情報ベースにincoherenciesを回避することができます。モバイルルータは、この場合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は、既存のレジストリ「 - RFC 3344あたりのモバイルIPv4番号」のルールを割り当てています。モバイル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]).
この数のスペースに、将来の割り当ての方針は、（[RFC2434]を参照）標準アクションまたはIESGの承認以下です。
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]).
この数のスペースに、将来の割り当ての方針は、（[RFC2434]を参照）標準アクションまたはIESGの承認以下です。
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.
作者は彼らの役に立つ議論、レビュー、およびコメントのためクリストフJanneteau、ジョージ・ポポビッチ、TyのBekiares、ガネーシャスリニバサン、Alpeshパテル、隆次Wakikawa、ジョージTsirtsis、とヘンリクLevkowetzに感謝したいと思います。ビジェイDevarapalliは、広範囲に文書の以降のバージョンのいずれかを検討しました。ハンスSjostrandは、外部エージェントモード処理に対する最後の明確化を同定しました。ピートマッキャンは、多くの書類の必要な改良に貢献しました。
Mobile IPv4 versions as early as 1996 (RFC 2002 by Charles Perkins) described Mobile Networks and Mobile Routers support.
モバイルIPv4バージョンは早ければ1996年（チャールズ・パーキンスによる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のアマンダBaberは、この仕様のために番号を割り当てる原則に合意し、IANA部分の改善を示唆しました。
Tim Polk of the IESG identified a deeply entrenched error on managing the Code fields.
IESGのティム・ポークは、コードフィールドの管理に深く定着し、エラーを特定しました。
Lars Eggert of the IESG suggested the accommodation of the otherwise legal non-contiguous netmask fields, instead of simply prefix lengths.
IESGのラース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のダン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のデビッド・ボーマンはキー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).
彼らは出版物（一般エリア審査チーム）のために検討されているようゴンサロ・カマリロは、文書のための目の追加セットでジェネラリストのレビューを提供します。
Jari Arkko of the IESG reviewed, suggested necessary improvements to, and diligently shepherded this document through IESG.
IESGのヤリArkkoは、審査に必要な改善を提案し、熱心にIESGを通じてこの文書を導きました。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのための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]コング、D.、Hamlen、M.、およびC.パーキンス、RFC 2006、1996年10月 "SMIv2のを使用してIPモビリティサポートのための管理オブジェクトの定義"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、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]マルキン、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]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル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.、公園、V.、ナラヤナン、V.、およびK.レオン、 "NEMOv4ベースにFAの拡張"、進歩、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.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885]エルンスト、T.およびH-Y。 LACH、 "ネットワークモビリティサポート用語"、RFC 4885、2007年7月。
Authors' Addresses
著者のアドレス
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
ケント・レオンシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408-526-5030 EMail: kleung@cisco.com
電話：+1 408-526-5030電子メール：kleung@cisco.com
Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
ゴパルDommetyシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408-525-1404 EMail: gdommety@cisco.com
電話：+1 408-525-1404電子メール：gdommety@cisco.com
Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA
VidyaナラヤナンQUALCOMM社5775モアハウス博士サンディエゴ、CA USA
Phone: +1 858-845-2483 EMail: vidyan@qualcomm.com
電話：+1 858-845-2483電子メール：vidyan@qualcomm.com
Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette, Essonne 91140 France
アレクサンドル・ペトレスクモトローラパークアルゴリズムサントーバンジフ=シュル=イヴェット、エソンヌ91140フランス
Phone: +33 169354827 EMail: alexandru.petrescu@motorola.com
電話：+33 169354827 Eメール：alexandru.petrescu@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at 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に情報を記述してください。