JP3878597B2 - ＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステム - Google Patents

Description

本発明はＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ６）におけるルーティングテーブル管理方法及びシステムに係り、特に、ＲＩＰｎｇ（Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ）を支援するＩＰｖ６ルータそれぞれのインターフェースごとに固有なインターフェースＩＤ（Ｉｎｔｅｒｆａｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を用いてルーティングテーブルを管理できるようにすることによって、多重ソースアドレスによるルーティングテーブル管理上の混乱を防止することができるようにする、ＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステムに関する。

コンピュータのインターネット（Ｉｎｔｅｒｎｅｔ）通信を提供する標準プロトコルであるＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）は、他のネットワークプロトコルと同様に階層で構成されているが、これをプロトコルスタック（ｓｔａｃｋ）、プロトコルスート（ｓｕｉｔ）またはプロトコル構造という。

ＴＣＰ／ＩＰプロトコルスタックは、ＴＣＰとＩＰという２個の最も重要なプロトコルを基盤にして構成されているが、ＩＰプロトコルはＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）階層３に該当するプロトコルであって現在バージョン４（ＩＰｖ４）が主に用いられており、物理的なサブネットワーキングの連結と目的地ＩＰアドレスを探していく経路を選択する機能がある。

このためにＩＰプロトコルは、インターネットに連結した多くの端末（ｔｅｒｍｉｎａｌｓ）やノード（ｎｏｄｅ；ＩＰプロトコルを具現する装置）の送信アドレスと受信アドレスを付与して解析する。現在インタネットワーク層では３２−ビットＩＰアドレスを用いてネットワーク上のホスト間相互通信を行う。ＩＰアドレスはネットワークＩＰとノードＩＰ（ホストＩＰ）を用いて特定ノードを区別する。

９０年代以後、インターネット使用の爆発的な増加によってＩＰｖ４プロトコルは割当可能な資源の不足、移動性（ｍｏｂｉｌｉｔｙ）欠如、保安性欠如などの短所によって改善の必要性が要求されて、このような短所を解決するための新しい標準プロトコルであるＩＰｖ６が開発された。

次世代ＩＰ（ＩＰｎｇ；Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ）とも呼ばれるＩＰｖ６プロトコルは、ＲＦＣ ２４６０（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２４６０）標準文書に記述されている。ＩＰｖ６プロトコルはＩＰアドレスの長さを既存の３２−ビットから１２８−ビットに拡張したことにより、インターネットアドレス資源枯渇問題を解決することができ、マルチメディアデータをリアルタイムに処理することができるようにするものである。ＩＰｖ６プロトコルは、ＩＰｖ４プロトコルでは保安機能のために'Ｉｐｓｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）'というパッチ（ｐａｔｃｈ）形態のプロトコルを別途に設置しなければならなかった問題を解決して、ＩＰｓｅｃをプロトコル内に搭載することによって保安機能を強化できるようにする等の長所がある。

ところが、ＩＰｖ６プロトコルは、ＩＰｖ４プロトコルと相異なるヘッダー構造を有しているために、両者のプロトコル間には互換性がない。したがって、今後は、ＩＰｖ４網が徐々にＩＰｖ６網やＩＰｖ４とＩＰｖ６を同時に支援する網に代替される展望である。また、最近では、ＩＰｖ６プロトコルの使用が多様な試験網と一部商用網を通じて徐々に拡大されている。

ＩＰｖ６応用ＴＣＰ／ＩＰ標準プロトコルは、アプリケーション階層（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）、ＴＣＰまたはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）で具現される伝送階層（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ）、ＩＰｖ６及び／またはＩＣＭＰｖ６（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ ＰｒｏｔｏｃｏｌｆｏｒＩＰｖ６）で具現されるインタネットワーク階層（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｌａｙｅｒ）及び物理階層（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）で構成される。

ＩＰｖ６データグラム（ｄａｔａｇｒａｍ）は、ＩＰｖ４と同様にヘッダーとペイロード（ｐａｙｌｏａｄ）２個部分で構成される。ペイロードは２個のホスト間で伝送されるデータを伝達する部分である。ＩＰｖ６ヘッダーは４０−バイトの固定サイズを有し、ＩＰｖ４で深刻なボトルネックとして明らかだったヘッダーチェック・サムフィールドをもたない。ＩＰｖ６プロトコルはＩＰｖ４プロトコルでは支援しない移動性支援、保安性支援、マルチメディア応用の品質保障などのためのヘッダー構造を有する。

そして、ＩＰｖ６標準プロトコルのヘッダーは、４−ビットのバージョンフィールド、８−ビットのトラフィッククラスフィールド、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）と関連した２０−ビットのストリームラベルフィールド、データの長さを示す１６−ビットの無符号整数ペイロード長フィールド、ＩＰｖ６ヘッダーから次に続くヘッダーの類型を定義する８−ビットのＮＨ（Ｎｅｘｔ Ｈｅａｄｅｒ）フィールド、パケットをフォワードする各ノードで１ずつ減少する８−ビットの無符号整数ホップフィールド、パケット送信者の１２８−ビットアドレスを示す発信地アドレスフィールド、パケット受信者の１２８−ビットアドレスを示す目的地アドレスフィールドを、基本ヘッダーフィールドに含むことができる。

ＩＰｖ６を完壁に具現するために含まれる拡張ヘッダーフィールドは、ホップ−バイ−ホップ（Ｈｏｐ−ｂｙ−Ｈｏｐ）オプションフィールド、目的地オプションヘッダー、ルーティングヘッダー、フラグメント（Ｆｒａｇｍｅｎｔ）ヘッダー、認証ヘッダー、ＥＳＰ（Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ）ヘッダーなどを含むことができる。

ところが、このようなＩＰｖ６標準プロトコルは、主にＰＣを用いる環境に適しているようにソフトウェアで具現されており、普通はウィンドウズ（Ｗｉｎｄｏｗｓ）（登録商標）、リナックス（Ｌｉｎｕｘ）（登録商標）、リアルタイム（Ｒｅａｌ−ｔｉｍｅ）ＯＳ等のようなＯＳにより処理されている。

一方、ルーティングプロトコルは、２種の一般的な範ちゅう、すなわち内部ゲートウエープロトコル（ＩＧＰ：Ｉｎｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）と外部ゲートウエープロトコル（ＥＧＰ：Ｅｘｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）に分けることができる。

ＩＧＰは、一ドメイン内で用いられるルーティングプロトコルであって、ＩＰｖ４で現在用いられる代表的なＩＧＰ用プロトコルとしてはＲＩＰ（Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）、ＩＳ−ＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ ｔｏ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ）などがある。

ＥＧＰは、相異なるドメイン間、特にＡＳｓ（Ａｕｔｏｎｏｍｏｕｓ Ｓｙｓｔｅｍｓ）間でルーティング情報を交換するために用いられるプロトコルであって、ＩＰｖ４の代表的なＥＧＰ用プロトコルとしてはＢＧＰ（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）等がある。

ＩＧＰは、ＥＧＰがルーティング情報を一つ以上のＡＳ間に伝達する期間、ＡＳ内でルーティング情報を伝達する。

原理的にＩＰｖ６ルーティング技術は、既存のＩＰｖ４と違う点がない。ただしルーティング政策面でＩＰｖ４よりはルート（ｒｏｕｔｅ）集合化（ａｇｇｒｅｇａｔｉｏｎ）等ＩＰｖ６アドレッシングによる厳格な規定を定義して、これに合うようにルーティングプロトコルを設定して運用しなければならないという点が違うだけである。

現在標準化されたり標準化中であるＩＰｖ６を支援するルーティングプロトコルは次の通りである。

ＩＰｖ６用ＩＧＰプロトコル：ＲＩＰｎｇ・ＯＳＰＦｖ６・ＩＰｖ６支援ＩＳ−ＩＳ

ＩＰｖ６用ＥＧＰプロトコル：ＢＧＰ４+

ＲＩＰは、距離ベクトル（ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ）基盤のアルゴリズムで具現された現在最も多く用いられているＩＧＰ用プロトコルである。

１９８８年に最初にこのプロトコルに対する定義が下されてＲＦＣ１０５８で標準化された。

ＲＩＰは、距離ベクトルアルゴリズムを基盤にしたプロトコルであって、プロトコル自体は簡単な反面、中小規模ネットワークのために設計されており、次のようなプロトコル自らの限界を有している。

第一に、最も長い経路が１５ホップであるネットワークに限定される。第二に、ルーティングループなどの状況を解決するために"無限大までカウンティング(counting unto infinity)"と呼ばれるプロセスを用いる。このプロセスは問題が解決される前に多量のネットワーク資源を消耗するようになる。

第三に、遅延、信頼度や負荷などのリアルタイムパラメーターに対する考慮はなく、代替経路を比較するために固定された測定基準を用いる。

ＲＩＰプロトコルは、ＲＦＣ １７２３（ＲＩＰｖ２）に続いてＲＦＣ ２０８０（ＩＰｖ６を支援するＲＩＰｎｇ規格）が定義されている。

図１は、一般的なＲＩＰｎｇのルーティングテーブルの構造を示した図面である。

図１に示したように、ＲＩＰｎｇが管理する一般的なＩＰｖ６用ルーティングテーブルエントリーは、目的地のＩＰｖ６プリフィクス（ｐｒｅｆｉｘ）１０、目的地までデータグラムを伝送するのに必要とされる全体費用（コスト）を表示するメトリック（ｍｅｔｒｉｃ）１６、ネクストホップ（ｎｅｘｔｈｏｐ）を示すｎｅｘｔ ｒｏｕｔｅｒのＩＰｖ６アドレス（ｎｅｘｔｈｏｐ ａｄｄｒｅｓｓ）２４、最近ルータが変化したか否かに対する情報を示す経路変化フラッグ（ｆｌａｇ）１８、ルーティングテーブル情報を隣のルータに伝送するのに必要な３０秒タイマー（ｔｉｍｅｏｕｔ ｔｉｍｅｒ，ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｉｏｎ ｔｉｍｅｒ）２０，２２の情報を有しなければならない。

ＲＩＰｎｇは、ＵＤＰ基盤のプロトコルであってＵＤＰポート番号５２１上でパケットを送受信する。ＲＩＰｎｇパケットはコマンド（要請または応答）、バージョンそして経路テーブルエントリーの３種のフィールドを含んでいる。

それぞれの経路テーブルエントリーは、ＩＰｖ６プリフィクス、外部ルータから内部ルータを分離させる経路タグ、プリフィクス内の重要なビット数を決定するプリフィクス長フィールド、そして現在の目的地メートルを定義するメーターを含んでいる。

この他にＲＩＰｎｇは、パケットのために即時に次のホップＩＰｖ６アドレスを明示する機能を提供する。次のホップは特定ＲＴＥ（Ｒｏｕｔｅ Ｔａｂｌｅ Ｅｎｔｒｙ）パケットとＮｅｘｔ Ｈｏｐ ＲＴＥ（Ｒｏｕｔｅ Ｔａｂｌｅ Ｅｎｔｒｙ）パケットを通じて指定される。

Ｎｅｘｔ Ｈｏｐ ＲＴＥ（Ｒｏｕｔｅ Ｔａｂｌｅ Ｅｎｔｒｙ）パケットは、メトリックフィールドでＦＦＨ値により識別される。経路タグとプリフィクス長さは送信時ゼロに設定して受信時には無視される。

この時ＲＩＰｎｇのネクストホップは、受信したＲＩＰｎｇパケットのネクストホップフィールド（ｆｉｅｌｄ）に明示される場合もあるしそうでない場合もある。

普通は０：０：０：０：０：０：０：０に指定され、受信したＲＩＰｎｇパケットのネクストホップが０：０：０：０：０：０：０：０である時、そのパケットを送信したルータのアドレスをネクストホップアドレスに指定する。

もしもネクストホップアドレスが明示されている場合、このアドレスは必ずリンクローカルアドレス（ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓ）でなければならない。

なぜならＲＩＰｎｇは、ＩＰｖ４バージョンであるＲＩＰがデザインされた時、内部ゲートウエープロトコル（ＩＧＰ：Ｉｎｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）でデザインされてｄｉｒｅｃｔｌｙ−ｃｏｎｎｅｃｔｅｄネットワークでだけその情報が有効で、リンクローカル範囲（ｌｉｎｋ−ｌｏｃａｌｓｃｏｐｅ）で用いられるためにリンクローカルアドレスだけを用いる。

すなわち、ＲＩＰｎｇではデータグラムのＩＰｖ６ソースアドレス（ｓｏｕｒｃｅ ａｄｄｒｅｓｓ）は必ずリンクローカルアドレスでなければならない。

ＲＩＰｎｇバージョン１は、要請と応答という２種のコマンドを支援する。要請はルーティングテーブル全部または一部を要求するのに用いられる。大部分の場合要請はＲＩＰｎｇ（ポート５２１）からマルチキャスターとして送信される。

単にルータ一つに対する情報が必要である場合の要請は、ＲＩＰｎｇポート以外に他のポートからそのルータに直接送信されることになる。

応答には特定質疑に対する応答、すべての隣接したルータに３０秒ごとに送信される応答である規則的なアップデート、そしてルータ変化を起こすアップデートの３つの応答タイプがある。

要請と応答パケット処理に対する定義はＲＦＣ ２０８０、ＲＦＣ ２０８１で定義されている

ＲＦＣ ２０８０によれば、ＲＩＰｎｇで応答メッセージを発生することにおいて、ＲＩＰｎｇポートでない他のポートのユニキャスト要求メッセージに対して応答する場合以外にはＩＰｖ６ソースアドレスとして送信側ルータインターフェースの使用可能なリンクローカルアドレスが用いられなければならない。

ユニキャスト要求メッセージに対する応答の場合に用いるソースアドレスは、グローバルに有効なアドレス（ｇｌｏｂａｌｙ ｖａｌｉｄ ａｄｄｒｅｓｓ）でなければならない。

そしてルータの使用可能なリンクローカルアドレスをＩＰｖ６ソースアドレスとして用いることは応答メッセージを受信した受信側ルータがルーティングテーブルの次のホップとしてソースアドレスを用いるためである。

もしも誤ったソースアドレスを用いれば、他のルータはデータグラムをルーティングできない。

時々ルータは、複数個のＩＰｖ６アドレスを一つの物理的なインターフェースのためのアドレスとして用いる。

通常これは、いくつかの論理的なＩＰｖ６のネットワークが一つの物理的な媒体により具現されることができるものを意味する。

一つのルータが一つの物理的なインターフェースのために複数のリンクローカルアドレスを用いることが可能である。

図２は、一般的なＩＰｖ６ルータのインターフェースに指定された多重ソースアドレスの例示図であって、ＩＰｖ６ルータの一つのインターフェースに多重のグローバルＩＰｖ６アドレス（ｍｕｌｔｉｐｌｅ ｇｌｏｂａｌ ＩＰｖ６ ａｄｄｒｅｓｓｅｓ）が指定されたり、多重のリンクローカルＩＰｖ６アドレス（ｍｕｌｔｉｐｌｅｌｉｎｋ−ｌｏｃａｌ ＩＰｖ６ ａｄｄｒｅｓｓｅｓ）の指定が可能なものを示す。

図２を参照すれば、ＩＰｖ６ルータのインターフェースｅｔｈ０には多重のＩＰｖ６リンクローカルアドレスが、ＩＰｖ６ルータのインターフェースｅｔｈ１は多重のＩＰｖ６グローバルアドレスが指定されている。

このようにＩＰｖ６ルータ一つのインターフェースに多重ソースアドレスが指定される理由は、いくつかのソースアドレスと目的地アドレスのうち最適のアドレスを選択して用いることによって目的地までの最も効率的なルーティング経路を探すためである。

このために最適のソースアドレスと目的地アドレスを選択するための技法が現在活発に研究中にある。

一方、このように一つのルータが一つの物理的なインターフェースのために複数のリンクローカルアドレスを用いる場合にルータは、インターフェースのために定義されたリンクローカルアドレスのうちから一つのソースアドレスを用いて応答メッセージを生成しなければならない。

そして、現在使用中のローカルアドレスが有効でない場合に他のローカルアドレスに交替して用いるようになる。

そしてこのようなソースアドレスの交替は、応答メッセージを受信した受信側ノードがソースアドレスで送信側を区別するために用いるために必要である。

もしも同一ルータから他のソースアドレスを用いたマルチパケットをルータが受信するようになれば、ルータはマルチパケットが相異なるルータから受信されたと推測するようになって望ましくない動作を誘発するようになる。

すなわち、同じルータから受信したいくつかのパケットが各々他のリンクローカルアドレスをソースアドレスに指定しているならば、パケットを受信したＲＩＰｎｇルータはこのパケットを各々他のルータから受信したとして処理する。

そして、ネットワークプリフィクスを含んでいるパケットを伝送するルータがいままで用いたリンクローカルアドレスがこれ以上有効でなくなって新しいリンクローカルアドレスをソースアドレスに指定して伝送するとしても、受信するルータ側ではこのパケットを他のルータから受信したとして処理するようになる。

例えば、Ｒ１ルータがＩ１インターフェースに指定されたｆｅ８０：：１：２：３：４／１０というリンクローカルアドレスをソースアドレスとしてＲ２ルータにメトリックが３である１０．０．０．０／８に関するルーティング情報を伝送した後、次のアップデート周期内にｆｅ８０：：１：２：３：４／１０アドレスが有効でなくなってｆｅ８０：：５：６：７：８／１０アドレスをソースアドレスに選択し、メトリックが５に変えられてＲ２ルータに１０．０．０．０／８に関するアップデートパケットを伝送すると仮定する。

この時、Ｒ２ルータは、以前に受信したルーティング情報と二番目に受信したルーティング情報が相異なるソースルータから受信したものと考えて、これに対するＤｅｃｉｓｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ過程を遂行する。

その結果、二番目に受信したメトリックが５であってプリフィクスが１０．０．０．０／８であるルーティング情報は無視される。すなわち、ＩＰｖ６ルータは多重のリンクローカルアドレスを用いることによってソースアドレス選択において混とんをもたらす可能性があり、受信側ルータでは誤ったルーティング情報をルーティングテーブルにもつ可能性がある。

以上の例のように、ＲＩＰｎｇルータの誤った動作を防止するためにソースアドレス選択に関するいろいろなアルゴリズムが研究中にある。しかしこのアルゴリズムは多重のアドレスのうちどのアドレスをソースアドレスとして選択するかに関する技法であって、アルゴリズムによってソースアドレスを選択するうちにソースアドレスが変えられる場合には、同様にＲＩＰｎｇルータに混とんを引き起こす可能性がある。

本発明は上記のような問題点を解決するために案出されたものであって、本発明の目的は、ＲＩＰｎｇを支援するＩＰｖ６ルータのインターフェースに多重ソースアドレスが指定されてルーティングテーブルを管理する際に発生する混乱を防止することができるようにした、ＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステムを提供することにある。

また本発明の他の目的は、一つのインターフェースに多重リンクローカルＩＰｖ６アドレスを指定することによるルーティング問題を防止することができるようにしたルーティングテーブル管理方法及びシステムを提供することにある。

このような目的を達成するための第１の発明によるＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法では、複数個のルータと複数個のホストで構成されたネットワークに適用されるルーティングテーブル管理方法において、
第１ルータは、１のフィールドであるプリフィクスフィールド（５０）にインターフェースＩＤ値を含み、他の１のフィールド（５６）に該インターフェースＩＤが保存されていることを知らせる所定値を含むルーティング情報パケットを第２ルータに伝送する第１段階と、前記第２ルータは、前記第１ルータから受信したルーティング情報パケットの前記他の１のフィールド（５６）に前記所定値が含まれている場合、前記１のフィールドであるプリフィクスフィールドに含まれるインターフェースＩＤ値を抽出する第２段階と、 抽出された該インターフェースＩＤ値と同様なインターフェースＩＤ値に従ってルーティング情報をアップデートする第３段階と、を含んで構成されたことを特徴とする。

第２の発明は、第１の発明において、前記プリフィクスフィールド（５０）に指定されるインターフェースＩＤ値は、ＭＡＣアドレスを用いて生成可能である。

第３の発明は、第１の発明において、前記第１段階は、前記第１ルータが受信したインターフェース情報からインターフェースＩＤを抽出する段階と、該第１ルータが前記他の１のフィールド（５６）に前記所定値を指定する段階と、前記第１ルータが前記１のフィールドであるプリフィクスフィールドに前記抽出されたインターフェースＩＤ値を指定する段階と、前記他の１のフィールド（５６）に指定された前記所定値及び前記１のフィールドであるプリフィクスフィールドに指定された前記インターフェースＩＤを含むルーティング情報を有するルーティング情報パケットを生成する段階と、前記第１ルータが生成したルーティング情報パケットを前記第２ルータに伝送する段階とを含む。

また、第４の発明は、第１の発明において、前記第３段階は、ルートエントリーが有する前記インターフェースＩＤ値と同じインターフェースＩＤ値が、前記第２ルータが保存するルーティングテーブルに存在するか否かを判断する段階と、ａ）前記判断の結果、インターフェースＩＤ値の同じルートエントリーが存在すれば、該ルートエントリーのルーティング情報を、受信されたルーティング情報パケットのルーティング情報でアップデートし、ｂ）前記判断の結果、インターフェースＩＤ値の同じルートエントリーが存在しなければ、受信されたインターフェースＩＤ値をソースルータのインターフェースＩＤ値に指定し、受信されたルーティング情報パケットのルーティング情報を利用してルートエントリーを生成する段階とを含む。

また、第５の発明は、第１または第３の発明において、前記第１ルータと前記第２ルータとの間のルーティングプロトコルにＩＧＰが用いられる。

また、第６の発明は、第１または第３の発明において、前記第１ルータと前記第２ルータとの間のルーティングプロトコルにＲＩＰｎｇが用いられる。

また、第７の発明は、第１または第３の発明において、前記所定値を指定した他の１のフィールド（５６）が、メトリック指定フィールドであり、そのフィールド値として１７〜２５５のうち少なくとも一つを用い、第８の発明は、第７の発明のメトリック指定フィールドのフィールド値として２５５を用いる。

さらに、第９の発明は、複数個のルータと複数個のホストで構成されたネットワークに適用されるルーティングテーブル管理システムにおいて、１のフィールドであるプリフィクスフィールド（５０）にはインターフェースＩＤ値を含み、他の１のフィールド（５６）には前記１のフィールドであるプリフィクスフィールドにインターフェースＩＤが保存されていることを知らせる所定値を含むルーティング情報パケットを第２ルータに伝送する第１ルータと、前記第１ルータから受信したルーティング情報パケットの他を分析して前記所定値を検出した場合、前記１のフィールドであるプリフィクスフィールドの値をソースルータのインターフェースＩＤにアップデートする第２ルータとを備えることを特徴とする。

第１０の発明は、第９の発明において、前記第１ルータは、ａ）受信したインターフェース情報からインターフェースＩＤを抽出し、ｂ）前記他の１のフィールド（５６）に前記所定値を指定し、ｃ）前記プリフィクスフィールド（５０）に前記抽出されたインターフェースＩＤを指定し、ｄ）前記所定値が指定された前記他の１のフィールド（５６）と前記インターフェースＩＤが指定された前記１のフィールドであるプリフィクスフィールドとを含むルーティング情報を有するルーティング情報パケットを生成し、ｅ）該生成したルーティング情報パケットを前記第２ルータに伝送する構成とする。

本発明によれば、一つのインターフェースに多重のＩＰｖ６リンクローカルアドレスが指定されることによって発生し得るルーティング問題を解決することができる効果がある。

また、本発明によれば、デフォルトアドレス選択技法（ｄｅｆａｕｌｔ ａｄｄｒｅｓｓ ｓｅｌｅｃｔｉｏｎ ｍｅｃｈａｎｉｓｍ）においていまだにアプリケーションレベル（ａｐｐｌｉｃａｔｉｏｎ ｌｅｖｅｌ）で解決するか否かに対する議論が続いている実情で、アプリケーションレベルより下位レベルでこれを制御するとしても物理的なインターフェース（ｐｈｙｓｉｃａｌ ｉｎｔｅｒｆａｃｅ）の固有ＩＤを用いるならば、ソースアドレスが何であっても関係なくＲＩＰｎｇを用いることができるようにする効果がある。

以下、本発明によるＩＰｖ６においてインターフェースＩＤを利用したルーティングテーブル管理方法及びシステムの実施形態につき、添附した図面を参照しながら詳細に説明する。

図３は、本発明が適用される複数のルータの連結状態図であって、多重のＩＰｖ６リンクローカルアドレスが指定されているインターフェースを有し、修正されたＲＩＰｎｇを搭載している複数のＩＰｖ６ルータRouterＡ〜Ｅと、これら複数のルータＡ〜Ｅに連結している複数のＩＰｖ６ホストHostＡ，Ｂとを備えている。ここで、ルータＡ〜ＥとホストＡ，Ｂは同じネットワーク上に設置されていなければならない。

修正されたＲＩＰｎｇを搭載しているソースルータＡ〜Ｅは、隣接するルータＡ〜Ｅにルーティング情報を含んだパケットを伝送する場合に、ソースアドレスの代りに用いるインターフェースＩＤを伝送する。

インターフェースＩＤは、各インターフェースごとに唯一のＩＤであって、一つのインターフェースに多重のＩＰｖ６リンクローカルアドレスが指定されているとしても、ＭＡＣアドレスを利用してインターフェースＩＤを生成することでインターフェースＩＤはただ一つだけ存在する。本発明においては説明の便宜のために、インターフェースＩＤを生成するのにＭＡＣアドレスを用いるイーサネット（登録商標）を例に挙げたが、イーサネット（登録商標）以外の他のリンクの場合にも標準で定義されている事項によってインターフェースＩＤを生成できる。たとえば、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）の場合にはＲＦＣ２４９２に、トークンリングの場合にはＲＦＣ２４７０に、ＦｒａｍｅＲｅｌａｙの場合にはＲＦＣ２５９０に、ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）の場合にはＲＦＣ２４６７に、ＮＢＭＡ（Ｎｏｎ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉ Ａｃｃｅｓｓ）の場合にはＲＦＣ２４９１に各々その標準が定義されている。

図１及び図２でインターフェースｅｔｈ０のリンクローカルアドレスは、２個が指定されているが、このうちｆｅ８０：：２０４：７６ｆｆ：ｆｅ６ｆ：７ｃ１ｆ／１０でｆｅ８０はプリフィクスアドレスであって、２０４：７６ｆｆ：ｆｅ６ｆ：７ｃ１ｆがインターフェースＩＤである。

図４Ａは、一般的なＲＩＰｎｇパケットフォーマットであって、図４Ｂはルートテーブルエントリーフォーマットである。

図４Ａに示したように、一般的なＲＩＰｎｇパケットフォーマットは、コマンド（ｃｏｍｍａｎｄ）３０、バージョン（ｖｅｒｓｉｏｎ）３２、複数のルートテーブルエントリー（ｒｏｕｔｅ ｔａｂｌｅ ｅｎｔｒｙ）４０ａ〜４０ｎで構成されており、ルートテーブルエントリー４０ａ〜４０ｎはＩＰｖ６プリフィクス５０、ルートタグ（Ｒｏｕｔｅ Ｔａｇ）５２、メトリック（ｍｅｔｒｉｃ）５６で構成されている。また、各ルートテーブルエントリー４０ａ〜４０ｎはプリフィクス長フィールド（Ｐｒｅｆｉｘ Ｌｅｎｇｔｈ Ｆｉｅｌｄ）５４を含む。

ここでソースアドレスの代わりに用いるインターフェースＩＤは、パケット当たり一つだけあれば良いので、ＲＩＰｎｇパケットのメトリック値が０ｘＦＦの場合にプリフィクス５０にはインターフェースＩＤが指定されていることにすることができる。ここで０ｘＦＦ値を用いたことはメトリック値に１バイト（Ｂｙｔｅ）が使用可能であり、そのうちから０〜１６までが現在用いられているために１７〜２５５までが本発明と関連して使用可能であって１７〜２５５中から２５５を選択したのである。

一方、修正されたＲＩＰｎｇを搭載しているルータＡ〜Ｅのルーティングテーブルには、ソースルータＡ〜ＥのインターフェースＩＤ値を貯蔵するためにインターフェースＩＤフィールドを具備する。図５は修正されたＲＩＰｎｇのルーティングテーブル構造に、別途のインターフェースＩＤフィールドが備わっていることを示す。

図５に示したように、修正されたＲＩＰｎｇのルーティングテーブルには、目的地のＩＰｖ６プリフィクス６０、ルートタグ（ｒｏｕｔｅ ｔａｇ）６２、プリフィクス長（Ｐｒｅｆｉｘ ｌｅｎ）６４、目的地までの距離を示すメトリック（ｍｅｔｒｉｃ）６６、フラッグ（ｆｌａｇ）６８、タイマー（ｔｉｍｅｏｕｔ ｔｉｍｅｒ，ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｉｏｎ ｔｉｍｅｒ）７０，７２、ネクストホップを示すｎｅｘｔ ｒｏｕｔｅｒのＩＰｖ６アドレス（ｎｅｘｔｈｏｐ ａｄｄｒｅｓｓ）７４を有し、さらに、インターフェースＩＤ値を貯蔵するためのインターフェースＩＤフィールド（ｉｎｔｅｒｆａｃｅ ＩＤ）７６を有している。

修正されたＲＩＰｎｇを搭載しているルータＡ〜Ｅは、ルーティング情報を含んでいるパケットが受信されると、受信されたパケットのルートテーブルエントリー４０ａ〜４０ｎのうちメトリック値が０ｘＦＦであるルートテーブルエントリーがある場合にそのプリフィクス５０にはインターフェースＩＤが貯蔵されているので、当該プリフィクスフィールドの値をそのパケットのソースルータＡ〜ＥのインターフェースＩＤフィールド７６に貯蔵する。

そして、ルータＡ〜Ｅは、ルートエントリーを処理する場合にインターフェースＩＤが同一であるか否かを比較して、同じ場合には同じソースルータＡ〜Ｅから受信したルートエントリーとして処理する。すなわち、インターフェースＩＤはインターフェースごとに唯一の値である。

この時、ルータＡ〜Ｅは、パケット受信時のソースアドレスが違う場合にインターフェースＩＤを比較し、同じ場合には、同じソースルータＡ〜Ｅから受信したエントリーとして処理する。その前には、ルーティングテーブルのネクストホップは新しいソースアドレスにアップデートする。

また、ルーティングテーブルを検索する時、インターフェースＩＤが同じエントリーをまず検索した後に一致するプリフィクスを選択し、この時ソースアドレスは検索する必要がない。

なぜならインターフェースＩＤが一致すればソースアドレスが違ったとしても同じルータＡ〜Ｅから受信したルートエントリー情報であるためである。

図６は、本発明に係る、送信側ルータのルーティング情報を含んだパケットの生成及び伝送過程を示すフローチャートである。

図６に示したように、送信側ルータはインターフェース情報から固有なインターフェースＩＤを抽出して（段階Ｓ１００）、パケット生成時の最上位ルートエントリーのメトリックフィールドに０ｘＦＦ値を指定して（段階Ｓ１０２）、ルートエントリーのプリフィクスにインターフェースＩＤが指定されていることを表示する。

次に、送信側ルータは、メトリックフィールドに０ｘＦＦ値が指定されているルートエントリーのプリフィクスにインターフェースＩＤ値を指定して（段階Ｓ１０４）、既存のＲＩＰｎｇパケット生成過程を経てパケット生成を完了し（段階Ｓ１０６）、生成されたＲＩＰｎｇパケットを他のルータに伝送する（段階Ｓ１０８）。

図７は、本発明に係る、受信側ルータのルーティング情報を含んだ受信パケットの処理過程を示すフローチャートである。

図７に示したように、受信側ルータは、ＲＩＰｎｇパケットが受信されると（段階Ｓ２１０）、ルートエントリーのメトリックフィールド値が０ｘＦＦなのかを判断する（段階Ｓ２１２）。

判断結果、メトリックフィールド値が０ｘＦＦ値でなければ既存ＲＩＰｎｇによるプロセスを進行し（段階Ｓ２１４）、メトリックフィールド値が０ｘＦＦ値ならばプリフィクスフィールドにソースルータのインターフェースＩＤ値が指定されているのでプリフィクス値を抽出して（段階Ｓ２１６）、インターフェースＩＤ値が同じルーティングテーブルが存在するかを判断する（段階Ｓ２１８）。

判断結果、インターフェースＩＤの同じルーティングテーブルが存在すれば当該ルーティングテーブルをアップデートして（段階Ｓ２２０）、インターフェースＩＤの同じルーティングテーブルが存在しなければソースルータのインターフェースＩＤ値で貯蔵する（段階Ｓ２２２）。

なお、本例ではＩＰｖ６のためのルーティングプロトコルとしてＲＩＰ（Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を取り扱ったが、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）とＩＳ−ＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ ｔｏ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ）等、小規模のネットワークに用いられるＩＧＰでも使用可能である。

本発明の技術思想につき、上記の実施形態によって具体的に説明したが、上記実施形態は説明のためのものであり、制限のためのものでないことを注意しなければならない。また、本発明の技術分野の通常の専門家ならば本発明の技術思想の範囲で多様な実施例が可能なことを理解できるものである。

一般的なＲＩＰｎｇのルーティングテーブルの構造を示した図。 一般的なＩＰｖ６ルータのインターフェースに指定された多重ソースアドレスに対する一例を示した図。 本発明が適用される複数のルータに対する連結状態を示した図。 図４Ａは一般的なＲＩＰｎｇパケットフォーマット、図４Ｂはルートテーブルエントリーフォーマット。 本発明による修正されたＲＩＰｎｇのルーティングテーブル構造を示した図。 本発明に係る送信側ルータのルーティング情報を含んだパケットの生成及び伝送過程を示すフローチャート。 本発明に係る受信側ルータのルーティング情報を含んだ受信パケットの処理過程を示すフローチャート。

符号の説明

RouterＡ〜ＲＥ：ルータ
HostＡ，Ｂ：ホスト

Claims (10)

1. 複数個のルータと複数個のホストで構成されたネットワークに適用されるルーティングテーブル管理方法において、
   第１ルータは、１のフィールドである１のフィールドであるプリフィクスフィールド（５０）にインターフェースＩＤ値を含み、他の１のフィールド（５６）に該インターフェースＩＤが保存されていることを知らせる所定値を含むルーティング情報パケットを第２ルータに伝送する第１段階と、
   前記第２ルータは、前記第１ルータから受信したルーティング情報パケットの前記他の１のフィールド（５６）に前記所定値が含まれている場合、前記１のフィールドであるプリフィクスフィールドに含まれるインターフェースＩＤ値を抽出する第２段階と、
   抽出された該インターフェースＩＤ値と同様なインターフェースＩＤ値に従ってルーティング情報をアップデートする第３段階と、を含んで構成されたことを特徴とするルーティングテーブル管理方法。
2. 前記プリフィクスフィールド（５０）に指定されるインターフェースＩＤ値は、ＭＡＣアドレスを用いて生成される請求項１に記載のルーティングテーブル管理方法。
3. 前記第１段階は、
   前記第１ルータが受信したインターフェース情報からインターフェースＩＤを抽出する段階と、
   前記第１ルータが前記他の１のフィールド（５６）に前記所定値を指定する段階と、
   該第１ルータが前記プリフィクスフィールドに前記抽出されたインターフェースＩＤ値を指定する段階と、
   前記他の１のフィールド（５６）に指定された前記所定値及び前記１のフィールドであるプリフィクスフィールドに指定された前記インターフェースＩＤを含むルーティング情報を有するルーティング情報パケットを生成する段階と、
   前記第１ルータが生成したルーティング情報パケットを前記第２ルータに伝送する段階と、を含む請求項１に記載のルーティングテーブル管理方法。
4. 前記第３段階は、
   ルートエントリーが有する前記インターフェースＩＤ値と同じインターフェースＩＤ値が、前記第２ルータが保存するルーティングテーブルに存在するか否かを判断する段階と、
   ａ）前記判断の結果、インターフェースＩＤ値の同じルートエントリーが存在すれば、該ルートエントリーのルーティング情報を、受信されたルーティング情報パケットのルーティング情報でアップデートし、
   ｂ）前記判断の結果、インターフェースＩＤ値の同じルートエントリーが存在しなければ、受信されたインターフェースＩＤ値をソースルータのインターフェースＩＤ値に指定し、受信されたルーティング情報パケットのルーティング情報を利用してルートエントリーを生成する段階と、を含む請求項１に記載のルーティングテーブル管理方法。
5. 前記第１ルータと前記第２ルータとの間のルーティングプロトコルにＩＧＰが用いられる請求項１または請求項３に記載のルーティングテーブル管理方法。
6. 前記第１ルータと前記第２ルータとの間のルーティングプロトコルにＲＩＰｎｇが用いられる請求項１または請求項３に記載のルーティングテーブル管理方法。
7. 前記所定値を指定した他の１のフィールド（５６）が、メトリック指定フィールドであり、そのフィールド値として１７〜２５５のうち少なくとも一つを用いる請求項１または３に記載のルーティングテーブル管理方法。
8. 前記メトリック指定フィールドのフィールド値として２５５を用いる請求項７に記載のルーティングテーブル管理方法。
9. 複数個のルータと複数個のホストで構成されたネットワークに適用されるルーティングテーブル管理システムにおいて、
   １のフィールドであるプリフィクスフィールド（５０）にはインターフェースＩＤ値を含み、他の１のフィールド（５６）には前記１のフィールドであるプリフィクスフィールドにインターフェースＩＤが保存されていることを知らせる所定値を含むルーティング情報パケットを第２ルータに伝送する第１ルータと、
   前記第１ルータから受信したルーティング情報パケットの他の１のフィールド（５６）を分析して前記所定値を検出した場合、前記１のフィールドであるプリフィクスフィールドの値をソースルータのインターフェースＩＤにアップデートする第２ルータと、を備えることを特徴とするルーティングテーブル管理システム。
10. 前記第１ルータは、
    ａ）受信したインターフェース情報からインターフェースＩＤを抽出し、
    ｂ）前記他の１のフィールド（５６）に前記所定値を指定し、
    ｃ）前記プリフィクスフィールド（５０）に前記抽出されたインターフェースＩＤを指定し、
    ｄ）前記所定値が指定された前記他の１のフィールド（５６）と前記インターフェースＩＤが指定された前記１のフィールドであるプリフィクスフィールドとを含むルーティング情報を有するルーティング情報パケットを生成し、
    ｅ）該生成したルーティング情報パケットを前記第２ルータに伝送する請求項９に記載のルーティングテーブル管理システム。