Summary

  • 10月28日の IDR 作業部会草案 draft-ietf-idr-rt-derived-community-13 は、Route Target から派生する拡張コミュニティを記述する。Global Administrator と Local Administrator の値を保ち、サブタイプを変える。この草案自体によれば、派生標識は元の RT を特定するだけで、経路の配布を制限したり VRF へ取り込ませたりしない。文書は IESG 審査中の Internet-Draft だ。
  • IANA には既に関連する六つの番号割当てがあり、2021年の先行草案を参照している。新版は参照の更新と追加番号を求める。番号の登録と、その標識を受け取った装置の動作は別々に決める。

十台の装置を一枚の宛先表に押し込まない

草案の例 では、ある VPN に十台のプロバイダーエッジルーターがある。共通の Route Target を付けた経路は、対応する VRF に取り込まれる。ところが別の経路は同じ VPN と関係しつつ、そのうち一部の装置にだけ届けたい。共通 RT を流用すると、全装置への配布を示してしまう。部分集合ごとに新しい RT を作れば、同じ VPN との関係を示す番号がいくつにも割れる。必要なのは新しい宛先表ではなく、関連性だけを示す札だ。

派生拡張コミュニティは RT と管理者の数値を共有し、サブタイプだけを変える。受信側は元の RT をたどれる。だが第2節は、この草案による限り札に配布・取り込みの効力を与えない。RFC 4684 の RT メンバーシップ NLRI に載せることもできず、RT を照合するポリシーも派生札には一致しない。元の鍵の名前を伝えることと、その鍵を使うことは違う。

現行 RFC 4360 が定義する RT は、それを持つ経路を受け取れるルーター群を示す。草案はその数値を借りて VPN との関係を保ち、別のサブタイプで権限の継承を止める。数値が同じだから動作も同じだと決める実装は、まさに区別すべき二つの命令を一つに戻してしまう。

IANA の表は通行許可を配らない

IANA の BGP 拡張コミュニティ登録簿 には、サブタイプ 0x15 の RT-derived-EC と IPv6 用の型 0x0015 が既に載る。草案は既存割当てを六つと数え、参照先を2021年の先行草案から更新するよう求める。さらに EVPN 項目の改名、UUID ベースの IPv6 RT と二種類の Transport Class に対応する追加割当てを要請する。要請中の番号を現在の登録済み番号として数えてはならない。

慣例的な RT 0x02 と派生 0x15 の組も万能ではない。草案は対応関係を表1で確定すると書く。表中には 0x0011 の IPv6 RT と、まだ割当てを求める派生値の組がある。受信機は数値の見覚えではなく、型、サブタイプ、正式な対応表を読む必要がある。

草案は派生札に共通の受信動作を与えない。個別の用途文書が AFI/SAFI、経路の種類、受信後の動作を指定する。札を発行する制度と、その札で何をさせるか決める制度を分けたわけだ。ネットワークで札を見たという事実から経路の取り込みを推定することはできない。

10月28日時点の Datatracker は第13版を IESG Evaluation、目標を Informational とし、IANA 審査を改訂後の再確認待ちと示す。公的資料が示すのは提案と既存の番号であり、実際の経路漏えい事故ではない。最終文書と実装記録が次の確認対象になる。