要約

  • RFC 1476では、受信した経路は近接性フィルター、メトリックとオプションの更新、集約、アクティブ経路選択、相手別の送信フィルターを順に通る。
  • 未知オプションのクラスは、経路をそのまま伝える、オプションを外す、ローカルに閉じ込める、経路ごと捨てるという別々の結果を生んだが、信頼性や実際の配送は保証しなかった。

受信欄と転送表の間

RFC 1476は、RAPを実験的な距離ベクトル型プロトコルとして提案した。対象は小さなLANから国際通信事業者までと広い。内部と外部を固定した階層で分けるより、管理ポリシーが必要な境界を作るという発想だった。

文書の大きな主張より、途中にある手続き図の方が証拠の読み方をよく示す。ピアから届いた経路は、近接性のフィルターと集約を経て候補データベースへ入る。そこから一部だけがアクティブ経路としてIP転送データベースへ移る。さらに出力フィルターが、どのピアに何を通知するかを決める。静的設定やインターフェース、RIPなどから来る経路も候補に加わる。

RFC Editorの記録が示すのは、1993年6月の文書とExperimentalという位置づけである。稼働中のRAP実装、選ばれた経路、転送されたパケットを示すものではない。

一つ目の判断は、候補を残すか

受信フィルターは、遠すぎる経路や細かすぎる経路を落とせた。資源が少なければ絞り込みを強くできる。全面的な接続性を担うルーターは有限の経路を通したうえで集約するか、それを行うルーターへのデフォルト経路を持つ必要があった。

ここには取り戻せない時間差がある。あとからフィルターを緩めても、以前捨てた通知をピアが再送するとは限らない。設定は「今なら受理できる」と示すだけで、「候補が今ある」とは示さない。再通知、受信前ログ、更新要求のどれかがなければ、失われた入力は戻らない。

二つ目の判断は、理解できない属性の扱い

RAPは距離を増やし、遅延と費用を足し、MTUと帯域幅については経路上の最小値を取る。理解しているポリシーなら、それを理由に経路を捨てることもできた。理解できないオプションにはクラスが付いていた。

クラス0は経路を利用し、伝えるならオプションを変更せず含める。クラス1は経路を利用し伝えるが、そのオプションは外す。クラス2はローカル利用だけを許し、伝えない。クラス3は経路全体を捨てる。全実装が必ず理解すべきなのはヘッダーの距離だけだった。

このクラスは認証ではない。送り手の身元も、値の正しさも、処理の安全性も証明しない。型とクラスは独立しており、同じ型に異なるクラスを使う実装もあり得た。formatを読めれば未知の値をログに出せる場合があるが、表示できることと意味を理解することは別だ。クラス1については、オプションを消しても機密性は得られないと本文が注意している。

IPv6の未知オプションにある動作ビットや、BGPのPartialを扱った既存記事とは焦点が異なる。RAPでは、未知属性への反応が、候補を残すか、ローカルだけで使うか、次の管理境界へ渡すかを変えた。

三種類の「ポリシー」を混ぜない

Source Restrictionは、その経路を使える送信元を表した。転送層にセキュリティフィルターがあるなら、見かけ上優れた経路を選んだパケットが最後に黙って落ちないよう、制限を経路情報へ反映する必要があった。

ただし、その反映はセキュリティ設定の一部を漏らし得る。RFCは認可されたネットワークの方向だけへ慎重に伝えるよう求めた。要件を書いたことは、実装が漏えいを防いだ証拠ではない。

AUPは利用目的について協力を求める印だった。商用トラフィックを避ける例が挙げられ、転送フィルターのような安全障壁ではないと明記された。Publicは、第三者が読める放送型媒体を経路の一部が通るという別の警告だった。送信元の資格、許される用途、媒体の露出は、同じ「制限」ではない。

三つ目の判断で詳細をまとめる

同じピアを通る細かな経路は、より広い経路へ集約できる場合があった。しかしRFC 1476は、可能なものをすべて自動でまとめる設計を採らなかった。特にポリシー属性は集約を妨げ、経路を捨てる理由にもなり得た。

RFC 1338は当時のsupernettingと規模問題を示す。RAPの問いは、状態を減らしたあともポリシー判断に必要な違いが残るか、だった。集約経路だけを見たピアは、その下にあった全候補や属性を復元できない。

四つ目の判断で初めて転送候補になる

集約後の経路は、RIPなど別の仕組みから来た経路と一緒に比較された。ローカルポリシーが属性とオプションの任意の組み合わせを用いて、IP転送データベースへ入れるものを決めた。

RFC 1058はRIPの距離ベクトル方式、RFC 1247はOSPFのリンク状態方式という同時代の基準だった。RAPが両者との共存を想定しても、学習した経路が自動的に採用されるわけではない。

候補データベースの記録はFIBの記録ではない。FIBの記録も、特定パケットの照合、出力インターフェース、相手側の受信をまとめて証明しない。

五つ目の判断で相手ごとの世界ができる

送信フィルターはアクティブ経路の一部だけを選び、ピアごとに異なる集合を作れた。ローカル転送に使う経路が、ある隣接者には見えないこともある。別の経路はオプションを外した姿で伝わる。

送信者には、データグラムフィルターを経路通知へ反映し、ピアがブラックホールへ流さないようにする義務もあった。これは規範であり、実行結果ではない。実効フィルター、送信した通知、受信側の選択、パケット観測をそろえて初めて検証できる。

TCPが応答してもRAPは停止し得る

RAPピアはポート38で対称なTCP接続を一つ使い、個々のコマンドを確認せずに双方向で交換した。PollとNo OperationはRAP層の生存確認を担った。

RFCはTCP keepaliveだけに頼ることを勧めなかった。分かるのは遠隔TCPがデータを受け取ることで、遠隔RAPプロセスが生きていることではない。接続が切れれば、そのピアから得た全経路を消す規則だったが、実際の消去には別のログが要る。

ループ対策も限定的だった。距離上限とTraceを使う最後の手段は、反復する誤りがない場合の「最終的な」解消であって、速い収束の保証ではなかった。

実験仕様から取り出せる境界

姉妹文書の RFC 1475 とその情報記録はTP/IXと転送経路識別子を扱う。前の記事が、その次ホップ固有の識別子とAdd/Purgeの時間差をすでに所有している。本稿はそこを繰り返さず、通知後の五つのローカル判断を対象にする。

RFC 2026の標準化用語を使っても、文書の分類と採用実績は分けなければならない。

これはHeng Luが述べる動作コードの優先、最小の初期仕様と将来判断の局所化、現実の層に沿う読み方でもある。受信通知は判断の入口を示す。後段の採用、転送、再通知、結果の権威までは持たない。

出典