コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Zeroconf

出典: フリー百科事典『ウィキペディア（Wikipedia）』
（ZeroConfから転送）

Zeroconf（ゼロ・コンフィギュレーション・ネットワーキング）は、人手による操作を介さず、かつ特別なコンフィギュレーションサーバを使わずに、利用可能な Internet Protocol (IP) ネットワークを自動的に作成する一連の技法である。

ゼロ・コンフィギュレーション・ネットワーキングはコンピュータや周辺機器を自動的にネットワークに接続することを可能にする。Zeroconfがない場合、ネットワーク管理者が Dynamic Host Configuration Protocol (DHCP) や Domain Name System (DNS) といったサービスの設定をする必要があり、場合によっては個々のコンピュータのネットワーク設定を人手で変更する必要もあり、時間がかかり面倒である。

Zeroconf は次の3つの技術に基づいている。

  • ネットワークデバイスへのネットワークアドレスの割り当て
  • コンピュータのホスト名の自動解決と自動配布
  • プリンターなどのネットワークデバイスの位置を自動的に特定
TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ

アドレス選択

[編集]

IPv4とIPv6には共にIPアドレスを自動設定する標準の方法が存在する。リンクローカルと呼ばれるそのアドレス設定において、IPv4では RFC 3927 に規定されている特別なブロック 169.254.0.0/16 を使用し、IPv6ではプレフィックス fe80::/10 を使用する。

ほとんどのIPv4ホストは、リンクローカルのアドレス設定 (IPv4LL) をDHCPサーバが利用できないときの最後の手段としてのみ使用する。通常、IPv4ホストはグローバルかリンクローカルかを問わずDHCPの割り当てたアドレスを使用している。その理由の1つは、IPv4ホストがインタフェース毎に1つのアドレスしか必要としないためである。もう1つの理由は、全てのIPv4ホストが分散名前解決機能（例えば、マルチキャストDNS）を実装しているわけではなく、そのためネットワーク上の他ホストの自動設定されたリンクローカルアドレスを発見するのが困難なためである。しかし、DHCPが他ホストに割り当てたアドレスを発見する場合でも、分散名前解決機能か必要な情報を持ったユニキャスト方式のDNSサーバを必要とし、一部のネットワークはDHCPで割り当てたホストとアドレスに関する情報で自動的に更新されるDNSサーバを備えている。

IPv6ホストはインタフェース毎に複数のアドレスをサポートすることを要求される。それだけでなく、IPv6ホストはグローバルアドレスが利用可能な場合でもリンクローカルアドレスを設定できなければならない。さらにIPv6ホストは複数のルータアドバタイズメント・メッセージの受信に応じて複数のグローバルアドレスを自分で設定することがあり、それによってDHCP6サーバを不要としている。詳しくは RFC 4862 を参照。

IPv4でもIPv6でも、自動設定アドレスのホスト固有部分は無作為に生成されることがある。IPv6ホストは一般に最大64ビットのプレフィックスと製造時に割り当てられた48ビットの IEEE MACアドレスから派生した64ビットの EUI-64 を結合する。ホストは通常ブロードキャストクエリを通じて、生成するアドレスをそのローカルネットワーク内の他ホストが使っていないことを保証する必要がある。

RFC 3927 ではこの技法を「リンクローカル」アドレス割り当てと呼ぶ。しかし、マイクロソフトではこれを Automatic Private IP Addressing (APIPA) または Internet Protocol Automatic Configuration (IPAC) と称している（遅くとも Windows 98 からサポートしている[1]）。

名前解決

[編集]

2000年、Bill Manning と Bill Woodcock が Multicast Domain Name Service[2] を発表し、そこからAppleとマイクロソフトの実装が生まれた。両社の実装はよく似ている。AppleのマルチキャストDNS (mDNS) はIETFの RFC 6762 として、マイクロソフトのLLMNR（Link-Local Multicast Name Resolution（英語版））は RFC 4795 として公開されている。

この2つのプロトコルは名前解決の方法に若干の差異がある。mDNSでは、ネットワークデバイスが local 名前空間にあるドメイン名を選ぶことができ、それを特別なマルチキャストIPアドレスを使って告知する。これは local ドメインに特別な意味論を導入するため[3]、IETFの何人かのメンバーが問題視している[4]。現在のLLMNRのドラフトでは任意のドメイン名を選択できるが、IETFの一部メンバーはセキュリティ上の危険を指摘している[5]。mDNSは後述するように DNS-SD と互換性があるが、LLMNR はそうではない[6]。

サービス発見

[編集]

Appleのプロトコル: マルチキャストDNS/DNS-SD

[編集]

マルチキャストDNS (mDNS) はユニキャストの Domain Name System と似たAPIを使うプロトコルだが、マルチキャストプロトコル上に実装されている。LAN上の各コンピュータはそれぞれDNSのリソースレコード（例えば、A、MX、SRVなど）のリストを持ち、mDNSのマルチキャストグループに参加している。あるmDNSクライアントがPCの名前からそのIPアドレスを知りたい場合、mDNSクライアントは既定のマルチキャストアドレスに要求を送信する。すると対応するAレコードを持つPCがそのIPアドレスを含めて応答する。IPv4でのmDNSマルチキャストアドレスは 224.0.0.251 で、IPv6のリンクローカル・アドレッシングでは ff02::fb である。

Appleの方式のもう半分は DNS-SD (DNS based Service Discovery) で、Domain Name Systemの上に構築されている。Appleの製品、多くのネットワークプリンター、様々なサードパーティ製品や各種OS向けのアプリケーションで使われている。Appleの方式ではDNSメッセージを使用しているが、対抗しているマイクロソフトの方式であるSSDPではHTTPメッセージを使用している。DNSのSRVレコード、TXTレコード、PTRレコードを使いサービスインタフェース名を告知する。サービスを提供しているホストは利用可能なサービスの詳細（インスタンス、サービスの種類、ドメイン名、オプションの設定パラメータなど）を告知（出版）する。サービスの種類は先着順で簡単に登録されている。DNS-SD.org がそのレジストリを保守・公表している。

SafariブラウザやiChatインスタントメッセンジャーなどmacOSの多くのネットワーククライアントは手近のサーバを特定するのにDNS-SDを使っている。Windows上では、一部のインスタントメッセンジャーやVoIPでDNS-SDをサポートしている。Unix系やLinuxディストリビューションにもDNS-SD機能を備えたものがある。

mDNS/DNS-SD を開発したのはAppleの従業員 Stuart Cheshire で、同社がAppleTalkからIPに方針転換したころである。

マイクロソフトのプロトコル: UPnP SSDP

[編集]

Simple Service Discovery Protocol (SSDP) はUPnPプロトコルの一種で Windows XP やいくつかのネットワーク機器ブランドで採用されている。SSDPはHTTPの通知 (NOTIFY) 機能を使い、サービス種別のURIと Unique Service Name (USN) を通知する。サービス種別は Universal Plug and Play 運営委員会が管理している。

SSDPはSOHO向けファイアウォール機器で多くサポートされており、ホストコンピュータがアプリケーションのためにファイアウォールに穴をあける。またホームシアターシステムとホストコンピュータ間のメディア交換にもSSDPが使われている。

サービス・ロケーション・プロトコル

[編集]

サービス・ロケーション・プロトコル (Service Location Protocol、SLP) は、サービス発見用プロトコルとして唯一 IETF のインターネット標準となったもので、ヒューレット・パッカードのネットワークプリンター、ノベルの製品、サン・マイクロシステムズの製品などで採用されている。SLP の仕様は RFC 2608 と RFC 3224 にあり、利用可能な実装としては Solaris に搭載されているもの、Linux/Windows/Java API用のOpenSLP[7]等がある。かつてはMac OS 9やMac OS Xにも搭載されていた。

標準化

[編集]

2005年3月、Apple、サン・マイクロシステムズ、マイクロソフトなどからの参加者を含むIETFのZeroconfワーキンググループはネットワーク上のアイテムにアドレスを割り当てる標準として RFC 3927 を公表した[8]。

LLMNR は公式採用に向けてIETFのDNSEXTワーキンググループに提出されたが合意には至らず、単なる情報RFCとして RFC 4795 が公表されるにとどまった[9]。LLMNRがインターネット標準として採用されず失敗に終わった後、IETFはLLMNRより広く採用されている mDNS/DNS-SD の仕様を情報RFCとして公表するようAppleに依頼した。現在それらは RFC 6762 として公表されている。

サービス発見のためのSLPの仕様は RFC 2608 としてIETFのSVRLOCワーキンググループが公表した[10]。

セキュリティ問題

[編集]

ユニキャストの信頼できるDNSがネットワーク全体を管理するモデルとは異なり、mDNSはなりすましによって情報を盗まれる危険性が高いと指摘されている。SNMPなどのネットワーク管理プロトコルと同様、mDNSを使ってそのネットワークの構成や個々のホストについて詳細情報が容易に得られるという問題もある[11]。

主な実装

[編集]

Apple Bonjour

[編集]

AppleのBonjour（以前はRendezvousと称していた）は、マルチキャストDNSと DNS Service Discovery を使用している。Appleは同社推奨のzeroconf技術を Mac OS X v10.1とv10.2の間にSLPからmDNS/DNS-SDに変更した経緯があるが、macOSでのSLPサポートは続いている。

AppleのmDNSResponderはCとJavaのインタフェースを持ち[12]、BSD、macOS、Linux、POSIX系OS、Windows で利用可能である。Windows版はAppleのウェブサイトからダウンロードできる[13]。

Avahi

[編集]

AvahiはLinuxとBSD向けのZeroconf実装である。IPv4LL、mDNS、DNS-SD を実装している。ほとんどのLinuxディストリビューションに含まれており、デフォルトでインストールするものもある。nss-mdns と連動して作動させるとホスト名解決機能を提供する[14]。

AvahiにはBonjourおよび歴史的なmDNS実装であるHowlとのバイナリ互換性を提供するライブラリがあり、それらに対応したソフトウェアをAvahiを経由して利用することができる。

Windows CE 5.0

[編集]

Windows CE 5.0 にはマイクロソフト独自のLLMNR実装が含まれている。

リンクローカル IPv4 アドレス

[編集]

以下のような実装が利用可能である。

  • Windowsと Mac OS はどちらも1998年からリンクローカルアドレスをサポートしている。AppleはDarwinのbootpパッケージでオープンソース実装をリリースしている。
  • Avahiのavahi-autoipdツールにはIPv4LLの実装が含まれている。
  • zcip (Zero-Conf IP)
  • BusyBoxはIPv4LLの単純な実装を組み込み可能である。
  • Stablebox - BusyBoxからのフォークであり、lladと呼ばれる若干異なるIPv4LL実装を提供している。
  • zeroconf - 単純なIPv4LLに基づくパッケージで、作者は Arthur van Hoff [15]。

以上の実装はいずれもスタンドアロンのデーモンまたはリンクローカルIPアドレスだけを扱うDHCPクライアント用プラグインである。既存または新規のDHCPクライアントもサポートするものとして次のものがある。

  • Elvis Pfützenreuter はuDHCPクライアント/サーバ向けのパッチを書いた[16]。
  • dhcpcd は、LinuxおよびBSD向けのオープンソースのDHCPクライアントで、IPv4LLサポートを含んでいる。NetBSDには標準として含まれている。

これらの実装では、ARP応答のブロードキャスト[17]や既存のネットワークコネクションが閉じられるといったカーネル問題には対処していない。

脚注・出典

[編集]
  1. ^ 自動 TCP/IP アドレス指定に DHCP サーバーを使用する方法
  2. ^ Multicast Domain Name Service
  3. ^ Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard 2005/08/25
  4. ^ Re: Summary of the LLMNR Last Call 2005/09/20
  5. ^ Summary of the LLMNR Last Call 2005/09/18
  6. ^ Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard 2005/08/25
  7. ^ “About OpenSLP”. openslp.org. 2015年12月17日閲覧。
  8. ^ Zero Configuration Networking (zeroconf) Charter
  9. ^ DNS Extensions (dnsext) Charter
  10. ^ Service Location Protocol (svrloc) Charter
  11. ^ Name (MDNS) Poisoning Attacks Inside the LAN 2008/01/23
  12. ^ MacDevCenter.com - A Rendezvous with Java 2004/08/31
  13. ^ Bonjour Print Services for Windows Apple Inc.
  14. ^ nss-mdns 0.10
  15. ^ ソースコード (AVH-IPv4LL.c)
  16. ^ [udhcp] Fwd: Zeroconf in udhcpc
  17. ^ AIR Wiki: Link-Local ARP Measurements

参考文献

[編集]
  • Erik Guttman (2001). “Autoconfiguration for IP Networking: Enabling Local Communication”. IEEE Internet Computing 5 (3): 81–86. doi:10.1109/4236.935181. 

関連項目

[編集]

外部リンク

[編集]
「https://ja-two.iwiki.icu/w/index.php?title=Zeroconf&oldid=102999415」から取得