(57)【要約】【課題】  通信速度の低下およびコストの上昇を最小限に抑えつつ、トラヒック解析等の攻撃に対して効力を有する通信技術を実現する。【解決手段】  通信装置は、ネットワークを構成するリンクに通信インターフェイスを介して接続される。この通信装置の電源が投入されあるいはリブートされると（Ｓ８０１）、例えば仮のリンクローカル・アドレスを生成することでランダムなMACアドレスを生成し（Ｓ８０２）、生成したそのランダムなMACアドレスがリンク内で一意であることを確認する（Ｓ８０３〜Ｓ８０５）。そして、上記ランダムなMACアドレスがリンク内で一意であることが確認された場合に、当該ランダムなMACアドレスを通信インターフェイスに割り当てる（Ｓ８０６）。【選択図】  図８
2006173673.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続するインターフェイス部と、
ランダムなMACアドレスを生成する手段と、
生成した前記ランダムなMACアドレスが所定の通信範囲内で一意であることを確認する手段と、
前記ランダムなMACアドレスが前記所定の通信範囲内で一意であることが確認された場合、当該ランダムなMACアドレスを前記インターフェイス部に割り当てる手段と、
を有することを特徴とする通信装置。
【請求項２】
IPv6に準拠して、ネットワークを構成するリンクに接続可能な通信装置であって、
前記リンクに接続するインターフェイス部と、
ランダムなインターフェイスIDを生成する手段と、
生成した前記ランダムなインターフェイスIDに基づいて、ランダムなMACアドレスを生成する手段と、
前記ランダムなインターフェイスIDが前記リンク内で一意であることを確認する手段と、
前記ランダムなインターフェイスIDが前記リンク内で一意であることが確認された場合、前記インターフェイス部に対して、前記ランダムなMACアドレスを割り当てるとともに、前記ランダムなインターフェイスIDをリンクローカル・アドレスとして割り当てる手段と、
を有することを特徴とする通信装置。
【請求項３】
IPv6に準拠して、ネットワークを構成するリンクに接続可能な通信装置であって、
前記リンクに接続するインターフェイス部と、
ランダムなMACアドレスを生成する手段と、
生成した前記ランダムなMACアドレスからインターフェイスIDを生成する手段と、
生成した前記インターフェイスIDが前記リンク内で一意であることを確認する手段と、
前記インターフェイスIDが前記リンク内で一意であることが確認された場合、前記インターフェイス部に対して、前記ランダムなMACアドレスを割り当てるとともに、前記インターフェイスIDをリンクローカル・アドレスとして割り当てる手段と、
を有することを特徴とする通信装置。
【請求項４】
前記インターフェイスIDが前記リンク内で一意であることの確認は、前記インターフェイスIDを対象に行うDAD(Duplicate Address Detection)を用いて行うことを特徴とする請求項２または３に記載の通信装置。
【請求項５】
IPv6匿名アドレスを用いてIPv6データの送受信を行う手段を更に有することを特徴とする請求項１から４までのいずれかに記載の通信装置。
【請求項６】
生成された前記ランダムなMACアドレスを複数保持し、IPv6データの少なくとも送信時と受信時とでMACアドレスを切り換える制御手段を更に有することを特徴とする請求項１から５までのいずれかに記載の通信装置。
【請求項７】
通信インターフェイスを介してネットワークに接続可能な通信装置の制御方法であって、
ランダムなMACアドレスを生成するステップと、
生成した前記ランダムなMACアドレスが所定の通信範囲内で一意であることを確認するステップと、
前記ランダムなMACアドレスが前記所定の通信範囲内で一意であることが確認された場合、当該ランダムなMACアドレスを前記通信インターフェイスに割り当てるステップと、
を有することを特徴とする通信装置の制御方法。
【請求項８】
IPv6に準拠して、ネットワークを構成するリンクに通信インターフェイスを介して接続可能な通信装置の制御方法であって、
ランダムなインターフェイスIDを生成するステップと、
生成した前記ランダムなインターフェイスIDに基づいて、ランダムなMACアドレスを生成するステップと、
前記ランダムなインターフェイスIDが前記リンク内で一意であることを確認するステップと、
前記ランダムなインターフェイスIDが前記リンク内で一意であることが確認された場合、前記通信インターフェイスに対して、前記ランダムなMACアドレスを割り当てるとともに、前記ランダムなインターフェイスIDをリンクローカル・アドレスとして割り当てるステップと、
を有することを特徴とする通信装置の制御方法。
【請求項９】
IPv6に準拠して、ネットワークを構成するリンクに通信インターフェイスを介して接続可能な通信装置の制御方法であって、
ランダムなMACアドレスを生成するステップと、
生成した前記ランダムなMACアドレスからインターフェイスIDを生成するステップと、
生成した前記インターフェイスIDが前記リンク内で一意であることを確認するステップと、
前記インターフェイスIDが前記リンク内で一意であることが確認された場合、前記通信インターフェイスに対して、前記ランダムなMACアドレスを割り当てるとともに、前記インターフェイスIDをリンクローカル・アドレスとして割り当てるステップと、
を有することを特徴とする通信装置の制御方法。
【請求項１０】
請求項７から９までのいずれかに記載の通信装置の制御方法を実現するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置およびその制御方法に関し、例えば、IPv6ネットワークに接続する通信装置およびその制御方法に関する。
【背景技術】
【０００２】
LAN内部ではデータリンク層の通信が行われ、MAC(Media Access Control)アドレスが(ノードの)インターフェイスを識別するために固定的に用いられる。データリンク層の通信は、イーサネット(登録商標)であっても無線LANであっても、LAN内の同一リンクに接続されている全ての(ノードの)インターフェイスが受信できるような信号を用いて行われる。かかる信号を用いて表現されたビットのかたまりは、MACフレーム(MAC frame)と呼ばれる。MACフレームは、発信元MACアドレス、宛先MACアドレス、フレーム・ボディ(framebody)等からなり、フレーム・ボディには送るデータが含まれる。フレーム・ボディ内に格納されるデータはIPパケットである。IPパケットにはIPヘッダとIPペイロードが含まれる。IPヘッダには発信元IPアドレスと宛先IPアドレスが含まれ、IPペイロードにはさらに上位プロトコルのパケットが含まれる。
【０００３】
ここで、無線LAN用の暗号化、例えばWEP(Wired Equivalent Privacy)やWPA(Wi-Fi Protected Access)を使う場合にはフレーム・ボディは暗号化される。このような暗号化がされない場合には、LAN内の同一リンクに接続するノードは他のノードが送受するフレーム・ボディを観測することが可能なので、MACアドレスやIPアドレスを把握することが容易である。
【０００４】
しかし、上記のWEPやWPAといった暗号化は万全とはいえない。なぜなら、フレーム・ボディは暗号化されるもののMACアドレスは暗号化されないからである。そのため、たとえノードがデータリンク層で暗号化を行い、匿名アドレスを使う場合でも、ノードのMACアドレスをLAN内部の別のノードから隠すことはできない。MACアドレスを使う通信をLAN内部で観測し、匿名アドレスを用いる通信をLAN外部で観測し、それらの観測結果を突き合わせれば、どのMACアドレスを使う通信とどの匿名アドレスを使う通信とが対応するかを突き止めることが可能である。このような通信の事実に関する解析は「トラヒック解析（traffic analysis）」と呼ばれている。プライバシ保護のためにトラヒック解析に対処する技術として、暗号を用いたものがいくつか提案されている。送信者と受信者を特定困難にする方法としては例えば以下のものがある。
【０００５】
非特許文献１は、通信路上にmixと呼ばれる計算機を設け、メッセージを公開鍵暗号を用いる暗号化によって変換し、mixに入力されるメッセージと出力されるメッセージの間の対応がわからないようにして送信者と受信者の特定を困難にする方法を開示している。この方法はメッセージを追跡困難にする一般的な手法を提案しており、異なるネットワークの間にmixを配置することによって、ネットワークの内外の通信の対応付けを追跡困難にすることができる。
【０００６】
非特許文献２は、ループ状の通信路に各ノードが接続されている環境で、公開鍵暗号を用いてメッセージを変換し、送信者と受信者の特定を困難にする方法を開示している。この方法では、ノードの前後のノードが結託するとノードの送信が把握されてしまうことを防ぐため、ランダム・アクセス・プロトコルを使用する。
【０００７】
また、非特許文献３は、通信路としてイーサネット(登録商標)のような同報型通信路を仮定し、前述の送信ノードの特定は困難だと仮定し、非特許文献２の方式を改良した方法を提案している。
【０００８】
【非特許文献１】D. Chaum, "Untraceable electronic mail, return addresses, and digital pseudonyms," Communications of ACM, Vol. 24, No. 2, pp. 84-88 (1981)
【非特許文献２】A. Pfitzmann, "A switched/broadcast ISDN to decrease user observability," 1984 International Zurich Seminar on Digital Communications, Applications of Source Coding, Channel Coding and Secrecy Coding, IEEE Catalog, no. 84 ch 1998-4, pp. 183-190 (1984)
【非特許文献３】満保 雅浩, 木下 宏揚, 辻井 重男, "送受信者追跡の不可能な通信プロトコルに関する研究," 電子情報通信学会論文誌 D-I, Vol. J74-D-I, No. 7, pp. 429-434 (1991)
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、非特許文献１に開示された方法では、イーサネット(登録商標)のようなLANに適用することを考えると、mixがLAN内部の全ての通信を仲介するようにLAN内部を構成しなければならず、現実的ではない。仮に現実的な構成が可能だとしても、各ノードが公開鍵暗号を用いること、mixを設けること、公開鍵暗号の暗号化と復号の処理が必要になり、通信速度の低下あるいはコストの上昇が避けられないという問題がある。
【００１０】
一方、非特許文献２の方法は、現在の有線LANや無線LANとは通信路の形状が異なり、かつプロトコルも異なるので、そのまま適用できないという課題がある。また、MACアドレスを追跡不可能にすることもできない。仮に何らかの方法によって適用できたとしても、各ノードが公開鍵暗号を用いること、公開鍵暗号の暗号化と復号の処理が必要になり、やはり通信速度の低下あるいはコストの上昇が避けられないという問題がある。
【００１１】
また、非特許文献３の方法は、非特許文献２の方法を改良しているが、メッセージの受信時に全てのノードが、受け取ったメッセージが自分宛であるか否かを確認するために復号を行う必要があるので、自分宛ではないメッセージの復号処理が通信速度の低下あるいはコストの上昇を引き起こすという問題がある。
【００１２】
通信速度の低下およびコストの上昇はとりわけ、一般向けの価格の制約が厳しい機器にとって大きな課題である。
【００１３】
要するに、現状のネットワークシステムは、データリンク層におけるノードおよびそのユーザのプライバシ保護に問題がある。特に、伝達距離が大きな無線をデータリンク層の通信方式として利用する場合、傍受が極めて容易である一方、傍受されている事実を検出することは極めて困難になるので、上記のMACアドレスに関するプライバシ保護の問題はより顕著なものとなる。かといって、上記した各文献に開示されたような方法を適用することも困難である。
【００１４】
本発明の目的は、通信速度の低下およびコストの上昇を最小限に抑えつつ、トラヒック解析等の攻撃に対して効力を有する通信技術を実現することを目的とする。
【課題を解決するための手段】
【００１５】
上記課題を解決するために、本発明の一側面に係る通信装置は例えば、ネットワークに接続するインターフェイス部と、ランダムなMACアドレスを生成する手段と、生成した前記ランダムなMACアドレスが所定の通信範囲内で一意であることを確認する手段と、前記ランダムなMACアドレスが前記所定の通信範囲内で一意であることが確認された場合、当該ランダムなMACアドレスを前記インターフェイス部に割り当てる手段とを有する。
【発明の効果】
【００１６】
本発明によれば、通信速度の低下およびコストの上昇を最小限に抑えつつ、トラヒック解析等の攻撃に対して効力を有する通信技術が実現される。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。
【００１８】
（第１の実施形態）
本実施形態では、イーサネット(登録商標)を用いるLANにおいて、ある装置(ホスト)がインターネット上の別の装置と匿名アドレス(temporary address)を用いて通信する場合に、イーサネット(登録商標)のLAN内部においてプライバシを保護する例を説明する。
【００１９】
図２は、本発明が適用される接続環境（ホストがイーサネット(登録商標)のLAN経由でインターネットと接続する環境）を模式的に示したものである。同図において、LANに接続されたホスト204、205、206はそれぞれ、 gateway 202を経由してインターネット201にアクセスすることが可能である。本実施形態では、各ホストはリンク207によって接続される。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、IP層の下側に接する。具体的には、リンク207はイーサネット(登録商標)である。なお、リンクにはイーサネット(登録商標)の他に、PPPリンク、X.25、フレームリレー、ATMネットワークなどがある。
【００２０】
リンクに接続されたIPv6装置を「ノード」と呼ぶ。
【００２１】
ノードの内部構成の典型例を図３に示す。
【００２２】
ノードにはルーターとホストがある。ルーターは自分宛ではないパケットを転送するが、ホストは自分宛ではないパケットを転送しない。図３からわかるように、ノード300は、ネットワーク・インターフェイス301、302、CPU 303、ROM 304、RAM 305、HD(ハードディスク)306、電源307、キーボード/ポインティングデバイスのインターフェイス308、モニターのインターフェイス309、バス310等を有する計算機である。
【００２３】
ルーターは複数のネットワーク・インターフェイス301、302を持つのに対し、ホストは多くの場合、１つのインターフェイス301を持つ。ネットワーク・インターフェイス301は、リンク207に接続され、リンク207に接続された他のノードと通信する。
【００２４】
ホスト204、205、206は、ネットワーク・インターフェイス301により、リンク207を介して、リンク207に接続された他のノード、あるいは、更にゲートウェイ202を介してインターネット201上のサイトと通信する。ルーターであるゲートウェイ202の場合は、ネットワーク・インターフェイス301がリンク207に接続され、それを介してリンク上の他の装置と通信し、ネットワーク・インターフェイス302がリンク208に接続され、それを介してインターネット201と接続され、それらを介してインターネット上のノードと通信する。なお、ノードによってはHDを持たないものもある。
【００２５】
なお、以下の処理内容(手順)は、プログラムもしくはモジュールとして実現され、そのプログラムがROM 304もしくはHD 306に格納されたノードが実行、もしくはそのモジュールを有するノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるCPU 303が読み込み、必要に応じてRAM 305を計算のための空間として利用しながらバス310を介してインターフェイス301にアドレスを割当てる、というような動作を行う。モジュールの場合は、プログラムがCPUやRAM等と協調して実行する上述の動作と同等の動作を実行する実体が、例えばLSIとして実現され、ノードに組み込まれている。ノードのCPUからモジュール(LSI)へ指示が発行され、それをきっかけにモジュールが動作し、処理を実行する。
【００２６】
以降では、IPv6のアドレス・アーキテクチャ、近隣探索、アドレス自動設定、ICMPv6、匿名アドレス(temporary address)について、以下の仕様書に基づいて、本発明に関連のある範囲で説明を行う。
【００２７】
・RFC3513, "Internet Protocol Version 6 (IPv6) Addressing Architecture,"
・RFC2461, "Neighbor Discovery for IP Version 6 (IPv6),"
・RFC2462, "IPv6 Stateless Address Autoconfiguration,"
・RFC2463, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,"
・RFC3041, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6,"
【００２８】
また、イーサネット(登録商標)や無線LAN等のデータリンク層においてMACアドレスを用いるデータ通信については、
・IEEE Std 802-2001、
・IEEE Std 802.3-2002
を参照しながら本発明に関連のある範囲で説明を行う。
【００２９】
本実施形態のイーサネット(登録商標)LAN環境で各ホストがIPv6グローバル・アドレスのプレフィックスやデフォルト・ルーターのアドレスを取得するプロトコルの仕組みを説明し、その次に、本発明を適用した具体的な実施形態を説明する。
【００３０】
最初に、イーサネット(登録商標)の場合のデータリンク層の通信の仕組みを説明する。前述のように、ノード間では、MACフレーム(MAC frame)と呼ばれるビットの固まりがリンクを介して送受信され、MACフレームはリンクに接続されている全てのインターフェイスに届く。
【００３１】
MACフレームの構成を図１１を参照しながら説明する。図１１はフレームの各構成要素とその長さ(オクテット)を示す。１フレームは、以下のフィールドからなる。
【００３２】
Preambleは、7オクテット(56ビット)長のフィールドで、フレームを受信するために必要な同期を可能にするビット・パターンを含む。
【００３３】
SFD(Start Frame Delimiter)は、1オクテット長のフィールドで、フレームの開始を示すビット・パターンを含む。
【００３４】
Destination addressは、6オクテット(48ビット)長のフィールドで、宛先MACアドレスを含む。宛先MACアドレスは、Individual addressあるいはGroup addressのいずれかであり、前者は特定の１つの宛先を指し、後者は１つ以上の複数の宛先を指す。Group addressの１つであるBroadcast addressは、そのイーサネット(登録商標)LANにおける全てのノードを指す。
【００３５】
Source addressは、6オクテット(48ビット)長のフィールドで、発信元MACアドレスを含む。
【００３６】
L/T(Length/Type)は、2オクテット(16ビット)長のフィールドで、後続のdataフィールドに含まれるデータのオクテット長、あるいはMAC client protocolのタイプを示す値を含む。
【００３７】
DataおよびPadは、nオクテット長(nは46以上1500以下の整数)のフィールドで、送信するデータを含む。Data長が46オクテット以下のときはDataとPadを合わせた長さが46オクテットになるようにPadフィールドが付加される。
【００３８】
FCS(Frame Check Sequence)は、4オクテット(32ビット)長のフィールドで、Dataフィールドに含めるデータの値から計算されたClyclic Redundancy Check(CRC) valueを含む。
【００３９】
インターネットの場合、Dataフィールドに格納されるデータはIPパケットである。IPパケットにはIPヘッダとペイロードが含まれる。IPヘッダには発信元IPアドレスと宛先IPアドレスが含まれ、ペイロードにはIPの上位プロトコル、例えば、ICMPv6やTCP、UDP等のパケットが含まれる。
【００４０】
以上の構成に従い、送信ノードは、Source addressフィールドに自分のMACアドレスを、Destination addressに宛先ノードのMACアドレスを、Length/Typeフィールドにデータ長あるいはTypeを示す値を、Dataフィールドにデータ(必要ならばPadフィールドにPad用データ)を、FCSにデータから計算したCRC valueを格納してMACフレームを構成し、イーサネット(登録商標)上に電気的な信号として送出する。イーサネット(登録商標)上に送出されたフレームは、本発明とは特に関係がないため詳細な説明は省略するが、CSMA/CD方式によって、リンク上の全ノードに伝わる。
【００４１】
各ノードは、MACフレームを検出すると、そのDestination addressを参照する。自分宛のMACフレームの場合には受信処理を行う。つまり、L/Tを参照してDataフィールドのデータ長あるいはプロトコルのタイプを判別し、Dataフィールドに格納されたデータを取り出し、FCSを用いて誤りを検出し、上位のプロトコル・スタックにデータを渡す。そうでない場合は受信処理しない。
【００４２】
以上のようにして、同じリンク上のノードから別のノードに対してデータリンク層でデータが転送され、上位プロトコルの通信を支える。
【００４３】
次に、データリンク層の上位のネットワーク層における通信の仕組み、つまり、IPv6アドレスとIPv6ノードの動作の概要を説明する。
【００４４】
IPアドレスには、１つのインターフェイスを宛先とするユニキャスト・アドレス（unicast address）と、複数のインターフェイスを宛先とするマルチキャスト・アドレス（multicast address）がある。MACアドレスには、１つのインターフェイスを宛先とするindividual addressと、複数のインターフェイスを宛先とするmulticast addressがある。それらの対応関係は、RFC2464, "Transmission of IPv6 Packets over Ethernet（登録商標） Networks,"に定義されている。
【００４５】
unicast のリンクローカルアドレス（link-local address）については、prefixとしてFE80::/64(16進数の「FE80」に、「0」を複数付加した64ビット長のデータ)を用い、このprefixにinterface IDを付加したIPv6アドレスが定義されている。interface IDとMACアドレスの対応関係は、Modified EUI-64形式として定められる。リンクローカル・アドレス(link-local address)とは、ある１つのリンク内部で使われるIPv6アドレスである。prefix、interface ID、Modified EUI-64形式の詳細は後述する。
【００４６】
multicastのIPアドレスについては、次のように定義されている。すなわち、DST[1], DST[2], ..., DST[16]という16バイトからなるIPv6 multicast addressに対応するイーサネット(登録商標)の(MACアドレスの)multicast addressは、0x3333に、DST[13], DST[14], DST[15], DST[16]をこの順番で付加した48ビットとする。
【００４７】
典型的なIPv6アドレスは prefix と interface ID からなり、prefixが上位64ビット、interface IDが下位64ビットである。prefixは、アドレスの種類を表わすのに使われ、リンクローカル・アドレスの場合は前述のように固定のFE80::/64である。グローバル・アドレスの場合はインターネットにおけるリンクの位置を表わす情報であり、subnet prefixと呼ばれる。interface IDは、あるリンク(正確にはa subnet prefix)における識別子であり、イーサネット（登録商標）のネットワーク・インターフェイスに割り当てられているMAC address 48ビットを基にして以下のように生成される。
【００４８】
イーサネット(登録商標)の IEEE identifier (MAC address) は、6バイト長のアドレスで、先頭の3バイトはIEEEによって管理・割当てがされ、company_idとして各会社に割り当てられる。残り3バイトは各会社(manufacturer)に管理が任されており、重複が起こらないように割当てがされる。
【００４９】
図４にイーサネット(登録商標)の MAC address の構成を示す。各フィールドは1バイト(8ビット)のデータを示し、左から3バイト（C1〜C3）がcompany_id、残り3バイト（M1〜M3）がthe manufacturer-selected extension identifierである。
【００５０】
図４に示したイーサネット(登録商標)の MAC addressを3バイトずつに分割し、中間に16進数の「FFFE」を挟み、先頭から7ビット目を1にする。これを図５に示す。図５のC1'は、図4のC1の先頭から7ビット目を1にしたものを表す。interface IDの先頭から7ビット目は、"u"ビット(IEEE EUI-64の用語でuniversal/localビット)と呼ばれ、globalスコープの場合は1、localスコープの場合は0に設定される。このようにして生成された、図５の構成の64ビット・データをModified EUI-64形式のinterface IDと呼ぶ。
【００５１】
次に、図３のノード300が、電源を投入されあるいはリブートされた場合に行う動作のフローチャートを図８に示す。この動作はDAD(Duplicate Address Detection)と呼ばれる。以下では図８の流れに沿って処理内容を説明する。
【００５２】
ノード300が電源を投入されあるいはリブートされると（ステップS801）、ネットワーク・インターフェイス301のイーサネット(登録商標)の MAC address(図４参照)からinterface ID(図５参照)を作成し、それを仮のリンクローカル・アドレス（tentative link-local address）(図６参照)とする（ステップS802）。次に、そのtentative link-local addressがリンク207上で一意かどうかを判断するために、ノード300は以下の処理を行う。
【００５３】
まず、インターフェイス301の初期設定を行う。例えば、インターフェイス301に、all-nodes multicast address (FF02::1)とそのtentative link-local address の solicited-node multicast address を割り当てる（図７参照）。つまり、そのインターフェイス301が all-nodes multicast address宛のパケットあるいはそのtentative link-local address の solicited-node multicast address 宛のIPパケットを含むMACフレームを検出したときはそれを自分のインターフェイス宛のIPパケットとして受け取れるようにする。具体的には、イーサネット（登録商標）・インターフェイスを電気的に使用可能な状態にして、上記のIPv6アドレス(multicast)に対してRFC2464に定められた対応関係を持つMACアドレス(multicast address)をイーサネット（登録商標）・インターフェイスに設定する。
【００５４】
all-nodes multicast addressとそれに対応するMACアドレスを割り当てることによって、既にそのtentative link-local addressを使っている他のノードからのデータを受信することが可能になる。また、そのtentative link-local address の solicited-node multicast addressとそれに対応するMACアドレスを割り当てることによって、同じtentative link-local addressを同時に使おうとしている他のノードの存在を検出することが可能になる。
【００５５】
あるtentative link-local address の solicited-node multicast addressとは、RFC2461の91ページに定義されているように、tentative link-local addressの下位24ビットをプレフィックスFF02:0:0:0:0:1:FF00::/104に付加したデータであり、link-local scope multicast address である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図８のステップS803である。
【００５６】
次に、近隣要請メッセージ（Neighbor Solicitation message）を生成する。Neighbor Solicitation message のターゲットアドレス（Target Address）には判断対象のtentative link-local addressを、IP Source(送信元アドレス)には unspecified address(128ビット全てが0)を、IP destination(宛先アドレス)には判断対象のtentative link-local address の solicited-node multicast addressを設定する。
【００５７】
この Neighbor Solicitation message をRetransTimerミリセカンド間隔でDupAddrDetectTransmits個、リンク207に送出する。このNeighbor Solicitation messageをIPパケットとして含むMACフレームのdestination addressには、宛先のIPアドレス(判断対象のtentative link-local address の solicited-node multicast address)に対応するMACアドレス(multicast address)が指定される。図８のステップS804がこの処理である。
【００５８】
Neighbor Solicitation messageを受け取ったノードは、その送信元アドレスが unspecified address ならば、その message がDADを行っているノードからのデータであることと判断する。
【００５９】
DAD実行中のノードはマルチキャストのパケットをループバックしているので自分が送ったNeighbor Solicitation messageを自分で受け取る。
【００６０】
同時に複数のノードが同じアドレスを対象としてDADをしている場合は、自分が送ったNeighbor Solicitation messages以外にも、同じアドレスを Target Addressに含むNeighbor Solicitation messagesを受け取る。つまり、重複していることがわかる。その場合には同時に複数のノードが同じアドレスを対象としてDADをしていると判断し、どのノードもそのアドレスは使わない(図8のステップS805の「はい」の場合)。
【００６１】
一方、Neighbor Solicitation messageを受け取ったノードが、その message の Target Address（ターゲットアドレス）に含まれるアドレスを既に使っていれば、Target Addressにそのtentative link-local addressが設定されたa multicast Neighbor Advertisement をall-nodes multicast address宛てに返す。従って、Neighbor Solicitation messageを送ったノードが all-nodes multicast address 宛てのa multicast Neighbor Advertisementを受け取り、その target address が (判断対象の) tentative address である場合(図８のステップS805の「はい」の場合)は判断対象の tentative address が唯一ではない(つまり、重複している)。
【００６２】
以上のDADの結果、判断対象の tentative link-local address がリンク207上で唯一であることが確認された(図８のステップS805の「いいえ」の場合)ならば、そのアドレスをリンクローカル・アドレスとしてインターフェイス301に割り当てる。これが図８のステップS806である。以上でDADは終了する。
【００６３】
以上説明した図８の動作は図２の gateway 202、DHCP server 203、
ホスト204、ホスト205、ホスト206のそれぞれが実行することができる。
【００６４】
図２のホスト、例えばホスト206は、リンクローカル・アドレスをインターフェイス301に割り当てたら、次はグローバル・アドレスを決定するために必要な情報(Router Advertisementと呼ばれる)を入手することを試みる。グローバル・アドレスは、インターネットで通信をするときに使われるIPv6アドレスである。
【００６５】
この動作を図９に示す。gateway 202が、Router Advertisementを送る場合を説明する。gateway 202はルーター(デフォルト・ルーター)として機能するので、以下ではルーター202と記す。ルーター202は管理者によって必要な設定が行われ、Router Advertisement を定期的にリンク207に送っている。ホスト206が Router Advertisement を早く入手したい場合は、ホスト206は Router Solicitation と呼ばれるデータをルーター202に送る。ホスト206はリンクローカル・アドレスを割り当てた直後にはルーター202の存在はわからないので、実際にはRouter Solicitationはリンク上のルーター全てに対するマルチキャストとして送られる。図９のステップS901はこの処理を示す。
【００６６】
Router Solicitation を受け取ったルーター202は Router Advertisement を送る。図９のステップS902の「はい」の場合に示すように、Stateless address autoconfiguration のみを指定するRouter Advertisement を受け取ったホスト206は、そのメッセージに含まれるプレフィックスの有効性(既にその装置によって使われていないこと等)を確認し、それ(ら)にインターフェイスIDを付加して作ったアドレスをグローバル・アドレスとして、インターフェイス301に割り当てる。図９のステップS903がこの処理である。また、ホスト206はルーター202のアドレスをデフォルト・ルーターのアドレスとして設定する。
【００６７】
図９のステップS902の「いいえ」の場合に示すように、ホスト206が stateless address autoconfigurationのみを指定するRouter Advertisement を受け取らなかった場合は、次の二つの場合に分けられる。Stateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementを受け取った場合(ステップS904の「はい」の場合)と、Router Advertisementを何も受け取らなかった場合(ステップS904の「いいえ」の場合)である。
【００６８】
後者の場合は、stateful address autoconfiguration、すなわちDHCPv6のみを実行する。これがステップS906であり、その基本的な動作フローチャートを図１０に示す。
【００６９】
なお、stateful address autoconfigtation においてやり取りされるメッセージの内容や形式等の詳細は、RFC3646, "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"を参照されたい。
【００７０】
以下、図１０のフローチャートを参照して基本的な動作の流れを説明する。
【００７１】
DHCPサーバー203は管理者によって必要な設定が行われている。具体的には、ノードとして自身のリンクローカル・アドレスをインターフェイス301に割り当ててあり、DHCPサーバーとして振る舞うために必要なサイトローカル・アドレスもしくはグローバル・アドレスのためのプレフィックス等が設定されている。
【００７２】
ステップS1001で、ホスト204はDHCPサーバーにDHCP Solicit Messageを送る。ホスト206はどこにDHCPサーバーが存在するのかわからないのでDHCPサーバーに対するマルチキャストとしてリンク207に送出する。ホスト206の接続されているリンク207とは異なるリンク(図示せず)にDHCPサーバーがいる場合には、DHCP Solicit Messageは、実際にはDHCPリレー(図示せず)によって中継されてDHCPサーバー203に届く。
【００７３】
DHCP Solicit Messageを受け取ったDHCPサーバー203はそれに対する返答としてDHCP Advertise Messageをホスト206に返す。これは(別リンクの場合はDHCPリレーによって中継されて)ホスト206に届く。これがステップS1002である。この時点でホスト206はDHCPサーバー203のアドレスがわかる。
【００７４】
次にステップS1003で、ホスト206は DHCP Request Message をDHCPサーバー203に送る。DHCPサーバー 203はDHCP Request Messageを受け取ると、ステップS1004でDHCP Reply Messageをホスト206に送る。
【００７５】
DHCP Reply Message受け取ったホスト206は、それからグロー
バルアドレスがわかるので、そのアドレスの中のinterface IDが重複しているか否かを確認するために、DAD処理に必要な処理を行う。つまり、インターフェイス301に前述のマルチキャストアドレス等を設定する。これがステップS1005である。
【００７６】
次にステップS1006で、Neighbor Solicitation Message を送り、Neighbor Advertisement Messageを受け取るかどうかをステップS1007で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをDHCPサーバー203から受け取るためにステップS1003に戻り、同じ処理を繰り返す。
【００７７】
ホスト206は、Neighbor Advertisement Messageを受け取らなかった場合は（ステップS1007の「いいえ」）、そのアドレスは重複していないので、ステップS1008で、そのアドレスをインターフェイス301に割り当てる。
【００７８】
以上で図９のステップS906が終わる。ステップS904でRouter Advertisementを何も受け取らなかった場合はこれで正常終了する。
【００７９】
ステップS904でstateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementを受け取った場合は、ステップS905でstateless address autoconfigurationとstateful address autoconfigurationの両方を行う。処理内容はステップS903あるいはS906を実行した場合と同じである。
【００８０】
以上のようにして、イーサネット(登録商標)をインターフェイスとして持つホスト206はstateless address autoconfiguration とstateful address autoconfiguration (DHCPv6)を任意の組み合わせで適用して、リンクローカル・アドレス、グローバル・アドレス、デフォルト・ルーター等を自動設定することができる。
【００８１】
匿名アドレスを使う場合は、以上のプロトコルが次のように拡張される。図９のステップS903あるいはステップS905において、ホスト206はRouter Advertisementを受け取り、それに含まれるプレフィックスの有効性(既にその装置によって使われていないこと等)を確認し、それ(ら)にインターフェイスIDを付加して作ったアドレスを、グローバル・アドレスとし、インターフェイス301に割り当てる。この際に、Modified EUI-64形式で生成したinterface IDのみではなく、ランダムなinterface IDにも同じ処理を行う。ランダムなinterface IDの生成方法は後述する。
【００８２】
新しい匿名アドレスはプレフィックスにランダムなinterface IDを付加して作られる。ホスト206が既にインターフェイスに割当てているアドレスと新しい匿名アドレスが同じ場合は、新しいランダムなinterface IDを生成し、新しい匿名アドレスを生成する。
【００８３】
次に、ホスト206は匿名アドレスを対象にDADを実行する。DADによって、他の装置がその匿名アドレスを既に使用していることがわかった場合は、新しい匿名アドレスを生成する。例えば最大5回まで繰り返し、その結果一意の匿名アドレスを得ることができない場合は、ホスト206はシステム・エラーをログ(記録)に残し、匿名アドレスを生成することを中断する。
【００８４】
ランダムなinterface IDは、例えばMD5 message digestを使って生成される。MD5とは、任意の入力からランダムな128ビットを出力する関数である。RFC3041の方法では128ビットが入力される。この入力128ビットは上位64ビットと下位64ビットから次のように構成される。interface IDを下位64ビットとする。何らかの方法で生成したランダムな値64ビットあるいは前回のMD5の計算結果の下位64ビットを、入力128ビットの上位64ビットとする。この128ビットを入力としてMD5 message digestを計算し、その計算結果128ビットの上位64ビットを取り出す。取り出した64ビットの左から7ビット目をゼロにした64ビットをinterface IDとする。計算結果の下位64ビットは、次回のMD5の計算に用いるため、記録しておく。
【００８５】
次に、ネットワーク層とデータリンク層の対応付けについて説明する。ノードが通信相手のIPアドレスを与えられたとき、通信相手が同じリンク上に存在するならばそのMACアドレスを知る必要がある。通信相手が同じリンク上ではなくインターネットのどこかに存在するならば、ルーター経由でそのデータを送るためにルーターのMACアドレスを知る必要がある。IPアドレスが与えられたときに、そのIPアドレスに対応するMACアドレス(正確にはデータリンク層アドレス)を得ることを「アドレス解決(address resolution)」と呼ぶ。
【００８６】
アドレス解決は次のように行われる。ノードAは、自分のキャシュを参照して、対象IPアドレスに対応するMACアドレスが記録されているか否かを確認する。記録にない場合、近隣要請メッセージ(Neighbor Solicitation message)を次のように作る。
【００８７】
Neighbor Solicitation message の Target Address には対象のIPアドレスを、IP Source にはノードAのIPアドレスを、IP destination には対象のIPアドレスに対応する solicited-node multicast address を、Source Link-Layer Address option にはノードAのMACアドレスを設定する。
【００８８】
そして、Neighbor Solicitation message をそのリンク上にマルチキャストする(solicited-node multicast address宛に送る)。このマルチキャストは、Destination addressに、solicited-node multicast address (IPアドレス)に対応する multicast address (MACアドレス)が設定されたMACフレームとしてリンクに送出される。
【００８９】
該当するノードBは、マルチキャストの宛先であるので、その近隣要請メッセージ（Neighbor Solicitation message）を受け取る。ノードBは、そのNeighbor Solicitation messageの Target address にノードBのアドレスが含まれていることを確認すると、返答として送る近隣通知メッセージ(Negihbor Advertisement message)を次のように作る。
【００９０】
Neighbor Advertisement message の Target Address には Neighbor Solicitation message の Target address を(コピーして)、IP Source にはノードBのIPアドレスを、IP destination にはノードAのIPアドレスを、Target Link-Layer Address option にノードBのMACアドレスを設定する。
【００９１】
ノードAからNeighbor Solicitation messageを受け取ったときに、ノードAのIPアドレスとMACアドレスがキャシュに記録されているので、以上のように作った Negihbor Advertisement message を(ノードAのIPアドレス宛に)送るときは、ノードAのMACアドレスをDestination addressとするMACフレームをリンクに送出する。
【００９２】
ノードAは、ノードBから Negihbor Advertisement message を受け取り、ノードBのMACアドレスを知ることができ、そのIPアドレスとMACアドレスの組をキャシュに記録する。キャシュの内容は一定の時間が経過した後に消去される。
【００９３】
ノードAとノードBが異なるリンクに接続されている場合は、その事実をノードAはIPv6アドレスとプレフィックスから判断できるので、ルーター(デフォルト・ルーター)宛にIPパケットを送ればよい。ルーター(デフォルト・ルーター)のIPアドレスは、前述のようにリンク接続時にaddress autoconfigurationによって与えられているので、（必要ならばアドレス解決を用いてルーターのMACアドレスを得て、）送信したいデータをルーター宛に送ることが可能である。
【００９４】
また、あるノード(例えば、ノードA)がアドレス解決を実行して同じリンク上に存在する他のノード(例えば、ノードB)のIPアドレスとMACアドレスの組をキャシュに記録した後、そのIPアドレスとMACアドレスの組を使ってノードAがノードBと通信可能か否かを定期的に確認することができる。これを到達可能性の確認(reachability confirmation)と呼ぶ。
【００９５】
このとき、ノードAは、Neighbor Solicitation message をノードB宛にユニキャストする。ノードBは、その Neighbor Solicitation message を受け取ったら返答としてNeighbor Advertise messageをノードAにユニキャストする。このときのノードBが送る Neighbor Advertise message を、solicited Neighbor Advertisement と呼ぶ。
【００９６】
一方、ノードBのMACアドレスが変更したときに、その事実をノードBがリンク上の他のノードに通知する場合に、Neighbor Advertisement message を(all-nodes multicast address 宛に)マルチキャストすることができる。このときのノードBが送る Neighbor Advertise message を、unsolicited Neighbor Advertisement と呼ぶ。
【００９７】
リンク上の他のノードが上記の unsolicited Neighbor Advertisement を受け取ったら、ノードBのIPアドレスと古いMACアドレスの組を新しい内容に更新する。
【００９８】
以上からわかるように、ノードが使用するIPアドレスには対応するMACアドレスが存在し、MACアドレスとIPアドレスの対応関係はアドレス解決によって把握され、その対応関係の状況は到達可能性の確認によって適宜確認され、MACアドレスが更新された場合にその事実を他のノードが把握することも可能になっている。
【００９９】
以上のようなネットワーク層とデータリンク層との対応付けを基にして、IPパケットがMACフレームを用いて伝送される。
【０１００】
次に、上述した動作(プロトコル)を利用して、ホスト206がIPv6アドレスを使う場合のデータリンク層の通信においてもプライバシ保護を実現する方法を述べる。
【０１０１】
データリンク層の通信においてプライバシ保護を実現するためには、ノードと匿名アドレス(IPv6アドレス)の対応関係が他のノードにわからないようにするだけではなく、ノードとMACアドレスの対応関係も他のノードにわからないようにする必要がある。匿名アドレスのみならず、リンクローカル・アドレスとノードとの対応関係も隠せるならば、その方が望ましい。
【０１０２】
例えば、全てのノードが同じMACアドレスを常に用いる方法がひとつの実現方法である。しかし、この方法の場合、データが自分宛か否かを判断するためにはIPパケットの宛先IPアドレスを参照しなければならず、そのために各ノードは全てのMACフレームのDataを自分宛のData(IPパケット)とみなしてIPパケット受信処理をしなければならないので、MACフレームのDestination addressが自分宛のときにのみIPパケット受信処理を行う現在のデータリンク層の通信より効率が悪くなる。しかも、通信速度に比例して処理効率が悪くなるので現実的とはいえない。
【０１０３】
そこで、以下のような、ある通信範囲において識別子が唯一であることを確認するプロトコルを用いてランダムなMACアドレスを生成することで、データリンク層の通信においてもプライバシ保護を実現する。
【０１０４】
以下では図８の流れに沿って処理内容を説明する。
【０１０５】
処理方法は、２つある。第１の方法は、リンクローカル・アドレスをMACアドレスから上で説明したように生成する方法である。第２の方法は、リンクローカル・アドレスとMACアドレスもランダムにする方法である。以下、前者を「方法その１」、後者を「方法その２」と呼ぶ。
【０１０６】
方法その１の場合、ステップS801でノード300が電源を投入されあるいはリブートされた後、interface IDが上に説明したようにMACアドレスから生成され、それをtentativelink-local address(図６を参照)とする（ステップS802）。イーサネット(登録商標)インターフェイスには(IEEEとインターフェイス製造会社によって割り当てられた)MACアドレスが設定され、MACフレームのsource addressにはそのMACアドレスが常に使われる。
【０１０７】
方法その２の場合、ステップS801でノード300が電源を投入されあるいはリブートされた後、匿名アドレスの生成方法に従ってランダムな interface ID を生成し、それをtentativelink-local address(図６を参照)とする（ステップS802）。イーサネット(登録商標)インターフェイスには(IEEEとインターフェイス製造会社によって割り当てられた)MACアドレスを設定せず、図１に示すランダムなMACアドレスをMACフレームのsource addressに使う。ランダムなinterface IDと、ランダムなMACアドレスと、ランダムなMACアドレスの第１オクテットの構成を、それぞれ図１に示す。
【０１０８】
図１に示すランダムなinterface IDとランダムなMACアドレスの対応関係は、Modified EUI-64形式で定められる関係を基にしている。具体的には、同図（ａ）に示すランダムなinterface IDの第４オクテットと第５オクテットを省き、第１オクテットを（ｃ）のように設定したものが、（ｂ）に示すランダムなMACアドレスになる。（ｃ）に示した例では、MACアドレスの第１オクテットのLSB(Least Significant Bit)、つまり左から８番目のビットは、Individual address/Group addressを示し、individualの場合は'0'の値をとる。その隣のビット、つまり左から７番目のビットは、Global address/Local addressを示し、Localの場合は'1'の値をとる。
【０１０９】
ランダムなinterface IDとランダムなMACアドレスは、任意のタイミングで生成することができる。例えばRFC3041に従って、１日に１つのランダムなinterface ID を生成し、その際に対応するランダムなMACアドレスを生成してもよい。あるいは、１時間に１つのランダムなinterface ID を生成し、その際に対応するランダムなMACアドレスを生成してもよい。生成した複数のinterface IDと複数のMACアドレスをメモリに記録しておいてもよい。
【０１１０】
あるいは、ランダムなMACアドレスの代わりに、次に説明する特定MACアドレスをMACフレームのsource addressに使うようにしてもよい。
【０１１１】
特定MACアドレスは、あらかじめ定めておく特定の値であり、本発明に従うノードは、その値が送信元MACアドレスに指定された場合は特定MACアドレスであると判断できるものとする。特定MACアドレスとして採用できる値は複数存在する。前述のように、MACアドレスの第１オクテットのLSBつまり左から8番目のビットは、Individual address/Group addressを示し、unicastの場合は'0'をとる。それを考慮して、FE:FF:FF:FF:FF:FF、あるいはFE:FF:FF:00:00:00（FE:FF:FFはcompany_idとして未割当てである。）を採用することが考えられる。
【０１１２】
次に、そのtentative link-local addressがリンク207上で一意かどうかを判断するために、ノード300は以下の処理を行う。
【０１１３】
最初に、インターフェイス301の初期設定を行う。インターフェイス301に、all-nodes multicast address (FF02::1)とそのtentative link-local address の solicited-node multicast address を割り当てる。つまり、そのインターフェイス301が all-nodes multicast address宛のパケットあるいはそのtentative link-local address の solicited-node multicast address 宛のIPパケットを含むMACフレームを検出したときはそれを自分のインターフェイス宛のIPパケットとして受け取れるようにする。具体的には、イーサネット(登録商標)インターフェイスを電気的に使用可能な状態にして、上記のIPv6アドレス(multicast)に対してRFC2464に定められた対応関係を持つMACアドレス(multicast address)をイーサネット(登録商標)インターフェイスに設定する。
【０１１４】
all-nodes multicast addressとそれに対応するMACアドレスを割り当てることによって、既にそのtentative link-local addressを使っている他のノードからのデータを受信することが可能になる。また、そのtentative link-local address の solicited-node multicast addressとそれに対応するMACアドレスを割り当てることによって、同じtentative link-local addressを同時に使おうとしている他のノードの存在を検出することが可能になる。
【０１１５】
あるtentative link-local address の solicited-node multicast address とは、RFC2461の91ページに定義されているように、tentative link-local addressの下位24ビットをプレフィックスFF02:0:0:0:0:1:FF00::/104に付加したデータであり、link-local scope multicast address である。以上のアドレス割当てが図８のステップS803である。
【０１１６】
次に Neighbor Solicitation message を作る。Neighbor Solicitation message の Target Address（ターゲットアドレス）には判断対象のtentative link-local addressを、IP Source(送信元アドレス)には unspecified address(128ビット全てが0)を、IP destination(宛先アドレス)には判断対象のtentative link-local address の solicited-node multicast addressを設定する。
【０１１７】
このNeighbor Solicitation messageをIPパケットとして含むMACフレームのdestination addressには、宛先のIPアドレス(判断対象のtentative link-local address の solicited-node multicast address)に対応するMACアドレス(multicast address)が指定される。source addressには、方法その１の場合はIEEEとインターフェイス製造会社によって割り当てられたMACアドレスを、方法その２の場合は前述のランダムなMACアドレスもしくは特定MACアドレスが指定される。
【０１１８】
以上の Neighbor Solicitation message を(含むMACフレームを)RetransTimerミリセカンド間隔でDupAddrDetectTransmits個、リンク207に送出する。図８のステップS804がこの処理である。
【０１１９】
Neighbor Solicitation messageを受け取ったノードは、その送信元アドレスが unspecified address ならば、その message がDADを行っているノードからのデータであることと判断する。
【０１２０】
DAD実行中のノードはマルチキャストのパケットをループバックしているので自分が送ったNeighbor Solicitation messageを自分で受け取る。
【０１２１】
同時に複数のノードが同じアドレスを対象としてDADをしている場合は、自分が送ったNeighbor Solicitation messages以外にも、同じアドレスを Target Addressに含むNeighbor Solicitation messagesを受け取る。つまり、重複していることがわかる。その場合には同時に複数のノードが同じアドレスを対象としてDADをしていると判断し、どのノードもそのアドレスは使わない(図8のステップS805の「はい」の場合)。
【０１２２】
一方、Neighbor Solicitation messageを受け取ったノードが、その message の Target Address（ターゲットアドレス）に含まれるアドレスを既に使っていれば、Target Addressにそのtentative link-local addressが設定されたa multicast Neighbor Advertisement をall-nodes multicast address宛てに返す。従って、Neighbor Solicitation messageを送ったノードが all-nodes multicast address 宛てのa multicast Neighbor Advertisementを受け取り、その target address が (判断対象の) tentative address である場合(図８のステップS805の「はい」の場合)は判断対象の tentative address が唯一ではない(つまり、重複している)。
【０１２３】
以上のDADの結果、判断対象の tentative link-local address がリンク207上で唯一であることが確認された(図８のステップS805の「いいえ」の場合)ならば（すなわち、所定の通信範囲内で一意であることが確認されたならば）、方法その１の場合は前述のIEEEとインターフェイス製造会社によって割り当てられたMACアドレスをインターフェイス301のMACアドレスとして割り当て済みなのでそのまま使う。方法その２の場合は、前述のランダムなMACアドレスをインターフェイス301のMACアドレスとして割り当て、その tentative link-local address をリンクローカル・アドレスとしてインターフェイス301に割り当てる。これが図８のステップS806である。以上でDADは終了する。
【０１２４】
方法その２の場合、上記のようにして生成・設定されたランダムなMACアドレスは、対応するinterface IDがリンク上で唯一であることが確認されているので、全てのノードが本プロトコルに従う場合は、MACアドレスとしてもリンク上で唯一になる。
【０１２５】
以後は、既に説明したように Stateless address autoconfigurationやStateful address autoconfiguration を実行し、グローバルアドレスをインターフェイスに割り当て、デフォルト・ルーターを設定する。
【０１２６】
なお、方法その２の場合、判断対象の tentative link-local address がリンク207上で唯一でない場合の動作は、２つ考えられる。
【０１２７】
例えば、異なる値を生成して重複の有無を確認し、５回目の重複を検出したら、IEEEとインターフェイス製造会社によって割り当てられたMACアドレスをインターフェイス301のMACアドレスとして割り当てて使用する、と取り決めておけば、リンクローカル・アドレスを用いる通信は異常が無い限り実行可能になることが保証される。あるいは、５回目の重複を検出したら、リンクローカル・アドレスを用いる通信を断念する、と取り決めておけば、IEEEによって割り当てられたMACアドレスを他のノードに知られることを避けることができる。ノードのポリシーに応じていずれの動作も選択可能にすることができる。
【０１２８】
次に、匿名アドレスを生成する際は、本実施形態の最初に説明した動作を行うが、方法その２の動作を行ってランダムなinterface ID とそれに対応するランダムなMACアドレスを生成し、それらの一意性を確認したうえでそのランダムなMACアドレスをインターフェイスに割り当て、匿名アドレスとそれに対応するMACアドレスとして組にして用いる点が従来の動作と異なる。
【０１２９】
このとき、匿名アドレスとそれと組にして用いるMACアドレス(ランダムなMACアドレス)は、リンクローカル・アドレスとそれと組にして用いるMACアドレスとは異なる。
【０１３０】
方法その１の場合、リンクローカル・アドレスとそれと組にして用いるMACアドレスは常に同じだが、匿名アドレスとそれと組にして用いるランダムなMACアドレスは生成の度に異なる値となる。
【０１３１】
方法その２の場合、リンクローカル・アドレスとそれと組にして用いるランダムなMACアドレスは電源を入れる度あるいはリブートの度に異なり、匿名アドレスとそれと組にして用いるランダムなMACアドレスは生成の度に異なる値となる。
【０１３２】
ランダムなMACアドレスは、IEEEとインターフェイス製造会社によって割り当てられたMACアドレス(IEEE identifier)とは全く関係がなく、ノードを特定するためのいかなる情報も含まない。特定MACアドレスも、同様の性質を持つ。従って、ランダムなMACアドレスあるいは特定MACアドレスを送信元MACアドレスとして用いるNeighbor Solicitation messageを受け取った他のノードは、そのNeighbor Solicitation messageがどのノードから送られたのかについて何の情報も得られない。
【０１３３】
一方、DADの結果、リンク上（すなわち、所定の通信範囲内）で唯一であることが確認されたランダムなMACアドレスは、データリンク層における識別子として機能する。従って、以降の通信においてランダムなMACアドレスを使ってデータリンク層の通信を行うことは可能である。しかも、そのランダムなMACアドレスをリンク上のどのノードが使っているのかを他のノードがプロトコルを観測することによって知ることはできない。
【０１３４】
ランダムなMACアドレスを複数観測しても、それらが同一のノードが生成したものであるか否かを判定することは困難である。従って、ランダムなMACアドレスを適宜更新して使えば、リンク上の他のノードにプライバシを侵害されることを防ぐことができる。
【０１３５】
本プロトコルに従うノードと従来のプロトコルに従うノードが混在するリンクを考える。従来のプロトコルとは、IEEEとインターフェイス製造会社によって割り当てられたMACアドレスを用いるプロトコルである。この従来のプロトコルに従うノードが使うMACアドレスはGlobalなので、左から7番目のビットは、'0'である。従って、本プロトコルに従って生成されたランダムなMACアドレス(左から7番目のビットが'1')とは必ず異なる値になることが保証される。従って、データリンク層のアドレスとして機能することは明らかであり、既存のプロトコルに従うノードも存在するリンクでも所望のプライバシ保護を達成できる。
【０１３６】
また、ランダムなMACアドレスとランダムなinterface IDの対応関係は、図１に示したものに限られるわけではない。例えば、ランダムなinterface IDの第７オクテットと第８オクテットを省いた６つのオクテットを用いて、第１オクテットを前述のように設定したものをランダムなMACアドレスにすることも可能である。
【０１３７】
つまり、DADによってリンク（所定の通信範囲内）における一意性が確認されたランダムなinterface IDからあらかじめ定められた確定的な規則で48ビットのビットパターンを抽出し、その第１オクテットのLSB(Least Significant Bit)、つまり左から8番目のビットに'0'を設定し、その隣のビット、つまり左から7番目のビットに'1'を設定する。この処理により、そのリンクにおけるMACアドレスの一意性が保証される。
【０１３８】
さらに、以上の説明ではイーサネット(登録商標)を例として取り上げて説明したが、別のデータリンク層プロトコルに適用することも可能である。
【０１３９】
本発明の本質は、リンクにおける一意性が確認されたランダムなビットパターンからあらかじめ定められた確定的な規則でランダムなビットパターンを導出し、それがデータリンク層において重複しないように特定ビットの値を設定した結果をアドレスとして採用することである。
【０１４０】
本実施形態では、リンクにおける一意性を判断するプロトコルとしてDADを、一意性が確認されたビットパターンとしてinterface IDを採用した場合を説明した。
【０１４１】
従って、データリンク層のアドレス長が64ビット以下の場合は、既に述べたような方法でランダムなデータリンク層アドレスを定めればよい。データリンク層のアドレス長が64ビット以上の場合は、ランダムなinterface IDを確定的な疑似乱数生成関数に入力し、その出力の疑似乱数列から所望の長さのランダムなビットパターンを抜き出し、特定ビットの値を設定すればよい。
【０１４２】
ただし、後者の場合は、全てのノードが上述のプロトコルに従う場合は、データリンク層アドレスが重複しないことは保証できるが、従来のプロトコルに従うノードも存在するリンクにおいては特定ビットの定義によっては一意性が保証されない可能性がある。前述のイーサネット(登録商標)のMACアドレスの左から7番目のビットのように、Global address/Local addressを示す特定ビットが設けられていれば、従来のプロトコルに従う場合のデータリンク層アドレスと必ず異なるビットパターンを実現できる。
【０１４３】
また、本実施形態では、ある通信範囲において識別子が唯一であることを確認するプロトコルとして、interface IDを対象に行うDuplicate Address Detection(DAD)を用いた。しかし、必ずしもDADのみが本発明を実現する方法というわけではない。例えば、時刻を基にしてランダムな48ビットのMACアドレスを生成し、同じ通信領域、つまりリンク上でそのランダムな48ビットのMACアドレスが唯一か否かを確認するためのデータリンク層上の専用プロトコルを設計することも可能である。
【０１４４】
また、ランダムなinterface IDは、RFC3041の方法によってのみ生成されるとは限らない。別の方法によって生成された場合にも、本発明は適用できることはいうまでもない。
【０１４５】
さらに、以上の例では、まずランダムなinterface IDを生成し、そのランダムなinterface IDからランダムなMACアドレスを生成するようにしたが、このかわりに、上述の MD5 message digest 等を用いて直接ランダムなMACアドレスを生成するようにしてもよい。この場合には、図４〜図６に示すように、生成したランダムなMACアドレス（図４）からインターフェイスIDを生成し（図５）、さらに、そのインターフェイスIDから tentative link-local address を生成する（図６）、という手順を踏むことになる。
【０１４６】
（第２の実施形態）
本実施形態では、第１の実施形態で述べたランダムなMACアドレスを用いてデータを送信する手段を説明する。
【０１４７】
一例として図２のホスト206が第１の実施形態の方法その２の動作を行い、匿名アドレスと、リンク207（所定の通信範囲内）において唯一であることが確認されたランダムなMACアドレスを使って、データを送る例を説明する。以下では、宛先ノードが同じリンク上のノードの場合と、そうでない場合に分けて説明する。
【０１４８】
ホスト206がリンク207上のホスト205宛にデータを送る場合は、次のように動作する。
【０１４９】
ホスト205のIPアドレスがホスト206に入力される。例えば、ホスト206を使用しているユーザが、ホスト205に保存されているファイルを閲覧するために、ホスト205のIPアドレスをキーボードから入力する。
【０１５０】
ホスト206は入力された宛先IPアドレス(ホスト205のIPアドレス)の値からprefixを参照し、それが同じリンク上のノードのIPアドレスであることを知る。
【０１５１】
同じリンク上のノードが宛先なので、アドレス解決を実行する。
【０１５２】
ホスト206は、自分のキャシュを参照して、対象IPアドレスに対応するMACアドレスが記録されているか否かを確認する。記録にない場合、Neighbor Solicitation message を次のように作る。
【０１５３】
Neighbor Solicitation message の Target Address には対象のIPアドレスを、IP Source にはホスト206の匿名アドレスを、IP destination には対象のIPアドレスに対応する solicited-node multicast address を、Source Link-Layer Address option にはホスト206のランダムなMACアドレスを設定する。
【０１５４】
そして、Neighbor Solicitation message をそのリンク上にマルチキャストする(solicited-node multicast address宛に送る)。このマルチキャストは、Destination addressに、solicited-node multicast address (IPアドレス)に対応する multicast address (MACアドレス)が設定されたMACフレームとしてリンクに送出される。
【０１５５】
ホスト205は、マルチキャストの宛先であるので、その近隣要請メッセージを受け取る。ホスト205は、その近隣要請メッセージの Target address にホスト205のアドレスが含まれていることを確認したら、返答として送る Negihbor Advertisement message を次のように作る。
【０１５６】
Neighbor Advertisement message の Target Address には Neighbor Solicitation message の Target address を(コピーして)、IP Source にはホスト205のIPアドレスを、IP destination にはホスト206の匿名アドレスを、Target Link-Layer Address option にホスト205のMACアドレスを設定する。
【０１５７】
ホスト206から近隣要請メッセージを受け取ったときに、ホスト206の匿名アドレスとランダムなMACアドレスがキャシュに記録されているので、以上のように作った Negihbor Advertisement message を(ホスト206のIPアドレス宛に)送るときは、ホスト206のランダムなMACアドレスを宛先MACアドレスとするMACフレームをリンクに送出する。
【０１５８】
ホスト206は、ホスト205から Negihbor Advertisement message を受け取り、ホスト205のMACアドレスを知ることができ、そのIPアドレスとMACアドレスの組をキャシュに記録する。キャシュの内容は一定の時間が経過した後に消去される。
【０１５９】
ホスト206は次のようなMACフレームを作る。Source address にはホスト206のランダムなMACアドレスを、Destination address にはホスト205のMACアドレスを、 L/TにはData長もしくはMAC client protocolのタイプを、DataおよびPadには送信するデータを、FCSにはDataおよびPadから計算したCRC valueを設定する。
【０１６０】
ホスト206は上記MACフレームをリンク207に送出する。
【０１６１】
ホスト205は、MACフレームの Destination address が自分のMACアドレスであることを確認し、受信処理を行う。つまり、L/Tを参照してDataフィールドのデータ長あるいはプロトコルのタイプを判別し、Dataフィールドに格納されたデータを取出し、FCSを用いて誤りを検出し、上位のプロトコル・スタックにデータを渡す。
【０１６２】
以上のプロトコルにおいて、ランダムなMACアドレスがどのホストによって使われているのかをホスト205が知ることはできない。
【０１６３】
次に、宛先ノードが同じリンクに接続されていない場合を説明する。例として、ホスト209が宛先ノードとする。
【０１６４】
ホスト209のIPアドレスがホスト206に入力される。例えば、ホスト206を使用しているユーザが、ホスト209(Webサーバーだとする)に保存されているファイルを閲覧するために、ホスト209のURLをキーボードから入力し、DNS(Domain Name System)によってホスト209のアドレスが判明したとする。
【０１６５】
ホスト206はDNSによって判明した宛先IPアドレス(ホスト209のIPアドレス)の値からprefixを参照し、ホスト209が同じリンク上のノードではないことを知る。
【０１６６】
同じリンク上ではないノードが宛先なので、ルーター経由でIPパケットを転送する。gateway202がルーターである。
【０１６７】
ホスト206は stateless address autoconfiguration によってルーター202(デフォルトルーター)のIPアドレスを既に知っているので、自分のキャシュを参照して、ルーター202(デフォルトルーター)のIPアドレスに対応するMACアドレスが記録されているか否かを確認する。記録にない場合、前述のアドレス解決を行う。
【０１６８】
ルーター202のMACアドレスが(アドレス解決によって)わかったならば、ホスト206は次のようなMACフレームを作る。Source address にはホスト206のランダムなMACアドレスを 、Destination address にはルーター202のMACアドレスを、 L/TにはData長もしくはMAC client protocolのタイプを、DataおよびPadには送信するデータを、FCSにはDataおよびPadから計算したCRC valueを設定する。
なお、送信するデータ(IPパケット)の宛先IPアドレスには、ホスト209のIPアドレスが、発信元IPアドレスにはホスト206の匿名アドレスが設定される。
【０１６９】
ホスト206は上記MACフレームをリンク207に送出する。
【０１７０】
ルーター202は、MACフレームの Destination address が自分のMACアドレスであることを確認し、受信処理を行う。つまり、L/Tを参照してDataフィールドのデータ長あるいはプロトコルのタイプを判別し、Dataフィールドに格納されたデータを取出し、FCSを用いて誤りを検出し、上位のプロトコル・スタックにデータを渡す。
【０１７１】
以上のプロトコルにおいて、ランダムなMACアドレスがどのホストによって使われているのかをホスト205が知ることはできない。
【０１７２】
ルーター202のIPスタックは、受信したデータ(IPパケット)の宛先IPアドレスを参照し、それがホスト209宛であることを知る。そこで、そのIPパケットをインターネット201に送る。実際は、ルーター202が持つ経路表を参照し、次のルーター宛にそのIPパケットを転送する。同様にしてルーターによるIPパケットの転送が繰り返され、ホスト209と同じリンク上のルーターによる転送を最後に、IPパケットがホスト209に届く。
【０１７３】
（第３の実施形態）
本実施形態では、第１の実施形態で述べたランダムなMACアドレスを用いてデータを受信する手段を説明する。
【０１７４】
ここでは、図２のホスト206が第１の実施形態の動作を行い、匿名アドレスと、リンク207（所定の通信範囲内）において唯一であることが確認されたランダムなMACアドレスを使って、データを受信する例を説明する。発信元ノードが同じリンク上のノードの場合と、そうでない場合に分けて説明する。
【０１７５】
ホスト206が同じリンク207上のホスト205からデータを受け取る場合、次のように動作する。
【０１７６】
ホスト205が、ホスト206宛のデータを持っているとする。第2の実施例において、ホスト206を使用しているユーザが、ホスト205に保存されているファイルを閲覧するために、そのリクエストをホスト205に送る場合を説明した。本実施形態では、その返答のデータをホスト206に送るとする。
【０１７７】
ホスト205は宛先IPアドレス(ホスト206の匿名アドレス)の値からprefixを参照し、それが同じリンク上のノードのIPアドレスであることを知る。
【０１７８】
同じリンク上のノードが宛先なので、アドレス解決を実行する。
【０１７９】
ホスト205は、自分のキャシュを参照して、対象IPアドレスに対応するMACアドレスが記録されているか否かを確認する。記録にない場合、アドレス解決を行う。第２の実施形態の動作が実行されてから間も無い場合は、IPアドレスと対応するMACアドレスは記録にあるので、MACアドレスはアドレス解決を行わずとも判明する。
【０１８０】
ホスト205は次のようなMACフレームを作る。Source address にはホスト206のランダムなMACアドレスを 、Destination address にはホスト206のランダムなMACアドレスを、 L/TにはData長もしくはMAC client protocolのタイプを、DataおよびPadには送信するデータを、FCSにはDataおよびPadから計算したCRC valueを設定する。
【０１８１】
ホスト205は上記MACフレームをリンク207に送出する。ホスト206は、MACフレームの Destination address が自分のランダムなMACア
ドレスであることを確認し、受信処理を行う。つまり、L/Tを参照してDataフィールドのデータ長あるいはプロトコルのタイプを判別し、Dataフィールドに格納されたデータを取り出し、FCSを用いて誤りを検出し、上位のプロトコル・スタックにデータを渡す。
【０１８２】
次に、発信元ノードが同じリンクに接続されていない場合を説明する。例として、ホスト209が発信元ノードとする。
【０１８３】
ホスト209が、ホスト206宛のデータを持っているとする。第２の実施形態において、ホスト206を使用しているユーザが、ホスト205に保存されているファイルを閲覧するために、ホスト205のURLをキーボードから入力し、DNS(Domain Name System)によってホスト209のアドレスが判明し、そのアドレス宛にIPパケットが送られた場合を説明した。本実施形態では、その返答のデータをホスト206に送るとする。
【０１８４】
ホスト209はホスト206のIPアドレス(匿名アドレス)の値からprefixを参照し、ホスト206が同じリンク上のノードではないことを知る。同じリンク上ではないノードが宛先なので、ルーター経由でIPパケットが転送される。第２の実施形態で述べたように、ルーターがIPパケットを転送し、gateway202(ルーター202(デフォルトルーター))までIPパケットが届く。IPパケットの宛先IPアドレスにはホスト206の匿名アドレスが記載されているので、ルーター202はそのIPパケットの宛先ノードが同じリンク上に接続されていることがわかる。
【０１８５】
ルーター202は自分のキャシュを参照して、ホスト206のIPアドレス(匿名アドレス)に対応するMACアドレスが記録されているか否かを確認する。記録にない場合、前述のアドレス解決を行うために、Neighbor Solicitation message を次のように作る。
【０１８６】
Neighbor Solicitation message の Target Address にはホスト206のIPアドレスを、IP Source にはルーター202のIPアドレスを、IP destination には対象のIPアドレス(匿名アドレス)に対応する solicited-node multicast address を、Source Link-Layer Address option にはルーター202のMACアドレスを設定する。
【０１８７】
そして、Neighbor Solicitation message をそのリンク上にマルチキャストする(solicited-node multicast address宛に送る)。このマルチキャストは、Destination addressに、solicited-node multicast address (IPアドレス)に対応する multicast address (MACアドレス)が設定されたMACフレームとしてリンクに送出される。
【０１８８】
ホスト206は、マルチキャストの宛先であるので、その近隣要請メッセージを受け取る。ホスト206は、その近隣要請メッセージの Target address にホスト206の匿名アドレスが含まれていることを確認したら、返答として送る Negihbor Advertisement message を次のように作る。
【０１８９】
Neighbor Advertisement message の Target Address には Neighbor Solicitation message の Target address を(コピーして)、IP Source にはホスト206の匿名アドレスを、IP destination にはルーター202のIPアドレスを、Target Link-Layer Address option にホスト206のランダムなMACアドレスを設定する。
【０１９０】
ルーター202から近隣要請メッセージを受け取ったときに、ルーター202のIPアドレスとMACアドレスがキャシュに記録されているので、以上のように作った Negihbor Advertisement message を(ルーター202のIPアドレス宛に)送るときは、ルーター202のMACアドレスを Destination address とするMACフレームをリンクに送出する。
【０１９１】
ルーター202は、ホスト206から Negihbor Advertisement message を受け取り、ホスト206のランダムなMACアドレスを知ることができ、そのIPアドレスとランダムなMACアドレスの組をキャシュに記録する。キャシュの内容は一定の時間が経過した後に消去される。
【０１９２】
ルーター202は次のようなMACフレームを作る。Source address にはルーター202のMACアドレスを 、Destination address にはホスト206のランダムなMACアドレスを、 L/TにはData長もしくはMAC client protocolのタイプを、DataおよびPadには送信するデータを、FCSにはDataおよびPadから計算したCRC valueを設定する。
【０１９３】
ルーター202は上記MACフレームをリンク207に送出する。ホスト206は、MACフレームの Destination address が自分のランダムなMACアドレスであることを確認し、受信処理を行う。つまり、L/Tを参照してDataフィールドのデータ長あるいはプロトコルのタイプを判別し、Dataフィールドに格納されたデータを取り出し、FCSを用いて誤りを検出し、上位のプロトコル・スタックにデータを渡す。
【０１９４】
（第４の実施形態）
ここまでは、ランダムなMACアドレスの生成方法、ランダムなMACアドレスを用いてデータを送信する方法、ランダムなMACアドレスを用いてデータを受信する方法を説明した。次に、複数のランダムなMACアドレス、複数の匿名アドレスとリンクローカル・アドレスを使う方法を説明する。
【０１９５】
匿名アドレスは適宜更新される。デフォルトの更新期間は例えば１日であり、リブートされたときにも更新される。ランダムなMACアドレスも適宜更新されるのが望ましい。その更新期間は、匿名アドレスと同期させてもよいし、非同期でもよい。
【０１９６】
匿名アドレスを１つ生成し、それがリンク（所定の通信範囲内）において唯一であることをDADによって確認するときにランダムなMACアドレスを１つ生成できる。この匿名アドレスとランダムなMACアドレスが必ずしも組になって使われる必要はない。
【０１９７】
ところで、第１の実施形態の方法その１の場合、リンクローカル・アドレスは、MACアドレスからModified EUI-64形式で生成された interface ID を、purefix の FE80::/64 に付加することによって作られる。従って、リンクローカル・アドレスとMACアドレスは固定の関係であり、それらを使い続ける限り、ノードのプライバシを把握するのに利用されてしまう。
【０１９８】
そこで、複数の匿名アドレスと複数のランダムなMACアドレスを生成すれば、匿名アドレスとランダムなMACアドレスとリンクローカル・アドレスを任意に組み合わせて使えるので、方法その１の場合でも、プライバシ保護の程度をより高めることが可能である。方法その２の場合にも、組み合わせを非固定的にすることはプライバシ保護の程度をより高めることになる。
【０１９９】
以下では、IEEEとインターフェイス製造会社によって割り当てられたMACアドレスとリンクローカル・アドレスが組として、かつ匿名アドレスとそれに対応するランダムなMACアドレスが組として使われる場合を、「基本的な使い方」と呼ぶことにする。
【０２００】
基本的な使い方の枠組みにおいて、例えば、匿名アドレス IP_temporary_address_1 に対応するランダムなMACアドレスが MAC_random_address_1、匿名アドレス IP_temporary_address_2 に対応するランダムなMACアドレスが MAC_random_address_2 だとする。つまり、IP_temporary_address_1 と MAC_random_address_1 の対応関係、 IP_temporary_address_2 と MAC_random_address_2 の対応関係は、図１で示される対応関係であるとする。この場合、IP_temporary_address_1が与えられれば、そのMACアドレスがMAC_random_address_1 であることがわかる。
【０２０１】
これに対して、本実施形態では、例えば、リンクローカル・アドレス IP_link-local_address と、ランダムなMACアドレス MAC_random_address_1 を対応させて使うことにし、匿名アドレス IP_temporary_address_1 とランダムなMACアドレス MAC_random_address_2 を対応させて使うことにする。この場合、リンクローカル・アドレスを使うリンク内での通信にはランダムなMACアドレスが用いられるので、IEEEとインターフェイス製造会社によって割り当てられたMACアドレスを使う場合よりもプライバシ保護の度合いが高まる。
【０２０２】
例えば、IPアドレスと組にして用いるMACアドレスを変更したときはunsolicited Neighbor Advertisementをマルチキャストすることでその事実をリンク上の他のノードに通知できるので、IPアドレスとMACアドレスの組を変更して使うことは可能である。
【０２０３】
なお本実施形態でも、第１の実施形態で説明したように、ランダムなinterface IDとそれに対応するランダムなMACアドレスの生成は、任意のタイミングで行える。
【０２０４】
１つの匿名アドレス IP_temporary_address_1 に対して複数のランダムなMACアドレスMAC_random_address_1とMAC_random_address_2を対応付けて用いることで、データ送信のときは(IP_temporary_address_1, MAC_random_address_1)の組を用い、その後は(IP_temporary_address_1, MAC_random_address_2)を使うようにして、unsolicited Neighbor Advertisementをマルチキャストする。
【０２０５】
すると、その後のデータ受信時には(IP_temporary_address_1,MAC_random_address_2)が使われる。時間の経過に伴い、MAC_address_3、MAC_address_4、...  と切り替えて使うこともできる。
【０２０６】
ランダムなMACアドレスとリンクローカル・アドレスと匿名アドレスの組合わせ方は、あらかじめ定義した規則あるいはポリシーに応じて組み合わせを変えるようにすることが可能である。
【０２０７】
プライバシを侵害する者の立場から考えると、MACフレームをフィルタリングする際に、１つのMACアドレスのみに着目していればあるノードの通信状況を把握できた場合に比べ、複数のMACアドレスを対象に通信状況を監視しなければならなくなるので、フィルタリングする対象のMACフレームが増え、処理も増大する。つまり、プライバシを侵害するためのコストが増加する。
【０２０８】
データリンク層にWEPやWPA等の暗号化が適用されている場合は、同じ匿名アドレスを用いるIPパケットが暗号化され、異なるMACアドレスを用いたMACフレームに格納されて通信される。従って、それらのMACフレームが同一の匿名アドレスを含むIPパケットを含むか否かが暗号化の鍵を知らない他のノードにはわからない。従って、プライバシ保護の程度を従来方式より高める効果を持つ。
【０２０９】
以上、本発明の種々の実施形態を説明した。要点は、IPv6ネットワークにおいて、データリンク層においてノードが使うMACアドレスとしてランダムなMACアドレスを生成し、それを用いてIPv6通信を実行する点にある。これにより、以下のような効果を奏する。
【０２１０】
（１）ノードが匿名アドレスを使用する場合に、同一リンク上の他のノードでさえも、ノードとMACアドレスの対応関係およびノードと匿名アドレスの対応関係がわからないので、ノードのプライバシを従来以上に保護することが可能になる。
【０２１１】
（２）同様に、リンクローカル・アドレスを使用する場合に、同一リンク上の他のノードでさえも、ノードとMACアドレスの対応関係およびノードとリンクローカル・アドレスの対応関係がわからないので、ノードのプライバシを従来以上に保護することも可能になる。
【０２１２】
（３）ランダムなMACアドレスとランダムなリンクローカル・アドレスと匿名アドレスを任意の組合わせで使用することができ、その組み合わせを時間の経過に応じて変更することも可能なので、プライバシ保護の程度をより細かな精度で高めることが可能である。
【０２１３】
（４）ランダムなMACアドレスは、ランダムなinterface IDを基にして生成することができるので、その処理量は暗号化や復号と比較すると無視できるほど小さく、極めて低コストに実現できる。
【０２１４】
（５）MACアドレスや匿名アドレスを使う際に必要なプロトコルは全く変更する必要がないので、対象とするIPv6装置以外にはいかなる変更も加えずとも実現でき、既存のIPv6装置が混在しているネットワークにおいても上記効果を得ることができる。
【０２１５】
（他の実施形態）
以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【０２１６】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。
【０２１７】
従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。
【０２１８】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０２１９】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。
【０２２０】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０２２１】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０２２２】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０２２３】
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０２２４】
【図１】本発明の実施形態に係るランダムなinterface IDとランダムなMACアドレスの例を示す図である。
【図２】本発明の実施形態に係るLANの模式図である。
【図３】本発明の実施形態に係るノードの構成例を示す図である。
【図４】本発明の実施形態に係るイーサネット(登録商標)のMAC addressの構成例を示す図である。
【図５】本発明の実施形態に係るinterface IDの構成例を示す図である。
【図６】本発明の実施形態に係るtentative link-local addressの構成例を示す図である。
【図７】本発明の実施形態に係るtentative link-local addressのsolicited-node multicast addressの構成例を示す図である。
【図８】本発明の実施形態に係るホストの、DADを終えるまでの動作を示すフローチャートである。
【図９】本発明の実施形態に係るホストの、アドレス自動設定を終えるまでの動作を示すフローチャートである。
【図１０】図９のS906の動作の詳細を示すフローチャートである。
【図１１】MACフレームの構成例を示す図である。
【図１】
2006173673.tif 000003
【図２】
2006173673.tif 000004
【図３】
2006173673.tif 000005
【図４】
2006173673.tif 000006
【図５】
2006173673.tif 000007
【図６】
2006173673.tif 000008
【図７】
2006173673.tif 000009
【図８】
2006173673.tif 000010
【図９】
2006173673.tif 000011
【図１０】
2006173673.tif 000012
【図１１】
2006173673.tif 000013