要約

  • RFC 1482の集約レジストリは、プレフィックス、Home AS、Announcing AS、通知先のNeighbor AS、連絡先を分けて記録する構想だった。それは予定された伝播方針であり、稼働中の経路観測ではない。
  • 登録内容は、データベースや生成ツール、ルータ設定を経て初めて動作に近づく。さらに、受信、選択、広告、転送、到達は、それぞれ別の確認を要した。

一行の登録は何度も姿を変えた

RFC 1482は、CIDR集約をNSFNETのPolicy-Based Routing Databaseへ組み込むために、単なる新しい欄以上の変更が必要だと記している。データベース用ツール、報告書、クライアント側パーサ、設定生成手順を改めなければならなかった。

しかも、既存のrcp_routedとGateDでは考え方が異なった。登録票の意味を新しいソフトウェアの構文へ写すだけでも、解釈の境界が生まれる。申請者が送った方針、保存された行、出力された報告、生成された設定、実際に読み込まれた設定は、同じ由来を持っていても同一の物ではない。

この違いは障害時に決定的になる。レジストリが更新済みでも、古いファイルが稼働しているかもしれない。正しい設定が読み込まれても、経路更新が届かないことがある。更新を受け取っても、選択や輸出フィルタで外れることがある。経路が選ばれても、対象アドレスへのパケットが届くとは限らない。

RFC 1482は、登録情報をルータの実況記録として設計したのではない。集約方針を電子的に取得し、調整し、設定へ変換するための材料として設計した。

旧データベースも「期待」と「観測」を分けていた

NSFNETの従来の仕組みでは、あるネットワークについて、どのASから広告を受け取ることを期待するかが登録された。RFCのネットワーク35の例には、主たるAS、二次的なAS、さらに追加のASが並ぶ。

これは受信許可の方針である。特定の時刻に更新が届いたという記録ではない。リストに載ること、実際に広告すること、ルータが受け取ること、最良経路に選ぶこと、転送表へ入れることは別の事象だった。

外向きの方針はannouncetoASで隣接ASごとに記述された。無制限、制限モード、個別の追加、除外、全面停止といった指定が可能である。同じbackboneに接続する二つの隣接ネットワークが、異なる経路集合を見ることは設計上あり得た。

したがって、ある観測点の表が細かいか粗いかだけで、上流が持つ知識全体は分からない。表示された経路は、受信情報と隣接者別方針を通した投影だからである。

Home ASと伝播するASは分けて書かれた

提案されたレジストリでは、一つの集約プレフィックスが複数行に現れる。最初の集約を作るHome ASがあり、同じ集約をさらに隣接者へ広告するAnnouncing ASがある。そして各行に、その広告を受ける予定のNeighbor ASが付く。

作例ではAS 100がHomeであり、AS 690、AS 200、AS 201がそれぞれ別の隣接集合へ同じプレフィックスを伝える。これは重複ではなく、伝播責任の分解である。

AS 200の下流で観測すれば、直近の送り手はAS 200かもしれない。だからといってHomeがAS 200に変わるわけではない。逆にHomeがAS 100だからといって、すべての観測者がAS 100から直接受け取るわけでもない。

後のRFC 1771はBGP-4の属性とAS_PATHを詳しく記述した。直近peerと経路上の先行ASを区別する助けになる。しかし、その後の仕様から1993年の各登録が実際に広告されたと証明することはできない。

直接受信と代理生成は同じプレフィックスを生んだ

CIDR対応の地域ネットワークは、集約プレフィックスを直接NSFNETへ広告できた。そうでない地域ネットワークのためには、backboneが代理で集約する案が示された。

GateDの例では、三つの構成プレフィックスがOR条件で並ぶ。そのどれか一つを聞けば、backboneはより大きな集約を受信したかのように保存し、伝播できた。構文はまだ例示段階だったが、条件は明確だった。一部分の観測が、より広い範囲の広告を起動する。

したがって、遠隔地で集約を見ても、全構成要素の到達性は証明されない。一つ目だけが生きている間に二つ目が撤回され、三つ目が未設定でも、覆う集約が残る可能性がある。

RFCは、集約内の「穴」宛てトラフィックがASを横断した後で捨てられる場合にも触れた。集約は表を短くするが、宛先ごとの配送証明ではない。失敗を消すのではなく、失敗が見える場所を変えることがある。

下流のために明細を復元しなかった

初期導入では、集約を分解してより具体的な経路として外へ広告することはしない、とされた。完全な経路情報が必要なpeerはCIDR対応プロトコルを使う。デフォルト経路を使うpeerは、構成要素の一覧を受け取らなくても集約先へ送信できる。

つまり、下流で見える粒度は交換条件の一部だった。粗い経路しか見えないことは、上流に明細がない証拠ではない。上流に明細があることも、全隣接者に同じ情報を渡した証拠ではない。

RFC 1338とRFC 1519は、アドレス配分と経路集約が必要になった構造的背景を示す。RFC 1786は後に、より豊かなルーティング方針レジストリ表現を示した。いずれもRFC 1482の計画や作例の導入実績を遡って保証する資料ではない。

33パーセントは実測値ではなかった

RFC 1482は、12,348広告のうち4,135を削減できる可能性、すなわち33パーセントを試算した。同時に、それを悲観的アルゴリズムによる楽観的見積もりと呼び、実際の削減量は異なり得るとした。

この数字は導入前後のルータを測った結果ではない。集約可能性を一定の仮定で数えた計画値である。また、直近の表削減と、その後の増加速度やアドレス枯渇は別問題だった。

RFC Editorの情報ページはこの文書をHistoricに分類している。本文は実装が進行中だと述べる一方、計画、議論、デバッグ、安定性、判断アルゴリズム、穴の処理を未解決事項として挙げた。進行中という表現だけでは、どのルータにどの設定が入ったかは分からない。

集約を監査するには来歴を展開する

集約がもたらした規模の利益は、多数の状態を一つの短い表現で扱えることだった。だからこそ、事故を説明するときには、その短い表現を生んだ来歴を展開しなければならない。

プレフィックス境界、構成要素、Home AS、各Announcing AS、隣接者別方針、登録版、生成版、インストール版、受信経路、選択、輸出、転送、到達結果を別々に残す。一行を正しく直すことと、通信を正しく直すことは同じではない。

もし最終の集約だけが残れば、過去のネットワークにそのプレフィックスが見えたことは分かる。しかし誰の意図で、どの変換を通り、どの一要素に起動され、どの穴を隠したのかは失われる。RFC 1482の核心は、圧縮された経路ほど圧縮されていない来歴を必要とした点にある。

出典