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