要約

  • RFC 8654はOPENとKEEPALIVE以外のBGPメッセージ上限を4,096から65,535オクテットへ引き上げるが、能力コード6を通知したピアにだけ拡張メッセージを送れる。
  • 能力は一つのセッションにおける受信の約束であり、全網への許可ではない。対応が混在すると、属性破棄、UPDATEの保留、または経路撤回が必要になり得る。

大きな封筒は二者間の約束から始まる

RFC 4271の基準は明快だ。BGPメッセージは全体を受信してから処理され、最大長は4,096オクテットである。RFC 8654は新しいアドレスファミリーや機能を収めるため、OPENとKEEPALIVE以外の上限を65,535オクテットへ広げた。

制御点は数字ではなく交渉にある。拡張メッセージを受信できる話者は、RFC 5492の仕組みでその能力を通知することがSHOULDとされる。IANAはこれを能力コード6として登録している。送信者は、そのセッションのピアから能力を受け取った場合に限って拡張メッセージを送ることがMAYである。

通知は実質的な義務を伴う。通知した実装は65,535オクテットまで受信できなければならない（MUST）。逆に、処理能力があっても設定によって能力を通知しなかった話者は拡張メッセージを受け入れてはならない（MUST NOT）。実装能力は設定された境界を上書きしない。

RFC 8654は別の送信境界も定める。この能力を通知していないピアへ送るNOTIFICATIONメッセージは4,096オクテットを超えてはならない（MUST NOT）。

一つの境界の容量は次の境界へ移らない

4,096オクテットを超えるUPDATEが対応ピアから入り、未対応の隣接へ伝播しようとすることがある。最初のセッションは受信を認めただけで、次のセッションには何も許可していない。

RFC 8654は中継話者に、RFC 7606のattribute discardで対象となる属性だけを取り除き、出力を縮小する試みをSHOULDとしている。その属性は経路選択やインストールに影響してはならない。それでも大きすぎる場合、その隣接へUPDATEを送信してはならない（MUST NOT）。NLRIを以前に通知済みなら、そのサービスから撤回しなければならない。

受益者は、大きな属性集合やNLRIを一つの封筒に収めたいアプリケーションである。一方、費用は次の隣接と、4,096オクテット境界を越えられない経路の利用者に及ぶ。表現容量が伝播と到達性の判断へ変わる。

内部整合性は展開責任になる

RFC 8654によれば、AS内部で整合した視界を保証できるのは、すべてのiBGP話者が能力を通知するときだけである。そうでなければ、外部ピアへ通知すべきかを運用者が検討する必要がある。

責任ある順序は、セッションごとの能力棚卸し、最大メッセージの受信・解析試験、バッファ余力の計測、内外すべての境界の特定、そして段階展開中に落ちた経路と破棄属性を監視することだ。その後に外部通知を決める。

RFC 8654はBGP固有の安全問題を解決しない。大きなバッファは意図的または偶発的な資源枯渇への露出を増やし得る。能力受信は経路の正当性や内容の安全性を証明せず、宣言された受信容量だけを示す。

証拠と限界

RFC 8654がサイズ、例外、交渉、混在境界を定義し、RFC 4271が元の上限を示す。RFC 5492は能力通知、RFC 7606は属性破棄の境界を定め、IANAがコード6を確認する。

資料は現在どのネットワークが有効化しているか、普遍的なメモリ費用、属性破棄で必ず収まるかを示さない。権力、承認、受益者、費用、反事実は標準から導いた分析である。

出典