要約

  • RFC 8950は、IPv4およびVPN-IPv4の到達性をIPv6 next hopで広告できるようにする。Capability code 5が示すのは、NLRI AFI、NLRI SAFI、next-hop AFIの特定tupleへの対応であり、address familyの有効化でもnext hopの到達性証明でもない。
  • 受信側はnext-hop lengthから型を判断する。Route reflectorは受け取ったencodingを変えてはならず、それを扱う能力を示さないclientへNLRIを配布できない。
  • 安全な移行は、両OPEN、正確なMP_REACH_NLRI、import結果、IPv6再帰解決、選択経路、FIB、adjacencyまたはtunnel、実際のIPv4 packetまでを別々に立証する。緑のsessionは出発点にすぎない。

午前1時40分、集約拠点がtransport coreを一つのIPv6 underlayへ移す。顧客サービスとprefixはIPv4のままだ。変わるのはcore内で出口を指す座標であり、すべてのtransport linkにIPv4とIPv6の二組を持つ必要を減らしたいという判断だった。

二台のroute reflectorと多くのclientは対応済みである。交換したばかりのclientはOPENでIPv4 unicastのMultiprotocol capabilityとExtended Next Hop Encodingを広告する。旧clientは前者だけを広告する。どちらのsessionもEstablishedになる。

新clientはIPv4 routeを受け、BGP best pathも選ぶ。しかしresolverがmanagement VRFを参照し、同じIPv6 addressを別interfaceへ解決したためtrafficは落ちる。旧clientにはrouteが届かない。Reflectorには、未対応clientのためにIPv6 next hopをIPv4へ翻訳する権限がないからだ。

Peer healthだけを見れば二台とも正常であり、reflectorだけを見ればIPv4 tableはそろっている。どちらの表示もservice outcomeを証明しない。この例は架空だが、各境界はRFCにある。

Destinationとnext hopは別の問いに答える

NLRIは「どのdestinationが到達可能か」を表す。Next hopは「その到達性を使うため、受信側がどのaddressへ再帰しforwardすべきか」を表す。両者が同じaddress familyであることは多いが、MP-BGPの構造上、同一でなければならないわけではない。

MP_REACH_NLRIにはAFI、SAFI、next-hop length、next-hop bytes、NLRIが入る。RFC 4760がその容器を定義した。従来のIPv4系AFI/SAFIはIPv4型next hopを想定しており、IPv4 serviceをIPv6-only coreで運ぶ場合に不足が生じた。

RFC 8950が広げたのは許容される組合せである。AFI 1のNLRIは依然IPv4であり、指定されたSAFIについてnext-hop AFI 2、すなわちIPv6を使える。顧客addressが変換されたのでも、IPv4責任が消えたのでもない。到達先と、そこへ向かうtransport anchorの型を分けただけである。

この狭さが導入自由を守る。Operatorは一つのdomain、選んだpeer、特定service familyだけで採用できる。未採用者がinvalidになることはない。異なるcompatibility setに残るだけだ。RFCは共通wire ruleを与えるが、誰をいつ移行させるかは決めない。

「IPv6-only core」という名称にも同じ境界が必要である。Underlayの重複addressやIGP stateを減らせても、IPv4顧客、契約、address resource、support、障害責任は残る。一つのlayerの設計名をproduct全体の消滅宣言にしてはならない。

Capability 5は正確なtupleを約束する

Extended Next Hop Encodingはcapability code 5である。そのvalueは、NLRI AFI、NLRI SAFI、next-hop AFIを各二octetで並べた六octetのtupleからなる。RFC 8950の組合せはNLRI AFI 1、SAFI 1、2、4、128または129、next-hop AFI 2である。

IPv4 unicast対応からVPN-IPv4やlabeled unicast対応を推定できない。Release、line card、address familyごとに実装範囲が違うこともある。管理画面の一つのextended-nexthop=trueでは、何が合意されたかが失われる。

Code 5はMultiprotocol capabilityでもない。前者は、すでに利用可能なfamilyについて別familyのnext-hop encodingを理解するという宣言である。AFI/SAFIそのものをpeer間で利用できるかは、RFC 4760のMultiprotocol capabilityが別に決める。

OPEN evidenceには二列必要になる。対象AFI/SAFIが双方でnegotiatedか。受信側が正確なextended-next-hop tupleを広告したか。SessionがEstablishedでも、そのどちらかは欠け得る。Senderは後者を確認して初めてIPv6 next hop付きIPv4 NLRIを送れる。

これはMinimum Initial Specificationの良い例である。共通層はcodeとdeterministic tupleだけを持ち、中央のmigration authorityを作らない。Tupleがなければ、そのpeerへそのencodingを送らない。リスクを負うendpointがlocal evidenceでcompatibilityを選ぶ。

Inventoryもdevice model単位では不十分だ。BGP instance、peer address、software/hardware version、session epoch、双方のAFI/SAFI、送受信した全tupleを残す必要がある。「RFC 8950対応製品」は調達情報であって、稼働sessionの証拠ではない。

Lengthは型情報である

AFI 1、SAFI 1、2、4では、IPv6 next hopは16または32 octetである。16は一つのIPv6 address、32はRFC 2545に従ってglobal addressとlink-local addressを並べ得る。

SAFI 128または129のVPN-IPv4では24または48 octetになる。各next hopは、八octetのRDをゼロにしたVPN-IPv6形式で表す。RFC 8950はRFC 5549のVPN encodingを、すでに相互運用していた実装と整合させ、erratumを処理した。

Receiverは、そのAFI/SAFIに許されたlengthからnext-hop protocolを判断しなければならない。Lengthは単なるdisplay widthではなくtype systemである。Telemetryやpolicy engineがuntyped stringへ正規化すれば、正しい意味で処理したことを後から検証できない。

Globalとlink-localにも別のscopeがある。Global addressはrouting tableで再帰できる。Link-localはinterfaceとlocal linkを伴って初めて一意になる。複数interfaceのfe80::1を一つのidentityとしてjoinしてはいけない。

Unnumberedやlink-local eBGPでは、BGP transportとcapabilityが正常でも、FIBはinterface-scoped adjacencyを必要とする。再起動、interface交換、peer-group継承によりaddress文字列は同じでも、有効性を支えたcontextが変わることがある。

VPN encodingのzero RDも、service RDやroute targetが消えたことを意味しない。Next-hop表現とVPN route identityは別のobjectである。

Route reflectorは翻訳装置ではない

Reflectorがnext hopを変更せずに伝える場合、そのencodingを変更してはならない。Clientが扱えなければNLRIを配布できない。IPv6 next hopをIPv4へ置換する行為はformat変換ではなく、新しいforwarding pointを作るrouting decisionだからである。

このruleはclient set全体に影響する。あるclientが生成するencodingを他のclientが共通reflector経由で受ける必要があれば、全員の互換性が必要になる。一台のupgradeが別の旧clientの不足を露呈しても、reflector故障ではない。

Routeが意図的に配布されない状態は誤診されやすい。旧clientはEstablishedで、従来encodingのrouteは受け続ける。Reflector自身のLoc-RIBにもrouteは残る。Prefix countだけでは、clientが自ら示したcapability boundaryを説明できない。

同一epochでorigin clientのUPDATE、reflectorのaccepted route、target clientのOPEN、target向けAdj-RIB-Outを結合する必要がある。Absenceはencoding unsupported for clientと記録すべきで、単なるprefix missingではない。

next-hop-self、route server、confederationでは責任が変わる。Next hop変更が常に禁止なのではない。Unchanged reflectionを翻訳と呼ばず、意図的rewriteを新しい権限行使として扱うべきなのである。

再帰解決でsyntaxがoperationになる

UPDATEを受け入れた後、receiverはIPv6 next hopを解決する。ResolverはtableまたはVRFを選び、IPv6 routeを探し、必要な再帰を行い、adjacencyやtunnelを結び、FIBへ渡す。

各段階は独立に壊れる。IGPにaddressがない、global tableにだけありBGP processはservice tableを見る、再帰先が未解決、neighbor discoveryが失敗、labelやSIDがない、encapsulation後のpacketがMTUを超える、control plane後にline cardが遅れる、といった状態である。

証拠のladderは次のようになる。

  1. Peerが対象MP-BGP familyを広告した。
  2. Peerが正確なextended-next-hop tupleを広告した。
  3. Senderが想定したMP_REACH_NLRIを送った。
  4. Receiverがnext-hop typeを正しく解釈した。
  5. Import policyがrouteを受け入れた。
  6. Decision processが選択または保持した。
  7. IPv6 next hopが意図したcontextで解決した。
  8. FIBがIPv4 destinationを予定のadjacency/tunnelへprogramした。
  9. IPv4 packetが到達し戻った。

一段上の証拠は次段を保証しない。「BGPにrouteがある」は、このdesignには粗すぎる。Dashboardは集約してよいが、どのobservationがどの遷移を証明したかを捨ててはならない。

Rollbackも同様である。IPv4 next hopへ戻すには旧underlay、next-hop-self policy、peer capability、広告順序を復元する必要がある場合がある。Code 5を消すだけでは、旧resolver pathがなければ障害が長引く。

Security policyにもIPv6側の面が増える

RFC 8950はrouteを認証しない。TCP authentication済みpeerも不正routeを送り得る。RPKI origin validationはIPv4 prefixのorigin AS authorizationを検査できるが、IPv6 next hopの安全性や到達性は証明しない。

「IPv4 routeにはIPv4 next hop」という旧前提を持つtoolは、新しいobjectを見落とす。ACLがBGP sessionだけ許可し、IPv6 underlayを観測しない場合もある。Threat detectionがdestinationとnext hopのfamily一致を暗黙に要求すればdiversionを逃す。

RFC 8950は、IPv6 infrastructureを介したtraffic diversionの新しい手段になり得て、hijackingやdenial of serviceを生む可能性を記す。また通常ではないがIPv4-mapped IPv6 next hopもあり得るため、security checkは普通のglobal IPv6と同一視してはならない。

対策はcross-family routeの一律拒否ではなく、authorization objectを広げることである。どのpeerがどのservice familyにIPv6 next hopを出せるか、許されるscope、resolver table、tunnel、依存するIPv4 destinationを明示する。

Transport authentication、GTSM、prefix policy、RPKI、next-hop authorization、underlay security、packet validationは別々のcontrolである。結果を組み合わせても、意味は統合してはいけない。

Canaryは二つのfamilyを通り抜ける

Capabilityを有効にする前に、限定したIPv4 prefixと予定するIPv6 next hopを一つ選び、既存route、FIB、packet path、peer、resolver contextを保存する。Propagation path上の各speakerについて期待tupleを列挙する。

新しいsession epochで双方のOPENをcaptureし、Multiprotocolとcode 5を別に確認する。Local configからremote receiptを推測しない。

UPDATEではAFI 1、対象SAFI、16/32または24/48のlength、正確なIPv6 bytes、NLRIを検査する。Reflectorがあればnext hop preservationと各clientのsupportを証明する。

各receiverでpre-policy、post-policy、selected path、recursive lookup、output table、adjacency/tunnel、FIBを保存する。単にdefault routeで何かへ届くのではなく、予測したIPv6 pathへ向く必要がある。

最後に実際のIPv4 trafficを流す。Source、destination、方向、return path、packet size、route epochを記録する。EncapsulationやMTUが関係するならpingだけでは不十分である。

Canaryをwithdrawし、downstream Adj-RIB-Out、RIB、recursion、FIBのcleanupまで確認する。Version controlに旧configがあることと、旧pathが現在packetを運べることは違う。

RFCはdeterministicな共通言語を定め、vendorが実装し、operatorが採否を決め、running networkが結果を示す。IPv6 coreを通ってもdestinationはIPv4のままである。Capability numberが一致してもforwarding authorityにはならない。Type、policy、recursion、hardware、packetが一致したときだけ、routeはoperation上の事実になる。