要約

  • RFC 3330は散在していたIPv4ブロックを集約し、近い数値でもホスト、送信元、宛先、転送、漏出に関する規則が異なることを可視化した。
  • 2002年の表は歴史的な一時点であり、恒久的な安全判定表ではない。後続RFCと現行IANAレジストリは、より具体的なプレフィックスも考慮する、版管理された多属性の分類を形づくった。

同じアドレス値でも、パケットに許される動作は違う

通常のIPv4アドレスは、公開経路で到達するホストを指し得る。一方、127/8は同じホスト内へ折り返す。10/8、172.16/12、192.168/16はプライベートネットワーク向けで、169.254/16は通常の構成が得られない場合などに単一リンク上で通信する。文書用プレフィックスは例示に使い、198.18/15は性能試験用に確保された。マルチキャストや限定ブロードキャストにも別の動作規則がある。

その違いは32ビットからは読み取れない。プロトコルの定義、割当、ルーティング方針が決める。すべての値を通常の公開宛先として扱うルーターは、ループバックをネットワークへ出してしまうかもしれない。逆に「特殊」というラベルだけで一律に遮断すれば、意図された通信まで止める。分類名と実行すべき動作は同じものではない。

RFC 3330以前、こうしたブロックの説明は複数のRFCやパラメータ記録に分かれていた。同文書はそれらをIANAの一覧としてまとめる一方、RIRを通じて事業者や利用者に配られる通常のIPv4空間は対象外だと明記した。一般の割当制度を置き換えたのではなく、少数の例外や特別な指定を見通しやすくしたのである。

「特殊」は一つの真偽値ではない

2002年の文書は主に文章で期待される動作を説明していた。その後、単一の「特殊」フラグでは実装やインシデント調査に足りないことが明確になった。送信元として有効でも宛先として無効な場合がある。外部インターフェース間で転送可能でも、グローバルに到達させるべきとは限らない。他の属性が偽でも、プロトコルが固有の処理を要求する場合もある。

RFC 5735は当時の一覧を置き換え、RFC 6890はIPv4とIPv6の特殊用途アドレスを継続管理するレジストリを定めた。現行の項目は、送信元としての有効性、宛先としての有効性、転送可能性、グローバル到達可能性、プロトコルによる予約を区別する。それぞれ別の問いに答える属性だ。これらを一つにまとめると、境界フィルターに必要な情報を失う。

RFC 8190は「グローバル到達可能」の意味を明確にした。これは管理ドメインの想定に基づく運用上の属性であり、経路広告もパケット漏出も決して起きないという実測保証ではない。公開観測点で「非グローバル」とされたプレフィックスが見つかれば、漏出、フィルター不備、送信元偽装、測定上の誤差などを疑える。観測だけでレジストリ属性が変わるわけではない。

最長一致のプレフィックスも重要だ。広いブロックの内側に、異なる属性を持つより具体的な割当が存在し得る。最初に見つけた包含範囲だけで判定すると、許されない送信元を通したり、正当な通信を捨てたりする。説明可能な判断には、実際に一致した最長プレフィックス、使った属性、参照したレジストリの版を残す必要がある。

一覧に日付が必要なのは、ネットワークが変わるから

RFC 3330には、特殊用途が終わり通常の割当に戻る予定のブロックや、その後に扱いが変わった範囲も記載されていた。それは誤りではなく、当時のネットワークを記録した結果である。危険なのは、2002年のスナップショットをソフトウェアや監査ルールに永久に埋め込むことだ。

後続文書は一覧を更新した。RFC 5737は2002年に記されたTEST-NETだけでなく、文書向けに三つのプレフィックスを確保した。RFC 3927はIPv4リンクローカルの動作を詳述し、RFC 6890は静的な文章から更新可能なレジストリへ移行した。現在の運用判断にはIANAのIPv4特殊用途アドレスレジストリが参照点となり、RFC 3330は一覧形成の歴史資料として残る。

日付は過去にも未来にも関わる。後年追加された属性を2002年の運用者へ遡って適用してはならない。逆に、古いRFCだけで今日のパケットを分類することもできない。インシデント報告では観測時刻、レジストリの版または取得済みスナップショット、正確なプレフィックス、パケット方向、インターフェース、判断に使った属性を記録する。

特殊用途の割当手続きも、技術要件と一般のアドレス政策を分けていた。標準化プロセスでIPv4ブロックを必要とするRFCは、サイズやプレフィックス長など技術的条件を記述する。IANAはRIRと相談し、公開直前に必要な割当を行う。RFC 3330が記録したのは運用慣行であり、すべての実験に恒久予約を与えたり、新たな一般割当ルールを作ったりしたのではない。

レジストリ項目は自分でパケットを止めない

レジストリは意図を表現し、ホスト、ルーター、ファイアウォール、ライブラリ、監査ツールにデータを提供する。しかし、機器を自動更新したり、ネットワーク境界でポリシーを強制したりはしない。登録上の属性と観測された動作の間には、独立した運用上の隔たりがある。

外部インターフェースでプライベート送信元のパケットが見つかるのは、偽装、設定ミス、カプセル化された経路などが原因かもしれない。ソフトウェアがローカル慣行としてループバックをログに使うこともある。コピーされたサンプル設定が文書用アドレスを本番に残したり、ベンチマーク通信が通常のテレメトリーに混入したりする。いずれも、アドレス値だけでは生成地点や装置の判断はわからない。

パケットの方向、入力・出力インターフェース、カプセル化、変換の状態、最長一致するレジストリ項目、フィルターが実際に取った動作を保存するべきだ。キャプチャは特定の場所で特定のビットが観測された証拠だが、生成場所の証明そのものではない。「グローバルに到達可能でない」ことも、「公開観測点に一度も現れない」ことを意味しない。

RFC 3330が示した歴史的転換は、IPv4空間が割当番号の連続ではなく、文書化された運用例外を持つ共有空間でもあるという認識だった。今に残る教訓は著名なプレフィックスの暗記ではない。数値、割当の種類、実行されたルール、観測結果を別々に扱うことだ。四つの記録を混同すれば、便利な一覧が起源や到達性の誤った証明書になる。

出典