要点

  • DHCPv6-PD は要求ルーターにプレフィックスの利用責任を渡すが、その先のトポロジーは記述しない。
  • 要求側はリースを安定した子プレフィックスと整合する寿命に変え、CE は各リースと正しいネクストホップ経路を同期させなければならない。
  • 委任から経路までの受領証によって、プロトコル状態を双方向のパケット証拠に結び付ける必要がある。

リースは正常、LAN は不通

サポート画面に IA_PD の成功が表示されている場面を考える。下流ルーターはプレフィックスを受け取り、preferred lifetime と valid lifetime は正常に減少し、DHCPv6 エラーもない。それでも、その先のサーバーへ向かうパケットは CE で消える。CE が委任プレフィックスを下流ルーターへ向ける経路を一度も入れなかったか、クライアントが使い終える前に削除したからだ。

二つの画面はどちらも正しい可能性がある。DHCPv6 の委任が有効でも、転送経路は未完成になり得る。問題は、リース成功をプール予約、リンク割り当て、Router Advertisement、転送実装、到達性まで含む証明として扱うことにある。

RFC 8415 は境界を明確にしている。プレフィックス委任は、委任ルーターが要求ルーターの背後のトポロジーを知らない状況を想定する。サーバーがプレフィックスを選び、クライアントがその責任を負う。クライアントはサブネット化し、インターフェースに割り当て、リンクへ広告できる。これらは委任後の処理であって、IA_PD 成功状態の中身ではない。

時間で区切られた責任移転

運用上必要なのは「プレフィックスあり」という印ではなく、クライアント ID、IAID、プレフィックスと長さ、サーバー、T1、T2、二つの寿命、観測時刻を一組にした記録である。Renew は寿命を延長できるが、RFC 8415 はサーバーがプレフィックス集合を変更したり、不適切になったプレフィックスを寿命ゼロで返したりすることも認める。成功ラベルではなく応答内容そのものが必要だ。

寿命には親子関係がある。委任から派生したアドレスや子プレフィックスを、親に残された時間より長く広告してはならない。これを破ると、上流の権限が終わっても LAN はアドレスを利用可能と判断する。利用者には経路障害に見えるが、実際には時間境界の不整合である。

RFC 9818 は LAN 側で再委任する CE の要件を加える。内部インターフェースで IA_PD を扱い、利用可能なプールから割り当て、不足時には管理エラーを記録する。方針やトポロジーの変更がない限り、リンクのプレフィックスを変えてはならない。さらに、リースと対応するネクストホップによってローカル経路表を動的に更新し、Release または失効時に経路を除去する必要がある。

上流ブロック不足、子プレフィックスの予約不整合、下流広告の欠落、リースに対応する経路の欠落、親を超える子の寿命、往復で異なる方針など、独立した障害点が残る。DHCP Reply だけを読み直しても解決しない。

境界の両側から受領証を作る

委任側ではサーバー、DUID、IAID、正確なプレフィックス、取引時刻、T1/T2、preferred/valid lifetime、そして Assign、Renew、Rebind、Release、失効の別を記録する。要求側では、実際に割り当てた子プレフィックス、対象のリンクやルーター、継承寿命、判断した設定世代を記録する。

次に転送証拠を添える。CE の経路、ネクストホップ、インターフェース、導入時刻、抑止し得るフィルター、削除イベントを記録する。下流ではローカル経路、Router Advertisement、期待する送信元アドレス選択を確認する。最後にサービス境界から双方向のパケット試験を行う。CE からの ping 一つでは DNS、ステートフルフィルター、送信元選択、非対称な復路を覆えない。

初回委任、更新、方針またはトポロジー変更、Release または失効の四時点で再評価する。同じプレフィックス文字列でも、ネクストホップ、プール、寿命、広告、フィルターは変わり得る。

適用範囲を広げ過ぎない

この受領証は DHCPv6 をトポロジープロトコルに変えない。責任分担を守ったまま複数システムの証拠を結ぶ。複数プロバイダー環境の送信元選択や経路方針も解決しない。RFC 9818 はその複雑さから複数プレフィックス・複数プロバイダーを対象外としており、運用者は出口、復路、障害領域の証拠を別に追加しなければならない。

出典