要約

  • RFC 3338はソケットAPIとホストのIPv4/IPv6スタックの間に変換器を置いた。AAAAだけを持つ相手に対し、ローカルIPv4プールからA応答を合成し、その値を実際のIPv6アドレスへ対応付けた。IPヘッダーの変換は行わない。
  • アプリケーションが受け取るIPv4値は、変換器の有効範囲付き状態にすぎない。プール枯渇、追い出しと再利用、APIの意味差、そしてホストのAAAAと特定ポートのIPv6対応の食い違いが、この見かけを破る。

解決器はアプリが理解できる形を返した

IPv4専用アプリケーションはgethostbyname型の結果とIPv4ソケット構造を前提にしていた。ソースコードが失われていたり、提供元が消滅していたりすれば、直ちに書き換えることはできない。RFC 3338は、ホスト自身はすでにネイティブIPv6を備える一方、古いバイナリだけがIPv4 APIに残る移行局面を対象にした。

BIAの名前解決器はアプリの呼び出しを横取りし、AとAAAAを調べる。AAAAしかなければ、アドレス写像器が内部IPv4プールから値を選び、IPv4とIPv6の対を保存して、アプリ向けのA応答を組み立てる。旧プログラムには慣れた4バイトの形が見えるため、変更せずに先へ進める。

その後、アプリがその値をIPv4ソケット関数に渡すと、関数写像器が呼び出しを捕まえ、表からIPv6相手を探し、対応するIPv6 APIを呼ぶ。パケットはネイティブIPv6スタックを通る。RFC 2767のBump-in-the-Stackと異なり、BIAはネットワーク層でIPv4とIPv6のヘッダーを書き換える必要がない。

アドレスに見える値は表の一行を指していた

通常のネットワークアドレスなら、この値が遠隔インターフェースやエンドポイントを識別すると考えやすい。BIAの合成値が語る範囲ははるかに狭い。ある変換表の、ある有効範囲の、ある世代に限って、一つのIPv6アドレスを参照する。

RFC 3338は内部プールの例として0.0.0.1から0.0.0.255のような未割り当て値を示した。これらはホスト外へ出る値ではない。一意性が必要なのも変換器の境界内だけである。ノード単位、ユーザー単位、プロセス単位の表があれば、同じビット列が別々の相手を指しても不思議ではない。

したがって、合成値だけを記録したログは曖昧である。表の範囲、エントリー世代、作成契機、IPv6参照先、DNS回答集合とTTL、プロセス所有者が要る。その「アドレス」は、世界的な宛先よりファイル記述子に近い。解釈する生きた表から切り離せば、数値だけでは意味を復元できない。

昨日のハンドルは再利用後に別の相手を指す

内部プールは有限である。多数のIPv4アプリが多数のIPv6ホストへ接続すれば、値を使い切り得る。RFCは最も古い写像を解放し、そのIPv4値を再利用する案を扱った。容量は戻るが、ハンドルの参照先は変わる。

アプリのキャッシュ、遅延コールバック、診断ログなどが古い値を保持していれば、再利用後も有効なアドレスに見える。ところが次の表引きでは、別のIPv6ホストへ変換される。大域経路に重複がなくても、一台の機械の中で寿命についての理解がずれるだけで誤配送と誤帰属が起きる。

監査可能な記録は割り当て、最終使用、追い出し、再利用、世代を残さなければならない。ソケット呼び出しは、発生時に有効だった世代へ結び付ける。同じ4バイトでも、再利用の前後では同じ運用上の身元ではない。

関数を置き換えてもAPIの意味までは同一にならない

関数写像器はIPv4ソケット関数を対応するIPv6関数へ変換するが、RFC 3338は両APIが完全互換ではないと警告する。IPv6だけの機能があり、raw socket、付随データ、ICMP値、ワイルドカード規則、アプリケーションプロトコル内に埋め込まれたアドレスには、OS依存の処理が要る。

置換した関数が成功したという事実は、呼び出しが行われたことしか保証しない。オプション、エラー、構造体の長さ、アドレス族、副作用まで元の意味を保ったとは限らない。アプリが特定の戻り値に依存していれば、変換器が正確に再現できないこともある。

だから受領証には、元のAPI名と引数、変換後のAPI名と引数、オプション変換、OS実装、戻り状態、アプリによる解釈を別々に残す。「ヘッダー変換なし」は一層を簡単にするだけで、意味変換そのものを消さない。

ホストのAAAAは、そのポートのIPv6対応を証明しない

デュアルスタックのサーバー機が、一部サービスのためにAAAAを公開していても、目的ポートのサーバープログラムはIPv4だけで待ち受けているかもしれない。BIAがAAAA経路を選べばホストまで届いても、サービス境界で失敗する。

RFC 3338は返されたアドレスを順に試すことを検討した。TCPならBIAがconnectの失敗を観測し、次へ進める可能性がある。UDPでは送信成功から即座に信頼できる応答が得られるとは限らず、どの候補が働いたかを変換器だけで知るのは困難、あるいは不可能であり、アプリ自身が反復しなければならない。

DNSは名前にレコードがあることを示す。ネットワーク到達性はパケットがアドレスへ届くことを示す。待受ポートはサービス入口を示す。アプリケーション成功は要求された処理の成立を示す。移行機構ではこの四つを混同しやすいが、前段の証拠を後段の証拠として使ってはならない。

互換層は移植を遅らせる制度にもなり得る

RFCは用途の境界を明確にした。BIAはExperimentalであり、IPv6を先行導入した組織が、ソースを入手できない旧アプリを動かすための仕組みだった。主流の本番利用には推奨されず、ソースがあればアプリを移植すべきで、BIAを先送りの口実にしてはならない。

これは技術上の注意だけではない。一時的な橋は写像、例外、監視、運用手順を蓄積する。現在の所有者は旧ソフトを延命できるが、将来の運用者は隠れた解決動作と状態を持つアドレス意味を引き継ぐ。やがて橋を外す費用が最初の移植より大きくなる。

導入記録には終了条件が要る。どのアプリが例外対象か、移植の所有者は誰か、未対応呼び出しは何か、何を観測すれば撤去できるかを明示する。出口のない「暫定」は、永続依存の別名である。

後年の接続競争は似た症状を別の方法で扱った

RFC 2767のBISは変換をスタック下層へ置き、RFC 2765のSIITに依存した。RFC 3338は適応点をAPI境界へ移した。RFC 2893は当時のデュアルスタック移行背景を示し、RFC 3493は後に基本IPv6ソケット拡張を記録し、RFC 4038はアプリ移行の選択肢を整理した。

RFC 6555と更新版RFC 8305のHappy Eyeballsは、後に複数アドレス族の接続を競争・順序付けして遅延や失敗を減らした。それはIPv6相手に私的なIPv4別名を割り当てるBIAとは違う。後年のアルゴリズムをBIAへ遡及すると、「実在候補を選ぶ」設計と「可変なローカルハンドルを作る」設計の歴史的な差が消える。

RFC 4291がIPv6アドレス体系を定義しても、BIAの内部IPv4プールに大域的意味は与えられない。また、どの標準文書もRFC 3338が特定の製品やネットワークで実運用された証拠にはならない。

互換ハンドルには必ず世代番号が要る

BIAの巧みさは、アプリから見えるインターフェースを保ち、下の実装を変えた点にある。代償は隠れた状態だった。アドレスに見えるものが可変表への参照となり、普通のソケット呼び出しに見えるものが横取りされた変換になる。

長く使える運用原則は、表現された値と、それを解釈する権限主体を一緒に記録することだ。合成A応答には写像受領証、変換呼び出しには変換前後の意味、接続には実際のIPv6宛先とポート、トランスポート結果、アプリ結果を付ける。

これがなければ、調査者はIPv4形状の数字を見て、存在しなかった大域的身元を読み込んでしまう。RFC 3338はIPv6移行の提案であると同時に、ハンドルの教訓でもある。ビット列が身元なのではない。検証可能な現在の写像こそが意味である。

出典