要約

  • RFC 1888 は四つの任意互換方式を定義する前に、既存の OSI 計画を IPv6 用にネイティブ設計し直すことを推奨した。
  • 可逆変換でも、複数リンクにまたがる Area、異種プレフィックスの非集約性、ホスト単位 NSAP とインターフェース単位 IPv6 の違いは解消しない。
  • RFC 4048 は未使用とみられた方式と逆方向の二つの仕様誤りを分離し、RFC 4548 は後者の狭い名前空間だけを修正した。

受信側の判断はアドレス式に書き込めない

1996 年 8 月の RFC 1888 は Experimental 文書であり、Internet Standard ではない。その最初の助言は、互換方式を使うことですらなかった。OSI NSAP 計画を持つ組織は、可能ならローカルトポロジーを明示的に再配置し、ネイティブな IPv6 計画を作るべきだとした。

理由は三つある。OSI/IS-IS の Area は複数の物理リンクにまたがり得るが、IPv6 のサブネットは一つのリンクを前提とする。Area 番号をそのままサブネット番号にしても、同一リンク上の隣接性は生まれない。

次に、広域ルーティングの集約には共通プレフィックスが要る。通常の IPv6 と制限付き NSAPA 由来アドレスは、同じ移行計画に属するだけでは一つに集約できない。個々の値を完全に復元できても、経路表は増え得る。

さらに、OSI の複数 NSAP はインターフェースを越えて一つの終端システムを表し得たのに対し、IPv6 アドレスは各インターフェースに付く。ホストの識別子を移しても、最後のリンクは選ばれない。ES-IS や IS-IS の移行も RFC の対象外であり、制御プレーンはアドレスと一緒には運ばれなかった。

同じ互換という名の四つの経路

第一方式は 0x02 で始まる十六オクテットの IPv6 アドレスに、制限付き ICD/DCC 形式 NSAPA を収めた。対象範囲ではアルゴリズム的に可逆だったが、文書自身が非効率なルーティングを警告し、一つの Area に複数の物理サブネットがある場合は追加機構が必要だとした。

第二方式は 0x03 で NSAPA を切り詰めた。残った階層で Area 付近までは運べても、完全な宛先は NSAPA destination option またはカプセル化 CLNP パケットで補わなければならない。受信側は転送、デカプセル化、破棄を選ぶ。自動的な最終発見は仕様外で、静的対応表や将来の ES-IS 類似機構が候補として残っただけだった。

障害通知もこの切断の影響を受けた。通常の自動設定や発見はそのまま使えず、完全な NSAPA は IPv6 routing header に入らない。切り詰められた送信元へ返された ICMP エラーが、本当の送信元に届かず破棄される可能性もあった。互換機構が、故障を説明する証拠まで切り詰めるのである。

第三方式は通常の IPv6 アドレスを使い、完全な送信元または宛先 NSAPA option を受信側へ渡す。機能を使わないノードには実装義務がない。従って option の存在は送信の証拠にすぎず、解釈や有効化、処理結果の証拠ではない。

第四方式は逆に、IANA AFI 35 の二十オクテット NSAPA 内に IPv6 を配置し、ICP 0 を用いた。再帰的な埋め込みは RFC 1326 に関連する異常やループを招くため禁止された。RFC 1629 は ATM 上の NSAP、RFC 3513 は後の IPv6 アドレス体系の文脈を与えるが、RFC 1888 の稼働証明ではない。

2005 年に分けられた二種類の失敗

RFC 4048 は 2005 年、IETF が知る限り、NSAP を IPv6 に入れる方式は本格的に使われたことがなく、IPv6 実装にも対応されていないと述べた。これは知識範囲を明示した組織的評価であり、あらゆる私的実験の全数調査ではない。それでも Historic 化と、旧プレフィックスを Reserved に戻す根拠になった。

一方、IPv6 を NSAPA に入れる方向には ATM を含む新たな関心があり、section 6 に二つの誤りがあった。ICP は一オクテットではなく十六ビット、つまり二オクテットである。四桁十進 IDI は自由な二進整数ではなく、二オクテットの BCD で表す。

RFC 4548 は 2006 年、この section 6 だけを置き換えた。AFI 35 の下で、十進 ICP 0 は IPv6、1 は IPv4 を表し、2〜9999 の割り当てには公開済みの定義形式と IETF consensus が必要となる。現在の IANA OSI NSAPA Numbers registry はその意味を保持するが、実装や通信量を証明しない。

RFC Editor の RFC 1888、RFC 4048、RFC 4548 各情報ページは、状態と置換関係を確認できる。狭い ICP 用途の修正は、制限付き・切り詰め NSAP-in-IPv6 方式の復活ではない。不要と判断された仕組みを退役させながら、なお正当な名前空間だけを正確に残したのである。

証拠は順番に読む必要がある。仕様、可逆変換、登録、パーサー、機能有効化、経路、最終リンク、受信判断、アプリケーション結果、そして独立した利用観測は別々の段階だ。一段下の受領証で、次の段階を済ませることはできない。