要約

  • RFC 5107 の suboption 11 は、relay が選んだ IPv4 アドレスをサーバーの option 54 に入れさせる。これは renewal を relay に戻すための宛先であり、実サーバーの interface や identity の証明ではない。
  • サーバーは上書き値を後続メッセージのために記憶する。lease とその補助状態を同じ世代で復元できなければ、正しい client request でも renewal path は壊れる。

復旧試験では DHCP サーバーの lease database が正常に戻った。ところが client の RENEW DHCPREQUEST は黙って捨てられる。client が示す Server Identifier はサーバー自身の interface ではなく、再起動前に relay から学んだ override だった。lease は永続化され、戻り先の記憶だけが失われていた。

通常の DHCPv4 では、初回の DHCPDISCOVER が relay を通るとき、Relay Agent Information に Circuit-ID や Remote-ID を追加できる。lease 取得後、RENEWING の client は option 54 のアドレスへ直接 DHCPREQUEST を送る。topology によっては relay を通らず、サーバーは現在の接続点を示す情報を受け取れない。

RFC 5107 は client の戻り先を relay 側へ引き戻す。relay は code 11、length 4 の Server Identifier Override suboption に IPv4 アドレスを入れる。対応サーバーはその値を reply の option 54 に使う。次の renewal はそのアドレスへ届き、relay は最新の option 82 情報を付けて実サーバーへ渡せる。

ここで Server Identifier という名前と、値の実際の役割が分かれる。option 54 はサーバーの物理的な場所を示さない場合がある。client が renewal を投入する入口であり、lease を判断するサーバー instance と同一とは限らない。

サーバーは relay から次のメッセージを受け取るまで、client ごとの override address を記録しなければならない。この状態には generation が必要である。学習元 relay、client/lease key、学習時刻、suboption digest、置換理由を保存しなければ、再起動後の不一致を説明できない。

未対応サーバーは suboption を無視し、自分の適切な interface address を option 54 に入れる。初回 ACK は成功し得るため、compatibility failure は renewal まで潜伏する。client は実サーバーへ直行し、relay は renewal を観測できず、attachment evidence も再付与されない。

混在 cluster では support を instance 単位で測る必要がある。二台が override を使い、一台だけ無視すると、全体の lease 成功率は問題を隠す。受信 suboption、送信 option 54、次回 renewal の実経路を対応づけるべきである。

通常、サーバーは DHCPREQUEST の option 54 が自分の interface address か確認する。override が含まれる場合、比較対象は suboption 11 になる。二つが同じなら、option 54 がローカル interface でなくても request を処理する。

この一致は message 内の整合性でしかない。suboption を誰が挿入したか、relay が信頼されているか、client が真正な reply を保存したか、アドレスを誰が保有するかは証明しない。match=true を server authentication に昇格させてはならない。

relay は通常どおり giaddr を設定する。override は allocation network の手掛かりを置き換えない。Circuit-ID、Remote-ID、Device Class、元の broadcast/unicast も別の事実である。一つの “relay context” blob にまとめると、どの証拠が欠けたか分からなくなる。

複数サーバーに forward する relay は、RENEW を含む全 DHCP message を全サーバーへ送ることが推奨される。relay が shadow lease table を持たずに済むためである。lease state を持つサーバーが request を評価する。

したがって fan-out には destination ごとの receipt が要る。relay receive は server receive ではない。一台の ACK は全 destination への delivery を証明しない。lease を持たないサーバーの silence も packet loss とは限らない。

RFC 5010 の Relay Agent Flags は、client message が元々 broadcast か unicast かを伝える。RFC 5107 は併用を勧める。server-facing packet の見え方から client 側の原形を推定すると、relay による変換を無視することになる。

override を採用すると relay availability が lease continuity の一部になる。client が override address に届かなければ最初の leg で止まる。relay が server に届かなければ二番目の leg で止まる。option 54 の形式が正しくても lease は timeout する。

観測すべき chain は、client ingress、override 選択、giaddr、original-delivery flag、relay evidence digest、server receipt、override state persistence、reply option 54、client receipt、renewal relay receipt、per-server forwarding、lease decision、client apply、first traffic である。

再起動試験では lease と override state を別々に検証する。lease だけ戻る場合は override_state_lost、override だけ古い場合は context_generation_mismatch と記録する。一般的な renewal_failed では復旧方法を選べない。

移行時には逆の問題も起こる。同じ anycast address の背後で relay set が変わるかもしれない。server pool は同じまま戻り先だけ変わるかもしれない。address continuity と principal continuity は別々に version 管理すべきである。

security boundary は relay-server trust にある。rogue relay は自分の address を指定して renewal を引き寄せ、後で拒否し、DHCPACK option を改変し、server が認めていない lifetime を見せることができる。suboption 11 自体に security benefit はない。

DHCP authentication と Relay Agent Information authentication は、保護する principal と field が異なる。server が relay option を検証したことは、client が server を検証したことではない。authenticated DHCP という一つの status では監査できない。

DHCPACK receipt も終点ではない。client が address、mask、router、route を install したか、first-hop policy が許可したか、traffic や service が成立したかは別の receipt である。Server Identifier は downstream outcome を代表しない。

RFC 5107 が示す最小限の教訓は、wire label を ontology にしないことである。Server Identifier が relay-chosen path address になり得るなら、operations model はその indirection を保ち、実サーバー identity を別に記録しなければならない。

出典