「NEMO」の編集履歴(バックアップ)一覧はこちら

NEMO」(2005/12/02 (金) 15:24:44) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

Network Mobility (NEMO) Basic Support Protocol Abstract この文章はインターネットにおいてモバイルネットワークが異なる接続点に接続 することを可能にするNEMOについて説明する。このプロトコルは、MIPv6を拡張 することで、ネットワークを移動するようなモバイルネットワークにおいて全て のノードに連続的な接続性を与える。また、全てのノードがモバイルネットワー クを動き回っている間、到達性を与える。モバイルネットワークをインターネッ トに接続する、モバイルルータ(MR)はHAと共にNEMOプロトコルを実行する。こ のプロトコルは、モバイルネットワーク内のノードに対してネットワークの移動 を意識させないように設計されている。 コンテンツ 1,紹介 2,専門用語 3,NEMOの概要 4,メッセージフォーマット  4-1,BU  4-2,BAck  4-3,MobileNetworkプレフィックスオプション 5,MRオプション  5-1,データ構造  5-2,BUの送信  5-3,BAckの受信  5-4,エラー処理   5-4-1,Implicitモード   5-4-2,Explicitモード  5-5,双方向トンネルの確立  5-6,MRのための近隣発見  5-7,MRのマルチキャストグループ  5-8,Homeへの帰還 6,HA動作  6-1,データ構造   6-1-1,BC   6-1-2,プレフィックステーブル  6-2,MobileNetworkプレフィックスの登録  6-3,MobileNetworkの到達性の広告  6-4,双方向トンネルの確立  6-5,パケットの転送  6-6,BAckの送信  6-7,MobileNetworkプレフィックスの非登録 7,動的HAアドレス発見の修正  7-1,動的HA発見要求の修正  7-2,動的HAアドレス発見要求の修正  7-3,HA情報オプションの修正 8,Dynamic Routingプロトコルのサポート 9,セキュリティの考慮 10,IANAの考慮 11,貢献人 12,謝辞 13、参考文献 付録  A,NEMOの動作例  B,Link State Routing ProtocolとNEMOの処理   B-1,トンネルインタフェースの考慮   B-2,OSPFエリアの考慮 1,Introduction この文章ではNetworkMobilityを可能にするために、MIPv6に拡張を行うことにつ いて述べる。この拡張はMIPv6と後方互換がある。特に、従順なNEMO-HAはMIPv6 のHAのように動作する。ここで説明されたソリューションは、ネットワークの移 動性のために[11]で特定された目標と要求を満たす。 NEMOはMRがインターネットへの接続点を変更した場合でも、MobileNetworkの全 てのノードに連続した通信を保証する。また、移動を行う際にMobileNetwork内 の全てのノードに接続性と到達性を提供する。この提案は、MobileNetwork内に おいて、移動性をサポートしないMNやホスト両方であってもサポートを行う。 この文章内において、MRはMIPv6のMNの拡張と定義し、接続点とサブネット間の ルーティングをMRが移動を伴っても、ルーティングを行う能力を付け加える。 この文章で説明されるソリューションはMRとHA間の双方向トンネルを提案する。 このトンネルはMRがHAへのBU(HAに現在の接続点を通知する)に成功した時に設 定される。 MobileNetworkとCNのノード間の全ての通信はHAを経由する。この文章では通信 の経路最適化は説明しない。 専門用語の文章[10]は、別のMRがそのMobileNetworkに接続することをMRが許す ようなシナリオとしてNestedMobilityを紹介します。任意のレベルの NestedMobilityがあるかもしれない。同じようにとどまっているそれぞれのMRが、 インターネットにおいて他のMRか、固定ARに接続しているかどうか操作する。こ こで説明されるソリューションは、NestedMobilityのためのレベルの数にどのよ うな制限も設けない。しかし、それぞれのレベルの入れ子が他のIPv6ヘッダのカ プセル化を導入するように、データパケットの重要なオーバヘッドを導入するか しれないことに注意。 この文章はMRのマルチホームの議論は行わない。 2,専門用語 キーワード”MUST”,”MUST NOT”,”REQUIRED”,”SHALL”,”SHALL NOT”,” SHOULD”,”SHOULD NOT”,”RECOMMENDED”,”MAY”と”OPTIONAL”はBCP14 やRFC2119で紹介されるように、この文章で解説される。 NEMOに関連する専門用語は[9][10]で定義される。このドキュメントは以下の用 語の定義を追加する。 Mobile Network Prefix IPv6プレフィックスはMRに委託され、MobileNetwork内に広告される。 MobileNetwork内に1つ以上のMobileNetworkプレフィックスを広告できる。 Prefix Table MRにおいてHomeAddressとMobileNetworkプレフィックスを関連付けるリスト。HA はどのMobileNetworkPrefixが特定のMRに所属するかを決定するのにPrefix Tableを管理、利用する。 NEMOの概要 MobileNetworkは、ルーティングインフラにおいて、ネットワークの境やサブネ ットを移動し、任意の接続点に接続できる。MobileNetworkは、移動を管理する MRと呼ばれる特定のゲートウェイを経由してのみアクセスできる。 MobileNetworkは少なくとも1つのMRを彼らの役に立たせる。MRはインフラに接 続点を追加するのに、MobileNetworkルートを割り当てない。その代わりに、広 告をするHAへの双方向トンネルがMobileNetworkのインフラであることを維持す る。また、MRもMobileNetworkのデフォルトのゲートウェイです。 MobileNetworkもまた、多様で入れ子にされたサブネットを含むことができる。 移動性をサポートしないルータは、ローカル割り当てのために永久に MobileNeteworkに接続されてもよい。また、MRは異なるMRに所有される MobileNeteworkに接続され、グラフを形成してもよい。特に、NEMOにおいて、そ れぞれのMRは一つのインタフェースで、別のMobileNetworkに接続する。もし、 ループを避ける場合、グラフは木構造になる。 MRにはHAに登録される時に届くユニークなHomeAddressがある。HomeAddressはHA により集められ広告されたプレフィックスから構成される。このプレフィックス は、Homeリンクで広告されるプレフィックスか、MRに委託されたプレフィックス のどちらかである。MRは、Homeリンクで複数のプレフィックスを持つと、一つ以 上のHomeAddressを持ちます。また、MRはMobileNetworkに接続されたものに、一 つ以上のプレフィックスを広告する。この仕様書の範囲外に、これらのプレフィ ックスを特定のMRに割り当てるための実際のメカニズムがある。 MRが、Homeリンクから外部に移動し新たなアクセスルータに移動した時、訪問先 のリンクからCoAを得る。MRは常にMNかMRのどちらかの動作ができる。それは接 続性を発生させ提供するセッションのために[1]でMobileNetworkのために定義さ れるMNのように機能する。MRがCoAを得ると同時に、[1]で説明されるようにHAに ただちにBUを行う。HAがBUを受信した時、MRのHomeAddressと現在の接続点のCoA を対応付ける登録情報を作成する。 もし、MobileNetworkでMRが、MRのように動作しノードに接続性を提供しようと 努めるならば、フラグRを設定したBUをHAに対して示す。また、HAがMRの MobileNetwork内のノードに意図したパケットを転送できるように、セッション 5.2で説明される一つのモードを使って、MobileNetworkPrefixに関する情報を含 むかもしれない。運搬を行うためのプレフィックス情報のための新たな MobilityHeaderオプションはセクション4.3で説明される。もし、MobileNetwork が一つ以上のIPv6プレフィックスを持ち、全てのプレフィックスに転送の設定を HAに要求する場合、一つのBUに多重プレフィックス情報オプションを同胞する。 HAはそれぞれのMRのCoAの持つプレフィックスに転送の設定をする。いくつかの シナリオでは、HAは静的な構成のような代わりのメカニズムでMRがどのプレフィ ックスに所属するかをすでに知っているかもしれない。これらのシナリオでは、 MRはBUに何もプレフィックス情報を含まないことはない。HAがMRから受信したBU にMRのRフラグが設定されている時、MRの所有する全てのプレフィックスに転送 の設定をする。 HAはBUの応答としてBAckをMRに送信する。肯定的な応答にMRフラグRが設定され るのは、HAがMobileNetworkへの転送を設定することを意味する。一度登録の作 業が完了すると、HAとMRの間に双方向トンネルを定着させる。このトンネルの終 端はMRのCoAとHAのアドレスです。もし、パケットのソースアドレスが MobileNetworkから受け取った所属するMobileNetworkPrefixならば、MRがHAを経 由してパケットを返信するトンネルはこのトンネルである。この返信トンネリン グはIP-in-IPカプセル化を利用する[3]。HAはカプセル化を解き、CNに転送する。 それ自身で発生したトラフィックのために、[1]で示されるように、MRは返信ト ンネルかルート最適化を利用できる。 CNがMobileNetworkのノードにデータパケットを送信した時、パケットは現在の MRのために情報を持つHAにルーティングされる。MRのネットワークプレフィック スは、結果の集合を広告した時、HAに集約されるかもしれない。その代わりに、 HAは、広告したMobileNetworkプレフィックスへのルートにより、受信したデー タパケットをMobileNetwork行きにするだろう。このルートの広告の動作メカニ ズムは、この文章の範囲外である。HAがMobileNetwork内のノードへのデータパ ケットを受信させるつもりの時、パケットはMRの現在のCoAにトンネルされる。 MRはパケットのカプセル化を解き、MobileNetworkに接続された内部のインタフ ェースに転送を行う。トンネルされたパケットのカプセル化をとく前に、MRは、 外側のIPv6ヘッダのソースアドレスがHAのアドレスかどうかチェックする。もし パケットがIPsecトンネルモードでプロテクトされているなら、このチェックは 必要ない。また、MRは内側のIPv6ヘッダの目的地アドレスがパケットを MobileNetworkに送る前にMobileNetworkで使われたプレフィックスに属するかを 確かめなければならない。もしできなければ、MRはパケットを落とすべきだ。 MobileNetworkは移動をサポートしないノードも、するノードをも含むことがで きる。MobileNetwork内のノードは配置かMRのようにできる。このプロトコルは MobileNetwork内のノードにNEMOの移動透過性を説明します。MNはMobileNetwork に接続することで通常のIPv6やMobileIPv6のように扱える。 MRとHAは双方向トンネルを経由してルーティングプロトコルを実行できる。この 場合、MRはBUにプレフィックス情報を含む必要は無い。その代わり、HAは MobileNetworkへの転送の設定を更新するためにルーティングプロトコルを使う。 ルーティングプロトコルを実行する時、双方向トンネルはトンネルインタフェー スのように扱われなければならない。このトンネルインタフェースは、ルーティ ングプロトコルがアクティブな院手フェースのリストを含んでいる。MRはHomeリ ンクから離れて訪問先に接続している時、MRの出口インタフェースに少しのルー ティングプロトコルメッセージも送信をしないように構成すべきだ。 最後に、HAはMRのHomeAddressのMobileNetworkプレフィックスにより、静的なル ートを構成してもよい。この場合、ルートはバインディングの流れや、MRのHome への帰還に関係なく設定される。利点として、移動のようなHomeNetworkのルー ティングアップデートのフォームにおいて追加の合図を発生させないこと。欠点 は、関連するMRに到達しないとしても、与えられた時間のポイント分ルートがあ ることです。 4,メッセージフォーマット 4.1,Binding Update 新しいフラグRは、BUがMNではなくMRから来たものであるかどうかをHAに示すた めにBUに含まれる。BUフォーマットの残りは[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2,Binding Ack 新たなフラグRは対応するBUを処理したHAがMRをサポートするのを示すために BAckに含まれる。このフラグは、対応するBUのMRフラグRに1がセットされた場 合にだけ設定される。残りのBAckフォーマットは[1]で定義される。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3,Mobile Network Prefix Option MNPOはMobileNetworkのプレフィックス情報をHAに示すためにBUに含まれる。MR がMobileNetowrkに一つ以上のIPv6プレフィックスを持ち、HAがMRの現在の位置 情報であるプレフィックスにパケットを転送したいならば、複数のMNPOがあるか もしれない。 MNPOには8n+4の整列要求がある。フォーマットは以下のようになる。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5,Mobile Routerの動作 MRの動作は、ホストやルータ、MNを組み合わせた振る舞いに大いに由来する。 MNは2つの方法で動作することができる。 【1】MHのような場合、HAはどんなプレフィックス情報もMHのHomeAddressに関 連することを主張しないが、キャッシュの登録情報はMHのHomeAddressに関連す ることを主張する。 【2】MRのような場合、MRHomeAddressに対応する登録情報を維持するのに加え、 HAはMobileNetworkに割り当てられたプレフィックスに関連する転送情報を維持 する。 2つのモードの間の区別はMRフラグRの値で表される。 MRは[1]のセクション8.5で説明されるようなIPv6MNのための全ての要求を実装し なければならない。 5.1,データ構造 MHのように、MRもまた、[1]で説明されるような、BUのリストを保持する。BUの リストの記録情報はBUで送信された概念的なデータ構造です。MRが現在のBUを送 信するそれぞれの目的地当たり一つのエントリーがある。 この文章ではBUリスト構造の新たなプレフィックス情報フィールドを紹介する。 このフィールドはMRのBUに含まれるプレフィックス情報を記録するのに利用する。 MRがBUにMRフラグRをセットしたならば、プレフィックス情報は含まれないので NULLが設定される。MRは、HAでダイナミックルーティングプロトコルが動作して いるか、implicitモードの時、BUにプレフィックス情報を含まない。 MHのように、MRは対応するBUリスト情報にBUのフラグの状態に関する情報を記録 する。登録情報の新しいMRフラグRはこの文章で説明される。フラグの状態は、 BUを送信する差、常にBUリストに格納される。 また、MRはMHのように同じ手順に従ってHAリストの住所を維持する。 5.2,BUの送信 MRは[1]で説明されるように、HAにBUを送信する。もし、セクション8で述べた ようにMRがルーティングプロトコルを動作させていなければ、どのプレフィック スがMRに属するかを決めるようHAに伝えるのに以下の一つのモードを利用する。 両方のモードでMRはMRフラグRを設定する。 Implicit: このモードでは、MRはBUにMobileNetworkPrefixオプションを含まない。HAはMR と転送先となるMobileNetworkの設定について所有するMobileNetworkPrefixを決 定するのにいくつかの方法を利用する。一例として、MobileNetworkへの転送の セットアップを要求するための、MRのHomeAddressの情報をHAが調査することで 手動構成するかもしれない。 Explicint: このモードでは、MRはBUにMobileNetworkPrefixオプションを一つ以上含む。こ れらのオプションはMobileNetworkでのMobileNetworkPrefix構成に関する情報を 含む。 MRはどちらかのモードを持たねばならず、両方を実行するかもしれない。後者の 場合、ローカル構成にどのモードを使うかをMRが決定する。これはこの文章では 範囲外である。 MRフラグをセットしたなら、HomeRegistrationフラグHはセットしなければなら ない。 もし、MRはHAに正当な登録情報を持つならば、同じHAへのその後のBUのMRフラグ の値は、同じ値であるべきである。Explicitモードで、対応する MobileNetworkPrefixに転送を可能にして欲しいなら、既存の登録情報をリフレ ッシュするために、MRは全てのBUのプレフィックスを含まなければならない。 5.3,BAckの受信 MRが、対応する先にMRが送信したBUのBAckをHAから受信する。もし、BAckの statusが0でMRフラグが1にセットされているならば、MRはBUがHAで確実に処理 され、MobileNetworkへの転送がセットされたと仮定する。MRはMobileNetworkか らの逆方向トンネルとして双方向トンネルの使用を開始できる。もしMRフラグR がセットされていなければ、MRは現在のHAがMRをサポートしないうえに、HAを発 見するために再び動的HAAddress発見を行うと結論付ける。また、別のものと登 録を試みる前に、それをサポートしなかったHAに登録の拒否を行わなければなら ない。 5.4,エラー処理 もし、BAckのstatusが128と139の間にセットされていれば、MRはMIPv6の仕様[1] で説明される必要な行動を取る。BAckのstatusのための値はこの文章で定義され、 以下のセクションでMRの動作を説明する。 5.4.1,Implicitモード Implicitモードにおいて、MRが解釈するエラーの状態は140と143だけである。MR は致命的なエラーのような141と142のBAckを扱わねばならず、Implicitモードに おいてそれ以降HAに送信を行うべきでない。 もしHAからのBAckにstatus140が含まれていたら、MRは同じHomeリンクの他のHA にBUを送信するべきです。もしHAが明確に返答をしないなら、MRからMRフラグを セットしてホームリンクの全てのHAにBUを送信するのを控えねばならず、情報を 登録しなければならない。 もしBAckのstatusが143ならば、MRは同じホームリンクの他のHAにBUを送信する べきです。もしHAが明確な返答をしないなら、MRはホームリンクの全てのHAにBU を送信するのを控えるべきで、Explicintモードでは同じホームリンクのHAにBU をい送信してもよい。 5.4.2,Explicitモード もしMRがExplicitモードでHAにBUを行った場合、MRが解釈するエラーの状態は 140と141と142だけです。MRは致命的なエラーのようにBAckとstatusを扱わねば ならず、Explicitモードにおいて、これ以降HAに送信を行うべきでない。 もし、HAからのBAckのstatusが140に設定されているならば、MRは同じホームリ ンクの他のHAにBUを送信するべきです。もし、HAが明確な返答をしない場合、MR からMRフラグをセットしてホームリンクの全てのHAにBUを送信するのを控えねば ならず、情報を登録しなければならない。 もし、BAckのstatusが141か142ならば、MRは同じリンクの他のHAにBUを送信する べきでえす。もし、HAが明確な応答をしない場合、ホームリンクの全てのHAへの BUの送信を控えるべきです。また、MRはMobileNetworkへのプレフィックスの広 告を停止し、MobileNetworkにおける新たなIPv6プレフィックスの取得を試みね ばならない。それは、初めに現在のMobileNetworkプレフィックスを割り当てら れたのと同じ方法で行われるだろう。あるいは、MRはImplicitモードにおいて同 じホームリンクのHAにBUを送信してもよい。 MRがエラー処理手順の終了までに、セクション5.4.1や5.4.2で説明される利用可 能な全てのモードを試みても、まだ積極的なBAckを受信できないなら、MRは HomeAddressのためにMRフラグをセットしてBUの送信を停止しなければならず、 情報を記録しなければならない。 全ての場合の上で、MRは、HAにおいてMRのHomeAddressを格納するためのキャッ シュが作成されないことを判断しなければならない。 5.5,双方向トンネルの確立 BAckの受信に成功した時、MRは双方向トンネルの終点をセットする。 MRが訪問先ネットワークに接続したら、MRとHA間の双方向トンネルをパケットが 両方に流れるのを許可しする。双方向トンネルはRFC2473で紹介されるように、 二つの片方向トンネルを合わせて作られる。MRからHAへのトンネルは、MRのCoA がトンネルの入口のように、HAのCoAが出口のようになる。逆は、それぞれが逆 になる。全てのIPv6通信とMobileNetworkからの送信は双方向トンネルを通る。 MRは通常、ルータに割り当てられたTunnnelHopLimitを使う。詳しくは[3]を参照。 5.6,MRのための近隣発見 MRがHomeにいる時、Homeリンクに接続されたインタフェースでRAを構成して送信 し、RSへの応答を行う。ルータライフライムの値が0にセットされ、他のノード のデフォルトルータのようにMRの構成の妨げとなる。 MRは、インタフェースが訪問先リンクに接続されている時に、求められていない RAを送信すべきでなく、出口インタフェースでのRSへの応答をするべきでない。 しかしながら、MRは訪問先で有効なアドレスを得るために、出口インタフェース で近隣要求を受信し近隣広告の応答を行う。 ルータは、リンク上の他のルータが送信したRAを通常無視する。しかしながら、 MRは出口インタフェースでRAの受信を無視してはならない。RAを受信するして、 移動の検出や、デフォルトルータの選択、アドレスの構築に利用しても良い。 5.7,MRのマルチキャストグループ Homeにいる時、MRは、いくつかの出口インタフェースで、SCOPE1ではインタフ ェースローカル、SCOPE2ではリンクローカルのマルチキャストグループの全て のルータアドレスに参加する。訪問先ネットワークの時、MRは対応するインタフ ェースで高位のマルチキャストグループに参加する。 5.8,Homeへの帰還 MRはHomeリンクに戻ったことを検出しとき、HAへの登録を拒否しなければならな い。MRは[1]のMNのためにHome帰還手順に従い定義と実行をしなければならない。 さらに、MRは出口インタフェースでルータのような振る舞いを開始し、以下のよ うな特徴がある。 MRは出口インタフェースでRAを送信しても良いが、ルータのライフタイムが0に 設定されるべきで、HomeリンクのホストはデフォルトルータのようにMRを選択で きない。 MRはHomeリンクの全てのルータアドレスマルチキャストグループに参加しても良 い。 動的ルーティングプロトコルを構成できるなら、MRは出口インタフェースからル ーティングプロトコル、メッセージを送信してもよい。 MRがExplicitモードで非登録のBUを送信した時、BUにいくつかのMobileNetwork プレフィックスオプションを含むべきでない。HAが登録情報を取り除いた時、関 連するMobileNetwokrプレフィックスのルートを全て削除する。 6,HAの動作 MRを適切に動作させるために、HAは[1]のセクション8.4の全ての必要なものをリ ストすることを満たさなければならない。HAはこのドキュメントの5.2で説明さ れる両方のモードを実行しなければならない。 6.1,データ構造 6.1.1,Binding Cashe HAは、それぞれのMRがHAに現状を登録したBCの情報を維持する。BCのデータ構造 の詳細は[1]で説明される。 HAは、対応するBC情報に、MRに関連するMobileNetworkプレフィックスを保存す る必要があるかもしれない。BUにより、明確なプレフィックス情報を格納するた めにBCを作成するなら、これは必要である。この情報は、Explicitモードにおい て、BC情報を取り除く(例えばルーティングテーブル維持)とき、ルーティング テーブルは手動で取り除くべきで、後ほどインストールされたルートを消すのに 使用できる。 また、HAはBCの情報にMRのフラグRの状態を保存する。 6.1.2,Prefix Table HAは、他のMRに所属するMRからのMobileNetworkプレフィックスの要求を妨げる ことができるべきである。HAは妨げることができる。プレフィックステーブルを 維持して、プレフィックステーブルの情報に対してMRから提供されたプレフィッ クス情報を証明するならばHAは攻撃を防ぐことができる。ExplicitモードでBUを 処理する時、プレフィックステーブルはHAにより利用される。MRとHAの間でダイ ナミックルーティングプロトコルを実行する時、これは必要ない。 それぞれのプレフィックステーブルのエントリーは以下のフィールドを含む:   MRのHomeAddress。このフィールドはあらかじめ構築されたプレフィックス   テーブルの検索に利用される。   HomeAddressに関連するMRのMobileNetworkプレフィックス。 6.2,MobileNetworkPrefixの登録 [1]のMIPv6のセクション10.3.1で詳細に説明されるようにHAがBUを処理する。こ のセクションは、MRフラグRが設定されたら、BUを処理しているかを説明する。 HAは以下のチェックのように動作する。   HomeRegistrationフラグH(Hフラグ)を設定しなければならない。しないな   らば、HAはBUを拒否しstatus140を設定したBAckを送信しなければならない。   注:基本的なサポートではMobileNetworkプレフィックスをBUでCNに送信す   ることを認めない。   MIPv6仕様[1]はHomeリンクに広告されるプレフィックスから構成した   HomeAddressをBUに含めることを必要とします。もしくは、[1]でのstatusの   値132でBUを拒否する。この仕様は、この要件を緩和するので、HomeAddress   がHAが役立つように構成するプレフィックスに属さないかもしれない場合に   だけHAはBUを拒否する。 もしHAがMRに対して正当な登録情報の内容を持ち、もしBUに反応する登録情報の 内容のRフラグに異なる値が設定されるならば、HAは登録を拒否し、status139を 設定したBAckを送信しなければならない。しかしながら、BUが非登録のBUなら、 HAはRフラグの値を無視する。 もし、BUのライフタイムが0に指定されるか、BUのCoAがHAに対応することを指 定されたなら、これはHomeAddressを指定するMobileNetworkプレフィックスの対 応をキャッシュから削除する。BUの処理手順はセクション6.7で説明される。 もしHAが根拠の無いようなBUを拒絶しないで、もしセクション8で説明されるよ うにHAとMR間でダイナミックルーティングプロトコルを実行しなかったならば、 HAは以下で説明するようにMobileNetoworkプレフィックス情報を検索する。   BUによりMobileNetworkプレフィックスオプションが提供されるなら、   MobileNetoworkプレフィックスのためのプレフィックス情報はオプションの   MNPフィールドとPrefixLengthフィールドから検索できる。もし、BUが一つ   以上のオプションを持つなら、HAは全てのMNPへの転送を設定しなければな   らない。もしHAがNUにおいて、全てのプレフィックスリストに転送の設定を   するのを失敗したなら、いくつかのプレフィックスに転送を行ってはならな   い。その上、BUを拒否して、statusに141をセットしてBAckを送信しなけれ   ばならない。   もし、HAがPrefixTableのプレフィックス情報を確認するチェックを怠った   なら、HAはBUを放棄し、statusに142をセットしたBAckを送信しなければな   らない。   もし、BUが運ぶプレフィックス情報に、オプションがついていないなら、   HAはMRへのプレフィックス割当を決定し、MobileNetoworkへの転送を設定す   るための情報を手動で仮構成する。もし、HAが利用できる情報が無いならば、   BUを拒否してstatusに143をセットしてBAckを送信する。 もし、HAがMRのための適当な登録情報の内容を持つならば、プレフィックスを蓄 えた登録情報の無いように対して、BUに格納されたプレフィックスを比較するべ きだ。もし、登録情報の内容にBUに現れないプレフィックスを含むなら、HAは MNPへの転送を無効にしなければならない。 全てのチェックをパスしたら、HAはMRのHomeAddressのために登録情報の内容を 作成するか、すでに存在するなら更新を行う。他には、HAはMRのHomeAddressの 対応を登録してはならない。 HAは、MRのためにプロキシ近隣発見を経由してMRのHaddressをHomeリンクに近隣 広告メッセージとしてマルチキャストする。プロキシ近隣発見メッセージの全て のフィールドは、[6]で説明されるように、Homeにいる間はこの近隣広告を送信 するならば、MRのために同じようの方法が設定できるだろう。例:もしBUにMRフ ラグRが設定されているならば、広告のRouter bit Rに設定しなければならない。 また、HAはセクション6.4で説明されるように、MRから要求されたMobileNetwork プレフィックスまでの双方向トンネルを作成するか、現在の双方向トンネルを更 新する。 6.3,MobileNetoworkの到達性の広告 MobileNetworkのために意味されたパケットを受信するために、HAは MobileNetwokに到達性を広告する。もし、Homeリンクが集合したプレフィックス で構成され、MNPがそのプレフィックスかで集められるなら、MobileNetworkに関 連するルーティングの変化はHomeリンクで制限されるかもしれない。もし、HAが Homeリンクのデフォルトルータのみなら、MNPへのルートはHA下の自然な集合で あるため、特別な何かをしなければならないことは無い。 もし、HAがMRからダイナミックルーティングプロトコルでルートの更新を受け取 ったら、妥当なインタフェースのルートを宣伝するために構成を行える。 双方向トンネルの確立 IPスタックへの双方向トンネルの実行や設置のメカニズムは、この仕様の範囲外 です。しかしながら、全ての実行は以下の動作の能力がなければならない。   HAはMNPが意味する、現在の位置情報(CoA)にパケットを転送できる。   HAはMRからトンネルされて、ソースアドレスとしてIPv6ヘッダの外側にMRの   CoAを含むパケットを受け取ることができる。 6.5,パケットの転送 HAがMobileNetwork行きのデータパケットを受信した時、双方向トンネルを経由 することでMRにデータを転送しなければならない。HAはBCのルーティングテーブ ルか、MobileNetworkにパケットを送信する組み合わせのどちらかを利用する。 これは実行仕様です。2つの例を示します。 1,HAはMRのHomeAddressへの次のホップとMNPのルートを維持する。HAが次のホ   ップにパケットの転送を試みた時、HomeAddressのための登録情報を見つける。   HAはパケットのCoAとしてMRのCoAとトンネルを引用する。 2,HAは、外部インタフェースとしてHAとMR間の双方向トンネルのインタフェー   スとMNPのルートを維持する。この目的のために、HAはトンネルインタフェ   ースのように、トンネルを扱わなければならない。トンネルインタフェース   を経由して転送を行う時、ソースアドレスと目的地アドレスをIPv6ヘッダの   外部にHAのアドレスとMRのCoAそれぞれを加えて、自動でカプセル化を行う。 6.6,Binding Ackの送信 MRはBAckと共に、MHにBAckを送るのに利用するいくつかのルールと以下の増進を 提供する。 HAは、BUの処理が成功したら、BAckに0を示すstatusコードをセットする。また、 MRフラグRにMobileNetworkのために転送を設定したことをMRに示すために設定す る。 もし、HAがMRのサポートを構成しないなら、BAckのstatusコードに140を設定す る。 もし、無効なBUでHAがプレフィックスへの転送のセットアップができないような 一つ以上のプレフィックスを受け取ったならば、MRに示すためにHAはstatusコー ド141をBAckに設定する。 もし、MRがBUに存在するパケットを転送するための一つ以上のプレフィックスに 公認されないHomeAddressを利用するなら、HAはこれに示すためにstatusコード 142をBAckに設定する。 もし、MobileNetworkに転送の設定を行う情報を決められないなら、HAは status143を設定する。MRがBUに何もプレフィックス情報を含まないならば、 Implicitモードを使う。 6.7,Mobile Network Prefixの登録解除 HAが登録解除のBUの処理に成功したとき、MRのHomeAddressを登録情報から削除 し、HomeAddressの代理を終了する。MIPv6仕様[1]で詳細な紹介がある。 それに加え、HAは双方向トンネルを取り払い、MobileNetworkへのパケットの転 送を停止する。HAはクリーンアップを行うために、暗黙か明白なソースから来た かどうか、どちらかの必要な情報を保つべきである。 Explicitモードでは、HAは現在のどんなMNPオプションも無視しなければならな い。 7,ダイナミックHAアドレス発見の変更 この文章は[1]で定義されたDHAADを拡張し、MRはそれをサポートするHAに登録を 試みるだけです。 7.1,DynamicHomeAgentDiscoveryRequestを修正する [1]で定義されたDHAAD要求メッセージに新しいフラグRを導入する。MRがこのフ ラグをセットすることで、MRをサポートするHAの発見を要求していることを示す。 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2,DynamicHomeAgentDiscoveryAddressRequestを修正する [1]で定義されたDHAADメッセージに新たなフラグRを導入する。もし、HAがMRの フラグRを含むDHADメッセージを受信したなら、MRをサポートするHAを登録し返 信をしなければならない。MRのサポートするフラグは、MRをサポートする少なく とも一つのHAがあれば設定しなければならない。もし、HAがMRをサポートしない なら、HAはサポートするMIPv6MNのみHAに登録し返信を行ってもよい。この場合、 MRのフラグを0に設定しなければならない。フォーマットは以下のようになる。 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.3,HA情報オプションの修正 [1]で定義されるHA情報オプションに新しいフラグRを導入する。もし、HAがMRを サポートするなら、フラグを設定するべきだ。 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8,ダイナミックルーティングプロトコルのサポート 今までに説明されたソリューションにおいて、HAがMRからのBUを受け取った時、 HAからMobileNetworkへの転送を設定した。これの代わりに、双方向トンネルを 経由するRIPngとOSPFのように、HAとMRのためにイントラドメインのルーティン グプロトコルを実行する。MRは、Homeリンクに接続して実行を行った時に、いく つかのルーティングプロトコルを実行し続けることができる。 イントラドメインのルーティングプロトコルの実行のサポートは、オプションで あり、MRとHAの構成に管理される。 特徴は、MobileNetworkが広大で異なるIPv6プレフィックスを持っている複数の サブネットの時、有用です。MobileNetwokrでのルートの変更は、早急にHAに通 知される。Homeリンクでのルートの変更は早急にMRに通知される。 MRがHomeリンクに接続している時、出口インタフェースを経由して送信されるル ート更新のためにルーティングプロトコルを実行する。MRが訪問先のネットワー クに移動し接続する時、訪問先リンクに接続するインタフェースでルート更新の 送信を止めるべきです。ルーティングプロトコルの認証が訪問先のネットワーク とMobileNetworkで可能でないなら、MobileNetowk特定のプレフィックスが訪問 先のネットワークに漏洩するチャンスを小さくする。通常の配置を実行すると、 Homeと訪問先両方で認められないルートを通知するのを妨ぐために適切な認証メ カニズムを含むことを予想する。MRはルーティングプロトコルメッセージを双方 向トンネルを経由してHAの方へ送信を開始する。多くのルーティングプロトコル はルーティング情報メッセージのソースアドレスとしてリンクローカルのアドレ スを利用する。MRはカプセル化したパケットの内側のIPv6ヘッダにリンクローカ ルアドレスを利用することを認める。しかし、MRか、HAのいずれかは他のリンク に転送を行ってはならない。 HAが内部のパケットを受け取った時、ルーティングテーブルに従ってルーティン グプロトコルメッセージにカプセル化の処理をし、更新を行う。通常のレーティ ングプロトコルの処理のように、双方向トンネルに設置された外部向きのインタ フェースで、ルーティング情報の次のホップ情報はMRのリンクローカルアドレス を満たす。 同様に、HAはMRに双方向トンネルを経由してルート更新を送信する。MRはルーテ ィングテーブルでメッセージを処理し更新を行う。HAによる全てのルート広告に よって、MRはHAに向けて双方向トンネルのインタフェースをセットする。 MRとHAがダイナミックルーティングプロトコルによってルートを変更する時、MR はHAへのBUにMNPを含めないべきです。構成に依存して、HAはBUのプレフィック ス情報とに基づくルートを加えてもよく、ルーティングプロトコルの更新にだけ りようしてもよい。さらに、BUとルーティングプロトコルの更新両方に含まれる プレフィックス情報は余計です。 HAからMRへのルーティングプロトコルメッセージが、潜在的にHomeNetworkの内 部のルーティング構造の情報を含むかも知れないので、メッセージは認証と秘密 性の保護が要求される。ふさわしい認証や秘密性保護のメカニズムは[14]で説明 され、利用しなければならない。ルーティングプロトコルメッセージの保護には [4]のIPsecESPを利用し、HAとMR間の双方向トンネルではHAとMRのアドレスをカ プセル化したメッセージの目的地アドレスやソースのように外部向けインタフェ ースのように扱う。 もし、MRとHAがOSPFv3のようなリンク状態のルーティングプロトコルを動作させ るなら、Appendix Bの推薦することに従うべきです。 9,セキュリティの考慮  略 10,IANAの考慮     略 11,貢献人       略 12,謝辞        略 13、参考文献      略 付録A,NEMOの動作例 このセクションでは、異なった管理ドメインに所属しているMRとMNを利用するこ とでNEMOプロトコルの図示を試みる。MRのMobileNetowrkはLocalFixedNode(LFN) とLocalFixedRouter(LFR)から成り立っている。LFRはアクセスリンクとして、 他の接続できるかもしれないほかのMNかMRをもつ。 Figure1はMRとMN両方がHomeにいる場合のシナリオを表している。 +----+ +-------+ | 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 ---------- Fifure1:MRとMNがHomeにいる場合 MRがHomeリンクから他へ移動し、訪問先に接続を行う。Figure2を見て。MRは訪 問先に接続してCoAを構成したとき、HA_MRにBUを行う。HA_MRはMRのHomeAddress の登録情報のエントリーを作成し、MobileNetwokのプレフィックスへの転送の準 備も行う。 +----+ +-------+ | 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 ---------- Figure2:MRが訪問先にいる場合 Figure3はMNが外部からHomeリンクに来て、MRに接続したことを表している。MN はMobileNetowrk内で広告されているプレフィックスからCoAを構成し、HA_MNと CN_MNにBUを送信する。HA_MNとCN_MN両方ともMNのHomeAddressの登録情報を作成 する。 +-------+ | 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 | +----+ Figeure3:訪問先リンクでMNがMRに接続した場合 ---- コメント等お願いします。 #comment

表示オプション

横に並べて表示:
変化行の前後のみ表示:
目安箱バナー