JP2005295217A - 通信装置、名前解決方法およびプログラム - Google Patents

Abstract

【課題】ＩＰｖ６のリンクローカル内の各ＩＰｖ６ノードのグローバルアドレスを容易に取得することができる名前解決方法及び通信装置を提供する。
【解決手段】ＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ第１のノード装置が、第１のアドレスで通信可能なネットワーク上の第２のノード装置から取得したＩＰｖ６アドレスがリンクローカルアドレスである場合には、当該取得したリンクローカルアドレスに含まれる第２のノード装置のインターフェイスＩＤと、第１のノード装置で利用可能なグローバルアドレスのプレフィックスとを組み合わせて、第２のノード装置のアドレス候補を生成し、宛先をアドレス候補とするＩＣＭＰｖ６のＮＩｑｕｅｒｙメッセージを送信し、当該アドレス候補を送信元アドレスとするＩＣＭＰｖ６のＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を第２のノード装置のグローバルアドレスと判定する。
【選択図】 図５

Description

本発明は、ＩＰ（internet protocol）ｖ６の名前解決方法および当該名前解決方法を用いた通信装置に関する。

近年、世界最大のコンピュータネットワーク（インターネット（Internet））の利用が普及しており、インターネットと接続し、公開された情報、サービスを利用したり、逆にインターネットを通してアクセスしてくる外部ユーザに対し、情報、サービスを提供することで、新たなコンピュータビジネスが開拓されている。またインターネット利用に関して、新たな技術開発、展開がなされている。

インターネットでは、各計算機がＩＰアドレスと呼ばれる識別子をもち、このＩＰアドレスを元に、パケットの交換が行われる。しかし、ＩＰアドレスはいわば数字であり、人間がそのまま使用するには直感的ではなく簡便性に欠ける。そのため、ＩＰｖ６アドレスと人間がより扱いやすい形である文字列、すなわち「名前」との変換のメカニズムが使われる。現在インターネットで最も利用されている変換システムにＤＮＳ（Domain Name System）がある。ＤＮＳはインターネット上でのグローバルな名前解決に用いられるため、ＤＮＳで利用される名前ＦＱＤＮ（Fully Qualified Domain Name）はやはりインターネット上で一意でなければならない。

一方、インターネットの普及に伴いすべてのノード機器（端末）がグローバルユニークな名前を持つ必要性は少なくなってきている。また、ＤＮＳでは、その性質上名前の公開について、あるノードの名前を特定のメンバにのみ公開するということはできない。よって、あるドメインがどのような名前を持つかはｂｒｕｔｅ ｆｏｒｃｅ的に発見することが可能であり、どのような名前をもつノードが存在するかという情報を悪意を持つ第三者が用意に入手することが可能となる。これはプライバシーの漏洩という問題を内包する。さらに、ＦＱＤＮを利用するためにはそのＦＱＤＮを管理するＤＮＳサーバを用意する必要があるが、このサーバの設置場所、管理、登録、運営という課題が発生する。

家庭内のような小さなネットワークにおいては、ネットワーク上にローカルに名前を定めてそれによってノードへのアクセスを行なう技術もいくつかある。しかし、これらの技術は、名前によって指定される通信相手がネットワーク的に近傍にいることが前提となっており、そのネットワークの外部から名前によってアクセスしようとした場合に直接利用することはできない。この場合には外部からの解決を受け持つ専用のサーバが必要であったり、そのためのサーバを発見するためのプロトコルが必要であったり、ユーザの利便性を損なう。

これらの問題を避けるために、例えばあるネットワーク内／管理ドメイン内だけで有効な名前を定めて利用する方法が考えられる。このような場合にはＤＮＳなどを利用せず、各ノードが自律的に名前解決をネットワークを利用して行なうことが考えられる。例えばＩＰｖ６ではＩＣＭＰｖ６（internet control message protocol v6）を利用して通信しているノードの名前（ＦＱＤＮやアドレス）をＮＩ（node information）ｑｕｅｒｙを用いて知ることができる（例えば、非特許文献１参照）。

このような手法を利用する場合、一般的にネットワーク上にあるノードの名前を収集して、アドレスとの対応をとるという手法が考えられる。しかしこのような方法を取ると、ＩＰｖ６ではその名前に対応するアドレスとしてリンクローカルアドレスを取得してしまう可能性がある。

リンクローカルアドレスは、ＩＰｖ６特有のアドレスで、当該アドレスをもつ端末はルータを介さずに直接通信できる範囲（リンクローカル）だけで通用するアドレスである。このアドレスを完全な情報として扱うにはアドレスの値の他に、パケットをやりとりするインターフェイスを示すｓｃｏｐｅｉｄ（例えば、イーサネット（Ｒ）のインターフェイスや無線ＬＡＮのインターフェイスなどのうちのどのインターフェイスかを示す番号）が必要となる。しかしｓｃｏｐｅｉｄの値の意味は各ノードによって異なるため、リンクローカルアドレスの完全な情報を他のノードに教えることは難しかった。
draft-ieft-ipngwg-icmp-name-lookups-10、［online］、２００３年６月２６日、IPng Working Group Internet Draft、［平成１６年３月１０日検索］、インターネット ＜URL：http://www.waterspriongs.org/pub/id/draft-ieft-ipngwg-icmp-name-lookups-10.txt＞

このように、従来の名前解決手法では、ＩＰｖ６ノードが同じリンクローカル内の他のＩＰｖ６ノードのグローバルアドレスを容易に取得することができないという問題点があった。

そこで、本発明は、上記問題点に鑑み、ＩＰｖ６のリンクローカル内の各ＩＰｖ６ノードのグローバルアドレスを容易に取得することができる、名前解決方法および、それを用いた通信装置、プログラムを提供することを目的とする。

本発明は、少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ第１のノード装置が、前記第１のアドレスで通信可能なネットワーク上の第２のノード装置から取得したＩＰｖ６アドレスが、リンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合には、（ａ）当該取得したリンクローカルアドレスに含まれる第２のノード装置のインターフェイスＩＤと、第１のノード装置で利用可能なグローバルアドレスのプレフィックスとを組み合わせて、第２のノード装置のアドレス候補を生成し、（ｂ）宛先をアドレス候補とするＩＣＭＰｖ６のＮＩｑｕｅｒｙメッセージを送信し、（ｃ）当該アドレス候補を送信元アドレスとするＩＣＭＰｖ６のＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を第２のノード装置のグローバルアドレスと判定する。

また、本発明は、少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ第１のノード装置が、前記第１のアドレスで通信可能なネットワーク上の第２のノード装置から取得したＩＰｖ６アドレスが、リンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合には、（ａ）第２のノード装置のグローバルアドレスを得るために、宛先を当該取得したリンクローカルアドレスとするＩＣＭＰｖ６のＮＩｑｕｅｒｙメッセージを送信し、（ｂ）第２のノード装置のリンクローカルアドレスを送信元アドレスとするＩＭＣＰｖ６のＮＩｒｅｐｌｙメッセージを受信することにより、当該ＮＩｒｅｐｌｙメッセージに含まれる第２のノード装置のグローバルアドレスを取得する。

本発明によれば、ＩＰｖ６のリンクローカル内の各ＩＰｖ６ノードのグローバルアドレスを容易に取得することができる。

以下、本発明の実施形態について図面を参照して説明する。

図１は、本発明の名前解決方法を用いたＩＰｖ６ノード（通信装置）の要部の構成例を示したもので、アドレス要求部１とアドレス応答部２とアドレス判断部３とアドレス変換部４と送受信部５と記憶部６からなる。ここで、ＩＰｖ６ノードとは、ＩＰｖ６を用いて通信を行う通信装置である。

アドレス要求部１は、同一ネットワーク内の他のＩＰｖ６ノードに名前（例えば、ホスト名、ドメイン名、ＦＱＤＭ）やアドレスを尋ねる（要求する）ためのＩＣＭＰｖ６の要求メッセージ（ＮＩｑｕｅｒｙ）を生成する。

アドレス応答部２は、他のＩＰｖ６ノードから送信された上記ＮＩｑｕｅｒｙに対するＩＭＣＰｖ６の応答メッセージ（ＮＩｒｅｐｌｙ）を生成する。

アドレス判断部３は、他のＩＰｖ６ノードから送信された上記ＮＩｒｅｐｌｙにより、当該他のＩＰｖ６ノードのグローバルアドレスが得られたか、リンクローカルアドレスが得られたのかをチェックする。グローバルアドレスが得られたときには、当該他のＩＰｖ６ノードの名前とともに当該グローバルアドレスを記憶部６に記憶する。一方、リンクローカルアドレスが得られたときには、当該他のＩＰｖ６ノードのグローバルアドレスを取得すべく、アドレス変換部４を起動する。

アドレス変換部４は、当該他のＩＰｖ６ノードのリンクローカルアドレスを基に、当該他のＩＰｖ６ノードのグローバルアドレスを得るための処理動作を行う。

記憶部６には、自装置の名前（ホスト名、ドメイン名、ＦＱＤＭ）やＩＰｖ６アドレス（ローカルアドレスのプレフィックス、グローバルアドレスのプレフィックス、ｓｃｏｐｅｉｄ、インターフェイスＩＤ）や、他のＩＰｖ６ノードの名前（ホスト名／ＦＱＤＭ）、ＩＰｖ６アドレス（ローカルアドレスのプレフィックス、グローバルアドレスのプレフィックス、ｓｃｏｐｅｉｄ、インターフェイスＩＤ）を記憶する。

送受信部５は、アドレス要求部１やアドレス変換部４で生成されたＮＩｑｕｅｒｙなどのメッセージを送信し、他のＩＰｖ６ノードからから送信されたＮＩｒｅｐｌｙなどのメッセージを受信して、上記各構成部１〜４へ渡す。

図１に示した構成によれば、ＩＰｖ６ノードにアドレス判断部３とアドレス変換部４を追加することで、ＮＩｑｕｅｒｙにより得られた他のＩＰｖ６ノードのリンクローカルアドレスを基に、当該当該他のＩＰｖ６ノードのグローバルアドレスを得ることができるのである。

次に、図２を参照して、図１に示し構成をもつＩＰｖ６ノードの処理動作について説明する。

図２において、ＩＰｖ６ノードである端末Ａ、Ｂ、Ｃは、例えばイーサネット（Ｒ）などのデータリンク層のプロトコルで通信するローカルネットワーク（ＬＡＮ）５０に接続して互いに通信可能であるとする。少なくとも端末Ａ、Ｂ、Ｃは同じリンクローカル内にあるものとする。

ＩＰｖ６ノードである端末Ｄは、端末Ａ、Ｂ、Ｃの接続されているＬＡＮ５０とは異なるネットワークに接続され（端末Ｄは、端末Ａ、Ｂ、Ｃとは異なるリンクローカルに存在する）、ルータを介して端末Ａ、Ｂ、Ｃのうちのいずれかと通信可能であるとする。

端末ＡのＦＱＤＮを「ｎｏｄｅＡ」、端末ＢのＦＱＤＮを「ｎｏｄｅＢ」、端末ＣのＦＱＤＮを「ｎｏｄｅＣ」、端末ＤのＦＱＤＮを「ｎｏｄｅＤ」とする。

また、当該リンクローカル上で用いられるリンクローカルアドレスのプレフィックス（ｐｒｅｆｉｘ）が「Ｌ」、グローバルアドレスのプレフィックスが「Ｐ１」、「Ｐ２」、「Ｐ３」であるとする。

端末Ａはｓｃｏｐｅｉｄ「Ｓａ」、インターフェイスＩＤ「ａ」をもち、端末Ｂはｓｃｏｐｅｉｄ「Ｓｂ１」、インターフェイスＩＤ「ｂ」をもち、端末Ｃはｓｃｏｐｅｉｄ「Ｓｃ」、インターフェイスＩＤ「ｃ」をもつ。なお、端末Ｂは、ＬＡＮ５０とは異なるインターフェイスを通じて通信するためのｓｃｏｐｅｉｄ「Ｓｂ２」をもつものとする。

端末Ｃは何らかの理由でグローバルアドレスのプレフィックス「Ｐ１」を利用していなかったとする。同様に端末Ａは何らかの理由でグローバルアドレスのプレフィックス「Ｐ３」を利用していないものとする。

従って、端末Ａはリンクローカルアドレス「Ｌ：：ａ」、グローバルアドレス「Ｐ１：：ａ」及び「Ｐ２：：ａ」を利用し、端末Ｂはリンクローカルアドレス「Ｌ：：ｂ」、グローバルアドレス「Ｐ１：：ｂ」、「Ｐ２：：ｂ」及び「Ｐ２：：ｂ」を利用し、端末Ｃは、リンクローカルアドレス「Ｌ：：ｃ」、グローバルアドレス「Ｐ２：：ｃ」及び「Ｐ２：：ｃ」を利用している。

端末Ａが、同じネットワーク（リンクローカル）上の各端末から、各端末のもつ名前を取得するには、例えばＮＩｑｕｅｒｙをリンクローカル内でマルチキャストする。このときのＮＩｑｕｅｒｙのソースアドレス（送信元アドレスｓｒｃ）はリンクローカルアドレスであると、各端末は、各端末のローカルリンクアドレスをソースアドレスとするＮＩｒｅｐｌｙを返してくる。

このとき、端末Ａが知りうる情報は、図３に示すように、端末Ｂ及び端末Ｃのそれぞれの名前とリンクローカルアドレスである。

この得られたリンクローカルアドレスは、端末Ａでしか意味を持たない。例えば、端末Ｄが端末Ｃと通信したい場合には、端末Ｃのアドレスを知る必要があるが、「ｎｏｄｅＣ」という名前はグローバルな名前でないとすると（例えば、ＤＮＳ（domain name system）に登録されていない場合）、ローカルな名前解決が必要となる。一方で、端末Ｄは、端末Ａ〜Ｃとは異なるリンクローカル内に存在するので、同一のリンクローカルにいることを仮定した名前解決方式を利用することは出来ない。そのため、例えば端末Ｄは、端末Ｃが存在するリンクローカル内の端末（例えば、端末Ａ）に、端末Ｃのアドレスを聞くという手法が考えられる。

しかし、この例では、端末Ａが知っているのは端末Ｃのリンクローカルアドレスであるので、端末Ａ、Ｃとは異なるリンクローカルにいる端末Ｄは、このアドレスを知っても無意味である。

また、例えば、端末Ｂがこのようなリンクローカル内での名前解決メカニズムを持っていない、あるいは端末Ａがリンクローカル内での名前を格納するような場合などには、端末Ｂは端末Ａに「ｎｏｄｅＣ」のアドレスを問い合わせるという場合が考えられる。このような場合でも、ｓｃｏｐｅｉｄが端末Ａと端末Ｂでは異なるので問題である。すなわち、「Ｓａ」というｓｃｏｐｅｉｄは端末Ｂには意味がなく、端末Ｃが「Ｓｂ１」に対応するインターフェイス側に存在するのかそれとも「Ｓｂ２」に対応するインターフェイス側に存在するのかはこのアドレス情報からだけではわからないである。

そのため、本実施形態では、端末Ａは、リンクローカルアドレスを入手した場合には、これをグローバルアドレスに変換する。

ここでは、少なくとも端末Ａが図１に示す構成を有する。他の端末には、図１に示す構成部１〜６のうちアドレス判断部３及びアドレス変換部４がなくともよい。

次に、図４、図５を参照して、端末Ａにおける名前解決処理動作について説明する。本実施形態にかかる名前解決手法は、リンクローカルアドレスが得られたときには、それをグローバルアドレスへ変換する（グローバルアドレスを取得する）ようになっている。

まず、図４を参照して、第１の名前解決方法を用いた端末Ａの処理動作について説明する。第１の名前解決方法では、ある端末のリンクローカルアドレスを入手した場合、当該端末からアドレスを問い合わせるための（ＩＣＭＰで定義されている）ＮＩｑｕｅｒｙを用いる、というものである。まず、端末Ａが同じリンクローカル内の各端末から、それぞれの名前を問い合わせる動作から説明する。

端末Ａのアドレス要求部１は、同じリンクローカル内の各端末の名前を問い合わせるためのＮＩｑｕｅｒｙを生成する。このとき生成されるＮＩｑｕｅｒｙの「Ｑｔｙｐｅ」というエリアには名前を要求するクエリであることを示す情報「ＦＱＤＮ」が記述され、ソースアドレス（ｓｒｃ）は端末Ａのリンクローカルアドレス「Ｌ：：ａ」、宛先（ｄｓｔ）は「ｍｕｌｔｉｃａｓｔ」である。アドレス要求部１で生成されたＮＩｑｕｅｒｙは送受信部５から、リンクローカル内にマルチキャストされる（ステップＳ１）。

端末Ａと同じリンクローカルに存在する端末Ｂ、Ｃの送受信部５は、当該ＮＩｑｕｅｒｙを受信すると、アドレス応答部２は、それぞれの名前を通知するための（ＩＣＭＰで定義されている）ＮＩｒｅｐｌｙを生成する。例えば、端末Ｃのアドレス応答部２で生成されるＮＩｒｅｐｌｙの「Ｄａｔａ」というエリアには、（ＮＩｑｕｅｒｙで要求された）端末Ｃの名前が記述され、ソースアドレス（ｓｒｃ）は端末Ｃのリンクローカルアドレス「Ｌ：：ｃ」、宛先（ｄｓｔ）は「Ｌ：：ａ」である。端末Ｂ、Ｃのアドレス応答部２１で生成されたＮＩｒｅｐｌｙは送受信部５から端末Ａへ送信される（ステップＳ２）。

以上は従来のＩＭＣＰｖ６の名前解決手法と同様である。

以下、端末Ｃと端末Ａとの間についてのみ説明するが、端末Ｂと端末Ａとの間も同様である。

端末Ａの送受信部５は端末Ｃから送信されたＮＩｒｅｐｌｙを受信すると、アドレス判断部３は、当該ＮＩｒｅｐｌｙのソースアドレスが記述されているエリアを調べ、当該エリア内のアドレスがリンクローカルアドレスかグローバルアドレスかを判断する（ステップＳ３）。例えば、ソースアドレスのプレフィックスが「Ｌ」であるときには、リンクローカルアドレスと判断し、「Ｐ１」「Ｐ２」「Ｐ３」のいずれかであるときにはグローバルアドレスと判断する。

ソースアドレスがグローバルアドレスの場合には、アドレス判断部３は、端末ＣからのＮＩｒｅｐｌｙに含まれていた当該端末の名前と当該名前に対応するグローバルアドレスとを記憶部６に記憶して、動作を終了する。一方、ソースアドレスがリンクローカルアドレスの場合には、アドレス判断部３は、アドレス変換部４を起動する。

アドレス変換部４は、先のステップＳ１〜ステップＳ２の処理により、端末Ｃが「Ｌ：：ｃ」というローカルアドレスをもっていることがわかったので、端末Ｃのグローバルアドレスを問い合わせるためのＮＩｑｕｅｒｙを生成する。このとき生成されるＮＩｑｕｅｒｙの「Ｑｔｙｐｅ」というエリアにはアドレスを要求するクエリであることを示す情報「ａｄｄｒｅｓｓ」が記述され、ソースアドレス（ｓｒｃ）は端末Ａのリンクローカルアドレス「Ｌ：：ａ」、宛先（ｄｓｔ）は端末Ｃのリンクローカルアドレス「Ｌ：：ｃ」である。アドレス変換部４で生成されたＮＩｑｕｅｒｙは送受信部５から端末Ｃへ送信される（ステップＳ４）。

端末Ｃの送受信部５は、当該ＮＩｑｕｅｒｙを受信すると、アドレス応答部２は、端末Ｃのアドレスを通知するための（ＩＣＭＰで定義されている）ＮＩｒｅｐｌｙを生成する。例えば、端末Ｃのアドレス応答部２で生成されるＮＩｒｅｐｌｙの「Ｄａｔａ」というエリアには、（ＮＩｑｕｅｒｙで要求された）端末Ｃのアドレス「Ｐ２：：ｃ」及び「Ｐ３：：ｃ」が記述され、当該ＮＩｒｅｐｌｙのソースアドレス（ｓｒｃ）は端末Ｃのリンクローカルアドレス「Ｌ：：ｃ」、宛先（ｄｓｔ）は「Ｌ：：ａ」である。端末Ｃのアドレス応答部２１で生成されたＮＩｒｅｐｌｙは送受信部５から端末Ａへ送信される（ステップＳ５）。

端末Ａの送受信部５は端末Ｃから送信されたＮＩｒｅｐｌｙを受信すると、アドレス変換部４は、当該ＮＩｒｅｐｌｙの「Ｄａｔａ」エリアに含まれているアドレス「Ｐ２：：ｃ」、「Ｐ３：：ｃ」を得る。今回通知されたアドレスはそのプレフィックスが「Ｐ２」「Ｐ３」であることからグローバルアドレスであることが明らかである。また、当該ＮＩｒｅｐｌｙのソースアドレスは端末Ｃのリンクローカルアドレスであることから、端末Ｃのグローバルアドレスは「Ｐ２」「Ｐ３」であると判定する。アドレス変換部４は、今回得られた端末Ｃのグローバルアドレスを、先のステップＳ１〜ステップＳ２で得られた（端末ＣからのＮＩｒｅｐｌｙに含まれていた）端末Ｃの名前ととともに記憶部６に記憶して、動作を終了する（ステップＳ６）。

上記第１の名前解決方法では、各端末が当該端末が持つグローバルアドレスを開示する場合にのみ可能である。例えば、グローバルアドレスを得たい端末Ｃがセキュリティ上の理由などでアドレスの開示を行なわない場合には、上記第１の名前解決方法は利用できない。あるいは、端末Ｃが単純にアドレスを開示するプロトコルを実装していない場合にも同様に利用できない。

そこで、次に、このような場合においても端末Ｃからグローバルアドレスを得ることのできる第２の名前解決方法について説明する。

端末Ａのアドレス変換部４では、まずこのリンクローカルで利用可能なグローバルアドレスのプレフィックスと、端末Ｃのリンクローカルアドレスの下位６４ｂｉｔのインターフェイスＩＤとを組み合わせて、アドレスを生成する。そして、名前の回収に利用したプロトコルを用いて、生成したアドレスを宛先（ｄｓｔ）として名前を再度問い合わせる。

端末Ｃが当該生成されたアドレスをもつ場合には、端末Ｃの名前「ｎｏｄｅＣ」を通知するためのメッセージ（ＮＩｒｅｐｌｙ）を返してくるはずである。端末Ａのアドレス変換部４は、送信元アドレスが当該生成されたアドレスであり、しかも、端末Ｃの名前「ｎｏｄｅＣ」を含むＮＩｒｅｐｌｙを受信したときに、生成されたアドレスが端末Ｃのグローバルアドレスと判定し、記憶部６に記憶する。

この時、端末Ａは、プレフィックス「Ｐ３」は利用していないが、このプレフィックス「Ｐ３」と端末ＣのインターフェイスＩＤとを組合せて生成されたアドレスを宛先とする問合せを行うようにしてもよい。

例えば端末Ａは、プレフィックス「Ｐ３」を利用していないが、仮にＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ（ＲＡ）などで、このリンクローカル上でプレフィックス「Ｐ３」は（他のだれかが）利用可能であるということを知ることができた場合、これを記憶して組み合わせの試行に利用してもよい。

端末Ｃのアドレス応答部２がＮＩｑｕｅｒｙに対しＦＱＤＮ応答しか行わない場合には図５に示すような処理動作となる。なお、図５において、図４と同一部分には同一符号を付し、異なる部分についてのみ説明する。すなわち、図５のステップＳ１からステップＳ３の処理動作は図４と同様であり、それ以降が異なる。

ステップＳ３において、ソースアドレスがリンクローカルアドレスである場合には、アドレス判断部３は、アドレス変換部４を起動する。

アドレス変換部４は、先のステップＳ１〜ステップＳ２の処理により、端末Ｃが「Ｌ：：ｃ」というローカルアドレスをもっていることがわかったので、現在端末Ａがリンクローカル内で利用可能なグローバルアドレスのプレフィックス「Ｐ１」「Ｐ２」「Ｐ３」と端末ＣのインターフェイスＩＤ「ｃ」とを組み合わせて、端末Ｃのアドレス候補を生成する（ステップＳ１１）。例えば、ここでは、「Ｐ１：：ｃ」、「Ｐ２：：ｃ」、「Ｐ３：：ｃ」が生成される。

アドレス変換部４は、これらのうちの１つ、例えば「Ｐ１：：ｃ」を宛先とした、端末Ｃに名前を問い合わせるためのＮＩｑｕｅｒｙを生成する。このとき生成されるＮＩｑｕｅｒｙの「Ｑｔｙｐｅ」というエリアには名前を要求するクエリであることを示す情報「ＦＱＤＮ」が記述され、ソースアドレス（ｓｒｃ）は端末Ａのリンクローカルアドレス「Ｌ：：ａ」、宛先（ｄｓｔ）は生成されたアドレス候補のうちの１つ「Ｐ１：：ｃ」である。アドレス変換部４で生成されたＮＩｑｕｅｒｙは送受信部５から端末Ｃへ送信される（ステップＳ１２）。

この場合、端末Ｃは「Ｐ１：：ｃ」というアドレスを利用していないので応答しない。すなわち、端末ＣからはＮＩｒｅｐｌｙは返ってこない。

端末ＡはＮＩｑｕｅｒｙ送信後、予め定められた時間内にＮＩｒｅｐｌｙを受信しないときには（タイムアウトしたときには）、ステップＳ１１で生成したアドレス候補のうちの他の１つ、例えば「Ｐ１：：ｃ」を宛先とした、端末Ｃに名前を問い合わせるためのＮＩｑｕｅｒｙを生成する。このとき生成されるＮＩｑｕｅｒｙの「Ｑｔｙｐｅ」というエリアには名前を要求するクエリであることを示す情報「ＦＱＤＮ」が記述され、ソースアドレス（ｓｒｃ）は端末Ａのリンクローカルアドレス「Ｌ：：ａ」、宛先（ｄｓｔ）は生成されたアドレス「Ｐ２：：ｃ」である。アドレス変換部４で生成されたＮＩｑｕｅｒｙは送受信部５から端末Ｃへ送信される（ステップＳ１３）。

端末Ｃの送受信部５は、当該ＮＩｑｕｅｒｙを受信すると、アドレス応答部２は、当該ＮＩｑｕｅｒｙの宛先が端末Ｃが利用するグローバルアドレス「Ｐ２：：ｃ」であるので、当該ＮＩｑｕｅｒｙに応答し、端末Ｃの名前「ｎｏｄｅＣ」を通知するための（ＩＣＭＰで定義されている）ＮＩｒｅｐｌｙを生成する。端末Ｃのアドレス応答部２で生成されるＮＩｒｅｐｌｙの「Ｄａｔａ」というエリアには、（ＮＩｑｕｅｒｙで要求された）端末Ｃの名前「ｎｏｄｅＣ」が記述され、当該ＮＩｒｅｐｌｙのソースアドレス（ｓｒｃ）は端末Ｃのグローバルアドレス「Ｐ２：：ｃ」、宛先（ｄｓｔ）は「Ｌ：：ａ」である。端末Ｃのアドレス応答部２１で生成されたＮＩｒｅｐｌｙは送受信部５から端末Ａへ送信される（ステップＳ１４）。

端末Ａの送受信部５は、端末Ａのローカルアドレスを宛先とするＮＩｒｅｐｌｙを受信すると、アドレス変換部４は、ＮＩｒｅｐｌｙの「Ｄａｔａ」エリアに含まれている名前が「ｎｏｄｅＣ」であることから、当該ＮＩｒｅｐｌｙは端末Ｃからのものであることがわかる。そして、当該ＮＩｒｅｐｌｙのソースアドレスを調べ、それが「Ｐ２：：ｃ」という、ステップＳ１１で生成したアドレスのうちの１つであるグローバルアドレスであることから、端末Ｃは、「Ｐ２：：ｃ」をグローバルアドレスとしてもつことを認識する。すなわち、端末Ｃのグローバルアドレスは「Ｐ２：：ｃ」であると判定する（ステップＳ１５）。

アドレス変換部４は、今回得られた端末Ｃのグローバルアドレスを、先のステップＳ１〜ステップＳ２で得られた（端末ＣからのＮＩｒｅｐｌｙに含まれていた）端末Ｃの名前ととともに記憶部６に記憶する。

端末Ａのアドレス変換部４は、ステップＳ１１で生成した３つのアドレス候補のうちの残りの１つ「Ｐ３：：ｃ」についても上記ステップＳ１３と同様に試行する。

すなわち、「Ｐ３：：ｃ」を宛先とした、端末Ｃに名前を問い合わせるためのＮＩｑｕｅｒｙを生成する。このとき生成されるＮＩｑｕｅｒｙの「Ｑｔｙｐｅ」というエリアには名前を要求するクエリであることを示す情報「ＦＱＤＮ」が記述され、ソースアドレス（ｓｒｃ）は端末Ａのリンクローカルアドレス「Ｌ：：ａ」、宛先（ｄｓｔ）は生成されたアドレス「Ｐ３：：ｃ」である。アドレス変換部４で生成されたＮＩｑｕｅｒｙは送受信部５から端末Ｃへ送信される（ステップＳ１６）。

端末Ｃの送受信部５は、当該ＮＩｑｕｅｒｙを受信すると、アドレス応答部２は、当該ＮＩｑｕｅｒｙの宛先が端末Ｃが利用するグローバルアドレス「Ｐ３：：ｃ」であるので、当該ＮＩｑｕｅｒｙに応答し、端末Ｃの名前「ｎｏｄｅＣ」を通知するための（ＩＣＭＰで定義されている）ＮＩｒｅｐｌｙを生成する。端末Ｃのアドレス応答部２で生成されるＮＩｒｅｐｌｙの「Ｄａｔａ」というエリアには、（ＮＩｑｕｅｒｙで要求された）端末Ｃの名前「ｎｏｄｅＣ」が記述され、当該ＮＩｒｅｐｌｙのソースアドレス（ｓｒｃ）は端末Ｃのグローバルアドレス「Ｐ３：：ｃ」、宛先（ｄｓｔ）は「Ｌ：：ａ」である。端末Ｃのアドレス応答部２１で生成されたＮＩｒｅｐｌｙは送受信部５から端末Ａへ送信される（ステップＳ１７）。

端末Ａの送受信部５は、端末Ａのローカルアドレスを宛先とするＮＩｒｅｐｌｙを受信すると、アドレス変換部４は、ＮＩｒｅｐｌｙの「Ｄａｔａ」エリアに含まれている名前が「ｎｏｄｅＣ」であることから、当該ＮＩｒｅｐｌｙは端末Ｃからのものであることがわかる。そして、当該ＮＩｒｅｐｌｙのソースアドレスを調べ、それが「Ｐ３：：ｃ」という、ステップＳ１１で生成したアドレス候補のうちの１つであるグローバルアドレスであることから、端末Ｃは、「Ｐ３：：ｃ」をグローバルアドレスとしてもつことを認識する（ステップＳ１８）。

アドレス変換部４は、今回得られた端末Ｃのグローバルアドレスを、先のステップＳ１〜ステップＳ２で得られた（端末ＣからのＮＩｒｅｐｌｙに含まれていた）端末Ｃの名前ととともに記憶部６に記憶する。

端末Ａのアドレス変換部４は、ステップＳ１１で生成した全てのアドレスについての試行を終了したので動作を終了する。

この結果、端末Ｃの名前「ｎｏｄｅＣ」に対応するＩＰｖ６アドレスとして、「Ｐ２：：ｃ」及び「Ｐ３：：ｃ」が取得され、記憶部６には、端末Ｃの名前「ｎｏｄｅＣ」とともに、当該端末Ｃのグローバルアドレス「Ｐ２：：ｃ」及び「Ｐ３：：ｃ」が記憶されたことになる。

なお、アドレス変換部４は、端末Ｃのグローバルアドレスが１つ得られた時点で（未試行のアドレスがあっても）、そこで動作を終了してもよい。すなわち、図５のステップＳ１５で端末Ｃのグローバルアドレス「Ｐ２：：ｃ」が得られた時点で、動作を終了してもよい。

また、図５のステップＳ１１では、アドレス候補を一括して生成していたが、この場合に限らず、ステップＳ１２、ステップＳ１３、ステップＳ１６の前段にアドレス候補を１つ生成するステップをそれぞれ設け、アドレス候補を１つ生成するた度にそれを宛先とするＮＩｑｕｅｒｙメッセージを送信するようにしてもよい。

以上説明したように、上記実施形態によれば、端末Ａは端末Ｃの名前「ｎｏｄｅＣ」に対応するＩＰｖ６アドレスを取得しようとしたときに、端末Ｃのリンクローカルアドレスを取得した場合には、端末Ｃのグローバルアドレスを得るために、宛先を端末ＣのリンクローカルアドレスとするＩＣＭＰｖ６のＮＩｑｕｅｒｙメッセージを送信する。そして、端末Ｃのリンクローカルアドレスを送信元アドレスとするＩＭＣＰｖ６のＮＩｒｅｐｌｙメッセージを受信することにより、当該ＮＩｒｅｐｌｙメッセージに含まれる端末Ｃのグローバルアドレスを取得する。

また、端末Ａは端末Ｃの名前「ｎｏｄｅＣ」に対応するＩＰｖ６アドレスを取得しようとしたときに、端末Ｃのリンクローカルアドレスを取得した場合には、当該リンクローカルアドレスに含まれる端末ＣのインターフェイスＩＤと、端末Ａで利用可能なグローバルアドレスのプレフィックスとを組み合わせて、端末Ｃのアドレス候補を生成し、宛先を当該アドレス候補とするＩＣＭＰｖ６のＮＩｑｕｅｒｙメッセージを送信する。そして、当該アドレス候補を送信元アドレスとするＩＣＭＰｖ６のＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を端末Ｃのグローバルアドレスと判定する。

このように、上記実施形態によれば、ＩＰｖ６のリンクローカル内の各ＩＰｖ６ノードのグローバルアドレスを容易に取得することができる。

本発明の実施形態に係る通信装置の要部の構成例を示した図。 本実施形態にかかる名前解決方法を説明するための通信システム全体の構成例を示した図。 端末Ａで取得された端末Ｂと端末Ｃの名前とアドレスの記憶例を示した図。 第１の名前解決方法に係る端末Ａの処理動作を説明するためのフローチャート。 第２の名前解決方法に係る端末Ａの処理動作を説明するためのフローチャート。

符号の説明

１…アドレス要求部、２…アドレス応答部、３…アドレス判断部、４…アドレス変換部、５…送受信部、６…記憶部。

Claims (8)

1. 少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ通信装置であって、
   前記第１のアドレスで通信可能なネットワーク上のノード装置の名前に対応するＩＰｖ６アドレスを取得する第１の取得手段と、
   前記取得手段で取得したＩＰｖ６アドレスがリンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合に、前記ノード装置のグローバルアドレスを取得する第２の取得手段と、
   を具備し、
   前記第２の取得手段は、
   前記第１の取得手段で取得したリンクローカルアドレスに含まれる前記ノード装置のインターフェイスＩＤと、前記通信装置で利用可能なグローバルアドレスのプレフィックスとを組み合わせて、前記ノード装置のアドレス候補を生成する手段と、
   宛先を前記アドレス候補とするＩＣＭＰｖ６（internet control message protocol v6）のＮＩ（node information）ｑｕｅｒｙメッセージを送信する送信手段と、
   前記アドレス候補を送信元アドレスとするＩＣＭＰｖ６のＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を前記ノード装置のグローバルアドレスと判定する判定手段と、
   を具備したことを特徴とする通信装置。
2. 前記送信手段は、前記ノード装置の名前を問い合わせるためのＮＩｑｕｅｒｙメッセージを送信し、
   前記判定手段は、
   前記ノード装置の名前を含み、かつ送信元アドレスが前記アドレス候補である前記ＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を前記ノード装置のグローバルアドレスと判定することを特徴とする請求項１記載の通信装置。
3. 少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ通信装置であって、
   前記第１のアドレスで通信可能なネットワーク上のノード装置の名前に対応するＩＰｖ６アドレスを取得する第１の取得手段と、
   前記取得手段で取得したＩＰｖ６アドレスがリンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合に、前記ノード装置のグローバルアドレスを取得する第２の取得手段と、
   を具備し、
   前記第２の取得手段は、
   前記ノード装置のグローバルアドレスを得るために、宛先を前記第１の取得手段で取得したリンクローカルアドレスとするＩＣＭＰｖ６（internet control message protocol v6）のＮＩ（node information）ｑｕｅｒｙメッセージを送信する送信手段と、
   前記ノード装置のリンクローカルアドレスを送信元アドレスとするＩＭＣＰｖ６のＮＩｒｅｐｌｙメッセージを受信することにより、前記ＮＩｒｅｐｌｙメッセージに含まれる前記ノード装置のグローバルアドレスを取得することを特徴とする通信装置。
4. 少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ第１のノード装置が前記第１のアドレスで通信可能なネットワーク上の第２のノード装置の名前に対応するＩＰｖ６アドレスを取得するための名前解決方法であって、
   前記第２のノード装置の名前に対応するＩＰｖ６アドレスを取得する第１のステップと、
   前記第１のステップで取得したＩＰｖ６アドレスがリンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合に、前記第２のノード装置のグローバルアドレスを取得する第２のステップと、
   を有し、
   前記第２のステップは、
   前記第１のステップで取得したリンクローカルアドレスに含まれる前記第２のノード装置のインターフェイスＩＤと、前記第１のノード装置で利用可能なグローバルアドレスのプレフィックスとを組み合わせて、前記第２のノード装置のアドレス候補を生成する第３のステップと、
   宛先を前記アドレス候補とするＩＣＭＰｖ６（internet control message protocol v6）のＮＩ（node information）ｑｕｅｒｙメッセージを送信する第４のステップと、
   前記アドレス候補を送信元アドレスとするＩＣＭＰｖ６のＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を前記第２のノード装置のグローバルアドレスと判定する第５のステップと、
   を有することを特徴とする名前解決方法。
5. 前記第４のステップは、前記第２のノード装置の名前を問い合わせるためのＮＩｑｕｅｒｙメッセージを送信し、
   前記第５のステップは、
   前記第２のノード装置の名前を含み、かつ送信元アドレスが前記アドレス候補である前記ＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を前記第２のノード装置のグローバルアドレスと判定することを特徴とする請求項４記載の名前解決方法。
6. 少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ第１のノード装置が前記第１のアドレスで通信可能なネットワーク上の第２のノード装置の名前に対応するＩＰｖ６アドレスを取得するための名前解決方法であって、
   前記第２のノード装置の名前に対応するＩＰｖ６アドレスを取得する第１のステップと、
   前記第１のステップで取得したＩＰｖ６アドレスがリンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合に、前記第２のノード装置のグローバルアドレスを取得する第２のステップと、
   を有し、
   前記第２のステップは、
   前記第２のノード装置のグローバルアドレスを得るために、宛先を前記第１のステップで取得したリンクローカルアドレスとするＩＣＭＰｖ６のＮＩｑｕｅｒｙメッセージを送信する第３のステップと、
   前記第２のノード装置のリンクローカルアドレスを送信元アドレスとするＩＭＣＰｖ６のＮＩｒｅｐｌｙメッセージを受信することにより、前記ＮＩｒｅｐｌｙメッセージに含まれる前記第２のノード装置のグローバルアドレスを取得することを特徴とする名前解決方法。
7. 少なくともＩＰｖ６のリンクローカルアドレスである第１のアドレスをもつ第１のノード装置が前記第１のアドレスで通信可能なネットワーク上の第２のノード装置の名前に対応するＩＰｖ６アドレスを取得するためのプログラムであって、
   前記第２のノード装置の名前に対応するＩＰｖ６アドレスを取得する第１のステップと、
   前記第１のステップで取得したＩＰｖ６アドレスがリンクローカルアドレスとグローバルアドレスのうちのリンクローカルアドレスである場合に、前記第２のノード装置のグローバルアドレスを取得する第２のステップと、
   を有し、
   前記第２のステップは、
   前記第１のステップで取得したリンクローカルアドレスに含まれる前記第２のノード装置のインターフェイスＩＤと、前記第１のノード装置で利用可能なグローバルアドレスのプレフィックスとを組み合わせて、前記第２のノード装置のアドレス候補を生成する第３のステップと、
   宛先を前記アドレス候補とするＩＣＭＰｖ６（internet control message protocol v6）のＮＩ（node information）ｑｕｅｒｙメッセージを送信する第４のステップと、
   前記アドレス候補を送信元アドレスとするＩＣＭＰｖ６のＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を前記第２のノード装置のグローバルアドレスと判定する第５のステップと、
   を有することを特徴とするプログラム。
8. 前記第４のステップは、前記第２のノード装置の名前を問い合わせるためのＮＩｑｕｅｒｙメッセージを送信し、
   前記第５のステップは、
   前記第２のノード装置の名前を含み、かつ送信元アドレスが前記アドレス候補である前記ＮＩｒｅｐｌｙメッセージを受信したときに、当該アドレス候補を前記第２のノード装置のグローバルアドレスと判定することを特徴とする請求項７記載のプログラム。

Images