要約

  • RFC 10038はSRv6 locator向けにDHCPv6のidentity associationを定義し、IAID、locator構造、preferred/valid lifetime、T1/T2、サーバーbinding、払い出せない場合の明示的な状態を持たせた。
  • 正常なReplyはクライアントによるlocator設定につながるが、ローカル経路の導入とルーティング広告は別の任意動作である。ローカルSIDの割り当て、複数locatorの利用、SID広告は仕様の対象外だ。
  • Weiqiang ChengとChangwang Linが編集者、Ruibo Han、Daniel Voyer、Geng Zhangが共同著者、Yuanxiang Qiuが貢献者である。個人の発明や実網導入ではなく、共同で定義した状態遷移として評価すべき記録だ。

運用設計が本当に結合されていたかどうかは、作るときよりも消すときによく分かる。クライアントがSRv6 locatorをReleaseした。DHCPv6サーバーはbindingを削除した。では、アクセス装置の経路、ルーティング広告、下流のキャッシュ、CPE上のSIDとpolicyはどうなったのか。

「リース解除済み」という一行は、それらの答えを含まない。

2026年8月にIETF Standards Track文書として公開されたRFC 10038は、DHCPv6を使ってSRv6 segment endpoint nodeにlocatorを割り当てる方法を定める。IA_SRV6_LOCATOR、IA Locator option、NoSRv6LocatorAvailを導入し、要求、Reply、更新、再binding、Releaseを一つの識別可能なライフサイクルにする。

著者記録も一つに縮めてはならない。Weiqiang ChengとChangwang Linは編集者であり、Ruibo Han、Daniel Voyer、Geng Zhangも著者、Yuanxiang Qiuは貢献者である。2026年8月31日に保存したIETFプロフィールでは、ChengはChina Mobile Research InstituteのChief Architect of IP Networks、SRv6 Operationsワーキンググループ議長、9本のRFCの著者として掲載されていた。これは標準化への参加を示すが、China Mobileや他の特定ネットワークでの導入を証明しない。

IAIDと時間が割り当てを特定する

単なるIPv6 prefix一覧では、どのクライアントに、どの条件で、いつまで割り当てたのかが分からない。IA_SRV6_LOCATORのIAIDは同じクライアントが持つ別のassociationから対象を識別する。T1は元のサーバーへ延長を求める時点、T2は利用可能な別サーバーにも延長を求められる時点を表す。

locator optionにはpreferred lifetimeとvalid lifetimeがあり、locator block、locator node、function、argumentの長さ、さらにAlgorithm値が含まれる。したがって記録すべき対象は「prefixがある」ではない。クライアント、IAID、relay、サーバー、構造、残り時間を備えたbindingである。

この時間軸には中間状態がある。preferredではなくなってもvalidである期間があり、T1を過ぎてもT2前なら元サーバーへの更新を続ける。valid lifetimeが終われば、サーバーはlocatorを回収しbindingを削除する。「有効／無効」だけの表示は、更新がどの段階にあるかを消してしまう。

有効なReplyを受信すると、クライアントは割り当てられたlocatorを設定する。しかし仕様はそこから先を慎重に区切る。locatorからローカルSIDをどう作るか、複数locatorをどのサービスに使うか、そのSIDをどう広告するかは対象外である。locatorの並び順からサービスの意味を推測することも禁止される。共通のwire上の順序をローカルpolicyに昇格させてはならない。

経路は別の所有者が作る

RFC 10038の5.5節では、DHCPv6 relayまたはサーバーが要求を受けたとき、対応するローカル経路を導入できる。そのnext hopは要求クライアントを指すべきである。さらに、他のrouterが学習できるよう、従来のルーティングプロトコルで広告できる。

ここでの任意性は実装上の余白ではなく、証拠の境界でもある。サーバーbindingが正しくても、ローカルRIBに経路がないことはあり得る。RIBにあってもFIBへのprogrammingが失敗し得る。経路があってもexport policyが広告を止める。広告が出ても全routerの収束は別である。収束しても、CPEに必要なSIDやSR policyがなければ意図したサービスにはならない。

Algorithm値も広告方法を分ける。0なら通常のIP prefix reachabilityとして広告できる。0以外ならRFC 9352またはRFC 9513のLocators TLVを使わなければならない。prefixの形だけを見て通常経路として扱うと、必要なalgorithm関係が失われる。

運用証拠は、サーバーbinding、クライアント設定、ローカルRIB、FIB、広告形式、下流収束、SID、SR policy、フィルター、packet観測を別の項目として持つべきだ。同じIAIDとlocatorで関連付けることはできるが、一つの成功状態に統合してはならない。

Releaseは依存状態を逆向きにたどる

Releaseを受けると、割り当てたlocatorを解放し、ローカル経路を削除し、以前の経路広告をwithdrawしなければならない。リース満了でも、サーバーはprefixを回収してbindingを消す。要求される結果は明確だが、実行主体は複数である。

サーバーはbindingを持ち、relayやアクセス装置はnext hopを持つ。routing systemは広告を持ち、CPEやcontrollerはSIDとpolicyを持つ。解除の証明には、終了したIAIDから、それに依存した経路、広告、cache、policyまでを追跡できるcorrelationが必要だ。

集約経路がある場合、個別locatorのReleaseで集約まで消えるとは限らない。RFCはRIB規模のために集約を使う選択を認めている。個別prefixが委任されていなければ、delegating routerがその宛先packetをdiscardできる。集約の存在と個別リースの無効は両立する。

この場合、「広告が残っている」は異常の十分条件ではない。確認すべきなのは、現在の個別委任集合と、無効なprefixに対する境界での処理である。古いlocatorへのpacketが集約の入口まで届き、そこで意図どおりdiscardされるなら、安全な否定結果になり得る。

信頼ドメインは運用条件である

この利用モデルは関連機器が一つのtrusted SR domainにあることを前提とする。CPEはoperatorまたはtrusted partnerが管理し、顧客宅内に置かれる場合でも機器とportはoperatorのadministrative domainに属する必要がある。

ただしDHCPv6には既定でend-to-end encryptionがない。hijacking、改ざん、盗聴の可能性は残る。複数の割り当て方式を併用するならpoolを重複させてはならない。1クライアント当たりの上限だけでは、悪意ある参加者が多数のクライアントを装ってpoolを消費する攻撃を止められない。

境界にあるDHCPv6クライアントは、内部・外部の両interfaceで適切にtrafficをfilterしなければならない。「trusted」と設定された所属情報は、port管理、address空間の分離、filter ruleの現状を代替しない。信頼は継続的に成立させる制御である。

宣言ではなく再現可能な連結を残す

Heng LuのRunning-Code Primacyを当てはめると、bindingは現実の一部を記述するが、経路を作る権威ではない。Minimum Initial Specificationは、共通層に必要な厳密さだけを置き、将来の判断を各operatorに残す設計を求める。

RFC 10038はoption、時間、client/server/relay動作、Release、経路との境界を共通化する一方、SID設計やサービスpolicy、集約方式を決めない。この狭さは欠点ではない。ローカルな選択を、ローカルなrunning evidenceで示す責任を明確にする。

再現可能な記録は、client identity、IAID、relay、server、locator構造、Algorithm、T1/T2、lifetime、binding、client設定、経路、広告、収束、SID、policy、filter、限定したpacket試験を時系列で結ぶ。解除時には同じ関係を逆向きに検証する。

「locatorを割り当てた」は正確で価値のある結論だ。「経路を導入して収束した」は別の結論である。Chengらの共同作業は、最初の結論を曖昧なinventoryから検証可能なleaseへ変えた。後の結論まで自動的に所有したわけではない。

出典