要点

  • RFC 2260 は、複数 ISP に接続する企業が各 ISP から一つずつプレフィックスを受け、平常時には割り当て元の ISP にだけその到達性を知らせる構成を描いた。
  • 障害時に他方のプレフィックスを注入すればグローバルな経路状態が増え、非直結 EBGP とカプセル化を使えば状態は事業者間の運用へ移る。より良い経路を求めれば、限定的な追加広告が再び必要になる。
  • 文書は方式を記述したのであって、上流による経路受理、アドレスの可搬性、実装、方針整合、経路表の実測改善、世界的到達性を証明してはいない。

一つの企業、一つではないアドレスの系譜

1998 年 1 月に公開された RFC 2260 は Informational 文書であり、インターネット標準ではない。出発点は、信頼性、負荷分散、地理的に良い経路を求めて複数 ISP に接続する企業が増えるほど、デフォルトフリーゾーンに企業単位の経路を恒久的に置く方式は拡張しにくい、という問題設定だった。

そこで企業は、接続する ISP ごとに一つのプロバイダー割り当てプレフィックスを受け取る。N 社に接続すれば N 個である。社内のホストには、最寄りの ISP 接続点に応じたプレフィックスを割り当ててもよく、複数プレフィックスから複数アドレスを持たせてもよい。どのプレフィックスを使うかは、入ってくるトラフィックがどの接続へ向かうかに影響する。

この集約可能性には依存関係が付く。ISP を替えれば、その ISP のブロックから番号を得た部分は再番号付けを要する。プレフィックスが大きなプロバイダー集約に収まることは、企業が契約終了後も同じ番号を持ち運べることを意味しない。RFC 2260 は NAT が番号問題に関係し得ると述べるが、マルチホームでの NAT 自体は扱っていない。

平常時の集約と、障害時だけ現れる経路

平常時の規則は単純である。ISP-A に直結する企業境界ルーターは、A が割り当てた Pref-A だけを A に広告する。B 側は Pref-B だけを B に広告する。各プレフィックスは割り当て元 ISP の集約の内側に残り、企業固有の経路としてインターネット全体へ伝える必要がない。

B 側のインターネット接続が失われたと A 側が判断すると、A 側は Pref-B も ISP-A に広告し始める。追加のより具体的な経路がデフォルトフリーゾーンへ入り、B の集約へ向かっていたトラフィックに別の入口を示す。B が回復すれば追加広告を止める。

その判断には状態が要る。RFC 2260 は、企業境界間の IBGP で受け取る到達可能な経路集合を比較し、共通部分がなくなったときに障害側プレフィックスを注入する例を示した。大きな集合の比較は高価になり得るため、ISP のバックボーンを表す一つ以上のプレフィックスだけを監視し、それが IBGP から消えたら注入する方法も挙げている。

しかし監視対象の消失は、遠隔の全宛先が失われたことの完全な証明ではない。新しい広告も、外部 ISP が受理するとは限らない。文書自身、プレフィックス長によるフィルターがあればインターネット全体の到達性を得られない場合があると認める。広告は意図の記録であり、受理、伝播、最良経路選択、転送、復路、アプリケーション結果は別の記録である。

RFC 2260 は、多数のマルチホーム企業が同時に上流障害を起こす確率は小さいため、平均的な追加経路数は企業総数の一部にとどまると期待した。これは観測値ではなく仮定である。自動注入された経路はデフォルトフリーゾーンの多くのルーターへ変化を伝え、フラップ時には回復した接続が安定するまで広告を保つ必要もある。

世界の表から消した状態は、事業者間に現れる

RFC 2260 の「さらなる改善」は非直結 EBGP を使う。企業境界は直結 ISP のルーターだけでなく、もう一方の企業境界に接続する ISP 内のルーターとも複数ホップ越しに EBGP を張る。各 ISP には、その ISP 自身が企業へ割り当てたプレフィックスだけを広告し、企業側と ISP 側の双方で直結経路を非直結経路より優先する。

非直結経路を使う転送はカプセル化される。B 側の企業接続が切れたとき、Pref-B 宛てのパケットは ISP-B までは通常どおり進み、そこから生きている A 側企業境界へカプセル化される。到着後に取り出され、企業内部へ運ばれる。この構成なら障害のたびに企業固有の追加経路をグローバル表へ出さず、より具体的経路の外部フィルターにも同じ形では依存しない。

代わりに、非直結セッション、直接・非直接の選好、トンネル終端、認証、障害判定、MTU、復路の整合という運用状態が必要になる。RFC 2260 は複数ホップ EBGP に適切なピア認証を求めるが、IBGP と一ホップ EBGP のセキュリティは範囲外とした。文書に方式があることは、二つの ISP が商業的・運用的に合意した証拠ではない。

経路を短くしたければ、可視性を増やす誘惑が戻る

非直結方式は障害時に経路を遠回りさせ得る。平常時でも、各境界が直結 ISP のプレフィックスだけを広告すると、同じ ISP の別顧客から、他方 ISP のプレフィックスを持つ企業ホストへの経路は最適でないことがある。別のプロバイダーのプレフィックスも広告すれば入口を改善できるが、その広告が広がりすぎればグローバル状態が増える。

RFC 2260 は、BGP Community などで伝播範囲を制限し、自動注入と非直結 EBGP を組み合わせる案を示す。ここに交換条件が露出する。広い経路可視性は障害回復や入口選択を改善し得るが、集約を弱める。厳しい集約は表を小さく保つ代わりに、プロバイダー依存の番号、トンネル、調整、または遠回りを受け入れる。

プロバイダー非依存プレフィックスは番号を一つにまとめるが、特定 ISP の集約には収まらない。RFC 2260 は、マルチホーム企業数 N に対してデフォルトフリーゾーンの状態が O(N) になると説明した。一つの ISP のプレフィックスを他の ISP が選択的に運ぶ方式は、代理集約、追加の ISP 間調整、複雑な設定を必要とする。

後の RFC 2519 は、集約が表の規模、処理量、フラップの範囲を抑える理由を整理した。RFC 4116 は RFC 2260 型の PA マルチホームがグローバル表へ追加負荷を与えない基本形を分類する一方、トランスポート層の生存性など全目的を満たさないとした。RFC 8678 も PA 方式で、ホストの送信元選択とルーターの出口選択が必要だと示す。いずれも RFC 2260 の採用や成果を実測した証拠ではない。

情報源と証拠の限界

以下の公式資料は文書の状態、提案された機構、同時代の参照先、後年の公式比較を支える。特定の導入、経路受理、全域伝播、実測された表の縮小、セッション継続、利用者の結果は支えない。