要約

  • RFC 1924 は IPv6 アドレスを一つの整数として扱い、85個の印字可能な ASCII 文字で固定長20文字にした。復号可能であることは、既存の人や道具がその表記を認識できることを意味しない。
  • アルファベットから九つの記号を外した設計は、引用、リスト、CIDR、URL、角括弧、エスケープとの共存を意識していた。内側の圧縮率だけでは表記の成否は決まらない。
  • 後の仕様はコロン区切りの16進表記を残し、URI では角括弧を加え、出力だけを正規化した。文字列の一致は比較を助けるが、割当、経路、到達性、主体、配送までは証明しない。

二つの正しい表記が出会えない

障害記録にはコロン区切りの IPv6 アドレスがある。監視装置にも同じ128ビットが残っている。ただし装置は Base85 の20文字で出力した。担当者が目に見える文字列をそのまま検索すると、結果はゼロになる。復号器の中では一致し、調査の表面では一致しない。

RFC 1924 は1996年4月1日に Informational として公開され、Internet Standard を定めるものではなかった。アドレス全体を符号なし整数とみなし、85進数で表現する提案である。例では 1080:0:0:0:8:800:200C:417A が 4)+k&C#VzJ4br>0wv%Yp になる。先頭のゼロも20桁の中に保持される。

変換に情報落ちはない。だが、その事実が保証するのは正しい実装が元の値を再構成できることだけだ。ログの索引、表計算の重複判定、図面の目視確認、シェルや URI の解析、運用者の経験は別の契約に従っている。

85は冗談ではなく境界値だった

IPv6 の値は (2^{128}) 通りある。84進数を20桁並べても全域を覆えず、85進数なら覆える。すなわち (84^{20} < 2^{128} \leq 85^{20}) である。94進や95進に増やしても必要な桁数は20のままなので、九つの印字可能文字を別の用途に残せた。

固定長には実利がある。保存欄の幅が決まり、先頭ゼロが消えず、16進表記のゼロ圧縮による揺れもない。すべての参加者が同じ復号器を持ち、外側が値の境界を保証するなら、簡潔で完全な表現になる。

ところが RFC が外した九文字は、外側の重要性そのものだった。二種類の引用符、コンマ、ピリオド、スラッシュ、コロン、左右の角括弧、バックスラッシュは、引用、列挙、文末、CIDR、URL、リテラルの境界、エスケープに使われる。アドレスは単独で運ばれず、別の文法の中で見つけてもらわなければならない。

見慣れた形にも表記揺れがあった

初期の IPv6 アドレス仕様は、16ビットずつ八つの16進グループをコロンで区切った。各グループの先頭ゼロを省き、一つの連続したゼログループを :: にし、末尾を IPv4 の10進表記にすることもできた。同じ値に複数の合法表記が生まれる一方、コロンとグループは IPv6 らしい輪郭を保った。

この輪郭は人間には有益だが、表記揺れは機械的な照合を壊す。検索語とログが別の省略を選べば見つからない。Whois、表計算、構成図、監査資料が、値は同じなのに別物のように見える。Base85 は揺れを固定長で消す代わりに、全員へ新しい識字能力を要求した。

URI の問題に対する後年の処方は、もっと局所的だった。IPv6 内部のコロンと URL 外部の構文が衝突するため、RFC 2732 はリテラルを角括弧で囲んだ。最小限の編集でコピー＆ペーストできることを目標に掲げ、IPv6 対応版の Internet Explorer、Mozilla、Lynx での実装も記録した。RFC 3986 はその IP-literal の場所を引き継いだ。

入力を広く、出力を一つにする

RFC 4291 は柔軟な16進表記を維持した。そこで RFC 5952 は、複数の合法表記が検索、テキストファイル、表計算、Whois、図、ログ、監査、検証に起こす問題を整理し、読み取りと書き出しを分けた。

パーサーは RFC 4291 の合法な入力をすべて受け入れる。一方、出力では各グループの先頭ゼロを除き、小文字を使い、最長の連続ゼロを :: にし、同長なら先の列を選び、単独のゼログループには :: を使わない。入力互換性は維持しながら、保存される証拠を一つの形へ寄せる設計である。

この方法は最小文字数の競争ではない。同じ値を独立した二つの装置が書いたとき、同じ検索語で見つかる可能性を高める。角括弧は外部の境界を、正規化は内部の比較を受け持つ。

証拠には六つの段差がある

元の128ビット、パース後の値、正規化表示、実際に保存されたログ文字列、検索の命中、観測されたネットワーク結果。この六段を一気に上ることはできない。同じ値に復号できる二表記は数値的に等しい。同じ正規形はフォーマッターの合意を示す。ログ行はある部品が文字列を記録したことを示す。

しかし、どれもアドレスの割当先、経路起点の権限、ライブ経路、インターフェースの到達性、サービスの認証済み主体、パケット配送を証明しない。正規化は証拠を探しやすくする技術であって、証拠の意味を増やす技術ではない。

一次資料の流れは RFC 1884、RFC 1924、RFC 2732、RFC 3986、RFC 4291、RFC 5952 で確認できる。これらは Base85 の実装が皆無だったという調査結果でも、後続文書が正式に否決したという記録でもない。

Running-Code Primacy は、実際のパーサー、ログ、作業手順が何を受け入れ保存したかを後世から問う枠組みになる。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption は、小さな共通仕様と局所的な選択の両立を考える助けになる。いずれも当時の RFC 著者の意図を示す史料ではない。

RFC 1924 は、アドレスの長さを20文字まで削った。削れなかったのは、共有された証拠に至るまでの人間と道具の距離だった。