要約

  • RFC 9762 の P は、PIOごとの正の選好信号である。対応ホストは、Aも設定された共有プレフィックスから新規SLAACアドレスを作る前に、DHCPv6 Prefix Delegationを試す。
  • P=1 はリースではない。RA受信、クライアントの判断、DHCP Reply、長さの適合、relay binding、経路とfilter、送信元と第一ホップ、実トラフィックは個別の証拠を要する。
  • Pが見えないことはPD不在を意味しない。一方、Pを含むRAは通常のRA信頼境界を継承し、偽装や変動によってアドレス取得の遅延やREBIND負荷を起こし得る。

監視グラフには、同じPIOのPが1と0を往復した跡が残っていた。端末はそのたびに状態を見直し、すでに委任を持つ端末ではREBINDが増えた。担当者はPが0になった瞬間を「委任失効」と解釈したが、DHCPのvalid lifetimeはまだ切れていなかった。

RFC 9762 は、この二つの時計を意図的に分けている。RAのPは、端末がどのアドレス取得方式を先に試すべきかを示す。DHCPサーバーが与えたプレフィックスの寿命を、RA送信者が上書きするためのビットではない。

この区別を失うと、監視画面は「P受信」を「PD利用可能」に変換し、さらに「プレフィックス取得済み」「経路設定済み」「通信可能」へと緑色を転用する。実際に観測した事実は小さい。特定interfaceがRAを受け、特定PIOにPがあり、対応クライアントが別protocolを開始する理由を得た。それだけである。

先に作ったアドレスは安く消せない

PをPIOに置く理由は順序にある。端末が共有on-link prefixから先にSLAACアドレスを作れば、applicationはそれを使い始める。後から端末専用のdelegated prefixを得たとき、両方を残せばscale上の利点が薄れ、先のアドレスを廃止すれば既存flowを壊しかねない。

そこでPは、アドレス作成より前に選好を知らせる。対応クライアントに対し、RFC 9663 の端末単位prefix modelを選び、共有PIOから個別アドレスを増やさないよう促す。選好はPIO単位である。global prefixではPDを優先し、別のULA prefixではSLAACを使う構成も可能だ。multihomingでは上流ごとに異なる選好を持てる。

PはRAのM、Oから独立する。Pを知らない既存端末の中にはMもOも0ならPDを始めないものがあり、それらも対象にするnetworkはMまたはOも必要になる。routerはPとAutonomous Aを別々に設定できなければならず、Pの変更がAを自動変更してはならない。

この独立性がfallbackを残す。PとAを同時に1にできる。Pを尊重する間、clientはAを未設定として扱い、新しいSLAAC addressを作らない。しかし適切な委任を得られなければ、そのinterfaceでP処理を止め、Aが許すSLAACやIA_NAへ戻れる。RFC 4862 が更新対象のautoconfiguration規則を、RFC 4861 がRAとNeighbor Discoveryの土台を定める。新しいbitは分岐を追加するが、両protocolを置き換えない。

P-listは寿命を持つローカル状態である

clientはinterfaceごとに、P=1で受信しpreferred lifetimeが0でないPIO prefixをすべてlistに保持する。listが空から1件へ増えたとき、すでに実行中でなければPD requestを開始すべきである。lifetime満了またはpreferred lifetime 0のPIO受信でentryを外す。

listが0へ戻った場合は条件付きだ。他にPDを続ける理由がなければrequestやrenewを止めるべきだが、取得済みprefixのlifetimeは変わらない。RAは招待を撤回できるが、DHCP leaseを取り消せない。

すでにdelegationがある状態でlistが変わると、新しいconfiguration情報として通常REBINDを行う。ただしlistが空になった場合を除く。RFC 8415 がそのstate machineを定める。Rebind、Reply、server、transaction、IA_PDは新しい証拠であって、先のRAの一部ではない。

運用記録はRA source、interface、PIO、P/A/L、lifetime、list generationを一組として残し、clientが実際にSolicitまたはRebindを出したかを別に残すべきだ。現在値だけでは、自然満了、明示撤回、packet loss、oscillationを判別できない。

Replyがあっても長さが使えない場合がある

clientはSLAAC addressを作れるだけ短いprefix length hintを送らなければならない。serverからprefixが届いても、SLAACに長すぎれば無視する。より短いprefixなら受け入れ、適切な長さへ分割できる。

最初のPはその結果を保証しない。serverへ届かない、poolが尽きる、policyで拒否される、error statusが返る、lengthやlifetimeが不適切という結果は残る。適切なprefixを得られない場合、clientはP処理を無効にし、利用可能な別方式へfallbackできる。

したがって委任成功のreceiptには、request、length hint、選ばれたserverまたはrelay、Reply、IAPREFIX、preferred/valid lifetime、clientのaccept判断が必要である。RA captureにはそのどれも含まれない。

逆向きの推論も禁じられる。Pはpositive indicatorであり、P付きPIOがないことをPD不在として扱ってはならない。RFC 7084 に基づくCE routerや明示設定されたhostは、招待がなくてもPDを実行できる。signalの不在はserviceの不在ではない。

Relayがleaseをforwardingへ投影する

RFC 9663のmodelでは、serverがprefixをdelegationし、first-hop routerがclientのlink-local addressをnext hopとするrouteをinstallする。infrastructureから見るprefixはoff-linkである。clientが多数のglobal addressを作っても、routerは各addressのNeighbor Cacheではなく端末単位のrouteを持てる。

この投影はPにも、遠隔serverにも自動ではない。RFC 8987 はdelegating relayに、leaseとnext hopの追跡、local route、ingress filter、lifetimeに応じた保持と削除、運用表示を求める。clientがReplyを受けたことはroute installの証明ではない。1台のrouterにrouteがあることは冗長peerの状態を証明しない。RIB entryはdata-plane deliveryの証明でもない。

clientにもrouting obligationがある。delegated prefixは取得interface上でoff-linkなので、そのprefix宛てpacketを同じinterfaceへ送り返してはならない。loop防止にはhigh-metric discard routeも使える。prefixから作ったaddressは、RFC 6724 のsource selectionで受信interfaceに結び付けるべきだ。

multihomingでは、Replyを提供したserverまたはrelayのlink-local addressとの関連も保存する。redundant systemから同じprefixを受けるなら複数の関連があり得る。RFC 8028 はsource prefixとfirst-hop routerの整合が必要な理由を示す。正しいprefixを誤ったupstreamへ出せば通信は失敗する。

証拠chainは、RA、P-list、DHCP request、accepted Reply、lease、relay binding、route、filter、address形成、source選択、first hop、packet delivery、application完了となる。隣り合う状態は関係するが、権限を共有しない。

同じlinkの相手もoff-linkになる

端末ごとのunique prefixを使うと、同じbroadcast domainにいる別clientのglobal addressもoff-linkになる。packetはまずdefault routerへ向かい、ICMPv6 Redirectによって直接pathへ変わる場合がある。RFC 9762はlocal policyが禁じない限りRedirect処理を勧める。対応しないhostやrouterではlocal communicationのlatencyが増え得る。

Internet向けのpingだけではこの挙動を検証できない。外向きは成功しても、peer-to-peer、service discovery、lateral policyが予期せぬpathを通ることがある。受入試験はoff-linkとsame-link、往路と復路を分ける必要がある。

resource trade-offも変わる。RFC 9663はprefix poolと端末単位routeを多く使う代わりに、address単位ND stateを減らし、端末の複数addressを一つの運命へまとめる。大規模Wi-Fiには有利でも、上流から小さなprefixしか得ていない家庭では/64不足を招く。Pはこのmodelを望むと伝えるだけで、capacity planを証明しない。

IANA registryは送信者を認証しない

IANAのIPv6 Neighbor Discovery PIO Flags registry はbit 3をPとして登録する。wire formatの衝突を防ぐが、access portでRAを送ったrouterの権限は証明しない。

RFC 6105 のRA-Guardがなければ、local attackerは似たPIOにPを立て、clientにAを無視させられる。利用可能なPD infrastructureがなければaddress取得は失敗または遅延する。RFC 7113 は、RA-Guardという設定名だけではextension headerやfragmentを用いた回避が閉じていると証明できないことを示す。

DHCP側は別境界である。RFC 7610 のDHCPv6-Shieldがなければrogue serverが不正なprefixや設定を返し得る。RAとDHCPを同じ組織が運用しても、protocol上は別のsender、message、decisionである。RAへの信頼がReplyへ自動継承されることはない。

Pのset/clear反復はlist変更とREBINDを増やす。RFC 8415のrate limitはclient送信量を抑えるが、infrastructure負荷やservice impactがゼロとは証明しない。input、transition、downstream workを別々に測るべきだ。

小さな権限だから進化できる

Pが全chainを証明しないのは欠陥ではない。最初の選択順序だけを共通化し、allocation、routing、filter、fallback、deliveryはそれぞれのownerに残す設計である。

Heng Luの最小初期仕様とローカルな将来判断は、この薄い共通面の価値を説明する。running codeの優位に従えば、設定ではなく実行状態を検証する。さらにreality layerを分ければ、standard、packet、lease、route、user outcomeを一つの「対応済み」に潰さずに済む。

Pの意味を守るには、主張もPと同じ大きさに保つ必要がある。