第6回　LLMNRを使ったローカル・セグメント上での名前解決：Windows管理者のためのIPv6入門

IPv6アドレスは128bitもあり、そのままでは取り扱うのは困難である。通常はホスト名やドメイン名を組み合わせて対象となるホストを表すことになる。FQDN名からIPv6アドレスを求めることを「名前解決」といい、Windows環境ではDNSとLLMNRがよく使われる。今回はローカル・セグメント上での名前解決を行うLLMNRを解説する。

» 2013年05月23日 17時43分公開

[打越浩幸，デジタルアドバンテージ]

連載目次

　前回は、DHCPサーバを使ったステートフルなアドレス設定について解説した。DHCPを使えば、組織全体で計画的にIPv6アドレスを割り当てることができるようになる。とはいえ、IPv6アドレスは128bitもあり、記憶するのも取り扱うのも困難である。そこでPCを参照する場合は、IPv4の場合と同様に、IPv6アドレスではなくホスト名やドメイン名を使って参照することになる。そこで重要になるのが、名前からIPv6アドレスを求める「名前解決」である。今回は、「LLMNR」と呼ばれる機能を使ったローカル・ネットワーク・セグメント上での名前解決について取り上げる。

IPv6における名前解決の方法

　名前解決とは、例えば「PC1」や「WINDOWSPC2.example.jp」といったホスト名から、IPv6アドレスを取得することを指す。前回までは128bitのIPv6アドレスを直接そのまま扱っていたが（例：「2001:db8:dead:beef:5cf2:466:dd8:e870」など）、これは人間にとってはとても扱いづらいし、ドメイン名のような階層的な名前空間を定義することもできない。そこでIPv4の場合と同様に、IPv6でも文字列で表記したホスト名からIPv6アドレスを求めたり、逆にIPv6アドレスからホスト名を求めるための機能が用意されている。今回と次回では、その機能についてみていく。

　IPv6で、ホスト名からIPv6アドレスを取得する方法として、Windows OSでは次の2つの方法が利用できる。

LLMNR（Link-Local Multicast Name Resolution）
DNS（Domain Name System。DNSv6）

　DNSはすでにIPv4で広く使われているものなので、その機能や仕組みは容易に推測できるだろう。従来のDNS（以下DNSv4）では32bitのIPv4アドレスのみを扱っていたが、DNSv6では128bitのIPv6を扱えるように拡張している。具体的には、DNSv4ではAレコード（＊1）でホスト名とIPv4アドレスを関連付けていたが、DNSv6ではAAAAレコード（＊1）でホスト名とIPv6アドレスを関連付けている点だけが異なる。ただし逆引き（IPv6アドレスからホスト名を求める機能）については、IPアドレス表記が長くなっていることから、少し扱いが面倒になっている。そのためDNSv6の扱いについては次回行うこととし、今回はもう1つのLLMNRについて解説する。

＊1 「Aレコード」や「AAAAレコード」とは、DNSサーバの設定画面で使われる、レコード（DNSエントリ）の種類を表す用語である。IPv4の32bitのアドレスは、DNSサーバの管理画面上では「pc1 IN A 10.20.30.4」のように「A」という文字で表記されていることから、こう呼ばれている（「IN A」は「Internet Address」の略とされている）。AAAAレコードとは、128bitのIPv6アドレスを指す用語であり、32bitの4倍幅であることからAAAAレコードと呼ばれている。管理画面上では「pc2 IN AAAA 2001:db8:beef:1::1」のように表現される。

　なおWindows Server OSでは「WINS（Windows Internet Name Service）」や「LMHOSTS（Lan Manager hosts）」ファイルを使ってホスト名（NetBIOS名）とIPv4アドレスの対応を管理していたが、これらはIPv6環境では利用されない。IPv6環境では、DNSかLLMNRによってのみ名前解決を行う。

サーバレスでローカルでの名前解決を行うLLMNR

　LLMNRは、ネーム・サーバなしで動作する、ローカル・セグメント上での利用に特化した名前解決のための機能（サービス）である。RFC 4795として仕様が公開されている（標準プロトコル規格ではなく、情報提供を目的とする「Informational」という扱い）。

　従来Windowsネットワークでは、NetBIOSのブロードキャストを使った名前解決手段が広く使われていた（連載「基礎から学ぶWindowsネットワーク」の第18回「NetBIOS over TCP/IPプロトコル」参照）。特別なネーム・サーバなどを別途用意することなく、同一セグメント上のノード同士で名前解決のためのパケットをブロードキャストすることにより、通信相手を見つけるという技術である。単一のネットワーク・セグメントしか存在せず、クライアントPCばかりで構成される家庭やSOHOネットワークなどでは、このような簡便な名前解決が有用である。名前解決のためだけに、わざわざDNSサーバを用意する必要がないからだ（DNSサービスはWindowsの場合はServer系OSでしか提供されていない）。

　IPv6環境でも、このような簡素な名前解決手段が求められるのは当然だろう。だがIPv6ではNetBIOSやNBT（NetBIOS over TCP/IP）はサポートされていないため、マイクロソフトではそれに代わる名前解決の手段としてLLMNRを開発し、Windows OSに実装した。当初は「Local Server-Less DNS Name Resolution」という名称だったことからも分かるように（The Cable Guy - 2004 年 3 月「IPv6 の Local Server-Less DNS Name Resolution」参照）、DNSサーバなしで（DNSと同等の）名前解決ができるようなサービスを目指して開発されたようである。

　NetBIOS（NBT）の名前解決のサービスと比較すると、LLMNRでは次のような違いがある。

基本的には単一ラベルのホスト名のみが検索の対象となる。ただし例外として、末尾に「.local」が付いている場合は、最初のホスト名部分のみを取り出して検索する（例：「server1.local」なら→「server1」が検索対象となる）。ドメイン名のサフィックスが付いている場合、LLMNRは利用されないが、NetBIOSの場合は15文字以内ならFQDN形式でも検索できる。
IPv6上だけではなく、IPv4上でも利用できる。
IPv6ではブロードキャスト送信が利用できないため、代わりにIPv6のマルチキャスト送信を使う。
送信先マルチキャスト・アドレスは、IPv6の場合は「FF02::1:3」、IPv4の場合は「224.0.0.252」とする。
L2パケットの送信先アドレス（イーサネットのあて先アドレス）は、IPv6の場合は「33-33-00-01-00-03」、IPv4の場合は「01-00-5E-00-00-FC」とする。
LLMNRのパケットは基本的にはUDPプロトコルを使って送信する（RFC 4795の仕様ではTCPも利用可となっているがWindows OSでは使用していない）。送信先ポート番号は「5355」である。
パケットのホップ・リミット（通過可能なルータの数）は1にセットする。つまり、ルータを越えてルーティングされることはない。
内部的にはDNSとほぼ同じパケット構造を採用している。
LLMNRはWindows Vista／Windows Server 2008以降のWindows OSで利用できる

　LLMNRを使った場合の名前解決のイメージを次に示しておく。LLMNR環境では、各PCが必要に応じて随時LLMNRの問い合わせパケットをマルチキャストで送信し、該当する名前を持つPCがそれに応答する、という動作をする。

LLMNRの動作
LLMNRでは、マルチキャストで名前の問い合わせパケットを送信する。すると該当するホスト名を持つノードは、応答パケットに自分自身の持つアドレス（IPv4もしくはIPv6）をセットし、送信元のノードへユニキャストを使って返信する。やりとりされるパケットのデータ構造はDNSの問い合わせ／応答パケットに似ているが、DNSサーバを使っているわけではない。DNSに似せたパケットを使ってやりとりしているだけである。

　LLMNRのパケットの構造は、基本的にはDNSの問い合わせ／応答パケットの構造をほぼそのまま利用している。

●名前解決の優先順位について

　Windows OSの名前解決ではDNS以外にLLMNRやNBTも利用しているため、場合によってはその優先度（どれを先にチェックするか）が問題になることもある。基本的には次の順序で名前解決が行われる（DNSサーバやWINSサーバを設定していない場合はスキップされる）。

DNS（IPv4もしくはIPv6）
LLMNR（IPv4もしくはIPv6）
NBT／WINS（IPv4経由でのみ利用可能）

　上の方ほど優先度が高く、先に検索される。結果が得られなかったり、サーバの応答がなければその次のものをチェックするようになっているので、場合によってはいくらか待ち時間が発生することもある。

LLMNRパケットの例

　ではLLMNRパケットの実際の例を見てみよう。

　まず2台のPC（いずれもOSはWindows 7）を用意し、1つの独立したネットワーク上に配置する。ネットワーク上にはDNSサーバやDHCPサーバはないし、固定的なIPv6アドレスも付けていない。また各PCのIPv4はバインドを外してあるので、IPv4アドレスを使った通信はいっさい発生しない。代わりに自動生成された「2001:db8:beef:1010:～」というIPv6アドレスだけが付いている。この状態で、あるPC（PC1WIN7ULT1）から別のPC2（PC2WIN7PRO2）に対して、「ping -6 PC2WIN7PRO2」を実行したときのパケットをキャプチャしてみた。

LLMNRの問い合わせパケット
2つあるLLMNRの問い合わせパケットのうち、2つ目のIPv6アドレスを問い合わせるパケットの例。ネットワーク・モニタ3.4でキャプチャしている。
　 （1）「PC2WIN7PRO2」のIPv4アドレスを問い合わせるパケットと、その応答。
　 （2）「PC2WIN7PRO2」のIPv6アドレスを問い合わせるパケットと、その応答。以下では、この問い合わせパケットを展開表示している。
　 （3）このLLMNRパケットはIPv6上で送信されている。IPv6パケットのあて先はマルチキャスト・アドレスの「FF02::1:3」。
　 （4）このLLMNRパケットはUDPで送信されている。UDPパケットのあて先ポート番号は「5355」。
　 （5）LLMNRの問い合わせパケットを展開したところ。このパケットのデータ構造はDNSのパケットとほとんど同じ（一部フラグなどの解釈が異なる）。
　 （6）問い合わせ内容は、「pc2win7pro2」というホストの「AAAAレコード」を返すように求めている。

　pingを実行するためには、まず相手先PCのIPv6アドレスを調べなければならない。さもないと、IPv6パケットを送信できないからだ。これを調査するのがLLMNRによる問い合わせである。上のキャプチャ画面にはLLMNRの問い合わせと応答が2組あるが、最初のものはIPv4アドレスの問い合わせ（DNSのAレコードの問い合わせ）、次のものはIPv6アドレスの問い合わせ（DNSのAAAAレコードの問い合わせ）である。この問い合わせに対する応答は次のようになっている。

LLMNRの応答パケット
先ほどの問い合わせに対する応答パケット。対象となるホスト名を持っているノードのみが応答すること。この問い合わせ結果にはAAAAレコードが2つ含まれている。
　 （1）「PC2WIN7PRO2」のIPv6アドレス問い合わせに対する応答。
　 （2）LLMNRの応答パケットを展開表示したところ。
　 （3）問い合わせ結果は「Success」、つまり求めるレコードが見つかったということを表している。
　 （4）応答には2つのレコードが含まれている。
　 （5）問い合わせ内容。
　 （6）1つ目の応答AAAAレコード。
　 （7）IPv6アドレスは「2001:db8:beef:1001:～」。これが求めるアドレス。
　 （8）2つ目の応答AAAAレコード。
　 （9）IPv6アドレスは「ff80:0:0:0:～」。これは「PC2WIN7PRO2」のリンクローカル・ユニキャスト・アドレス。IPv6スタックの起動時に必ず割り当てられる、ローカルなIPv6アドレス。ローカルのセグメント上なら、このIPv6アドレスを使って通信してもよい（ルータを越えてこのアドレスへ送信することはできない）。

　応答パケットには、返信元のPCのIPv6アドレス情報が2つ含まれているのが分かるだろう。pingコマンドでは、この2つのうちのいずれかを使って、ICMPv6の通信を行う。この例では、リンク・ローカル・ユニキャスト・アドレスを使って以後のICMPv6の通信を行っていた。なお、LLMNRの応答パケットを受信した側は結果をLLMNR用のキャッシュに保存し、一定期間保持する。これにより、通信のたびにLLMNRを送信する必要がなくなる。

LLMNRキャッシュの表示

　LLMNRで解決された名前のキャッシュは、DNSで解決された名前のキャッシュとは別々に管理されているが、それぞれを確認する方法はWindows OSには特に用意されていない。コマンド・プロンプト上で「ipconfig /all」を実行すれば、名前解決され、キャッシュされた名前の一覧が表示されるが、それぞれのエントリがDNSキャッシュとLLMNRキャッシュのどちらに含まれているものかは判別できない。ちなみに、「ipconfig /flushdns」を実行すればキャッシュがすべて削除されるので、これを実行してから名前解決をさせると、どのようなホスト名が（DNSもしくはLLMNRで）名前解決されたかを確認できる。

「ipv6-literal.net」を使ったIPv6アドレスのリテラル表記

　アプリケーションによっては、IPv6アドレスを直接指定できない場合がある。例えばファイル・サーバを名前ではなくIPv6アドレスで直接指定して開こうとしても、IPv6アドレスには「:」記号が含まれているため、UNC中に含めることができない。このような場合は、IPv6アドレスをFQDN形式で表現できるようにする、「IPv6アドレスのリテラル表記」を使うとよい（Windowsにおける拡張機能）。具体的には、IPv6で表記したアドレス中の「:」を「-」に置き換え、さらに最後に「.ipv6-literal.net」を追加する。アプリケーションなどでこの名前を使うと自動的にIPv6アドレスに置き換えられる。

例：
「ping 2001:db8:beef:1:11:22:33:44」をリテラル表記にすると→
「ping 2001-db8-beef-1-11-22:33:44.ipv6-literal.net」

「ping fe80::a82a:a762:63eb:594e」をリテラル表記にすると→
「ping fe80--a82a-a762-63eb-594e.ipv6-literal.net」

　今回は、LLMNRを使った名前解決の方法について見てきた。DNSサーバを持たない非常に小規模なWindowsネットワークでは、このような手間のかからない名前解決方法（ゼロ・コンフィギュレーションなどとも呼ばれる）も求められている。従来のNetBIOS／NBTを拡張するのではなく、DNSをベースにしたLLMNRは、これからもWindowsネットワークでは広く使われることになるだろう（Windows以外のOSでも、やはりDNSをベースにした同様のゼロ・コンフィギュレーション・プロトコルがいくつか開発され、普及している）。

　次回は、IPv6のDNSとWindows Server OSにおけるDNSサーバの設定などについて取り上げる。

« 前の回へ

次の回へ »

「Windows管理者のためのIPv6入門」バックナンバー