要約

  • IPv4 のリースが有効な間にも、その通信を運ぶトンネルの IPv6 送信元は変わり得る。サービスを説明するには、割り当てたアドレスだけでなく、その対応関係を見る必要がある。
  • クライアントが選べる範囲と、サーバーが変更を受け入れる頻度は別の問題だ。推奨プレフィックスには一定の裁量が残る一方、更新には制限が設けられる場合がある。
  • 送信元を変えられることは、匿名性を意味しない。現在の割り当てを知る事業者と、長期間残る識別情報を分けて考える必要がある。

利用者のネットワークで IPv6 のプレフィックスが変わった。しかし、IPv4 のリースはまだ有効である。この二つは矛盾しない。IPv4 の通信を IPv6 上のトンネルで運ぶ構成では、割り当てられた資源と、その通信が出発する IPv6 の位置は別々の情報だからだ。

その関係を動的に設定する方法を定めたのが、2019 年 3 月公開の RFC 8539 である。DHCPv6 上で DHCPv4 を運ぶ仕組みを使い、ソフトワイヤの設定を行う。公式記録では現在も Proposed Standard とされ、2026 年 9 月 8 日の正誤情報の照会では該当する記録がなかった。これは文書の確認結果であって、特定事業者の設備や品質を調査した結果ではない。

この規定から読み取れるのは、単なる移行技術の手順以上のものだ。IPv4 サービスの起点を選ぶ自由は、どこまで利用者に委ねられるのか。その自由を実用にするため、事業者は何を維持し続けなければならないのか。

選択肢は、すでに到達できる場所の中にある

動的設定を始める前に、利用可能な IPv6 プレフィックスが設定されていなければならない。DHCPv6、ルーター広告、その他の方法による設定が前提となる。IPv4 のリースを取得しただけで、必要な IPv6 の経路まで用意されるわけではない。

そのうえで、終端利用者のルーティング可能な IPv6 ネットワーク内なら、あらかじめ決められた境界機器だけにトンネルの起点を固定しない配置が可能になる。IPv4 サービスを担う機器と、特定のネットワーク境界を担う機器を分けられる余地が生まれる。ただし、任意の機器が対応しているという調査結果でも、別の事業者へそのままサービスを持ち出せるという保証でもない。

サーバーから渡される情報にも、必須条件と選択の参考がある。境界リレーの有効なアドレスは必須で、欠落や不正があればクライアントはメッセージを破棄する。一方、推奨プレフィックスはヒントである。不正なヒントは無視し、受け取っていないものとして処理を進める。ヒントがない場合や、適合するプレフィックスが見つからない場合には、規定された条件の下で適切なスコープの別の有効なプレフィックスを選べる。

したがって、事業者の推奨を絶対的な禁止規則と読むのは正確ではない。しかし、クライアントに裁量があるからといって、外部の任意のアドレスを指定できるわけでもない。到達性とスコープという技術的な範囲が、選択権の境界になる。

既存の IPv6 アドレスを使うことも、新しく構成することもできる。どちらの場合も、必要なら重複アドレス検出を含め、設定を完了してから送信元として要求する。文字列を選ぶ自由ではなく、実際に使用できる起点を選ぶ自由なのである。

対応表は資源の付属品ではない

サーバーは IPv6 の送信元を、IPv4 のリースおよびクライアント識別子とともに記録する。この対応関係はリースとともに有効であり、IPv6 の番号変更があれば、同じ IPv4 リースに新しい送信元を対応付ける更新が必要になる。

各 DHCPACK には、サーバーが実際に対応付けている送信元が入る。クライアントはそれを自分の有効な送信元と比較しなければならない。確認応答という名称だけでは、希望した新しい値が採用されたかどうかは分からない。

なぜ対応関係が重要なのか。Lightweight 4over6 は、一つの具体例を示す。アドレスとポートの変換は利用者側に置き、事業者側の軽量アドレスファミリー変換ルーターは、IPv6 アドレス、公開 IPv4 アドレス、制限されたポート集合を対応付ける。外から来た通信を正しい終端へ送る際にも、利用者からのカプセル化された通信を検証する際にも、この情報を使う。

これは、事業者の中央装置にアプリケーションの変換セッションを一つ残らず保存する構造とは異なる。ただし、中央のある種類の状態を減らすことと、中央が状態をまったく持たなくなることは同じではない。割り当てと利用位置の対応は、なお維持しなければならない。

ポート集合を伴う割り当てなら、IPv4 アドレスの空きと追加接続に使えるポートの余裕も分けて見る必要がある。文書に共有や配置の仕組みがあるだけで、実際の節約額、混雑の程度、あらゆる変更後のセッション継続を証明することはできない。本稿は実装や通信測定を扱っていない。

場所の自由と時間の自由を分ける

RFC 8539 は、送信元更新の最小間隔をサーバー側で設けることを認めている。この任意の方針を実装する場合、仕様上の既定値は 60 秒だ。早すぎる更新要求を応答せずに破棄することも、旧送信元を入れた確認応答を返すこともできる。

これは、すべてのクライアントに一律の待機を要求する数字ではない。どの設備でも 60 秒以内に復旧するというサービス水準でもない。方針を有効にするか、どの値で運用するかは別途確認が必要で、クライアントの再試行や解放の動作も、それに合わせる必要がある。

更新を抑える側にも事情はある。送信元が何度も変われば、設定系の処理が増える可能性がある。他方、プレフィックス変更により起点の変更が必要になった利用者にとって、同じ制限は通信を再び使うまでの制約になる。仕様だけでは、どちらの費用が大きいか、制限が適切かを判断できない。悪意を推定する理由にもならない。

さらに、選ぶ送信元は他の有効なリースの対応関係と衝突してはならない。新しい割り当ての衝突と、既存リースの更新時の衝突では扱いが異なるが、別の有効な対応関係を勝手に上書きする仕組みではない。

サービスの説明には、リース期間だけでなく、配置の範囲と変更の条件も必要になる。動的という形容詞は、それらの条件を不要にはしない。

起点が変わっても、識別情報は残り得る

変わらないインターフェース識別子は、ネットワークやセッションをまたぐ追跡につながり得ると RFC 8539 は指摘する。また、MAP-E のアドレス形式を参照し、IPv4 アドレスとポート集合識別子を用いる構成について説明している。その文脈では、すでに割り当てた資源を知っているサーバーに、追加のクライアント情報を与えず、リースされた IPv4 アドレスが変われば構成される識別子も変わる。

しかし、「追加で知らせない」は「知られていない」ではない。事業者はサービス提供のために現在の対応関係を知る必要がある。以前の記録を残していれば、新しい送信元に変えてもその記録は消えない。

DHCP クライアントの匿名性プロファイルも、リンク層アドレスだけを変えて他の識別子が固定なら、関連付けが続き得ることを説明する。同時に、匿名性を高める設定には運用上の影響がある。識別子を変えて新しいアドレスを求めると、以前のアドレスがまだリース中として扱われ、追加の資源を使う場合がある。戻ってきたクライアントへの同じアドレスの再割り当てや、登録済み識別子に基づく接続も関係してくる。

だからといって、すべての固定回線の機器が識別子を無作為に変えるべきだという結論にはならない。既知のネットワークで安定した割り当てを求める場面と、関連付けを減らしたい場面では、優先順位が違う。配置変更、安定運用、匿名性を一つの機能として宣伝すると、この違いが見えなくなる。

安全性にも適用範囲がある。RFC 8539 はクライアントごとの専用のレイヤー 2 接続を想定し、共有媒体での適用を推奨していない。入口でのフィルタリングや境界リレーでの検証も防御上の前提となる。送信元の選択は、その範囲内で委ねられた権限である。

Lu Heng がノート 36で述べる、推奨ではなく実際の構造を描くという姿勢に照らせば、結論は限定的でよい。動的設定は配置を柔軟にする。ただし、対応関係を保つ仕事、変更の頻度を決める権限、識別情報の問題は残る。