要約

  • RFC 6164 は RFC 3627 の分析を誤りとは呼ばず、運用経験によって /127 が利用可能だと分かったと記した。そのうえで、ルータ二台だけのポイントツーポイントという狭い互換性領域を定義した。
  • 改訂後も、実際の媒体、両端の実装、Subnet-Router anycast の停止、予約値の回避を確認しなければならない。文書の地位は現在の案内を変えるが、現場の状態を生成しない。

八年間が追加したもの

RFC 3627 の議論は机上の恐怖ではなかった。/127 には二つのアドレスしかない。一方のルータが末尾一の値を使い、同時に末尾ゼロを Subnet-Router anycast として引き受けると、他方がゼロをユニキャストとして設定した際に重複アドレス検出で拒否され得る。二者用の空間に、個別の宛先と集合的な宛先が重なった。

文書自身、二台のルータしかないリンクでその anycast が役立つかは疑わしいと述べている。また、問題が広く観測されていないのは、実装が普及していないからかもしれないとも認めた。それでも当時のアーキテクチャはサポートを求めていた。運用者が全装置の暗黙の例外を保証できない以上、/64 や /126 などを選ぶ警告には合理性があった。

2011年に RFC 6164 が加えたのは、反対票ではない。先行分析は正しいと明記しながら、IPv6 の運用経験は /127 を成功裏に使えることを示した、と続けた。経験は衝突を否定したのではなく、衝突を除去できる条件と、別の障害がより重要になる場面を明らかにした。

新しい例外は小さく作られた

対象は、ルータ同士を結び、参加者がルータ二台だけで、ホストがいないリンクである。Ethernet でもポイントツーポイントとして設定されていれば対象になり得る。ルータとホストの接続、ルータとホストが混在する区間、リンクローカルのアドレス範囲は対象外だ。

番号を付ける理由も具体的である。監視、逆引き DNS、traceroute の解釈、管理、EBGP セッションなど、グローバルまたは明示的なインターフェースアドレスを必要とする運用がある。リンクローカルだけにすれば攻撃面が減る場合もあるが、診断と管理の便益は同じではない。

この範囲内で、RFC 6164 は二つの MUST を組み合わせた。ルータは /127 の割り当てをサポートしなければならない。同時に、そのプレフィクスでは Subnet-Router anycast を無効にしなければならない。後者がなければ、2003年に示された衝突は残る。

さらに、親の /64 から多数の /127 を切り出すとき、下位64ビットがすべてゼロのアドレスや、予約済み subnet anycast に当たる最上位128個の値はユニキャストに使うべきではない。例外は隣接する意味まで消去しない。

広い空白は受動的ではなかった

運用経験が重く見たのは、節約だけではない。Ethernet のルータ間リンクに /64 を置くと、未割り当ての on-link 宛先が膨大に残る。そこへパケットが来るたび、ルータは INCOMPLETE の近隣キャッシュを作り、Neighbor Solicitation を送り、再送タイマーを持つことがある。

RFC 6164 は、二つのルータと Subnet-Router anycast を除いても 2^64 - 3 の未割り当て値があると説明する。攻撃者はアドレスを所有する必要がない。応答しない宛先を次々に選ぶだけで、メモリと CPU に仕事を発生させられる。レート制御とガベージコレクションは影響を抑えても、圧力の間に正当な BGP セッションが相手のリンク層アドレスを再解決できるとは限らない。

また、Neighbor Discovery を使わない一部のポイントツーポイント媒体では、より短いプレフィクス内の未使用宛先へ向かったパケットが両端を往復する恐れがある。RFC 4443 は同じリンクへ送り返すことを禁じ、ICMPv6 Destination Unreachable を推奨する。しかし /127 は余った on-link 宛先そのものをなくし、古い実装の影響も狭める。

新しい判断では、anycast の機能をこの場面で止め、その代わりにキャッシュ枯渇と ping-pong の面を閉じる。危険が消えたのではなく、管理可能な条件の下で順序が変わった。

Historic は記憶喪失ではない

RFC 6547 は2012年、RFC 3627 を Historic に移し、両文書が衝突する場合は Standards Track の RFC 6164 に従うと明示した。これは読者が現行の指針を選ぶための経路情報である。

一方、古い文書の観察は保存される。重複アドレス検出の手順、実装差への懸念、代替案は、新しい MUST がなぜ対になっているかを説明する。ICMPv3 と書かれた参照名を ICMPv6 に直す検証済み erratum も、文書が Historic になったから不要になるわけではない。

技術制度が過去を正直に扱うには、証拠と処方を分ける必要がある。証拠は当時の仕様と推論を示す。処方は現在どの互換性集合を選ぶかを示す。状態ラベルは後者を更新し、前者を焼却しない。

リンクは文書に従った証拠を出せるか

IPAM に /127 が載っていても、実媒体に二台しかいないとは限らない。インターフェースが point-to-point と表示されても、Ethernet サービスや仮想ファブリックが第三者を収容できない証明にはならない。片側の製品仕様だけでは、相手側の anycast や ICMPv6 の挙動も分からない。

必要な証跡は別々である。設計上の参加者、実際に観測した参加者、両端のソフトウェア能力、anycast 無効化、親プールの予約値検査、近隣キャッシュの挙動、ルーティング隣接、FIB、実パケットの結果を順に確認する。隣接が成立した事実は有用だが、将来のトポロジーや転送まで保証しない。

この分離は、標準の力を弱めない。むしろ、標準が本当に決められる範囲を明確にする。共通ルールは判定条件を与え、現場はその条件を満たす証拠を出す。

改訂を成功させた節度

この八年間の成果は、禁止を推奨へ反転したことだけではない。新しい文書が適用範囲を小さく保ち、古い衝突を消す実装条件を置き、新しい攻撃面を説明し、後続文書が権威関係を明示した点にある。

「/127 は危険」という標語を「/127 は安全」に置き換えれば、節度は失われる。安全性はプレフィクス長に宿るのではなく、二台限定の媒体、両端の挙動、アドレス計画と検証の組合せに宿る。

運用実績は古い警告を消さなかった。警告を、新しい判断を説明できる証拠へ変えたのである。

出典