要約

  • IESGは2026年9月17日、SAVNETのドメイン間送信元アドレス検証に関する問題整理の第21版について最終意見募集を始めた。締め切りは10月1日で、現時点では情報提供型RFCを目指すInternet-Draftである。
  • 草案は正当な通信の誤遮断と、偽装した送信元の誤通過を別々に扱う。第6節は、SAV表を使う境界ルーターだけでは自分の誤りを把握できないと指摘する。
  • 影響を受けた下流網やピアからの連絡が調査の端緒になる。連絡と表の修正を結ぶ記録は本稿の提案であり、IETFが定めた共通様式ではない。

送信元アドレスの検証では、入り口のインターフェースとアドレスの組み合わせに対し、ルーターが局所的な許否を出す。しかしその表が参照できなかった正当な経路まで、ルーターが知っているわけではない。SAVNET作業部会がIESGへ送った文書の重要性は、フィルターの実行精度だけでなく、判断の材料が欠けたときに誰が誤りを知らせるかという問題を表に出した点にある。今回の動きは新製品の導入発表ではなく、問題分析への最終意見募集だ。

草案は、あるプレフィックスが一部の相手にしか広告されない場合や、送信元専用あるいは直接返送型anycastに使われる場合を説明する。フィルター側のBGP情報に経路が見えないことは、その送信元が不正であることの証明にならない。それでも見えている経路だけから許可表を組み立てれば、正当なパケットを落とし得る。逆に、誤遮断を避けるために到来方向の制約を緩くし過ぎれば、偽装アドレスを通す余地が広がる。

導入範囲も効き目を左右する。ある事業者が自分の境界で検査しても、顧客網の内側で別の送信元が偽装される可能性を、部分導入だけで消すことはできない。文書は今後の仕組みに、誤遮断と誤通過の双方の改善、手作業に頼り過ぎない表の更新、早期導入者にも得られる効果、専用情報の保護、変更後の速やかな収束を求める。これらは将来の方式への要件であり、実網で達成した性能値ではない。

第6節の論点はさらに実務的だ。境界ルーターは、自分が参照したSAV表と処理結果を示せても、その処理が誤っていたかを内在的に判断できない。通信に支障が出た下流事業者やピアからの申告を受けて初めて調べられる場合がある。申告だけでフィルターの過失が確定するわけではないが、装置内のログだけで申告を退けることもできない。時刻、接続先、入力情報、表の版を突き合わせる作業が必要になる。

Daniel Kadeとして提案したいのは、調査の範囲を絞った記録である。対象インターフェースと隣接関係、申し立てられた送信元プレフィックス、当時の表と入力の版、申告を受けた時刻、判断した担当者、変更または維持した理由、再確認の結果を一続きに残す。パケット内容や商業上の接続情報を広く共有する必要はなく、必要な相手に必要な範囲だけ渡す。これは草案が必須とした事業者間APIでも、全ての苦情を真実とみなす仕組みでもない。

第21版の日付は7月19日で、9月17日の新たな出来事はIESGによるLast Callの開始である。正式RFCの成立、実装や障害の発生を示す記録ではない。草案が問うているのは、境界で強制力を持つ判断に対し、境界の向こうで見つかった反証をどう戻すかということだ。誤りを受け取る経路がなければ、正確そうに見える局所ルールも、外から見ると訂正不能な壁になりかねない。

出典