要約

  • Reconfigure はクライアントに Renew、Rebind、Information-request のいずれかを開始させる認証済みのトリガーであり、送信だけでは新しい設定を証明しない。
  • サーバーが指定した後続要求を受け取れば Reconfigure 要求は満たされるが、Reply、ローカル適用、通信やサービスの結果は依然として別の事実である。

運用画面は因果関係を一つの状態に圧縮しがちである。「Reconfigure sent」が「client configured」になる瞬間、RFC が残した検証点が消える。RFC 9915 における Reconfigure は、サーバーがクライアントへ後続の交換を促すメッセージである。設定内容そのものでも、その内容をクライアントが使い始めた証拠でもない。

最初に確認すべきなのは、受け入れる意思とメッセージの妥当性である。Reconfigure Accept は、クライアントが Reconfigure を受け入れる意思をサーバーへ知らせる。これがなければ既定では受け入れない。さらに、ユニキャストでない、必要な server/client identifier がない、Reconfigure Message option がない、要求種別が不正、または認証がないか失敗した Reconfigure は、クライアントが破棄しなければならない。従って送信記録は、サーバーが要求を出したという記録にすぎない。

有効な Reconfigure をクライアントが受けたとしても、次の事実は限定される。option が Renew、Rebind、Information-request のどれを送るかを指定し、クライアントはその交換を開始する。処理中は追加の Reconfigure を捨てる。RFC がこの最初のメッセージを trigger と呼ぶのは重要である。これは別の取引を始動するものだからであり、アドレス、プレフィックス、DNS 情報などを単独で適用するものではない。

その後、サーバーには狭いが有用な受領記録ができる。RFC 9915 は、指定した Renew、Rebind、Information-request を受け取れば、サーバーは Reconfigure 要求が満たされたと解釈すると述べる。言えるのは「サーバーが要求した種類のクライアントメッセージを受け取った」までである。Reply が届いた、option が受諾された、OS が設定をインストールした、とは言えない。

後続交換の性格も一つではない。Renew と Rebind にはそれぞれの binding とサーバー選択の規則があり、Information-request はアドレスやプレフィックスを求めず設定情報を求める。各交換で設定情報を運ぶのは Reply である。特定の変更を主張するには Reply と関係する option/IA の記録が要る。ルート選択、DNS 利用、パケット到達、アプリケーション完了を主張するなら、それぞれの観測点がさらに必要になる。

Reconfigure の認証は最初の境界を守るが、その先を一つの成功にしない。RFC 9915 は DoS リスクのため DHCP 認証を求める。Volz も共同執筆者である RFC 9096 は DHCPv6 の安全性とプライバシーの改善を扱う。これらは特定の制御メッセージの検証条件であり、可用性やエンドツーエンドの業務結果の保証ではない。

記録には、client DUID、server identifier、Reconfigure の送信と検証、要求された msg-type、サーバーが受け取った対応要求、Reply と関係値を残すべきである。運用結果を問うなら、ローカル適用や実行時の観測を別に結びつける。IANA の registry は DHCPv6 のコードを識別できても、後続段階が起きたことを証明しない。

これは Heng Lu の最小の仕様と実行されたコードを重視する姿勢に沿う。「送った」「要求を受けた」を、まだ観測していない「設定された」に置き換えない。Volz の著者名も同様に限定する。彼は集団標準の共同著者であり、実在のクライアント、サーバー、ネットワークを支配する人物としてこの資料に現れるわけではない。

出典