(57)【要約】      （修正有）【課題】ＩＰパケットを処理するためのアーキテクチャーを提供する。【解決手段】ＩＰパケットを処理する方法及び装置が開示される。方法は、テンプレートと呼ばれるパケットフィールドの組を規定するステップ（ステップ１１０１及び１１０２）と、テンプレートをメモリに格納するステップと、現在のＩＰパケットが処理対象であるか否かを判定するステップ（ステップ１１０４）と、現在のＩＰパケットに適用すべき処理を特定するステップ（ステップ１１０４）と、特定された処理の属性に応じて、格納されたテンプレートのうちの少なくとも１つを選択するステップと、テンプレートを使用して現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するステップ（ステップ１１０７）とを有する。【選択図】図７
2005287034.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰパケットを処理する方法であって、
パケットフィールドの複数の組を規定するステップと、
規定されたパケットフィールドの組を記憶装置に格納するステップと、
現在のＩＰパケットが処理対象であるか否かを判定するステップと、
前記現在のＩＰパケットに適用されるべき処理を特定するステップと、
前記特定された処理の属性に応じて、前記格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択するステップと、
前記選択されたパケットフィールドの組のうちの少なくとも１つを使用して、前記現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するステップとを有することを特徴とする方法。
【請求項２】
前記規定されたパケットフィールドの各組は、拡張ヘッダを有することを特徴とする請求項１記載の方法。
【請求項３】
前記規定されたパケットフィールドの各組は、前記拡張ヘッダと関連付けられた少なくとも１つの予測拡張ヘッダを更に有することを特徴とする請求項２記載の方法。
【請求項４】
前記予測拡張ヘッダは、
前記拡張ヘッダの予測可能フィールドを修正して、初期予測拡張ヘッダを形成するステップと、
前記初期予測拡張ヘッダの予測不可能なフィールドを変更して、前記予測拡張ヘッダを形成するステップにより形成されることを特徴とする請求項３記載の方法。
【請求項５】
前記判定するステップ及び前記特定するステップは、前記ＩＰパケットに対するセキュリティポリシーを参照して実行され、
さらに、前記現在のＩＰパケットに対するセキュリティアソシエーションを作成するステップを含み、前記選択するステップ及び前記操作するステップは、前記セキュリティアソシエーションに依存することを特徴とする請求項１記載の方法。
【請求項６】
前記現在のＩＰパケットが認証される場合、前記操作するステップが、
前記格納された拡張ヘッダのコピーを取得するステップと、
前記格納された拡張ヘッダのコピーを前記現在のＩＰパケットに組み込んで、中間ＩＰパケットを形成するステップと、
前記中間ＩＰパケットの認証フィールドを判定するステップと、
前記認証フィールドを前記中間ＩＰパケットに組み込み、前記処理済みＩＰパケットを形成するステップとを有することを特徴とする請求項２記載の方法。
【請求項７】
前記現在のＩＰパケットに対してトンネリング及び認証が施される場合、前記操作ステップが、
前記格納された拡張ヘッダのコピー及び前記格納された予測拡張ヘッダのコピーを取得するステップと、
前記格納された予測拡張ヘッダのコピーを使用して、中間ＩＰパケットを形成するステップと、
前記中間ＩＰパケットの認証フィールドを判定するステップと、
前記認証フィールド及び前記格納された拡張ヘッダのコピーを、前記現在のＩＰパケットに組み込んで、前記処理済みＩＰパケットを形成するステップとを有することを特徴とする請求項３記載の方法。
【請求項８】
ＩＰパケットを処理する装置であって、
パケットフィールドの複数の組を規定する手段と、
前記規定されたパケットフィールドの組を記憶装置に格納する手段と、
現在のＩＰパケットが処理対象であるか否かを判定する手段と、
前記現在のＩＰパケットに適用されるべき処理を特定する手段と、
前記特定された処理の属性に応じて、前記格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択する手段と、
前記選択されたパケットフィールドの組のうちの少なくとも１つを使用して、前記現在のＩＰパケットを操作し、処理済みＩＰパケットを形成する手段とを有することを特徴とする装置。
【請求項９】
前記規定されたパケットフィールドの各組は、拡張ヘッダと、前記拡張ヘッダと関連付けられた少なくとも１つの予測拡張ヘッダを有し、
前記拡張ヘッダの予測可能フィールドを修正して、初期予測拡張ヘッダを形成する手段と、
前記初期予測拡張ヘッダの予測不可能なフィールドを変更して、前記予測拡張ヘッダを形成する手段とを更に有することを特徴とする請求項８記載の装置。
【請求項１０】
（ａ）前記現在のＩＰパケットが認証される場合、前記操作する手段は、
前記格納された拡張ヘッダのコピーを取得する手段と、
前記格納された拡張ヘッダのコピーを、前記現在のＩＰパケットに組み込んで、中間ＩＰパケットを形成する手段と、
前記中間ＩＰパケットの認証フィールドを判定する手段と、
前記認証フィールドを前記中間ＩＰパケットに組み込み、前記処理済みＩＰパケットを形成する手段とを有し、
（ｂ）前記現在のＩＰパケットに対してトンネリング及び認証が施される場合、前記操作する手段は、
前記格納された拡張ヘッダのコピー及び前記格納された予測拡張ヘッダのコピーを取得する手段と、
前記格納された予測拡張ヘッダのコピーを使用して、中間ＩＰパケットを形成する手段と、
前記中間ＩＰパケットの認証フィールドを判定する手段と、
前記認証フィールド及び前記格納された拡張ヘッダの前記コピーを前記現在のＩＰパケットに組み込んで、前記処理済みＩＰパケットを形成する手段とを有する手段を更に有することを特徴とする請求項９記載の装置。
【請求項１１】
プロセッサにＩＰパケットの処理を指示するためのコンピュータプログラムが記録されたコンピュータ可読媒体を有する、コンピュータプログラムプロダクトであって、前記コンピュータプログラムが、
パケットフィールドの複数の組を規定するコードと、
前記規定されたパケットフィールドの組を記憶装置に格納するコードと、
現在のＩＰパケットが処理対象であるか否かを判定するコードと、
前記現在のＩＰパケットに適用されるべき処理を特定するコードと、
前記特定された処理の属性に応じて、前記格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択するコードと、
前記選択されたパケットフィールドの組のうちの少なくとも１つを使用して、前記現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するコードとを有することを特徴とするコンピュータプログラムプロダクト。
【請求項１２】
前記規定されたパケットフィールドの各組は、拡張ヘッダと、前記拡張ヘッダと関連付けられた少なくとも１つの予測拡張ヘッダとを有し、前記コンピュータプログラムは、
前記拡張ヘッダの予測可能フィールドを修正して、初期予測拡張ヘッダを形成するコードと、
前記初期予測拡張ヘッダの予測不可能なフィールドを変更して、前記予測拡張ヘッダを形成するコードとを更に有することを特徴とする請求項１１記載のコンピュータプログラムプロダクト。
【請求項１３】
さらに、
（ａ）前記現在のＩＰパケットが認証される場合、前記操作するコードは、
前記格納された拡張ヘッダのコピーを取得するコードと、
前記格納された拡張ヘッダのコピーを、前記現在のＩＰパケットに組み込んで、中間ＩＰパケットを形成するコードと、
前記中間ＩＰパケットの認証フィールドを判定するコードと、
前記認証フィールドを前記中間ＩＰパケットに組み込み、前記処理済みＩＰパケットを形成するコードとを有し、
（ｂ）前記現在のＩＰパケットに対してトンネリング及び認証が施される場合、前記操作するコードは、
前記格納された拡張ヘッダのコピー及び前記格納された予測拡張ヘッダのコピーを取得するコードと、
前記格納された予測拡張ヘッダのコピーを使用して、中間ＩＰパケットを形成するコードと、
前記中間ＩＰパケットの認証フィールドを判定するコードと、
前記認証フィールド及び前記格納された拡張ヘッダのコピーを前記現在のＩＰパケットに組み込んで、前記処理済みＩＰパケットを形成するコードとを有することを特徴とする請求項１２記載のコンピュータプログラムプロダクト。
【請求項１４】
プロセッサにＩＰパケットの処理を指示するためのコンピュータプログラムであって、
パケットフィールドの複数の組を規定するコードと、
前記規定されたパケットフィールドの組を記憶装置に格納するコードと、
現在のＩＰパケットが処理対象であるか否かを判定するコードと、
前記現在のＩＰパケットに適用されるべき前記処理を特定するコードと、
前記特定された処理の属性に応じて、前記格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択するコードと、
前記選択されたパケットフィールドの組のうちの少なくとも１つを使用して、前記現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するコードとを有することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワークに関し、特に、インターネットプロトコル（ＩＰ）パケットを処理するためのアーキテクチャに関する。
【背景技術】
【０００２】
ＩＰは、ネットワークを介したデータ交換のために、コンピュータシステムにより使用される代表的なデータ標準である。ＩＰ標準により、データはパケット中で送信元コンピュータシステムから宛先コンピュータシステムへ転送される。データは、２つのコンピュータの間で直接転送されることも可能であるし、宛先コンピュータシステムに到着する前に、他のコンピュータシステムを経由して間接的に転送されることも可能である。ＩＰバージョン４（ＩＰｖ４）及びＩＰバージョン６（ＩＰｖ６）は、ＩＰ通信標準の２つのよく知られたバージョンである。ＩＰｖ４及びＩＰｖ６は、その用語及び実装において異なるが、多くの等価な機能を共有する。本明細書において開示されるＩＰトンネリング技術は、ＩＰｖ４及びＩＰｖ６に適用されるため、ＩＰｖ４標準及びＩＰｖ６標準の両方の用語が、適宜使用される。インターネットプロトコルセキュリティ標準（ＩＰｓｅｃ）は、暗号処理を使用してＩＰデータに対する認証機能及び機密保持機能を取り扱うＩＰ標準である。ＩＰパケット用の処理システムは、ＩＰｓｅｃ処理だけでなく、パケットカプセル化（すなわち、パケットトンネリング）をサポートすることが好ましい。
【０００３】
ＩＰパケットは、ヘッダとそれに続くペイロードとを含む。ＩＰｖ４では、「オプション("options")」が存在する場合、「オプション」は、ＩＰヘッダの一部として発生する。ＩＰｖ６では、ＩＰヘッダに続いてＩＰ拡張ヘッダが存在する可能性がある。本明細書では、ＩＰｖ４のオプションと、ＩＰｖ６のＩＰ拡張ヘッダは、機能的に等価であるとみなすことができる。
【０００４】
いくつかの状況において、ＩＰパケットは、カプセル化ＩＰパケットのペイロードとして輸送されうる。カプセル化パケットを、「トンネルパケット」と呼び、トンネルパケットの送信元と宛先との間の転送経路を、トンネルと呼ぶ。また、パケットをカプセル化し、送信元から宛先へ送信する技術を、トンネリングと呼ぶ。パケットがトンネリングされる（形成される）際、トンネルパケットには、新規のＩＰヘッダ及び新規のＩＰ拡張ヘッダが与えられ、これらはそれぞれ、外側ＩＰヘッダ、外側ＩＰ拡張ヘッダと呼ばれる。また、カプセル化された(元の）パケットのヘッダ及び拡張ヘッダは、内部ＩＰヘッダ及び内部ＩＰ拡張ヘッダと呼ばれる。外側ＩＰヘッダは、内部ＩＰヘッダのいくつかのフィールドをコピーして形成されてもよいが、外側ＩＰ拡張ヘッダの形成は、必ずしも内部ＩＰ拡張ヘッダに直接関連するとは限らない。
【０００５】
通常のＩＰ処理システムは、ソフトウェアで実現される。ＩＰデータの転送速度の上昇に伴い、このソフトウェアによる実現は、いくつかのアプリケーションについては遅すぎる場合がある。ソフトウェアシステムにおいて通常使用される処理方法を、直接ハードウェアに対応付けて実現した場合、得られるハードウェアシステムの速度は、通常、対応するソフトウェアシステムよりもずっと高速である。しかしながら、このようなハードウェアによる実現は、複雑であり、かつ柔軟性に欠けるであろう。
【発明の開示】
【課題を解決するための手段】
【０００６】
本発明の目的は、既存の構成の１つ以上の欠点を実質的に解決するか、少なくとも改善することである。
【０００７】
本発明は、ＩＰパケット処理時に使用可能なパケットフィールドの組（「テンプレート」と呼ぶ）を予め規定する構成を開示する。これを本明細書においては、ＩＰトンネリングアプローチと呼ぶ。このアプローチは、特にパケット処理がトンネリング及び認証を含む場合に有用である。拡張ヘッダ等のこれらの予め規定されたテンプレートは、後でＩＰパケット処理時に使用するために構築及び格納される。テンプレートはカプセル化処理及び／又は認証処理の少なくとも一部を高速で実行するために用いられ、「拡張パケット(augmented packet)」と呼ばれるパケットが形成される。カプセル化処理及び／又は認証処理の残る処理が必要な場合、所望であれば、従来の方法を使用するか、あるいはトンネリングアプローチをさらに適用して、それらの処理を実行できる。
【０００８】
トンネリングアプローチは、以前の技術よりも多くのメモリ資源を要求する反面、ＩＰパケット処理に必要な処理負荷を低減させる。このため、このトンネリングアプローチは、ソフトウェア、ハードウェアのどちらで実現しても、ＩＰ処理速度を増大させる。ＩＰトンネリングアプローチ及び予め規定されたパケットフィールドを使用するＩＰ処理システムにおけるハードウェアの使用率を増加させることにより、処理をより高速化することが可能となる。
【０００９】
本発明の第１の見地によれば、ＩＰパケットを処理する方法であって、
パケットフィールドの複数の組を規定するステップと、
規定されたパケットフィールドの組を記憶装置に格納するステップと、
現在のＩＰパケットが処理対象であるか否かを判定するステップと、
現在のＩＰパケットに適用されるべき処理を特定するステップと、
特定された処理の属性に応じて、格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択するステップと、
選択されたパケットフィールドの組のうちの少なくとも１つを使用して、現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するステップとを有することを特徴とする方法を提供する。
【００１０】
本発明の別の見地によれば、ＩＰパケットを処理する装置であって、
パケットフィールドの複数の組を規定する手段と、
規定されたパケットフィールドの組を記憶装置に格納する手段と、
現在のＩＰパケットが処理対象であるか否かを判定する手段と、
現在のＩＰパケットに適用されるべき処理を特定する手段と、
特定された処理の属性に応じて、格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択する手段と、
選択されたパケットフィールドの組のうちの少なくとも１つを使用して、現在のＩＰパケットを操作し、処理済みＩＰパケットを形成する手段とを有することを特徴とする装置を提供する。
【００１１】
本発明の別の見地によれば、プロセッサにＩＰパケットの処理を指示するためのコンピュータプログラムが記録されたコンピュータ可読媒体を有するコンピュータプログラムプロダクトであって、コンピュータプログラムが、
パケットフィールドの複数の組を規定するコードと、
規定されたパケットフィールドの組を記憶装置に格納するコードと、
現在のＩＰパケットが処理対象であるか否かを判定するコードと、
現在のＩＰパケットに適用されるべき処理を特定するコードと、
特定された処理の属性に応じて、格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択するコードと、
選択されたパケットフィールドの組のうちの少なくとも１つを使用して、現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するコードとを有することを特徴とするコンピュータプログラムプロダクトを提供する。
【００１２】
本発明の別の見地によれば、プロセッサにＩＰパケットの処理を指示するためのコンピュータプログラムであって、
パケットフィールドの複数の組を規定するコードと、
規定されたパケットフィールドの組を記憶装置に格納するコードと、
現在のＩＰパケットが処理対象であるか否かを判定するコードと、
現在のＩＰパケットに適用されるべき処理を特定するコードと、
特定された処理の属性に応じて、格納されている、規定されたパケットフィールドの組のうちの少なくとも１つを選択するコードと、
選択されたパケットフィールドの組のうちの少なくとも１つを使用して、現在のＩＰパケットを操作し、処理済みＩＰパケットを形成するコードとを有することを特徴とするコンピュータプログラムを提供する。
【００１３】
本発明の他の見地もまた開示される。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の１つ以上の実施の形態を、図面と関連して説明する。本発明は、１つ以上の添付の図面のステップ及び／又は機能と関連させて説明される。１つ以上の添付の図面において、同一符号で示すステップ及び／又は機能は、反対の意図が示されない限り、同一の１つ以上の機能又は動作を表す。
【００１５】
尚、「背景技術」での記載及び従来技術の構成に関する以上の記載は、それぞれ刊行物及び／又は実施を通して公知技術を形成する処理又は装置の記載に関するものであることに留意されたい。当該記載は、これらの方法や装置が多少なりとも当該技術分野における周知技術の一部を形成するものとして本発明者又は出願人が説明したものと解釈するべきではない。
【００１６】
図１は、開示されたＩＰトンネリングアプローチが実現可能なシステムのブロック図である。送信元コンピュータ８０１は、矢印８０２で示すように、ＩＰハードウェアモジュール８０３に接続される。図２を参照して説明するように、ＩＰハードウェアモジュール８０３は、ハードウェア要素及びソフトウェア要素の両方を具備する。破線８１１で示すように、ソフトウェア８１０は、コンピュータ８０１上で稼動する。送信元コンピュータ８０１は、矢印８０６で示すように、ネットワーク８０７に接続される。宛先コンピュータ８０９は、矢印８０８で示すように、ネットワーク８０７に接続される。ソフトウェア８１２は、破線８１３で示すように、宛先コンピュータ８０９上で稼動する。
【００１７】
本発明によるトンネリングアプローチは、ネットワーク８０７を介して宛先コンピュータ８０９へＩＰパケットを送信するために、送信元コンピュータ８０１によってソフトウェア８１０及びＩＰハードウェアモジュール８０３とともに用いられ、ソフトウェア８１０により生成されたＩＰパケットを処理する。
【００１８】
図１は、汎用コンピュータ８０１、８０９及び個別ＩＰハードウェアモジュール８０３を示すが、トンネリングアプローチは、組み込み型コンピュータシステムにおいても使用できる。多機能オフィス機器（プリンタ、スキャナ、コピー機及びファックスの能力を統合した装置等）を含むことが可能なシステム（不図示）及びネットワークルータにおいて、ＩＰ及びＩＰｓｅｃの取り扱いが必要な処理は、ソフトウェア(組み込み型プロセッサ及び組み込み型ソフトウェアを使用）内、又はハードウェア内で行われてもよい。このようなシステムにおいて、ＩＰを介して送信されるべきデータは、（ハードウェア）スキャナ等の別の組み込み型コンピュータシステムから入力されてもよい。
【００１９】
図２は、図１の送信元コンピュータ８０１及びＩＰ処理モジュール８０３の機能要素を示す図である。送信元コンピュータのソフトウェア８１０は、矢印２０８で示すように、アプリケーションソフトウェア２０２と対話するドライバソフトウェアモジュール２０１を具備する。ドライバソフトウェアモジュール２０１は、矢印２０６で示すように、ＩＰハードウェアモジュール８０３と対話する。この説明では、図１の送信元コンピュータ８０１とＩＰハードウェアモジュール８０３との間の特定の機能配分を仮定する。しかしながら、この仮定は例証のために過ぎず、他の機能配分も使用できる。ＩＰハードウェアモジュール８０３は、矢印２０７で示すように、ＩＰｓｅｃエンジン２０４と対話するＩＰエンジン２０３を具備する。ＩＰｓｅｃエンジン２０４は、矢印２０９で示すように、拡張ヘッダテンプレートメモリ２０５と対話する。また、コンピュータのソフトウェア８１０は、トンネリングアプリケーションソフトウェアモジュール２１０を有する。トンネリングアプリケーションソフトウェアモジュール２１０は、図４Ａを参照してより詳細に説明する。
【００２０】
アプリケーションソフトウェア２０２は、ネットワーク８０７を介して送信元コンピュータ８０１から宛先コンピュータ８０９へ転送すべきデータの発信元である。アプリケーションソフトウェア２０２は、このデータをドライバソフトウェア２０１へ転送する。ドライバソフトウェア２０１は、ＩＰハードウェアモジュール８０３と通信する。
【００２１】
ＩＰエンジン２０３は、ネットワーク８０７を介して送信するためのデータをパッケージ化するために、アプリケーションソフトウェア２０２により生成されたデータからＩＰパケットを形成する。ネットワーク８０７を介したパケット送信の前に、ＩＰエンジン２０３は、ＩＰｓｅｃ処理のために、各パケットをＩＰｓｅｃエンジン２０４に渡す。ＩＰｓｅｃエンジン２０４は、対象とされている特定のパケットに対するＩＰｓｅｃ処理が必要である場合、どのＩＰｓｅｃ処理が必要であるかを判定する。ＩＰトンネリングが適用され、且つ外側ＩＰ拡張ヘッダが必要である場合、適切な外側ＩＰ拡張ヘッダは、ＩＰ拡張ヘッダテンプレートメモリ２０５から読み出される。尚、ＩＰｖ４が使用される場合、外側ＩＰヘッダに後続して必要な外側ＩＰ拡張ヘッダの代わりに、ＩＰヘッダ内でのオプションが必要となる。しかし、これらは本システム全体から見れば、同等の必要性である。
【００２２】
ＩＰｓｅｃエンジン２０４は、メモリ２０５から読み出されたＩＰ拡張ヘッダのコピーを、ＩＰパケット内に挿入する。ＩＰ拡張ヘッダのコピーのいくつかの部分は、ＩＰパケットに挿入される前に、修正される可能性がある。次に、ＩＰｓｅｃエンジン２０４は、認証ヘッダの生成等により、パケットを処理する。ＩＰｓｅｃエンジン２０４が、パケット処理を終了した後、ネットワーク８０７を介したパケット送信のために、パケットは、ＩＰエンジン２０３に戻される。
【００２３】
ＩＰ拡張ヘッダテンプレートは、ドライバソフトウェア２０１により、例えばアプリケーションソフトウェア２０２及び／又はトンネリングソフトウェアアプリケーション２１０からの情報を使用して、事前にＩＰ拡張ヘッダテンプレートメモリ２０５内に格納される。アプリケーションがテンプレート内で使用される情報を供給しうるので、ＩＰ拡張ヘッダテンプレートは、通常、アプリケーション２０２（図２を参照）が開始された際に生成される。
【００２４】
図３は、図２のＩＰｓｅｃエンジン２０４及び拡張ヘッダテンプレートメモリ２０５の機能要素を示す図である。ＩＰｓｅｃエンジン２０４は、セキュリティポリシーデータベース３００、セキュリティアソシエーションデータベース３０１、テンプレートインデックスデータベース３０２及びプロセッサ３０３を具備する。ＩＰｓｅｃエンジン２０４は、矢印２０９で示すように、拡張ヘッダテンプレートメモリ２０５と対話する。拡張ヘッダテンプレートメモリ２０５は、２つのメモリ領域、すなわち、拡張ヘッダ領域３０４及び予測拡張ヘッダ領域３０５に分割される。
【００２５】
ネットワーク８０７を介した送信に先立ってＩＰｓｅｃ処理用のＩＰパケットを受信すると、ＩＰｓｅｃエンジン２０４は、パケットに対するＩＰｓｅｃ処理が必要であれば、どのＩＰｓｅｃ処理が必要であるかを判定するために、セキュリティポリシーデータベース３００に問い合わせる。ＩＰｓｅｃ処理が必要である場合、ＩＰｓｅｃエンジン２０４は、ＩＰｓｅｃ処理の実行に必要な鍵及びアルゴリズム等の複数の暗号パラメータを決定するために、プロセッサ３０３を介して、セキュリティアソシエーションデータベース３０１に問い合わせる。
【００２６】
このため、例えば、ＩＰｓｅｃエンジン２０４によりセキュリティアソシエーションデータベース３０１から読み出されたＩＰｓｅｃパラメータは、トンネルモードを指定してもよい。このトンネルモードの場合には、当該パケット用に形成すべき新規のＩＰヘッダを必要とする。この場合、新規のＩＰパケットは、１つ以上の外側ＩＰ拡張ヘッダを必要としてもよく、この外側ＩＰ拡張ヘッダは、本構成においてはＩＰ拡張ヘッダテンプレートメモリ２０５内に格納されたテンプレートに基づいて形成される。どの１つ以上のＩＰ拡張ヘッダテンプレートを使用すべきかを判定するために、必要な１つ以上のＩＰ拡張ヘッダテンプレート用のＩＰ拡張ヘッダテンプレートメモリ２０５への複数のインデックスを、セキュリティアソシエーションデータベース３０１内に格納してもよい。これらのインデックスは、拡張ヘッダテンプレートメモリ２０５から読み出されるべきＩＰ拡張ヘッダテンプレートを指定する。また、これらのインデックスは、複数のＩＰ拡張ヘッダテンプレートから導出された複数のＩＰ拡張ヘッダの、最終トンネルパケット内での発生順序を指定する。あるいは、必要な１つ以上のＩＰ拡張ヘッダテンプレートのインデックスを、別個のテンプレートインデックスデータベース３０２内に格納してもよい。
【００２７】
ＩＰ拡張ヘッダテンプレートメモリ２０５は、ＩＰ拡張ヘッダ用のテンプレートを収容する。２つ以上のＩＰｓｅｃセキュリティアソシエーションが、１つのＩＰ拡張ヘッダテンプレートを使用してもよい。また、各ＩＰｓｅｃセキュリティアソシエーションが、２つ以上のＩＰ拡張ヘッダテンプレートを使用してもよい。
【００２８】
「セキュリティアソシエーション」は（インターネット・エンジニアリング・タスク・フォースからのＲＦＣ２４０８で規定されるように）、２つ以上のエンティティ間の関係であり、安全に通信を行うために、エンティティがセキュリティサービスをどのように利用するかを記述する。セキュリティアソシエーションは、送信元コンピュータシステムから宛先コンピュータシステムへのデータの一方向の流れに対して適用される。２つのコンピュータシステムの間の双方向データフローに対しては、各方向についてのセキュリティアソシエーションが必要である。セキュリティアソシエーションの一部を構成するセレクタは、データフローから、セキュリティアソシエーションが適用される特定のＩＰデータグラムのみを選択するために使用されてもよい。各セキュリティアソシエーションは、データフローに適用されるべき単一の暗号処理動作を指定する。データフロー上で複数の暗号処理操作を実行するために、一連のセキュリティアソシエーションを、そのデータフローに適用してもよい。暗号処理ステップの指定は、
【００２９】
・適用されるべきセキュリティプロトコル（認証ヘッダ（ＡＨ）又はカプセル化セキュリティペイロード（ＥＳＰ）等）と；
・動作モード（トランスポートモード又はトンネルモード）と；
・使用すべき暗号アルゴリズム（ＭＤ５を用いるＨＭＡＣ、ＳＨＡ−１を用いるＨＭＡＣ、ＡＥＳ、ＤＥＳ等）と；
・暗号アルゴリズムの鍵値と；
・暗号アルゴリズムの初期値と；
・シーケンス番号（以前に送信されたデータグラムの、潜在的に悪意のある「再利用(replay)」を検知するために使用可能な単調増加番号）と；
・新規のセキュリティアソシエーションへの置き換えが必要となるまでに、セキュリティアソシエーションを適用可能な最大バイト数のカウントと；
・セキュリティアソシエーションが失効する時間（この時間を過ぎると新規のセキュリティアソシエーションで置き換えねばならない）を含むことができる。
【００３０】
セキュリティアソシエーションの使用は、
・シーケンス番号のインクリメントと；
・バイトカウントの更新とを含む、更新されるべき複数のパラメータを必要としてもよい。
【００３１】
通常、アプリケーションが最初に宛先コンピュータシステムへのパケット送信を試みた際にセキュリティアソシエーションが作成され、その接続のためのセキュリティポリシーが、ＩＰｓｅｃ処理の必要性を指定する。
【００３２】
セキュリティアソシエーションの確立処理は、暗号鍵生成及び交換のために複雑であり、時間を要する。従って、セキュリティアソシエーション確立処理の一部は、送信元コンピュータ内及び宛先コンピュータシステム内のソフトウェアにより実行されてもよい。
【００３３】
拡張ヘッダテンプレートは、通常、対応するセキュリティアソシエーションが作成される際に作成される。この拡張ヘッダテンプレートの作成は、セキュリティアソシエーション確立のために使用された、送信元コンピュータ内のソフトウェアと同じソフトウェアにより実行されてもよい。
【００３４】
例えば、セキュリティポリシーが、特定の接続用のパケットに対して、認証及び一連の既知のＩＰアドレスを介したトンネリングを指定した場合、ルーティング拡張ヘッダテンプレートは、対応する認証セキュリティアソシエーションを作成する際に作成されるであろう。そのセキュリティアソシエーションがパケット上で呼び出された場合、そのテンプレートを常に使用できるよう、セキュリティアソシエーションをヘッダテンプレートにリンクする。
【００３５】
既存のセキュリティアソシエーションと同一の拡張ヘッダを使用して拡張すべきパケットを必要とする後続のセキュリティアソシエーションが確立された場合、これらのセキュリティアソシエーションは、既存の拡張ヘッダテンプレートを使用できる。この場合、これらの後続のセキュリティアソシエーションは、同一のヘッダテンプレートにリンクされるであろう。代わりに、後続のセキュリティアソシエーションの各々に対する新規の拡張ヘッダテンプレートを作成してもよい。
【００３６】
この例では、次に、セキュリティアソシエーションは、ＩＰｖ４パケットが、ＩＰｖ６ネットワークを介してトンネリングされるべきであることを指定してもよい。この場合、ＩＰｖ６「タイプ０」のルーティング拡張ヘッダが、トンネリングされたパケットのルートの指定のために使用される。拡張ヘッダテンプレートは、指定されたルートの既知のＩＰアドレスを使用して作成される。通常、このルートはセキュリティアソシエーションが作成された際に、通知又は決定される。従って、セキュリティアソシエーションの有効期間中、拡張ヘッダテンプレートは、不変である。
【００３７】
元のＩＰｖ４パケットは、ＩＰｖ６ネットワークを介してトンネリングされるため、ＩＰｖ６ベースヘッダ、（拡張ヘッダテンプレートメモリからの）「タイプ０」ルーティング拡張ヘッダ及びＩＰｓｅｃ認証ヘッダが、元のＩＰｖ４パケットの先頭に付加(prepend)される。
【００３８】
ＩＰｓｅｃ認証ヘッダ内の認証データは、ＩＰｖ６ベースヘッダの一部、「タイプ０」ルーティング拡張ヘッダ、ＩＰｓｅｃ認証ヘッダの一部、及びオリジナルＩＰｖ４パケットを使用して算出される。しかしながら、認証データは送信元コンピュータシステムではなく、宛先コンピュータで現れるヘッダを使用して算出される。特に、「タイプ０」ルーティング拡張ヘッダは、トンネリングされたパケットがＩＰｖ６ネットワークを介して転送されるに連れて変更される。従って、ＩＰｓｅｃ認証ヘッダ内の認証データは、宛先コンピュータシステムで現れる状態を予測した「タイプ０」ルーティング拡張ヘッダを使用して算出される。
【００３９】
通常、セキュリティアソシエーションが作成される際に、宛先コンピュータにおいて検出されるような「タイプ０」ルーティング拡張ヘッダの予測も可能となる。従って、セキュリティアソシエーションが作成される際に、予測拡張ヘッダを拡張ヘッダテンプレートメモリ内に格納でき、予測拡張ヘッダはセキュリティアソシエーションの有効期間中不変である。
【００４０】
「タイプ０」ルーティング拡張ヘッダが使用される場合、予測ヘッダは、図１６Ａに示す形式（１００２）を有してもよい。この予測ヘッダは、図１５Ａに示す形式（９０２）でもよい非予測（送信元）ヘッダと異なる。「タイプ０」ルーティング拡張ヘッダが使用される場合、予測ヘッダと非予測ヘッダの相違は、ヘッダに含まれるＩＰアドレス及び「残りセグメント(segments left)」フィールドである。
【００４１】
セキュリティアソシエーションをパケット処理のために使用する際に、拡張ヘッダ及び予測拡張ヘッダの両方が、テンプレートメモリから読み出される。
【００４２】
この例では、予測拡張ヘッダは、認証データの算出に使用され、一方、非予測（送信元）拡張ヘッダは、ＩＰｖ６パケットの形成に使用されるであろう。
【００４３】
拡張ヘッダテンプレートは、１つ以上のセキュリティアソシエーションにより使用されている間、テンプレートメモリ内に残存するであろう。通常、セキュリティアソシエーションは、特定の期間の経過後、あるいは、特定の数のバイト又はパケットの処理に使用された後、終了する。通常、セキュリティアソシエーションの有効期間は、セキュリティアソシエーションの作成のために使用されたセキュリティポリシーにより決定される。
【００４４】
拡張ヘッダテンプレートが、セキュリティアソシエーションのいずれにも使用されない状態となった場合、その拡張ヘッダテンプレートは、新規の拡張ヘッダテンプレートにより上書きされてもよい。通常、テンプレートメモリの管理は、送信元コンピュータシステム内のソフトウェアにより行われる。このソフトウェアは、セキュリティアソシエーションの確立、及び拡張ヘッダテンプレートの作成においても使用される。
【００４５】
図４Ａは、図１の汎用コンピュータをより詳細に示す図である。ＩＰトンネリングの方法は、図４Ａに示すような汎用コンピュータシステム１８００と、図１〜図３及び図４Ｂに示す特定用途ハードウェアモジュール８０３との組み合わせの使用により実現できる。コンピュータ８０１とＩＰハードウェアモジュール８０３との間の機能配分は、可変であり、本明細書において説明される構成に限定されない。図７〜図１３のプロセスは、コンピュータシステム１８００内部で実行するトンネリングアプリケーションソフトウェアプログラム２１０等のソフトウェアとして実現されてもよい。
【００４６】
特に、ＩＰトンネリング方法のステップは、トンネリングソフトウェア２１０内の命令により達成される。命令は、コンピュータ８０１及びモジュール８０３により実行される。命令は、１つ以上の特定のタスクを実行する１つ以上の各コードモジュールとして構成されてもよい。また、トンネリングソフトウェア２１０は、ＩＰトンネリング方法を実行する第１の部分と、第１の部分とユーザとの間のユーザインタフェースを管理する第２の部分の２つの部分に分割されてもよい。ソフトウェア２１０は、例えば、以下に説明する記憶装置を含むコンピュータ可読媒体内に格納されてもよい。ソフトウェア２１０は、コンピュータ可読媒体からコンピュータ８０１内に読み込まれ、その後、コンピュータ８０１及びハードウェアモジュール８０３により実行される。このようなソフトウェア又はコンピュータプログラムが記録されたコンピュータ可読媒体は、コンピュータプログラムプロダクトである。コンピュータ内のコンピュータプログラムプロダクトの使用は、ＩＰトンネリングを行うのに有用な装置を好ましく実現する。
【００４７】
コンピュータシステム１８００は、コンピュータモジュール８０１と、キーボード１８０２及びマウス１８０３等の入力装置と、ディスプレイ１８１４及びスピーカ１８１７を含む出力装置とにより構成される。変調器−復調器（モデム）トランシーバ装置１８１６は、例えば、電話回線８０２又は他の機能媒体を介して接続可能な通信ネットワーク８０７との通信のために、コンピュータモジュール８０１により使用される。モデム１８１６は、インターネットへのアクセス、及びローカルエリアネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）等の他のネットワークシステムへのアクセスの獲得のために使用できる。モデム１８１６は、いくつかの実現例において、コンピュータモジュール８０１に内蔵されてもよい。
【００４８】
本例において、ＩＰ処理モジュール８０３は、専用の接続８０２を介してコンピュータ８０１に接続される。あるいは、ＩＰ処理モジュールが、ネットワークルータ又はネットワークスイッチ等の装置において実現された場合、ネットワーク８０７を介して、モジュール８０３をコンピュータ８０１に接続することも可能である。
【００４９】
コンピュータモジュール８０１は、通常、少なくとも１つのプロセッサユニット１８０５及びメモリユニット１８０６を含む。メモリユニット１８０６は、例えば、半導体ランダムアクセスメモリ（ＲＡＭ）及び半導体読み出し専用メモリ（ＲＯＭ）から構成される。また、モジュール８０１は、複数の入力／出力（Ｉ／Ｏ）インタフェースを含む。複数の入力／出力（Ｉ／Ｏ）インタフェースは、ビデオディスプレイ１８１４及びスピーカ１８１７に接続されるオーディオ／ビデオインタフェース１８０７と、キーボード１８０２、マウス１８０３及び必要に応じて設けられるジョイスティック（不図示）用のＩ／Ｏインタフェース１８１３と，モデム１８１６用に使用され、且つＩＰ処理モジュール８０３と通信を行うインタフェース１８０８とを含む。
【００５０】
いくつかの実現例において、モデム１８１６は、インタフェース１８０８内等、コンピュータモジュール８０１に内蔵されていてもよい。記憶装置１８０９は、コンピュータモジュール８０１内に設けられ、通常、ハードディスクドライブ１８１０と、フロッピディスク１８３６を受け付けるフロッピディスクドライブ１８１１とを含む。更に、コンピュータモジュール８０１は、磁気テープドライブ（不図示）を使用してもよい。ＣＤ−ＲＯＭ１８３５を受け付けるＣＤ−ＲＯＭドライブ１８１２は、通常、データの不揮発性供給元として設けられる。コンピュータモジュール８０１の構成要素１８０５から構成要素１８１３は、通常、関連技術の当業者に知られるコンピュータシステム１８００の従来の動作モードが得られるように、相互接続バス１８０４を介して通信を行う。上述の構成を実現可能なコンピュータの例は、複数のＩＢＭ−ＰＣとその互換機と、Sun Sparcstations又はSun Sparcstationsから派生した類似のコンピュータシステムとを含む。
【００５１】
通常、トンネリングアプリケーションプログラム２１０は、ハードディスクドライブ１８１０上に常駐する。トンネリングアプリケーションプログラム２１０は、（コンピュータ８０１内の）プロセッサ１８０５及び（ＩＰ処理モジュール８０３内の）プロセッサ１８３１による実行時に読み出され、制御される。プログラム２１０及びネットワーク８０７から取り込まれた任意のデータの中間記憶は、半導体メモリ１８０６及び１８３２を使用して、或いはこれらメモリとハードディスクドライブ１８１０との協働により行うことができる。いくつかの例において、トンネリングアプリケーションプログラム２１０は、ＣＤ−ＲＯＭ１８３５上又はフロッピディスク１８３６上に符号化され、対応するドライブ１８１２又はドライブ１８１１を介して読み取られた状態でユーザに提供されてもよい。あるいは、アプリケーションプログラム２１０は、モデム装置１８１６を介してネットワーク８０７からユーザにより読み取られてもよい。更に、ソフトウェアは、他のコンピュータ可読媒体からコンピュータシステム１８００内に読み込むことも可能である。
【００５２】
本明細書で用いられる「コンピュータ可読媒体」とは、実行及び／又は処理のための命令及び／又はデータを、コンピュータシステム１８００及びＩＰモジュール８０３へ供給する任意の記憶媒体又は伝送媒体である。記憶媒体の例には、フロッピディスク、磁気テープ、ＣＤ−ＲＯＭ、ハードディスクドライブ、ＲＯＭ又は集積回路、光磁気ディスク、又はＰＣＭＣＩＡカード等のコンピュータ可読カードが含まれる。これらの装置は、コンピュータモジュール８０１及びＩＰモジュール８０３の内部又は外部のいずれに設けられてもよい。伝送媒体の例は、無線送信チャネル又は赤外線送信チャネルと、別のコンピュータ又はネットワーク装置へのネットワーク接続と、電子メール送信及びウェブサイト等に記録された情報を含む、インターネット又はイントラネットとを含む。
【００５３】
図４Ｂは、図１のＩＰハードウェアモジュール８０３をより詳細に示す図である。ＩＰハードウェアモジュール８０３は、プロセッサ１８３１と、メモリ１８３２とを有し、さらに、ＩＰモジュール８０３を介してトンネリングアプリケーションソフトウェアを読み込むことが望ましい場合には、トンネリングアプリケーションソフトウェアを含むＣＤ−ＲＯＭ（不図示）を受け付けるためＣＤ−ＲＯＭドライブ１８３３とを具備する。Ｉ／Ｏインタフェース１８３０は、矢印８０２で示すように，図１に示す送信元コンピュータ８０１との対話を提供する。
【００５４】
ＩＰハードウェアモジュール８０３が、組み込み型コンピュータシステムであるか、又は組み込み型コンピュータシステムの一部を構成する場合、トンネリングアプリケーションソフトウェアは、メモリ１８３２内のＲＯＭ内に組み込み可能であり、ＣＤ−ＲＯＭドライブ１８３３は存在しないであろう。
【００５５】
図５は、１００として、ＩＰパケット１０１及びＩＰパケット１０１がカプセル化されたトンネルパケット１０５を表す図である。ＩＰパケット１０１は、ＩＰヘッダ１０２、複数のＩＰ拡張ヘッダ１０３及びペイロード１０４から構成される。トンネリング後、新規の（トンネル）ＩＰパケット１０５が形成される。トンネルパケット１０５は、新規のＩＰヘッダ１０６と、複数の新規のＩＰ拡張ヘッダ１０７と、ＩＰ拡張ヘッダ１０７に続くオリジナルＩＰパケット１０１のコピーであるペイロード１０２’＋１０３’＋１０４’とを有する。ＩＰヘッダ１０２’は、ＩＰヘッダ１０２のコピーである。ＩＰ拡張ヘッダ１０３’は、ＩＰ拡張ヘッダ１０３のコピーである。ペイロード１０４’は、ペイロード１０４のコピーである。
【００５６】
トンネルパケット１０５において、新規のＩＰヘッダ１０６を、外側ＩＰヘッダと呼ぶ。ＩＰ拡張ヘッダ１０７を、外側ＩＰ拡張ヘッダと呼ぶ。これに対して、オリジナルＩＰヘッダ１０２のコピー１０２’を、内部ＩＰヘッダと呼ぶ。また、オリジナルＩＰ拡張ヘッダ１０３のコピー１０３’を、内部ＩＰ拡張ヘッダと呼ぶ。
【００５７】
尚、上述したように、外側ＩＰヘッダ１０６は、通常、内部ＩＰヘッダ１０２’からいくつかのフィールドをコピーすることにより形成できる。しかしながら、外側ＩＰ拡張ヘッダ１０７は、必ずしもオリジナルＩＰパケット１０１と関連付けされる必要はないので、外側ＩＰ拡張ヘッダ１０７の形成は、より複雑である。
【００５８】
図６は、トンネルパケットがＩＰｓｅｃヘッダを含む場合のパケットカプセル化の別の例４００を示す図である。オリジナルＩＰパケット１０１は、ＩＰヘッダ１０２とペイロード１０４とを含む。また、本例において、オリジナルＩＰパケット１０１は、ＩＰ拡張ヘッダ１０３を含む。パケット１０１のカプセル化により、新規のＩＰトンネルパケット４０１が形成される。このパケット４０１は、新規の外側ＩＰヘッダ４０２と、オリジナルＩＰヘッダ１０２のコピー１０２’と、オリジナルＩＰ拡張ヘッダ１０３のコピー１０３’とを含む。また、新規のパケット４０１は、さらにオリジナルペイロード１０４のコピー１０４’を含む。また、新規のパケット４０１は、認証ヘッダ等のＩＰｓｅｃヘッダ４０４を含む。ＩＰｓｅｃヘッダ４０４は、ＩＰｓｅｃ処理の一部としてパケット４０１に追加される。また、新規のパケット４０１は、複数の新規（外側）のＩＰ拡張ヘッダ４０３を含む。ヘッダ４０３は、開示されたＩＰトンネリングアプローチに従って、拡張ヘッダメモリ領域３０４（図３を参照）内に格納されたＩＰ拡張ヘッダテンプレートから作成される。ＩＰｓｅｃ処理が、認証ヘッダ及びトンネルモードをパケット４０１に追加することを含む場合、図４のＩＰｓｅｃヘッダ４０４は、新規のＩＰ拡張ヘッダ４０３を含むＩＰパケット４０１全体に適用される認証ヘッダである。この処理を、図９及び図１０を参照してより詳細に説明する。
【００５９】
図７は、開示されたトンネリング技術に従って、予め規定されたテンプレートを生成し、これらのテンプレートを使用してＩＰパケットを処理するプロセスを示す図である。図示された２つの各プロセス１１００及びプロセス１１００’は、コンピュータ８０１上及びＩＰモジュール８０３上で稼動している、個別の、しかし相互に関連するプロセスモジュールとして実現できる。プロセス１１００は、（ｉ）メモリ領域３０４内に格納するための拡張ヘッダテンプレート及び（ｉｉ）拡張ヘッダテンプレートメモリ２０５のメモリ領域３０５（図２を参照）内に格納するための予測拡張ヘッダテンプレートの生成に関する。プロセス１１００’では、開示されたトンネリング技術に従って、プロセス１１００により生成された予め規定された複数のテンプレートを使用してパケット処理を行う。
【００６０】
プロセス１１００の第１のステップ１１０１において、アプリケーションソフトウェア２０２及びトンネリングアプリケーションソフトウェア２１０のいずれか又は両方は、メモリ領域３０４内に格納するための拡張ヘッダテンプレートを生成する。続くステップ１１１３では、メモリ領域３０５内に格納するための対応する予測拡張ヘッダテンプレートを生成する。一般に、ステップ１１０１で生成された各拡張ヘッダテンプレートに対して、ステップ１１１３で、１つの対応する予測拡張ヘッダテンプレートが生成される。しかしながら、各拡張ヘッダテンプレートに対して、２つ以上の対応する予測拡張ヘッダテンプレートを生成することも可能である。ドライバソフトウェア２０１により実行されるステップ１１０２では、これらのテンプレートを、拡張ヘッダテンプレートメモリ２０５のメモリ領域３０４及びメモリ領域３０５内に格納する。プロセス１１００は、テンプレート生成とメモリ領域３０４及びメモリ領域３０５内へのテンプレートの格納とを行う事前の(a priori)処理を表す。しかしながら、この処理は、開示された技法により使用可能な拡張ヘッダテンプレート又は他のテンプレートを、どのように生成しうるかの一例に過ぎない。
【００６１】
プロセス１１００の例を考察するため、３０４１として参照される拡張ヘッダテンプレートは、図１５Ａ及び図１５Ｂを参照して説明するように、特定のタイプ０ルーティングオプションを内蔵している。対応する予測拡張ヘッダテンプレート３０５１は、第１の拡張ヘッダテンプレート３０４１のヘッダフィールドから導出された予測ヘッダフィールドを内蔵している。上述の予測動作は、認証ヘッダ要求に基づく。従って、予測拡張ヘッダテンプレート３０５１は、拡張ヘッダテンプレート３０４１との使用に最適な認証ヘッダ（図１５Ａの９０３等）が、その後、そのような認証ヘッダが要求されるような場合に判定されることを可能とする。
【００６２】
図７のプロセス１１００’へ戻ると、アプリケーションソフトウェア２０２及びドライバソフトウェア２０１により実行される第１のステップ１１０３は、パケットＡの受信及び／又は生成を行う。これにより、例えば、アプリケーションソフトウェア２０２は、パケットＡを生成できる。あるいは、パケットＡは、別のソフトウェア処理（不図示）から受信され、ドライバソフトウェア２０１に提供されることが可能である。その後、プロセッサ３０３により実行される決定ステップ１１０４では、ＩＰｓｅｃ処理又はトンネリング処理が必要か判定する。この判定は、セキュリティポリシーデータベース内のセキュリティポリシーにより確立されるであろう。もし必要であれば、矢印ＹＥＳに従って、ステップ１１０７へ進む。
【００６３】
ＩＰハードウェアモジュール８０３により実現されるステップ１１０７では、モジュール８０３がパケットＡを操作し、拡張ヘッダテンプレートメモリ２０５内のテンプレートを使用して、それぞれ、Ａ１（非認証ＩＰｓｅｃ処理のみが実行される場合）、Ａ２（トンネリングのみが必要である場合）、Ａ３（トンネリング及びＩＰｓｅｃ認証処理が実行される場合）、又はＡ４（ＩＰｓｅｃ認証処理のみが実行される場合）と呼ばれるパケットを形成する。パケットＡ及びＡ３は、それぞれ、図１４のパケット７００並びに図１５Ａ及び図１５Ｂのパケット９００／９００’により示される。形態Ａから形態Ａ１、Ａ２、Ａ３又はＡ４へのパケット変換は、図９と関連してより詳細に説明する。
【００６４】
図７へ戻ると、ステップ１１０７の後、ＩＰハードウェアモジュール８０３により実行されるステップ１１０５では、パケットＡ１、Ａ２、Ａ３又はＡ４をネットワーク８０７へ送信し、ネットワーク８０７によってパケットは宛先コンピュータ８０９へ送信される。ステップ１１０５の後、矢印１１０６に従って、ステップ１１０３へ戻る。検査ステップ１１０４へ戻り、ＩＰｓｅｃ処理及びトンネル処理のいずれも不要な場合、矢印ＮＯに従って、ステップ１１０５へ進む。
【００６５】
要約すると、図７は、プロセス１１００に従った、予め規定された複数のパケットフィールド（すなわち、メモリ領域３０４及び３０５内に格納されるテンプレート）の生成、及びプロセス１１００’に従ったＩＰパケット処理時の、メモリ領域３０４及び３０５内に格納されたこれらのテンプレートの使用を表す図である。
【００６６】
図８は、図７のＡ等のパケットが生成されるプロセス１１０３（図７を参照）を示す図である。処理は、矢印１１０６に従って、図７から第１のステップ１５０１へ進む。プロセス１１０３は、送信用データを生成するステップ１５０１によって開始する。ステップ１５０１は、通常、アプリケーションソフトウェア２０２により実行される。その後、再び、アプリケーションソフトウェア２０２により実行されるステップ１５０２では、上記のデータをドライバソフトウェア２０１へ送信する。ドライバソフトウェア２０１により実行される、続くステップ１５０３では、上記のデータを、ハードウェアモジュール８０３内のＩＰエンジン２０３へ送信する。その後、ＩＰエンジン２０３により実行されるステップ１５０４では、上記のデータからパケットＡを形成する。次のステップ１５０５では、上記のパケットＡをＩＰｓｅｃエンジン２０４に渡す。ステップ１５０５の後、矢印１１１２に従って、図７の検査ステップ１１０４へ戻る。
【００６７】
図９は、開示されたトンネリング技術に従って図７のパケットＡを処理する、プロセス１１０７を示す図である。
ＩＰｓｅｃ処理において、通常、複数のＩＰデータグラムは、まず、セキュリティポリシーデータベース３００と照合される。送信元ＩＰアドレス、宛先ＩＰアドレス、トランスポートプロトコル（例えばＴＣＰ(Transmission Control Protocol)又はＵＤＰ(User Datagram Protocol)）、転送元(transport source)アドレス及び転送先(transport destination)アドレス等のＩＰパケットからの複数のフィールドは、データベース３００内のセキュリティポリシーにおける複数のセレクタと比較される。
【００６８】
通常、各セキュリティポリシーは、一致ポリシー(matching policy)が発見されるまで順に照合される。個人ベース、サイトベース、機関ベース又は会社ベースでのセキュリティポリシー強化のために、セキュリティポリシーデータベース３００は、通常、システム又はネットワーク管理者によりセットアップされる。一致ポリシーが、ＩＰデータグラムが送信可能となる前に、ＩＰｓｅｃ処理が必要であることを示す場合、セキュリティアソシエーションデータベース３０１を検索する。一致ポリシーは、通常、チェックすべき最初のセキュリティアソシエーションを示す、セキュリティアソシエーションデータベース３０１へのインデックスを含む。通常、引き続くセキュリティアソシエーションは、最初のセキュリティアソシエーションから、リンクされたリストの形式によりリンクされる。また、各セキュリティアソシエーションは、通常、セキュリティポリシーデータベース３００において使用される複数のセレクタと同一の複数のセレクタを有する。セレクタは、ＩＰデータグラムに対する特定のセキュリティアソシエーションのよりきめ細かな選択を可能とする。
【００６９】
一致アソシエーションが発見されない場合、新規のセキュリティアソシエーションを、それぞれ、送信元コンピュータシステム８０１と宛先コンピュータシステム８０９との間でネゴシエートする必要がある。通常、このネゴシエーションは、インターネット鍵交換（ＩＫＥ）等の複数の鍵交換プロトコルを使用して行われる。鍵生成及び鍵交換は、通常、複雑な手順であり、たいがいはソフトウェアドライバ２０１により処理されるであろうが、計算コストのかかる演算について、何らかの形でハードウェアを用いた高速化を用いることも可能である。どの型のセキュリティアソシエーションをネゴシエートするべきかを判定する複数のパラメータ（例えば、暗号アルゴリズム制限、鍵長さ制限、バイト制限及び／又は時間満了制限）は、通常、セキュリティポリシー内のフィールドからもたらされる。
【００７０】
セキュリティアソシエーションは一般に、オフされた機器を起動させることはなく、また、バイトカウント制限及び／又は時間満了により失効するため、通常、動的な性質を有する。セキュリティアソシエーションが失効すると、新規のアソシエーションを、その置き換えとしてネゴシエートする必要がある。この置き換えは、通常、新規の暗号鍵の生成を含む。一方で、セキュリティポリシーは通常、セキュリティに関するサイトポリシー、会社ポリシー又は機関ポリシーを反映するものであるため、より静的な傾向がある。
【００７１】
セキュリティアソシエーションは、セレクタに加え、実行されるべき特定の暗号演算の詳細を指定する。動作の指定に使用される典型的なパラメータは、ＡＨ／ＥＳＰ、アルゴリズム、鍵、初期値、シーケンス番号、トランスポート／トンネルモード、バイトカウント及び時間満了を含む。
【００７２】
セキュリティアソシエーションと１つ以上のヘッダテンプレートとの間の関係が、有用であることは明らかである。トンネルモードにおいて、セキュリティアソシエーションが検出され、且つセキュリティアソシエーションが認証ヘッダの必要性を明示した場合、ＩＰｓｅｃエンジン２０４は、暗号演算１２０１の実行前に、１つ以上の拡張ヘッダをデータグラムに追加する必要があるだろう。
【００７３】
セキュリティアソシエーションは、暗号パラメータに加え、ヘッダテンプレートメモリ２０５内の１つ以上のヘッダテンプレートへの１つ以上のインデックスを格納してもよい。あるいは、個別のヘッダインデックスデータベース３０２を、ヘッダテンプレートメモリへのインデックスを格納するために使用してもよい。後者の場合、セキュリティアソシエーションは、ヘッダインデックスデータベース３０２への単一のインデックスを格納し、ヘッダインデックスデータベース３０２は、ヘッダテンプレートメモリ２０５内への１つ以上のインデックスを格納する。
【００７４】
ヘッダテンプレートに対するこれらのインデックスの値は、通常、新規のセキュリティアソシエーションの作成処理の一部として、ソフトウェアドライバ２０１により初期化されるであろう。どのヘッダが必要であるかの詳細及びこれらのヘッダの内容は、通常、セキュリティについてのサイトポリシー、会社ポリシー又は全機関にわたるポリシーの一部として規定されるであろう。
【００７５】
図９のプロセス１１０７は、図７の処理における矢印１１１０に従って、パケット「Ａ」に対するプロセス１１０７が指示されることにより開始する。検査ステップ１２００では、認証を含まないＩＰｓｅｃ処理がパケットＡに対して必要であるかを判定する。この判定は、セキュリティアソシエーションデータベース内のセキュリティアソシエーションにより確立されうる。判定の結果、必要なら、矢印ＹＥＳに従って、ステップ１２０１へ進む。ＩＰｓｅｃエンジン２０４により実行されるステップ１２０１では、非認証ＩＰｓｅｃ処理に必要な暗号パラメータを読み出し、且つこの処理を実行することにより、パケットＡからパケットＡ１を形成する。その後、検査ステップ１２０２へ進む。
【００７６】
プロセッサ３０３（図３を参照）により実行されるステップ１２０２では、セキュリティアソシエーション内に格納された情報に基づいて、考慮すべき現在のパケットに対してトンネリングが必要か判定される。この判定は、セキュリティアソシエーションデータベース内のセキュリティアソシエーションにより確立されうる。必要であれば、矢印ＹＥＳに従って、ステップ１２０７へ進む。プロセッサ３０３により実行されるステップ１２０７では、拡張ヘッダインデックスを、テンプレートインデックスデータベース３０２から読み出す。次に、ステップ１２０７では、このインデックスを使用して、それぞれ、拡張ヘッダテンプレートメモリ３０４から対応する拡張ヘッダのコピーを得、予測拡張ヘッダテンプレートメモリ３０５から対応する予測拡張ヘッダテンプレートのコピーを得る。その後、ステップ１２０８では、修正中間パケットＡ２を形成するために、読み出された拡張ヘッダテンプレートのコピーをパケットＡ又はパケットＡ１内に挿入する。また、ステップ１２０８では、予測ヘッダテンプレートコピーの修正も実行できる。この修正は、認証ヘッダ中の空白の「シーケンス番号」フィールドと、現在のシーケンス番号（セキュリティアソシエーションと関連付けられた暗号パラメータのうちの１つ）との置き換え、及び、タイプ０ルーティングヘッダ内の空白の「次ヘッダ」フィールドと、続くヘッダ又はトランスポートプロトコルのＩＰプロトコル番号との置き換えとを含む。
【００７７】
ステップ１２０８の後、検査ステップ１２０９に進み、ＩＰｓｅｃ認証が必要であるか判定される。この判定は、セキュリティアソシエーションデータベース内のセキュリティアソシエーションにより確立されうる。必要である場合、矢印ＹＥＳに従って、ステップ１２１０へ進む。ステップ１２１０では、認証パラメータを、セキュリティアソシエーションデータベース３０１から読み出す。その後、ステップ１２１３では、認証処理を実行することにより、認証フィールドＦ（完全性チェック値（ＩＣＶ））を判定し、それにより、パケットＡ３を形成する。ステップ１２１３により実行された認証処理の少なくとも一部は、図１１を参照してより詳細に説明するように、ステップ１２０８により処理された予測ヘッダテンプレートに対して実行される。続いて、矢印１２１４に従って、矢印線１１１１に従った図７へ戻る。ステップ１２０９へ戻り、認証が必要でない場合、矢印ＮＯに従って、矢印線１１１１に従った図７へ戻る。
【００７８】
図９を参照して説明したプロセス１１０７では、複数の拡張ヘッダインデックスを読み出すためのステップ１２０７、及び複数の認証パラメータを読み出すためのステップ１２１０の２つのステップを使用するが、別の構成において、これらの動作は、より効率的に、ステップ１２０７の実行と同時に読み出されてもよい。
【００７９】
ステップ１２０２へ戻ると、トンネリングが必要でない場合、矢印ＮＯに従って、ステップ１２０３へ進む。ステップ１２０３では、ＩＰｓｅｃ認証が必要か判定される。この判定は、セキュリティアソシエーションデータベース内のセキュリティアソシエーションにより確立されうる。必要であれば、矢印ＹＥＳに従って、ステップ１２０４へ進む。プロセッサ３０３により実行されるステップ１２０４では、拡張ヘッダインデックスをテンプレートインデックスデータベース３０２から読み出し、このインデックスを使用して、拡張ヘッダテンプレートメモリ３０４内に格納される拡張ヘッダテンプレートを取得する。また、ステップ１２０４では、認証パラメータをセキュリティアソシエーションデータベース３０１から読み出す。また、ステップ１２０４では、拡張ヘッダを修正する可能性があるが、その場合は予測ヘッダの読み出し又は処理を行わない。
【００８０】
拡張ヘッダに対して実行可能な修正の例は、認証ヘッダ内の空白の「認証データ」フィールドの、ＩＰｓｅｃエンジン２０４内に含まれるハードウェアにより算出された認証データグラムの完全性チェック値による置き換えと、認証ヘッダテンプレート内の空白の「シーケンス番号」フィールドの、現在のシーケンス番号（セキュリティアソシエーションと関連付けられた暗号パラメータのうちの１つ）による置き換えと、タイプ０ルーティングヘッダ内の空白の「次ヘッダ」フィールドの、続くヘッダ又はトランスポートプロトコルのＩＰプロトコル番号による置き換えとを含む。
【００８１】
その後、ステップ１２０５では、（修正）拡張ヘッダをパケットＡ内又はパケットＡ１内に挿入することにより、中間パケットを形成する。次に、ステップ１２０５では、中間パケットの形成を受けて認証処理を実行することにより、パケットＡ４を形成する。続いて、矢印１１１１に従って、図７へ戻る。ステップ１２０３へ戻って、認証が必要でない場合、矢印ＮＯ及び矢印１１１１に従って図７へ戻る。
【００８２】
図１０は、図３の予測拡張ヘッダ記憶装置３０５内に格納される予測拡張ヘッダテンプレートを生成する、図７のプロセス１１１３を示す図である。第１のステップ１８００では、一時メモリ（不図示）へ、拡張ヘッダテンプレート３０４１のコピーを格納する。その後、ステップ１８０１では、拡張ヘッダテンプレート３０４１の予測可能フィールドを修正することにより、初期予測拡張ヘッダテンプレート３０４１Ａを形成する。次のステップ１８０２では、図７に関連して述べたように、初期テンプレート３０４１Ａの予測不可能なフィールドを修正することにより、予測拡張ヘッダテンプレート３０５１を形成する。拡張ヘッダテンプレート３０４１と関連予測拡張ヘッダテンプレート３０５１は、それぞれ図３の拡張ヘッダメモリ３０４及び予測拡張ヘッダ記憶装置３０５内に格納される。
【００８３】
図１０のプロセス１８０１の実行のために、ＩＰｖ４パケット上の認証アルゴリズムの実行時に、次のＩＰｖ４オプションは、「予測可能フィールド」とみなされる。従って、認証アルゴリズムの実行のために、次のＩＰｖ４オプションは、処理ヘッダ内又はヘッダの一部に含まれる：
・オプションの終了(end of options)
・動作無し(no operation)
・ルータ警告(router alert)
・同報通信の送信(send a directed multi-destination delivery)。
上述の予測可能フィールドは、修正せずに使用される。換言すれば、これらのオプションに対するヘッダテンプレート及び予測ヘッダテンプレートは、同一である。
【００８４】
次のＩＰｖ４オプションは、図１０のステップ１８０２における「予測不可能なフィールド」とみなされ、ステップ１８０２においてゼロで置き換えられる：
・ルーズソースルーティング(loose source routing)
・タイムスタンプ
・レコードルート（経路記録）
・ストリクトソースルーティング(strict source routing)
・トレースルート（経路確認）。
【００８５】
次のＩＰｖ６拡張ヘッダは、ステップ１８０１において、宛先における予測値によって置き換えられる：
・タイプ０ルーティング。
【００８６】
従って、上述の構成において、全ての拡張ヘッダテンプレートは、対応する予測拡張ヘッダテンプレートを有するが、これらの予測拡張ヘッダテンプレートは、仕様に応じて異なるか、又は同一であるかが決定される。
【００８７】
尚、ＩＰｖ６は、「オプション」と呼ばれるより小さいエンティティによって構成される２つの拡張ヘッダを更に有する。尚、これらの「オプション」は、ＩＰ拡張ヘッダ及び／又はＩＰｖ４パケットヘッダ内のオプションに関連して先に述べたオプションとは異なる。これらの「ＩＰｖ６拡張ヘッダ内のオプション」は、オプションが認証算出に含まれるべきか否か、あるいは、算出のためにゼロで置き換えられるべきか否かを示すビットを含む。ＩＰｖ６拡張ヘッダのこのようなオプションには：
・ホップバイホップオプション
・宛先オプション
がある。
【００８８】
図１１は、図９のパケット認証を実行するプロセス１２１３（図９を参照）を示す図である。プロセス１２０９は、ステップ１３００へ進む矢印１２１６に従って、図９の処理から開始する。ステップ１３００では、パケットＡ２内の拡張ヘッダテンプレートコピーの代わりに（修正）予測拡張ヘッダテンプレートコピーを用いることにより、中間パケットを形成する。次に、ステップ１３００では、認証手順を中間パケットに適用することにより、認証フィールドＦを判定する。その後、ステップ１３０１では、フィールドＦを中間パケット内に挿入する。また、ステップ１３０１では、予測拡張ヘッダテンプレートの代わりに中間パケット内の拡張ヘッダテンプレートを用いることにより、パケットＡ３を形成する。その後、矢印１２１４に従って図９へ戻る。
【００８９】
図１２は、図２のハードウェア要素とソフトウェア要素との間のデータフロー５００を表す図である。ステップ「３」において、ドライバソフトウェア２０１は、図７のプロセス１１００に従って、拡張ヘッダテンプレート及び予測拡張ヘッダテンプレートを生成する。この生成は、場合により、アプリケーションソフトウェア２０２及びトンネリングアプリケーションソフトウェア２１０からの情報を使用して行われる。次のステップ「４」において、ドライバソフトウェア２０１は、拡張ヘッダテンプレートを拡張ヘッダテンプレートメモリ２０５内のメモリ領域３０４内に格納し、予測拡張ヘッダテンプレートを拡張ヘッダテンプレートメモリ２０５内のメモリ領域３０５内に格納する。次のステップ「１」は、アプリケーションソフトウェア２０２により生成されている送信用データを表す。次のステップ「２」は、アプリケーションソフトウェア２０２が上述のデータを、ＩＰハードウェアモジュール８０３と通信可能なドライバソフトウェア２０１に、どのようにして転送するかを表す。その後、ステップ「５」において、ドライバソフトウェア２０１は、ステップ「１」でアプリケーションソフトウェア２０２により生成されたデータをＩＰエンジン２０３へ送信する。次のステップ「６」において、ＩＰエンジン２０３は、ネットワーク８０７を介した送信用データをカプセル化するために、図８のプロセス１１０３に従って、そのデータからＩＰパケットを形成する。
【００９０】
次のステップ「７」において、ＩＰエンジン２０３は、ＩＰｓｅｃ処理のために、上記のパケットをＩＰｓｅｃエンジン２０４のプロセッサ３０３に渡す。その後、ステップ「８」において、ＩＰｓｅｃエンジン２０４は、ＩＰｓｅｃ処理が必要である場合、どのＩＰｓｅｃ処理が必要であるかを判定する。これは、セキュリティポリシーデータベース３００の検索、及びそれに続くセキュリティアソシエーションデータベース３０１の検索により判定される。続くステップ「９」において、ＩＰｓｅｃエンジンは、拡張ヘッダテンプレートメモリ３０５から適切なＩＰ拡張ヘッダテンプレート及び予測拡張ヘッダテンプレートを読み出す。ＩＰトンネリングが必要であり、且つＩＰ外側ヘッダ（ＩＰｖ６が使用される場合）の後にＩＰ拡張ヘッダが必要である場合、このようなテンプレートは、必要である。あるいは、オプションがＩＰヘッダ内で必要である場合、ＩＰｖ４環境下において、テンプレートは必要である。
【００９１】
ステップ「９」は、図１３を参照して説明するような方法により検索される拡張ヘッダテンプレートメモリ２０５に対する参照を使用して実行される。次のステップ「１０」において、ＩＰｓｅｃエンジン２０４は、ＩＰ拡張ヘッダテンプレートコピーを、ＩＰパケット内に挿入する。これにより、この挿入の前のＩＰ拡張ヘッダテンプレートのいくつかの部分は、修正される可能性がある。その後、ステップ「１１」において、ＩＰｓｅｃエンジン２０４は、対応する予測拡張ヘッダテンプレートを使用した認証ヘッダ生成により、更にパケットを処理する。続くステップ「１２」において、ＩＰｓｅｃエンジン２０４は、送信用の処理済みパケットをＩＰエンジン２０３に戻す。最後に、ステップ「１３」において、ＩＰエンジン２０３は、パケットをネットワーク８０７を介して送信する。
【００９２】
図１３は、図１２のデータフローをより詳細に示す図である。データフロー処理は、ステップ「７」によって開始する。ステップ「７」において、ＩＰエンジン２０３は、ＩＰｓｅｃ処理のためのＩＰｓｅｃエンジン２０４のプロセッサ３０３にパケットを渡す。その後、ステップ「８Ａ」において、ＩＰｓｅｃエンジン２０４は、セキュリティポリシーデータベース３００に照会し、ＩＰｓｅｃ処理が必要である場合、対象パケットに対してどのＩＰｓｅｃ処理が必要であるかを判定する。その後、ステップ「８Ｂ」において、ＩＰｓｅｃエンジン２０４は、セキュリティアソシエーションデータベース３０１からＩＰｓｅｃ処理を実行するために必要な複数の暗号パラメータ（鍵、アルゴリズム等）を検索する。これは、ステップ「８Ａ」に従ったＩＰｓｅｃ処理が必要であることを前提とする。その後、ステップ「８Ｃ」において、ＩＰｓｅｃエンジン２０４は、メモリ２０５内のＩＰ拡張ヘッダテンプレート及び対応する予測拡張ヘッダテンプレートのアドレス位置と、テンプレートコピーが最終パケット内に現れるべき順序とを特定するリファレンスを、セキュリティアソシエーションデータベース３０１から読み出す。これは、ステップ「８Ａ」によって、トンネルモード処理が必要である場合であり、そうでなければ、ステップ「８Ｃ’」において、ＩＰｓｅｃエンジン２０４は、テンプレートインデックスデータベース３０２からの上記のリファレンスを読み出す。
【００９３】
宛先コンピュータ８０９は、パケット（あるいは、データグラムと称される）を受信すると、まず、データグラムがＩＰｓｅｃヘッダを含むか判定する。そして、ＩＰｓｅｃヘッダがデータグラムに存在しない場合、データグラムの分配を決定するため、セキュリティポリシーデータベース（不図示）を調べる。分配は、データグラムの受け入れ又は破棄のいずれであってもよい。データグラムがＩＰｓｅｃヘッダを含む場合、適切なＩＰｓｅｃ処理ステップが試行される。各ＩＰｓｅｃ処理ステップは、宛先コンピュータ８０９のセキュリティアソシエーションデータベース（不図示）内に、対応するセキュリティアソシエーションを必要とする。対応するセキュリティアソシエーションが存在しない場合、データグラムは破棄される。ある認証ヘッダについて、対応するセキュリティアソシエーションが存在する場合、その認証算出のための暗号パラメータはセキュリティアソシエーションから読み出され、データグラムに対する完全性チェック値（ＩＣＶ）の算出のために使用される。データグラム内のいくつかのフィールドは算出から除外される。認証ヘッダ内の（ＩＣＶを格納する）認証データフィールドは、そのような除外フィールドの１つである。算出されたＩＣＶがデータグラム内のＩＣＶと一致し、且つ有効性に関する全ての他の条件が満足された場合（例えば、シーケンス番号が妥当である、バイトカウントが超過していない、又は満了時間を超過していない）、データグラムは、認証されたとみなされる。
【００９４】
受信データグラムについてのＩＰｓｅｃ処理が全て終了した後、宛先コンピュータ８０９は、そのようなデータグラム内にどのＩＰｓｅｃ処理の存在が予期されていたかを判定するため、セキュリティポリシーデータベース（不図示）を調べる。必要なＩＰｓｅｃ処理が存在した場合、そのパケットは受入れられる。必要なＩＰｓｅｃ処理が存在しない場合、パケットは破棄される。
【００９５】
図１４は、ＩＰｖ４パケット７００を示す図である。ＩＰｖ４パケット７００は、２つの部分、すなわち、ＩＰｖ４ヘッダ７０１及びＴＣＰペイロード７０２から構成される。図１のネットワーク８０７のようなＩＰｖ６ネットワークを介してＩＰｖ４パケット７００を送信するために、ＩＰｖ４パケット７００をトンネリング（すなわち、カプセル化）することができる。このトンネリングは、ＩＰｖ４パケット７００を新規のＩＰｖ６パケットのペイロードとして取り扱う場合、ＩＰｖ６ヘッダの追加を必要とする。更に、本例において、生成されたＩＰｖ６パケットを、指定された方法でルーティングすることが望ましい。そのために、「タイプ０」ルーティング拡張ヘッダが組み込まれている。最後に、この特定の例において、ＩＰｖ６パケットを認証することにより、「認証ヘッダ」をペイロードの前に追加することが望ましい。
【００９６】
図１５Ａ及び図１５Ｂは、ルーティングオプション及び認証を含むＩＰｖ６トンネルパケット内にカプセル化された後の、図１４のＩＰｖ４パケットを表す図である。図１５Ａ及び図１５ＢのＩＰｖ６パケットは、符号９００（図１５Ａ）及び符号９００’（図１５Ｂ）で参照される２つの部分により示されている。ＩＰｖ６パケット部９００は、ベースヘッダ９０１、ＩＰｖ６タイプ０ルーティングヘッダ９０２及びＩＰｓｅｃ認証ヘッダ９０３を有する。この特定の例は、パケットに指定された３つの中間ＩＰｖ６アドレスを有する。このため、図１５Ａは、第１のＩＰｖ６中間アドレス９０４、第２のＩＰｖ６中間アドレス９０５、第３のＩＰｖ６中間アドレス９０６、及び最終のＩＰｖ６宛先アドレス９０７を示している。図１５Ｂにおいて、ＩＰｖ６パケットの第２の部分９００’は、ＩＰｖ４ヘッダ７０１’及びＴＣＰペイロード７０２’を有する、元のＩＰｖ４パケット７００のコピーを有している。
【００９７】
ＩＰｖ６パケット（９００及び９００’）が、（８０７のような）ネットワークを介して送信される際、パケットは、まず、フィールド９０４に従って、第１の中間アドレスで指定される宛先へ送信される。パケットがこの宛先に到着すると、ＩＰｖ６タイプ０ルーティングヘッダ９０２内の第２の中間アドレス９０５は、ＩＰｖ６ベースヘッダ９０１の宛先アドレスフィールド内にある第１のＩＰｖ６中間アドレス９０４と交換される。そして、「残りセグメント」フィールド９０８が、デクリメントされる。
【００９８】
同様に、このＩＰｖ６パケットが、フィールド９０５に従って第２の中間アドレスで指定された宛先に到着すると、ＩＰｖ６タイプ０ルーティングヘッダ９０２内の第３の中間アドレス９０６が、この時点でＩＰｖ６ベースヘッダ９０１の宛先アドレスフィールド内にある第２の中間アドレスと交換される。更に、「残りセグメント」フィールド９０８が再びデクリメントされる。最後に、ＩＰｖ６パケットが、第３の中間アドレスで指定された宛先に到着すると、ＩＰｖ６タイプ０ルーティングヘッダ９０２内の最終の宛先アドレス９０７が、この時点でＩＰｖ６ベースヘッダ９０１の宛先アドレスフィールド９０４内にある第３の中間アドレス９０６と交換され、「残りセグメント」フィールド９０８が、再度デクリメントされる。
【００９９】
このように、ＩＰｖ６パケットがネットワーク８０７を介して最終の宛先へ向かうにつれ、タイプ０ルーティングヘッダ９０２が変化することがわかる。パケットが最終宛先で受信された際、図１６Ａ及び図１６Ｂに示す形態を有する。この時点において、最終のＩＰｖ６宛先アドレスは、ＩＰｖ６ベースヘッダ１００１内にある。更に、第１〜第３の中間アドレスは、ＩＰｖ６タイプ０ルーティングヘッダ１００２内にある。最後に、「残りセグメント」フィールドは、０の値にデクリメントされている。従って、図１６Ａ及び図１６Ｂは、パケットが図１の宛先コンピュータ８０９に到着した時の図１５Ａ及び図１５Ｂのトンネルパケットを示す図である。
【０１００】
送信元コンピュータシステム８０１が、コンピュータ８０１から送信されるべきＩＰｖ６パケットに対する認証値を算出する場合、宛先コンピュータシステム８０９で受信されるであろうタイプ０ルーティングヘッダ値を予測する必要がある。そのため、タイプ０ルーティングヘッダを発信ＩＰｖ６パケットに追加する場合、送信元コンピュータシステム８０１は、図１７に示すタイプ０ルーティングヘッダを使用してＩＰｖ６パケットを作成する。これは、図１５Ａに示す９０２と同一であり、図３のメモリ領域３０４内に格納される「拡張ヘッダ」と呼ばれる。しかしながら、コンピュータシステム８０１により送信されるＩＰｖ６パケットに対する認証値９０３の算出には、図１８に示すタイプ０ルーティングヘッダが使用される。これは、図３のメモリ領域３０５内に格納される「予測拡張ヘッダ」と呼ばれる。
【０１０１】
このようにして、図１７のルーティングヘッダ１６０１及び図１８のルーティングヘッダ１７０１の両方が、拡張ヘッダテンプレートメモリ２０５内に格納される。より具体的には、ルーティングヘッダ１６０１は拡張ヘッダメモリ部分３０４内に格納され、ルーティングヘッダ１７０１は予測拡張ヘッダメモリ部分３０５内に格納される。
【産業上の利用可能性】
【０１０２】
上述の構成が、コンピュータ産業及びデータ処理産業に適用できることは、上述の説明により明らかである。
先の説明は、本発明のごく一部の実施形態を説明したものであり、本発明の範囲及び精神を逸脱せずに、本発明の変形及び／又は変更を行うことができる。実施形態は、例証であって、限定的ではない。
【図面の簡単な説明】
【０１０３】
【図１】開示されたＩＰトンネリングアプローチを実施可能なシステムのブロック図である。
【図２】図１の送信元コンピュータ及びＩＰ処理モジュールの機能要素を示す図である。
【図３】図２のＩＰｓｅｃエンジン及び拡張ヘッダテンプレートメモリの機能要素を示す図である。
【図４Ａ】図１の汎用コンピュータをより詳細に示す図である。
【図４Ｂ】図１のＩＰハードウェアモジュールをより詳細に示す図である。
【図５】ＩＰパケット及び、ＩＰパケットをカプセル化して得られるトンネルパケットを示す図である。
【図６】ＩＰｓｅｃヘッダを含むパケットカプセル化の別の例を示す図である。
【図７】予め規定されたテンプレートを生成するプロセス、及びこれらのテンプレートを使用してＩＰパケットを処理するプロセスを示す図である。
【図８】図７のパケットの生成方法を示す図である。
【図９】開示されたトンネリング技術に従って図７のパケットの処理する方法を示す図である。
【図１０】図７の予測拡張ヘッダテンプレートの包括的な生成プロセスを示す図である。
【図１１】パケット認証を実行する図９のプロセスを示す図である。
【図１２】図１のハードウェア要素とソフトウェア要素との間のデータフローを表す図である。
【図１３】図１２のセキュリティポリシーデータベース要素のデータフローをより詳細に示す図である。
【図１４】ＩＰｖ４パケットの例を示す図である。
【図１５Ａ】、
【図１５Ｂ】ルーティングオプション及び認証ヘッダを含む、典型的なＩＰｖ６トンネルパケット内にカプセル化された図１４のＩＰｖ４パケットを表す図である。
【図１６Ａ】、
【図１６Ｂ】図１の宛先コンピュータへ図１５Ａ及び図１５Ｂのトンネルパケットが到着した際の状態を示す図である。
【図１７】図１５Ａ及び図１５ＢのＩＰｖ６トンネルパケットの作成に使用された（タイプ０ルーティング）拡張ヘッダを示す図である。
【図１８】上記トンネルパケットの認証値の算出に使用された（タイプ０ルーティング）拡張ヘッダを示す図。
【図１】
2005287034.tif 000003
【図２】
2005287034.tif 000004
【図３】
2005287034.tif 000005
【図４Ａ】
2005287034.tif 000006
【図４Ｂ】
2005287034.tif 000007
【図５】
2005287034.tif 000008
【図６】
2005287034.tif 000009
【図７】
2005287034.tif 000010
【図８】
2005287034.tif 000011
【図９】
2005287034.tif 000012
【図１０】
2005287034.tif 000013
【図１１】
2005287034.tif 000014
【図１２】
2005287034.tif 000015
【図１３】
2005287034.tif 000016
【図１４】
2005287034.tif 000017
【図１５Ａ】
2005287034.tif 000018
【図１５Ｂ】
2005287034.tif 000019
【図１６Ａ】
2005287034.tif 000020
【図１６Ｂ】
2005287034.tif 000021
【図１７】
2005287034.tif 000022
【図１８】
2005287034.tif 000023
【外国語明細書】
TITLE OF THE INVENTION
INTERNET PROTOCOL TUNNELLING USING TEMPLATES
FIELD OF THE INVENTION 
The present invention relates generally to computer networks, and in particular, to architectures for processing Internet protocol (IP) packets.
BACKGROUND
IP is a common data standard used by computer systems to exchange data over a network.  Using the IP standard, data is transferred in packets from a source computer system to a destination computer system.  Data can be transferred directly between the two computers, or indirectly, being passed through other computer systems before arriving at the destination computer system.  IP version 4 (IPv4) and IP version 6 (IPv6) are two popular versions of the IP communication standard.  IPv4 and IPv6 differ in their terminology and implementations, but the two standards share many equivalent features.  The IP tunnelling technique disclosed in this description applies to IPv4 and IPv6, and accordingly terminology from both the IPv4 and IPv6 standards is used where appropriate.  The Internet protocol security standard (IPsec) is an IP standard that deals with authentication and confidentiality features for IP data, using cryptographic processing.  Processing systems for IP packets preferably support packet encapsulation (ie., tunnelling) as well as IPsec processing.
IP packets contain a header, followed by a payload.  In IPv4, "options", if present, appear as part of the IP header.  In IPv6, the IP header can be followed by IP extension headers.  IPv4 options and IPv6 IP extension headers can, for the purposes of this description, be considered to be functionally equivalent.
In some circumstances, an IP packet can be transported as the payload of an encapsulating IP packet.  The encapsulating packet is called a "tunnel packet".  The forwarding path between the source and destination of the tunnel packet is called a tunnel.  The technique of encapsulating a packet and sending it from a source to a destination is called tunnelling.  Once tunnelled (formed), a tunnel packet is provided with a new IP header and new IP extension headers, that are respectively referred to as an outer IP header and outer IP extension headers.  The header and extension headers of the (original) encapsulated packet are referred to as the inner IP header and the inner IP extension headers.  The outer IP header may be constructed by copying some fields from the inner IP header, however, the construction of the outer IP extension headers is not necessarily directly related to the inner IP extension headers.  
Typical IP processing systems are implemented in software.  As IP data rates increase, this software implementation approach is sometimes too slow for some applications.  If the processing methods typically used in software systems are directly mapped to a hardware implementation, then the speed of the resultant hardware system is typically greater than the corresponding software systems, however, such hardware implementations would be complex and inflexible.
SUMMARY
It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.
Disclosed are arrangements which predefine sets of packet fields (referred to as "templates") that can be used in processing IP packets.  This is referred to as the IP tunnelling approach in this description.  The approach is particularly useful when the packet processing involves tunnelling and authentication.  These pre-defined templates, such as extension headers for example, are constructed and stored for later use when processing IP packets.  The templates are used to rapidly perform at least part of the encapsulation and/or authentication process(es), to form what is referred to as an "augmented packet".  The remainder of the encapsulation and/or authentication process(es), if required, can, if desired, be performed in a conventional fashion or using further application(s) of the tunnelling approach. 
The tunnelling approach makes higher demands on memory resources than previous techniques, however it reduces the processing load required to process the IP packets.  This tunnelling approach can thus provide increases in IP processing speed, whether implemented in software or hardware.  Even greater speed advantages can be obtained by increasing the proportionate use of hardware in an IP processing system using the IP tunneling approach and pre-defined packet fields.
According to a first aspect of the present invention, there is provided a method of processing IP packets, the method comprising the steps of:
defining a plurality of sets of packet fields;
storing the sets of defined packet fields in a memory;
determining if a current IP packet is intended to be processed;
identifying the process to be applied to the current IP packet;
selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
According to another aspect of the present invention, there is provided an apparatus for processing IP packets, the apparatus comprising:
means for defining a plurality of sets of packet fields;
means for storing the sets of defined packet fields in a memory;
means for determining if a current IP packet is intended to be processed;
means for identifying the process to be applied to the current IP packet;
means for selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
means for operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
According to another aspect of the present invention, there is provided a computer program product having a computer readable medium having a computer program recorded therein for directing a processor to process IP packets, said computer program comprising:
code for defining a plurality of sets of packet fields;
code for storing the sets of defined packet fields in a memory;
code for determining if a current IP packet is intended to be processed;
code for identifying the process to be applied to the current IP packet;
code for selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
code for operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
According to another aspect of the present invention, there is provided a computer program for directing a processor to process IP packets, said computer program comprising:
code for defining a plurality of sets of packet fields;
code for storing the sets of defined packet fields in a memory;
code for determining if a current IP packet is intended to be processed;
code for identifying the process to be applied to the current IP packet;
code for selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
code for operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
Other aspects of the invention are also disclosed.
DETAILED DESCRIPTION INCLUDING BEST MODE
One or more embodiments of the present invention will now be described with reference to the drawings. Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.
It is to be noted that the discussions contained in the "Background" section and that above relating to prior art arrangements relate to discussions of processes or devices which form public knowledge through their respective publication and/or use.  Such should not be interpreted as a representation by the present inventor(s) or patent applicant that such processes or devices in any way form part of the common general knowledge in the art.
Fig. 1 shows a block diagram of a system upon which the disclosed IP tunnelling approach can be practiced.  A source computer 801 is connected as depicted by an arrow 802 to an IP hardware module 803.  As will be described in relation to Fig. 2, the IP hardware module 803 comprises both hardware and software elements. Software 810 runs, as depicted by a dashed line 811, on the computer 801.  The source computer 801 is connected, as depicted by an arrow 806, to a network 807.  A destination computer 809 is connected, as depicted by an arrow 808, to the network 807.  Software 812 runs, as depicted by a dashed line 813, on the destination computer 809.  
The disclosed tunnelling approach is used by the source computer 801, in conjunction with the software 810 and the IP hardware module 803, to process IP packets generated by the software 810 for transmission across the network 807 to the destination computer 809.
While Fig. 1 shows general purpose computers 801 and 809 as well as a separate IP hardware module 803, the tunnelling approach can also be used in embedded computer systems.  In such systems (not shown), which can include multi-function office equipment (such as devices integrating printer, scanner, copier, and facsimile capability), and network routers, the processing required to handle IP and IPsec may be done in software (using an embedded processor and embedded software) or in hardware.  In such systems, the data to be sent over IP may come from another embedded computer system, such as a (hardware) scanner for example. 
Fig. 2 shows functional elements of the source computer 801 and the IP module 803 of Fig. 1.  The software of the source computer 810 comprises a driver software module 201 which interacts, as depicted by an arrow 208, with application software 202.  The driver software module 201 interacts, as depicted by an arrow 206, with the IP hardware module 803.  This description assumes a particular distribution of functionality between the source computer 801 and the IP hardware module 803 of Fig. 1.  However, this is for illustration only, and other distributions of functionality can also be used.  The IP hardware module 803 comprises an IP engine 203 that interacts, as depicted by an arrow 207 with an IPsec engine 204.  The IPsec engine 204 interacts, as depicted by an arrow 209, with an extension header template memory 205.  The software of the computer 810 also includes a tunnelling application software module 210 that is described in more detail in regard to Fig. 4A.
The application software 202 is the source of the data that is to be transferred from the source computer 801 to the destination computer 809 over the network 807.  The application software 202 transfers this data to the driver software 201 which communicates with the IP hardware module 803.  
The IP engine 203 constructs IP packets from the data generated by the application software 202 in order to package the data for transmission over the network 807.  Prior to transmitting the packets over the network 807, the IP engine 203 passes each packet to the IPsec engine 204, for IPsec processing.  The IPsec engine 204 determines which, if any, IPsec processing is required for the particular packet being considered.  If IP tunnelling is to be applied, and if an outer IP extension header is required, then the appropriate outer IP extension header is retrieved from the IP extension header template memory 205.  It is noted that in the case of IPv4, instead of an outer IP extension header being required after the outer IP header, option(s) are required within the IP header.  This is, however, an equivalent requirement from the perspective of the present system. 
The IPsec engine 204 inserts a copy of the IP extension header, retrieved from the memory 205, into the IP packet.  This insertion possibly modifies some parts of the copied IP extension header before inserting the modified copy into the IP packet.  The IPsec engine 204 then processes the packet by, for example, generating an authentication header.  After the IPsec engine 204 completes processing of the packet, the packet is returned to the IP engine 203 for transmission across the network 807.  
The IP extension header templates are stored beforehand in the IP extension header template memory 205 by the driver software 201, possibly using information from the application software 202 and/or the tunnelling software application 210.  The IP extension header templates are typically generated when the application 202 (see Fig. 2) is started, since the application may supply information that is used in the templates.
Fig. 3 shows functional elements of the IPsec engine 204 and the extension header template memory 205 of Fig. 2.  The IPsec engine 204 comprises a security policy database 300, a security association database 301, a template index database 302 and a processor 303.  The IPsec engine 204 interacts, as depicted by the arrow 209, with the extension header template memory 205.  This memory 205 is partitioned into two memory regions, namely an extension header region 304 and a predicted extension header region 305.
Upon receipt of the IP packet for IPsec processing prior to transmission across the network 807, the IPsec engine 204 consults the security policy database 300 in order to determine what IPsec processing, if any, is required by the packet.  If IPsec processing is required, the IPsec engine 204, via the processor 303, consults the security association database 301 in order to determine the cryptographic parameters, such as keys, algorithms and so on, required to perform the IPsec processing. 
Thus, for example, the IPsec parameters extracted by the IPsec engine 204 from the security association database 301 may specify tunnel mode, which then requires a new IP header to be constructed for the packet in question.  In this case, the new IP packet may require one or more outer IP extension headers, which in the described arrangement are constructed based upon templates that are stored in the IP extension header template memory 205.  In order to determine which IP extension header template(s) should be used, indices into the IP extension header template memory 205 for the required IP extension header template(s) may be stored in the security association database 301.  These indices would specify the IP extension header templates to be extracted from the extension header template memory 205, as well as the order in which the IP extension headers that are derived from the IP extension header templates would appear in the final tunnel packet.  Alternatively, the indices of the required IP extension header template(s) can be stored in a separate template index database 302.  
The IP extension header template memory 205 contains the templates for the IP extension headers.  An IP extension header template may be used by more than one IPsec security association.  Each IPsec security association may use more than one IP extension header template.
A "Security Association" (as defined in RFC 2408 from the Internet Engineering Task Force) is a relationship between two or more entities that describes how the entities will utilize security services to communicate securely.  A security association applies to uni-directional dataflow from a source computer system to a destination computer system.  For bi-directional dataflow between two computer systems, two Security Associations are required, one in each direction.  Selectors that form part of the Security Association may be used to select only certain IP datagrams from the dataflow, to which the Security Association applies.  Each Security Association specifies a single cryptographic processing operation that is to be applied to the dataflow.  A sequence of Security Associations may be applied to a dataflow, in order to perform multiple cryptographic processing operations on that dataflow.  The specification of a cryptographic processing step may include:
* the security protocol to be applied (eg: authentication header (AH), or encapsulating security payload (ESP));
* the mode of operation (transport mode, or tunnel mode);
* the cryptographic algorithm to be used (eg: HMAC with MD5, HMAC with SHA-1, AES, DES);
* the key value for the cryptographic algorithm;
* an initial value for the cryptographic algorithm;
* a sequence number, a monotonically increasing number possibly used to detect potentially malicious "replay" of previously sent datagrams;
* a count of the maximum number of bytes to which the Security Association may be applied, before having to be replaced by a new Security Association;
* a time when the Security Association expires, after which the association must be replaced by a new Security Association.
Use of a Security Association may require that certain parameters be updated, including:
* increment of the sequence number;
* update of the byte count
Typically, a security association is created when an application first attempts to send a packet to a destination computer system, and the security policy for that connection specifies that an IPsec operation is required.
The process of establishing a security association is complex, and may take some time, because of the generation and exchange of cryptographic keys.  Thus, parts of the process of establishing a security association may be performed by software in the source and destination computer systems.
Typically, an extension header template is created when the corresponding security association is created.  This may be performed by the same software in the source computer system that is used to establish the security association.
For example, if a security policy specifies that packets for a particular connection should be authenticated and tunnelled through a series of known IP addresses, a routing extension header template would be created when the corresponding authentication security association is created.  The security association would be linked to the header template so that the template can be used whenever the security association is invoked on a packet.
If subsequent security associations are established that require packets to be augmented with the same extension header as an existing security association, it is possible for these security associations to use the existing extension header template.  In this case, these subsequent security associations would be linked to the same header template.  Alternatively, new extension header templates may be created for each subsequent security association.
Continuing with the example, the security association may specify that IPv4 packets should be tunnelled over an IPv6 network. In this case, an IPv6 "Type 0" routing extension header is used to specify the route of the tunnelled packets.  The extension header template is created with the known IP addresses of the specified route.  This route is typically known or determined when the security association is created, and thus the extension header template is invariant for the lifetime of the security association.
Since the original IPv4 packet is being tunnelled over an IPv6 network, an IPv6 base header, the "Type 0" routing extension header (from the template memory), and an IPsec authentication header, will be prepended to the original IPv4 packet.
The authentication data in the IPsec authentication header will be calculated using parts of the IPv6 base header, the "Type 0" routing extension header, parts of the IPsec authentication header, and the original IPv4 packet.  However, the authentication data are calculated using these headers as they will appear at the destination computer system, not as they appear at the source computer system.  In particular, the "Type 0" routing extension header will change as the tunnelled packet is transferred over the IPv6 network.  Thus, the authentication data in the IPsec authentication header will be calculated using the "Type 0" routing extension header as predicted to be seen by the destination computer system.
Typically, when the security association is created, it is also possible to predict the "Type 0" routing extension header as seen by the destination computer.  Thus, the predicted extension header can be stored in the template memory when the security association is created, and is invariant for the lifetime of the security association.
In the case of a "Type 0" routing extension header, the predicted header may have the form (1002) as shown in Fig 16A.  This differs from the non-predicted (source) header, which may have the form (902) as shown in Fig. 15A.  In the case of a "Type 0" routing extension header, the differences are the IP addresses included in the header, and the "segments left" field.
Both the extension header, and the predicted extension header will be retrieved from the template memory when the security association is used to process a packet.
Continuing to follow this example, the predicted extension header would be used in the calculation of the authentication data, while the non-predicted (source) extension header would be used in the construction of the IPv6 packet.
The extension header template would remain in the template memory while it is being used by one or more security associations.  Typically, a security association is terminated after a specified period of time has elapsed, or after it has been used to process a specified number of bytes or packets.  Typically, the lifetime of a security association is determined by the security policy that was used to create it.
If an extension header template is no longer being used by any security associations, it may be overwritten by a new extension header template.  Typically, the management of the template memory would be handled by the software in the source computer system that also used to establish security associations and create the extension header templates.
Fig. 4A shows the general purpose computer of Fig. 1 in more detail.  The method of IP tunnelling can be practiced using a combination of the general-purpose computer system 1800, such as that shown in Fig. 4A, together with the special purpose hardware module 803 shown in Figs. 1-3 and 4B.  The distribution of functionality between the computer 801 and the IP hardware module 803 can be varied, and is not limited by the arrangement described in this description.  The processes of Figs. 7-13 may be implemented as software, such as the tunnelling application software program 210 executing within the computer system 1800.  In particular, the steps of method of IP tunnelling are effected by instructions in the tunnelling software 210 that are carried out by the computer 801 and the module 803.  The instructions may be formed as one or more code modules, each for performing one or more particular tasks.  The tunnelling software 210 may also be divided into two separate parts, in which a first part performs the IP tunnelling methods and a second part manages a user interface between the first part and the user.  The software 210 may be stored in a computer readable medium, including the storage devices described below, for example.  The software 210 is loaded into the computer 801 from the computer readable medium, and then executed by the computer 801 and the hardware module 803.  A computer readable medium having such software or computer program recorded on it is a computer program product.  The use of the computer program product in the computer preferably effects an advantageous apparatus for IP tunnelling.
The computer system 1800 is formed by the computer module 801, input devices such as a keyboard 1802 and mouse 1803, output devices including a display device 1814 and loudspeakers 1817.  A Modulator-Demodulator (Modem) transceiver device 1816 is used by the computer module 801 for communicating to and from the communications network 807, for example connectable via the telephone line 802 or other functional medium.  The modem 1816 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN), and may be incorporated into the computer module 801 in some implementations.
In the present example, the IP processing module 803 is connected to the computer 801 over a dedicated connection 802.  Alternately, the module 803 could be connected to the computer 801 over the network 807 when the IP processing module is implemented in devices such as network routers or network switches.
The computer module 801 typically includes at least one processor unit 1805, and a memory unit 1806, for example formed from semiconductor random access memory (RAM) and read only memory (ROM).  The module 801 also includes a number of input/output (I/O) interfaces including an audio-video interface 1807 that couples to the video display 1814 and the loudspeakers 1817, an I/O interface 1813 for the keyboard 1802 and the mouse 1803 and optionally a joystick (not illustrated), and an interface 1808 for the modem 1816 and for communicating with the IP processing module 803.  In some implementations, the modem 1816 may be incorporated within the computer module 801, for example within the interface 1808.  A storage device 1809 is provided and typically includes a hard disk drive 1810 and a floppy disk drive 1811 for receiving a floppy disk 1836.  A magnetic tape drive (not illustrated) may also be used.  A CD-ROM drive 1812 for receiving a CD-ROM 1835 is typically provided as a non-volatile source of data.  The components 1805 to 1813 of the computer module 801, typically communicate via an interconnected bus 1804 and in a manner which results in a conventional mode of operation of the computer system 1800 known to those in the relevant art.  Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom.  
Typically, the tunnelling application program 210 is resident on the hard disk drive 1810 and read and controlled in its execution by the processor 1805 (in the computer 801) and the processor 1831 (in the IP processing module 803).  Intermediate storage of the program 210 and any data fetched from the network 807 may be accomplished using the semiconductor memories 1806 and 1832, possibly in concert with the hard disk drive 1810.  In some instances, the tunnelling application program 210 may be supplied to the user encoded on the CD-ROM 1835 or the floppy disk 1836 and read via the corresponding drive 1812 or 1811, or alternatively may be read by the user from the network 807 via the modem device 1816.  Still further, the software can also be loaded into the computer system 1800 from other computer readable media.  
The term "computer readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 1800 and the IP module 803 for execution and/or processing.  Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 801 and the IP module 803.  Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.
Fig. 4B shows the IP hardware module 803 of Fig. 1 in more detail.  The IP hardware module 803 comprises the processor 1831, the memory 1832, and, if it is desired to load the tunnelling  application software via the IP module 803, a CD-ROM drive 1833 for receiving a CD-ROM (not shown) containing the tunnelling application software.  An I/O interface 1830 provides interaction, as depicted by the arrow 802, with the source computer 801 as shown in Fig. 1.
In the event that the IP hardware module 803 is, or forms part of an embedded computer system, then the tunnelling application software can be embedded in ROM within the memory 1832, and the CD-ROM drive 1833 would not be present.
Fig. 5 depicts, at 100, an IP packet 101 and the tunnel packet 105 that results from encapsulating the IP packet 101.  The IP packet 101 consists of an IP header 102, IP extension headers 103, and a payload 104.  After tunnelling, the new (tunnel) IP packet 105 is constructed.  The tunnel packet 105 has a new IP header 106, new IP extension headers 107, followed by a payload 102' + 103' + 104' which is a copy of the original IP packet 101.  The IP header 102' is a copy of the IP header 102.  The IP extension headers 103' are copies of the IP extension headers 103.  The payload 104' is a copy of the payload 104.  
In the tunnel packet 105, the new IP header 106 is referred to as an outer IP header.  The IP extension headers 107 are referred to as outer IP extension headers.  In contrast, the copy 102' of the original IP header 102 is referred to as an inner IP header.  Furthermore, the copies 103' of the original IP extension headers 103 are referred to as inner IP extension headers.  
As previously noted, the outer IP header 106 can typically be constructed by copying some fields from the inner IP header 102'.  However, construction of the outer IP extension headers 107 is more complex, since the outer IP extension headers 107 are not necessarily related to the original IP packet 101. 
Fig. 6 shows another instance 400 of packet encapsulation, where the tunnel packet includes an IPsec header.  The original IP packet 101 contains the IP header 102, and the payload 104.  It also contains, in the present example, the IP extension headers 103.  As a result of encapsulation, a new IP tunnel packet 401 is formed.  This packet 401 contains a new outer IP header 402, and a copy 102' of the original IP header 102, as well as a copy 103' of the original IP extension headers 103.  The new packet 401 also contains a copy 104' of the original payload 104.  The new packet 401 also contains an IPsec header 404, such as an authentication header, that is added as part of IPsec processing.  The new packet 401 also contains new (outer) IP extension headers 403 that are created from the IP extension header templates stored in the extension header memory region 304 (see Fig. 3) according to the disclosed IP tunneling approach.  When the IPsec processing includes the addition of an authentication header and tunnel mode, the IPsec header 404 in Fig. 4 is an authentication header that applies to the whole IP packet 401, including the new IP extension headers 403.  This will be explained in more detail in regard to Figs. 9 and 10.
Fig. 7 shows processes for generating pre-defined templates, and for using these templates to process IP packets according to the disclosed tunnelling technique.  Each of two illustrated processes 1100 and 1100' can be implemented as separate but inter-related process modules running on the computer 801 and the IP module 803.  The process 1100 relates to generation of (i) the Extension Header templates for storage in the memory region 304 and (ii) the Predicted Extension Header templates for storage in the memory region 305 (see Fig. 2) of the extension header template memory 205.  The process 1100' processes packets according to the disclosed tunnelling technique using the pre-defined templates generated by the process 1100.  
In a first step 1101 of the process 1100, either or both of the application software 202 and the tunnelling application software 210 generate Extension Header templates for storage in the memory region 304.  A following step 1113 generates the corresponding Predicted Extension Header templates for storage in the memory region 305.  In general, a single corresponding Predicted Extension Header template is generated in the step 1113 for each Extension Header template that is generated in the step 1101.  It is possible, however, to generate more than one corresponding Predicted Extension Header template for each Extension Header template.  A following step 1102, performed by the driver software 201, stores these templates in the memory regions 304 and 305 of the extension header template memory 205.  The process 1100 depicts an a-priori process for generation and storage of templates in the memory regions 304 and 305.  This is, however, only one example of how the extension header templates or any other templates usable by the disclosed technique can be generated. 
Thus, to consider an example of the process 1100, an Extension Header template referred to as 3041 incorporates a specific Type 0 routing option as described in relation to Figs. 15A-15B.  A corresponding Predicted Extension Header template referred to as 3051 incorporates predicted header fields derived from the header fields of the first Extension Header template 3041.  The aforementioned prediction operation is based upon authentication header requirements.  The Predicted Extension Header template 3051 thus enables an authentication header (eg. 903 in Fig. 15A), that is suitable for use with the Extension Header template 3041, to be determined at a later stage in the event that such an authentication header is required. 
Turning to the process 1100' in Fig. 7, a first step 1103, performed by the application software 202 and the driver software 201, receives and/or generates a packet A.  Thus, for example, the application software 202 can generate the packet A, or alternately, the packet A can be received from another software process (not shown) and provided to the driver software 201.  Thereafter, a decision step 1104, performed by the processor 303, determines whether IPsec or tunnelling processing is required.  This would be established by the security policy in the security policy database. If this is the case, then control passes according to a YES arrow to a step 1107.  
The step 1107, implemented by the IP hardware module 803 operates on the packet A to form a packet referred to respectively as A1(if only non-authentication IPsec processing is performed), A2 (if only tunnelling is required), A3 (if tunnelling and IPsec authentication processing is performed) or A4 (if only IPsec authentication processing is performed) using templates in the extension header template memory 205.  The packets A and A3 are, respectively, illustrated by packets 700 in Fig. 14 and 900/900' in Figs. 15A, 15B.  The transformation of the packet from the form A to the forms A1 or A2 or A3 or A4 will be described in more detail with reference to Fig. 9.  
Returning to Fig. 7, after the step 1107, a step 1105, performed by the IP hardware module 803, sends the packet A1 or A2 or A3 or A4 to the network 807 by means of which the packet is transmitted to the destination computer 809.  After the step 1105, control passes in accordance with an arrow 1106 back to the step 1103.  Returning to the testing step 1104, if neither IPsec nor tunnel processing are needed, then control passes according to a NO arrow to the step 1105. 
In summary, Fig. 7 depicts both generation of the pre-defined packet fields (ie templates stored in the memory regions 304, 305) in accordance with the process 1100, and the use of these templates, stored in the memory regions 304, 305, in IP packet processing according to the process 1100'.
Fig. 8 shows the process 1103 (see Fig. 7) by means of which packets such as A in Fig. 7 are generated.  Control passes, in accordance with the arrow 1106, from Fig. 7 to a first step 1501.  The process 1103 commences with the step 1501 which generates data for transmission.  The step 1501 is typically performed by the application software 202.  Thereafter, a step 1502, again performed by the application software 202, sends the aforementioned data to the driver software 201.  A following step 1503, that is performed by the driver software 201, sends the aforementioned data to the IP engine 203 in the hardware module 803.  Thereafter, a step 1504, performed by the IP engine 203, constructs the aforementioned data into the packet A.  A subsequent step 1505 passes the aforementioned packet A to the IPsec engine 204.  After the step 1505 control passes in accordance with the arrow 1112 back to the testing step 1104 in Fig. 7.  
Fig. 9 shows the process 1107 by means of which packets A in Fig. 7 are processed according to the disclosed tunnelling technique.
In IPsec processing, typically, IP datagrams are first checked against the Security Policy database 300.  Fields from the IP packet, such as source IP address, destination IP address, transport protocol (eg: Transmission Control Protocol (TCP), or User Datagram Protocol (UDP)), transport source address, and transport destination address are compared against selectors in Security Policies in the database 300.  Typically, each Security Policy is checked in turn, until a matching policy is found.  The Security Policy database 300 is typically set up by systems or network administrators, in order to enforce security policies on an individual, site, institution, or company basis.  If the matching policy indicates that IPsec processing is required before the IP datagram can be transmitted, the Security Association database 301 is searched.  The matching policy typically contains an index into the Security Association database 301, indicating the first Security Association to check.  Typically, subsequent Security Associations are linked from the first Security Association, in a linked list fashion. Each Security Association also has selectors, which are typically the same selectors used in the Security Policy database 300.  The selectors allow a finer-grain selection of a particular Security Association for an IP datagram. 
If no matching association can be found, then a new Security Association must be negotiated between the source and destination computer systems 801 and 809 respectively.  Typically this negotiation is done using key-exchange protocols such as Internet Key Exchange (IKE). Key generation and exchange is typically a complex procedure, and would most likely be handled by the software driver 201, possibly with some form of hardware acceleration (not shown) for computationally expensive operations.  Parameters that determine what type of Security Association must be negotiated (eg: cryptographic algorithm, key length, byte and/or time expiry limits) typically come from fields in the Security Policy.
Security Associations are typically dynamic in nature, since they do not generally survive equipment being turned off, and may also expire due to byte count restrictions, and/or time expiry.  If a Security Association expires, a new association must be negotiated as a replacement.  This would typically involve the generation of a new cryptographic key.  In contrast, Security Policies tend to be more static, since they usually reflect a site, company, or institutional policy with regard to security.
In addition to the selectors, Security Associations specify the details of the particular cryptographic operation to be performed.  Typical parameters used to specify the operation include AH/ESP, algorithm, key, initial value, sequence number, transport/tunnel mode, byte count, and time expiry.
The relationship between a Security Association and a header template, or header templates, is clearly advantageous.  When the Security Association is found, and it specifies that an Authentication Header is required, in tunnel mode, then the IPsec engine 204 may need to add an extension header (or headers) to the datagram before the cryptographic operation 1201 is performed.
In addition to the cryptographic parameters, the Security Association may store an index, or indices, to header template(s) in the header template memory 205.  Alternatively, the separate header index database 302 may be used to store indices into the header template memory.  In this latter case, the Security Association may contain a single index into the header index database 302, and the header index database 302 then contains the index, or indices, into the header template memory 205.
The values of these indices to header templates would typically be initialized by the software driver 201, as part of the creation process of a new Security Association.  The details of what headers are required, and the contents of those headers, would typically be defined as part of the site, company, or institution-wide policy on security.
The process 1107 in Fig. 9 commences with control passing from Fig. 7, in accordance with the arrow 1110 to thereby direct the process 1107 to the packet "A".  A testing step 1200 determines if IPsec processing that does not involve authentication is required for the packet A.  This would be established by the security association in the security association database. If this is the case, then control passes in accordance with a YES arrow to a step 1201.  The step 1201, performed by the IPsec engine 204, retrieves cryptographic parameters needed for the non-authentication IPsec processing and performs this processing to form from the packet A the packet A1.  Thereafter, control passes to a testing step 1202.  
The step 1202, performed by the processor 303 (see Fig. 3), based on information stored in the Security Association, determines if tunnelling is needed for the current packet being considered.  This would be established by the security association in the security association database.  If this is the case, then control passes in accordance with a YES arrow to a step 1207.  The step 1207, performed by the processor 303, retrieves an extension header index from the template index database 302.  The step 1207 then uses this index to obtain copies of corresponding Extension Header and predicted extension header templates from the extension header template memory 304 and the predicted extension header template memory 305 respectively.  Thereafter, a step 1208 inserts the copy of the retrieved extension header template into the packet A or A1 in order to thereby form a modified intermediate packet A2.  The step 1208 can also perform modifications to the predicted header template copy including replacement of a blank Sequence Number Field in an Authentication Header template with the current sequence number (one of the cryptographic parameters associated with the Security Association), and replacement of a blank Next Header field in a Type 0 Routing Header with the IP protocol number of the following header or transport protocol.
After the step 1208, control passes to a testing step 1209 which determines whether IPsec authentication is needed.  This would be established by the security association in the security association database.  If this is the case then control is passed according to a YES arrow to a step 1210.  The step 1210 retrieves authentication parameters from the security association database 301.  Thereafter a step 1213 performs authentication processing to determine the authentication field F (the Integrity Check Value (ICV)) and to thereby form the packet A3.  At least part of the authentication processing performed by the step 1213 is performed in relation to the predicted header template that was processed by the step 1208 as is described in more detail in regard to Fig. 11.  Subsequently, control passes in accordance with an arrow 1214 back to Fig. 7 in accordance with the arrow segment 1111.  Returning to the step 1209, if authentication is not required, then control passes according to the NO arrow back to Fig. 7 in accordance with the arrow segment 1111.
Although the process 1107 that has been described in relation to Fig. 9 uses the two steps 1207 and 1210 to respectively retrieve the extension header indices and the authentication parameters, these operations can, in an alternate arrangement, be more efficiently retrieved at the same time when performing the step 1207.
Returning to the step 1202, if tunnelling is not required, then control passes in accordance with a NO arrow to a step 1203 which determines whether IPsec authentication is needed.  This would be established by the security association in the security association database.  If this is the case then control is passed according to a YES arrow to a step 1204.  The step 1204, performed by the processor 303, retrieves the extension header index from the template index database 302 and uses this index to obtain an Extension Header template stored in the extension header template memory 304.  The step 1204 also retrieves authentication parameters from the security association database 301.  The step 1204 also possibly modifies the extension header but does not retrieve or process a predicted header in this instance. 
Examples of the modifications that can be performed to the extension header include replacement of a blank Authentication Data field in an Authentication Header with the Integrity Check Value of the authenticated datagram calculated by hardware included in the IPsec engine 204, replacement of a blank Sequence Number Field in an Authentication Header template with the current sequence number (one of the cryptographic parameters  associated with the Security Association), and replacement of a blank Next Header field in a Type 0 Routing Header with the IP protocol number of the following header or transport protocol.
Thereafter a step 1205 inserts the (modified) extension header into the packet A or A1 to form an intermediate packet, upon which the step 1205 then performs authentication processing to thereby form the packet A4.  Subsequently, control passes back to Fig. 7 in accordance with the arrow segment 1111.  Returning to the step 1203, if authentication is not required, then control passes according to the NO arrow back to Fig. 7 in accordance with the arrow segment 1111.
Fig. 10 shows the process 1113 in Fig. 7 for generating the Predicted Extension Header templates to be stored in the predicted extension header memory 305 in Fig. 3.  A first step 1800 stores a copy of the Extension Header template 3041 in a temporary memory (not shown).  Thereafter, a step 1801 modifies predictable fields of the Extension Header Template 3041 to thereby form an initial Predicted Extension Header template 3041A.  A subsequent step 1802 modifies unpredictable fields of the initial template 3041A to form the Predicted Extension Header template 3051 as referred to in relation to Fig. 7. The Extension Header template 3041 and the associated Predicted Extension Header template 3051 are respectively stored in the extension header memory 304 and the predicted extension header memory 305 in Fig. 3.
In performing the authentication algorithm on IPv4 packets, the following IPv4 options are considered to be "predictable fields" for the purposes of the process 1801 in Fig. 10, and are thus included in processing headers or parts of headers for the purposes of the authentication algorithm:
*  end of options
*  no operation
*  router alert
*  send a directed multi-destination delivery
The aforementioned predictable fields are used without modification, or in other words, for these options, the header Template and Predicted Header Template would be the same.
The following IPv4 options are considered to be "unpredictable fields" for the step 1802 of Fig. 10 and are replaced by zeros in the step 1802:
*  loose source route
*  time stamp
*  record route
*  strict source route
*  trace route
The following IPv6 extension header is replaced in the step 1801 by the predicted value at the destination:
*  Type 0 routing
Accordingly, in the described arrangement, every extension header template has a corresponding predicted extension header template, however these may differ or be identical, depending on the specifics.
It is further noted that IPv6 has two extension headers that consist of smaller entities called "options".  It is noted that these "options" are not the options referred to earlier in regard to the IP extension headers and/or options in the IPv4 packet header.  These "options-within-IPv6-extension-headers" contain a bit which indicates whether the option should be included in the authentication calculation, or replaced by zeros for that calculation.  The two such IPv6 extension headers with these options are:
*  hop by hop options
*  destination options
Fig. 11 shows the process 1213 (see Fig. 9) for performing packet authentication.  The process 1209 commences with control passing from Fig. 9 in accordance with the arrow 1216 to a step 1300.  The step 1300 substitutes the (modified) predicted extension header template copy for the extension header template copy in the packet A2 to form an intermediate packet.  The step 1300 then applies an authentication procedure to the intermediate packet to determine an authentication field F.  Thereafter, a step 1301 inserts the field F into the intermediate packet.  The step 1301 also substitutes the extension header template in the intermediate packet for the predicted extension header template thus forming the packet A3.  Thereafter, control passes in accordance with the arrow 1214 back to Fig. 9.  
Fig. 12 depicts data flow 500 between the hardware and software elements of Fig. 2.  In a step "3", the driver software 201 generates extension header templates and predicted extension header templates according to 1100 in Fig. 7, possibly using information from the application software 202 and the tunnelling application software 210.  In a following step "4" the driver software 201 stores the extension header templates in the memory region 304, and predicted extension header templates in the memory region 305, in the extension header template memory 205.  A subsequent step "1" depicts data being generated by the application software 202 for transmission.  A following step "2" depicts how the application software 202 transfers the aforementioned data to the driver software 201 which is capable of communicating with the IP hardware module 803.   Thereafter in a step "5", the driver software 201 sends the data generated by the application software 202 in the step "1" to the IP engine 203.  In a following step "6" the IP engine 203 constructs the data into an IP packet according to 1103 in Fig. 8 in order to encapsulate the data for transmission over the network 807.  
In a following step "7" the IP engine 203 passes the aforementioned packet to the processor 303 of the IPsec engine 204 for IPsec processing.  Thereafter, in a step "8", the IPsec engine 204 determines what IPsec processing, if any, is required.  This is determined by searching the Security Policy database 300 followed by searching the Security Association database 301. In a subsequent step "9" the IPsec engine retrieves an appropriate IP extension header template and predicted extension header template from the extension header template memory 205.  Such templates are required if IP tunnelling is required, and if IP extension headers are required after the IP outer header (this being the case for IPv6).  Alternately, in the IPv4 environment, templates are required if options are required in the IP header.  
The step "9" is performed using references to the extension header template memory 205 that will be retrieved in a manner to be described in relation to Fig. 13.  In a following step "10" the IPsec engine 204 inserts a copy of the IP extension header template into the IP packet, possibly modifying some parts of the IP extension header template before this insertion.  Thereafter, in a step "11", the IPsec engine 204 further processes the packet, possibly by generating an authentication header using the corresponding predicted extension header template.  In a subsequent step "12", the IPsec engine 204 returns the processed packet to the IP engine 203 for transmission.  Finally, in a step "13" the IP engine 203 transmits the packet over the network 807. 
Fig. 13 shows the data flow of Fig. 12 in more detail.  The data flow process commences with the step "7" in which the IP engine 203 passes the packet to the processor 303 of the IPsec engine 204 for IPsec processing.  Thereafter, in a step "8A" the IPsec engine 204 consults the security policy database 300 to determine what, if any, IPsec processing is required for the packet under consideration.  Thereafter, in a step "8B" the IPsec engine 204 retrieves the cryptographic parameters, (eg., keys, algorithms, etc) required to perform the IPsec processing from the security association database 301.  This presupposes that IPsec processing is required in accordance with the step "8A".  Thereafter, in a step "8C", the IPsec engine 204 retrieves references, which specify address locations of IP extension header templates and corresponding predicted extension header templates in the memory 205, and the order in which the template copies are to appear in the final packet, from the security association database 301.  This presupposes that tunnel mode processing is required in accordance with the step "8A".  Alternately, in a step "8C' ", the IPsec engine 204 retrieves the aforementioned references from the template index database 302.  
Upon receipt of the packet (alternately referred to as a datagram), the destination computer 809 first determines whether the datagram contains IPsec headers.  If no IPsec headers are present, a Security Policy database (not shown) is consulted in order to determine a dispensation for the datagram.  The dispensation may be either to accept the datagram, or to discard it.  If the datagram does contain IPsec headers, the appropriate IPsec processing steps are attempted.  Each IPsec processing step requires a corresponding Security Association in a Security Association database (not shown) of the destination computer 809.  If a corresponding Security Association is absent, the datagram is discarded.  In the case of the corresponding Security Association being present for an Authentication Header, the cryptographic parameters for that authentication calculation are retrieved from the Security Association, and used to calculate an Integrity Check Value (ICV) for the datagram.  Some fields in the datagram are excluded from the calculation, and the Authentication Data field in the Authentication Header (which contains the ICV) is one such field. If the calculated ICV matches the ICV in the datagram, and all other conditions for validity are met (eg: sequence number is valid, byte count is not exceeded, time expiry is not exceeded), the datagram is considered authenticated.
After all IPsec processing has been completed on the received datagram, the destination computer 809 consults the Security Policy database (not shown) in order to determine what IPsec processing was expected to be present in such a datagram.  If the required IPsec processing was present, the packet is accepted. Otherwise it is discarded.
Fig. 14 shows the IPv4 packet 700.  The IPv4 packet 700 consists of two parts, namely the IPv4 header 701, and the TCP payload 702.  In order to send to send this packet 700 over an IPv6 network such as 807 in Fig. 1, the IPv4 packet 700 can be tunnelled (ie., encapsulated).  This requires that an IPv6 header be added, in which case the IPv4 packet 700 is treated as the payload of the new IPv6 packet.  Furthermore, in the present example, it is desired to route the resultant IPv6 packet in a specified manner.  In order to do this, a "Type 0" routing extension header is incorporated.  Finally, for this particular example, it is desired to authenticate the IPv6 packet, and accordingly an "authentication header" is added before the payload.
Figs. 15A and 15B depict the IPv4 packet of Fig. 14 after encapsulation in an IPv6 tunnel packet including routing options and authentication.  The IPv6 packet in Figs. 15A and 15B is shown in two sections, these being referred to by reference numerals 900 (Fig. 15A) and 900' (Fig. 15B).  The IPv6 packet section 900 has a base header 901, an IPv6 Type 0 routing header 902, and an IPsec authentication header 903.  This particular example has three intermediate IPv6 addresses specified for the packet.  Accordingly, Fig. 15A shows a first IPv6 intermediate address 904, a second IPv6 intermediate address 905, a third IPv6 intermediate address 906, and a final IPv6 destination address 907.  In Fig. 15B the second segment 900' of the IPv6 packet comprises a copy of the original IPv4 packet 700 which has the IPv4 header 701' and the TCP payload 702'.
When the IPv6 packet (900 and 900') is transmitted across the network (such as 807), the packet is initially sent to a destination specified by the first intermediate address according to the field 904.  When the packet reaches this destination, the second intermediate address 905 in the IPv6 Type 0 routing header 902 is interchanged with the first IPv6 intermediate address 904 which is in the destination address field of the IPv6 base header 901.  Furthermore, the "segments left" field 908 is decremented.
Similarly, when the IPv6 packet arrives at the destination specified by the second intermediate address, according to the field 905, then the third intermediate address 906, which is in the IPv6 Type 0 routing header 902, is interchanged with the second intermediate address, which at this point is to be found in the destination address field of the IPv6 base header 901.  Furthermore, the "segments left" field 908 is again decremented.  Finally, when the IPv6 packet arrives at the destination specified by the third intermediate address, then the final destination address 907, which is in the IPv6 Type 0 routing header 902 is interchanged with the third intermediate address 906, which at this point is to be found in the destination address field 904 of the IPv6 base header 901.  Furthermore, the "segments left" field 908 is again decremented.
Thus, it is seen that the Type 0 routing header 902 changes as the IPv6 packet progresses towards its final destination through the network 807.  When the packet is received at the final destination, it is in the form shown in Figs. 16A and 16B.  Here the final IPv6 destination address is to be found in the IPv6 base header 1001.  Furthermore, the first, second and third intermediate addresses are to be found in the IPv6 Type 0 routing header 1002.  Finally, the "segments left" field has been decremented to a value of 0.  Figs. 16A and 16B thus show the tunnel packet of Figs. 15A and 15B upon arrival at the destination computer 809 of Fig. 1.
When the source computer system 801 calculates the authentication value for the IPv6 packet being sent from the computer 801, it must predict the value of the Type 0 routing header which will be received at the destination computer system 809.  Thus, when adding the Type 0 routing header to the originating IPv6 packet, the source computer system 801 uses the Type 0 routing header shown in Fig. 17 to create the IPv6 packet.  This is identical to 902 in Fig. 15A.  This is called the "Extension Header" stored in the memory region 304 in Fig. 3.  However, the Type 0 routing header shown in Fig. 18 is used to calculate the authentication value 903 for the IPv6 packet which is sent by the computer system 801.  This is called the "Predicted Extension Header" stored in the memory region 305 in Fig. 3.
Accordingly, both the routing header 1601 in Fig. 17 and the routing header 1701 in Fig. 18 are stored in the extension header template memory 205.  More particularly, the routing header 1601 is stored in the extension header memory partition 304 and the routing header 1701 is stored in the predicted extension header memory partition 305. 
Industrial Applicability
It is apparent from the above that the arrangements described are applicable to the computer and data processing industries.
The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 shows a block diagram of a system upon which the disclosed IP tunnelling approach can be practiced;
Fig. 2 shows functional elements for the source computer and IP processing module of Fig. 1;
Fig. 3 shows functional elements of the IPsec engine and the extension header template memory of Fig. 2;
Fig. 4A shows the general purpose computer of Fig. 1 in more detail;
Fig. 4B shows the IP hardware module of Fig. 1 in more detail;
Fig. 5 depicts an IP packet and the tunnel packet that results from encapsulating the IP packet; 
Fig. 6 shows another instance of packet encapsulation including an IPsec header;
Fig. 7 shows processes for generating pre-defined templates, and for using these templates to process IP packets; 
Fig. 8 shows how packets in Fig. 7 are generated;
Fig. 9 shows how packets in Fig. 7 are processed according to the disclosed tunnelling technique;
Fig. 10 shows a generic process for generating Predicted Extension Header templates in Fig. 7; 
Fig. 11 shows the process of Fig. 9 for performing packet authentication;
Fig. 12 depicts data flow between the hardware and software elements of Fig. 1;
Fig. 13 shows the data flow for the security policy database element of Fig. 12 in more detail; 
Fig. 14 shows an example of a IPv4 packet; 
Figs. 15A and 15B depict the IPv4 packet of Fig. 14 encapsulated in an exemplary IPv6 tunnel packet including routing options and authentication header;
Figs. 16A and 16B show the tunnel packet of Figs. 15A and 15B upon arrival at the destination computer of  Fig. 1;
Fig. 17 shows the (Type 0 Routing) extension header used to create the IPv6 tunnel packet of Figs. 15A and 15B; and
Fig. 18 shows the (Type 0 Routing) extension header used to calculate the authentication value for the aforementioned tunnel packet.
1.    A method of processing IP packets, the method comprising the steps of:
defining a plurality of sets of packet fields;
storing the sets of defined packet fields in a memory;
determining if a current IP packet is intended to be processed;
identifying the process to be applied to the current IP packet;
selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
2.    A method according to claim 1, wherein each said set of defined packet fields comprises an extension header.
3.    A method according to claim 2, wherein each said set of defined packet fields further comprises at least one predicted extension header associated with the extension header.
4.    A method according to claim 3, wherein a said predicted extension header is formed by:
modifying predictable fields of the extension header to form an initial predicted extension header; and
changing unpredictable fields of the initial predicted extension header to form the predicted extension header.
5.    A method according to claim 1, wherein the determining and identifying steps are performed with reference to a security policy for the IP packets, and the method further comprises creating a security association for the current IP packet, wherein the selecting and operating steps depend upon the security association.
6.    A method according to claim 2, wherein if the current IP packet is to be authenticated, then the operating step comprises the steps of:
acquiring a copy of the stored extension header;
incorporating the copy of the stored extension header into the current IP packet, to form an intermediate IP packet;
determining an authentication field of the intermediate IP packet; and
incorporating the authentication field into the intermediate IP packet to form the processed IP packet.
7.    A method according to claim 3, wherein, if the current IP packet is to be tunnelled and authenticated, then the operating step comprises the steps of:
acquiring a copy of the stored extension header and a copy of the stored predicted extension header;
constructing an intermediate IP packet using the copy of the stored predicted extension header;
determining an authentication field of the intermediate IP packet; and
incorporating the authentication field and the copy of the stored extension header into the current IP packet to form the processed IP packet. 
8.    An apparatus for processing IP packets, the apparatus comprising:
means for defining a plurality of sets of packet fields;
means for storing the sets of defined packet fields in a memory;
means for determining if a current IP packet is intended to be processed;
means for identifying the process to be applied to the current IP packet;
means for selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
means for operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
9.    An apparatus according to claim 8, wherein each said set of defined packet fields comprises an extension header and at least one predicted extension header associated with the extension header, said apparatus further comprising:
means for modifying predictable fields of the extension header to form an initial predicted extension header; and
means for changing unpredictable fields of the initial predicted extension header to form the predicted extension header.
10.    An apparatus according to claim 9, further comprising:
means wherein, (a) if the current IP packet is to be authenticated, then the means for operating comprise:
means for acquiring a copy of the stored extension header;
means for incorporating the copy of the stored extension header into the current IP packet, to form an intermediate IP packet;
means for determining an authentication field of the intermediate IP packet; and
means for incorporating the authentication field into the intermediate IP packet to form the processed IP packet; and 
(b) if the current IP packet is to be tunnelled and authenticated, then the means for operating comprise:
means for acquiring a copy of the stored extension header and a copy of the stored predicted extension header;
means for constructing an intermediate IP packet using the copy of the stored predicted extension header;
means for determining an authentication field of the intermediate IP packet; and
means for incorporating the authentication field and the copy of the stored extension header into the current IP packet to form the processed IP packet.
11.    A computer program product having a computer readable medium having a computer program recorded therein for directing a processor to process IP packets, said computer program comprising:
code for defining a plurality of sets of packet fields;
code for storing the sets of defined packet fields in a memory;
code for determining if a current IP packet is intended to be processed;
code for identifying the process to be applied to the current IP packet;
code for selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
code for operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
12.    A computer program product according to claim 11, wherein each said set of defined packet fields comprises an extension header and at least one predicted extension header associated with the extension header, said computer program further comprising:
code for modifying predictable fields of the extension header to form an initial predicted extension header; and
code for changing unpredictable fields of the initial predicted extension header to form the predicted extension header.
13.    A computer program product according to claim 12 further comprising:
code wherein, (a) if the current IP packet is to be authenticated, then the code for operating comprises:
code for acquiring a copy of the stored extension header;
code for incorporating the copy of the stored extension header into the current IP packet, to form an intermediate IP packet;
code for determining an authentication field of the intermediate IP packet; and
code for incorporating the authentication field into the intermediate IP packet to form the processed IP packet; and 
(b) if the current IP packet is to be tunnelled and authenticated, then the code for operating comprises:
code for acquiring a copy of the stored extension header and a copy of the stored predicted extension header;
code for constructing an intermediate IP packet using the copy of the stored predicted extension header;
code for determining an authentication field of the intermediate IP packet; and
code for incorporating the authentication field and the copy of the stored extension header into the current IP packet to form the processed IP packet.
14.    A computer program for directing a processor to process IP packets, said computer program comprising:
code for defining a plurality of sets of packet fields;
code for storing the sets of defined packet fields in a memory;
code for determining if a current IP packet is intended to be processed;
code for identifying the process to be applied to the current IP packet;
code for selecting, depending on an attribute of the identified process, at least one of the stored sets of defined packet fields; and
code for operating upon the current IP packet, using the at least one set of selected packet fields, to form a processed IP packet.
1  Abstract
A method and apparatus for processing IP packets is disclosed.  The method comprises defining sets of packet fields referred to as templates (in method steps 1101-1102), storing the templates in a memory, determining (in a step 1104) if a current IP packet is intended to be processed, identifying (in the step 1104) the process to be applied to the current IP packet, selecting, depending on an attribute of the identified process, at least one of the stored templates, and operating (in a step 1107) upon the current IP packet, using the templates, to form a processed IP packet.
2  Representative Drawing
Fig. 7
2005287034.tif 000024
2005287034.tif 000025
2005287034.tif 000026
2005287034.tif 000027
2005287034.tif 000028
2005287034.tif 000029
2005287034.tif 000030
2005287034.tif 000031
2005287034.tif 000032
2005287034.tif 000033
2005287034.tif 000034
2005287034.tif 000035
2005287034.tif 000036
2005287034.tif 000037
2005287034.tif 000038
2005287034.tif 000039
2005287034.tif 000040
2005287034.tif 000041
2005287034.tif 000042