JP2006506007A - サービスに基づくポリシーの実施点として働くネットワークゲートウエイにおけるデータパケットのフィルタリング - Google Patents

Abstract

本発明は、パケットデータ通信セッション中に、ソースコードノードからネットワークゲートウエイを介して宛先ノードへ伝送されるデータパケットをフィルタにかける方法に関する。フィルタリングは、前記ネットワークゲートウエイ（ＧＧＳＮ）において行われる。宛先ノードまたはソースノードは、セッションの第１の期間中には、第１のネットワークアドレスをもち、セッションの次の第２の期間中には、第２の異なるアドレスをもつ。データパケットは、宛先アドレスと拡張ヘッダとを含むヘッダをもち、拡張ヘッダは、前記第２の期間中に別のアドレス情報を伝送するのに使用され、方法は、宛先アドレスも、拡張ヘッダも所定のアドレス基準に整合しないデータパケットを選択的にブロックすることを含む。

Description

本発明は、セッション中にパケットヘッダの宛先アドレスが変わったときに、パケット交換式データネットワークのゲートウエイノードが、宛先アドレスに基づくパケットフィルタを維持できるようにする装置および方法に関する。
本発明は、限定はしないが、とくに、２Ｇまたは３Ｇの汎用パケット無線サービス（General Packet Radio Service, GPRS）ネットワークの汎用パケット無線サービスのゲートウエイ支援ノード（General Packet Radio Service Gateway Support Node, GGSN）が、ＧＰＲＳネットワークから出て行くか、またはそこに到達するパケットの宛先アドレスに基づいて、サービスに基づくローカルポリシー（Service-Based Local Policy, SBLP）に基づくゲーティング機能を適用できるようにし、一方で、ＩＰセッション中に宛先アドレスが変わることになり得るネットワークローミングを支援する装置および方法に関する。

グローバル システム フォー モバイル コミュニケーションズ(Global System for Mobile Communications, GSM)標準にしたがうネットワークのような、従来の２Ｇ移動ネットワークが、ユーザの移動局（mobile station, MS）に、回線交換式の音声およびデータサービスを与えてきたが、移動遠隔通信業界には、パケット交換式移動ネットワークを展開する大きな動きがある。パケット交換式移動ネットワークは、ネットワークおよび無線資源の効率に非常に優れており、また、より高度なユーザサービスを与えることもできる。固定形と移動形の遠隔通信ネットワークを収束させるとき、固定ネットワークにおいて普及しているインターネットプロトコル（Internet Protocol, IP）は、移動パケットネットワークのためのパケットルーティング機構としての当然の選択である。現在、固定ネットワークの領域では、ＩＰバージョン４（IP version 4, IPv4）の使用が普及している。しかしながら、ＩＰバージョン６（IPv6）へ次第に移行すると期待されている。ＩＰｖ６は、ＩＰｖ４よりも、とくに、相当に増大したアドレス空間、より効率的なルーティング、より大きなスケーラビリティ、向上したセキュリティ、サービス品質（Quality of Service, QoS）の統合、マルチキャスティングの支援、および他の特徴に関して、十分に認められる特長をもつ。

現在展開されている移動パケット交換サービスの特定の例は、２ＧのＧＳＭネットワークおよび３Ｇのユニバーサル モバイル テレコミュニケーション システム（Universal Mobile Telecommunications System, UMTS）ネットワークの両者（以下では、ＧＰＲＳネットワークと呼ぶ）において実行される汎用パケット無線サービス（ＧＰＲＳ）を含む。無線ローカルエリアネットワーク（wireless Local Area Network, wLAN）のような、ＧＰＲＳ以外の無線アクセス技術は、ホットスポットのような領域（会議場、空港、展示場、等）におけるローカルブロードバンドサービスのアクセスにおいて、柔軟性および経済性のＧＰＲＳへの補足を与えることも期待される。したがって、移動ネットワークのオペレータは、ＧＰＲＳと、ＧＰＲＳ以外のネットワークまたはサブネットワークとの間における移動局のローミングを支援することを望んでいる。

3G TS 23.060 v3.12.0(2002-06)として参照され、３ＧＰＰのウエブサイトからhttp://www.3gpp.org/ftp/specs/2002-06/R1999/23 series/において得られる、ＧＰＲＳのサービス説明（１９９９年リリース）の技術仕様（GPRS Service Description (release 1999) Technical Specification）を参照すると、２Ｇ（ＧＰＲＳ／ＧＳＭ）および３Ｇ（ＧＰＲＳ／ＵＭＴＳ）の移動パケットネットワークの詳細なサービスの説明が得られる。また、ＧＰＲＳネットワークの機能は、一般によく知られているが、別の側面を、これより詳しく記載することにする。

ＧＰＲＳのパケット交換サービスにアクセスするために、ＭＳは、先ず、ＳＧＳＮについて（２Ｇ ＧＳＭ ＧＰＲＳの付加または３Ｇ ＵＭＴＳ ＧＰＲＳの付加の何れかの）ＧＰＲＳ付加手続きを行なう。認証および位置更新手続きを行ない、成功であるときは、ＧＰＲＳ付加手続きは、ＭＳが、ＳＧＳＮおよび到来パケットデータの通知によってページングできるようにする。しかしながら、パケットデータを実際に送受信するには、ＭＳは、割り当てられたパケットデータプロトコル（Packet Data Protocol, PDP）のアドレス（例えば、ＩＰアドレス）をもち、そのＰＤＰアドレスで使用するための少なくとも１つのＰＤＰの文脈をアクティブにしなければならない。ＭＳの各ＰＤＰアドレスは、それと関係付けられた１つ以上のＰＤＰの文脈をもち、ＰＤＰの文脈を定めるデータは、ＭＳ、ＳＧＳＮ、およびＧＧＳＮに記憶される。ＰＤＰの文脈をアクティブにする処理を行うと、ＭＳは、ＳＧＳＮだけでなく、対応するＧＧＳＮにも認識され、外部データネットワークとのインターワーキングを開始できる。

当初から移動ネットワークとして設計されたＧＰＲＳネットワークが、（ＧＰＲＳネットワーク内のＭＳのための）移動管理および（ＧＰＲＳネットワーク間をローミングするＭＳのための）ローミング機能を取り入れる一方で、インターネット技術標準化委員会（Internet Engineering Task Force, IETF）では、ＩＰユーザ端末の移動を全般的に支援する研究も行なわれた。このために、ＩＥＴＦは、モバイルＩＰ（Mobile IP, MIP）プロトコルを開発した。ＭＩＰは、移動局（または、ＭＩＰの用語では移動ノード（mobile node, MN））が、異なるサブネットプレフィックスをもつＩＰネットワーク間を移動するとき（マクロ移動）の移動を支援するように設計されている。例えば、ＭＩＰは、ＧＰＲＳネットワークと、ｗＬＡＮネットワークのようなＧＰＲＳ以外のネットワークとの間の移動を支援するのに使用される。モバイルＩＰは、ネットワークまたはサブネットワーク内の移動（ミクロ移動）の管理には使用されないと考えられる。ミクロ移動は、一般に、ＷＣＤＭＡのソフター／ソフトハンドオーバのような、レイヤ２の機構に特定のアクセス技術によって管理される。

ＩＰの２つのバージョンに対応するＭＩＰの２つのバージョンがある。ＭＩＰバージョン４（MIP version 4, MIPv4）は、ＩＰバージョン４（IP version 4, IPv4）のアドレスにＩＰアドレスの移動性を与えるように設計され、一方で、より新しいＭＩＰバージョン６（MIP version 6, MIPv6）のＭＩＰは、ＩＰバージョン６（IP version 6, IPv6）のアドレスにＩＰアドレスの移動性を与えるように設計されている。ＭＩＰｖ４は、IETF Request For Comment (RFC) 2002に記載されており、なお、RFC 2002は、ＩＥＴＦのウエブサイトのhttp://www.ietf.org/rfc/rfc2002.txt?number=2002において得られる。インターネットの草案のＭＩＰｖ６は、2002年10月29日付けのＩＥＴＦのインターネットの草案、“Mobility Support in IPv6”（ＩＥＴＦのウエブサイト上でhttp://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txtに書き込むときに得られる）に記載されており、draft-ietf-mobileip-ipv6-19.txtとして参照される。

ルーティングの最適化を行うＭＩＰローミングに関係するシナリオは、図１に示されている。ＭＮは、そのホームネットワーク（Home Network, HN）のホームＩＰアドレス（home IP address, HAddr）を割り当てられる。ＨＮにおけるルーティング手続きは、ＭＮがＨＮ内のどこにいても、ＩＰネットワーク上の通信関係のノード（Correspondent Node, CN）から送られたＩＰパケットが、ＭＮに届くことを保証する。ＭＮは、外部ネットワーク（foreign network, FN）にロームすると、ＩＰパケットがルーティングされなければならないＦＮ内の気付アドレス（Care of Address, CoA）を割り当てられる。しかしながら、ＭＮの移動は、セッション中に、ＩＰレイヤおよび上位レイヤ（例えば、トランスポートレイヤおよびアプリケーションレイヤ）にトランスペアレントでなければならず、ＣＮのＩＰレイヤによって生成されるパケットは、宛先アドレスとして、ＨＡｄｄｒを保持し続ける。

ＭＩＰｖ６のルーティング最適化プロトコルのもとでは、ＭＮは、ＦＮへロームすると、ＣＮへ結合更新を送り、ＣＮにＣｏＡを知らせる。次に、ＣＮのＭＩＰレイヤは、セッション内の後のパケットの宛先アドレスをＣｏＡに設定し、ＭＮのＨＡｄｄｒをパケットの拡張ヘッダとして、ルーティングヘッダタイプ２に置く。ＨＡｄｄｒは、ＭＮのＭＩＰレイヤにおいて、ルーティングヘッダタイプ２のフィールドから検索され、ＭＮのＩＰレイヤへ送られる、対応するパケットの宛先アドレスとして使用される。

このシナリオでは、ＣＮは、ＧＰＲＳネットワーク（GPRS network, GN）内に位置し、ＧＮは、汎用パケット無線サービスゲートウエイ支援ノード（ＧＧＳＮ）を介してＩＰネットワークにインターフェイスする。機能は、文献3GPP TS 23.207 V5.3.0（2002年3月）の5.2.3節に定められている。ＧＧＳＮは、サービスに基づくローカルポリシー（ＳＢＬＰ）の実施点を含み、これは、ＧＧＳＮを通るパケットに、ポリシーに基づく入場制御を適用する。個々のセッションにおけるポリシーの実施は、‘ゲート’によって定められ、ゲートは、アップストリームおよびダウンストリームのトラヒックに対して別々に定められている。各ゲートは、パケット分類器を含み、パケット分類器に整合するパケットを通す。パケット分類器は、ソースＩＰアドレス、宛先ＩＰアドレス、ソースポート、宛先ポート、およびプロトコルを含む。パケット分類器のソースおよび宛先ＩＰアドレスは、アドレスの範囲を定めるために、ワイルドカードを含んでもよい。対応するゲートのパケット分類器に整合しないパケットはブロックされる。

ＧＧＳＮを通るＩＰセッションを設定するために、ＣＮは、ＧＧＳＮに、ソースＩＰアドレス、宛先ＩＰアドレス（すなわち、ＨＡｄｄｒ）、ソースポート、宛先ポート、およびプロトコルを特定する認証要求を送る。文献3GPP TS 23.207 V5.3.0（2002年3月）の5.2.3節に定められているＧＧＳＮ内のＳＢＬＰ決定点（ローカル決定点）、またはＧＧＳＮの外部のポリシー制御機能（Policy Control Function, PCF）が、ＩＰセッションを認証するかどうかを判断する。セッションが認証されると、ＳＢＬＰ実施点においてセッションの各指示ごとに、ゲートが設定され、認証トークンがＣＮへ送られる。認証トークンは、媒体認証のためのＳＩＰ拡張におけるＩＥＴＦの仕様にしたがう。

アップリンクのＳＢＬＰは、ＣＮ（または、ＧＮ内の他のノード）が、指定された宛先ＩＰアドレスへアクセスするのを妨げるのに使用される。したがって、要求された宛先ＩＰアドレスが、ＳＢＬＰのもとで承認されるときのみ、ゲートが認証される。しかしながら、ＧＧＳＮによって認識された宛先アドレスは、セッション中にＨＡｄｄｒからＣｏＡに変わるので、このようなゲートは、上述のＭＩＰｖ６のルーティング最適化プロトコルの妨げになる。ＣｏＡにアドレス指定されたパケットは、セッションに対応するアップリンクゲートのパケット分類器に整合せず、ブロックされることがある。

ルート最適化は、ＭＩＰｖ６において必須であるが、ＭＩＰｖ４においてはオプションである。最適ルートではない、別のルートは、図２に示されている。ＣＮとＨＮ内のＭＮとの間に、ＩＰセッションが設定される。ＭＮは、セッション中にＦＮへロームし、結合更新を送り、ＨＮ内のホームエージェント（Home Agent, HA）に、ＦＮ内のＣｏＡを知らせる。この例において、ＦＮは、ＧＧＳＮを介してＩＰＮへ接続されるＧＰＲＳネットワークである。

結合更新に応答して、ＨＡは、宛先アドレスとしてＨＡｄｄｒをもつ後のパケットをインターセプトし、それらを、ソースアドレスとして設定されたＨＡのＩＰアドレスと、宛先アドレスとして設定されたＭＮのＣｏＡとを含むパケット内にカプセル化することによって、ＣｏＡへのＩＰトンネルを設定する。ＭＮのＭＩＰレイヤは、パケットを逆カプセル化し、それらをＩＰレイヤへ送り、ローミングをＩＰレイヤおよび上位レイヤにトランスペアレントにする。このトンネリングは、IETF RFC 2473に記載されているＩＰｖ６汎用パケットトンネリング機構（IPv6 General Packet Tunneling Mechanism）を使用して、実現することができる。

ＣＮのＩＰアドレスは変わっていないので、アップリンク方向において、ＭＮは、ＦＮへローミングした後に、そのパケットのソースおよび宛先アドレスを変更する必要はない。しかしながら、ＧＧＳＮは、退出パケットに送出フィルタを適用し、ＦＮ内に無いソースアドレスをもつパケットをブロックする。これは、ＳＢＬＰゲートがパケット分類器のソースアドレスをＧＧＳＮ内のＩＰアドレスに整合するように設定することによって、実行される。その結果、ソースアドレスとしてＨＡｄｄｒをもつ、ＭＮからのパケットは、ブロックされる。

この問題に対処するために、ＭＩＰｖ４およびＭＩＰｖ６の標準規格は、ＭＮがＣｏＡとＨＡアドレスとの間のアップリンク方向のトンネルを設定するといった、逆方向トンネリングプロトコルを含む。アップリンクのパケットは、ソースアドレスとしてＦＮ内のＣｏＡを保持しているパケット内にカプセル化されているので、送出フィルタは、カプセル化されたパケットを通すことを許可する。ＨＡは、パケットを逆カプセル化して、それらをＣＮへ転送する。ＭＩＰｖ６の逆方向トンネリングは、例えば、2002年10月29日に発行されたＩＥＴＦのモバイルＩＰ審議会の草案（IETF Mobile IP Working Group Draft）（‘Mobility Support in IPv6’）に記載されており、これは、http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txtに書き込むときに検索される。

しかしながら、この解決案では、ＦＮ内のＧＧＳＮが、アップリンクのパケットに対してＳＢＬＰゲートを実行したときに問題が発生する。ＭＮは、ＦＮに入ると、ＣＮとのＩＰセッションがＧＧＳＮをルーティングするのを許可する認証要求を、ＧＧＳＮへ送らなければならない。セッションがＧＧＳＮのローカルネットワークの外部で始まったときでも、認証プロトコルは、セッション中に認証を許可するので、これ自体は問題ではない。しかしながら、アプリケーションレイヤ（例えば、ＳＩＰセッションレイヤ）から発信された認証要求が、ＨＡアドレスを宛先アドレスとして特定すると、（例えば、ＣｏＡを使用する）ＭＮの移動管理は、アプリケーションレイヤにトランスペアレントであるので、ＨＡアドレスは、終端の宛先アドレスを識別しない。ＳＢＬＰの実施点は、退出パケットの最終宛先を制御しないので、ＨＡアドレスに基づいてアップリンクのＳＢＬＰゲートを認証することは、ＳＢＬＰゲートの目的を無効にする。さらに加えて、ＧＧＳＮは、カプセル化されたパケットのペイロードを調べて、最終の宛先アドレスを見付けることは許されておらず、ペイロードが、例えば、ＩＰＳｅｃを使用して、暗号化されていても、そうすることはできない。

本発明の１つの態様にしたがって、宛先アドレスと拡張ヘッダとを含むヘッダをもつデータパケットを、ネットワークゲートウエイにおいてフィルタにかける方法であって、宛先アドレスも、拡張ヘッダも、所定のアドレス基準に整合しないデータパケットを選択的にブロックすることを含む方法を与える。

本発明の別の態様にしたがって、宛先アドレスを含むヘッダをもつデータパケットを、ネットワークゲートウエイにおいてフィルタにかける方法であって、宛先アドレスが宛先アドレスの基準も、転送エージェントの基準も満たしていないデータパケットを選択的にブロックすることを含み、転送エージェントの基準が、少なくとも１つの転送エージェントのアドレスを定め、転送エージェントが、転送エージェントにアドレス指定されたパケットを、パケットのペイロードにおいて特定されているネットワークアドレスの宛先ノードへ転送する方法。

ここで、本発明の特定の実施形態を、図面を参照して記載する。
本発明の第１の実施形態は、図１を参照して既に記載したように、ＭＩＰｖ６のルート最適化が、サブネットワークのローミングに使用されるときに、ＳＢＬＰに基づくゲーティング機能の適用の問題に第１の解決案を与える。ＭＩＰｖ６のルート最適化では、ＨＡｄｄｒは、ルーティングヘッダタイプ２の拡張ヘッダ（Routing Header Type 2 extension header, T2H）に記憶され、したがって、ＭＮのＭＩＰレイヤによって検索され、ＩＰレイヤへ送られるパケット内に宛先アドレスとして再記憶される。

図３ａに示されているように、ＩＰセッション中に、ＭＮがＦＮへロームする前に、ＣＮからＭＮへ送られるパケットは、宛先ＩＰアドレス（destination IP address, DA）として、ＨＡｄｄｒをもつ。ＭＮは、ＦＮへロームすると、ＣｏＡを含む結合更新（binding update, BU）を、ＣＮへ送る。ＭＩＰｖ６のルーティング最適化プロトコルにしたがって、ＣＮは、ＢＵに応答して、ＣｏＡにアドレス指定された後のパケットを、Ｔ２Ｈ内にＨＡｄｄｒを置いて送る。

本発明の発明者は、ＧＧＳＮがルーティングヘッダタイプ２の拡張ヘッダを調べて、パケットの終端の宛先アドレスを識別できることを認識した。従来のパケット分類器は、ルーティングヘッダタイプ２の拡張ヘッダのＩＰアドレスを含まない。しかしながら、ＳＢＬＰプロトコルは、ＧＧＳＮにとってローカルであるので、他のネットワークとの相互運用性の問題を発生することなく、ＳＢＬＰの実施を変更できる。

第１の実施形態では、図３ｂに示されているように、従来のパケット分類器は、退出ＳＢＬＰゲートのために生成され、パケット分類器の宛先アドレス（packet classifier destination address, PCD）を含んでいる。ＳＢＬＰの実施点では、パケット分類器の宛先アドレス（ＰＣＤ）をパケットの宛先アドレス（packet destination address, PD）と比較し（ステップ30）、ルーティングヘッダタイプ２の拡張ヘッダと比較する（ステップ32）ことによって、ゲートを実行する。何れも整合しないときは、パケットはブロックされ（ステップ34）、さもなければ、パケットは通過することを許可され（ステップ36）、他のゲート条件を適用される。

第１の実施形態の解決案は、ＳＢＬＰの実施点のみの変更を要求し、ＭＮまたはＣＮの機能の変更、あるいは遠隔のエージェントのような新しい目標の生成を要求しないので、効果的である。宛先ＩＰアドレスの代わりとして整合するルーティングヘッダタイプ２の拡張ヘッダを特定する拡張パケット分類器を定めることによって、同様の効果を実現することができるが、ルーティングヘッダタイプ２の拡張ヘッダは、パケット分類器内のＨＡｄｄｒと同じであると考えられるので、冗長する。ＧＧＳＮ内の目標間で機能を異なるように分配することによって、この効果を実現することができる。

ルーティングヘッダタイプ２の拡張ヘッダを調べる解決案は、ＭＩＰｖ６によって禁止されていないが、ルーティングヘッダタイプ２の拡張ヘッダの意図された目的を侵害し、元の宛先アドレスを宛先のユーザ装置にローカルに再記憶すると考えられる。このような侵害を防ぐために、技術的手段が実行されると、第１の実施形態の解決案を失敗させることになる。

第２の実施形態では、図４ａに示されているように、終端の宛先アドレス（ＨＡｄｄｒ）は、退出パケットのホップごとのオプションの拡張ヘッダＨＨ内に記憶される。ＩＰｖ４およびＩＰｖ６の両者は、ホップごとのオプションの拡張ヘッダを可能にしており、これは、中間ノードによって読み出さなければならない。ＩＰｖ６のホップごとのオプションの拡張ヘッダの存在は、ＩＰｖ６の次のヘッダフィールド内にゼロを置くことによって示される。

ＭＮがＣＮへＢＵを送ることに応答して、ＣＮは、後のパケットのＨＨ内にＨＡｄｄｒを記憶する。この動作は、タイプ２のヘッダ内にＨＡｄｄｒを記憶し、宛先ＩＰアドレスフィールド内にＣｏＡを記憶することに加えて、行われる。
図４ｂに示されているように、ＳＢＬＰの実施点では、パケット分類器の宛先アドレス（ＰＣＤ）をパケット宛先アドレス（ＰＤ）と比較し（ステップ40）、さらに、ＨＨ内のＩＰアドレスと比較する（ステップ42）。何れも整合しないときは、パケットはブロックされる（ステップ44）。さもなければ、パケットは通過することを許可され（ステップ46）、他の制約を適用される。

第２の実施形態は、ＧＧＳＮが、検査することを許可されたフィールドのみを検査する点で、第１の実施形態よりも優れており、したがって、第２の実施形態の解決案を失敗させることになる技術的手段は採用されないと考えられる。しかしながら、第２の実施形態では、第１の実施形態とは異なり、既存のＭＩＰｖ６のインターネットの草案の仕様にしたがうＭＮの機能の変更が必要である。

第３の実施形態は、図２を参照して既に記載したように、逆方向トンネル上でＳＢＬＰの退出ゲートを適用することの問題に対する第１の解決案を与える。逆方向トンネルは、ペイロード内のＣＮアドレスを、暗号化するなどして、隠す。その代りに、第３の実施形態は、第２の実施形態の解決案と同様の解決案を採用する。

図５ａに示されているように、ＩＰセッション中に、ＭＮは、最初に、ＨＡｄｄｒに設定されたパケットソースアドレス（packet source address, PS）と、ＣＮアドレス（CN address, CNAddr）に設定されたＰＤとを含むパケットを、ＣＮへ送る。ＭＮは、ＦＮへロームすると、ＢＵを、そのＨＡへ送り、ＣｏＡと、ＨＡアドレス（HA address, HAAddr）のＨＡとの間に逆方向ＩＰトンネルを設定する。

この実施形態では、ＭＮは、逆方向トンネリングパケットのＨＨ内にＣＮＡｄｄｒ（または、ＣＮ自体が、移動体であり、移動のためにモバイルＩＰｖ６を使用して、そのホームネットワークから離れている場合は、ＣＮのホームアドレス）を含む。図５ｂに示されているように、ＳＢＬＰの実施点は、パケット分類器の宛先アドレス（ＰＣＤ）をパケットの宛先ＩＰアドレス（ＰＤ）と比較し（ステップ50）、さらに、ＨＨ内のＩＰアドレスと比較する（ステップ52）。何れも整合しないときは、パケットはブロックされる（ステップ54）。さもなければ、パケットは、通過することを許可され（ステップ56）、他の制約を適用される。

第３の実施形態は、逆方向トンネリングに既に要求されている機能に対する追加の機能をＣＮにおいて要求する。第４の実施形態は、このような追加の機能を要求せず、逆方向トンネリング上でＳＢＬＰの退出ゲートを適用することの問題に対する第２の解決案を与える。

第４の実施形態では、ＨＡのＩＰアドレスを含む拡張パケット分類器のＰＣＨＡが定められる。図６に示されているように、ＳＢＬＰの実施点では、パケット宛先アドレス（ＰＤ）をパケット分類器宛先アドレス（ＰＣＤ）と比較し（ステップ60）、パケット分類器のＨＡアドレス（packet classifier HA address, PCHA）と比較する（ステップ62）。何れも整合しないときは、パケットはブロックされる（ステップ64）。さもなければ、パケットは、通過することを許可され（ステップ66）、他の制約を適用される。

既に記載したように、ＧＧＳＮとＨＡとの間に信頼または制御関係が存在していないならば、ＳＢＬＰの効果はなくなる。
制御関係の例として、ＦＮのＧＧＳＮとＨＮのＨＡとは、共通のＳＢＬＰの決定点にアクセスし、共通のＳＢＬＰの決定点は、共通のポリシーに基づいて、ＦＮおよびＨＮにおけるＳＢＬＰの実施点に対して認証を発行する。その代りに、ＦＮとＨＮとの間の認証トラヒックを低減するために、例えば、ブロックされたＩＰアドレスのリストを共用することによって、ＦＮとＨＮとの間でＳＢＬＰの決定点が再現される。

信頼関係の例では、ＧＧＳＮのＳＢＬＰの決定点は、信頼するＨＡのＩＰアドレスのリストを記憶し、リスト上にあるＨＡアドレスを含んでいるパケット分類器を使用して、ゲートを認証する。ＧＧＳＮは、ＨＡのＳＢＬＰを制御しないが、自分自身のＳＢＬＰにしたがうＳＢＬＰを維持していると信じている。

上述の実施形態は、ＧＰＲＳネットワークにおけるＳＢＬＰに関して記載されているが、宛先アドレスに基づくパケットフィルタは、他の文脈でも、例えば、ローカルＩＰネットワーク（無線ネットワークでなくてもよい）におけるファイアウオールとして、必要とされることが分かるであろう。図１のシナリオにおいて、ＣＮは、ローカルＩＰネットワーク内のノードであってもよい。ＭＩＰｖ６のルート最適化以外の文脈において、宛先アドレスの明らかな変更が現れることがある。例えば、ＩＰ転送構成では、セッションを別の物理装置へ転送するのに、送信側ノードによって設定された宛先アドレスをセッション中に変更しなければならない。第１および第２の実施形態の変形は、これらの別の文脈に適用できる。

同様に、逆方向トンネリング構成は、モバイルＩＰにおけるローミング以外の文脈に現われることがあり、第３および第４の実施形態の変更は、これらの別の文脈に適用できる。
上述の実施形態は、送信側ノードにとってローカルであるネットワークのゲートウエイにおいて、退出パケットに、宛先に基づくフィルタを適用することについて開示しているが、送信側ノードへの遠隔ネットワークのゲートウエイにおいて、到来パケットに、宛先に基づくフィルタを適用してもよい。第２および第３の実施形態では、これは、ローカルネットワークと遠隔ネットワークとの標準化を要求し、送信側ノードがＨＨ内に宛先アドレスを置くことを保証する。

第１ないし第３の実施形態では、ＳＢＬＰの実施点がパケット宛先アドレスと拡張ヘッダとの両者を常に検査することは必須ではなが、その代りに、ゲートが、最初に、パケットの宛先アドレスのみを検査し、ローミングイベントに応答して、拡張ヘッダのみを検査するように変更してもよい。

上述の実施形態は、例示的に与えられており、その変更または変形も本発明の技術的範囲に含まれる。

宛先ノードがルート最適化を使用してローミングしているときに、ＧＧＳＮにおいて退出ＳＢＬＰを適用することを試みることによって発生する問題を示す図。 退出ＳＢＬＰを逆方向トンネルに適用するのを試みることによって発生する問題を示す概念図。 図１のシナリオにおけるルート最適化を示す信号図。 本発明の第１の実施形態における、退出ＳＢＬＰゲートを適用するＳＢＬＰ実施点の動作のフローチャート。 図１に示されている問題を解決するための、本発明の第２の実施形態を示す信号図。 第２の実施形態において、退出ＳＢＬＰゲートを適用するＳＢＬＰ実施点の動作のフローチャート。 図２に示されている問題を解決するための、本発明の第３の実施形態を示す信号図。 第３の実施形態において、退出ＳＢＬＰゲートを適用するＳＢＬＰ実施点の動作のフローチャート。 本発明の第４の実施形態において、退出ＳＢＬＰゲートを適用するＳＢＬＰ実施点の動作のフローチャート。

Claims (22)

1. 宛先アドレスと拡張ヘッダとを含むヘッダをもつデータパケットをネットワークゲートウエイにおいてフィルタにかける方法であって、宛先アドレスも、拡張ヘッダも、所定のアドレス基準に整合しないデータパケットを選択的にブロックすることを含む方法。
2. 対応するパケットデータの通信セッション中に、ソースノードから宛先ノードへ伝送されるパケットのみに、アドレス基準を適用する請求項１記載の方法。
3. 宛先ノードが、パケットデータ通信セッションの第１の期間中には第１のネットワークアドレスをもち、データ通信セッションの第２の次の期間中には第２の異なるネットワークアドレスをもち、ソースノードが、第１の期間中には、宛先アドレスとして第１のネットワークアドレスをもつパケットを伝送し、第２の期間中には、宛先アドレスとして第２のネットワークアドレスをもち、拡張ヘッダ内に第１のネットワークアドレスをもつパケットを伝送する請求項２記載の方法。
4. 宛先ノードが、第２の期間中に受信したパケットを、パケットのペイロードを復号する前に、第２のネットワークアドレスを第１のネットワークアドレスと置換することによって変換する請求項３記載の方法。
5. 拡張ヘッダが、ルーティングヘッダタイプ２の拡張ヘッダである請求項４記載の方法。
6. 宛先ノードが、第１の期間と第２の期間との間で、第１のネットワークアドレスを含む第１のネットワークから、第２のネットワークアドレスを含む第２のネットワークへロームする請求項３ないし５の何れか１項記載の方法。
7. ソースノードが、パケットデータ通信セッションの第１の期間中には、第１のネットワークアドレスをもち、データ通信セッションの第２の次の期間中には、第２の異なるネットワークアドレスをもち、パケットがソースアドレスを含み、ソースノードが、第１の期間中には、ソースアドレスとして第１のネットワークアドレス、および宛先アドレスとして宛先ノードのアドレスをもつパケットを伝送し、第２の期間中には、ソースアドレスとして第２のネットワークアドレス、拡張ヘッダ内の宛先ノードのアドレス、および宛先アドレスとしてパケットを宛先ノードへ転送する転送エージェントのアドレスをもつパケットを伝送する請求項２記載の方法。
8. 第２期間中に第２のソースノードによって伝送されるパケットのペイロードが、宛先ノードのアドレスを含む請求項７記載の方法。
9. ソースノードが、第１の期間と第２の期間との間に、第１のネットワークアドレスを含む第１のネットワークから、第２のネットワークアドレスを含む第２のネットワークへロームする請求項７または８記載の方法。
10. パケットがソースノードと宛先ノードとの間でルーティングする１つ以上の中間ノードが、拡張ヘッダ内の情報を読み出す請求項３、４、または８の何れか１項記載の方法。
11. 拡張ヘッダが、ホップごとのオプションの拡張ヘッダである請求項１０記載の方法。
12. 宛先アドレスを含むヘッダをもつデータパケットをネットワークゲートウエイにおいてフィルタにかける方法であって、宛先アドレスが宛先アドレスの基準も、転送エージェントの基準も満たしていないデータパケットを選択的にブロックすることを含み、転送エージェントの基準が、少なくとも１つの転送エージェントのアドレスを定め、転送エージェントが、転送エージェントにアドレス指定されたパケットを、パケットのペイロードにおいて特定されているネットワークアドレスの宛先ノードへ転送する方法。
13. 少なくとも１つの転送エージェントが、宛先アドレスの基準を満たしていないネットワークアドレスをもつパケットをブロックする請求項１２記載の方法。
14. 転送エージェントの基準が、少なくとも１つの転送エージェントのアドレスを含むか、または除外するように可変である請求項１２記載の方法。
15. パケットデータネットワークのソースノードにおいてデータパケットを伝送する方法であって、データパケットの宛先アドレスに基づいて通信セッションのデータパケットにフィルタをかけるネットワークゲートウエイを介して、第１のネットワークアドレスの宛先ノードとのパケットデータ通信セッションを設定することと、セッション中に宛先ノードの第２のネットワークアドレスの指示を受信することと、第２のネットワークアドレスにアドレス指定された、セッション内の後のパケットを伝送することと、ソースノードと宛先ノードとの間の中間ノードによって読み出される情報を含む拡張ヘッダ内に第１のネットワークアドレスを含むこととを含む方法。
16. ソースノードと宛先ノードとの間のパケットデータセッションに、ネットワークゲートウエイにおいて、宛先アドレスに基づくフィルタを適用する方法であって、宛先ノードが、ホームネットワーク内のホームアドレスから、外部ネットワーク内の気付アドレスへロームし、結合更新をソースノードへ送り、ソースノードが、セッション内の後のパケットを気付アドレスへアドレス指定し、後のパケットの拡張ヘッダ内にホームアドレスを置き、宛先アドレスに基づくパケットフィルタを、後のパケットの拡張ヘッダに適用することを含む方法。
17. 宛先ノードが、拡張ヘッダを使用して、ホームアドレスを後のパケットの宛先アドレスとして再記憶する請求項１６記載の方法。
18. 拡張ヘッダが、ソースノードと宛先ノードとの間の中間ノードによって読み出される請求項１６記載の方法。
19. ソースノードと宛先ノードとの間のパケットデータセッションに、ネットワークゲートウエイにおいて、宛先アドレスに基づくパケットフィルタを適用する方法であって、ソースノードが、ホームネットワーク内のホームアドレスから、前記ネットワークゲートウエイをもつ外部ネットワーク内の気付アドレスへロームし、パケットを宛先ノードへ転送するために、ホームネットワーク内のホームエージェントへの逆方向トンネルを設定し、ソースノードが、外部ネットワークから送られたパケットの拡張ヘッダ内に宛先ノードのアドレスを置き、ネットワークゲートウエイが宛先アドレスフィルタをパケットの拡張ヘッダに適用する方法。
20. 請求項１ないし１９の何れか１項記載の方法を実行するように構成されたコンピュータプログラム。
21. 請求項１ないし１９の何れか１項記載の方法を実行するように構成された装置。
22. 添付の図面を参照して、ここに実質的に記載された方法。

Images