要約

  • RFC 9928では、4o6RAが旧来のIPv4クライアントに代わり、DHCPv4メッセージをDHCPv6へ封入し、応答を取り出す。クライアントはその処理を認識しない。
  • 4o6機能を中間ノードへ移すと、DHCPv6サーバーからレイヤー2の接続位置が見えなくなる場合がある。RFCは4o6RAとLDRAの背中合わせ構成を推奨する一方、両者の内部連携方式は規定しない。
  • 成功したリースが示すのは、割り当てと応答配送が成立したことまでである。入口ポート、Interface-IDのローカル対応、適用されたプール規則、直接DHCPv4経路の不在までは示さない。
  • 運用記録は、受信、封入、入れ子のリレー順序、サーバー判断、元ポートへの配送、バイパス検出、期限または訂正を個別に結ぶ必要がある。

リース表では同じ成功に見える

レイヤー2スイッチの先に、更新できないIPv4専用の無線装置が複数あるとする。各ポートは異なるアンテナや設備位置に対応し、接続位置によって与えるアドレスプールや設定が変わる。装置Aも装置BもDHCPACKを受け取り、疎通を始めた。リース表だけを見れば二つとも成功である。

だが、一方の要求から物理ポート情報が途中で失われていたなら、同じ緑色の表示は同じ根拠を意味しない。汎用プールから返されたアドレスでも、短い疎通試験には合格し得るからだ。

RFC 7341は、DHCPv4をDHCPv6で運ぶDHCP 4o6を定義した。そこでは対応クライアントが封入と解封入を担う。ソフトウェアを変更できないIPv4機器は、この前提を満たさない。

RFC 9928は処理をDHCPv4-over-DHCPv6 Relay Agentへ移す。4o6RAはDHCPv4要求を受け取り、DHCPV4-QUERYを作成して上流へ送り、正常なDHCPV4-RESPONSEからDHCPv4応答を取り出して元の機器へ渡す。

旧来クライアントは通常のDHCPv4しか見ない。RFCも、クライアントは4o6サービスの存在を認識しないと明記する。この透明性によって互換性が得られる。同時に、クライアントを中間経路の証人にすることはできなくなる。

トポロジーは割り当て規則の材料になる

RFC 7969が扱うのは、ネットワーク位置に応じたDHCP設定である。リレーは要求が入ってきた場所を知り、その情報をサーバーがアドレスプールやパラメーターの選択に使える。

DHCPv4では、通常は最初のリレーがgiaddrを設定するため、多段経路の一部しか伝わらない。DHCPv6ではRelay-forwardを入れ子にし、各層のlink-addressやInterface-IDによって経路を表せる。応答は逆順のRelay-replyとして戻る。

RFC 9928は、4o6処理をIPv6ネットワークの中間位置へ移すと、手前にあるレイヤー2区間が隠れると説明する。4o6RAだけでは、封入された要求にインターフェース情報が入らず、トポロジー伝搬が途切れる。

これは必ずパケットを壊すわけではない。サーバーは受け取った情報に従って有効な応答を作れる。ただし、位置依存ポリシーが必要とした入力が欠けている。リース成功率は、その欠落を測る指標ではない。

LDRAが運ぶ値は不透明である

RFC 9928は、4o6RAとLightweight DHCPv6 Relay Agentを背中合わせに実装することを推奨する。LDRAはクライアント側インターフェースを把握し、上流のDHCPV4-QUERYにInterface-IDを付加する。

RFC 6221では、LDRAのRelay-forwardにInterface-IDを必須とする。その値は同じインターフェースに対して安定しているべきであり、再起動後も維持することが望ましい。サーバーが完全一致で割り当て規則を適用できるようにするためだ。

ただし値はopaque、つまり中身を解釈しない不透明な識別子である。バイト列そのものが、ラック、スロット、ポート、利用者を世界共通の形式で名乗るわけではない。監査には、プロトコル上の値と、その時点で値を物理ポートへ結んだローカル表の両方が要る。

RFC 9915は、サーバーがRelay-forwardのInterface-IDをRelay-replyへコピーするよう求める。リレーはその値を使い、クライアント側インターフェースを選ぶ。したがって同じ値がサーバーの方針と帰路配送に関わるが、ローカル対応の正しさまで自動的に保証するものではない。

内部の受け渡しは標準化されていない

RFC 9928は、4o6RAからLDRAへインターフェース情報を渡す内部機構、その形式、4o6RA関与の表示を対象外とする。これは欠陥ではなく、実装に残された境界である。一つのプロセス内で完結する装置も、スイッチASICと制御ソフトをまたぐ装置も、同じ外部動作を実現できる。

そのため、準拠していることと内部の来歴が残ることは同義ではない。運用側は、どの部品が観測し、どのマッピング世代がInterface-IDを生成し、欠落や古い対応をどう検出したかを記録しなければならない。

一方、4o6RAとDHCP 4o6サーバーが同一ノードにある単純な構成では、LDRAを別に置かなくても十分な場合がある。二つの箱を必須と一般化してはいけない。必要なトポロジー情報がポリシーへ届き、その由来を説明できるかが判断基準となる。

バイパスも有効な応答を返し得る

クライアントが4o6RAを認識しない以上、ネットワークはDHCPv4のbroadcastとunicastをいずれも4o6RAへ誘導する必要がある。同じレイヤー2範囲に直接到達可能なDHCPv4サーバーがあると、要求が4o6RAを通らない可能性がある。

RFC 9928は、その結果としてクライアントとサーバーの状態が食い違い、到達性へ影響する設定ミスが生じ得るとする。ただし新しいセキュリティ問題ではなく、配備エラーとして扱う。

運用上は、分類名より観測が重要である。意図した4o6経路と直接DHCPv4経路の双方が、一見妥当なリースを返せる。したがって記録には、broadcastの捕捉、更新時unicastの経路、直接サーバー経路が存在しないか遮断されたという否定的証拠も必要だ。

リレー管理記録の構成

提案する記録はRFCの新フィールドではない。既存システムに散在する事実を、意味を混同せず結ぶための運用上の受領証である。

入口では、DHCPv4要求、トランザクションの限定的な指紋、時刻、アクセス装置、クライアント側ポートを残す。続いて、マッピング世代、4o6RA、選択した上流インターフェース、封入イベントを記録する。4o6RAからLDRAへの内部受け渡しは、実装版と欠落時の扱いを含め独立項目にする。

プロトコル側では、不透明なInterface-ID、その値が置かれたRelay-forward層、他のlink-addressとリレー順序を保存する。サーバー側では、該当した規則、選択プール、返した設定を保存する。帰路では入れ子の順序、解封入、元ポートへの配送を結ぶ。

最後に、直接DHCPv4経路の検査結果、RenewやRebind、物理移動、修正、期限切れ、ロールバックを記す。単一のログは全体を証明できない。目的は、各遷移を管理する主体が自分の事実に責任を持てるようにすることだ。

IETFは相互運用可能な機構を定める。アクセス事業者はポート対応を、リレー運用者は捕捉と封入を、DHCPサービス所有者は規則とプールを管理する。仕組みを知らない旧来クライアントに、見えない経路の承認者という役割を負わせてはならない。

出典