要約

  • RFC 9915の撤回規則は、過去にReplyで受け取った構成Optionをclientが再度要求し、Renew、RebindまたはInformation-Requestへの有効なReplyがそれを省いた場合に限って働く。
  • この欠落はserverの応答内容とclientの規範上の義務を示す。保存構成、利用process、旧宛先への通信、service結果が変わったことまでは示さない。
  • IA Optionは別処理であり、同じ情報がRouter Advertisementやlocal policyから再供給されることもあるため、値だけでなく由来を追う必要がある。

03:00のReplyが証明する範囲

Section 18.2.10.5には前提が三つある。以前のReplyがOptionを渡したこと、後続の要求がそのOptionを再び求めたこと、対応する有効なReplyがOptionを含まなかったことである。最後のpacketだけを見ても、要求側が何を求めたかは分からない。二つのserver設定を比較しても、対象clientがどちらのReplyを受け取ったかは分からない。

条件がそろうと、clientは以前の情報を使うのをやめ、Optionを受け取らなかった状態へ戻るべきだとRFCは定める。しかしSHOULDはserver logをclientの実行証明へ変換する魔法ではない。構成の書換え、daemonのreload、接続の再選択には、それぞれ別の失敗点がある。

03:00のReplyは制御面の強い証拠である。03:07のpacketはdata planeの別の証拠である。両者が並んだとき、正しい問いは「RFCに違反したか」から始まらない。まず、03:07の宛先をどの仕組みが現在供給しているかを確かめる。

残存を許す条件と許さない条件

RFC 9915は、停止する現実的な方法がなく、他の情報源もなく、外部への影響もない場合に限り、値の残存をMAYとして認める。例はClient FQDN Optionで設定されたhostnameである。合理的な解除方法がなく外部影響もないなら、その名前を無理に空にする必要はない。RFC 4704はFQDN OptionとDNS更新の役割分担を定義している。

NTP server addressは逆である。条件を満たす後続Replyから消えたなら、clientはそのDHCP構成のaddressを使うのをやめなければならない。RFC 5908はNTP/SNTP serverの位置を渡すOptionを規定する。したがって旧宛先への継続通信は重要な調査対象になる。

ただし、RFC 9915は同じ構成情報の別の供給元を受け入れるようにも求める。DNSでは、RFC 3646のDHCPv6 OptionとRFC 8106のRDNSSが、異なる権威とlifetimeで同じresolver addressを渡し得る。同じ値が残っていることと、撤回されたDHCP値を使い続けていることは同義ではない。

IAとReconfigureを混ぜない

この撤回規則はIA Optionに適用されない。IA_NAのaddressやIA_PDのprefixはSection 18.2.10.1で処理される。単純な「欠落検知」をすべてのOptionへ展開すると、leaseの状態を誤って削除済みと判定しかねない。

Reconfigureも結果ではなくtriggerである。有効なReconfigureを受けたclientはRenew、RebindまたはInformation-Requestを実行する。RFCはapplicationへの影響を考慮してeventのlogを勧めているが、triggerの受信、exchangeの完了、local stateの反映、serviceの回復は独立した時点である。

七分間を監査可能にする

変更記録には、旧Optionを供給したReply、再要求、欠落した有効Reply、client構成のversion、consumer processの反映、残存値の供給元、旧宛先への最後の通信を残すべきだ。この順序があれば、遅延、実装不備、別経路からの正当な再供給を区別できる。

RFC 8415にも実質的に同じ規則があった。RFC 9915は独立した節として見通しを良くし、旧基本仕様を置き換えた。新しいのは運用上の事実ではなく、引用しやすい境界である。その境界を越えて「Replyから消えたから現場からも消えた」と報告してはならない。

出典