コンテンツにスキップ

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

「Zeroconf」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
Cewbot (会話 | 投稿記録)
Cewbot (会話 | 投稿記録)
119行目: 119行目:
[[Category:Domain Name System]]
[[Category:Domain Name System]]
[[Category:システム管理]]
[[Category:システム管理]]
[[Category:アップルのソフトウェア]]
[[Category:Appleのソフトウェア]]

2021年5月23日 (日) 07:17時点における版

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

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

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

  • ネットワークデバイスへのネットワークアドレスの割り当て
  • コンピュータのホスト名の自動解決と自動配布
  • プリンターなどのネットワークデバイスの位置を自動的に特定

アドレス選択

IPv4IPv6には共に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とマイクロソフトの実装が生まれた。両社の実装はよく似ている。アップルのマルチキャストDNS (mDNS) はIETFRFC 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]

サービス発見

アップルのプロトコル: マルチキャスト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 である。

アップルの方式のもう半分は DNS-SD (DNS based Service Discovery) で、Domain Name Systemの上に構築されている。アップルの製品、多くのネットワークプリンター、様々なサードパーティ製品や各種OS向けのアプリケーションで使われている。アップルの方式では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 を開発したのはアップルの従業員 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 2608RFC 3224 にあり、利用可能な実装としては Solaris に搭載されているもの、Linux/Windows/Java API用のOpenSLP[7]等がある。かつてはMac OS 9Mac OS Xにも搭載されていた。

標準化

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

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

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

セキュリティ問題

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

主な実装

Apple Bonjour

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

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

Avahi

AvahiLinuxBSD向けの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年からリンクローカルアドレスをサポートしている。アップルは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]や既存のネットワークコネクションが閉じられるといったカーネル問題には対処していない。

脚注・出典

参考文献

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

関連項目

外部リンク