要約

  • RFC 9928 は、RFC 7341 を実装できない IPv4-only 端末に代わり、4o6RA が DHCPv4-over-DHCPv6 のカプセル化と復元を行う方式を定める。
  • 代理化で観測点も移る。正しい応答を運べたことは、Layer 2 の入口情報、トポロジーに基づく割当、端末の設定受容、到達性まで証明しない。

移行判定で見落としやすいのは、失敗したパケットではなく、成功した記録から消えた文脈である。DHCPv4 要求が入り、DHCPV4-QUERY が出て、応答が戻り、内側の DHCPv4 メッセージが端末へ渡った。ところが、その要求がどのアクセスポートから来たかを示す記録がない。サーバーは答えたが、期待した場所に対して答えたかは分からない。

RFC 7341 は、IPv6 ネットワークを越えて IPv4 のアドレスや設定を取得する DHCP 4o6 を定義した。そこでは端末自身が DHCPv4 を DHCPv6 に包む。RFC 9928 が扱うのは、その変更を受け入れられない組み込み端末や長寿命機器である。中間のスイッチまたはルーターに 4o6RA を置き、端末の代わりに包み替える。

端末側から見れば通常の DHCPv4 である。一方、RFC 7341 の関係では 4o6RA がクライアントになる。DHCPv6 クライアントとして使うインターフェースを決め、適切なサーバーまたはリレーを探し、IPv6 設定を得て、DHCP 4o6 Server Address option を要求する。その後、端末の要求から DHCPV4-QUERY を作る。

戻り側の規則も限定的で明確だ。DHCPv4 message option がない、または形式が不正な DHCPV4-RESPONSE は捨てる。内側の応答が正しく、実際に転送できる場合にだけ取り出して端末へ送る。RFC 9928 は新しいメッセージ形式を作らず、既存の 4o6 サーバーにも追加要件を課さない。共通部分を小さく保つ設計である。

問題は、DHCP の選択が接続場所に依存し得ることだ。RFC 7969 では、IPv4 の giaddr は通常、最初のリレーが設定するため、複数段の一部しか表さない。DHCPv6 では各リレーの link-address と Interface-ID によって、クライアントからサーバーまでの経路情報を積み上げられる。

端末が自分で DHCP 4o6 を行えば、DHCPv6 リレーはカプセル化メッセージを受けたインターフェースを知る。処理を中間の 4o6RA に移すと、DHCPv6 側に見えるクライアントはその 4o6RA になり、その背後の Layer 2 網が消える。RFC 9928 は、4o6RA 単体では隠れたインターフェース情報をメッセージに載せられず、トポロジー伝播が壊れると明記している。

対策として RFC 6221 の LDRA を 4o6RA と一体に置き、Interface-ID を出力側に供給する構成を推奨する。ただし、両機能の間でインターフェース情報を渡す内部方式、その形式、4o6RA の関与を示すかどうかは規定外である。標準が保証するのは相互運用の境界までであり、内部データの由来は運用者が証明する。

Heng Lu の Minimum Initial Specification は、この分担を弱点ではなく設計原則として読む。共有層には、互いに検証できる最小の規則だけを置く。後の実装判断は、実際に採用し結果を負う現場に残す。だからこそ現場は「RFC 対応」という一語ではなく、ポートから Interface-ID までの対応を自分の証拠として持たなければならない。

経路の強制も同じくローカルな責任である。端末は 4o6RA の存在を知らないため、DHCPv4 の broadcast と unicast をすべて 4o6RA に通す必要がある。中央配置や NAT が手段になる。同じ Layer 2 に直接到達できる DHCPv4 サーバーが残れば、要求は迂回し、端末とサーバーに食い違う状態が生じ、到達性へ影響する設定ミスになり得る。RFC はこれを新しいセキュリティ問題ではなく配備誤りとするが、復旧責任が消えるわけではない。

証拠は一つの「成功」ではなく、引き継ぎごとに残す。端末の transaction ID と要求 hash、入口ポートや VLAN、4o6RA の DHCPv6 インターフェース選択、サーバー発見、query/response hash、リレー順序、link-address と Interface-ID、サーバーが参照したポリシー入力、返した設定、形式検査と転送判断、端末が保持した lease/options、競合確認、独立した経路・サービス観測である。

担当も分ける。アクセス担当は端末が現れた場所を、中継担当は変換内容を、DHCP 担当は選択規則を、端末担当は取り込んだ状態を、サービス担当は結果を説明する。これは会議のための分業ではない。どの層を戻せばよいかを、障害時に判断するための分離である。

Running-Code Primacy が求めるのは、動いたプログラムの範囲を正確に認めることだ。リレーの成功はリレー処理の証拠であり、サーバー応答は与えられた入力に対する判断であり、端末の bound state はローカル状態であり、probe は時点付き観測である。一つの緑色表示に全てを代表させる必要はない。

情報源