JP4944845B2

JP4944845B2 - インターネットプロトコルのアドレス機構

Info

Publication number: JP4944845B2
Application number: JP2008175792A
Authority: JP
Inventors: ニカンデル、ペッカ
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2001-03-16
Filing date: 2008-07-04
Publication date: 2012-06-06
Anticipated expiration: 2022-02-15
Also published as: US7155500B2; DE10296445B4; WO2002076060A3; JP4302398B2; WO2002076060A2; DE10296445T5; US20020133607A1; JP2008271601A; GB0106559D0; JP2004533741A; AU2002232348A1; GB2367986B; GB2367986A

Description

本発明は、インターネットプロトコル（ＩＰ）のアドレス機構に関し、特に、ＩＰｖ６のアドレス機構に関するものである。

インターネットの利用が急速に高まってきたことにより、現状のインターネットプロトコルであるＩＰｖ４の弱点と限界が見えつつある。従って、インターネット技術特別調査委員会（ＩＥＴＦ）は、関連機関と緩やかな関係を保ちながら、ＩＰｖ６として知られる、拡張されたインターネットプロトコルを開発中である。特に、ＩＰｖ６は、より強化されたセキュリティー機構であるＩＰＳｅｃを組み込み、二つあるいはそれ以上の機関が、インターネットを介して安全に通信できるようにし、移動体でのインターネットアクセス（モバイルＩＰ）に対応できるものを目指している。モバイルＩＰによって、利用者は、一つのＩＰアクセスノードから他のノードへローミングしながら、移動中でもインターネットにアクセスすることができる。特に、モバイルＩＰは、（例えば、無線ＬＡＮと携帯電話ネットワークに接続された）無線移動機器を介してインターネットにアクセスする人たちによって用いられるものになる。

ＩＰｖ６は、１２８ビット長のＩＰアドレスを用いた、より広いＩＰアドレス空間を提供する。アドレスの前半の６４ビットは、ＩＰ端末あるいはホストによって用いられる（ローカルリンクと称される）インターネットアドレスノードを一意に識別するルーティング接頭部を形成し、一方、アドレスの後半の６４ビットは、アクセスノードにつながる（あるいはローカルリンク内の）移動端末を一意に識別するホスト接頭部を形成している。ホスト接頭部は、アクセスインターフェースを介して一意にホストを識別することから、“インターフェース識別子”と呼ばれる。通常、ホストがアクセスノードを登録した際には、アクセスノードから送られた同報メッセージによって、ホストはアクセスノードのルーティング接頭部を認識する。次に、ＲＦＣ３０４１（ＩＥＴＦ）に従い、ホストは、ホスト自身によって生成した乱数を用いて、そのインターフェース識別子を生成する。さらに、ホストは、リンク層アドレスを用いて、インターフェース識別子を生成するが、このリンク層アドレスは、例えば、アクセスネットワークによって用いられるＭＡＣ層アドレスである。

この方法が潜在的に抱える問題としては、同一のアクセスノードに接続された（必然的に同一のルーティング接頭部を持つ）２つのホストが、同一のインターフェース識別子を生成し、このために、同一のＩＰアドレスを生成してしまうというものがある。これは、許されるものではない。従って、ＩＰｖ６では、複製アドレス検出（ＤＡＤ）と呼ばれる機構が提供されている。一度、可能なＩＰアドレスをホストが生成すると、もしローカルリンクがローカルブロードキャストあるいはマルチキャストを行う場合には、ホストは、提案されたＩＰアドレスを含む、隣接ノードへの請求メッセージを、アクセスノードに対して送るか、あるいは、直接、ローカルリンクに送る。必要に応じて、アクセスノードは、このノードに接続した全ての他のホストに対して、同報メッセージを送る。もし、メッセージを受信したホストが、メッセージに含まれるＩＰアドレスを、すでに適用済みのアドレスであると認識した場合には、当該ホストは、請求元のホストに対して、隣接同報メッセージを送ることにより応答する。もし、請求元のホストが、所定の時間内に、隣接同報メッセージを受け取らない場合には、当該ホストは、生成されたアドレスを採用することになる。一方、もし、所定の時間内に、隣接同報メッセージが受信された場合には、請求元のホストは、新しいインターフェース識別子とＩＰアドレスを生成し、上記の請求処理を繰り返す。
前述の方法がもつ問題としては、多数の第三者にとって、隣接請求メッセージに対して、常に、隣接同報メッセージで応答することにより、請求元のノードを拒否することが比較的簡単にできてしまうということがあげられる。この種の攻撃は、“サービス拒否”攻撃と呼ばれる。

モバイルＩＰにＩＰｖ６を適用する際には、さらに他の問題がある。すでに説明したように、モバイルＩＰにより、ホストは、アクセスノードとアクセスネットワークの間でローミングが可能となるが、この特徴は、ホストの現在の物理的な位置を定義するＩＰアドレスを、ホスト自身が変更できるようにすることが必須となる。通常、移動ホストには、ホームネットワーク中での“固定”のホームＩＰアドレスが割当てられる。ホストがホームにある時には、ホストは、その物理アドレスとして、そのホームアドレスを用いることができる。しかし、ホストが、それ自身を“外部”アクセスノードに所属させる際には、そのホストには、一時的な気付アドレスが割当てられる。到着するパケットについては、対応するホストのモバイルＩＰ層は、気付アドレスと、宛先フィールド中のホームアドレスを交換し、一方、送出されるパケットについては、対応するホストのモバイルＩＰ層は、ホームアドレスと、宛先フィールド中の気付アドレスを交換する。モバイルホストが、新たな気付アドレスを取得した際には、全ての対応するホストに対し、それらの対応付け情報を更新するために、対応付けの更新メッセージを送る必要がある。

この機構がもつ潜在的なリスクとして、悪意をもつ第三者によって、偽造した対応付けの更新を対応するホストに送ることができてしまい、その結果、モバイルホストに向けられたデータパケットが、悪意をもつ者へ配送されてしまうというものがある。そして、もし悪意をもつ第三者により（その者によりパケットが開かれ読み出された後に）パケットがホストに転送されると、モバイルホストは、そのパケットが再配送され読まれたという事実を知ることさえ、不可能となる。この問題は、モバイルＩＰに限られたものではなく、ＩＰｖ６アーキテクチャ中の他の通信機能にも存在する問題である。このようなモバイルＩＰに関する問題および他の問題のいくつかについては、２００１年２月、ＩＥＴＦ提案“ｄｒａｆｔ−ｎｉｋａｎｄｅｒ−ｉｐｎｇ−ａｄｄｒｅｓｓ−ｏｗｎｅｒｓｈｉｐ−００．ｔｘｔ”に、より詳細に記載されている。
この問題についての解決策は、２００１年２月、ＩＥＴＦ提案“ｄｒａｆｔ−ｂｒａｄｎｅｒ−ｐｂｋ−ｆｒａｍｅ−００．ｔｘｔ”に提案されている。この解決策には、モバイルホストで、公開鍵と個人鍵からなる目的構築鍵（ＰＢＫ）の組を生成する処理が含まれている。エンドポイントＩＤは、ＩＰ接続を初期化した後、すぐに、接続関係にあるホストに送られる。続いて、モバイルホストは、接続関係にあるホストに、個人鍵を送り、接続関係にあるホストは、一方向性の符号化関数を鍵に適用し、以前受信したＥＩＤと比較することにより、公開鍵がこの接続に所属するものであることを確認することができる。続いて送られる対応付け更新は、モバイルホストで、ホストの個人鍵により署名される。接続関係にあるホストは、以前受信した公開鍵を用いた対応付け更新に付属した署名を確認する。

ＩＰｖ６に関して、これまで考察してきた２つの問題とは、すなわち、請求元ホストに近隣同報メッセージを送ることにより引き起こされるサービス攻撃が、拒否される可能性があるということと、対応付け更新の偽造による“中間位置にいる者”からの攻撃の可能性があるということである。同様の問題は、以下の状況でも生じる恐れがある。ＩＣＭＰルータ探索（ＲＦＣ２４６１、セクション６．１．２）、ＩＣＭＰリダイレクト（ＲＦＣ２４６１、セクション８．１）、共通トンネリング（ＲＦＣ２４７３）、ＩＰｓｅｃトンネリング（ＲＦＣ２４０１）、ルータ・リナンバリング（ＲＦＣ２８９４）、ＩＰｖ６ルーティング・ヘッダ（ＲＦＣ２４６０、セクション８．４）の状況、ならびに、条件によっては近接逆探査（ｄｒａｆｔ−ｉｅｔｆ−ｉｏｎ−ｉｐｖ６−ｉｎｄ−０５．ｔｘｔ）およびＳＣＴＰ（ＲＦＣ２９６０）の状況である。他の多くの提案と同様に、ＨＩＰ提案でも起こりうる可能性もある。これらの全ての問題は、ＩＰアドレスの所有者を検証できないという、共通の原因となる。
ブラッドナーの提案を考慮すると、ＰＢＫは、公開鍵をＩＰアドレスに対応付けるのではなく、ＥＩＤにのみ対応付けるものとなる。さらに、ＥＩＤとＩＰアドレスの間には、直接の対応付け関係はない。従って、ＰＢＫは、上記の問題を直接解決できるものではない。
本発明の目的は、上記の問題を解決することにある。特に、本発明の目的は、ＩＰアドレスの所有者を証明する手段を提供することである。本明細書では、ＩＰアドレスの所有権とは、アドレスの特定の範囲内で、ＩＰアドレスを用いる権限が所有者に与えられ、さらに、そのＩＰアドレスに適用されるルーティング情報を変更できる権限が所有者に与えられていることを意味している。

本発明の第一の特徴では、ＩＰネットワークに接続されたホストが、ホストが所有することを請求するＩＰアドレスを利用できる権限を有することを検証する方法が提供され、このＩＰアドレスは、ルーティング接頭部とインターフェース識別子を有しており、本方法は、ホストから一つあるいはそれ以上のコンポーネント（即ちデータコンポーネント）を受信するステップと、一方向性の符号化関数を、特定のあるいは各々のコンポーネント、もしくは、特定のあるいは各々のコンポーネントの派生物に適用するステップと、その結果あるいは結果の派生物をＩＰアドレスのインターフェース識別子と比較するステップとを含み、もし、その結果あるいは結果の派生物がインターフェース識別子と一致した場合には、ホストは、そのＩＰアドレスを利用する権限をもつものであると仮定され、一方、もし、その結果あるいは結果の派生物がインターフェース識別子と一致しない場合には、ホストは、そのＩＰアドレスを利用する権限をもたないものであると仮定される方法であることを特徴としている。
ホストは、コンポーネント、および／あるいは、コンポーネントの派生物を用いて、そのＩＰアドレスのインターフェース識別子を生成することができる。複数のコンポーネントが含まれる場合には、いくつかのコンポーネントと、他のコンポーネントの派生物との組み合わせに対し、一方向性の符号化関数を適用するものであってもよい。コネクションが継続している間、生成するホストは、これらのコンポーネントを保持し、必要に応じ、これらのコンポーネントを第三者に提供することができる。この第三者は、コンポーネントを利用して、インターフェース識別子を再構成し、ＩＰアドレスに関するホストの所有権を検証することができる。悪意のある第三者にとっては、逆符号化を行い、ＩＰアドレスからコンポーネントを復元することは困難であり、これにより、アドレスに関して真の所有権をもつかのようになりすますことは困難となる。

前記一方向性の符号化関数は、ＳＡＨ−１、ＭＤ５、あるいは他の既知の暗号化による一方向性の符号化関数であってよい。
本発明の実施例の利点は、公開鍵インフラ（ＰＫＩ）のように大掛かりなインフラを必要とせず、暗号化関数を新たな観点から適用することに基づくことにある。さらに、本発明の一部の実施例では、現在提案中のＩＰｖ６仕様に対して、アーキテクチャ上の変更を必要としないため、本発明は、先に考慮したブラッドナーの提案、すなわち、現在提案中のＩＰｖ６アーキテクチャに変更を必要とするものよりも有利なものとなる。
ＩＰネットワークは、インターネット、あるいは、企業のＬＡＮまたはＷＡＮなどの私設のＩＰネットワークを含むものであってよい。ＩＰネットワークは、インターネット、および／あるいは私設のＩＰネットワークに接続されたアクセスネットワークを含むものであってもよい。
好ましくは、前記コンポーネントは、前記ホストにより生成されたか第三者により前記ホストに対して発行された公開鍵、あるいは公開鍵の要約、あるいは、同一の長さをもつ固定（例えば、ゼロ）ビット系列、および、関連したハッシュ値の系列の一つであるハッシュ値を含んでいる。これに代わり、あるいはこれに加えて、前記コンポーネントは、ホストのリンク層アドレスに対応した、あるいはホストのリンク層アドレスから導出された初期インターフェース識別子、または、同一の長さをもつ固定（例えば、ゼロ）ビット系列を含んでいる。さらに好ましい構成としては、前記コンポーネントは、前記公開鍵あるいは公開鍵の前記要約、およびホストのリンク層アドレスに対応した、あるいはホストのリンク層アドレスから導出された初期インターフェース識別子、または、同一の長さをもつ固定（例えば、ゼロ）ビット系列を含んでいる。さらに好ましい構成としては、前記コンポーネントは、前記系列中の、受信したハッシュ値の位置を特定するカウンタ値を含んでいる。

好ましくは、前記ハッシュ値の系列は、ホストにおいて、種値、前記公開鍵あるいは公開鍵の前記要約、および初期インターフェース識別子に対して、一方向性の符号化関数を適用することにより求められる。これに代わり、前記ハッシュ値の系列は、ホストにおいて、前記種値、および前記公開鍵あるいは公開鍵の前記要約のいずれか、あるいは初期インターフェース識別子に対して、一方向性の符号化関数を適用することにより求められる。受信されたハッシュ値から求められ、前記値を生成するために用いられるハッシュ値は、系列中の最後の値である。最初のＩＰアドレス検証のタイミングで、ホストから受信されたハッシュ値は、系列中で、最後のハッシュ値よりも先にあるハッシュ値である。その後の各々の検証処理では、一つ前のハッシュ値を次々に受信する必要がある。
好ましくは、本方法は、ハッシュ系列の最後の値を求めるステップと、一つあるいはそれ以上の数の他のコンポーネントが連結された最後のハッシュ値に、一方向性の符号化関数を適用するステップとを含んでいる。その結果については、最後の結果とインターフェース識別子とを比較する前に、さらに処理が施されるものであってよい。
本発明の第二の特徴では、ホストにおいてＩＰアドレスを生成する方法が提供され、ＩＰアドレスは、ルーティング接頭部およびインターフェース識別子を含み、本方法は、一つあるいはそれ以上の数のコンポーネントに対して、一方向性の符号化関数を適用することにより、インターフェース識別子を生成するステップを含んでいる。
好ましくは、前記コンポーネントは、乱数からハッシュ値を用いるなんらかの方法によって生成される、ハッシュ値を含んでいる。より好ましくは、乱数の組み合わせと初期インターフェース識別子、または、前記公開鍵あるいは公開鍵の前記要約、または、前記初期インターフェース識別子と前記公開鍵あるいは公開鍵の前記要約との組み合わせの、いずれかの組み合わせに対して、一方向性の符号化関数を適用することにより、ハッシュ値が生成される。

本発明の第三の特徴では、新たなホストがネットワークに接続された際に、ＩＰネットワークでのＩＰアドレスの複製を防ぐ方法が提供され、本方法は、下記のステップを含んでいる。
一方向性の符号化関数を用いて、一つのコンポーネント、または複数のコンポーネント、および／または、一つのコンポーネントあるいは複数のコンポーネントの派生物を組み合わせることによって、新しいホストにおいて、インターフェース識別子を生成し、その結果、または、その結果の派生物を前記インターフェース識別子として用いるステップであって、前記インターフェース識別子は、前記ＩＰアドレスの一部を形成することを特徴とするステップと、
新しいホストから、アクセスネットワークにすでに接続されている他のホストに対して、近隣請求メッセージを送るステップと、
新しいホストで、他の各ホストから、前記ＩＰアドレスを所有することを請求する近隣同報メッセージを受信するステップであって、その近隣同報メッセージあるいは各々の近隣同報メッセージは前記コンポーネントあるいは複数のコンポーネントを含むことを特徴とするステップと、
受信した各々の近隣同報メッセージに対して、
前記符号化関数を用いて、コンポーネントあるいは複数のコンポーネント、および／または、コンポーネントあるいは複数のコンポーネントの派生物を組み合わせるステップと、
その結果、またはその結果の派生物を、ＩＰアドレスのインターフェース識別子と比較するステップであって、もしその結果あるいはその派生物がそのインターフェース識別子と一致する場合には、そこから近隣同報メッセージを受け取ったとされるホストを、ＩＰアドレスを用いる権限をもつものと仮定され、一方、もし、その結果あるいはその派生物がインターフェース識別子と一致しない場合には、そのホストは、そのＩＰアドレスを利用する権限をもたないものであると仮定されることを特徴とするステップ。

好ましくは、前記コンポーネントあるいは複数のコンポーネントは、公開鍵あるいは公開鍵の要約、またはそれらの派生物を含む。これにより、新たに加わったホストは、公開鍵を認識し、近隣同報メッセージを送信するこのホストが、そのＩＰアドレスを生成するためにこの公開鍵を利用したものであると確実に仮定することができ、これにより、新しく加わったホストは、そのＩＰアドレスを利用する権限を得るために、他のホストは、各々対応した個人鍵を所有しなければならないものであると仮定することができる。
好ましくは、上記の仮定のもとに、新たに加わったホストは、なんらかの既知の認証プロトコル、あるいは（ゼロ知識プロトコルなどの）他の公開鍵暗号化によるプロトコルを用いて、現状で、他のホストが必要とする個人鍵を所有していることを検証することができる。好ましくは、（検証）プロトコルが適切に動作していることにより、他のホストは、そのＩＰアドレスを利用する権限をもつものであると仮定することができ、前記プロトコルが適切に動作しない場合には、他のホストは、このＩＰアドレスを利用する権限がないものと仮定することができる。
本発明の第四の特徴では、ＩＰネットワークに接続されたホストが、そのホストが所有することを請求しているＩＰアドレスを利用する権限をもつものであり、そのホストが、そのアドレスに対して送られたデータパケットを受信できることを検証する方法が提供され、本方法は、以下のステップを含んでいる。

本発明の上記第一の特徴における方法を実行し、前記ホストがIPアドレスを利用する権限をもつことを検証するステップと、
接続要求のための宛先アドレスとして前記ＩＰアドレスを用いて、ホストへの接続要求を発行するステップと、
ホストからの応答を受信するステップと、
受信した応答が、接続要求に対する正当な応答であることを検証するステップ。
好ましくは、前記接続要求は、乱数を含んでいる。よリ好ましくは、前記接続要求は、乱数を連結した前記ＩＰアドレスを含んでいる。より好ましくは、前記応答は、前記乱数を連結した前記ＩＰアドレスに対して、一方向性の符号化関数を適用することにより、構成される。

本発明の第五の特徴では、ＩＰネットワークを介し、第一ホストから第二ホストに対して送信される公開鍵を認証する方法が提供され、本方法は、以下のステップを含んでいる。
前記第一ホストにおいて、前記公開鍵を用いてインターフェース識別子を生成し、このインターフェース識別子をルーティング接頭部と組み合わせて、第一ホストのためのＩＰアドレスを形成するステップと、
前記ＩＰネットワーク上の第一ノードから第二ノードに対して、前記公開鍵を送るステップと、
前記第二ノードにおいて、前記公開鍵が前記インターフェース識別子を生成するために用いられる鍵であることを検証するステップ。
本発明の第六の特徴では、ＩＰアドレスを公開鍵に対応付ける方法が提供され、ここでＩＰアドレスは、ルーティング接頭部とインターフェース識別子を含んでおり、本方法は以下のステップを含んでいる。
符号化関数を用いて、一つあるいはそれ以上の数のコンポーネント、および／あるいはそのコンポーネントの派生物を組み合わせることにより、前記インターフェース識別子を生成するステップと、
公開鍵と個人鍵の組の中の個人鍵で署名された証明書を生成するステップであって、この証明書は、インターフェース識別子と、前記コンポーネントまたは前記派生物あるいは他の派生物のいくつかを含み、ホストの公開鍵を用いて証明書が認証できるように、また、証明書の内容を用いて該インターフェース識別子を再構築し、その結果と真のインターフェース識別子とを比較することにより、インターフェース識別子の所有権が検証されるようになっていることを特徴とするステップ。

（実施例の詳細な説明）
図１は、インターネット通信手順を示すものであり、ここでは、複数の利用者端末あるいはホスト１から４が、インターネット５に接続されている。ホスト１から３は、アクセスネットワーク７のアクセスノード６を介して、インターネット５に接続されている。ホスト４は、図には示していないアクセスネットワークによって接続されている。
ホスト１の一つが、アクセスネットワーク７に新たに接続しようとするものであり、このホストに関して、アクセスネットワークは外部ネットワークである（よって、アクセスノード６は外部エージェントである）と仮定する。ホスト１は、外部エージェントからルータ同報メッセージを受信することにより、この仮定した状態を認識する。（このメッセージは、外部エージェントにより定期的に配信されるメッセージや、ホスト１から外部エージェントに対して送られるルータ請求メッセージに応じて、ホスト１に送信されるものであってよい）ホスト１は、ルータ同報メッセージによって、インターネット中で、この外部エージェントを一意に識別するルーティング接頭部を認識する。次に、ホスト１は、そのホームネットワーク９のホームエージェント８に対して、外部エージェント６を介して、対応付け更新メッセージを送り、ホームエージェントに対して、その新しい位置を伝える。ホームエージェントは、ホスト１に対して、外部エージェント６を介して対応付け認知メッセージを送ることにより、応答する。すでに上述したように、ホスト１は、ルーティング接頭部とインターフェース識別子を組み合わせて、ＩＰアドレスを形成している。

以下、インターフェース識別子を生成するための新しい方法について説明する。本方法は、以下の利点をもっている。
・リンク層アドレスへの、インターフェース識別子の対応付け
・公開鍵への、インターフェース識別子の対応付け
・複製アドレス検出の際に、サービス拒否攻撃を阻止する手段の提供
・遠隔から“アドレス所有権”を探索する手段の提供

インターフェース識別子の一般的な説明
ここで説明する方法は、暗号化の面で、強力な一方向性の符号化関数にもとづくものである。一方向性の符号化関数は、ＨＡＳＨ（．．．）と表すものとし、ここでは、特定の一方向性の符号化関数として、ＳＨＡ−１を用いることとする。（しかし、これに代わり、他のものを用いることも可能である）一般的な記法として、インターフェース識別子を生成する本方法は、以下のように定義される。
interface identifier : =HASH(component1 | component2 | component3)
ここで、“．．．｜．．．”は、連結を表し、コンポーネントの一つは、新たに生成された（“新”）乱数であり、他のコンポーネントは、インターフェース識別子を生成するノード（または、ホスト）が、インターフェース識別子を対応付けようとする情報である。
与えられたインターフェース識別子に関しては、そのインターフェース識別子の値にハッシングする複数のコンポーネントを計算により求めることは困難である。インターフェース識別子は、６４ビットの長さをもつため、この場合、その６３ビットが有用となり、この複数のコンポーネントを求めるためには、平均すると、２の６３乗の半分、すなわち２の６２乗の回数分の処理を必要とする。現在の処理装置によれば、このデータ長のハッシュ値を逆転することも可能ではあるが、実用上は、この処理には数百年を要するものとなる。ランダムなインターフェース識別子は、比較的短い寿命、多くの場合は日のオーダーの寿命をもつものと仮定できるため、この仮定は、リスクを生じる上では無視しうるものである。将来の計算機の処理能力の向上（１８ヶ月で倍増）を考慮しても、このリスクが顕在化するまでには、幾年もかかることになる。悪意をもつノードは、ＮＳパケットを受信するごとに、コンポーネントを計算するのではなく、あらかめじ計算しておいた値をキャッシュしておくことを選択するかもしれない。しかし、この処理に必要となる記憶領域は、禁止されているものである。

本方法のセキュリティは、インターフェース識別子の生成元以外の他者は、要求に応じて迅速、容易には、コンポーネントの値を提供できないという前提にもとづいている。もちろん、単一のコンポーネントのみを用いて、インターフェース識別子を生成することにより、ある程度のセキュリティーのレベルを得ることも可能である。しかし、複数のコンポーネントを用いることにより、後で述べるような、他の利点を得ることができる。
インターフェース識別子を生成する本方法により得られる利点を最大限活用するために、ネットワークに接続する全てのノードは、ある“合意”に従う必要がある。この合意は、多くの事項を取り決めるものになる。まず初めに、この合意は、インターフェース識別子を生成する方法を限定する。次の合意は、もし、ノードが、インターフェース識別子を生成するために用いられるコンポーネントを提供できるならば、そのノードは、これらのコンポーネントを提供できないノードに比べて、より確実にそのインターフェース識別子を“所有”できるものであると規定するものである。さらに、三番目の合意は、コンポーネントの構造的、意味的な条件を規定するものであり、すなわち、コンポーネントの一つは、乱数であり、他のコンポーネントは恣意的なものであることを規定するものである。

インターフェース識別子のリンク層アドレスへの対応付け
基本的なＩＥＴＦ文書（ＲＦＣ２３７３）に基づくと、リンク層アドレスを直接利用して、インターフェース識別子が生成される。この構成方法は、可逆であり、リンク層アドレスとインターフェース識別子が各々に対応し合ったものであることを確認することができる。すなわち、所定のインターフェース識別子に関して、誰もが、対応するリンク層アドレスを生成でき、その逆も可能となっているということである。これは、ローカルリンクの内部では、有用である。しかし、別のＩＥＴＦ文書（ＲＦＣ３０４１）に基づくと、リンク層アドレスがローカルリンクの外部に送出されて、ホストの秘匿性がリスクに晒されないように、このリンクは破壊されるものになっている。インターフェース識別子を生成するためにリンク層アドレスを用いるが、実際には、この情報は用いられることはない。すなわち、新しいインターフェース識別子を生成するために用いられる乱数は、外部に発行されることもなく、いかなる方法によっても利用されることはない。従って、所定のインターフェース識別子からリンク層を推察することや、まして、（リンク層アドレスによって識別された）あるノードが、所定のインターフェイスを実際に生成したことを知ることはできない。

ここで説明する方法は、リンク層アドレスとインターフェース識別子との間のリンクを、部分的に、再構成するものである。すでに説明したように、インターフェース識別子は、いくつかのコンポーネントから生成され、それらのコンポーネントの（少なくとも）一つは、生成するノードに対してのみ初期段階で既知のものとなっている。他のコンポーネントは、リンク層アドレスである。インターフェース識別子を所有することを請求しているノードは、インターフェース識別子を生成するために用いられたコンポーネントを公開した（必然的にそうした）時に、この公開されたコンポーネントを認識した他のノードは、自動的に、これらのコンポーネントの中から、リンク層アドレスを選び出すことになる。コンポーネントが、インターフェース識別子へのハッシングを実際に行ったことを確認することにより、インターフェース識別子の生成者が、所定のリンク層アドレスを用いようとしたことを確証することができる。
インターフェース識別子をリンク層アドレスに対応付けるためには、次式によって、インターフェース識別子を生成することが十分となる。
interface identifier : = HASH(random | link layer address)
ここで、“ｒａｎｄｏｍ”とは、新しい乱数であり、“ｌｉｎｋｌａｙｅｒａｄｄｒｅｓｓ”とは、生成元のノードが利用しようとするリンク層アドレスである。

インターフェース識別子の公開鍵への対応付け
従来から、ＩＰアドレスを公開鍵（あるいは、他のセキュリティ関係の情報）に対応付けられないことは、ＩＰｖ６に関するいくつかの通信機構のセキュリティに関する重大な問題であった。例えば、他のノードに、特定のアドレスに関して、ルーティング情報の変更を通知しようとするノードは、そのＩＰアドレスを“所有”することを示す必要がある。
このような認証に関する、３つの可能な解決策について検討した。一番目は、認証を局所的に構成することである。これは、単一の管理者のもとにある、小規模から中規模のネットワークでうまく動作する。二番目は、ＩＰアドレスの所有権の証明を提供するための、広域のインフラの一種を使う場合である。セキュア・リバースＤＮＳなどの、特定の目的のＰＫＩは、このサービスを提供するものである。しかし、実際に、このようなサービスを実現することは極めて困難である。三番目は、相互の合意に基づいて、認証を行うというものである。これは、いわゆるＡＡＡアプローチと呼ばれ、ＩＥＴＦのＡＡＡワーキンググループによって推奨されている。しかし、このようなシステムは、そのサービス範囲が広がるにつれて、漸近的にグローバルなインフラの形態に近いものとなり、数的な拡張性を確保し、信頼性を維持するという面で問題になる。すなわち、これらの３つの方法のいずれもが、拡張性の面で制限を受けることとなる。

ここで提案する四番目の方法は、暗号を用いて、ＩＰｖ６アドレスのＩＰｖ６インターフェース識別子は、暗号化のための重要情報をもつには十分な長さを持っているという事実を活用する。その基本的な考え方は、インターフェース識別子と公開鍵との間の暗号に関する重要なリンクを提供するインターフェース識別子を、コンポーネントベースで生成するということである。すなわち、インターフェース識別子を生成する際に用いられるコンポーネントの一つが、公開鍵（あるいは、公開鍵のハッシュ、すなわち、公開鍵の暗号化の要約あるいは“指紋”）である。リンク層アドレスの場合と同様に、コンポーネントを公開することにより、インターフェース識別子の生成者は、特定の公開鍵を利用したいことを請求することを、ノードが提供するものとなる。従って、インターフェース識別子と、それを生成する元になったコンポーネントのみが与えられると、インターフェース識別子の現状の利用者が、所定の暗号化鍵を実際に利用したい状態にあるということを、他のノードが確証することができる。逆の命題、すなわち、公開鍵の利用者が、所定のインターフェース識別子を利用したい状況にあるということは、その鍵によって、インターフェース識別子に署名することにより与えられる。これらの特徴を与えるために、インターフェース識別子は、以下により定義し、
interface identifier := HASH (random | public key)
署名を以下のように行う、
certificate/signed message :={interface identifier | public key} _{ｐｒｉｖａｔｅｋｅｙ}

ここで、“．．．｜．．．”は、連結を表し、“｛…｝_Ｋ”は、鍵Ｋで署名されたメッセージを表し、“random”は、新しい乱数であり、public keyは、公開鍵あるいはその暗号化されたハッシュであり、“private key”は、対応する個人鍵である。より保証を加えるために、以下のように、署名されたメッセージの中に乱数を含めることができる。
certificate/signed message : ={interface identifier | random | public key} _{ｐｒｉｖａｔｅｋｅｙ}

完全なインターフェース識別子の生成手順
本発明とその応用をさらに説明する目的のために、以下、詳細に、実施方法を提案する。この提案では、インターフェース識別子を生成するために、リンク層アドレスと公開鍵を利用する。
ここでは、以下の演算子を利用する。
．．．｜．．．は、連結を表す。
｛…｝_Ｋは、鍵Ｋで署名されたメッセージを表す。
［…］_Ｋは、鍵Ｋで暗号化されたメッセージを表す。

１． II_０を、ホストのリンク層アドレスにもどつき、［ＲＦＣ２３７３］ＡｐｐｅｎｄｉｘＡで規定された通りに生成された、６４ビットの初期インターフェース値とする。もしこのような値がない場合には、II_０を、６４ビットのゼロとする。
２．オプションとして、認証された第三者から、鍵の組＜Ｋ＋，Ｋ−＞を生成もしくは取得する。ここで、Ｋ＋は、公開鍵であり、Ｋ−は、それに対応した個人鍵である。
３．公開鍵の要約を計算により求め、＃Ｋ＋：＝ＨＡＳＨ（Ｋ＋）とする。もし公開鍵を用いない場合には、＃Ｋ＋は、同一の長さのゼロ値とする。
４．初期乱数値Ｈ_Ｎを生成し、ここで、Ｎは、次のステップで生成される系列の長さである。
５．ハッシュ値の系列、Ｈ_Ｎ，．．．，Ｈ_ｉ，．．．，Ｈ_０を生成する。ここでは、Ｈ_ｉ−１：＝ＨＡＳＨ（Ｈ_ｉ｜II_０｜＃Ｋ＋）であり、Ｈ_０が得られるまで、関数をＮ回適用する。
６．ＲＦＣ３０４１準拠のインターフェース識別子生成アルゴリズムのためのＨの来歴の種値を、ハッシュ系列の最終値、すなわち、Ｈ：＝Ｈ_０とする。
７．ＲＦＣ３０４１のセクション３．２．１に規定された通りに、（小修正を施しながら）以下の処理を続ける。
・連結Ｈ｜II_０’を求める。ここで、Ｈは、ステップ６で生成した、来歴の種値であり、II_０’は、６４ビットのゼロ値である。＊）注記あり
・ II’＝ＭＤ５（Ｈ｜II_０’）を求める。
・ＭＤ５要約のII’の最左側の６４ビットをとり、ビット６をゼロにする。この結果が、インターフェース識別子IIとなる。
・もし、より多くの試みが必要になる場合には、（すなわち、認証の重複などの理由がある場合）ハッシュ系列の最終値を棄却して、これにより、Ｎを一つ繰り下げ、Ｎ：＝Ｎ−１とし、上記のステップ６以降を繰り返す。この手順は、ＭＤ５関数を単に一度だけ適用する［ＲＦＣ３０４１］とは異なる。

８．もし、ステップ２で、オプションの公開鍵値が、生成されるか得られた場合には、インターフェース識別子を含む自己署名された証明書と、公開鍵の要約と、ハッシュ系列中の複数の値と、ハッシュ系列の最後の値と、ホストのリンク層アドレスを生成し、以下を求める。
ＣＥＲＴ：＝｛II，＃Ｋ＋，Ｎ，Ｈ_０｝_Ｋ−
もし、公開鍵を用いない場合には、ＣＥＲＴを別に用いるところでは、常に、Ｎｕｌｌ値を用いる必要がある。
＊）II_０’をII_０とする代わりに、ゼロとする理由は、２つある。一つ目の理由は、II_０は、Ｈ_Ｎ，．．．，Ｈ_ｉ，．．．，Ｈ_０の系列の生成に含まれていて、これにより、ＲＦＣ３０４１で論じられているように、悪い乱数生成を引き起こす可能性を考慮しなければならないということである。さらに、Ｈ_ｉで所有権を証明することは、またII_０を必要とし、以下に論じるように、この所有権をリンク層アドレスに局所的にリンク付けてしまう可能性が残されている。二つ目の理由は、IIの計算からII_０を切り離すことによって、遠隔ノードに対して、最初にＨを公開できるだけになることである。遠隔リンクを介して、II_０を公開してしまうことは、ＲＦＣ３０４１の秘匿性を守るという目的を実質的に阻害することになり、望ましいことではない。

ここで説明した方法では、インターフェース識別子の所有権は、基本的には、生成されたハッシュ系列に基づくものであり、要求に応じて、ハッシュ系列から以前の値を取り出すことに依っている。この要求は、頻度が低い（攻撃が発生しない限り、実質的には存在しない）ため、多くのホストに対しては十分なように思われる。しかし、暗号化鍵に対して、インターフェース識別子を強力に対応付けるように、また、インターフェース識別子に対しても、その鍵を対応付けるように、この方法は設計されている。さらに、この方法は、インターフェース識別子の生成に対し、リンク層アドレスを強力に対応付けるものとなっている。この理由を、以下に記す。
ハッシュ系列Ｈ_Ｎ，．．．，Ｈ_ｉ，．．．，Ｈ_０が構成される際には、各ステップにおいて、リンク層アドレスと公開鍵のハッシュの両方が用いられる。このことは、実際には、インターフェース識別子を用いる際には、ホストが、特定の公開鍵と特定のリンク層アドレスを利用したいという状況であることを示している。局所的には、これにより、ノードは、“間違った”リンク層アドレスのノードのインターフェース識別子を用いて他のノードから送られてくるパケットを無視できることになる。リンク層アドレスの変更が、特別の特権やハードウェア動作を必要とするような環境では、この状況は、セキュリティの向上に、なんらかの寄与を及ぼすものとなる。
公開鍵を含めることは、より意味のある効果をもたらす。このことは、特に、他のホストが、公開鍵を認識し、これらのホストが、持つべきインターフェース識別子の所有権を、確実に仮定できるようになることを意味している。すなわち、インターフェース識別子の生成処理の過程で、特定の公開鍵のハッシュを用いることにより、そのノードは、その特定のインターフェース識別子に、鍵を“所有”させようとしていることを強力に示すものとなる。これと逆の方向となる処理は、自己署名された証明書によって表され、基本的に、鍵の所有者が、インターフェース識別子を“所有”したいことを示すものとなる。これら２つのものは、ともに、インターフェース識別子と公開鍵の間の、暗号化について強力な双方向性の対応付けを生み出している。実際には、初期の段階で近接請求メッセージを用いて、ホストが、この情報を公開しようとして、請求された近接同報（メッセージ）の中にこの情報を言い換えることは、有用なものになると考えられる。この目的のために、近接請求（ＮＳ）メッセージおよび近接同報（ＮＡ）メッセージは、以下の情報を含むものであってよい。

−公開鍵、Ｋ＋自身
−自己署名された証明書、ＣＥＲＴ
−オプションとして、初期インターフェース識別子、II_０
しかし、リンク層アドレスを検証する以外の目的に対しては、これは必要ではなく、インターフェース識別子の所有権が検証されないならば、この検証は、行われない可能性が高い。Ｋ＋とＣＥＲＴを含めることにより、受信するホストは、鍵Ｋ＋の所有者が、請求されたインターフェース識別子を利用したい状況にあることを検証できるものとなる。
本方法を用いて生成されたインターフェース識別子は、多くの利用先があり、それらの一部を詳細に説明する。

ＤＡＤの際のサービス拒否の防止
アドレスの再構成の間、新しく生成されたインターフェース識別子は、既に存在するインターフェース識別子との間で衝突を起こす可能性がある。この状況は、他のノードがすでに識別子を“所有”していることを表す、近接同報パケットを受信することにより示される。ＲＦＣ３０４１では、このような衝突を解消する方法として、ＭＤ５を用いて、次のインターフェース識別子を計算により求め、最大５回までこれを試みるという方法がある。残念なことに、この方法は、すべてのインターフェース識別子を所有することを単に要求しているような悪意をもつノードに対しては、適用できない。

ハッシュに基づくＤｏＳ防止
悪意をもつノードに対して、インターフェース識別子を“所有”しようと要求することを防止するために、以下のようにＤＡＤプロトコルを拡張することが提案されている。
ａ）全ての近接請求（ＮＳ）パケットは、以下の形式をもっている。
＜ＴＡ，Ｃ，Ｋ＋，ＣＥＲＴ＞
ここで、ＴＡは暫定的なアドレス、Ｃは乱数、Ｋ＋は応答するノードの公開鍵、およびＣＥＲＴは、上記のステップ８で生成された証明書である。（接続要求として用いられる）乱数と証明書は、厳密に言うと必要となるものではないが、オーバーヘッドもほどんどなく、セキュリティを少しばかり向上させる効果がある。
ｂ）ＮＡ取り消しメッセージは、ＤＡＤの一部として送られ、以下の形式をもつものである。
＜ＴＡ，ＴＬＬＡ，ｉ，Ｈ_ｉ，＃Ｋ＋，Ｒ＞
ここで、ＴＡは、その所有権についてＮＡが要求しているアドレスであり、ＴＴＬＡは、ターゲットのリンク層アドレスであり、［ＲＦＣ２３７３］ＡｐｐｅｎｄｉｘＡで規定されるようにＴＴＬＡからII_０が計算される、また、ｉは、使用されたハッシュ値のカウンタ値であり（最初のＮＡの衝突について、ｉは１と定義され）、Ｈ_ｉは、ハッシュ系列中のｉ番目のハッシュであり、＃Ｋ＋は、公開鍵の要約（あるいは、公開鍵の暗号が用いられない場合には、１２８ビットのゼロ値）であり、Ｒは、ＭＤ５（Ｈ_ｉ｜Ｃ）である。これらの値を発行することにより、応答ノードは、それがインターフェース識別子を“所有”するものであることを示すものとなる。さらに、応答ノードがインターフェース識別子を生成した際に、オプションの公開鍵の組が、応答ノードによって生成あるいは取得された場合には、このメッセージには、以下の形式をもつ、公開鍵と署名が含まれるものとなる。
＜ＴＡ，ＴＬＬＡ，ｉ，Ｈ_ｉ，＃Ｋ＋，Ｒ，Ｋ＋，ＳＩＧＮ＞

ここで、Ｋ＋は、上記のステップ２で生成された公開鍵であり、ＳＩＧＮは、Ｋ−を用いて生成された、ＩＰヘッダを含む、パケット全体に対する署名である。
ＮＡを送出するホストが、インターフェース識別子を実際に所有することを検証するために、受信ホストは、以下の処理を実行する。
１．ｉ回だけ、Ｈ_ｉ−１：＝ＨＡＳＨ（Ｈ_ｉ｜II_０｜＃Ｋ＋）を計算し、Ｈ_０を計算により求める。
２．Ｈ＝Ｈ_０とする。
３． II’＝ＭＤ５（Ｈ｜II_０’）を計算により求める。ここで、II_０’は、６４ビットのゼロ値である。
４． II’と、０ｘＤＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦのビット毎のＡＮＤを計算し、II とする。これにより、基本的に、II’のビット６がクリアされ、IIが得られる。
５．ＴＡ＝０ｘｆｅ８０００００００００００００｜IIであることをチェックする。ここで、０ｘｆｅ８０００００００００００００は、ＩＰｖ６リンクローカルアドレスの接頭部である。
６．Ｒ＝ＭＤ５（Ｈ_ｉ｜Ｃ）であることをチェックする。
さらに、もし、ＮＡが、オプションの署名を含むならば、受信ホストで以下を計算する。
７．＃Ｋ＋＝ＨＡＳＨ（Ｋ＋）であることをチェックする。
８．Ｋ＋を用いて、受信したパケットについて、ＳＩＧＮが、有効な署名であることをチェックする。
例えば、ｉ＝１の場合、ＮＡは、
＜ＴＡ，ＴＬＬＡ，１，Ｈ_１，＃Ｋ＋，ＴＩＭＥ，Ｋ＋，ＳＩＧＮ＞
を含み、計算は下記のようになる。

１．Ｈ_０：＝ＨＡＳＨ（Ｈ_１｜II_０｜＃Ｋ＋）
２．Ｈ：＝Ｈ_０
３．II’：＝ＭＤ５（Ｈ｜６４ビットのゼロ）
４．II：＝II’と、０ｘＤＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦのビット毎のＡＮＤ
５．ＴＡ＝０ｘｆｅ８０００００００００００００｜IIのチェック
６．Ｒ＝ＭＤ５（Ｈ_ｉ｜Ｃ）のチェック
７．＃Ｋ＋＝ＨＡＳＨ（Ｋ＋）のチェック
８．ＳＩＧＮが、受信したパケットについて有効な署名であることのチェック
もし、全てのチェックに合格した場合には、請求元ノードは、請求者が実際にインターフェース識別子を所有し、それが新しいインターフェース識別子を生成することになることを仮定してもよいものとなる。
しかし、この状態では、再び攻撃が発生する可能性が残っている。新しいノードがインターフェース識別子を生成した際に、そのインターフェース識別子を所有することを請求する代わりに、攻撃側は、そのノードがインターフェース識別子を確立できるようにし、その時に限り、動作できるようにする。そのノードが、一度、インターフェース識別子に関する所有権を確立すると、攻撃側は、インターフェース識別子を要求するＮＳを送出する。このプロトコルによれば、正しい所有者は、これまで秘密とされた値Ｈ_１を公開することにより、反撃しなければならず、これにより、攻撃側を最初にブロックする。しかし、次に、攻撃側は、Ｈ_１を公開したＨＡを単純に再現することにより、再度、インターフェース識別子を所有することを要求する。正しい所有者は、ハッシュ系列中の以前の値Ｈ_ｉを公開することにより、この繰り返し攻撃を防護する。このように、この問題を解決するものとして知られている唯一の方法は、Ｈ_ｉの長さに依存して、２の（ｉ＊（（Ｈ_ｉの長さ）−１））乗のオーダーの処理数に及ぶ、力ずくのやりかたである。さらに、２つ以上のＨ_ｉの値を、局所的に公開することが必要となる場合でも、攻撃の試みを示す良い方法となる。
本方法は、図２のフローチャートで詳細に示されている。

ＰＫベースのＤｏＳの防止
繰り返し攻撃の問題を解決する他の方法としては、公開された、強力に対応付けられたコンポーネントの一つを利用するというものがある。すなわち、２つのノードが、同一の公開されたコンポーネントを提供することにより、所定のインターフェース識別子を“所有”することを要求している際には、一つのノードのみが、それらのコンポーネントの一つを“所有”しているということを示せるだけであり、特定のコンポーネントが、この衝突を解決するために用いられる。ここでは、解決に用いられるコンポーネントは、公開鍵である。従って、もし２者が、同一のコンポーネントを示すことにより、同一のインターフェース識別子を所有することを要求するならば（あるいは、それらのコンポーネントが、すでに公開済みであるならば）、請求者のうちの一方が、そのインターフェース識別子に対応付けられた公開鍵に対応した個人鍵を利用する能力があることを示すによって、この衝突は解決される。
公開鍵の暗号化の方法には、いくつかの種類がある。これには、ＲＳＡなどの従来の公開鍵暗号化、ＤＳＡなどの公開鍵署名アルゴリズム、およびゼロ知識プロトコルが含まれている。インターフェース識別子に関する所有権を証明する目的のために、これらの方法のいずれかを用いることができる。すなわち、暗号化された要約によって公開鍵を表現することが可能となり、請求者が実際に個人鍵にアクセスする証拠をタイムリーに提供できることが可能となるということだけが、求められている。このように、タイムリーに証拠を提供する通常の方法は、認証プロトコルを実行することである。

リンク層アドレスに基づくＤｏＳの防止
用いられるリンク層通信の特徴に依存して、リンク層アドレスを用いて、衝突を解消する（そして、繰り返し攻撃に対処する）ことも可能になり、これは、局所的に、インターフェース識別子の所有権を検証する唯一の手段としても用いられる。すなわち、もし、利用される通信媒体が、安全で確実なリンク層アドレスを持っているならば、すでに説明したように、リンク層アドレスをインターフェース識別子に対応づける能力が十分あるものとなり、これにより、正当なインターフェース識別子のみを用いることが確かなものとなる。

インターフェース識別子のルーティング可能なアドレスへの拡張
ここまでは、インターフェース識別子についてのみ説明してきた。しかし、［ＲＦＣ３０４１］に規定されているように、ランダムに生成されたインターフェース識別子は、局所的に一意であることが仮定されるのみである。すなわち、グローバルなインターネット環境では、互いに衝突し合うインターフェース識別子が生じる可能性があり、むしろ、おおむね発生すると言ってもよいものである。（“誕生日のパラドックス”によれば、２の（６３／２）乗あるいは３０億通りのインターフェースがある場合には、このような衝突が起こる可能性は、約５０％である）従って、衝突は、（拡張された）複製アドレス検出の手順での一意性を求めることにより、局所的なものには許すことができないが、これらの衝突は、非局所での場合に容認される必要がある。従って、非局所での場合には、インターフェース識別子によってのみ認証を行うことは賢明とはいえない。

接続要求／応答
パケットベースの通信の基本的な問題は、ソースアドレスを容易になりすますことができてしまうことにある。すなわち、グローバル浸入フィルタを用いない場合には、ソースアドレスが妥当性をもっていないところでパケットを簡単に送ることができるということである。基本的なセキュリティのレベルは、パケットで指定されたソースアドレスへの逆接続要求を送り、応答を待つことにより達成される。パケットの送り元は、そのアドレスに送られたパケットを受信できる場合にのみ、適切に応答することができる。この方法は、よく知られた方法であり、例えば、いくつかのプロトコルにおける、いわゆるクッキー機構で用いられている。
インターフェース識別子の所有権を証明するための、基本的な、ハッシングのみに基づく方法は、単純なコンポーネントの開示による接続要求／応答手法と、より複雑なコンポーネントの開示の繰り返し手法とを組み合わせている。（これらの手法の両者ともに、上記で説明済みである）さらに、この組み合わせは、所有権を検証するものは大量の計算を必要としないように行うものとなっている。少ない処理量であるため、計算機資源を極端に消費するサービス拒否攻撃を起こすことを防止できる。

この基本的な考え方は、要求元が、まず、インターフェース識別子を含んだチェックされるべきアドレスと、インターフェース識別子がつくられる元になるコンポーネントを送る。これは、プロトコル中の最初のメッセージとなる。検証機能は、コンポーネントをチェックし、要求元も、インターフェース識別子自身を生成したことを確認するか、それが起源となるノードからの物であることを確証する。しかし、このプロトコルは、たいていの場合、この最初の組のコンポーネントを認識した多くのノードが存在するものの、後に使われる、その次の組のコンポーネントを認識するノードの数は、かなり少なくなるように設計されている。
検証機能が、インターフェース識別子とコンポーネントをチェックすると、それは、検証されるアドレスに接続要求を送る。原則的に、この接続要求は、単純な乱数である。しかし、ここでは、この乱数は、検証されるべきインターフェース識別子とコンポーネントと組み合わされ、これにより、同一の乱数を繰り返し使用することが可能となる。この接続要求は、プロトコル中の第二のメッセージとなる。要求元が、この接続要求を受け取ると、それは応答を生成する。この応答は、プロトコルの第三と最終のメッセージを形成する。応答を生成する際には、２つの可能なオプションが存在する。
ａ）請求者は、インターフェース識別子と、それが、第一のメッセージ中にすでに開示したものと同一の組のコンポーネントを使用し、
interface identifier : = HASH (components)
これらのインターフェース識別子とコンポーネントを送る。（なぜなら、これらは、検証機能によっては、保持されていないためである）
ｂ）応答を生成する際には、請求者は、インターフェース識別子と、以前のコンポーネントの組、すなわち、第一のメッセージ中にすでに開示したコンポーネントを生成するときにしようしたコンポーネントの組を使用し、
interface identifier : = HASH (components1)
components1 : = HASH (components2)
インターフェース識別子とコンポーネント２（ｃｏｍｐｏｎｅｎｔｓ２）を送る。

これらの手法は、両方とも、各々の利点と欠点を持っている。手法ａ）の主な利点は、コンポーネントの第二の組は、公開する必要がなく、その結果、後で利用するために、これらを“保存”しておくことができることである。しかし、その欠点は、コンポーネントの第一の組を知っている者であれば、その応答が生成できてしまうところにある。それに対し、手法ｂ）では、コンポーネントの第二の組を用いることにより、そのコンポーネントの組を公開情報とできる。従って、それらが一度でも利用された後には、コンポーネントの第一の組を認識することができた任意のホストは、コンポーネントの第二の組を認識した可能性が高くなるということになる。従って、セキュリティの面ではほとんど強化されていないことになる。
ここでは、第一の手法ａ）が好ましく、同一の組のコンポーネントを、第一と最後のメッセージで用いる。この方法は、以下を保証するものである。
−請求者は、検証すべきアドレスに送られたメッセージを、受け取ることができる。この特徴は、単純な接続要求／応答のプロトコルによって実現できる。
−請求者は、インターフェース識別子が生成する元になったコンポーネントの組を、それ自身で生成しているか、それらのコンポーネントをなんらかの方法で認識している。このように、（基本的な要求接続と応答に比べて）セキュリティのレベルを向上させるためには、コンポーネントを知る（あるいは認識する）必要がある。不幸にも、コンポーネントを認識することは、それほど困難なことではない。幸運なことは、ここで説明したプロトコルでは、コンポーネントは、保護の第一層としてのみ働き、実際の所有権は、公開鍵の暗号化のみによって証明されるということである。

攻撃する者は、少なくとも３つの異なる方法で、コンポーネントを認識する。攻撃する者は、コンポーネントを生成したノードと同一のローカルリンク上にあるものであるため、あるいは、攻撃する者は、コンポーネントを生成したノードと他の遠隔ノードとの間のトラフィックを盗聴することができるため、あるいは、攻撃する者は、このプロトコルを実行することにより起源となるノードからコンポーネントを認識したものであるため、攻撃する者はコンポーネントを認識することができる。
もし、攻撃する者が、コンポーネントを生成したノードと同一のローカルリンク上にあるものであるために、コンポーネントを認識できた場合には、インターフェース識別子を利用することは困難であるということが分かる。その場合、コンポーネントの起源となる生成元が、インターフェース識別子の所有者となっていると考えられる。もし、起源ノードが、他のローカルリンクに移動したり、あるいは、攻撃する者が、他のローカルリンクに移動した場合には、この状況は、盗聴または検証プロトコルを実行することによって、攻撃する者が、コンポーネントを認識した場合と同様となる。
他の場合では、攻撃する者と、コンポーネントの実際の生成元は、異なるリンク上に存在する。従って、これらは、異なるルーティング接頭部を持つものとなる。ここでは、起源ノードと攻撃する者は、異なるルーティング可能アドレスを持つため、起源ノードと同一のインターフェース識別子を用いる攻撃する者は、攻撃する者として扱うことはできない。本セクションで説明したように、攻撃する者は、基本的な接続要求／応答プロトコルを実行するが、その実行によって、攻撃する者を助けるようなことにはならず、また助けてはならない。
本方法は、図３のフローチャートで詳細に示されている。

接続要求／応答と公開鍵に基づく認証の組み合わせ
ローカルの場合に重要な問題になるのは、インターフェース識別子の一意性である。既に述べたように、グローバルの場合には、インターフェース識別子は、一意である必要はなく、一般的に一意とはなっていない。従って、その一意性の保証や証明を試みる意味はない。同様に、リンク層アドレスも、グローバルの場合には、関係のないものとなる。それに代えて、公開鍵とインターフェース識別子とを互いに強力に対応付けることができることが極めて重要となる。しかし、署名の生成や署名の検証といった、公開鍵の処理は、計算機処理上では高価なものであるため、ここでは、一方向性の符号化関数を最初に用いて、攻撃を困難にするための“前線バリア”とし、その後で、公開鍵機能を用いることが、好ましい方法となる。公開鍵を直接利用することは、計算機資源を極端に消費するサービス拒否攻撃を引き起こす可能性をもっている。
公開鍵に基づく方法では、先ず始めに、請求者が、検証すべきアドレスと、インターフェース識別子と、インターフェース識別子を生成する元となるコンポーネントを含むパケットを送る。しかし、検証機能は、状態を生成したり、そうでない場合には、この第一のメッセージをかつて受信したことを記憶していることは求められていないため、これらのコンポーネントは、請求者の公開鍵に関するなんらかの情報を含むものではない。検証機能は、以前と同じように、接続要求を生成する。しかし、接続要求に加え、請求者に対して、追加情報として、その公開鍵も送る。この場合、公開鍵は、自己署名証明書として送付するのが最良となる。検証機能は、この証明書をすでに入手していて、それを送ることは、メッセージに追加することのみを要求するようになっていることが望ましい。
次のステップは、要求されるものに依って、いくつかのオプションを含んでいる。もし、検証機能が、その公開鍵を提供していた場合には、請求者はそれを使うことができる。いずれの場合でも、請求者は、それ自身の個人鍵を用いて、接続要求に対応する必要があり、効率的に多層の応答を生成することができる。すなわち、請求者は、接続要求を受信しそれに応答することが実際に可能であることを示す。攻撃する者は、虚偽の応答メッセージを送り、検証機能にとって、メッセージの処理には多大な計算機資源を消費するものとなるため、検証機能にとっては、これを検証することが処理の面から“安価”である必要がある。

次に、さらに高度なセキュリティレベルが、公開鍵を用いて形成される。ここでは、検証機能は、インターフェース識別子と公開鍵の間の対応付けが、実際に存在することをチェックできることが、まず必要となる。しかし、公開鍵に関する情報が検証機能に届けられると、それを用いる方法についてはいくつかの標準的なオプションが存在する。
以上を要約すると、本方法は、以下のセキュリティ保護の“層”を持っていることになる。
０．１検証機能は、請求者が、インターフェース識別子に対応したコンポーネントの組を認識していることを、極めて安価に、接続要求を送る前でさえ、検証することができる。
０．２検証機能は、状態に関する情報を格納する必要がなく、安価に、接続要求を構築することができる。
１．１検証機能は、請求者が接続要求を受信できたことを、安価に検証することができる。
１．２検証機能は、第一のメッセージで用いられた同一の組のコンポーネントをまだ知っていることを、安価に検証することができる。
２．１検証機能は、請求者によって与えられた公開鍵が、実際に、インターフェース識別子を生成する際に用いられた複数のコンポーネントの一つであることを、安価に検証することができる。
２．２検証機能は、請求者が公開鍵に対応した個人鍵を所有していることを、（費用をかけて）検証することができる。

プロトコルの詳細な説明
アリスとボブの間での機構を説明する。ここでは、ボブがアリスに対して、ボブがＩＰアドレスＴＡを“所有”していることを証明しようとしている。以下の、３メッセージプロトコルを用いる。さらに、ボブが、どのようにアドレスを生成するかを特定するために、０−ステップが必要となる。
０．上記で概説した方法を用い、ボブは新しいＩＰアドレスＴＡを生成する。
１．ボブは、ボブがアドレスＴＡを所有していることをアリスに証明しようとする。これを行うために、ボブは、以下を含むメッセージをアリスに送る。
ＭＳＧ１＝＜ＴＡ，Ｈ_０，＃Ｋ＋，Ｎ＞
ここで、
・ＴＡは、ルーティング接頭部ＲＰとインターフェース識別子IIから成り立ち、その所有権をボブが証明しようとしているＩＰアドレスであり、
・Ｈ_０は、IIを生成する際に、Ｈ_０であり、
・＃Ｋ＋は、Ｈ_０を生成する際に、ボブが用いた公開鍵のハッシュ値であり、
・Ｎは、ボブがアリスから受信することを期待している返信を特定するために、ボブが用いる（一回限りの）乱数である。Ｎは、任意の数でよいため、もしボブが乱数を用いたくなければ、ボブは任意の数、例えば、ゼロを指定してもよい。

２．アリスはパケットを受信し、接続要求を送る。
２．１アリスは、以下をチェックする。
interface_identifier(TA)=MD5(H_０|64-bit zero) bitwiseand 0xDFFFFFFFFFFFFFFF.
これは、ボブが、Ｈ_０の正しい値を知っていることを証明することである。これが可能なのは、ボブは、それを彼自身が作り出していたから、または、盗聴によってや、前もってこれと同一のプロトコルを実行することによって、それを知りえていたことのいずれかの理由があるためである。これは、インターフェース識別子の所有権の証明する上での弱さとして、すでに説明したとおりである。
２．２アリスは、以下の接続要求を生成する。
Ｃ：＝ＭＤ５（Ｐ｜Ｈ_０｜＃Ｋ＋｜Ｎ｜ＴＡ）
ここで、Ｐは、（一回限りの）乱数である。この単一の乱数は、幾度かの接続要求のために用いられるため、アリスが、状態を作り出す必要はない。
２．３アリスは、アドレスＴＡにパケットを送る。そのパケットは、接続要求Ｃを含んでいる。ここでは、ボブはＴＡを介して到達可能であることをチェックするために、このメッセージはアドレスＴＡに送られることに注目したい。オプションとして、パケットは、アリスが自己署名した証明書、ＣＥＲＴ_Ａ＝｛II_Ａ，＃Ｋ_Ａ＋，Ｎ_Ａ，Ｈ_Ａ，０｝Ｋ_Ａ−を含むものであってもよい。
ＭＳＧ２＝＜Ｎ，Ｃ＞またはＭＳＧ２＝＜Ｎ，Ｃ，Ｋ_Ａ＋，ＣＥＲＴ_Ａ＞

３．ボブは、接続要求を受信し、応答を返す。
３．１オプションとして、ボブは、Ｎをチェックして、接続要求が、彼の初期パケットに対応して実際に送られたものかどうかを確認する。
３．２ボブは応答を計算する
Ｒ：＝ＭＤ５（Ｃ｜ＴＡ｜Ｈ_０｜＃Ｋ＋｜Ｎ）
３．３オプションとして、ボブは、アリスの公開鍵Ｋ_Ａ＋を取り出し、ＣＥＲＴ_Ａをチェックする。
最初に、ボブが以下を検証する。
・アリスがＭＳＧ２を送信する際に、ＩＰヘッダ中のソースＩＰアドレスとしてアリスが用いた、インターフェース識別子に対して、II_Ａが一致すること
・II_Ａが、ＭＤ５（Ｈ_０｜６４ビットのゼロ）と０ｘＤＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦとのビット毎の論理積と等しいこと
・＃Ｋ_Ａ＋が、ＨＡＳＨ（Ｋ_Ａ＋）と等しいこと
・ＣＥＲＴ_Ａが、＃Ｋ_Ａ＋を含むこと
・ＣＥＲＴ_Ａが、有効に署名されたこと
もし、この検証の結果、正しくないことが判明した場合には、ボブは、オプション部のＫ_Ａ＋とＣＥＲＴ_Ａは、まったく受信しなかったかのようにして、処理を続ける。

３．４もし、ボブが、アリスの公開鍵を受信し、ステップ３．３の検証の結果が正しいものであった場合には、ボブは、ボブとアリスとの間で共有すべき秘密鍵を準備する。
・秘密の対称な鍵Ｋ_ＡＢを生成し、アリスとボブの間で共有するものとする
・アリスの公開鍵を用いて、新しく生成された鍵Ｋ_ＡＢと、ボブがＨ_０を生成する際に用いたII_０と、ボブがＨ_０を生成する際に用いたＨ_１とを含むメッセージを暗号化する。これは、秘密の部分Ｓであり、アリスだけが開くことができるものとなる。
Ｓ：＝［II_０，Ｋ_ＡＢ，Ｈ_１］_ＫＡ＋
もし、Ｓが生成されない場合には、空のストリングで代用する。
３．５ボブは、応答Ｒを含むパケットを、アリスに送る。さらに、このメッセージは、ＭＳＧ１が含むのと同一のＴＡ、Ｈ_０、＃Ｋ＋およびＮを含まなければならない。
ＭＳＧ３＝＜ＴＡ，Ｈ_０，＃Ｋ＋，Ｎ，Ｒ，Ｓ＞
オプションとして、メッセージは、ボブの個人鍵Ｋ＋と、ボブの証明書ＣＥＲＴと署名ＳＩＧＮも含んでよい。
ＭＳＧ３＝＜ＴＡ，Ｈ_０，＃Ｋ＋，Ｎ，Ｒ，Ｓ，Ｋ＋，ＣＥＲＴ，ＳＩＧＮ＞
署名ＳＩＧＮは、メッセージの残りの部分に対する署名であり、ボブの個人鍵Ｋ−を用いて生成される。

４．アリスは、応答を受信し、それをチェックする。
４．１アリスは、いかなる状態も保持していないため、アリスは、まず、インターフェース識別子がＨ_０に関して有効であることを、再度チェックする。
interface_identifier(TA)=MD5(H_０|64-bit zero) bitwiseand 0xDFFFFFFFFFFFFFFF.
もし、これが成立しない場合には、アリスは、このパケットを単に棄却する。
４．２Ｐを知って、アリスは、受信したメッセージからの情報を用いて、Ｃを再計算し、
Ｃ’：＝ＭＤ５（Ｐ｜Ｈ_０｜＃Ｋ＋｜Ｎ｜ＴＡ）
応答Ｒが期待通りの値を持っていることをチェックする。
Ｒ＝ＭＤ５（Ｃ’｜ＴＡ｜Ｈ_０｜＃Ｋ＋｜Ｎ）

もし、この検証結果、正しくないことが判明した場合には、アリスは、ボブの請求は無効であると仮定する。一方、有効な請求であることは、ボブがＴＡに送られたパケットを受信できることを証明することになる。
４．３もし、メッセージが、オプション部、すなわち、ボブの公開鍵Ｋ＋、ボブの証明書ＣＥＲＴ、および対応する署名ＳＩＧＮを含んでいる場合には、アリスは、以下をチェックする。
・ＣＥＲＴの中のIIが、ＴＡのインターフェース識別子と一致すること
・＃Ｋ＋が、ＨＡＳＨ（Ｋ＋）と等しいこと
・ＣＥＲＴが、＃Ｋ＋を含むこと
・ＣＥＲＴが、有効に署名されたこと
・署名ＳＩＧＮが有効であること
これは、鍵Ｋ＋の所有者が、アドレスＴＡを使いたい状況にあること、また、ボブがＫ−を知っていることから鍵Ｋ＋をボブが所有していることを、証明するものである。
４．４もしメッセージが秘密の部分Ｓを含んでいる場合には、アリスは、アリスの個人鍵Ｋ_Ａ−を用いてＳを暗号解読し、II_Ａと、Ｋ_ＡＢとＨ_１を取り出す。
アリスは、以下をチェックする。
II＝ＭＤ５（ＨＡＳＨ（Ｈ_１｜II_０｜＃Ｋ＋））
これにより、IIの生成元が、その要約が＃Ｋ＋である公開鍵を利用したい状況にあり、II_０と一致するリンク層アドレスを持つ状況にあることが証明される。これにより、IIからＫ＋までと、Ｋ＋からIIに戻るループが閉じる。II_０が解読により得られるという事実は、メッセージが暗号化されているため、通常は問題にはならない。

もし、オプションのステップ４．３を含む、全てのプロトコルが検証が成功すると、ボブは現状でＴＡに到達可能であり、Ｋ＋はボブがＴＡを生成するのに用いた公開鍵であるということを、アリスは知ることとなる。さらに、アリスは、ボブのリンク層アドレスはII_０であることを知るが、アリスは、その情報については関知しない。
以上を要約すると、ここで提示した手法の利点は下記のようになる。
−［ＲＦＣ２３７３］で規定されるが［ＲＦＣ３０４１］では破棄されるような、リンク層アドレスとインターフェース識別子との間の強力な対応付けが、部分的に再構築され、［ＲＦＣ３０４１］のプライバシー保護の目的に適うものになる。
−新しい対応付けは、インターフェース識別子から公開鍵に対して、生成される。
−ＩＰｖ６の自動構成［ＲＦＣ２４６２］の間に、サービス拒否攻撃を阻止する手段が、複製アドレス検出（ＤＡＤ）手順に付け加えられる。
−局所的なルーティング情報を修正する目的のためにインターフェース識別子を“探索”する手段が、例えば、ＩＰｖ６対応付け更新など、必要に応じて提供される。
本手法の主要な特徴を以下に示す。
−一方向性の関数をコンポーネントに適用し、ＩＰｖ６アドレスのインターフェース識別子を形成し、コンポーネントの少なくとも一つを最初に秘密とすることにより、後にこれらのコンポーネントを公開して、インターフェース識別子の所有権の証明に活用することができる。
−一方向性の関数を、コンポーネントに複数回適用することにより、攻撃する者が以前公開されたコンポーネントを利用した攻撃を行うものに対する、セキュリティの保護を提供することが提案されている。
−一方向性の関数をコンポーネントに適用し、ＩＰｖ６アドレスのインターフェース識別子を形成し、これらのコンポーネントに、意味的な情報を付与し、これらのコンポーネントを公開することにより、インターフェース識別子を、インターフェース識別子の利用者のために意味的に重要なコンポーネントの値を表す暗号化トークンとして動作させることができる。

−特に、リンク層アドレスは、意味的に重要なコンポーネントとして用いられるものの一つである。リンク層アドレスを含ませることのセキュリティ上の意義は、ローカルリンクの物理的な実装に依存するものとなる。
−特に、公開鍵、または公開鍵のメッセージ要約は、意味的に重要なコンポーネントとして用いられるものの一つである。潜在的に、公開鍵、または公開鍵のメッセージ要約は、鍵とＩＰｖ６アドレスが、ＰＫＩやＡＡＡインフラのような外部のインフラを必要とせずに、リンクできるようにするものであるため、これは極めて大きなセキュリティ上の重要性を持つものである。
−公開鍵をインターフェース識別子に対応付ける能力を用いて到達性をチェックする既知の接続要求・応答方法を組み合わせることにより、インターネット上で、特定のインターフェース識別子を制御しようと請求する者が、実際に、高い確率で、その制御が可能となっていることをチェックすることが可能となる。
−コンポーネントからインターフェース識別子を繰り返し生成することを組み合わせることにより、検証機能が、計算機資源を極端に消費するサービス拒否に対する、なんらかの保護を有するように、インターフェース識別子の所有権のチェックを行うことが可能となる。このＤｏＳ保護は、検証機能に費用をかけて公開鍵の計算をさせる、ノードの数を制限することにより実現される。
上記の実施例については、本発明の範囲を逸脱することなく、様々な変形が可能となっている。

インターネットに接続された複数のホストを含むネットワークの概要図である。図１に示したネットワーク中での、複製アドレス検出処理のフローチャートである。図１に示したネットワーク中での、対応付け更新処理を実行する方法のフローチャートである。

Claims

ＩＰネットワークに接続されたノードが前記ノードにＩＰアドレスを対応付けるための方法であって、該ＩＰアドレスは、ルーティング接頭部およびインターフェース識別子を含み、前記ノードは公開鍵と個人鍵の組を有しており、該方法は、
一方向性の符号化関数を用いて、前記公開鍵と個人鍵の組の公開鍵を有する複数のデータコンポーネントを対応付けることにより前記インターフェース識別子を生成するステップと、
前記インターフェース識別子と前記公開鍵を有し、且つ前記公開鍵と個人鍵の組の個人鍵で署名された証明書を生成するステップであって、前記証明書を前記ノードが有する公開鍵を用いて認証できるように、また、前記証明書の内容を用いて前記インターフェース識別子を再構築することにより、前記インターフェース識別子の所有権が検証されるようになっている前記生成ステップを有することを特徴とする方法。
請求項１記載の方法において、前記一方向性の符号化関数はハッシュ関数であることを特徴とする方法。
請求項１または２記載の方法において、前記データコンポーネントは、ランダム値を含むことを特徴とする方法。
ＩＰアドレスを利用する権限を提供する方法であって、
第１のノードにおいて請求項１記載の方法を実行し、インターフェース識別子と、対応する証明書とを有するＩＰアドレスを生成するステップと、
前記ＩＰアドレスと前記証明書とを第２のノードに送信するステップと、
前記第２のノードにおいて、前記証明書の内容を用いてインターフェース識別子を再構築し、再構築された前記インターフェース識別子を、送信された前記ＩＰアドレスと比較するステップと、
前記第２のノードにおいて、前記第１のノードの前記公開鍵を用いて前記証明書を検証するステップを含むことを特徴とする方法。
ＩＰネットワークにおいて使用され、公開鍵と個人鍵の組を有するノードであって、該ノードは、
一方向符号化関数を用いて、前記公開鍵と個人鍵の組の公開鍵を有する複数のデータコンポーネントを対応付けることにより前記ノードで用いられるＩＰアドレスのインターフェース識別子を生成する手段と、
前記公開鍵と個人鍵の組の中の個人鍵で署名された証明書を生成する手段とを有し、該証明書は、該インターフェース識別子と前記公開鍵を含み、前記証明書がホストの公開鍵を用いて認証され、また、該証明書の内容を用いて該インターフェース識別子を再構築することにより、該インターフェース識別子の所有権が検証されることを特徴とするノード。