IPv6のDNSディスカバリーを説明してみます
IPv6のDNSディスカバリーに関して、全体がよく見えないというご意見があり、少し簡単にですがまとめてみました。（こうなると、ブログではなくて“記事”かもしれませんね……）。^^; 意外と、このあたりを綺麗にまとめたものって少ないような気がします。もし、間違いなどありましたらコメントください。/(^^;
まずは、基礎知識の確認から。アドレスなどの自動設定を行うには「ステートレス（Stateless）」と「ステートフル（Stateful）」という大きく二つのモードがあります。ステートレスの代表が「RA（Router Advertisement）」で、ルータが設定に必要な情報を各装置に広告する方式です。ステートフルの代表が「DHCP（Dynamic Host Configuration Protocol）」で、DHCPサーバがアドレスなどの情報を要求に応じて提供します。
ステートレス、ステートフルの長所、短所はある意味で相反します。管理されたネットワークを欲する場合には、軽いけれどもアドレスの割り当てを制御できないステートレス方式は不向きで、特定のクライアントのみにアドレスを割り当てたり、どのクライアントに何の情報を割り当てたかをサーバ側で管理できるステートフル方式は重いけれど好ましいという評価が行われることが多いという事例などからも、その辺りが読み取れますよね。
最後でまとめようと思いますが、これらの方式に対して判断を下す場合には、良い悪いではなく、合うか合わないかが大事になります。では、前回のコメントで書いた
- Router Advertisement（RA）
- DHCPv6 option
- Well-known Anycast Addresses
という3種類の提案（RFC4339）について個々の長所と短所をご説明していきましょう。ただし、「どれがいい」ということまでは言及しません。詳細は、
をご覧になっていただくのが一番いいと思います。それでは、まずはRA の場合から。
▼ RA（Router Advertisement）方式
この方式は、ルータが行う広告（Router Advertisement）にオプションを増設し、ルータとプリフィックス（たとえば、ISPが持っているIPv6アドレス）の通知と同時にDNSサーバの通知を行うというものです。
長所としては、既存のRAの上に構築でき、RAが動作するリンク内であれば通知が可能になること。そして、オーバーヘッドが小さいことです。
短所としては、RAを受け取る側が対応する必要があること。そして、RAを送信するルータがリンク内に存在することが前提となることでしょうか。
▼ DHCPv6 option 方式
この方式は、IPv6においてもDHCPを使用してDNSサーバの情報を提供しようというものです。
長所としては、まず第一に、DHCPv6とそのDNS通知オプションについてはすでに標準化済なため、相互接続可能な実装が数多く存在することでしょう。また、DHCPについての知識は現状でも十分に行き渡っていると考えられることです。
短所としては、他の方式に比べてオーバーヘッドが大きいことです。
少し余談になりますが、ここで“DHCPv6-lite”というものを少し簡単にご紹介しておいたほうがいいかもしれません（比較的よく出てくるキーワードです）。DHCPv6-liteとは、一言で言ってしまうと「サーバ情報の取得（提供）のために軽量化したDHCPv6」のことですが、ここでひとつだけ注意しなければいけない点があります。それは、「サーバがクライアントの状態を管理しない」という部分にあります。
DHCPv6-liteは、IPv6においてDNS情報をどのように取得するかという議論の中で、軽いDHCPv6が必要とされたという背景で生まれてきました。ここでは、主としてノードに設定情報（DNS、SIP、NTPなど）を渡すことを想定しており、INFORMATION-REQUESTとREPLAYメッセージだけで情報の授受を行う形が基本となっています（つまり、問い合わせに対する応答しかない）。通常のDHCPと異なり、ステートフルな管理を行うものではない点には注意をしてください。
他にも、ホストやルータにプリフィックスを払い出すオプションの“DHCPv6-PD（prefix delegation）”という言葉を知っておくといいかもしれませんね。
▼ Well-known Anycast Addresses 方式
この方式は、規定の（well-known）アドレスをDNSサーバとするものです。
長所としては、あらかじめ機器にDNSのアドレスを埋め込めることや、DNS情報取得のためのオーバヘッドがほとんど無いことにあります。
短所としては、「あらかじめDNSサーバを決めておく」ためには“そこ”に確実にDNSサーバがあること、そして、そのDNSサーバへの到達性を確保（ルーティング）しておく必要があることです。
ちなみに、Well-knownサイトローカルアドレスによるDNSとの通信を確立する方式については、サイトローカルアドレス自体が廃止されたため、この方式についても廃止されています。一部の実装にその名残が見受けられるようですが、使えませんので注意してください。
このように、各方式には一長一短があり、単純に、どれが優れてどれが劣っているというものではありません。現状でよく使われているのは、RAの“Managed-Flag＝1”で、端末がDHCPv6による設定を実行するという形のようですが、管理者の皆様には、ご自身が管理するゾーンがどのような要求を抱えているかをよく分析してどれを選ぶか決めていただくのが良いと思います。