要約

  • AMS-IX はアムステルダムで 2 台のルートサーバーを AS6777 として運用しており、参加には両方とのセッションが必要になる。
  • 仕様が必須としている挙動は NEXT_HOP を無改変で渡すこと一つだけで、AS_PATH と MED の保持は理由付きの推奨事項にとどまる。
  • 公開文書の中で明示された責任配分は、プレフィックスリストの整合性と設定の準拠を参加者に負わせるものだけである。

アムステルダムの交換点でルートサーバーに参加したネットワークは、ピアごとに BGP セッションを建てるのをやめ、他の参加者が広告している内容を再広告する 1 台とのセッションに切り替える。AMS-IX はその 2 台を公開している。rs1.ams-ix.net は 80.249.208.255 と 2001:7f8:1::a500:6777:1、rs2.ams-ix.net は 80.249.209.0 と 2001:7f8:1::a500:6777:2 で、いずれも AS6777 として話す。条件は具体的だ。両方に接続し、セッションごとに広告するプレフィックスの数と長さを一致させ、TCP 179 番を開く。AMS-IX のルートサーバー文書はそれを淡々と列挙している。

その文書がやっていないのは、運用者を対称的な保証の束に縛ることだ。記述されているのは挙動である。列挙されている義務は参加者の側にある。

仕様が譲らない一点

RFC 7947は交換点のルートサーバーを定義しており、最も強い要求はアドレスに関するものだ。「the NEXT_HOP attribute MUST be passed unmodified」（2.2.1 節、2016 年 9 月）。この一文が、ルートサーバーがパケットにとってルーターでない理由を説明している。クライアントが見るネクストホップは、広告したピアのスイッチングファブリック上のアドレスであり、トラフィックはファブリックをピア間で直接渡り、BGP を代弁した機械を通らない。同月の運用文書である RFC 7948も同じ線を引く。到達性情報の配布はトラフィックの転送ではない。

属性処理の節にあるそれ以外は、意図的に柔らかい。ルートサーバーは中継する経路に「SHOULD NOT prepend its own AS number」——自らの AS 番号を前置きすべきでない（2.2.2.1 節）。MULTI_EXIT_DISC は伝播させ、「SHOULD NOT modify its value」——値を変更すべきでない（2.2.3 節）。2.2 節は属性の透過を既定としつつ、ローカル設定が必要とする場合の例外を明示的に認め、2.1 節はポリシーによるフィルタリングをそのまま許す。

AS_PATH で MUST ではなく SHOULD にとどめた理由も RFC 自身が書いている。経路の先頭 AS が想定外だとセッションを拒否する旧世代クライアントが実在し、必須規則にすればそれらを置き去りにしたからだ。そこで仕様は、より重い保証を引き受ける代わりに、先頭 AS 検査を無効化できることを（できればピア単位で）実装に義務づけた。要求レベルの衣装を着たエンジニアリング上の妥協であり、交換点が経路属性に絶対に触れない義務を負ったと読んでいた人には効く話だ。

運用者が記録に残していること

AMS-IX は取り決めの自分の側を公開している。中継する経路の AS_PATH に AS6777 を挿入せず、該当する箇所では先頭 AS 検査を無効にしなければならない。エクスポート先は RPSL の記述とコミュニティで選ぶ。コミュニティ 0:6777 は全エクスポートを遮断し、6777: は指定したピアを有効にする。新規セッションは既定で IRRDB と RPKI の併用フィルタを通る。学んだ経路は参加者自身とその下流顧客に使えるが、上流・外部ピア・他の交換点のルートサーバーへの再配布は禁止されている。

その文章には二度読みたい記述がある。一つは、IRRDB と RPKI のデータには有効性の保証がなく、単独で頼るべきではないという注意である。運用者自身による、既定のフィルタリングの説明だ。もう一つは責任条項である。「Participants are responsible for ensuring that their routing configuration complies with this policy.」

RFC 7948 はもっと早く同じ配分に着地していた。クライアントには、宣言したプレフィックスリストが実際に広告する内容と整合することを確かめる責任があるとし（4.3 節）、運用者側のリーク緩和を勧め、クライアント単位の受信フィルタがある場合には受信経路と設定済みリストの自動比較を求めている。文書が描く役割は後見ではなく行政である。ルートサーバーは濾過し、選択し、再広告する。運用者は自分のしたことを公開する。そして誰も、個々の参加者に対する検証義務を箇条書きで引き受けてはいない。

期待していたものと、書いてあること

私が探していたのは文書化された取引だった。各メンバーへのセッション一本と引き換えに、交換点があなたに対して負うものの一覧が公開されている、という取引である。文書が支えているのは前半だけだ。取引は実在する。セッション数は本当に崩れる。ただしその対価はサービス水準ではなく露出で支払われる。無条件の MUST がパケットを共有装置の外に保つ。二つの SHOULD、互換性の理由、そしてローカル設定への出口が、経路選択と MED について運用者の手を自由にしておく。

したがって有用な読み方は「AMS-IX のルートサーバーはずさんだ」ではない。これは権限を限定された管理者として設計されている、という読み方だ。制御プレーンの判断は許され、パケットの転送は一つも許されず、説明責任は主に公開テキストで果たされる。この枠組みは私のものであり、IETF のものでも交換点のものでもない。どんな公式見解もそう述べてはいない。

参加者が実際に確かめられること

このルートサーバーのディレクトリ項目は同じ公開事実を一箇所に集めているが、検証の問題はそこから漏れている部分にある。参加者は方針ページを読んで共有装置の内部準拠を監査することはできない。できるのは、自分が受け取る経路を読み、見えているネクストホップがルートサーバーではなくピアであることを確かめることだ。0:6777 と 6777: が文書どおりのエクスポート挙動を生むか観察できる。両方のセッションを維持し、各サーバーが何を送るかを突き合わせれば、差異は謎ではなく差異として現れる。

当該文書は公開版に日付がなく、2026 年 11 月 12 日に取得したもので、掲載時点での有効性は確認できていない。実際の挙動はここでは試験していないし、既定のフィルタリングとコミュニティによるエクスポート制御が rs1 と rs2 で同一に働くかは、確認した範囲のページからは確定しない。明示的な責任記述はプレフィックスリストの整合性に関するものが一つ見つかっただけであり、そのページに広範な運用者保証がないことは当該ページについての観察であって、他所にそうした文書が存在しない証拠ではない。

取引の正直な要約

ルートサーバーは喋るが運ばない。文書もその形をしている。無条件の約束が一つ、トラフィックを装置の外に保つ。条件付きの約束が二つ、トラフィックを導く属性について交換点の手を自由にしておく。それ以上の安心を必要とするネットワークは、方針文書の中には見つけられない。見つかるか見つからないかは、自分の受信経路の中である。文書が責任の所在として既に指しているのは、まさにそこだ。