JP2006173673A

JP2006173673A - 通信装置およびその制御方法

Info

Publication number: JP2006173673A
Application number: JP2004359119A
Authority: JP
Inventors: Kazuomi Oishi; 和臣大石
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-12-10
Filing date: 2004-12-10
Publication date: 2006-06-29

Abstract

【課題】通信速度の低下およびコストの上昇を最小限に抑えつつ、トラヒック解析等の攻撃に対して効力を有する通信技術を実現する。
【解決手段】通信装置は、ネットワークを構成するリンクに通信インターフェイスを介して接続される。この通信装置の電源が投入されあるいはリブートされると（Ｓ８０１）、例えば仮のリンクローカル・アドレスを生成することでランダムなMACアドレスを生成し（Ｓ８０２）、生成したそのランダムなMACアドレスがリンク内で一意であることを確認する（Ｓ８０３〜Ｓ８０５）。そして、上記ランダムなMACアドレスがリンク内で一意であることが確認された場合に、当該ランダムなMACアドレスを通信インターフェイスに割り当てる（Ｓ８０６）。
【選択図】図８

Description

本発明は、通信装置およびその制御方法に関し、例えば、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)をイーサネット(登録商標)インターフェイスに設定する。

ある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がこの処理である。

以上の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アドレスを設定する。

ホスト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を用いて誤りを検出し、上位のプロトコル・スタックにデータを渡す。

ルーター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アドレスを設定する。

ホスト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フレームの構成例を示す図である。

Claims

ネットワークに接続するインターフェイス部と、
ランダムな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をリンクローカル・アドレスとして割り当てるステップと、
を有することを特徴とする通信装置の制御方法。
請求項７から９までのいずれかに記載の通信装置の制御方法を実現するためのプログラム。