要約

  • DHCPv6 clientはnetwork informationの変化を検出したとき、保有中のaddressが現在のlinkに適するかをConfirmで照会する。requestは特定のserverを指名しない。
  • Successは提出した全addressがlink testに通ったことだけを示す。serverはT1、T2、preferred lifetime、valid lifetimeを無視するため、leaseは延長されない。
  • RFC 9915はTomek Mrugalski、Bernie Volz、Michael C. Richardson、Sheng Jiang、Timothy Wintersの共同著作である。仕様はtopology、lease authority、実際の通信結果を混同しない。

移動後に残る二つの状態

端末が別のWi-Fiへ移るとき、OSには少なくとも二つの状態が残る。一つは「このaddressは今いるlinkのprefixに属するか」。もう一つは「このaddressをあと何秒使えるか」だ。

前者は場所に関する状態、後者はleaseに関する状態である。Confirmが調べるのは前者だけだ。

RFC 9915では、DHCP serverから得たaddressを持ち、delegated prefixは持たないclientがnetwork informationの変化を検出したときにConfirmを使う。Client Identifier、IA、現在の全addressを入れる一方、Server Identifierを入れてはならない。入っていればserverはmessageを破棄する。

元の割当serverを指定しないのは、権限を曖昧にするためではない。現在のlinkにどのprefixが適するかは、そのlinkの情報を持つserverが答えられる。bindingを最初に作った主体である必要はない。

全addressが適切ならSuccess、一つでも不適切ならNotOnLink。prefix情報がなく判定できない場合、またはaddressが一つもなければ、serverはReplyを送ってはならない。沈黙は肯定ではなく、判定不能を含む「有効な応答なし」である。

ゼロにして送る時間

Confirm messageのIA_NAではT1とT2、IA Addressではpreferred-lifetimeとvalid-lifetimeを0にすることが推奨される。serverが無視するからだ。

これは無駄なfieldではない。何をこの取引の対象外にするかを明示している。serverはaddressを見てlink適合性を調べるが、古いlease clockを読み直したり、新しいclockを発行したりしない。

期限を延長するのはRenewである。T1になるとclientはleaseを提供したserverへ送り、serverはbindingを探し、新しいlifetimeと必要なT1/T2を返す。応答がなくT2に達した後は、Rebindによって任意の利用可能serverへ延長を求める。

したがって三つの操作は、単なるretry段階ではない。

  • Confirmはlink knowledgeを持つserverに場所を問う。
  • Renewは元の割当serverに時間を問う。
  • Rebindは元の経路が失敗した後、別のserverに時間の責任を引き受けられるか問う。

IANAのmessage type registryもConfirmを4、Renewを5、Rebindを6として区別する。registryは名称の互換性を支えるが、serverの知識や実行結果までは記録しない。

同じ継続、異なる根拠

Successを受け取ればclientはaddressを使い続けられる。Confirm exchangeがReplyなしで終了した場合も、最後に知っていたlifetimeの範囲内でleaseと設定を使い続けることが推奨される。

画面上は同じだ。addressは消えない。しかし一方にはlink verdictがあり、他方にはない。interface snapshotだけでは区別できない。transaction ID、responder DUID、status、時刻を結合する必要がある。

どちらの場合もclockは更新されない。valid lifetimeが残り600秒なら、Successの直後に600秒へ戻るわけではない。後続のRenewまたはRebind Replyが新しい値を与えるまでは減り続ける。

RFC 4862はpreferred、deprecated、invalidを分ける。preferred lifetimeが尽きれば、新しい通信でそのaddressを選ぶべきではなくなる。valid lifetimeが尽きればsourceにもdestinationにも使えない。Confirm済みという表示は、これらの状態を上書きできない。

この規則は障害時の継続性を守りながら、存在しない許可を作らない。応答が一時的に得られなくても、まだ有効なleaseを直ちに捨てる必要はない。しかし沈黙から新しい時間を生成することもない。

多数決ではない複数Reply

特定serverを指名しないため、複数のReplyが到着し得る。RFC 9915は、一つでも有効なSuccessがあればaddressを使い、NotOnLinkを無視できるとする。受け取ったReplyがすべてNotOnLinkのときだけserver discoveryを再開する。

これは過半数ルールではない。十分なlink情報を持つ一つのserverの肯定を、継続のために採用する。ただし、反対したserverの存在は消してよい情報ではない。

例えば二台がNotOnLink、一台がSuccessなら、clientの最終判断は継続である。同時に、prefix configurationの同期状態には疑問が残る。単一の成功counterに集約すると、その疑問を事故前に失う。

必要な記録は、各serverのDUID、relay path、interface、評価したaddress set、prefix configuration revision、statusである。どの肯定が決定的だったかも残す。

しかも判定はaddress set全体に対するものだ。一つのaddressが不適切ならNotOnLinkになるが、statusだけでは原因addressを特定できない場合がある。入力を捨てたnegative resultは診断能力を持たない。

Confirmが代行しない検査

linkのprefixに合っていても、同じaddressを別nodeが使っているかもしれない。Duplicate Address Detectionは別である。

on-linkでもneighborが応答するとは限らない。Neighbor Unreachability Detectionは別のprobeとstateを持つ。

localに妥当でもupstream routeがあるとは限らない。prefix knowledgeはpacket deliveryではない。

leaseが有効でもapplication sessionが生きているとは限らない。configurationとservice continuityは別である。

また、別serverがlinkを知っていても、元のserverがbindingを保持している証拠にはならない。

一つのmessageにこれらを詰め込まないことが、最小機構としての強さである。各layerが自分のreceiptを持ち、必要なときにjoinできる。

仕様を書く人と実装を作る人

RFC 9915は2026年1月にInternet Standard STD 102となった。著者はTomek Mrugalski、Bernie Volz、Michael C. Richardson、Sheng Jiang、Timothy Wintersであり、さらに多くのreviewerとcontributorがいる。個人がDHCPv6を所有するという話ではない。

IETF DatatrackerにはMrugalskiの多数のDHCP関連RFCが記録されている。ISCが2024年に公開した職員紹介は、大学院での研究から生まれたDibblerと、その後のKea開発を説明する。仕様とrunning codeの両側を歩いた人物像は確認できるが、全vendorのconformanceを証明するものではない。

この経歴が重要なのは、Confirmの境界が実装上の分岐だからだ。Success、全ReplyがNotOnLink、Replyなしという三経路は、一時的には同じaddress表示を残し得る。実行logなしでは、仕様名だけから経路を復元できない。

Heng LuのMinimum Initial Specificationとして読むと、共通化したのはlinkに必要な小さな判定だけである。lease、route、applicationの判断はcontextを持つactorに残る。Running-Code Primacyは、その小さな判定が実際にどう使われたかを確認することを求める。

agency problemは、安いmetricが広い約束へ変わるときに現れる。client vendorはConfirm success rateを簡単に出せる。operatorはrelay contextとprefix revisionを保存し、lease serviceはbindingを管理し、利用者はexpiryの影響を負う。一番安い数字の提供者だけに意味を決めさせてはならない。

残ったaddressを説明する六つのreceipt

第一はmovement trigger。interface、変化したnetwork information、client state、時刻を記録する。

第二は既存lease。assigning server DUID、IAID、address、取得時刻、T1/T2、preferred/valid lifetime、Confirm直前の残り時間である。

第三はrequest。client DUID、transaction ID、全address、relay/interface、Server Identifierがないことを残す。

第四は全Reply。responder DUID、link context、prefix revision、statusを保存する。無応答はexchange timeoutとして記録し、Successを補わない。

第五はclient decision。一つ以上の肯定、受信分がすべて否定、または無応答のどれだったか、継続か再発見かを記録する。

第六は後続の権限と動作。Renew/Rebind、新lifetime、deprecated/invalidへの移行、DAD、neighbor、routeを別項目にする。

このjoinがあれば、報告は簡潔でも正確になる。「server Sが時刻Tにaddress setを現在linkへ適合と判断。lease lifetimeは変更なし」。Successを大きく見せるより、はるかに運用価値が高い。

情報源