JP2004357016A - 特定アドレス使用制限装置 - Google Patents
特定アドレス使用制限装置 Download PDFInfo
- Publication number
- JP2004357016A JP2004357016A JP2003152834A JP2003152834A JP2004357016A JP 2004357016 A JP2004357016 A JP 2004357016A JP 2003152834 A JP2003152834 A JP 2003152834A JP 2003152834 A JP2003152834 A JP 2003152834A JP 2004357016 A JP2004357016 A JP 2004357016A
- Authority
- JP
- Japan
- Prior art keywords
- address
- network address
- ipv6
- specific
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
Abstract
【解決手段】IPv6装置が使用希望または使用するIPv6アドレスが匿名アドレス(temporary address)であるか否かを、その装置のデータリンク層のMACアドレスからIEEE EUI−64形式で生成したアドレスと比較して判断するノードまたはルーター202を、装置と同じサブネット207に設ける。IEEE EUI−64形式のアドレスを使用希望する場合はそれが既に使用されている旨のメッセージをノードが送出して、装置にそのアドレスを使用させない。あるいは、そのアドレスを含むパケットか否かをルーター202が判断して、当該パケットの場合は破棄し、ネットワーク外部へ転送しない。
【選択図】 図2
Description
【発明の属する技術分野】
本発明は、特定アドレスの使用を制限する装置に関する。
【0002】
【従来の技術】
IPv6に対応するパーソナル・コンピュータやワークステーションでは、ネットワークとの接続のインターフェイスには通常はイーサネット(R)が用いられ、それが持つIEEE identifier(MAC address)を元にしてIPv6アドレスが生成される。この方法によって生成されたアドレスをIEEE
EUI−64形式のIPv6アドレスと呼ぶ。
【0003】
IPv6アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと(集約可能)グローバルアドレスの3種類が存在する。
【0004】
それらの詳細や構成方法などのアドレス体系は、RFC 2373 ‘‘IPVersion 6 Addresssing Architecture、’’‘‘ RFC 2374 ‘‘An IPv6 Aggregatabale Global Unicast Address Format、’’ RFC 2375 ’’IPv6 Multicast Address Assignment、’’RFC 2450 ’’Proposed TLA and NLA Assignment Rule、’’RFC2461 ’’Neighbor Discovery for IP Version 6 (IPv6)、’’RFC 2462 ’’IPv6 Stateless Address Autoconfiguration、’’等に記述されている。
【0005】
ところで、IEEE EUI−64形式のIPv6アドレスのように、IEEE identifier (MAC address)等のハードウェアに1対1に対応する情報を固定的に用いて生成されたアドレスを使うと、それが装置もしくはその装置のユーザと1対1に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【0006】
この課題に対しては、ランダムなIPv6アドレス(正確にはinterface ID)を生成する方法が、RFC3041 ’’Privacy Extensions for Stateless Address Autoconfiguration in IPv6、’’等において提案されている。生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算/生成し、ユニークなランダムな値を定めるプロトコル(の拡張)も記述されている。このランダムなIPv6アドレスは、temporary addressあるいは匿名アドレスと呼ばれる。
【0007】
【発明が解決しようとする課題】
しかし、全ての装置が匿名アドレスを常に使うとは限らない。IEEE EUI−64形式のアドレスを使うように初期設定されている装置も存在すると考えられ、その装置がそのアドレスを継続使用するとプライバシが侵害される可能性がある。
【0008】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、ローカルなネットワークに設けた特定アドレス使用制限装置が、ネットワーク上の他の装置がIEEE EUI−64形式のアドレスの使用を試みるか否かを判断し、前記他の装置がIEEE EUI−64形式のアドレス使用を試みる場合は、そのアドレスが既に使用されている旨のメッセージを送る手段を有する。
【0009】
本手段により、ネットワーク上の装置がIEEE EUI−64形式のアドレスを使用することを防ぐことができるので、IEEE EUI−64形式のアドレスを使用した通信をモニターされてプライバシが侵害される可能性を無くすことができる。
【0010】
上記課題を解決するために、本出願の他の発明では、ローカルなネットワークにおけるdefault gatewayが特定アドレス使用制限装置を兼ねる。前記制限装置は、ネットワーク上の他の装置がIEEE EUI−64形式のアドレスを含むデータを送信するか否かを判断し、前記他の装置がIEEE EUI−64形式のアドレスを含むデータを送信する場合は、そのアドレスを記録し、そのアドレスを含むデータをネットワーク外部へ転送しないように処理する制御手段を有する。
【0011】
本手段により、ネットワーク上の他の装置がIEEE EUI−64形式のアドレスを使用してネットワーク外部と通信することを防ぐことができるので、IEEE EUI−64形式のアドレスを使用した通信をモニターされてプライバシが侵害される可能性を無くすことができる。
【0012】
【発明の実施の形態】
(第1の実施の形態)
本実施の形態では、ホストがイーサネット(R)のLAN経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【0013】
図2は、本発明が適用される接続環境(ホストがイーサネット(R)のLAN経由でインターネットと接続する環境)を模式的に示したものである。
【0014】
図2は、LANに接続されたホスト204、205、206がgateway202経由でインターネット201にアクセスする環境を示す。本実施の形態では、各ホストはリンク207で接続するものとし、具体的にはイーサネット(R)であるとする。208もリンクである。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、IP層の下側に接する。リンクにはイーサネット(R)の他に、PPPリンク、X.25、フレームリレー、ATMネットワークがある。リンクに接続されたIPv6装置をノードと呼ぶ。203はDHCPサーバーである。
【0015】
ノードの内部構成の典型例を図3に示す。
【0016】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図3からわかるように、ノード300は、ネットワーク・インターフェイス301、302、CPU303、ROM304、RAM305、HD(ハードディスク)306、電源307、キーボード/ポインティングデバイスのインターフェイス308、モニターのインターフェイス309、バス310等を有する計算機である。
【0017】
ルーターは複数のインターフェイス301、302を持つのに対し、ホストは多くの場合は一つのインターフェイス301を持つ。ネットワーク・インターフェイス301は、リンク207に接続され、リンク207に接続された他のノードと通信する。
【0018】
ホスト204、205、206は、ネットワーク・インターフェイス301により、リンク207を介して、リンク207に接続された他のノード、あるいは、更に、ゲートウェイ202を介して、インターネット201上のサイトと通信する。ゲートウェイ202(ルーター)においては、ネットワーク・インターフェイス301は、リンク207に接続され、それを介してリンク上の他の装置と通信し、ネットワーク・インターフェイス302はリンク208に接続され、それを介してインターネット201と接続され、それらを介してインターネット上のノードと通信する。なお、ノードによってはHDを持たないものもある。
【0019】
なお以下の処理内容(手順)は、装置もしくはプログラムとして実現される。すなわち、装置で実現する形態では、その装置を有するノード300が、以下の処理内容(手順)を実行する。また、プログラムとして実現する形態では、そのプログラムがROM304もしくはHD306に格納されたノードが、以下の処理内容(手順)を実行する。例えば、プログラムとして実現される場合は、そのプログラムをCPU303が読み込み、必要に応じてRAM305を計算のための空間として利用しながらバス310を介してインターフェイス301、302にアドレスを割当てる、というような動作を行なう。
【0020】
本実施の形態のイーサネット(R)LAN環境で各ホストがIPv6グローバルアドレスのプレフィックスやdefault gatewayのアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【0021】
典型的なIPv6アドレスはprefixとinterface IDからなり、prefixが上位64ビット、interface IDが下位64ビットである。interface IDは、イーサネット(R)・インターフェイスのMAC address 48ビットを元にして以下のように生成される。
【0022】
イーサネット(R)のIEEE identifier(MAC address)は、6バイト長のアドレスで、先頭の3バイトは製造ベンダーコードとしてIEEEによって管理・割当てがされている。残り3バイトは各ベンダーに管理が任されており、重複が起こらないように割当てがされる。図4にイーサネット(R)のMAC addressの構成を示す。各四角は1バイト(8ビット)のデータを示し、左から3バイトは製造ベンダーコード、残り3バイトはベンダーが管理するコードとなっている。ベンダーが管理するコードはイーサネット(R)・カード毎に異なるように振られるので、イーサネット(R)・カード毎に世界で唯一のアドレスが対応し、イーサネット(R)上でのデータの送受信の際にアドレスとして利用される。
【0023】
イーサネット(R)のMAC address(図4参照)を3バイトずつに分割し、中間に16進数の「FFFE」をはさみ、先頭から7ビット目を1にする。これを図5に示す。図5のC1’は、図4のC1の先頭から7ビット目を1にしたものを表す。このようにして生成された、図5の構成の64ビット・データをIEEE EUI−64形式のinterface IDと呼ぶ。IEEEEUI−64形式のinterface IDから生成されたIPv6アドレスをIEEE EUI−64形式のIPv6アドレスと呼ぶ。
【0024】
次に、図3のノードが、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図8に示す。この動作はDAD(Duplicate Address Detection)と呼ばれる。以下では図8の流れに沿って処理内容を説明する。
【0025】
ステップS801でノード300が電源を入れられたあるいはリブートされた後、まずネットワーク・インターフェイス301のイーサネット(R)のMACaddress(図4参照)からinterface ID(図5参照)を作成し、それをtentative link−local address(図6参照)とする(ステップS802)。
【0026】
次に、そのtentative link−local addressがリンク207上で一意かどうかを判断するために、ノード300は以下の処理を行なう。
【0027】
最初に、インターフェイス301の初期設定をする。すなわち、インターフェイス301に、all−nodes multicast address(FF02::1)とそのtentative link−local addressのsolicited−node multicast addressを割当てる(図7参照)。つまり、そのインターフェイス301がall−nodes multicast address宛のパケットあるいはそのtentative link−local addressのsolicited−node multicast address宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。
【0028】
前者(all−nodes multicast address)を割当てることによって、既にそのtentative link−local addressを使っている他のノードからのデータを受信することが可能になる。また、後者(そのtentative link−local addressのsolicited−node multicast address)を割当てることによって、同じtentative link−local addressを同時に使おうとしている他のノードの存在を検出することが可能になる。
【0029】
あるtentative link−local addressのsolicited−node multicast addressとは、RFC2461のpage91に定義されているように、tentative link−local addressの下位24ビットをプレフィックスFF02:0:0:0:0:1:FF00::/104に付加したデータであり、link−local scope multicast addressである。図6と図7にそれらの関係を示す。以上のアドレス割当てが図8のステップS803である。
【0030】
次にNeighbor Solicitation messageを作る。Neighbor Solicitation messageのTargetAddress(ターゲットアドレス)には判断対象のtentative link−local addressを、IP Source(送信元アドレス)にはunspecified address(128ビット全てが0)を、IP destination(宛先アドレス)には判断対象のtentative link−local addressのsolicited−node multicast addressを設定する。
【0031】
このNeighbor Solicitation messageをRetransTimerミリセカンド間隔でDupAddrDetectTransmits個イーサネット(R)207に送出する。図8のステップS804がこの処理である。
【0032】
Neighbor Solicitation messageを受け取ったノードは、その送信元アドレスが unspecified addressならば、そのmessageがDADを行っているノードからのデータであることと判断する。
【0033】
同時に複数のノードが同じアドレスを対象としてDADをしている場合は、自分が送ったNeighbor Solicitation messages以外にも、同じアドレスをTarget Addressに含むNeighborSolicitation messagesを受け取る(自分が送ったNeighbor Solicitation messageと、同時にそのアドレスを対象としてDADをしている他のノードが送ったNeighbor Solicitation messageを受け取る)ので、重複していることがわかる。その場合にはどのノードもそのアドレスは使わない。
【0034】
なお、受け取ったNeighbor Solicitation messageが、自分が送ったもの(マルチキャストのパケットをループバックしているため)であるならば、他にそれを使っているあるいは使おうとしているノードが存在することを示さない。自分が送ったNeighbor Solicitation messageに加えて、同じアドレスをTarget Addressに含むNeighbor Solicitation messagesを受け取った場合に、同時に複数のノードが同じアドレスを対象としてDADをしていると判断する。
【0035】
一方、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である場合(図8のS805ステップの「はい」の場合)は判断対象のtentative addressが唯一ではない(つまり、重複している)。
【0036】
以上のDADの結果、判断対象のtentative link−localaddressがリンク207上で唯一であることが確認された(図8のS805ステップの「いいえ」の場合)ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス301に割当てる。これが図8のステップS806である。以上でDADは終了する。
【0037】
以上に説明した図8の動作は図2のgateway 202、DHCP server203、ホスト204、ホスト205、ホスト206のそれぞれが実行することができる。
【0038】
図2のホスト、例えばホスト206は、リンクローカルアドレスをインターフェイス301に割当てたら、次はサイトローカルアドレスやグローバルアドレスを決定するために必要な情報(Router Advertisementと呼ばれる)を入手することを試みる。
【0039】
この動作を図9に示す。gateway202が、Router Advertisementを送る場合を説明する。gateway202は通常はルーターと呼ばれるので以下ではルーター202と記す。ルーター202は管理者によって必要な設定が行われ、Router Advertisementを定期的にリンク207に送っている。ホスト206がRouter Advertisementを早く入手したい場合は、ホスト206はRouter Solicitationと呼ばれるデータをルーター202に送る。ホスト206はリンクローカルアドレスを割当てた直後にはルーター202の存在はわからないので、実際にはRouter Solicitationはリンク上のルーター全てに対するマルチキャストとして送られる。図9のステップS901はこの処理を示す。
【0040】
Router Solicitationを受け取ったルーター202は Router Advertisementを送る。図9のステップS902の「はい」の場合に示すように、Stateless address autoconfigurationのみを指定するRouter Advertisementを受け取ったホスト206は、そのメッセージに含まれるプレフィックスの有効性(既にその装置によって使われていないこと等)を確認し、それ(ら)にインターフェイスIDを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス301に割当てる。図9のステップS903がこの処理である。
【0041】
図9のステップS902の「いいえ」の場合に示すように、ホスト206がstateless address autoconfigurationのみを指定するRouter Advertisementを受け取らなかった場合は、次の二つの場合に分けられる。Stateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementを受け取った場合(ステップS904のはいの場合)と、Router Advertisementを何も受け取らなかった場合(ステップS904のいいえの場合)である。
【0042】
後者の場合はstateful address autoconfiguration、すなわちDHCPv6のみを実行する。これがステップS906であり、その基本的な動作フローチャートを図10に示す。
【0043】
なお、stateful address autoconfigtationにおいてやり取りされるメッセージの内容や形式等の詳細は、“draft−ietf−dhc−dhcpv6−23.txt”もしくはその改訂版に説明されている。以下では図10の番号に沿って基本的な動作の流れを説明する。
【0044】
DHCPサーバー203は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをインターフェイス301に割当ててあり、DHCPサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【0045】
図10のステップS1001で、ホスト204は、DHCPサーバーにDHCP Solicit Messageを送る。ホスト206はどこにDHCPサーバーが存在するのかわからないので、DHCPサーバーに対するマルチキャストとしてリンク207に送出する。ホスト206の接続されているリンク207とは異なるリンク(図示せず)にDHCPサーバーがいる場合には、DHCP Solicit Messageは、実際にはDHCPリレー(図示せず)によって中継されてDHCPサーバー203に届く。
【0046】
DHCP Solicit Messageを受け取ったDHCPサーバー203はそれに対する返答としてDHCP Advertise Messageをホスト206に返す。これは(別リンクの場合はDHCPリレーによって中継されて)ホスト206に届く。これがステップS1002である。この時点でホスト206はDHCPサーバー203のアドレスがわかる。
【0047】
次にステップS1003でホスト206はDHCP Request MessageをDHCPサーバー203に送る。DHCPサーバー203はDHCPRequest Messageを受け取ると、ステップS1004でDHCP Reply Messageをホスト206に送る。
【0048】
ステップS1004でDHCP Reply Message受け取ったホスト206は、それからサイトローカルアドレスもしくはグローバルアドレスがわかるので、そのアドレスの中のinterface IDが重複しているか否かを確認するために、DAD処理に必要な処理を行なう。つまり、インターフェイス301に前述のマルチキャストアドレス等を設定する。これがステップS1005である。
【0049】
次に、ステップS1006でNeighbor Solicitation Messageを送り、Neighbor Advertisement Messageを受け取るかどうかをステップS1007で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをDHCPサーバー203から受け取るためにステップS1003に戻り、同じ処理を繰り返す。
【0050】
ホスト206は、図10のステップS1007でNeighbor Advertisement Messageを受け取らなかった場合はそのアドレスは重複していないので、ステップS1008でそのアドレスをインターフェイス301に割当てる。
【0051】
以上で図9のステップS906が終わる。ステップS904でRouter Advertisementを何も受け取らなかった場合はこれで正常終了する。
【0052】
ステップS902でstateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementを受け取った場合は、ステップS905でstateless addressautoconfigurationとstateful address autoconfigurationの両方を行なう。処理内容はステップS903とS906と同じである。
【0053】
以上のようにして、イーサネット(R)をインターフェイスとして持つホスト206はstateless address autoconfigurationとstateful address autoconfiguration(DHCPv6)を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、default gateway等を自動設定することができる。
【0054】
匿名アドレスを使う場合は、以上のプロトコルが次のように拡張される。図9のステップS903あるいはステップS905において、ホスト206はRouter Advertisementを受け取り、それに含まれるプレフィックスの有効性(既にその装置によって使われていないこと等)を確認し、それ(ら)にインターフェイスIDを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス301に割当てる。この際に、IEEE EUI−64形式で生成したinterfaceIDのみではなく、ランダムなinterfaceIDにも同じ処理を行なう。ランダムなinterfaceIDの生成方法は後述する。
【0055】
新しい匿名アドレスはプレフィックスにランダムなinterfaceIDを付加して作られる。ホスト206が既にインターフェイスに割当てているアドレスと新しい匿名アドレスが同じ場合は、新しいランダムなinterfaceIDを生成し、新しい匿名アドレスを生成する。
【0056】
次に、ホスト206は匿名アドレスを対象にDADを実行する。DADによって、他の装置がその匿名アドレスを既に使用していることがわかった場合は、新しい匿名アドレスを生成する。最大5回まで繰り返し、その結果一意の匿名アドレスを得ることが出来ない場合は、ホスト206はシステム・エラーをログ(記録)に残し、匿名アドレスを生成することをあきらめる。
【0057】
ランダムなinterfaceIDは、MD5message digestを使って生成される。MD5とは任意の入力から、ランダムな128ビットを出力する関数である。RFC3041の方法では128ビットが入力される。この入力128ビットは上位64ビットと下位64ビットから次のように構成される。interface IDを上位64ビットとする。何らかの方法で生成したランダムな値64ビットあるいは前回のMD5の計算結果の下位64ビットを、入力128ビットの下位64ビットとする。この128ビットを入力としてMD5message digestを計算し、その計算結果128ビットの上位64ビットを取り出す。取り出した64ビットの左から7ビット目をゼロにした64ビットをinterface IDとする。計算結果の下位64ビットは、次回のMD5の計算に用いるため、記録しておく。
【0058】
次に本発明の実施の形態を説明する。上述した動作(プロトコル)を利用して、IEEE EUI−64形式のアドレスを使用させないプロトコルを説明する。
【0059】
なお、IPの下層に位置するデータリンク層の通信は、イーサネット(R)の場合、イーサネット(R)・インターフェイスのMAC addressを識別子とする放送型パケット通信である。従って、イーサネット(R)にアクセスできる装置は通信される全てのパケットを観測でき、各パケットの送信元MAC addressと宛先MAC addressを取得することができる。
【0060】
本形態の特定アドレス使用制限装置の動作を、図1にそって説明する。例として、ホスト206がIEEE EUI−64形式のアドレスの使用を試みる場合を説明する。なお以下の処理内容(手順)は、装置もしくはプログラムとして実現される。プログラムとして実現する形態では、そのプログラムがROM304もしくはHD306に格納されたノードが、以下の処理内容(手順)を実行する。図1は、このプログラムの主要部を示す。
【0061】
この場合、リンク207に接続されているならば、どのIPv6装置であってもホスト206のMAC addressを取得できるので、gateway 202、DHCP server203、ホスト204、ホスト205(およびホスト206)のいずれも特定アドレス使用制限装置として動作可能である。
【0062】
IPv6装置が使用希望または使用するIPv6アドレスが匿名アドレス(temporary address)であるか否かを、その装置のデータリンク層のMACアドレスからIEEE EUI−64形式で生成したアドレスと比較して判断するノードまたはルーター202を、装置206と同じサブネット207に設ける。IEEE EUI−64形式のアドレスを使用希望する場合はそれが既に使用されている旨のメッセージをノードが送出して、装置にそのアドレスを使用させない。
【0063】
すなわち、電源を入れられたあるいはリブートされたホスト206がDADを実行する。このDADにおいて、Neighbor Solicitationmessageを受け取った特定アドレス使用制限装置は、ステップS101で、そのTarget Addressを取り出し、それが自身のアドレスと一致するか否かを判断し、一致する場合はステップS107に、一致しない場合はステップS102に進む。
【0064】
ステップS102で、Target Addressの下位64ビット(interfaceID)を取り出す。
【0065】
ステップS103で、取り出したinterfaceIDの左から25〜40ビットが0xFFFEであるか否かを判断し、0xFFFEでない場合は処理を終了し、0xFFFEである場合はステップS104に進む。
【0066】
ステップS104で、取り出したinterfaceIDの左から7ビット目が1であるか否かを判断し、1でない場合は処理を終了し、1の場合はステップS105に進む。
【0067】
ステップS105で、Neighbor Solicitation messageを含むイーサネット(R)・パケットの送信元MAC address(送信元のデータリンク層の識別子であり、送信元の装置固有の識別子である)を取り出す。
【0068】
ステップS106で、送信元MAC address(送信元の装置固有の識別子)からIEEE EUI−64形式で生成した64ビットデータと、ステップS102で取り出したinterfaceIDとが一致するか否かを判断する。一致する場合はステップS107に進み、一致しない場合は終了する。
【0069】
ステップS107でIPv6のNeighbor Discovery Protocolのa multicast Neighbor Advertisementを送る。
【0070】
以上の処理が行なわれると、ホスト206がIEEE EUI−64形式のinterfaceIDとは異なるinterface IDを使おうとするときはa multicast Neighbor Advertisementを受け取らないので、それから生成されるIPv6アドレスを使える。
【0071】
一方、IEEE EUI−64形式のinterfaceIDを使おうとすると、a multicast Neighbor Advertisementを受け取るのでそのinterfaceIDおよびそれから生成されるIPv6アドレスを使えない(可能ならば、他のIPv6アドレスを生成して、用いることになる)。
【0072】
すなわち、送信元であるホスト206が、送信元MACアドレス(送信元のデータリンク層の識別子であり、送信元の装置固有の識別子である)から特定方法で生成したネットワークアドレス(IEEE EUI−64形式のinterfaceIDから生成したIPv6アドレス)の使用を試みると、特定アドレス使用制限装置は、その試みを検出する。そして、そのネットワークアドレスが使用されていることを示すメッセージであるa multicast Neighbor Advertisementを送信することにより、ホスト206にそのネットワークアドレスの使用制限を通知する。
【0073】
従って、プライバシを侵害される可能性をなくすことができる。
【0074】
(第2の実施の形態)
本実施の形態では、IEEE EUI−64形式のinterfaceIDから生成されたアドレスは使用されるが、それを使ってネットワーク外部とは通信させないことにより、プライバシを侵害されないようにする。
【0075】
第1の実施の形態では、IEEE EUI−64形式のinterfaceIDを一切使わせないようになっているので、他のinterfaceIDを生成する手段を持たないIPv6装置は、アドレスを持つことが出来ない。設定の変更をネットワーク経由でのみ行なえるIPv6装置も考えられるので、本実施の形態では、IEEE EUI−64形式のインターフェイスIDから生成したリンクローカルアドレスを使えるようにし、しかし、IEEE EUI−64形式のインターフェイスIDから生成したグローバルアドレスは使えないようにする特定アドレス使用制限装置を提供する。
【0076】
本実施の形態における特定アドレス使用制限装置は、図2におけるgateway202(ルーター)として実現される。図11にそって、その動作を説明する。なお以下の処理内容(手順)は、装置もしくはプログラムとして実現される。プログラムとして実現する形態では、そのプログラムがROM304もしくはHD306に格納されたノードが、以下の処理内容(手順)を実行する。図11は、このプログラムの主要部を示す。特定アドレス使用制限装置は、リストを生成・管理しているものとする。このリストは、RAM305に格納される。このリストには、後述のS1007で、アドレスが登録される。
【0077】
IPv6装置が使用希望または使用するIPv6アドレスが匿名アドレス(temporary address)であるか否かを、その装置のデータリンク層のMACアドレスからIEEE EUI−64形式で生成したアドレスと比較して判断するノードまたはルーター202を、装置と同じサブネット207に設ける。そのアドレスを含むパケットか否かをルーター202が判断して、当該パケットの場合は破棄し、ネットワーク207外部へ転送しない。
【0078】
特定アドレス使用制限装置は、リンク207上のIPv6装置(例えば、ホスト206)から外部ネットワーク201へ転送するものとして受け取ったIPv6パケットを対象に、次の処理を行なう。外部ネットワーク201へ転送するものとして受け取ったIPv6パケットとは、destination addressが、外部ネットワーク201上のアドレスであるIPv6パケットである。
【0079】
ステップS1001で、対象とするIPv6パケットのsource addressを取り出し、それがリストに登録されているか否かを判定する。登録されている場合は、ステップS1008に進む。登録されていない場合は、ステップS1002に進む。
【0080】
ステップS1002で、対象IPv6パケットのsource addressの下位64ビット(インターフェイスID)を取り出す。取り出したinterfaceIDの左から25〜40ビットが0xFFFEであるか否かを判断し、0xFFFEでない場合はステップS1009に進み、0xFFFEである場合はステップS1004に進む。
【0081】
ステップS1004で、取り出したinterfaceIDの左から7ビット目が1であるか否かを判断し、1でない場合はステップS1009に進み、1の場合はステップ1005に進む。
【0082】
ステップ1005で、対象のIPv6パケットを含むイーサネット(R)・パケットの送信元MAC addressを取り出す。
【0083】
ステップ1006で、送信元MAC addressからIEEE EUI−64形式で生成した64ビットデータと、ステップ1002で取り出したinterfaceIDとが一致するか否かを判断する。一致する場合はステップ1007に進み、一致しない場合はステップS1009に進む。
【0084】
ステップ1007で対象IPv6パケットのsource addressをリストに登録し、ステップS1008に進む。したがって、このアドレスがリストに登録された以降、外部ネットワークへのパケットのソースアドレス(発信元アドレス)が、このアドレスであった場合には、S1002からS1007の処理を行なうことなく、S1001からS1008へ進む。
【0085】
ステップS1008で、対象IPv6パケットを破棄し、終了する。
【0086】
ステップS1009で、対象IPv6パケットを外部ネットワーク201に転送し、終了する。
【0087】
以上の動作から明らかなように、IEEE EUI−64形式のinterfaceIDから生成されたグローバルアドレスをsource addressとするIPv6パケットは破棄されるので、外部ネットワーク201に転送されない。
【0088】
一方、IEEE EUI−64形式とは異なるインターフェイスIDから生成されたグローバルアドレスをsource addressとするIPv6パケットは、外部ネットワーク201に転送される。
【0089】
すなわち、送信元であるホスト206のMACアドレス(データリンク層の識別子であり、装置固有の識別子である)から特定方法で生成したネットワークアドレス(IEEE EUI−64形式のインターフェイスIDから生成したIPv6アドレス)を含むデータの送信を、特定アドレス使用制限装置が検出し、そのデータの転送を中止する。
【0090】
従って、プライバシを侵害される可能性をなくすことができる。
【0091】
【発明の効果】
本発明によれば、プライバシの侵害を防ぐことができる。
【0092】
IPv6ネットワークにおいて、特定方法、例えばIEEE EUI−64形式でinterfaceIDを生成する装置、あるいはIEEE EUI−64形式で生成されたinterfaceIDからIPv6アドレスを生成する装置が、そのinterfaceIDあるいはそのIPv6アドレスを使用できないようにすることができる。従って、そのIPv6アドレスを使用することによりプライバシを侵害される可能性をなくす効果が得られる。
【0093】
これにより、IEEE EUI−64形式で生成されたinterfaceIDを使用してしまうことがなくなり、IPv6装置およびそのユーザのプライバシを保護できる。
【0094】
また、プライバシが侵害される恐れがあるアドレスを用いて、ネットワーク外部とは通信できないようにすることができる。
【0095】
IEEE EUI−64形式のアドレスを使用することは可能だが、それを用いてネットワーク外部とは通信できないようにすることができる。
【0096】
これにより、IEEE EUI−64形式のアドレスを使ってネットワーク内部の通信は行なえるので、ネットワーク設定が簡便であるというIPv6がそもそも持つ特徴を維持しながら、IEEE EUI−64形式で生成されたinterfaceIDを不用意に使用してしまうことはなくなるので、IPv6装置のユーザの使い勝手を悪くせずにプライバシを保護できる。
【0097】
対象とするIPv6装置そのものにはいかなる変更も加えないので、既存のIPv6装置を対象に上記効果を得ることができる。
【図面の簡単な説明】
【図1】アドレス判断の動作フローチャートである。
【図2】イーサネット(R)LANの模式図である。
【図3】ノードの構成図である。
【図4】イーサネット(R)のMAC addressの構成図である。
【図5】interfaceIDの構成図である。
【図6】a tentative link−local addressの構成図である。
【図7】あるtentative link−local addressのsolicited−node multicast addressの構成図である。
【図8】ホストがDADを終えるまでの動作を説明するフローチャート図である。
【図9】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図10】ホストがDHCPでアドレスを取得するまでの動作フローチャート図である。
【図11】転送判断の動作フローチャートである。
【符号の説明】
201 インターネット
202 gateway
203 DHCPサーバー
204 ホスト
205 ホスト
206 ホスト
207 リンク
208 リンク
Claims (7)
- 他の装置が装置固有の識別子から特定方法で生成したネットワークアドレスの使用を試みていることを検出する検出手段と、
前記試みを検出すると、前記ネットワークアドレスの使用制限を通知する手段とを有することを特徴とする特定アドレス使用制限装置。 - 前記ネットワークアドレスは、Internet Protocol Version 6(IPv6)のネットワークアドレスであり、前記装置固有の識別子からネットワークアドレスを生成する特定方法は、IEEE EUI−64形式のインターフェイスIDを用いてネットワークアドレスを生成する方法であり、前記通知手段は、IPv6のNeighbor Discovery Protocolのa multicast Neighbor Advertisementを送信する手段であることを特徴とする前記請求項1記載の特定アドレス使用制限装置。
- 他の装置が、装置固有の識別子から特定方法で生成したネットワークアドレスを含むデータを送信したことを検出する検出手段と、
前記送信を検出すると、特定ネットワークアドレスを含むデータの転送を中止する手段とを有することを特徴とする外部ネットワークとの中継を行なう特定アドレス使用制限装置。 - 前記ネットワークアドレスは、Internet Protocol Version 6(IPv6)のネットワークアドレスであり、前記装置固有の識別子からネットワークアドレスを生成する特定方法は、IEEE EUI−64形式のインターフェイスIDを用いてネットワークアドレスを生成する方法であり、前記転送中止手段は、IPv6のグローバルアドレスを用いたパケットをネットワーク外部に転送しない手段であることを特徴とする前記請求項3記載の特定アドレス使用制限装置。
- 他の装置が装置固有の識別子から特定方法で生成したネットワークアドレスの使用を試みていることを検出し、
前記試みを検出すると、前記ネットワークアドレスの使用制限を通知する手段とを有することを特徴とする特定アドレス使用制限方法。 - 他の装置が、装置固有の識別子から特定方法で生成したネットワークアドレスを含むデータを送信したことを検出し、
前記送信を検出すると、特定ネットワークアドレスを含むデータの転送を中止する手段とを有することを特徴とする外部ネットワークとの中継方法。 - 請求項5又は6の方法を実行するプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003152834A JP4054719B2 (ja) | 2003-05-29 | 2003-05-29 | 特定アドレス使用制限装置 |
US10/799,215 US7530100B2 (en) | 2003-05-29 | 2004-03-11 | Apparatus for limiting use of particular network address |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003152834A JP4054719B2 (ja) | 2003-05-29 | 2003-05-29 | 特定アドレス使用制限装置 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2004357016A true JP2004357016A (ja) | 2004-12-16 |
JP2004357016A5 JP2004357016A5 (ja) | 2006-02-02 |
JP4054719B2 JP4054719B2 (ja) | 2008-03-05 |
Family
ID=33447806
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003152834A Expired - Fee Related JP4054719B2 (ja) | 2003-05-29 | 2003-05-29 | 特定アドレス使用制限装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US7530100B2 (ja) |
JP (1) | JP4054719B2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006253811A (ja) * | 2005-03-08 | 2006-09-21 | Ricoh Co Ltd | 電子機器、ipアドレス決定方法、ipアドレス決定プログラム、ipアドレス決定プログラムを記録した記録媒体 |
WO2012014928A1 (ja) * | 2010-07-27 | 2012-02-02 | パナソニック株式会社 | ユーザ認証システム、認証装置及びプログラム |
US9866524B2 (en) | 2013-03-29 | 2018-01-09 | Nec Platforms, Ltd. | Home gateway apparatus and packet transfer method |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050271049A1 (en) * | 2004-06-03 | 2005-12-08 | International Business Machines Corporation | DHCP cache method and apparatus |
US8462808B2 (en) * | 2004-09-02 | 2013-06-11 | Brother Kogyo Kabushiki Kaisha | Information server and communication apparatus |
JP2008294940A (ja) * | 2007-05-28 | 2008-12-04 | Toshiba Corp | クライアント装置並びにアドレス割当のための方法およびプログラム |
US7962584B2 (en) * | 2008-02-13 | 2011-06-14 | Futurewei Technologies, Inc. | Usage of host generating interface identifiers in DHCPv6 |
CN101547383B (zh) * | 2008-03-26 | 2013-06-05 | 华为技术有限公司 | 一种接入认证方法及接入认证***以及相关设备 |
CN101547223B (zh) * | 2008-03-26 | 2012-11-21 | 华为技术有限公司 | 地址配置方法、装置和*** |
US8782746B2 (en) | 2008-10-17 | 2014-07-15 | Comcast Cable Communications, Llc | System and method for supporting multiple identities for a secure identity device |
CN102571592B (zh) * | 2012-01-18 | 2016-02-24 | 神州数码网络(北京)有限公司 | 具有端口绑定功能的三层交换设备和数据报文转发方法 |
US9344365B1 (en) * | 2015-02-03 | 2016-05-17 | Google Inc. | Mesh network addressing |
CN109981813B (zh) * | 2019-03-19 | 2021-09-17 | 新华三技术有限公司 | 报文处理方法及装置 |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6093207A (en) * | 1994-03-18 | 2000-07-25 | Pisharodi; Madhavan | Middle expanded, removable intervertebral disk stabilizer disk |
US5885299A (en) * | 1994-09-15 | 1999-03-23 | Surgical Dynamics, Inc. | Apparatus and method for implant insertion |
US5826014A (en) * | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
US6324267B1 (en) * | 1997-01-17 | 2001-11-27 | Scientific-Atlanta, Inc. | Two-tiered authorization and authentication for a cable data delivery system |
US5888226A (en) * | 1997-11-12 | 1999-03-30 | Rogozinski; Chaim | Intervertebral prosthetic disc |
US6101499A (en) * | 1998-04-08 | 2000-08-08 | Microsoft Corporation | Method and computer program product for automatically generating an internet protocol (IP) address |
US7039688B2 (en) * | 1998-11-12 | 2006-05-02 | Ricoh Co., Ltd. | Method and apparatus for automatic network configuration |
ATE275788T1 (de) * | 1999-05-03 | 2004-09-15 | Nokia Corp | Sim authentifizierungsmechanismus für dhcrv4/v6 nachrichten |
US6629149B1 (en) * | 1999-08-17 | 2003-09-30 | At&T Corp. | Network system and method |
FI109950B (fi) * | 2000-01-20 | 2002-10-31 | Nokia Corp | Osoitteen saanti |
JP2002190816A (ja) * | 2000-12-20 | 2002-07-05 | Nec Corp | 無線通信システム |
GB2367986B (en) * | 2001-03-16 | 2002-10-09 | Ericsson Telefon Ab L M | Address mechanisms in internet protocol |
US20030026230A1 (en) * | 2001-08-02 | 2003-02-06 | Juan-Antonio Ibanez | Proxy duplicate address detection for dynamic address allocation |
US6745333B1 (en) * | 2002-01-31 | 2004-06-01 | 3Com Corporation | Method for detecting unauthorized network access by having a NIC monitor for packets purporting to be from itself |
US6930988B2 (en) * | 2002-10-28 | 2005-08-16 | Nokia Corporation | Method and system for fast IP connectivity in a mobile network |
US7246231B2 (en) * | 2002-10-31 | 2007-07-17 | Ntt Docomo, Inc. | Location privacy through IP address space scrambling |
-
2003
- 2003-05-29 JP JP2003152834A patent/JP4054719B2/ja not_active Expired - Fee Related
-
2004
- 2004-03-11 US US10/799,215 patent/US7530100B2/en active Active
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006253811A (ja) * | 2005-03-08 | 2006-09-21 | Ricoh Co Ltd | 電子機器、ipアドレス決定方法、ipアドレス決定プログラム、ipアドレス決定プログラムを記録した記録媒体 |
WO2012014928A1 (ja) * | 2010-07-27 | 2012-02-02 | パナソニック株式会社 | ユーザ認証システム、認証装置及びプログラム |
JP2012027844A (ja) * | 2010-07-27 | 2012-02-09 | Panasonic Electric Works Co Ltd | ユーザ認証システム、認証装置及びプログラム |
US9866524B2 (en) | 2013-03-29 | 2018-01-09 | Nec Platforms, Ltd. | Home gateway apparatus and packet transfer method |
Also Published As
Publication number | Publication date |
---|---|
US20040243850A1 (en) | 2004-12-02 |
JP4054719B2 (ja) | 2008-03-05 |
US7530100B2 (en) | 2009-05-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Cheshire et al. | Dynamic configuration of IPv4 link-local addresses | |
US8543669B2 (en) | Network switch and method of preventing IP address collision | |
US9860207B2 (en) | Methods of using beacon messages to discover devices across subnets | |
KR100538223B1 (ko) | 모바일 노드와 대응 노드간 접속 시 터널링 제거 시스템및 방법 | |
Thaler | Multi-link subnet issues | |
JP2007036374A (ja) | パケット転送装置、通信網及びパケット転送方法 | |
KR20040065643A (ko) | IPv6 프로토콜을 위한 IP 주소 및 도메인명자동등록 방법 | |
JP4054719B2 (ja) | 特定アドレス使用制限装置 | |
WO2009117963A1 (zh) | 地址配置方法、装置和*** | |
JP2004040804A (ja) | 重複アドレスノードに仮想アドレスを自動で割り当てる装置及び方法 | |
US8438390B2 (en) | Method and system for using neighbor discovery unspecified solicitation to obtain link local address | |
JP6137178B2 (ja) | 通信情報検出装置及び通信情報検出方法 | |
JP3858884B2 (ja) | ネットワークアクセスゲートウェイ及びネットワークアクセスゲートウェイの制御方法並びにプログラム | |
Cheshire et al. | RFC 3927: Dynamic configuration of IPv4 link-local addresses | |
Atkinson et al. | A proposal for unifying mobility with multi-homing, NAT, & security | |
JP2007104396A (ja) | 不正接続防止システムおよび方法、プログラム | |
JP7376289B2 (ja) | アドレス監視装置およびアドレス監視方法 | |
JP2005086256A (ja) | トンネルゲートウェイ装置 | |
Singh et al. | IPv6 subnet model: the relationship between links and subnet prefixes | |
Mrugalski et al. | RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | |
JP5310734B2 (ja) | 通信装置、通信装置の制御方法、及びネットワークシステム | |
JP2004135108A (ja) | 通信制御方法、通信端末、ルータ、通信端末の制御プログラム、およびルータの制御プログラム | |
US10298481B1 (en) | Method and apparatus for testing VLAN | |
JP2006173673A (ja) | 通信装置およびその制御方法 | |
JP2004056477A (ja) | 通信制御装置及び方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051213 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051213 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070726 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070904 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071030 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071127 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071210 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101214 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4054719 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111214 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121214 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131214 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |