要約

  • RFC 3736では、IPv6アドレスをすでに持つノードが、DHCPv6のInformation-requestとReplyで追加情報を求められる。サーバーにアドレスを割り当ててもらう交換ではない。
  • 「ステートレス」とは、この情報サービスのためにサーバーがクライアントごとの動的状態を保持する必要がないという意味だ。任意のクライアント識別子、サーバーのローカルポリシー、中継処理は残る。

アドレスとリゾルバーは別の仕事

IPv6のステートレスアドレス自動設定は、ルーター広告をもとにホストのアドレスを形成できる。しかし、それで設定がすべて済むわけではない。再帰DNSサーバーのアドレス、SIPサーバーの情報、ほかのオプションが必要な場合もある。DHCPをひとまとまりの機能、つまり「サーバーにアドレスを求め、同時に残りのネットワーク設定も受け取るもの」と考えたくなる。

RFC 3736は、その機能を切り分けた。クライアントは別の方法――通常はステートレスアドレス自動設定、または手動設定――ですでにアドレスを持ち、通信に使えるリンクローカルアドレスも少なくとも一つ持つ。Information-requestには、欲しいオプションの種類を示すOption Requestオプションを含める。サーバーは選んだ設定値をReplyで返す。このモードはアドレスのIdentity Associationを要求せず、アドレス割り当ても行わない。

交換は意図的に二つのメッセージに絞られている。Information-requestの後にReplyが届く。DNS設定を求めても、それがアドレスリースの交渉に変わるわけではない。同じサーバーシステムが、アドレスを求めるクライアントと、追加パラメーターだけを求めるクライアントの双方を扱うこともできる。リレーの動作はステートフルDHCPと変わらない。

ただし「ステートレス」は、サーバーに設定もポリシーもないという意味ではない。RFC 3736が述べるのは、このサービスにクライアント別の動的状態を維持する必要がないことだ。管理者が応答を個別化したければ、クライアントはClient Identifierを含めてもよい。サーバーは依然として設定ポリシーに基づきオプションを選べるし、リレーがメッセージを転送することもある。不要になるのは、この情報サービスのためにクライアントごとのアドレス束縛を作って追跡することだ。

この違いはIPv6 Router Advertisementのフラグを読む際にも役立つ。RFC 4861では、ManagedフラグはDHCPv6でアドレスを取得できること、OtherフラグはDNSなどの追加情報をDHCPv6から得られることを示す。Managedが設定されるとOtherは冗長になる。これらは可用性のシグナルであって、ホストがDHCP交換を完了したこと、リゾルバーを設定したこと、到達できることの証拠ではない。

アドレスリースを外すと、その時計もなくなる

割り当てられたアドレスには優先・有効期間があり、いつ使い続けられるか、いつ無効になるかを知らせる。その他の設定情報には同じような期限が付かない場合がある。RFC 3736は、ホストが値を更新するために次のInformation-requestをいつ送るべきかを明示的に未定のままにした。新しいリンクへ移動した場合の更新規則も示さなかった。

RFC 4242は後にInformation Refresh Timeオプションを追加し、DHCPv6情報を更新するまでの上限を示せるようにした。理由は重要だ。アドレスやプレフィックスのリースが交換に含まれないなら、更新の時期を知らせる有効期間もないことがある。RFC 8415はDHCPv6を後に統合し、RFC 3736とRFC 4242を廃止しながら、二メッセージの情報要求を引き継いだ。

この歴史は「SLAACでアドレスができればDHCPは不要」という話ではない。アドレス形成とホストのその他の設定は分けられる、という設計だ。情報サービスが必要とするクライアント別状態は減る一方、情報源の優先順位、更新、インターフェース範囲、ホスト内のリゾルバー設定というライフサイクルの仕事は残る。Replyはプロトコルがオプションを返した証拠であり、それがホストに設定されたことやDNS問い合わせの成功を単独で証明するものではない。

これらのRFCは、現在のクライアントがこのモードをどれほど使うか、特定のネットワークがどう設定しているかを示していない。規定しているのは仕組みと境界であり、導入率やサービス結果ではない。

出典