Link-Local Multicast Name Resolution

By The Cable Guy

Link-local Multicast Name Resolution (LLMNR) とは、近隣のコンピュータの名前を解決するさらなる方法を提供する新しいプロトコルです。LLMNR はドメイン ネーム システム (DNS) サーバーを持たないネットワークに特に有益です。LLMNR はリクエストおよび応答メッセージの単純な交換を使用し、インターネット プロトコル バージョン 6 (IPv6) または IP バージョン 4 (IPv4) アドレスに対し、コンピュータ名を解決します。このコラムでは Microsoft® Windows Vista™ および Windows Server® コード名 "Longhorn" (現在ベータ テスト中) の LLMNR の実装について説明します。

注 :

このコラムでは IPv4、IPv6、DNS プロトコルの操作と DNS クライアントおよびサーバーの動作を知っていることが前提とされています。

トピック

はじめに
LLMNR メッセージの構造
ホストのスタートアップおよび名前解決のプロセス
詳細情報

はじめに

LLMNR とは "Link-local Multicast Name Resolution (LLMNR)" (draft-ietf-dnsext-mdns-47.txt) という表題でインターネット ドラフトに定義されているプロトコルで、これにより、IPv6 と IPv4 ホストの両方が、DNS サーバーまたは DNS クライアントの構成を必要とせずに近隣のコンピュータの名前解決を実行することができます。

IPv4 ホストは NetBIOS over TCP/IP (NetBT) を使用して、名前クエリ要求メッセージをローカル サブネットのブロードキャスト アドレスにブロードキャストすることにより、近隣のホストについて IPv4 アドレスに対しコンピュータ名を解決することができます。クエリされた名前を持つノードはユニキャスト NetBIOS 名前クエリ応答メッセージをリクエスタに送りかえし、名前が解決されます。しかし、NetBT は IPv4 でのみ動作し、IPv6 では動作しません。さらに IT 管理者は DNS が名前解決専用に使用されている環境で NetBT を無効にすることができます。DNS サーバーのないネットワークで NetBT が無効にされている場合、名前を解決するためにホスト ファイルにエントリを追加する必要があります。

LLMNR は DNS サーバーが存在しない、または実用的でないネットワークでの名前解決を可能にします。例として、アドホックな IEEE 802.11 ワイヤレス ネットワークを形成するコンピュータのグループにより形成される一時的なサブネットがあります。LLMNR で、アドホックなワイヤレス ネットワークのホストは、コンピュータの中の 1 台を DNS サーバーとして構成し、そのコンピュータの IP アドレスを持つそのほかのコンピュータを DNS サーバーとして機能させる必要なしで、互いのコンピュータ名を解決することができます。

LLMNR メッセージは Request for Comments (RFC) 1035 に定義されている DNS メッセージに類似した形式を使用し、DNS メッセージとは異なるポートを使用します。Windows Vista の LLMNR 名前クエリ要求メッセージは UDP ポート 5355 に送信されます。LLMNR 名前クエリ応答メッセージは UDP ポート 5355 から送られます。LLMNR リゾルバのキャッシュは DNS リゾルバのキャッシュから分離されます。

注 :

また、LLMNR インターネット ドラフトは LLMNR メッセージがどのように TCP で送受信されるかについても説明しています。しかし、TCP ベースの LLMNR メッセージは Windows Vista でサポートされません。

IPv6 で送信された LLMNR メッセージについて、クエリを行っているホスト (リクエスタ) は LLMNR 名前クエリ要求メッセージを FF02::1:3 のリンクローカル スコープ IPv6 マルチキャスト アドレスに送信します。IPv4 で送信された LLMNR メッセージについて、クエリを行っているホストは LLMNR 名前クエリ要求メッセージを 224.0.0.252 の IPv4 マルチキャスト アドレスに送信します。両方の場合で、マルチキャスト アドレスがスコープされ、マルチキャスト対応のルータがクエリ メッセージを最初に送信されたサブネットを越えて転送することを防ぎます。

注 :

LLMNR インターネット ドラフトは、リクエストを行っているホストについて “sender” という用語を使用しています。

すべての IPv6 ベースの LLMNR ホストは IPv6 マルチキャスト アドレス FF02::1:3 でリッスンし、それらのイーサネット ネットワーク アダプタが宛先マルチキャスト アドレス 33-33-00-01-00-03 を持つイーサネット フレームをリッスンするよう指示します。すべての IPv4 ベースの LLMNR ホストは IPv4 マルチキャスト アドレス 224.0.0.252 をリッスンし、そのイーサネット ネットワーク アダプタに宛先マルチキャスト アドレス 01-00-5E-00-00-FC を持つイーサネット フレームをリッスンするよう指示します。

名前クエリについての通常の LLMNR メッセージの交換はマルチキャスト クエリおよび、サブネットのホストがリクエストされた名前について権限がある場合、リクエスタに対するユニキャスト応答で構成されます。Windows Vista ベースの LLMNR ホストはユニキャスト クエリの送信、またユニキャスト クエリへの応答のどちらも行いません。

DNS サーバーとは対照的に、LLMNR ホストは割り当てられた名前で始まる DNS 名前空間の部分に対してではなく、割り当てられた特定の名前についての権限を持ちます。DNS の用語を使用し、LLMNR ホストはその割り当てられた名前に対応するゾーン アペックスにのみ権限があります。(ゾーンという用語はここでは大ざっぱに使用されています。この理由は、LLMNR ホストはゾーンを保存する DNS サーバーではないためです。) たとえば、名前 office.example.com を割り当てられた LLMNR ノードもまた office.example.com で始まるすべての名前に権限を持つわけではありません。

LLMNR メッセージの構造

以前に説明したように、LLMNR は DNS メッセージと類似した形式を使用します。図 1 で LLMNR メッセージの形式を示します。

DNS メッセージと同様、LLMNR は 12 バイトのヘッダーおよびゼロまたはそれ以上の質問レコードを含むセクションのシリーズ、回答レコード、権限レコードおよび追加レコードを使用します。図 2 で LLMNR ヘッダーの構造を示します。

DNS メッセージと同様、LLMNR は 2 バイトのトランザクション ID フィールドを使用してクエリをその応答、フラグおよびインジケータの 2 バイトのフィールド (このコラムの後半で説明します) と一致させ、質問レコード、回答レコード、権限レコードの件数を示す 2 バイトのフィールドのシリーズは LLMNR ヘッダーを通ったメッセージに含まれます。

最大サイズの LLMNR メッセージは 65,527 バイトの長さ (IPv6 の UDP メッセージの最大サイズに対応しています) または 65,507 バイトの長さ (IPV4 の UDP メッセージの最大サイズに対応しています) です。リンクの最大転送ユニット (MTU) を超える LLMNR メッセージは送信ホストにより断片化されます。

図 3 は LLMNR ヘッダーのフラグおよびインジケータの 2 バイトのフィールドの構造を示しています。

これらの 2 バイト内で、次のフィールドおよびフラグが LLMNR に定義されています。

• QR フラグ : DNS と同様、クエリ/応答 (QR) フラグはメッセージがクエリ (QR=0) または応答 (QR=1) かを示します。

• Opcode フィールド : DNS と同様、4 ビットの操作コード (Opcode) フィールドはクエリの種類を示します。LLMNR について、Opcode はクエリと応答の両方に 0 で設定されます。

• C フラグ : Conflict (C) フラグは名前の競合を示します。名前がサブネットで一意的であると考えられる場合、応答側は C フラグを 0 に設定します。リクエスタが以前にクエリされている名前の複数の応答を受け取っている場合、C フラグを 1 に設定します。応答側は応答を C フラグが 1 に設定されているクエリに送信しませんが、名前が一意的であると以前に確認した、可能性のある応答側は、権限を持っている名前が一意的であるかを確認する必要があります。

• TC フラグ : DNS と同様、Truncation (TC) フラグは、メッセージがリンクで許可された最大ペイロードのサイズより長いため、切り捨てられたことを示す応答で 1 のみに設定されます。リクエスタが TC フラグが 1 に設定されている応答を受け取ると、新しい TCP ベースのリクエスト メッセージを応答側のユニキャスト アドレスに送信することができます。LLMNR メッセージの最大サイズは大きいため、Windows Vista のLLMNR はクエリまたは応答に TC フラグを設定することはありません。

• T フラグ : Tentative (T) フラグは、応答側が名前に権限を持っている場合で、その名前が一意的であると確認していない場合、応答に 1 を設定します。

• RCODE フィールド : DNS と同様、4 ビットのリターン コード (RCODE) フィールドは応答が成功したことを示します。LLMNR について、RCODE フィールドはリクエスタおよび応答側により 0 に設定されます。DNS サーバーとは異なり、クエリされた名前に権限を持たない LLMNR の応答側は 3 に設定された RCODE を持つクエリに応答せず、その名前が見つからなかったことを示します。クエリされた名前に権限を持たない LLMNR 応答側は何の応答も送信しません。リクエスタは応答がないことを解釈し、RCODE が 3 に設定された名前クエリ応答を DNS サーバーから受け取る DNS クライアントと同じ方法でクエリを行います。

Windows Vista は IPv4 と IPv6 の両方について LLMNR をサポートします。IPv6 で送信される LLMNR クエリ メッセージは IPv6 ヘッダーの次のフィールドを使用します。

• 宛先アドレス フィールドは FF02::1:3 に設定されています。

• ソース アドレス フィールドは送信インターフェイスのリンク ローカルまたはそのほかのユニキャスト アドレスに設定されます。

• ホップ制限フィールドは 1 に設定されています。

IPv4 で送信された LLMNR クエリ メッセージは IPv4 ヘッダーで次のフィールドを使用します。

• 宛先アドレス フィールドは 224.0.0.252 に設定されています。

• ソース アドレス フィールドは送信インターフェイスのユニキャスト IPv4 アドレスに設定されています。

• Time-to-Live (TTL) フィールドは 1 に設定されています。

LLMNR クエリについて、Windows Vista ベースのリクエスタは宛先ポート フィールドを 5355 に、また、ソース ポート フィールドを動的に割り当てられたポート番号に設定します。LLMNR の応答について、Windows Vista ベースの応答側は宛先ポート フィールドを一致するクエリの動的に割り当てられたポートに、また、ソース ポート フィールドを 5355 に設定します。

ホストのスタートアップおよび名前解決のプロセス

Windows Vista を実行しているホストが起動すると、LLMNR 名前クエリ要求メッセージをその権限を持っている名前に送信することにより、名前が一意的なものであることを確認します。この名前は単一ラベルの名前としてのコンピュータ名です。

たとえば、クライアント 1 と名づけられ、wcoast.example.com のプライマリ DNS サフィックスを持つコンピュータがクライアント 1 という名前の LLMNR には権限を持ちますが、client1.wcoast.example.com には権限を持ちません。0 に設定されている C フラグを持つそれ自体の名前について最初のリクエストへの応答がある場合、名前の競合が発生します。LLMNR ホストはその競合に気付き、その名前についての LLMNR リクエストに応答しません。しかし、競合を検出したホストは 15 分ごとにその名前への新しいクエリを送信し、競合している名前を持つコンピュータがもうリンクにないかどうかを確認します。それ自体の名前についての続きのクエリへの応答がない場合、ホストはクエリへの応答を開始します。

hostname.local の形式の名前をクエリすることに慣れているユーザーに対する利便性として、Windows Vista は hostname.local という名前を hostname に変換し、LLMNR を使用して単一ラベルの名前を解決しようとします。Windows Vista ベースのコンピュータは computername.local という名前には権限を持ちません。

単一ラベルで、分類されていない名前が解決される必要がある場合、IPv6 と IPv4 の両方を使用している (既定の構成) Windows Vista を実行しているコンピュータは次を行います。

1. 単一ラベル名をコンピュータのプライマリ DNS サフィックスと組み合わせ、DNS 名前クエリ要求メッセージをその DNS サーバーに送信することにより、通常の DNS 解決を実行します。Windows Vista は必要に応じて、名前デボルブまたは構成された追加の検索サフィックスに基づき追加の DNS クエリを実行します。

2. DNS 名前解決が成功しなかった場合 (たとえば、DNS サーバーが RCODE=3 を返す場合)、IPv6 と IPv4 の両方で、マルチキャスト LLMNR 名前クエリ要請メッセージの 2 つまでのセットを送信してください。

3. LLMNR 名前解決が成功せず、また NetBT が有効である場合、3 つまでの NetBIOS 名前クエリ要請メッセージをブロードキャストしてください。

解決されている名前が単一ラベル名 (または hostname.local 名) である場合、LLMNR および NetBT は使用されません。ホストが DNS サーバーを使用するように構成されているかどうかに関わらず、LLMNR は使用されることに注意してください。これにより Windows Vista を実行しているコンピュータが DNS に保存されている対応するアドレス レコードを持たない近隣の LLMNR ホストのコンピュータ名を解決することができます。

LLMNR 名前クエリ要請メッセージを受け取る近隣の LLMNR ホストは、それらがメッセージの質問のセクションにおける名前について権限があるかどうかをチェックします。権限がある場合、LLMNR ホストは元の質問のセクションおよび応答側に到達するために使用できる 1 つまたは複数の IP アドレスを含む回答のセクションを含む LLMNR 名前クエリ応答メッセージを作成し、送信します。応答側はリクエスタに到達可能なこれらのアドレスのみを含む必要があります。たとえば、アドレスはクエリを受け取ったインターフェイスに割り当てられる必要があります。

詳細情報

Windows Vista の TCP/IP 拡張機能に関する詳細は次のリソースをご覧ください。

• Next Generation TCP/IP Stack の Web サイト (英語情報)

• Microsoft IPv6 の Web サイト (英語情報)

• Windows Vista Networking の Web ページ (英語情報)

The Cable Guy の全コラムの一覧と概要をご覧になるには、ここをクリックしてください。