要約

  • RFC 8654ではreceiverが最大65,535 octetsを扱えると宣言する。OPENとKEEPALIVEは例外で、senderはpeerからcapabilityを受け取った後だけ大きなmessageを送れる。
  • 約束はそのsessionで終わる。4,096-octet peer向けにはRFC 7606で許されたattributeだけをdiscardでき、なお収まらなければ送信せず、既存routeをwithdrawする。
  • 安全な導入はexternal依存の前にiBGPを統一し、encoded sizeと資源を計測し、rollback用のlegacy-fit表現を残す。

Ingressの両端にcapability code 6が表示され、大きなUPDATEはRIBへ入った。だが別のegressではpeerが能力を宣言していない。Attribute set自体が旧上限を超え、prefixを分割しても収まらない。Local successをpath-wide guaranteeと誤認した結果である。

RFC 4271は二-octet Length fieldを持ちながら、messageを19〜4,096に制限する。RFC 8654は交渉したsessionで65,535まで拡張し、code 6、length 0のcapabilityを定義する。意味は「このsessionで大きなmessageを受信・処理できる」であり、Internet全体の性質ではない。

方向性が重要だ。Speakerは相手からcapabilityを受信した場合だけExtended Messageを送れる。RFC 5492はcapability利用をsession合意として扱い、operatorは不足を理由にsessionを拒否することもできる。実装が機能を持っていてもadvertiseしなかったなら、隠れた寛容さで受理してはならない。

OPENとKEEPALIVEは拡張対象外である。RFC 9072はOPEN Optional Parametersの255-octet制限をtype 255と二-octet lengthで広げる別仕様だ。大きなOPEN capability containerは、大きなUPDATEの権限を証明しない。

上限はpacking目標ではない

ADD-PATHはNLRIごとに四-octet Path Identifierを加え、Large Communityは一値十二-octetである。VPN等の属性もbyteを使う。しかしそれらはpaddingではない。Export policyやcandidate identityに必要な意味を持つ。

Attributesが小さければNLRIを複数UPDATEへ分けられる。Attribute block単独で4,096を超えれば、prefix分割は無効だ。TCP segmentationもBGP semanticsを分割しない。Receiverは一つのheader lengthを検証する。

Legacy egressで許される縮小は、RFC 7606のattribute discard対象だけである。Route selectionやinstallationに影響するattributeを削除できず、local policyが参照する場合も危険だ。なお大きければ広告せず、過去に広告したNLRIをwithdrawする。意味を欠いたrouteより明示的な不在を選ぶ。

その結果、同じrouteが一方のborderにあり他方にない、route reflectorsごとにexternal viewが違う、failover時にbackupだけ送れない、といった非対称が起きる。RFC 8654が関連iBGP speakersの統一を求める理由である。

Parserの責任も拡大する

65,535受信の約束はbuffer、queue、parse、validation、policy、logへ及ぶ。RFC 8654はresource exhaustionを明示する。複数legacy peer向けのreformatもCPUを使う。Authenticated peerでもvalidで高価なmessageを送れる。

FRRoutingはRFC 8654をsupported RFCとして列挙し、BIRD 3.3.0はenableとrequireを分離する。これは実装claimであり、production negotiationやheadroomの証明ではない。

証拠はsession epochに結び付ける。Local/received capabilities、peer、AFI/SAFI、running build、inbound/outbound encoded length、attribute length、NLRI countを残す。結果をrepack、discard、suppress、withdraw、Bad Message Length、policy rejectに分ける。

UPDATE受信はFIBやpacketを証明しない。Selection、recursive resolution、ASIC programming、measured trafficまで照合して初めてcontinuity claimになる。