要約

  • DHCPv6 Reconfigureは新しい設定を運ぶ命令ではない。あらかじめ受け入れを表明したクライアントに、Renew、Rebind、Information-requestのいずれかを始めさせる認証付きトリガーである。
  • RFC 6977では、サーバーが対象の全クライアントへReconfigureを送らない場合でも、Reconfigure-Replyに Success を返せる。要求処理、選択、送信、認証、後続取引、状態適用、サービス継続には、それぞれ別の証拠が要る。

緑になったのは最初の境界だけだった

アクセス網のリレーが、あるリンクに関するプロビジョニング情報の変更を検知したとする。リレーはリンクアドレスと複数のDUIDをReconfigure-Requestに入れてサーバーへ送る。サーバーは Success を含むReconfigure-Replyを返し、運用画面は処理完了を表示する。

その時点では、端末の状態は一つも変わっていないかもしれない。

サーバーの記録が不足しているクライアント、Reconfigure Acceptを送ったことのないクライアントは除外される。送信対象でもレート制限の待ち行列に残り得る。届いたメッセージが認証で拒まれることも、Renewを開始したままReplyを受け取っていないこともある。DHCPクライアントが新しい状態を入れても、アプリケーションが古いアドレスを保持する場合さえある。

画面が「サーバーはリレー要求を処理した」と表示するなら正確だ。問題は、その確認を「全クライアントの変更が完了した」という権限の大きな主張へ変えることである。

RFC 6977の応答リストには、サーバーがReconfigureを送らないクライアントが記載される。要求された全員がそのリストに入っていても、結果コードは Success でよい。リレーとサーバーの受付確認は、クライアントの実行証明ではないという明示的な境界だ。

現行仕様は設定ではなく次の会話を選ぶ

RFC 9915は現在のDHCPv6基礎仕様であり、RFC 8415を置き換えた。IANAのDHCPv6レジストリではRECONFIGUREがメッセージ種別10として登録されている。共通機構の仕事は、特定のクライアントに次のDHCPv6交換を求めることに限られる。

Reconfigureはユニキャストで送られ、Server Identifier、対応するClient Identifier、受理可能な認証情報、Reconfigure Messageオプションを含む。このオプションが指定できるのはRenew、Rebind、Information-requestだけである。新しいアドレスや通常の設定オプションをトリガーへ直接入れてはならない。それらは後続交換のReplyで決まる。

サーバーが持つのは、次の会話を始めるよう促す権限である。クライアントは識別子、認証、リプレイ値を検証し、自分で要求を組み立てる。サーバーはその時点の状態からReplyを生成する。クライアント実装が適用を行い、運用者が実際の動作を観測する。

したがって、有効なReconfigureを捕捉しても新設定の証明にはならない。それはある権限からある識別子へトリガーが送られた証拠でしかない。識別子が現在の端末と一致するか、後続交換が完了したか、アプリケーションが移行したかは別問題である。

参加しない選択も相互運用の一部

クライアントはReconfigure Acceptで受信意思を示す。このオプションを送らない端末へ、サーバーはReconfigureを前提とした制御を行えない。しかし、その端末はDHCPv6として不正なのではない。通常の有効期間、クライアント主導のRenew、通常のInformation-requestで状態を更新できる。

この設計は任意機能が事実上の義務になるのを防ぐ。同時に、事業者には導入率を測る責任が生じる。対応率が70％なら、迅速化できるのは70％である。残り30％が安全に追随できる時間と経路を残さなければならない。

RFC 8947が扱う小規模機器では、認証処理や永続状態のコストが実装範囲を制限し得る。運用者が迅速な更新を望むことと、すべての端末がその機能を実装する義務があることは同じではない。

認証が確定するのは送信権限の範囲

Reconfigure Key Authentication Protocolは、最初のReplyで128ビット鍵を渡し、後のReconfigureをHMAC-MD5で検証する。初回の鍵はDHCPv6経路上で平文配送されるため、その時点の経路保護は脅威モデルから消せない。

リプレイ検出値は単調に増加し、サーバー再起動後も継続しなければならない。フェイルオーバー先がリースを復元しても、鍵やリプレイ状態を失えば、対象を知っていても受理されるトリガーを作れない。秘密を複製すれば可用性は上がるが、侵害範囲も広がる。

認証が答えるのは、このメッセージが共有鍵を持つサーバー権限から来ており、過去のメッセージの再送ではないか、という問いである。リレーが正しい集団を選んだか、サーバーの状態が正しいか、後続Replyが適切か、アプリケーションが動くかは証明しない。

「認証済み」を「端から端まで正しい」と読み替えると、暗号が明確にした境界を運用が再び曖昧にしてしまう。

リレーは候補を出し、サーバーが決定する

RFC 6977はリレーとサーバーの間にReconfigure-RequestとReconfigure-Replyを加える。リレーは変更の影響を受けたと考えるリンクアドレスとクライアント識別子を提示できる。サーバーは、リレーを認めるか、リンク情報を信頼するか、十分な状態があるか、誰を選ぶか、どの速度で処理するかを決める。

既定は拒否であり、未知のリレーからの要求は破棄される。RFC 8213のIPsecはリレー—サーバー間を保護できるが、保護されたチャネルは対象集団の妥当性まで保証しない。侵害されたリレーが、誤った加入者を正しく認証された経路で提示することは可能である。

再送時、リレーはクライアントを削除できるが追加できない。この非対称性は進行中の要求が密かに拡大するのを防ぐ一方、リンク、DUID、binding、リレー権限の照合を不要にはしない。

複数サーバーが同じ要求を受ける環境では、保持する状態や方針によって選択が分かれる。複数の Success を足しても一つの最終事実にはならない。各トリガーを送信サーバー、対象クライアント、後続トランザクションへ結び付ける必要がある。

成功を六つの事実へ分解する

実務の台帳には少なくとも次の段階が必要だ。

  1. リレーがどの元データの変更を観測し、どのクライアントを候補にしたか。
  2. どのサーバーが要求を受理または拒否したか。
  3. どのクライアントを選択し、実際に何通送ったか。
  4. どのクライアントが認証を受け入れ、指定された要求を送ったか。
  5. どのDHCPv6交換がReplyまで完了したか。
  6. どの状態が適用され、どのアプリケーション経路が確認されたか。

証拠はリレーログ、Reconfigure-Reply、選択記録、送信カウンター、認証結果、トランザクションID、端末状態、サービス試験に分かれる。隣り合う段階の差は、消すべき雑音ではなく故障の所在である。

全DUIDを除外した Success は、要求処理の成功と到達範囲ゼロを同時に示す。Renewは来たがReplyがないなら、トリガー成功と交換失敗である。端末の適用後もアプリが旧アドレスを使うなら、DHCP成功とサービス移行失敗が並立する。一つの完了フラグでは、これらを正しく表現できない。

レート制限は結果の意味を変える

一つの変更イベントが多数の個別Reconfigureと後続交換へ扇状に広がる。RFC 6977がサーバーのレート制御を求めるのは、通常の割り当てや更新を保護するためである。

要求を今受理したことと、全トリガーを今送ったことは違う。観測すべき時間は、元データの変更から選択、待ち行列、送信、要求、Reply、適用まで続く。Reconfigure-Replyの応答時間だけでは最初の区間しか測れない。

方針には元イベントごと、要求ごと、サーバー時間帯ごと、変更窓ごとの上限と、再試行の停止条件が要る。無制限再送は不在クライアントを恒常的な負荷に変え、通常DHCP処理まで損なう。

安全な旧設定の併存期間より待ち行列が長ければ、仕様に沿った遅延が停止人口を作る。容量計画と切り戻し時間は、同じエンドツーエンド予算として設計しなければならない。

復元した状態は現在地ではない

RFC 5007、RFC 5460、RFC 7653のLeasequery、Bulk Leasequery、Active Leasequeryは、サーバー状態の復元や継続同期を助ける。フェイルオーバー時の情報不足を減らすが、以前観測したbindingを現在接続中の端末へ変えるわけではない。

記録中のクライアントはリンクを離れているかもしれない。更新ストリームは遅延、順序入れ替え、再同期を伴う。リースが復元されてもReconfigure鍵やリプレイ値は欠けることがある。由来、鮮度、完全性を記録し、広範囲なトリガーの前に稼働中の証拠で確かめるべきだ。

RFC 9243のYANGデータモデルはDHCPv6サービス設定を見やすくする。これは制御面の意図を説明するもので、端末の実効状態を観測したものではない。モデルが整っていることと、クライアントが変わったことは別である。

リナンバリングは誤認の被害を拡大する

RFC 6879が扱うIPv6企業網のリナンバリングでは、Reconfigureにより一部クライアントを早くサーバーへ戻せる。だが、新旧プレフィックスの併存、非参加端末、古いアドレスを保持するアプリケーションは残る。

可逆な移行は、旧状態を明示した期間維持し、除外・遅延・未移行を計測し、独立した観測後に段階的に撤去する。リレー—サーバーの Success だけで併存期間を短縮すれば、通常の待ち時間や任意不参加が障害になる。

Reconfigureは移行を早める選択肢であって、即時切替を正当化する証明ではない。

共通層を小さく保つ理由

共通仕様が決めるべきなのは、形式、識別子、参加表示、認証、リプレイ処理、三つの後続交換である。商用上の変更理由、リレーごとの信頼、サーバー負荷、アプリケーションの危険度、旧状態の撤去時期までは知り得ない。

リレーは現場イベントを検知して候補を出す。サーバーは信頼、状態、選択、予算を決める。クライアントは自分の実装で適用する。運用者は変更窓、保護策、証拠、切り戻しを選ぶ。相互運用の核を小さくすれば、将来の判断を稼働主体に残せる。

Heng Luの原則では、標準文書や確認記録ではなくrunning codeが最初の根拠になる。記録は現実を説明できるが、それ自体で現実を作らない。実装、検証、配備、利用を通じて初めて変更が実在する。

Minimum Initial Specificationは最小の共通トリガーを作り、Localized Future Decisionは信頼と運用を各現場に残し、Voluntary AdoptionはReconfigure Acceptを出さない選択にも表れている。仕様は会話を始める。動いている参加者が、会話の結果を現実にする。

出典