要約
- RFC 5007 の成功応答は、クライアントデータ、追加照会が必要なリンク一覧、または空の結果になり得る。いずれも端末が今オンラインだという判定ではない。
- 問い合わせ先、応答形、複数サーバーの照合、保持状態、経路・認可判断、実際に観測した結果を分けて記録する必要がある。
アクセス装置を再起動した。Leasequery でローカルのバインディング行が再び埋まり、復旧表は緑になる。ここで「端末を確認」と書けば、台帳の復元が現場の観測へすり替わる。
RFC 5007 は、DHCPv6 サーバーが持つバインディング情報へ軽量にアクセスする方法を定める。LEASEQUERY は照会専用であり、IPv6 アドレス、プレフィックス、そのバインディングの状態を変更しないと明記されている。返るのはサーバーの知識であって、端末を直接測定した結果ではない。
オンデマンドの代表例では、アクセスコンセントレータが IPv6 パケットを受信し、そのアドレスをリース中のクライアント情報を更新する。パケット観測が先にあり、照会はそれを契機に起きる。応答があるからといって、元のパケットが正当だったこと、同じ端末が今も到達可能であることまでは示さない。
成功応答にも三つの分岐がある。バインディングがあれば OPTION_CLIENT_DATA が返り、要求側は保持情報を更新する。複数リンクにバインディングがあれば OPTION_LQ_CLIENT_LINK が返り、各リンクを指定した再照会が必要になる。バインディングが見つからない場合は、成功応答であっても両オプションがない。単一の success 指標では、データ取得、次の作業一覧、空の回答を区別できない。
エラーも不存在の証明ではない。状態に応じて別サーバーを選ぶ、照会を直す、複数サーバーへ送る、またはローカル方針で終了する。権威情報を持つサーバーが分かるならそこへ送り、不明なら既知または設定済みの全サーバーへ送ることが推奨される。途中終了には運用上の理由があっても、権威集合を網羅したことにはならない。
複数の応答は照合が必要だ。別々の種類や値、たとえば一方のアドレスと他方の委任プレフィックスは disjoint data とされ、統合すべきである。同じ種類・同じ値が重なる場合は conflicting data とされ、異なるサーバー間では最新の OPTION_CLT_TIME を持つデータを選ぶことが推奨される。
検証済み errata は実装判断を変える。技術 erratum 3763 は、OPTION_CLT_TIME のないクライアントデータを捨てるという原文を削除した。フェイルオーバーの相手側はバインディングを持っていても、クライアントとの最終トランザクション時刻を持たない場合がある。時刻付き応答もあればそちらを優先し、時刻なししか得られなければそのデータを受け入れられる。編集 erratum 4816 は誤記 OPTION_CLIENT_LINK を OPTION_LQ_CLIENT_LINK に直す。
OPTION_CLT_TIME 自体も生存確認ではない。サーバーが応答を作る時点で、最後にクライアントと通信してから経過した時間を表す。端末からの現在の heartbeat でも、人の資格情報でも、認可エンジンの結果でもない。「受け取ったサーバー報告の中で新しい」と「今そこにいる」は別だ。
委任プレフィックスの再起動問題は循環を示す。アクセス装置が必要な経路をまだ投入できないと、照会を起動するはずの通信そのものが届かない。RFC 5007 は先回りして内部データを再構築する考えを述べるが、その方式は同 RFC の仕様外である。後の RFC 5460 が Bulk Leasequery、RFC 7653 が Active Leasequery を定義した。単発照会に一括復旧や継続通知の性質を持ち込んではならない。
保護された通信にも限界がある。信頼されたリレーが信頼されない起点の要求を運ぶことがあり、サーバーは relay 経由を拒否したり、信頼済み要求者にも返す項目を制限したりできる。悪意あるサーバーなら不正確なリース情報や経路情報も返せる。認証は交換の参加者を絞るが、保持データの完全性や現在性を保証しない。
negative cache は負荷対策である。最近の照会でデータが返らなかった事実を一定時間保持すれば、再起動時の要求増幅を抑えられる。しかし、その記録は端末やバインディングが存在しないという恒久証明ではない。
運用証跡には次を残すべきだ。
- 契機となった観測、照会種別、アドレスまたは DUID、リンク条件;
- 想定した権威サーバー集合と実際の問い合わせ範囲;
- 要求・応答、認証、リレー、再試行、終了理由;
- データ、リンク一覧、空成功、エラーという正確な応答形;
- リンク別の追加照会と未完了項目;
- disjoint data の統合と conflict の選択;
OPTION_CLT_TIMEの有無と適用した規則;- negative cache と保持状態のリビジョン;
- 経路・フィルター・認可判断と、その後に独立観測した効果。
これは RFC の追加要件ではなく、Heng Lu の reality layers に沿った統治上の提案だ。サーバー表現、交換、ローカル状態、執行、観測効果を、証拠が結ぶまで別々に扱う。
RFC 7513 は SAVI のバインディング回復で Leasequery を利用し得ることを示すが、制御に使うバインディングが人の身元や端末の現在性になるわけではない。背景は RFC 3315、RFC 3633、IPv4 の RFC 4388 にあり、後続の RFC 8415 と RFC 9915 もこの証拠境界を消さない。
出典
- RFC 5007 — DHCPv6 Leasequery
- RFC 5007 — 正式テキスト
- RFC Editor の RFC 5007 記録
- RFC 5007 errata
- IETF Datatracker 記録
- IETF Datatracker 履歴
- RFC 3315 — DHCPv6
- RFC 3633 — IPv6 プレフィックス委任
- RFC 4388 — DHCP Leasequery
- RFC 5460 — DHCPv6 Bulk Leasequery
- RFC 7513 — SAVI framework
- RFC 7653 — DHCPv6 Active Leasequery
- RFC 8415 — DHCPv6
- RFC 9915 — DHCPv6
- IANA DHCPv6 Parameters
- Heng Lu — Running Code Primary
- Heng Lu — Minimum Initial Specification
- Heng Lu — On Reality Layers
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
