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