JP3692107B2 - 名前解決装置及び名前解決方法 - Google Patents
名前解決装置及び名前解決方法 Download PDFInfo
- Publication number
- JP3692107B2 JP3692107B2 JP2002287717A JP2002287717A JP3692107B2 JP 3692107 B2 JP3692107 B2 JP 3692107B2 JP 2002287717 A JP2002287717 A JP 2002287717A JP 2002287717 A JP2002287717 A JP 2002287717A JP 3692107 B2 JP3692107 B2 JP 3692107B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- network
- information
- identification information
- node information
- 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.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上の各ノードの名前を適宜更新する名前解決装置及び名前解決方法に関する。
【０００２】
【従来の技術】
近年、世界最大のコンピュータネットワークであるインターネットが急速に普及しており、インターネットと接続されて公開された情報やサービスを利用したり、逆にインターネットを介してアクセスしてくる外部ユーザに対して、情報やサービスを提供することで、新たなコンピュータビジネスが開拓されている。また、インターネット利用に関して、新たな技術開発や展開がなされている。
【０００３】
インターネットでは、各計算機がIPアドレスと呼ばれる識別子をもち、このIPアドレスを元に、パケットの交換が行われる。しかしながら、IPアドレスはいわば数字であり、人間がそのまま使用するには直感的ではなく簡便性に欠ける。このため、IPv6アドレスと人間がより扱いやすい形である文字列、すなわち「名前」との変換のメカニズムが使われている。現在インターネットで最も利用されている変換システムにDNS(Domain Name System)がある（非特許文献１〜４）。
【０００４】
DNSはインターネット上でのグローバルな名前解決に用いられるため、DNSで利用される名前FQDN(Fully Qualified Domain Name)はやはりインターネット上で一意でなければならない。
【０００５】
一方、インターネットの普及に伴い、すべてのノードがグローバルユニークな名前を持つ必要性は少なくなってきている。また、DNSでは、その性質上名前の公開について、あるノードの名前を特定のメンバにのみ公開することはできない。よって、あるドメインがどのような名前を持つかは、力ずく（brute force）で発見することが可能であり、どのような名前をもつノードが存在するかという情報を悪意を持つ第三者が容易に入手することができる。これはプライバシーの漏洩という問題を引き起こす。さらに、FQDNを利用するためにはそのFQDNを管理するDNSサーバを用意する必要があるが、このサーバの設置場所、管理、登録及び運営という課題が発生する。
【０００６】
一方、家庭内のような小さなネットワークでは、ネットワーク上にローカルに名前を定めて、それによってノードヘのアクセスを行なう技術もいくつか提案されている。
【０００７】
【非特許文献１】
IETF RFC1034 Domain names -concepts and facilities. Nov-01-1987
【非特許文献２】
IETF RFC1035 Domain names -implementation and specification. Nov-01-1987
【非特許文献３】
IETF RFC2462 IPv6 Stateles Address Autoconfiguration. December 1998
【非特許文献４】
IETF RFC2463 Internet Control Message Protocol(ICMPv6) for the Internet
Protocol Version 6(IPv6) Specification. December 1998
【０００８】
【発明が解決しようとする課題】
しかしながら、これらの技術は、名前によって指定される通信相手がネットワーク的に近傍にいることが前提となっており、そのネットワークの外部から名前によってアクセスしようとした場合に直接利用することはできない。この場合には外部からの解決を受け持つ専用のサーバが必要であったり、そのためのサーバを発見するためのプロトコルが必要であったり、ユーザの利便性を損なう。
【０００９】
これらの問題を避けるために、ノードローカルなデータベースを利用するという方法が考えられる。たとえばこれはUnix（登録商標）などのOSでは、/etc/hostsファイルとして良く知られている。
【００１０】
ある個人が他人にアクセスしてもらいたい場合には、直接アドレスと名前のデータを交換するという方法で、他人に名前を伝えることができる。しかしながら、静的なデータベースは手動で更新しなければならない。
【００１１】
一方、IPv6では、家庭のような小さな網においてもリナンバリング（Renumbering）が起きると予想されている。リナンバリングとは、あるネットワークにおいて、ネットワークプレフィクスが異なる値に変化することを意味する。
【００１２】
これは、IPv6では、基本的にプロバイダからアドレスの割り付けを受けるため、例えばユーザがプロバイダを変えた場合には必ず発生する。このとき、静的なノードローカルデータベースを利用する場合、すでにその中の情報を誰かに伝えてしまった場合には、リナンバが起きたことを伝えなければならないが、プライバシーの漏洩という点を鑑みた場合、「誰に何を教えるのか」という問題が発生する。すなわち、例えば、foo、barという2つの名前をもつノードをネットワークに持つある個人が、他人に自分のネットワーク上のノードの名前を教える場合、ある人間に対してはfooしか教えたくなく、また他のある人間に対してはbarしか教えたくない場合も考えられる。このとき、リナンバの起きた後、どちらに何を教えるかが問題となる。
【００１３】
本発明は、このような点に鑑みてなされたものであり、その目的は、ネットワーク上でリナンバリングを行った場合に、その更新情報を簡易かつプライバシを損なわずに伝達可能な名前解決装置及び名前解決方法を提供することにある。
【００１４】
【課題を解決するための方法】
本発明の一態様によれば、所定のネットワークに接続された個々のノードの名前と各ノードを識別するアドレスとを管理する名前解決装置において、個々のノードごとに、ノードの名前、ネットワーク識別情報、ネットワーク上の位置を示すプレフィックス及びノードのインタフェース識別情報からなるノード情報を保存するノード情報保存部と、ネットワークに接続されている他のノードに関する前記ノード情報を、ネットワークを介して収集するノード情報収集部と、前記ノード情報収集部にて収集した他のノードに関する前記ノード情報に基づいて、前記ノード情報保存部に保存されている前記ノード情報を更新するノード情報更新部と、前記ノード情報保存部に保存されている前記ノード情報のうち、所定のノードに対応する前記インタフェース識別情報を一方向性関数にて変換する関数変換部と、前記一方向性関数にて変換された前記インタフェース識別情報を他のノードから受け取った場合に、この識別情報と前記関数変換部で変換された前記インタフェース識別情報とを比較する比較部と、前記比較部で一致したと判定される場合のみ、比較した前記インタフェース識別情報に対応する前記プレフィックスを前記他のノードに提供するノード情報提供部と、を備えることを特徴とする名前解決装置が提供される。
【００１５】
【発明の実施の形態】
以下、本発明に係る名前解決装置及び名前解決方法について、図面を参照しながら具体的に説明する。
【００１６】
図１は本発明に係る名前解決装置の一実施形態の概略構成を示すブロック図である。図１の名前解決装置は、ネットワーク１に接続される各ノードの内部に設けられる。ここで、ノードとは、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistants）、携帯電話及び家電ノードなど、通信機能を持った任意の機器を指す。
【００１７】
図１の名前解決装置は、名前問合せ部２と、データベース３と、名前更新部４と、応答部５と、ネットワーク処理部６と、管理部７とを備えている。
【００１８】
名前問合せ部２は、ネットワーク１に接続されている他のノードに名前を問い合わせて、各ノードのノード情報を収集する。収集されたノード情報は、データベース３に格納される。
【００１９】
インターネット上のプロトコルであるIPv6（Internet Protocol version 6）では、例えばICMP（Internet Control Message Protocol）ノード情報要求（node information query）などが利用可能である。なお、データベース３への格納は、人間が手動で行ってもよいが、以下では自動的に収集する仕組みについて説明する。
【００２０】
名前更新部４は、ネットワーク１上の各ノードのノード情報が変更になっているか否かを判断して、ノード情報が変更になっていれば、データベース３を更新する。
【００２１】
応答部５は、他のノードからの問合せに対して、自ノードのノード情報をネットワーク１経由で返信する。ネットワーク処理部６は、ネットワーク１を経由したデータの送受信を制御する。
【００２２】
管理部７は、名前問合せ部２が問い合わせて収集した各ノードのノード情報を、名前（name）、ネットワークＩＤ（network ID）、ネットワーク・プレフィックス（network prefix）及びインタフェースＩＤ（interface ID）で管理する。ネットワークＩＤとは、ネットワーク１自体の識別情報であり、ネットワーク・プレフィックスとは、ネットワーク１上の位置を示す情報であり、インタフェースＩＤとは、ノードのインタフェース識別情報である。
【００２３】
例えば、名前問合せ部２が、あるネットワークＮｘに接続された２台のノードを見つけたとする。これら２台のノードは、図２のようなIPv6アドレスをもち、一台の名前はfoo、もう一台の名前はbarである。図２の「prefixlen 64」は、ネットワーク・プレフィックスのプレフィックス長が上位６４ビットであることを示している。
【００２４】
このとき、データベース３には、図３及び図４に示すような情報が格納される。すなわち、名前fooは、図３に示すように、ネットワークＩＤが「3ffe::/64」、ネットワーク・プレフィックスが「3ffe::/64」、インタフェースＩＤが「::230:65ff:fe1a:3525」である。また、名前barは、図４に示すように、ネットワークＩＤが「3ffe::/64」、ネットワーク・プレフィックスが「3ffe::/64」、インタフェースＩＤが「::203:93ff:fe00:e6ac」である。
【００２５】
以下では、名前、ネットワークＩＤ、ネットワーク・プレフィックス及びインタフェースＩＤをエントリと呼ぶ。
【００２６】
各ノードは、データベース３に格納された各ネットワークＩＤに対して、固有の名称をつけることができる。例えば、「自宅」、「親戚の家」などである。
【００２７】
各ノードを外部ネットワーク１に接続した場合でも、自己が所持するデータベース３を参照し、自己が定めた（グローバル・ユニークではない）名称を用いて通信相手のIPv6アドレスを指定することができる。
【００２８】
各ノードは、自己が持つローカルなデータベース３の中から、いくつかのエントリを選択的に他人（他ノード）に教えることができる。これにより、自己が選んだ相手のみに名前を公開することができる。
【００２９】
また、名前問合せ部２は、自己が接続しているネットワーク１上の他のノードのエントリを定期的に自動収集することも可能である。
【００３０】
ネットワーク１上に接続されるノードの種類や名前は時間によって変化するため、データベース３に保存されているエントリが実際には存在しない可能性もある。このため、定期的にデータベース３の更新を行う必要がある。
【００３１】
（第１の更新例）
第１の更新例は、ノードが直接移動して、ネットワーク１上の他のノードの名前を収集可能な場合を念頭に置いている。
【００３２】
図５はデータベース３の第１の更新例を示すシーケンス図である。まず、あるノードをネットワーク１に接続し、ネットワーク１上の他のノードに名前を問い合わせる（ステップＳ１）。他のノードから返答があると（ステップＳ２）、管理部７はプレフィックスが変更されたか否かを判定する（ステップＳ３）。変更されていなければ処理を終了し、変更されていれば、データベース３を更新する（ステップＳ４）。
【００３３】
上述したステップＳ３では、ネットワーク１上の各ノードのインタフェースＩＤに基づいてプレフィックスを更新する。すなわち、名前問合せ部２が収集した名前の中に、同じインタフェースＩＤを持つが、異なるネットワーク・プレフィックスを持つノードが存在する場合、名前更新部４は、名前が更新されたと判断し、データベース３上のそのインタフェースＩＤに対応するネットワーク・プレフィックスを新しいプレフィックスに置き換えるという動作を行って、名前の更新を行う。
【００３４】
例えば、あるノードＭが、図２に示す２台のノードが接続されたネットワークNxから離れている間に、このネットワークNxでリナンバリングが行われ、ネットワーク・プレフィックスが「3ffe:/64」から「2001::/64」に変更になったとする。その後に、ノードＭがネットワークNxに移動してきて名前の収集を行い、図６に示す２台のノードを発見したとする。
【００３５】
図６に示す２台のノードのインタフェースＩＤは、図２に示す２台のノードのインタフェースＩＤと同じであるため、ノードＭの名前更新部４は、ネットワーク・プレフィックス「3ffe::/64」が「2001::/64」に変更されたと判断し、データベース３を更新する。
【００３６】
上述したインタフェースＩＤは、必ずしもグローバル・ユニークなものとは限らないため、上述した第１の更新例は、インタフェースＩＤが比較的グローバル・ユニークなEUI-64形式の場合のみに適用可能である。
【００３７】
また、ノードが属するネットワーク１のデフォルト・ルータのプレフィックスが変化した場合のみ、上述したデータベース３の更新処理を行ってもよい。あるいは、データベース３を更新してもよいか否かをユーザに確認してもよい。
【００３８】
このように、第１の更新例では、インタフェースＩＤが同じでネットワーク・プレフィックスが異なるノード情報については、ノード情報が更新されたと判断してデータベース３の更新を行うため、データベース３を自動更新することができる。
【００３９】
（第２の更新例）
第２の更新例は、身元の知れたノードに対してのみ名前の更新情報を知らせるものである。
【００４０】
自己が直接ネットワーク１に接続しない場合、例えばネットワーク１に接続されているノードの情報を第三者から教えてもらった場合は、そのネットワーク１で名前の更新が行われても、第三者から更新情報を教えてもらわない限り、データベース３を更新できない。この場合、データベース３を更新する方法として、新しいエントリを持っている第三者からデータベース３を更新してもらう方法が考えられる。この方法では、データベース３中の更新前のエントリが持っているネットワークＩＤと同じ値を持つすべてのエントリのネットワーク・プレフィックスを更新後の値に変更する。これにより、プライバシを保持したまま、効率的にプレフィックスの更新を行うことができる。
【００４１】
図７は第２の更新例を説明するネットワーク配置図、図８はデータベース３の第２の更新例を示すシーケンス図である。図７では、ネットワークNxの所有者をＸとし、ある人間ＡがネットワークNxについての情報として、ネットワーク所有者Ｘから２つの名前foo,barのノード情報をすでに教えてもらっていたとする（ステップＳ１１）。人間Ａはネットワーク１には直接接続されていないとする。
【００４２】
その後、ネットワークNxがリナンバリングを行い、ネットワーク・プレフィックスが変わったとする（ステップＳ１２）。この場合、ネットワーク所有者Ｘは人間Ａに会ったときに、ネットワーク・プレフィックスが変わったことを伝えなければならないが、すでにネットワーク所有者Ｘは人間Ａに何を教えていたか忘れてしまったとする。
【００４３】
このとき、人間Ａは、ネットワーク所有者Ｘに対して、ネットワークNxについて知っているインタフェースＩＤを一つ選択し、そのハッシュ値を教える（ステップＳ１３）。ここでは、選択したインタフェースＩＤをハッシュ関数に入力してハッシュ値を求める。
【００４４】
なお、必ずしもハッシュ関数を利用する必要はなく、非可逆変換が可能な一方向性関数であればよい。
【００４５】
ネットワーク所有者Ｘは、自己が持っているエントリからハッシュ値に合致するエントリを探し、エントリがあれば、それに対するインタフェースＩＤを除いたエントリの内容を人間Ａに通知する（ステップＳ１４）。人間Ａは、通知されたエントリの内容に従って自己のデータベース３を更新する（ステップＳ１５）。
【００４６】
このような手順を行うことで、ネットワーク所有者Ｘは、人間Ａが何を持っているか忘れていても、不必要にすべてのエントリを教えることを避けることができる。また、人間Ａは、ネットワーク１に接続されていなくても、ネットワーク１上の名前の変更に応じて、データベース３を更新できる。
【００４７】
上述した第２の更新例は、プライバシを保護した伝聞による更新にも利用可能である。例えば、図９に示すように、人間ＢがネットワークNxについての情報として、ネットワーク所有者Ｘから名前fooに関する情報だけを教えてもらっているとする。すなわち、ネットワーク所有者Ｘが、例えば名前barに関する情報を人間Ｂに教えたくないような場合である。
【００４８】
ネットワーク所有者Ｘが名前の変更を行ったという事実が秘密でないと仮定する。人間Ａは、人間Ｂに会ったときに、人間Ｂが持っているインタフェースＩＤのハッシュ値を教えてもらう。このハッシュ値が人間Ａが持っているものと一致すれば、人間Ａは、人間Ｂに対して、インタフェースＩＤを除いたエントリのみを教える。
【００４９】
これにより、人間Ｂはすでに持っている情報を更新できるが、新しいエントリを取得することはできない。すなわち、人間Ｂは、元々知っている情報以外の情報を得ることはできない。同様に、人間Ａは、人間ＢからネットワークＮx上の新しいノード情報を得ることはできない。
【００５０】
このように、第２の更新例では、ハッシュ値が一致する場合のみ、相手に名前の更新情報を通知するため、プライバシを保護でき、セキュリティ性を向上できる。
【００５１】
（第３の更新例）
第３の更新例は、ネットワーク・プレフィックスをDNSに登録し、ネットワーク・プレフィックスの値をFQDNで示すものである。
【００５２】
第３の更新例では、各ノードのデータベース３に、ネットワーク・プレフィックスとしてFQDNを保存する。ネットワーク・プレフィックスとFQDNとの変換は、DNSが行う。DNSは、各ノードとは別個にネットワーク１に接続されている。
【００５３】
ネットワーク所有者Ｘが自己のネットワーク１に関する何らかのFQDNを持っている場合、すなわち、自己のネットワーク１に対するドメインを持っている場合、エントリの中のネットワーク・プレフィックスの値を、実際のプレフィックスではなく、プレフィックスを示すFQDNにすることができる。
【００５４】
アドレス解決の必要性が発生すると、データベース３に保存されているFQDNに対応するネットワーク・プレフィックスをDNSに問い合わせる。応答部５は、DNSから回答のあったネットワーク・プレフィックスを用いて、IPv6アドレスを生成して応答する。
【００５５】
各ノードのデータベース３には、ネットワーク・プレフィックスの代わりにFQDNに対応する値が保存されているため、リナンバリングの際には、FQDNに対応する値を更新すればよい。各ノードは、定期的にこのFQDNに対応する値を確認し、他のノードから、あるノードのIPv6アドレス要求があった場合には、最も最近のFQDNに対応するネットワーク・プレフィックスとインタフェースIDからIPv6アドレスを生成して応答する。すなわち、IPv6アドレスの要求があるたびに、FQDNに対応するネットワーク・プレフィックスをDNSに問合せるのは面倒であるため、過去にDNSに問合せたネットワーク・プレフィックスをキャッシュしておき、ノードからIPv6アドレスが要求されると、このキャッシュからネットワーク・プレフィックスを読み出して送信する。これにより、アドレス要求に対する応答を高速化することができる。もちろん、毎回ＤＮＳを確認してもよい。
【００５６】
例えば、Nx.orgというドメインが存在する場合、すなわち、「network.Nx.orgは3ffe::である」という情報と、その逆引き「3ffe::はNx.orgである」という情報とがDNSで管理されているとする。
【００５７】
あるノードが自己のデータベース３にノード情報を格納する際は、ネットワーク・プレフィックスの逆引きを行い、それに対してFQDNが設定されている場合は、FQDNを正引きしてその値が一致していることを確認したうえで、ネットワーク・プレフィックスとしてFQDN（この例では、network.Nx.org）を自己のデータベース３に保存する。データベース３に保存されたFQDNは、適宜ネットワーク１に問い合わせることにより、更新可能である。
【００５８】
このように、第３の更新例では、各ノードのデータベース３に、ネットワーク・プレフィックスの代わりにFQDNを保存するため、無作為な文字列であるネットワーク・プレフィックスを保存するよりも、ノード情報が把握しやすくなる。
【００５９】
上述した各実施形態では、各ノードがIPv6アドレスを有する例を示したが、アドレスには特に制限はなく、例えば、IPv4でもよい。
【００６０】
【発明の効果】
以上詳細に説明したように、本発明によれば、ネットワーク上のノード情報が変更されても、変更があったことを各ノードに簡易な手順で知ることができる。また、ネットワーク上の他のノードに対して、プライバシを維持した状態で、ノード情報を送信できる。
【図面の簡単な説明】
【図１】本発明に係る名前解決装置の一実施形態の概略構成を示すブロック図。
【図２】ネットワークに接続された２台のノードのIPv6アドレスの例を示す図。
【図３】図２の名前fooのエントリを示す図。
【図４】図２の名前barのエントリを示す図。
【図５】データベースの第１の更新例を示すシーケンス図。
【図６】リナンバリングを行った後の２台のノードのIPv6アドレスの例を示す図。
【図７】第２の更新例を説明するネットワーク配置図。
【図８】データベースの第２の更新例を示すシーケンス図。
【図９】第２の更新例の変形例を説明するネットワーク配置図。
【符号の説明】
１ ネットワーク
２ 名前問合せ部
３ データベース
４ 名前更新部
５ 応答部
６ ネットワーク処理部
７ 管理部
【発明の属する技術分野】
本発明は、ネットワーク上の各ノードの名前を適宜更新する名前解決装置及び名前解決方法に関する。
【０００２】
【従来の技術】
近年、世界最大のコンピュータネットワークであるインターネットが急速に普及しており、インターネットと接続されて公開された情報やサービスを利用したり、逆にインターネットを介してアクセスしてくる外部ユーザに対して、情報やサービスを提供することで、新たなコンピュータビジネスが開拓されている。また、インターネット利用に関して、新たな技術開発や展開がなされている。
【０００３】
インターネットでは、各計算機がIPアドレスと呼ばれる識別子をもち、このIPアドレスを元に、パケットの交換が行われる。しかしながら、IPアドレスはいわば数字であり、人間がそのまま使用するには直感的ではなく簡便性に欠ける。このため、IPv6アドレスと人間がより扱いやすい形である文字列、すなわち「名前」との変換のメカニズムが使われている。現在インターネットで最も利用されている変換システムにDNS(Domain Name System)がある（非特許文献１〜４）。
【０００４】
DNSはインターネット上でのグローバルな名前解決に用いられるため、DNSで利用される名前FQDN(Fully Qualified Domain Name)はやはりインターネット上で一意でなければならない。
【０００５】
一方、インターネットの普及に伴い、すべてのノードがグローバルユニークな名前を持つ必要性は少なくなってきている。また、DNSでは、その性質上名前の公開について、あるノードの名前を特定のメンバにのみ公開することはできない。よって、あるドメインがどのような名前を持つかは、力ずく（brute force）で発見することが可能であり、どのような名前をもつノードが存在するかという情報を悪意を持つ第三者が容易に入手することができる。これはプライバシーの漏洩という問題を引き起こす。さらに、FQDNを利用するためにはそのFQDNを管理するDNSサーバを用意する必要があるが、このサーバの設置場所、管理、登録及び運営という課題が発生する。
【０００６】
一方、家庭内のような小さなネットワークでは、ネットワーク上にローカルに名前を定めて、それによってノードヘのアクセスを行なう技術もいくつか提案されている。
【０００７】
【非特許文献１】
IETF RFC1034 Domain names -concepts and facilities. Nov-01-1987
【非特許文献２】
IETF RFC1035 Domain names -implementation and specification. Nov-01-1987
【非特許文献３】
IETF RFC2462 IPv6 Stateles Address Autoconfiguration. December 1998
【非特許文献４】
IETF RFC2463 Internet Control Message Protocol(ICMPv6) for the Internet
Protocol Version 6(IPv6) Specification. December 1998
【０００８】
【発明が解決しようとする課題】
しかしながら、これらの技術は、名前によって指定される通信相手がネットワーク的に近傍にいることが前提となっており、そのネットワークの外部から名前によってアクセスしようとした場合に直接利用することはできない。この場合には外部からの解決を受け持つ専用のサーバが必要であったり、そのためのサーバを発見するためのプロトコルが必要であったり、ユーザの利便性を損なう。
【０００９】
これらの問題を避けるために、ノードローカルなデータベースを利用するという方法が考えられる。たとえばこれはUnix（登録商標）などのOSでは、/etc/hostsファイルとして良く知られている。
【００１０】
ある個人が他人にアクセスしてもらいたい場合には、直接アドレスと名前のデータを交換するという方法で、他人に名前を伝えることができる。しかしながら、静的なデータベースは手動で更新しなければならない。
【００１１】
一方、IPv6では、家庭のような小さな網においてもリナンバリング（Renumbering）が起きると予想されている。リナンバリングとは、あるネットワークにおいて、ネットワークプレフィクスが異なる値に変化することを意味する。
【００１２】
これは、IPv6では、基本的にプロバイダからアドレスの割り付けを受けるため、例えばユーザがプロバイダを変えた場合には必ず発生する。このとき、静的なノードローカルデータベースを利用する場合、すでにその中の情報を誰かに伝えてしまった場合には、リナンバが起きたことを伝えなければならないが、プライバシーの漏洩という点を鑑みた場合、「誰に何を教えるのか」という問題が発生する。すなわち、例えば、foo、barという2つの名前をもつノードをネットワークに持つある個人が、他人に自分のネットワーク上のノードの名前を教える場合、ある人間に対してはfooしか教えたくなく、また他のある人間に対してはbarしか教えたくない場合も考えられる。このとき、リナンバの起きた後、どちらに何を教えるかが問題となる。
【００１３】
本発明は、このような点に鑑みてなされたものであり、その目的は、ネットワーク上でリナンバリングを行った場合に、その更新情報を簡易かつプライバシを損なわずに伝達可能な名前解決装置及び名前解決方法を提供することにある。
【００１４】
【課題を解決するための方法】
本発明の一態様によれば、所定のネットワークに接続された個々のノードの名前と各ノードを識別するアドレスとを管理する名前解決装置において、個々のノードごとに、ノードの名前、ネットワーク識別情報、ネットワーク上の位置を示すプレフィックス及びノードのインタフェース識別情報からなるノード情報を保存するノード情報保存部と、ネットワークに接続されている他のノードに関する前記ノード情報を、ネットワークを介して収集するノード情報収集部と、前記ノード情報収集部にて収集した他のノードに関する前記ノード情報に基づいて、前記ノード情報保存部に保存されている前記ノード情報を更新するノード情報更新部と、前記ノード情報保存部に保存されている前記ノード情報のうち、所定のノードに対応する前記インタフェース識別情報を一方向性関数にて変換する関数変換部と、前記一方向性関数にて変換された前記インタフェース識別情報を他のノードから受け取った場合に、この識別情報と前記関数変換部で変換された前記インタフェース識別情報とを比較する比較部と、前記比較部で一致したと判定される場合のみ、比較した前記インタフェース識別情報に対応する前記プレフィックスを前記他のノードに提供するノード情報提供部と、を備えることを特徴とする名前解決装置が提供される。
【００１５】
【発明の実施の形態】
以下、本発明に係る名前解決装置及び名前解決方法について、図面を参照しながら具体的に説明する。
【００１６】
図１は本発明に係る名前解決装置の一実施形態の概略構成を示すブロック図である。図１の名前解決装置は、ネットワーク１に接続される各ノードの内部に設けられる。ここで、ノードとは、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistants）、携帯電話及び家電ノードなど、通信機能を持った任意の機器を指す。
【００１７】
図１の名前解決装置は、名前問合せ部２と、データベース３と、名前更新部４と、応答部５と、ネットワーク処理部６と、管理部７とを備えている。
【００１８】
名前問合せ部２は、ネットワーク１に接続されている他のノードに名前を問い合わせて、各ノードのノード情報を収集する。収集されたノード情報は、データベース３に格納される。
【００１９】
インターネット上のプロトコルであるIPv6（Internet Protocol version 6）では、例えばICMP（Internet Control Message Protocol）ノード情報要求（node information query）などが利用可能である。なお、データベース３への格納は、人間が手動で行ってもよいが、以下では自動的に収集する仕組みについて説明する。
【００２０】
名前更新部４は、ネットワーク１上の各ノードのノード情報が変更になっているか否かを判断して、ノード情報が変更になっていれば、データベース３を更新する。
【００２１】
応答部５は、他のノードからの問合せに対して、自ノードのノード情報をネットワーク１経由で返信する。ネットワーク処理部６は、ネットワーク１を経由したデータの送受信を制御する。
【００２２】
管理部７は、名前問合せ部２が問い合わせて収集した各ノードのノード情報を、名前（name）、ネットワークＩＤ（network ID）、ネットワーク・プレフィックス（network prefix）及びインタフェースＩＤ（interface ID）で管理する。ネットワークＩＤとは、ネットワーク１自体の識別情報であり、ネットワーク・プレフィックスとは、ネットワーク１上の位置を示す情報であり、インタフェースＩＤとは、ノードのインタフェース識別情報である。
【００２３】
例えば、名前問合せ部２が、あるネットワークＮｘに接続された２台のノードを見つけたとする。これら２台のノードは、図２のようなIPv6アドレスをもち、一台の名前はfoo、もう一台の名前はbarである。図２の「prefixlen 64」は、ネットワーク・プレフィックスのプレフィックス長が上位６４ビットであることを示している。
【００２４】
このとき、データベース３には、図３及び図４に示すような情報が格納される。すなわち、名前fooは、図３に示すように、ネットワークＩＤが「3ffe::/64」、ネットワーク・プレフィックスが「3ffe::/64」、インタフェースＩＤが「::230:65ff:fe1a:3525」である。また、名前barは、図４に示すように、ネットワークＩＤが「3ffe::/64」、ネットワーク・プレフィックスが「3ffe::/64」、インタフェースＩＤが「::203:93ff:fe00:e6ac」である。
【００２５】
以下では、名前、ネットワークＩＤ、ネットワーク・プレフィックス及びインタフェースＩＤをエントリと呼ぶ。
【００２６】
各ノードは、データベース３に格納された各ネットワークＩＤに対して、固有の名称をつけることができる。例えば、「自宅」、「親戚の家」などである。
【００２７】
各ノードを外部ネットワーク１に接続した場合でも、自己が所持するデータベース３を参照し、自己が定めた（グローバル・ユニークではない）名称を用いて通信相手のIPv6アドレスを指定することができる。
【００２８】
各ノードは、自己が持つローカルなデータベース３の中から、いくつかのエントリを選択的に他人（他ノード）に教えることができる。これにより、自己が選んだ相手のみに名前を公開することができる。
【００２９】
また、名前問合せ部２は、自己が接続しているネットワーク１上の他のノードのエントリを定期的に自動収集することも可能である。
【００３０】
ネットワーク１上に接続されるノードの種類や名前は時間によって変化するため、データベース３に保存されているエントリが実際には存在しない可能性もある。このため、定期的にデータベース３の更新を行う必要がある。
【００３１】
（第１の更新例）
第１の更新例は、ノードが直接移動して、ネットワーク１上の他のノードの名前を収集可能な場合を念頭に置いている。
【００３２】
図５はデータベース３の第１の更新例を示すシーケンス図である。まず、あるノードをネットワーク１に接続し、ネットワーク１上の他のノードに名前を問い合わせる（ステップＳ１）。他のノードから返答があると（ステップＳ２）、管理部７はプレフィックスが変更されたか否かを判定する（ステップＳ３）。変更されていなければ処理を終了し、変更されていれば、データベース３を更新する（ステップＳ４）。
【００３３】
上述したステップＳ３では、ネットワーク１上の各ノードのインタフェースＩＤに基づいてプレフィックスを更新する。すなわち、名前問合せ部２が収集した名前の中に、同じインタフェースＩＤを持つが、異なるネットワーク・プレフィックスを持つノードが存在する場合、名前更新部４は、名前が更新されたと判断し、データベース３上のそのインタフェースＩＤに対応するネットワーク・プレフィックスを新しいプレフィックスに置き換えるという動作を行って、名前の更新を行う。
【００３４】
例えば、あるノードＭが、図２に示す２台のノードが接続されたネットワークNxから離れている間に、このネットワークNxでリナンバリングが行われ、ネットワーク・プレフィックスが「3ffe:/64」から「2001::/64」に変更になったとする。その後に、ノードＭがネットワークNxに移動してきて名前の収集を行い、図６に示す２台のノードを発見したとする。
【００３５】
図６に示す２台のノードのインタフェースＩＤは、図２に示す２台のノードのインタフェースＩＤと同じであるため、ノードＭの名前更新部４は、ネットワーク・プレフィックス「3ffe::/64」が「2001::/64」に変更されたと判断し、データベース３を更新する。
【００３６】
上述したインタフェースＩＤは、必ずしもグローバル・ユニークなものとは限らないため、上述した第１の更新例は、インタフェースＩＤが比較的グローバル・ユニークなEUI-64形式の場合のみに適用可能である。
【００３７】
また、ノードが属するネットワーク１のデフォルト・ルータのプレフィックスが変化した場合のみ、上述したデータベース３の更新処理を行ってもよい。あるいは、データベース３を更新してもよいか否かをユーザに確認してもよい。
【００３８】
このように、第１の更新例では、インタフェースＩＤが同じでネットワーク・プレフィックスが異なるノード情報については、ノード情報が更新されたと判断してデータベース３の更新を行うため、データベース３を自動更新することができる。
【００３９】
（第２の更新例）
第２の更新例は、身元の知れたノードに対してのみ名前の更新情報を知らせるものである。
【００４０】
自己が直接ネットワーク１に接続しない場合、例えばネットワーク１に接続されているノードの情報を第三者から教えてもらった場合は、そのネットワーク１で名前の更新が行われても、第三者から更新情報を教えてもらわない限り、データベース３を更新できない。この場合、データベース３を更新する方法として、新しいエントリを持っている第三者からデータベース３を更新してもらう方法が考えられる。この方法では、データベース３中の更新前のエントリが持っているネットワークＩＤと同じ値を持つすべてのエントリのネットワーク・プレフィックスを更新後の値に変更する。これにより、プライバシを保持したまま、効率的にプレフィックスの更新を行うことができる。
【００４１】
図７は第２の更新例を説明するネットワーク配置図、図８はデータベース３の第２の更新例を示すシーケンス図である。図７では、ネットワークNxの所有者をＸとし、ある人間ＡがネットワークNxについての情報として、ネットワーク所有者Ｘから２つの名前foo,barのノード情報をすでに教えてもらっていたとする（ステップＳ１１）。人間Ａはネットワーク１には直接接続されていないとする。
【００４２】
その後、ネットワークNxがリナンバリングを行い、ネットワーク・プレフィックスが変わったとする（ステップＳ１２）。この場合、ネットワーク所有者Ｘは人間Ａに会ったときに、ネットワーク・プレフィックスが変わったことを伝えなければならないが、すでにネットワーク所有者Ｘは人間Ａに何を教えていたか忘れてしまったとする。
【００４３】
このとき、人間Ａは、ネットワーク所有者Ｘに対して、ネットワークNxについて知っているインタフェースＩＤを一つ選択し、そのハッシュ値を教える（ステップＳ１３）。ここでは、選択したインタフェースＩＤをハッシュ関数に入力してハッシュ値を求める。
【００４４】
なお、必ずしもハッシュ関数を利用する必要はなく、非可逆変換が可能な一方向性関数であればよい。
【００４５】
ネットワーク所有者Ｘは、自己が持っているエントリからハッシュ値に合致するエントリを探し、エントリがあれば、それに対するインタフェースＩＤを除いたエントリの内容を人間Ａに通知する（ステップＳ１４）。人間Ａは、通知されたエントリの内容に従って自己のデータベース３を更新する（ステップＳ１５）。
【００４６】
このような手順を行うことで、ネットワーク所有者Ｘは、人間Ａが何を持っているか忘れていても、不必要にすべてのエントリを教えることを避けることができる。また、人間Ａは、ネットワーク１に接続されていなくても、ネットワーク１上の名前の変更に応じて、データベース３を更新できる。
【００４７】
上述した第２の更新例は、プライバシを保護した伝聞による更新にも利用可能である。例えば、図９に示すように、人間ＢがネットワークNxについての情報として、ネットワーク所有者Ｘから名前fooに関する情報だけを教えてもらっているとする。すなわち、ネットワーク所有者Ｘが、例えば名前barに関する情報を人間Ｂに教えたくないような場合である。
【００４８】
ネットワーク所有者Ｘが名前の変更を行ったという事実が秘密でないと仮定する。人間Ａは、人間Ｂに会ったときに、人間Ｂが持っているインタフェースＩＤのハッシュ値を教えてもらう。このハッシュ値が人間Ａが持っているものと一致すれば、人間Ａは、人間Ｂに対して、インタフェースＩＤを除いたエントリのみを教える。
【００４９】
これにより、人間Ｂはすでに持っている情報を更新できるが、新しいエントリを取得することはできない。すなわち、人間Ｂは、元々知っている情報以外の情報を得ることはできない。同様に、人間Ａは、人間ＢからネットワークＮx上の新しいノード情報を得ることはできない。
【００５０】
このように、第２の更新例では、ハッシュ値が一致する場合のみ、相手に名前の更新情報を通知するため、プライバシを保護でき、セキュリティ性を向上できる。
【００５１】
（第３の更新例）
第３の更新例は、ネットワーク・プレフィックスをDNSに登録し、ネットワーク・プレフィックスの値をFQDNで示すものである。
【００５２】
第３の更新例では、各ノードのデータベース３に、ネットワーク・プレフィックスとしてFQDNを保存する。ネットワーク・プレフィックスとFQDNとの変換は、DNSが行う。DNSは、各ノードとは別個にネットワーク１に接続されている。
【００５３】
ネットワーク所有者Ｘが自己のネットワーク１に関する何らかのFQDNを持っている場合、すなわち、自己のネットワーク１に対するドメインを持っている場合、エントリの中のネットワーク・プレフィックスの値を、実際のプレフィックスではなく、プレフィックスを示すFQDNにすることができる。
【００５４】
アドレス解決の必要性が発生すると、データベース３に保存されているFQDNに対応するネットワーク・プレフィックスをDNSに問い合わせる。応答部５は、DNSから回答のあったネットワーク・プレフィックスを用いて、IPv6アドレスを生成して応答する。
【００５５】
各ノードのデータベース３には、ネットワーク・プレフィックスの代わりにFQDNに対応する値が保存されているため、リナンバリングの際には、FQDNに対応する値を更新すればよい。各ノードは、定期的にこのFQDNに対応する値を確認し、他のノードから、あるノードのIPv6アドレス要求があった場合には、最も最近のFQDNに対応するネットワーク・プレフィックスとインタフェースIDからIPv6アドレスを生成して応答する。すなわち、IPv6アドレスの要求があるたびに、FQDNに対応するネットワーク・プレフィックスをDNSに問合せるのは面倒であるため、過去にDNSに問合せたネットワーク・プレフィックスをキャッシュしておき、ノードからIPv6アドレスが要求されると、このキャッシュからネットワーク・プレフィックスを読み出して送信する。これにより、アドレス要求に対する応答を高速化することができる。もちろん、毎回ＤＮＳを確認してもよい。
【００５６】
例えば、Nx.orgというドメインが存在する場合、すなわち、「network.Nx.orgは3ffe::である」という情報と、その逆引き「3ffe::はNx.orgである」という情報とがDNSで管理されているとする。
【００５７】
あるノードが自己のデータベース３にノード情報を格納する際は、ネットワーク・プレフィックスの逆引きを行い、それに対してFQDNが設定されている場合は、FQDNを正引きしてその値が一致していることを確認したうえで、ネットワーク・プレフィックスとしてFQDN（この例では、network.Nx.org）を自己のデータベース３に保存する。データベース３に保存されたFQDNは、適宜ネットワーク１に問い合わせることにより、更新可能である。
【００５８】
このように、第３の更新例では、各ノードのデータベース３に、ネットワーク・プレフィックスの代わりにFQDNを保存するため、無作為な文字列であるネットワーク・プレフィックスを保存するよりも、ノード情報が把握しやすくなる。
【００５９】
上述した各実施形態では、各ノードがIPv6アドレスを有する例を示したが、アドレスには特に制限はなく、例えば、IPv4でもよい。
【００６０】
【発明の効果】
以上詳細に説明したように、本発明によれば、ネットワーク上のノード情報が変更されても、変更があったことを各ノードに簡易な手順で知ることができる。また、ネットワーク上の他のノードに対して、プライバシを維持した状態で、ノード情報を送信できる。
【図面の簡単な説明】
【図１】本発明に係る名前解決装置の一実施形態の概略構成を示すブロック図。
【図２】ネットワークに接続された２台のノードのIPv6アドレスの例を示す図。
【図３】図２の名前fooのエントリを示す図。
【図４】図２の名前barのエントリを示す図。
【図５】データベースの第１の更新例を示すシーケンス図。
【図６】リナンバリングを行った後の２台のノードのIPv6アドレスの例を示す図。
【図７】第２の更新例を説明するネットワーク配置図。
【図８】データベースの第２の更新例を示すシーケンス図。
【図９】第２の更新例の変形例を説明するネットワーク配置図。
【符号の説明】
１ ネットワーク
２ 名前問合せ部
３ データベース
４ 名前更新部
５ 応答部
６ ネットワーク処理部
７ 管理部
Claims (5)
- 所定のネットワークに接続された個々のノードの名前と各ノードを識別するアドレスとを管理する名前解決装置において、
個々のノードごとに、ノードの名前、ネットワーク識別情報、ネットワーク上の位置を示すプレフィックス及びノードのインタフェース識別情報からなるノード情報を保存するノード情報保存部と、
ネットワークに接続されている他のノードに関する前記ノード情報を、ネットワークを介して収集するノード情報収集部と、
前記ノード情報収集部にて収集した他のノードに関する前記ノード情報に基づいて、前記ノード情報保存部に保存されている前記ノード情報を更新するノード情報更新部と、
前記ノード情報保存部に保存されている前記ノード情報のうち、所定のノードに対応する前記インタフェース識別情報を一方向性関数にて変換する関数変換部と、
前記一方向性関数にて変換された前記インタフェース識別情報を他のノードから受け取った場合に、この識別情報と前記関数変換部で変換された前記インタフェース識別情報とを比較する比較部と、
前記比較部で一致したと判定される場合のみ、比較した前記インタフェース識別情報に対応する前記プレフィックスを前記他のノードに提供するノード情報提供部と、を備えることを特徴とする名前解決装置。 - 前記ノード情報更新部は、前記ノード情報収集部にて収集した前記ノード情報に含まれる前記インタフェース識別情報を鍵として、前記ノード情報保存部に保存されている前記プレフィックスを更新することを特徴とする請求項１に記載の名前解決装置。
- 前記一方向性関数は、ハッシュ関数であることを特徴とする請求項１または２に記載の名前解決装置。
- 前記ノード情報保存部に保存されている前記ノード情報に基づいて、動的にIPv6（Internet Protocol version 6）アドレスを生成するアドレス生成部を備えることを特徴とする請求項１及至３のいずれかに記載の名前解決装置。
- 所定のネットワークに接続された個々のノードの名前と各ノードを識別するアドレスとを管理する名前解決方法において、
個々のノードごとに、ノードの名前、ネットワーク識別情報、ネットワーク上の位置を示すプレフィックス及びノードのインタフェース識別情報からなるノード情報を保存し、
ネットワークに接続されている他のノードに関する前記ノード情報を、ネットワークを介して収集し、
前記収集された他のノードに関する前記ノード情報に基づいて、前記保存されているノード情報を更新し、
前記保存されているノード情報のうち、所定のノードに対応する前記インタフェース識別情報を一方向性関数にて変換し、
前記一方向性関数にて変換された前記インタフェース識別情報を他のノードから受け取った場合に、この識別情報と前記一方向性関数にて変換された前記インタフェース識別情報とを比較し、
前記比較により一致したと判定される場合のみ、比較した前記インタフェース識別情報に対応する前記プレフィックスを前記他のノードに提供することを特徴とする名前解決方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002287717A JP3692107B2 (ja) | 2002-09-30 | 2002-09-30 | 名前解決装置及び名前解決方法 |
| US10/671,738 US7908356B2 (en) | 2002-09-30 | 2003-09-29 | Name resolution device and name resolution method with automatic node information updating function |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002287717A JP3692107B2 (ja) | 2002-09-30 | 2002-09-30 | 名前解決装置及び名前解決方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004128727A JP2004128727A (ja) | 2004-04-22 |
| JP3692107B2 true JP3692107B2 (ja) | 2005-09-07 |
Family
ID=32280416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002287717A Expired - Lifetime JP3692107B2 (ja) | 2002-09-30 | 2002-09-30 | 名前解決装置及び名前解決方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7908356B2 (ja) |
| JP (1) | JP3692107B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4244968B2 (ja) | 2005-07-05 | 2009-03-25 | ブラザー工業株式会社 | 端末装置、およびプログラム |
| JP4682329B2 (ja) * | 2006-02-15 | 2011-05-11 | 独立行政法人情報通信研究機構 | 通信ネットワークにおけるネームシステム及びネーミング方法 |
| US9288216B2 (en) * | 2008-06-19 | 2016-03-15 | Qualcomm Incorporated | Methods and apparatus for reducing the effectiveness of chosen location attacks in a peer-to-peer overlay network |
| US8699515B2 (en) * | 2009-07-21 | 2014-04-15 | Cisco Technology, Inc. | Limiting of network device resources responsive to IPv6 originating entity identification |
| JP5041381B2 (ja) * | 2010-02-05 | 2012-10-03 | Ｎｅｃアクセステクニカ株式会社 | 名前解決システム、名前解決サーバ、名前解決方法及び名前解決プログラム |
| US9912557B2 (en) | 2013-03-01 | 2018-03-06 | Nec Corporation | Node information detection apparatus, node information detection method, and program |
| US9794218B2 (en) | 2014-04-29 | 2017-10-17 | Trustiosity, Llc | Persistent network addressing system and method |
| US9774531B2 (en) * | 2014-09-26 | 2017-09-26 | Futurewei Technologies, Inc. | Hash-based forwarding in content centric networks |
| US9967227B2 (en) | 2015-11-11 | 2018-05-08 | Fastly, Inc. | Enhanced content route selection in content delivery networks |
| US11232488B2 (en) | 2017-08-10 | 2022-01-25 | Nextroll, Inc. | System, devices and methods for identifying mobile devices and other computer devices |
| US11716375B2 (en) * | 2017-11-22 | 2023-08-01 | Nextroll, Inc. | System, devices and methods for identifying mobile devices and other computer devices |
| US11196705B2 (en) * | 2018-01-05 | 2021-12-07 | Nextroll, Inc. | Identification services for internet-enabled devices |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5185860A (en) * | 1990-05-03 | 1993-02-09 | Hewlett-Packard Company | Automatic discovery of network elements |
| US6101499A (en) * | 1998-04-08 | 2000-08-08 | Microsoft Corporation | Method and computer program product for automatically generating an internet protocol (IP) address |
| US6160804A (en) * | 1998-11-13 | 2000-12-12 | Lucent Technologies Inc. | Mobility management for a multimedia mobile network |
| KR100856149B1 (ko) * | 1999-11-26 | 2008-09-03 | 네테카 인코포레이티드 | 전자 메일 서버 및 전자 메일 통신을 용이하게 하기 위한 방법 |
| US20020087722A1 (en) * | 2000-12-29 | 2002-07-04 | Ragula Systems D/B/A/ Fatpipe Networks | Domain name resolution making IP address selections in response to connection status when multiple connections are present |
-
2002
- 2002-09-30 JP JP2002287717A patent/JP3692107B2/ja not_active Expired - Lifetime
-
2003
- 2003-09-29 US US10/671,738 patent/US7908356B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US7908356B2 (en) | 2011-03-15 |
| JP2004128727A (ja) | 2004-04-22 |
| US20040133675A1 (en) | 2004-07-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3848198B2 (ja) | ネームサーバ、ネットワーク・システム、逆引き要求処理方法、正引き要求処理方法及び通信制御方法 | |
| EP1759510B1 (en) | Method and apparatus for looking up configuration information for a network node | |
| EP1583323B1 (en) | Communications apparatus, name resolution method and program | |
| JP3935459B2 (ja) | コンテンツ管理装置、コンテンツ管理システム及びコンテンツ管理プログラム | |
| US7779158B2 (en) | Network device | |
| US20060206608A1 (en) | User terminal management apparatus, user terminal management program, and user terminal management system | |
| JP3692107B2 (ja) | 名前解決装置及び名前解決方法 | |
| WO2005096160A1 (en) | Proxy dns for web browser request redirection in public hotspot accesses | |
| JP4524906B2 (ja) | 通信中継装置、通信中継方法、および通信端末装置、並びにプログラム記憶媒体 | |
| Yan et al. | Is DNS ready for ubiquitous Internet of Things? | |
| JP4186733B2 (ja) | 通信システム、端末及びアドレス生成方法 | |
| JP2005101890A (ja) | 名前登録仲介装置、名前解決仲介装置、名前解決システム、名前解決方法、名前登録仲介プログラムおよび名前解決仲介プログラム | |
| WO2001033364A1 (fr) | Dispositif pour rechercher le nom d'un noeud de communication dans un reseau de communication | |
| EP2077018B1 (en) | Method for controlling access to a network in a communication system | |
| EP2077029B1 (en) | Identifying a subnet address range from dns information | |
| Bajko | Locating IEEE 802.21 mobility services using DNS | |
| JP2007226343A (ja) | プレゼンス・システム、プレゼンス提供方法およびプログラム | |
| EP1465390A2 (en) | Method of automatically determining device's nickname, and method of avoiding redundant nicknames for devices in network and network system thereof | |
| JP2006148241A (ja) | ホームゲートウェイ装置及びｉｐ通信方法 | |
| JP2004120125A (ja) | ルータおよびルータ設定情報処理方法 | |
| JP2004120470A (ja) | サーバ装置及び名前解決方法 | |
| Jiang et al. | Privacy considerations for DHCP | |
| Cheshire | RFC 8766: Discovery Proxy for Multicast DNS-Based Service Discovery | |
| CN116800718A (zh) | 域名查询方法、装置、非易失性存储介质及电子设备 | |
| JP2007037072A (ja) | 接続先切り替え通信ネットワークシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041227 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050315 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050516 |
|
| 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: 20050607 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050617 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3692107 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090624 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090624 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100624 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100624 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110624 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120624 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120624 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130624 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |