RFC5177 日本語訳
5177 Network Mobility (NEMO) Extensions for Mobile IPv4. K. Leung, G.Dommety, V. Narayanan, A. Petrescu. April 2008. (Format: TXT=56094 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
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
コメントを求めるワーキンググループK.レオン要求をネットワークでつないでください: 5177年のG.Dommetyカテゴリ: 標準化過程シスコシステムズV.ナラヤナンクアルコムInc.A.ペトレスクモトローラ2008年4月
Network Mobility (NEMO) Extensions for Mobile IPv4
モバイル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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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プロトコルを広げることによってモバイルRouterとホームのエージェントの間のモバイルNetworksをサポートするためにプロトコルについて説明します。 モバイルRouterは1つ以上のネットワークセグメントか一緒に移行するサブネットの移動性に責任があります。 モバイルRouterはモバイルNetworkにノードから移動性を隠します。 モバイルNetworkの上のノードは、モバイルRouterとの関係で修理されていて、どんな移動性機能も持っていないかもしれません。
Extensions to Mobile IPv4 are introduced to support Mobile Networks.
モバイルNetworksをサポートするためにモバイルIPv4への拡大を導入します。
Leung, et al. Standards Track [Page 1] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[1ページ]RFC5177
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 モバイルネットワーク. . . . . . . . . . . . . . . 3 1.2に関する例。 プロトコル. . . . . . . . . . . . . . . . . . . 5 2の概要。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 6 3。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 7 4。 モバイルネットワーク拡大. . . . . . . . . . . . . . . . . . 8 4.1。 モバイルネットワーク要求拡張子. . . . . . . . . . . . . 8 4.2。 モバイルネットワーク承認拡大. . . . . . . . . 9 5。 モバイルルータ操作. . . . . . . . . . . . . . . . . . . 11 5.1。 エラー処理. . . . . . . . . . . . . . . . . . . . . 12 5.2。 モバイルルータ管理. . . . . . . . . . . . . . . . . 12 6。 ホームエージェント操作. . . . . . . . . . . . . . . . . . . . . 13 6.1。 概要. . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2。 データ構造. . . . . . . . . . . . . . . . . . . . . 14 6.2.1。 レジスタ・テーブル. . . . . . . . . . . . . . . . . . 14 6.2.2。 テーブル. . . . . . . . . . . . . . . . . . . . . 14 6.3を前に置いてください。 モバイルネットワーク接頭語登録. . . . . . . . . . . . 14 6.4。 モバイルネットワークの可到達性. . . . . . . . . 16 6.5の広告を出します。 双方向のトンネル設立. . . . . . . . . . 16 6.6。 登録回答. . . . . . . . . . . . . . . 17 6.7を送ります。 モバイルネットワーク接頭語Deregistration. . . . . . . . . . . 17 7。 データ推進操作. . . . . . . . . . . . . . . . . . 17 8。 入れ子にされたモバイルネットワーク. . . . . . . . . . . . . . . . . . . . 18 9。 モバイルルータとホームのエージェント. . . . 18 10の間にプロトコルを発送します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 10.1。 セキュリティいつDynamicルート設定プロトコルIs Used. . . . . . 20 11 IANA問題. . . . . . . . . . . . . . . . . . . . . 20 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 22 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 24
Leung, et al. Standards Track [Page 2] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[2ページ]RFC5177
1. Introduction
1. 序論
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プロトコルに説明します。 これらの拡大を導入するという目標はホストとルータのグループが等質的(全体で)に移行する移動性シナリオに対応することです。 モバイルNetworkのすべてのホストとルータがインターネットに接続するアプリケーションを実行できて、インターネットから届いているのが必要です。
For details regarding terminology related to network mobility (NEMO), a quick read of RFC 4885 [RFC4885] is suggested.
ネットワークの移動性(ネモ)に関連する用語に関する詳細に関しては、RFC4885[RFC4885]の迅速な読書は示されます。
1.1. Examples of Mobile Networks
1.1. モバイルネットワークに関する例
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.
モバイルNetworkは1セットのホストとルータを結びつけます。 このモバイルNetworkをインターネットに接続するのは2つのレベルで確実にされます: まず最初に、モバイルRouterはモバイルNetworkへの半面とワイヤレス・アクセスシステムへの別の側で接続されます。 2番目に、トラフィックをカプセル化することによってホームのリンクに置かれたホームのエージェントはCorrespondent NodeとLocal Fixed Node(LFN、モバイルNetworkのノード)の間のトラフィックを管理します。
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.
このモバイルNetworkのための適用性のシナリオは次に、説明されます。 モバイルNetworkはワイヤレスで可能にされたパーソナル・デジタル・アシスタント(PDA)とブルートゥースワイヤレスリンクレイヤ技術で結びつけられた携帯用の写真用カメラによって形成されます。 これは時々パーソナル・エリア・ネットワーク(PAN)と呼ばれます。 以下のイラストでは、人は、PDAがモバイルRouterの役割を果たしているのに気付くことができて、カメラはLocal Fixed Nodeの役割に気付きます。
Leung, et al. Standards Track [Page 3] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[3ページ]RFC5177
----
| HA |
---- --------
| / \ ----
-+--------| Internet |---------| CN |
\ / ----
--------
/ \
/ \
/ \
---- ----
| AR | | AR |
---- ----
|cellular |cellular
---- | ハ| ---- -------- | / \ ---- -+--------| インターネット|---------| CN| \ / ---- -------- / \ / \ / \ ---- ---- | アルゴン| | アルゴン| ---- ---- |セル|セル
/ |cellular
| ---- ----
Mobile | | MR | |LFN | ---movement-->
Network < ---- ----
| | |
| -+-----------+-
\ Bluetooth
/ |セル| ---- ---- モバイル| | さん| |LFN| ---動き-->Network<。---- ---- | | | | -+-----------+\ブルートゥース
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.
カメラ(地方のFixed Node)はCorrespondent Node(CN)サーバに写真内容をアップロードします。モバイルNetworkが遠くに移行すると、モバイルNetworkに役立つモバイルRouterは別のものへのあるセルアクセス(アクセスRouter)から接着点を変えます、新しい状態でaを得てCare、-、Address。 ホームのエージェント(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ベースのモバイルNetworksの適用性の非常に簡単な具体化ですが、本書では提示されたモバイルIPv4拡張子(NEMOv4)で、より複雑なモバイルNetworksは容易に設備されます。 例えば、バス、列車、船、または飛行機で乗客によって使用されたラップトップコンピュータはモバイルNetworksを形成しながら、すべてみなされるべきです、彼らが一緒に(等質的である)移行する限り。
Leung, et al. Standards Track [Page 4] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[4ページ]RFC5177
1.2. Overview of Protocol
1.2. プロトコルの概要
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プロトコルに拡大を提示します。 これらの拡大を送って、受ける実体は、モバイルRouterとホームのエージェントです。 モバイルIPソフトウェアと移行するときの(モバイルNetworkと共に)そのIPスタックを動かすのから、アドレシングにおける少しの変化も見えていませんLocal Fixed Nodeが安心している。
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:
全体のモバイルNetworkのための移動性が現在の接着点を示すモバイルRouterによってサポートされる、(注意、-、Address) ホームのエージェントに: モバイルRouterは拡張Registration Requestをホームのエージェントに送ります。(そのエージェントは、拡張Registration Replyを返します)。 このシグナリングは以下の図で例証されるように2つの実体の間のトンネルを設立します:
LFN MR HA CN
| | | |
| | Extended Registration | |
| |---------------------->| |
| | Request | |
| | | |
| | | |
| | Extended Registration | |
| |<----------------------| |
| | Reply | |
| | | |
|<--------o=======================o-------->|
| | Encapsulated | |
| | Application Traffic | |
| | | |
ハ、LFN CNさん| | | | | | 拡張登録| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 要求| | | | | | | | | | | | 拡張登録| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 返信| | | | | | | <、-、-、-、-、-、-、--o=======================o-------->|、|、| 要約します。| | | | アプリケーショントラフィック| | | | | |
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.
モバイルNetwork(ホームのエージェントの上でそれとなく構成されるか、またはRegistration RequestでモバイルRouterによって明らかに特定される)の中で使用された接頭語(es)は/がホームネットワークにおけるルート伝播のためにホームのエージェントによって広告を出されるということです。 ノードとモバイルNetworkのノードからのトラフィックはモバイルRouterのホームのエージェントによってトンネルを堀られます、逆もまた同様に。 モバイルRouterは直接トンネリングなしでモバイルNetworkに置かれたLocal Fixed Nodeからのパケットを進めることができますが(逆のトンネリングが使用されなかったなら)、イングレスフィルタリングがAccess Routerでつけられていると、これらのパケットは下げられるでしょう。
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]に関連して、この仕様が共同見つけられるのを主に扱う、Care、-、Addressモード。 外国人のエージェント、Care、-、Addressモード('レガシー'Foreignエージェント[RFC3344]がいる)はそうです。
Leung, et al. Standards Track [Page 5] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[5ページ]RFC5177
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と比べて、このドキュメントはモバイルRouterのホームAddressとホームのエージェントの間の追加トンネルを指定します。 このトンネルが間に正常なトンネルの中でカプセル化される、Care、-、Address(CoA)とホームのエージェント。 ForeignエージェントCoAモードで、モバイルRouterとホームのエージェントの間のトンネルが、Foreignエージェントが適切な訪問モバイルRouterにdecapsulatedパケットを向けるのを許容するのが必要です。 しかしながら、共同見つけられたCoAモードで、モバイルRouterがモバイルNetworkのためのカプセル化されたパケットの受取人であるので、追加トンネルは、不可欠でなく、排除できるでしょう。 この特徴のための提案が前記のように広がりドキュメント[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.
モバイルNetworkとCorrespondent Nodesのノードの間のすべてのトラフィックがホームのエージェントを通り抜けます。 このドキュメントはこのトラフィックの経路最適化に関連する局面に触れません。
A similar protocol has been documented in RFC 3963 [RFC3963] for supporting IPv6 Mobile Networks with Mobile IPv6 extensions.
同様のプロトコルは、IPv6がモバイルIPv6拡張子があるモバイルNetworksであるとサポートするためにRFC3963[RFC3963]に記録されました。
Multihoming for Mobile Routers is outside the scope of this document.
このドキュメントの範囲の外にモバイルRoutersのためのマルチホーミングがあります。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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移動性サポートのための用語はRFC3344[RFC3344]で定義されます。 IPv6見解から、ネットワーク移動性サポート(ネモ)のための用語はRFC4885[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.
RFC3344[RFC3344]は一緒に移行する1つ以上の全体のネットワークの移動性に原因となるルータであるかもしれないモバイルノードとモバイルRouterを定義します、恐らく飛行機、船、列車、自動車、自転車、またはカヤックの上に。
Leung, et al. Standards Track [Page 6] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[6ページ]RFC5177
Mobile Network Prefix
モバイルネットワーク接頭語
The network prefix of the subnet delegated to a Mobile Router
as the Mobile Network.
サブネットのネットワーク接頭語はモバイルNetworkとしてモバイルRouterに委任しました。
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.
モバイルNetwork PrefixesのリストはモバイルRouterのホームAddressで索引をつけました。 ホームのエージェントは、どのモバイルNetwork Prefixesが特定のモバイルRouterに属すかを決定するのにPrefix Tableを管理して、使用します。
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".
RFC4885[RFC4885]は、Networkと接着点を変えることができないモバイルに属す固定ノードになるように、Local Fixed Node(LFN)を定義します。 少なくとも後者が"elephan(t)"であると断言されますが、NEMO LFNが"elefen"であるとはっきりと断言されるので、この定義はRFC1323[RFC1323]について「長くて、太っているネットワーク、LFN」に混乱するべきではありません。
3. Requirements
3. 要件
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仕様は、静的な構成を使用するか、またはルーティング・プロトコルを実行するモバイルRouterとホームのエージェントがモバイルNetworksをサポートすることができると述べましたが(RFC3344[RFC3344]のセクション4.5を見てください)、モバイルRouterによって役立たれたモバイルNetworksの明白な登録のためのソリューションが全くありません。 ソリューションは、あるモバイルNetwork Prefixを要求するモバイルRouterがそうするのが認可されるのを保証する手段をホームのエージェントに提供する必要があります。 また、ソリューションは、ネットワークデバッグで支援するために、交換されたメッセージでモバイルNetwork Prefixes(そして、潜在的に他のサブネット関連している情報)を暴露するでしょう。
The following requirements for Mobile Network support are enumerated:
モバイルNetworkサポートのための以下の要件は列挙されます:
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 モバイルRouterは明白であるか暗黙のモードで作動するはずであることができます。 モバイルRouterは、どのモバイルNetwork(s)が、ルーティング・プロトコルで伝播される必要であるかを明らかにホームのエージェントに知らせるかもしれません。 また、モバイルRouterは暗黙のモードで機能するかもしれません。そこでは、ホームのエージェントがAAAサーバなどの他の手段を通して、または、プレ構成かダイナミックルーティングプロトコルでモバイルNetworksを学ぶかもしれません。
o The Mobile Network should be supported using Foreign Agents that
are compliant to RFC 3344 [RFC3344] without any changes ('legacy'
Foreign Agents).
o モバイルNetworkは、少しも変化('レガシー'Foreignエージェント)なしでRFC3344[RFC3344]に言いなりになっているForeignエージェントを使用することでサポートされるべきです。
Leung, et al. Standards Track [Page 7] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[7ページ]RFC5177
o The Mobile Network should allow Fixed Nodes, Mobile Nodes, or
Mobile Routers to be on it.
o モバイルNetworkがそれにFixed Nodes、モバイルNodes、またはモバイルRoutersをあるはずです。
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 モバイルNetworkの上のLocal Fixed Nodesは実行しているモバイルIPスタックなしで彼らのセッションを実行するはずであることができます。 LFNsのモバイルNetworkが変化のような移動性イベントを'隠している'モバイルRouter管理、Care、-、そのモバイルNetworkのLocal Fixed NodesからのAddress。
4. Mobile Network Extensions
4. モバイルネットワーク拡大
4.1. Mobile Network Request Extension
4.1. モバイルネットワーク要求拡張子
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:
Explicit Modeに関しては、モバイルNetwork Prefixesに関してモバイルRouterは登録の間、ホームのエージェントに知らせます。 文脈かRFC3344の文脈でRegistration Requestはゼロを含んでいます、1かいかなる他の拡大に加えたいくつかのモバイルNetwork Request拡張子が[RFC3344]を定義しました。 数個のモバイルNetworksが、登録される必要があるとき、それぞれが別々のモバイルNetwork Request拡張子で含まれています、それ自身のType、Length、Sub-タイプ、Prefix Length、およびPrefixと共に。 モバイルNetwork Request拡張子は、Type長さ価値(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
以下をタイプしてください。
148 Mobile Network Extension
148 モバイルネットワーク拡大
Length:
長さ:
Decimal 6.
小数6。
Sub-Type:
サブタイプ:
0 (Mobile Network Request)
0 (モバイルネットワーク要求)
Leung, et al. Standards Track [Page 8] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[8ページ]RFC5177
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分野に保管されていたアドレスのネットワーク部分をカバーする一番左ビットの数を示す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.
一番左Prefix LengthビットがモバイルNetwork Prefixを作るIPv4アドレスを含むネットワークバイトオーダーにおける32ビットの符号のない整数。
4.2. Mobile Network Acknowledgement Extension
4.2. モバイルネットワーク承認拡大
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.
文脈かRFC3344の文脈でRegistration Replyはゼロを含んでいます、1かいかなる他の拡大に加えたいくつかのモバイルNetwork Acknowledgement拡張子が[RFC3344]を定義しました。 Implicit Mode、Network AcknowledgementがモバイルRouterに知らせるモバイルに関しては、このモバイルRouterに関してホームのエージェントがセットする接頭語は推進を上げます。 これらのモバイルNetworksからのトラフィックだけがホームのエージェントにトンネルを堀られることを許可などなどの方針はモバイルRouterによって適用されるかもしれません。 数個のモバイルNetworksが、明らかに承認される必要があるとき、Explicit Modeに関しては、それぞれが別々のモバイルNetwork Acknowledgement拡張子で含まれています、それ自身のType、Sub-タイプ、Length、Prefix、およびPrefix Length分野で。 モバイルNetwork Request拡張子が処理されて、したがって、ホームのエージェントがスキップされなかったのをモバイルRouterに示すために、少なくとも1つのモバイルNetwork Acknowledgement拡張子がうまくいっているRegistration Replyにあるに違いありません。
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.
Registration Replyはどんな非ゼロ番号のExplicit ModeとImplicit Mode Acknowledgementsサブタイプも含むかもしれません。 両方のサブタイプは独身のRegistration Replyに出席している場合があります。 モバイルNetwork Acknowledgement拡張子はType長さの価値(TLV)の形式でコード化されます。 登録がCode HA_MOBNET_ERROR(Registration Replyのコード分野)と共に否定されるとき、含まれているモバイルNetwork ExtensionのCode分野は失敗の理由を提供します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語の長さ| 予約されます。| 前に置きます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leung, et al. Standards Track [Page 9] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[9ページ]RFC5177
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_病人接頭語_レン)
2 Mobile Router is not authorized for prefix
(MOBNET_UNAUTHORIZED)
2 モバイルRouterは接頭語のために認可されません。(MOBNET_権限のない)です。
3 Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED)
3 推進セットアップは失敗しました。(セットアップ_が失敗したMOBNET_FWDING_)
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分野に保管されていたアドレスのネットワーク部分をカバーする一番左ビットの数を示す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.
一番左Prefix LengthビットがモバイルNetwork Prefixを作るIPv4アドレスを含むネットワークバイトオーダーにおける32ビットの符号のない整数。
Leung, et al. Standards Track [Page 10] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[10ページ]RFC5177
5. Mobile Router Operation
5. モバイルルータ操作
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.
一般に、RFC3344[RFC3344]に設定されるようにモバイルNodeの動きからモバイルRouterの操作を得ます。 ホームAddressのために移動性結合を維持することに加えて、モバイルRouterはホームのエージェントと共にモバイルRouterに割り当てられたモバイルNetwork Prefix(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'がそれが逆の必要性を示すために送るすべてのRegistration Requestメッセージで1まで噛み付いたモバイルRouter SHOULDセットはすべてのトラフィックのためにトンネルを堀ります。 逆のトンネルがなければ、モバイルNetworkからのすべてのトラフィックが訪問されたネットワークにおけるイングレスフィルタリングを受けることがあるでしょう。 うまくいっているRegistration Replyのレセプションでは、モバイルRouterはRFC3344[RFC3344]に一致における登録を処理します。 さらに、以下の方法を取ります:
o Check for Mobile Network Acknowledgement extension(s) in
Registration Reply.
o Registration ReplyのモバイルNetwork Acknowledgement拡張子がないかどうかチェックしてください。
o Create tunnel to the Home Agent if the Mobile Router is registered
in reverse tunneling mode.
o モバイルRouterが逆のトンネリングモードで登録されるなら、ホームのエージェントにトンネルを作成してください。
o Set up default route via this tunnel or egress interface when the
Mobile Router is registered with or without reverse tunneling,
respectively.
o それぞれトンネルを堀って、モバイルRouterが逆のあるなしにかかわらず登録されたらこのトンネルか出口のインタフェースを通してデフォルトルートをセットアップしてください。
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.
この仕様に従って、モバイルRouterは以下の2つのモードの1つで作動するかもしれません: 明白であって、暗黙です。 明白なモードでは、モバイルRouterはすべてのRegistration Requests(モバイルNetwork Request拡張子としての)のモバイルNetwork Prefix情報を含んでいます、暗黙のモードにどんなRegistration Requestのこの情報も含んでいませんが。 後者の場合では、ホームのエージェントはモバイルIP以外の手段でモバイルNetwork Prefixesを入手します。 ホームのエージェントでの静的な構成を通してモバイルNetwork Prefixを入手する1つの例があります。
A Mobile Router can obtain a co-located or Foreign Agent Care-of Address while operating in explicit or implicit modes.
モバイルRouterが共同見つけられるかForeignエージェントを得ることができる、Care、-、Addressは明白であるか暗黙のモードにおける作動をゆったり過ごします。
For deregistration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions.
反登録に関しては、モバイルRouterは少しもモバイルNetwork Request拡張子なしで生涯セットによる登録要求をゼロに送ります。
Leung, et al. Standards Track [Page 11] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[11ページ]RFC5177
5.1. Error Processing
5.1. エラー処理
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 Registration Replyメッセージには、2つのCode分野があるかもしれません: Registration Replyヘッダーにおける1つの自体('適切な'Code)とモバイルNetwork Acknowledgement Extensionの中の1(単に'コード')。 モバイルRouterは、ホームのエージェントでモバイルNetwork Prefixesを管理すると関連するどんな誤りも特定するためにRegistration ReplyのモバイルNetwork Acknowledgement ExtensionのCode分野の値を解釈します。 また、それはRegistration Replyヘッダー(適切なCode)のCode分野の値を解釈します。
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.
Registration Reply(適切)のCode分野の値がHA_MOBNET_DISALLOWEDに設定されるなら、モバイルRouterは、どんなモバイルNetwork Prefix拡張子があるRegistration Requestsもそのホームのエージェントに送るのを止めなければなりません。
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.
Registration Reply(適切)のCode分野の値がHA_MOBNET_ERRORに設定されるなら、モバイルRouterは、分野のPrefixとPrefix Lengthの値によってモバイルNetwork Acknowledgement拡張子で定義されるモバイルNetwork Prefixesのいずれも含むRegistration Requestsを送るのを止めなければなりません。 登録がこの場合否定されて、どんなモバイルNetwork Prefixesのためのも進めないことがモバイルRouterのホームのエージェントによってセットアップされることに注意してください。
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ホームのエージェントによって処理されたならモバイルRouterがモバイルNetwork拡張子なしでRegistration Replyを受けるのは、可能です。 その場合、モバイルRouterはホームのエージェントがモバイルNetworksをサポートしないケースとしてモバイルNetwork拡張子の欠如を解釈しなければなりません。
All the error code values have been assigned by IANA; see Section 11.
すべての誤りコード値がIANAによって割り当てられました。 セクション11を見てください。
5.2. Mobile Router Management
5.2. モバイルルータ管理
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環境でモバイルRouterを操作するのにおいて、進行中の状態情報の必要な初期の構成と指揮の管理に関する、ある要件があります。 モバイルRouterメインテナンスインディケータは、他のモバイル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のためのManagement Information基地(MIB)へのオブジェクトはRFC2006[RFC2006]で定義されます。 モバイルIPプロトコルの基本型の構造は3つの実体について説明します: モバイルノード、ホームのエージェント、および外国人のエージェント。 これらの実体に加えて、このドキュメントは、モバイルRouterになるように機能的な実体を提案します。
Leung, et al. Standards Track [Page 12] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[12ページ]RFC5177
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によって可能にされたホームのエージェントにおける必要な初期の構成が制限されない、Prefix Tableのコンテンツ。 モバイルRouterは、初期の構成としてモバイルNetwork Prefixesを保存する必要があるかもしれません。
The definition of MIB objects related to the Mobile Router and to a NEMOv4-enabled Home Agent is outside the scope of this document.
MIBオブジェクトの定義は、モバイルRouterに関連して、このドキュメントの範囲の外にNEMOv4によって可能にされたホームのエージェントにはあります。
6. Home Agent Operation
6. ホームエージェント操作
6.1. Summary
6.1. 概要
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.
ホームのエージェントはRFC3344[RFC3344]でモバイルNodeサポートに指定されたすべての操作をサポートしなければなりません。 ホームのエージェントは、モバイルRouterのために両方が暗黙の、そして、明白な運転モードであるとサポートしなければなりません。
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:
ホームのエージェントがRFC3344[RFC3344]に一致における登録を処理する、Care、-、Address。RFCはトンネルを通ってモバイルRouterのホームAddressにルートセットアップを含んでいます。 さらに、明白なモードで登録するモバイルRouterにおいて、以下の方法を取ります:
1. Check that the Mobile Network Prefix information is valid.
1. モバイルNetwork Prefix情報が有効であることをチェックしてください。
2. Ensure the Mobile Network Prefix(es) is/are authorized to be on
the Mobile Router.
2. モバイルRouterにあるようにモバイルNetwork Prefix(es)が認可された/であることを確実にしてください。
3. Create a tunnel to the Mobile Router if it does not already
exist.
3. 既に存在しないなら、モバイルRouterにトンネルを作成してください。
4. Set up route for the Mobile Network Prefix via this tunnel.
4. モバイルNetwork Prefixのためにこのトンネルを通ってルートをセットアップしてください。
5. Propagate Mobile Network Prefix routes via routing protocol if
necessary.
5. 必要なら、ルーティング・プロトコルでモバイルNetwork Prefixルートを伝播してください。
6. Send the Registration Reply with the Mobile Network
Acknowledgement extension(s).
6. モバイルNetwork Acknowledgement拡張子があるRegistration Replyを送ってください。
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.
モバイルNetwork拡張子で指定されないモバイルRouterへのトンネルを通って何かサブネットルートがあれば、これらのルートは取り外されます。
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).
モバイルNodeがモバイルRouterとして機能することは許可されていない場合では、ホームのエージェントがCode分野がHA_MOBNET_DISALLOWED(Registration Replyの適切なCode分野)であるRegistration Replyメッセージを送ります。
Leung, et al. Standards Track [Page 13] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[13ページ]RFC5177
For a Mobile Router registering in implicit mode, the Home Agent performs steps 3-6 above, once the registration request is processed successfully.
暗黙のモードで登録するモバイルRouterに関しては、ホームのエージェントは上のステップ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.
反登録に関しては、ホームのエージェントは、このトンネルを使用することでモバイルRouterとすべてのルートにトンネルを取り外します。 モバイルNetwork拡張子は無視されます。
6.2. Data Structures
6.2. データ構造
6.2.1. Registration Table
6.2.1. レジスタ・テーブル
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.
RFC3344[RFC3344]によると、ホームのエージェントのRegistration Tableはそれに登録されたあらゆるモバイルNodeのための拘束力がある情報を含んでいます。 RFC3344[RFC3344]はRegistration Tableの書式を定義します。 RFC3344[RFC3344]によって指定されたすべてのパラメタに加えて、ホームのエージェントは対応する登録エントリーにおけるモバイルRouterに関連しているモバイルNetwork Prefixesを保存しなければなりません、対応する登録が明白なモードで実行されたとき。 ホームのエージェントがモバイルRouterによって役立たれたモバイルNetwork Prefixesに可到達性の広告を出しているとき、Registration Tableに保存された情報は使用できます。
6.2.2. Prefix Table
6.2.2. 接頭語テーブル
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.
モバイルRouterが明白なモードで作動しているとき、ホームのエージェントはモバイルNetwork Prefixesの使用のためにモバイルRouterを認可できなければなりません。 また、モバイルRouterが暗黙のモードで作動するとき、ホームのエージェントはそのモバイルRouterに関連しているモバイルNetwork Prefixesの場所を見つけることができなければなりません。 ホームのエージェントはそのモバイルRouterに関連しているモバイルNetwork接頭語に伴うモバイルRouterのホームAddressを保存するかもしれません。 モバイルRouterがホームAddressを割り当てさせないなら、このテーブルはダイナミックなホームAddress課題に使用されるモバイルRouterのNetwork Access Identifier(NAI)[RFC2794]を保存するかもしれません。
6.3. Mobile Network Prefix Registration
6.3. モバイルネットワーク接頭語登録
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.
ホームのエージェントはこのセクションに従ってモバイルRoutersから来るRegistration Requestsを処理しなければなりません。 RFC3344[RFC3344]は、ホームのエージェントとともに記名するモバイルノードのホームAddressがホームネットワークの広告に掲載された接頭語に属さなければならないと指定します。 しかしながら、この仕様に従って、必ずホームネットワークのものではなく、ホームのエージェントによって勤められる接頭語からホームAddressを構成しなければなりません。
Leung, et al. Standards Track [Page 14] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[14ページ]RFC5177
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.
Registration Requestが有効であるなら、ホームのエージェントは、Registration Requestに拡大を含んでいて、何かモバイルNetwork Prefixがあるかどうか確認するためにチェックします。
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.
そうだとすれば、含まれている拡大、およびホームAddressからRegistration RequestのホームAddress分野からモバイルNetwork Prefix情報を得ます。 登録要求にあらゆるモバイルNetwork Prefix拡張子を含むように、ホームのエージェントはPrefix Tableに対してチェックを実行しなければなりません。 Prefix TableがそのホームAddressをそのモバイルNetwork Prefixと対にする少なくとも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.
Prefix Tableに対してこのチェックに続いて、ホームのエージェントはモバイルNetwork Acknowledgement拡張子を含むRegistration Replyを組み立てなければなりません。 チェックが失敗していたモバイルNetwork Prefixにおいて、対応するモバイルNetwork Acknowledgement拡張子におけるCode分野は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.
チェックがうまくいったモバイルNetwork Prefixにおいて、それぞれのモバイルNetwork Acknowledgement拡張子におけるCode分野は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.
ホームのエージェントは、Prefix TableチェックがうまくいったそれぞれのモバイルNetwork Prefix拡張子のための推進をセットアップするのを試みなければなりません。 推進セットアップが特定のモバイルNetwork Prefix(利用可能な十分なメモリ利用可能であるか十分でないデバイスなどでないことなどの理由による)のために失敗するなら、それぞれのモバイルNetwork Acknowledgement拡張子におけるCode分野は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モバイルNetwork Prefixでうまくいくなら、Registration ReplyメッセージのCode分野(適切)は0に設定されるでしょうに。 推進とセットアップがありとあらゆるモバイルNetwork Prefixesに失敗していたとき、さもなければ、そのCode(適切)は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.
すなわち、暗黙のモード、少しもモバイルNetwork Request拡張子なしでRegistration Requestを送るなら、モバイルRouterが推進をセットアップするのにホームのエージェントはあらかじめ構成されたモバイルNetwork接頭語情報を使用するかもしれません。
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
ホームのエージェントがモバイルRouterのために既存の拘束力があるエントリーをアップデートしているなら、Registration Requestに接頭語に対するRegistration Tableを含んでいる場合、それはすべての接頭語を預けなければなりません。 1つ以上のモバイルNetwork接頭語が包含からなくなるなら
Leung, et al. Standards Track [Page 15] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[15ページ]RFC5177
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).
すべてのチェックがうまくいくなら、ホームのエージェントは、モバイルRouterのために新しいエントリーを作成するか、それのために既存の拘束力があるエントリーをアップデートして、またはモバイルRouterかForeignエージェントにうまくいっている登録回答を返して戻します(ForeignエージェントからRegistration Requestを受け取ったなら)。
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.
ホームネットワークからモバイルRouterホームAddressを得るとき、RFC3344[RFC3344]によると、ホームのエージェントはモバイルRouterホームAddressのために、プロトコル(ARP)をプロキシAddress Resolutionにします。
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'ビットが設定されるなら、ホームのエージェントは、対応するモバイルNetwork接頭語のために双方向のトンネルを作成するか、または既存の双方向のトンネルをアップデートします。 このトンネルは逆のトンネルからモバイルRouterホームアドレス自体において独立しているのに維持されます。
6.4. Advertising Mobile Network Reachability
6.4. 広告モバイルネットワークの可到達性
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.
ホームのエージェントによって勤められたモバイルNetwork接頭語がホームネットワーク接頭語で集められて、ホームのエージェントがホームネットワークのデフォルトルータであるなら、ホームのエージェントはモバイルNetwork Prefixesの広告を出す必要はありません。 モバイルNetwork Prefixのためのルートは自動的にホームネットワーク接頭語に集められます(モバイルNetwork Prefixesが自動的にホームネットワーク接頭語に集められると思われます)。 モバイルRouterがダイナミックルーティングプロトコルでモバイルNetwork接頭語ルートをアップデートするなら、ホームのエージェントSHOULDは適切なネットワークのルートを伝播します。
6.5. Establishment of Bi-directional Tunnel
6.5. 双方向のトンネル設立
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.
ホームのエージェントは、それに登録されたモバイルRouterのモバイルNetwork接頭語のために双方向のトンネルを作成して、維持します。 IPv4のモバイルRouterが操作であるとサポートするホームのエージェントが接頭語がモバイルRouterで役立ったモバイルNetworkに運命づけられたパケットを進めることができなければならない、それ、Care、-、Address。 また、ホームのエージェントが外側のヘッダーセットのソースアドレスでモバイルRouterによってトンネルを堀られたパケットを受け入れることができなければならない、Care、-、モバイルRouterのAddressと内側のヘッダーのものはモバイルRouterのホームAddressか登録されたモバイルNetwork接頭語の1つからのアドレスにセットしました。
Leung, et al. Standards Track [Page 16] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[16ページ]RFC5177
6.6. Sending Registration Replies
6.6. 送付登録回答
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に関する登録回答におけるステータスコードにRegistration Requestのうまくいっている処理と少なくとも1つのモバイルNetwork接頭語のための推進のうまくいっているセットアップがモバイルRouterで役立ったのを示すように設定しなければなりません。 Registration Replyは少なくとも1つのモバイルNetwork Acknowledgement拡張子を含まなければなりません。
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のための推進にセットできないか、または、よりモバイルのNetwork接頭語がモバイルRouterで役立ったなら、それはMOBNET_FWDING_SETUP_FAILEDへのRegistration ReplyにモバイルNetwork Acknowledgement Extension状態Codeをはめ込まなければなりません。 接頭語の長さが10進32よりゼロ以上であるときに、状態Codeは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.
モバイルRouterが要求にモバイルNetwork接頭語を含んでいるのにパケットを送るのが認可されないなら、ホームのエージェントはMOBNET_UNAUTHORIZEDにCodeを設定しなければなりません。
6.7. Mobile Network Prefix Deregistration
6.7. モバイルネットワーク接頭語Deregistration
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.
受け取られていることである、Registration Requestが反登録のためにいるCare、-、Address(それのうまくいっている処理でのホームのエージェント)はRegistration Tableからエントリー(または、エントリー)を削除しなければなりません。 ホームのエージェントは、双方向のトンネルを取りこわして、モバイルRouterからの/にどんなパケットも送るのを止めます。 ホームのエージェントは反登録要求におけるどんな含まれているモバイルNetwork Request拡張子も無視しなければなりません。
7. Data Forwarding Operation
7. データ推進操作
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).
モバイルNetworkのノードへのトラフィックのために、ホームのエージェントはパケットの二重トンネリングを実行しなければなりません、モバイルRouterがForeignエージェントとともに記名したならCare、-、Address。 この場合、ホームのエージェントは、トンネルヘッダー(ソースIPアドレスはホームのエージェントにセットしました、そして、送付先IPアドレスはモバイルRouterのホームAddressにセットした)と共にパケットをカプセルに入れって、次に、より多くの1回の間、トンネルヘッダーをもって要約しなければなりません(ソースIPアドレスはホームのエージェントにセットしました、そして、送付先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.
最適化、SHOULDが共同見つけられた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
ホームのエージェントが双方向のトンネルのモバイルNetwork接頭語からパケットを受けるとき、それは、反-パケットをカプセルに入れって、正常なIPパケットとしてそれを発送しなければなりません。 それがそれについて確かめなければならない、入来
Leung, et al. Standards Track [Page 17] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[17ページ]RFC5177
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アドレスがパケットでセットする、Care、-、モバイルRouterのAddress。 ソースアドレスが設定されないならパケットを下げなければならない、Care、-、モバイルRouterのAddress。
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.
モバイルNetworkのノードからのトラフィックのために、逆のトンネルが可能にされるなら、モバイルRouterはトンネルヘッダー(ソースIPアドレスはモバイルRouterのホームAddressにセットしました、そして、送付先IPアドレスはホームのエージェントにセットした)と共にパケットをカプセルに入れります。 さもなければ、パケットは直接Foreignエージェントかアクセスルータに発送されます。
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モードで、モバイルRouterは、より多くの1回の間、トンネルヘッダーと共に要約するかもしれません(ソースIPアドレスがCoAにセットしました、そして、送付先IPアドレスはホームのエージェントにセットしました)。
8. Nested Mobile Networks
8. 入れ子にされたモバイルネットワーク
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.
入れ子にされたNetwork MobilityはモバイルRouterが別のモバイルRouterをモバイルNetworkに付かせるシナリオです。 任意のレベルの入れ子にされた移動性があるかもしれません。 モバイルRouterが別のモバイルRouter、または、インターネットの固定Access Routerに付くか否かに関係なく、それぞれのモバイルRouterの操作は同じままで残っています。 ここで説明されたソリューションはレベルの数に関して入れ子にされた移動性のためにどんな制限も課しません。 もっとも、2冊は注意されるべきです。 まず最初に、物理的な輪がモバイルNetworksの入れ子にされた集合で現れるときはいつも、このプロトコルは、彼らを検出でない、また解決しません--データグラム推進は妨げられるかもしれません。 2番目に、それぞれのレベルの巣篭もりが別のトンネルヘッダーカプセル化を導入するとき、モバイルNetworksの深い入れ子にされた集合のモバイルRoutersはデータ・パケットの上で重要なオーバーヘッドを導入するかもしれません。 それぞれのレベルの巣篭もりに従って使用可能なMTUが減少するので、MTUが発見であるとサポートしないアプリケーションが追加ヘッダーカプセル化で悪影響を受けます。
9. Routing Protocol between Mobile Router and Home Agent
9. モバイルルータとホームのエージェントの間のルーティング・プロトコル
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.
モバイルRouterとホームのエージェントの間には、ダイナミックルーティングプロトコルを実行するいくつかの利益があります。 いくつかのワイヤレスのサブネットを含んでいて、モバイルNetworkが比較的大きいなら、ダイナミックルーティングプロトコルを使用することによって、モバイルRouterからホームのエージェントまで感動的なネットワークの中のトポロジー変化を暴露することができます。 前項で定義されるモバイルIPv4へのNEMOv4プロトコル拡張子の目的はこれらのトポロジー変化に関してホームのエージェントに知らせるのではなく、モバイルRouterの移動性を管理することです。
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.
同様に、ダイナミックルーティングプロトコルを使用することによって、ホームネットワークにおけるトポロジー変化をモバイルRouterに暴露することができます。 新しい固定ネットワークがホームネットワークで加えられるとき、これが必要であるかもしれません。
Leung, et al. Standards Track [Page 18] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[18ページ]RFC5177
Here too, the purpose of NEMOv4 extensions is not to inform the Mobile Router about topology changes at home.
また、ここで、NEMOv4拡張子の目的はホームでトポロジー変化に関してモバイルRouterに知らせないことです。
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実装が2人乗り自転車でどうモバイルRouterと、そして、推進情報ベースの中の支離滅裂の州をホームに創設することのないホームのエージェント(1)と、そして、モバイルRouterに働いているか、そして、訪問されたドメインで不正確なアドレス指定情報を位相的に紹介することのない(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交換Registration Requestによって確立された双方向のトンネルの上にモバイルRouterとホームのエージェントの間で交換された情報を送ります--登録Reply(セクション6.5を見ます)。 感動的なネットワークにおけるサブネットのネットワーク・アドレスと接頭語であるなら、また、送られたコネがモバイルIPv4 Registration Requestであったなら、ルーティング・プロトコルメッセージの中でモバイルRouterによって送られて、当時のそれらはSHOULD NOTですか? これは推進情報ベースの中で「不-干渉性」を避けます。 モバイルRouter SHOULDはこの場合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.
モバイルRouter SHOULDは外国ネットワークでルーティング・プロトコル情報最新版を送りません。 移動式であるネットワークで有効なサブネットアドレスと接頭語は位相的にそうです。訪問されたネットワークでは、不正確です。
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.
モバイルRouterとホームのエージェントがトンネルのインタフェースの上でダイナミックルーティングプロトコルを使用して、そのプロトコルがそのプロトコルのメッセージを保護するためにセキュリティー対策を提供するなら、セクション10.1におけるセキュリティ推薦は適用されます。
10. Security Considerations
10. セキュリティ問題
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].
モバイルNetwork拡張子は登録メッセージにおけるモバイルIP拡大のように同じ規則で保護されます。 RFC3344[RFC3344]のSecurity Considerations部を見てください。
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.
ホームのエージェントは、モバイルRouterがRegistration RequestのモバイルNetworksに移動性サービスを供給するのが認可されることを確かめることができなければなりません、モバイルRouterを代表してこれらのモバイルNetwork Prefixesを据えつける前に。 それらの接頭語のためにモバイルRouterのうまくいっている承認なしで接頭語のための推進をセットアップしてはいけません。 それが要求した接頭語のために首尾よくそれを認可できないので登録失敗があるとき、モバイルRouterに通知しなければなりません。
Leung, et al. Standards Track [Page 19] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[19ページ]RFC5177
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.
RFC3344[RFC3344]の指定されるとしてのミネソタ-HA Authentication ExtensionはすべてのRegistration Requestsと回答を認証しなければなりません。 すなわち、明白なモード、1つ以上のモバイルNetwork Prefix拡張子と共に登録要求を送るとき、ミネソタ-HA Authentication拡張子の前にすべてのモバイルNetwork Prefix拡張子を含まなければなりません。 また、ミネソタ-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.
モバイルRouterは逆のトンネリングの前にモバイルNetworkで受け取られていているすべてのパケットの上でホームのエージェントにそれらをフィルターにかけるイングレスを実行するはずです。 モバイルRouterはモバイル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.
また、モバイルRouterは、モバイルNetworkで到着するパケットのソースアドレスがどんなインタフェースに関するモバイルRouterの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ヘッダーのソースアドレスがモバイルRouterのものに設定されることを確かめなければならない、Care、-、Address。 また、それは、モバイルNetworkで内側のIPヘッダーのソースアドレスがaがアドレスを位相的に修正するということであることを確実にしなければなりません。 これによって、ノードはホームのエージェントが保護されたネットワークに攻撃に着手するのに使用できないでしょう。
10.1. Security when Dynamic Routing Protocol Is Used
10.1. セキュリティいつDynamicルート設定プロトコルIs Used
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.
ダイナミックルーティングプロトコルがモバイルRouterとホームのエージェントの間で使用されるならホームネットワーク、ルーティングアップデートSHOULDにモバイルNetwork情報を伝播するために、モバイルRouterとホームのエージェントの間にIPsec超能力秘密性で保護されて、立ち聞きする者にとって、ホームネットワークトポロジーの情報が目に見えるのを防いでください。
11. IANA Considerations
11. IANA問題
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は「RFC3344あたりのモバイルIPv4番号」を既存の登録への規則に割り当てました。 モバイルIPコントロールメッセージ(No.とUDPポートNo.434から送られたもの)に現れるかもしれないExtensionsのための付番スペースは変更されるべきです。
Leung, et al. Standards Track [Page 20] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[20ページ]RFC5177
The new Values and Names for the Type for Extensions appearing in Mobile IP control messages are the following:
モバイルIPコントロールメッセージに現れるExtensionsのためのTypeのための新しいValuesとNamesは以下です:
+-------+--------------------------+
| Value | Name |
+-------+--------------------------+
| 148 | Mobile Network Extension |
+-------+--------------------------+
+-------+--------------------------+ | 値| 名前| +-------+--------------------------+ | 148 | モバイルネットワーク拡大| +-------+--------------------------+
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:
モバイルNetwork ExtensionsのためのSub-タイプのためのValuesとNamesのために新しい数のスペースを作成してあります。 この数のスペースは初めは、このドキュメントによって割り当てられた以下のエントリーを保持するために定義されます:
+-------+-----------------------------------------+
| Value | Name |
+-------+-----------------------------------------+
| 0 | Mobile Network Request Extension |
| 1 | Explicit Mode Acknowledgement Extension |
| 2 | Implicit Mode Acknowledgement Extension |
+-------+-----------------------------------------+
+-------+-----------------------------------------+ | 値| 名前| +-------+-----------------------------------------+ | 0 | モバイルネットワーク要求拡張子| | 1 | 明白なモード承認拡大| | 2 | 暗黙のモード承認拡大| +-------+-----------------------------------------+
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]).
この数のスペースへの将来の課題の方針はStandards ActionかIESG Approvalに続くことです([RFC2434]を見てください)。
The new Code Values for Mobile IP Registration Reply messages are the following (for a registration denied by the Home Agent):
モバイルIP Registration Replyメッセージのための新しいCode Valuesは以下(ホームのエージェントによって否定された登録のための)です:
+-------+-----------------------------------------------------------+ | Value | Name | +-------+-----------------------------------------------------------+ | 147 | Mobile Network Prefix operation error (HA_MOBNET_ERROR) | | 148 | Mobile Router operation is not permitted | | | (HA_MOBNET_DISALLOWED) | +-------+-----------------------------------------------------------+
+-------+-----------------------------------------------------------+ | 値| 名前| +-------+-----------------------------------------------------------+ | 147 | モバイルNetwork Prefix操作誤り(HA_MOBNET_ERROR)| | 148 | モバイルRouter操作は受入れられません。| | | (ハ、MOBNET_が禁じた_) | +-------+-----------------------------------------------------------+
Table 3: New Code Values for Mobile IP Registration Reply
テーブル3: モバイルIP登録のための新法値は返答します。
Leung, et al. Standards Track [Page 21] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[21ページ]RFC5177
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):
モバイルNetwork Acknowledgement ExtensionのためのCode Valuesのために新しい数のスペースを作成してあります。 この数のスペースは初めは、このドキュメントによって割り当てられた以下のエントリーを保持するために定義されます(登録の結果になってください、ホームのエージェントによって送られるように):
+---+---------------------------------------------------------------+ | 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) | +---+---------------------------------------------------------------+
+---+---------------------------------------------------------------+ | 0 | 成功| | 1 | 無効の接頭語の長さ(MOBNET_INVALID_PREFIX_LEN)| | 2 | モバイルRouterは接頭語のために認可されません。| | | (MOBNET_権限のない)です。 | | 3 | 推進セットアップは(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]).
この数のスペースへの将来の課題の方針はStandards ActionかIESG Approvalに続くことです([RFC2434]を見てください)。
12. Acknowledgements
12. 承認
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、ジョージ・ポポビッチ、タイBekiares、ガネッシュSrinivasan、Alpeshパテル、龍治Wakikawa、ジョージTsirtsis、およびHenrik Levkowetzに感謝したがっています。 ビジェイDevarapalliは手広くドキュメントの後のバージョンの1つを見直しました。 ハンス・シェストランドはForeignエージェントモード処理に関して最後の明確化を特定しました。 ピートマッキャンは多くの声明の必要な気品を寄付しました。
Mobile IPv4 versions as early as 1996 (RFC 2002 by Charles Perkins) described Mobile Networks and Mobile Routers support.
1996(チャールズ・パーキンスによるRFC2002)としての初期のモバイルIPv4同じくらいバージョンはモバイルNetworksとモバイルRoutersサポートについて説明しました。
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のティム・ポークはCode分野を管理するときの深く強固な誤りを特定しました。
Lars Eggert of the IESG suggested the accommodation of the otherwise legal non-contiguous netmask fields, instead of simply prefix lengths.
の代わりにする、IESGのラース・エッゲルトがそうでなければ、法的な非隣接のネットマスク分野の宿泊設備を勧めた、単に長さを前に置いてください。
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はMIP4環境でモバイルRouters、NEMOv4によって可能にされたホームのエージェント、および彼らのdeployabilityの管理可能性の必要性を示しました。
Leung, et al. Standards Track [Page 22] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[22ページ]RFC5177
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ドキュメントを再検討するために輸送領域の管理職の進行中の取り組みの一部としてこのドキュメントを再検討しました。 モバイルNetworkでアプリケーションに深く悪影響を与える使用可能な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).
それらが公表(Area Review Team司令官)のために考えられているので、ゴンサロ・キャマリロは追加セットの目からジェネラリストレビューをドキュメントに供給しました。
Jari Arkko of the IESG reviewed, suggested necessary improvements to, and diligently shepherded this document through IESG.
IESGのヤリArkkoはIESGを通して論評して、必要な改善を勧めて、まめにこのドキュメントを守りました。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.とブレーデン、B.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[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.パーキンス、「IPの移動性のための管理オブジェクトの定義は、使用がSMIv2"であるとサポートします、RFC2006、1996年10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC2453] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[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)」、RFC4271 2006年1月。
Leung, et al. Standards Track [Page 23] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[23ページ]RFC5177
13.2. Informative References
13.2. 有益な参照
[NEMOv4-FA] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA
extensions to NEMOv4 Base", Work in Progress,
February 2008.
2008年2月のProgressの[NEMOv4-FA]TsirtsisとG.とParkとV.とナラヤナン、V.とK.レオン、「NEMOv4基地へのFA拡張子」Work。
[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、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[RFC4885] エルンスト、T.、およびH-Y。 ラック、「ネットワーク移動性サポート用語」、RFC4885、2007年7月。
Leung, et al. Standards Track [Page 24] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[24ページ]RFC5177
Authors' Addresses
作者のアドレス
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
ケントレオン・シスコシステムズ170w.タスマン・Driveカリフォルニア95134サンノゼ(米国)
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シスコシステムズ170w.タスマンDriveサンノゼ、カリフォルニア95134米国
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ナラヤナンクアルコムInc.5775カリフォルニア米国
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
Alexandruペトレスク・モトローラParc les Algorithmesセイント・オーバン・Gif上-エソンヌ91140イヴェット(フランス)
Phone: +33 169354827 EMail: alexandru.petrescu@motorola.com
以下に電話をしてください。 +33 169354827はメールされます: alexandru.petrescu@motorola.com
Leung, et al. Standards Track [Page 25] RFC 5177 Mobile Router April 2008
レオン、他 ルータ2008年4月のモバイルの標準化過程[25ページ]RFC5177
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Leung, et al. Standards Track [Page 26]
レオン、他 標準化過程[26ページ]
一覧
スポンサーリンク
