要約
- PRL に IPv4 アドレスが載っている事実は、そのアドレスへ Router Solicitation を送る根拠になる。現在そこに正しい装置があり、応答できることまでは示さない。
- Router Advertisement を受理し、IPv6 アドレスが付いた後にも、近隣到達性、戻り経路、任播インスタンスの整合性、アプリケーション結果が残る。
- 共通仕様は発見に必要な最小情報を扱い、実行結果は各運用主体が観測する。この境界を守ることが Running-Code Primacy の実務になる。
完了報告の一行に消えた四つの状態
構成管理の記録には「09:00、PRL 更新完了」とある。isatap.example.net は予定どおり二つの IPv4 アドレスを返し、配布値と設計値は一致した。
しかし、これは構成上の完了でしかない。一方の装置は前夜にドレイン済みだった。代替装置は別の IPv4 区画にあり、protocol 41 を許可する変更だけが未反映だった。09:05 にホストが二つの候補へ RS を送ると、RA は一つしか戻らない。09:08、ホストには IPv6 アドレスとデフォルトルートがあるが、一部プレフィックスの戻り経路は旧装置へ向いたままだった。
この時系列は RFC の仕組みから組み立てた仮想例であり、実在組織の障害報告ではない。示しているのは、公開、制御応答、ローカル設定、双方向サービスがそれぞれ別の時刻と所有者を持つという点だ。
「PRL 更新完了」は正しい。間違いは、その一行を「IPv6 提供完了」と読み替えたことである。
ISATAP が候補表を必要とした理由
ISATAP は IPv4 網を IPv6 の NBMA リンクとして扱う。デュアルスタックのノードは IPv6 パケットを IPv4 protocol 41 で包み、ISATAP インターフェース識別子に IPv4 アドレスを埋め込む。下位の宛先を計算できるため、既存 IPv4 サイトの内部で IPv6 を自動トンネル化できる。
一方、IPv4 の広域マルチキャストを一般に利用できるとは仮定しない。通常の共有リンクのように、すべてのルーターへ一度に問い合わせることはできない。そこでホストは Potential Router List、PRL を初期化し、その各 IPv4 アドレスへユニキャストで問い合わせる。
PRL の出所は一つではない。手動設定、DHCPv4 のベンダー固有オプション、FQDN の名前解決、サイト固有の方法が認められる。この柔軟性は導入を容易にするが、どの方法も装置の生存確認を内包してはいない。
DNS は特に誤解されやすい。権威サーバーが正しい A レコードを返しても、返された装置がその後に停止することはある。RFC 5214 は PrlRefreshInterval を定め、DNS TTL がある場合はその最小値と比較して早い方で更新するよう求める。鮮度の上限を定める仕組みであり、有効期間中の稼働保証ではない。
ビットの一致が証明する範囲
ISATAP アドレスの一部から IPv4 ロケーターを静的に導ける。受信側は、外側 IPv4 送信元が内側 IPv6 送信元に埋め込まれた値と一致するか、ルーターなら PRL のメンバーであるかを確認する。
この検査は重要である。無関係な外側アドレスを、内側が示すピアとして無条件に受け入れないための決定論的な制約になる。ただし、アドレス所有者、装置の稼働、設定世代、経路、サイト権限までは証明しない。
RFC 5214 は、一つの ISATAP インターフェースの locator set が複数サイトをまたいではならないとする。サイト境界はパケットに刻まれた自然法則ではない。IPv4 ルーティング、名前管理、フィルター、資産台帳、変更手続が同じ範囲を指して初めて成立する。
セキュリティ節もこの前提を明確にする。外部からの注入を防ぐには、サイト境界で IPv4 ingress と protocol 41 を制限する。内部ノードがルーターを装う危険もあるため、PRL を最新に保ち、解決機構を改ざんから守る必要がある。リストへの掲載は信頼の終点ではなく、信頼を支える運用の結果である。
RA は一段進んだ証拠である
ホストは PRL の候補へ RS を送り、広告ルーターは要求元へ直接 RA を返す。受理される RA の link-local ISATAP 送信元は、PRL にある IPv4 アドレスを埋め込んでいなければならない。
RA の成功を軽視してはいけない。少なくとも一往復の制御交換と送信元関係を観測したことになる。しかし、その成功をサービス完了へ拡張してもいけない。プレフィックスやルートの lifetime を受理した後、アドレス設定、近隣確認、IPv4 アンダーレイ、IPv6 戻り経路、外部到達性が続く。
RFC 5214 は、ホストが Neighbor Unreachability Detection を行い、アドレス解決後に NS/NA で初期到達性を確認することを推奨する。ルーターも実行できるが、大規模環境では状態量が問題になり得る。ARP 失敗や継続する ICMPv4 エラーも、隣接経路が壊れた可能性を示す情報として扱う。
したがって証拠は、PRL の取得時刻、IPv4 到達性、RS 送信、RA 受信、RA 送信元検証、アドレス設定、NS/NA、NUD、双方向トラフィック、アプリケーション結果という順で積み上がる。後段の空白を前段の緑色表示で埋めることはできない。
任播は可用性と匿名性を同時に増やす
RFC 6964 は、負荷分散やサイト区画のため複数の広告ルーターを配置できると説明する。PRL に IPv4 anycast アドレスを載せ、複数装置へ割り当てる構成も可能だ。
この方式では、同じ候補アドレスが別の物理装置へ到達し得る。昨日の RA は装置 A、今日の RA は装置 B から返る。それでも DNS と PRL は変わらない。A が正常だった事実は、B の IPv6 経路、フィルター、MTU、ソフトウェアが一致する証明にならない。
複数ルーターが異なるプレフィックスを扱うなら、広告ルーター間の IPv6 ルーティングや companion gateway が、正しい戻り先を保持しなければならない。発見の安定性は、内部ルーティングの整合性を自動生成しない。
RFC 6324 の自動トンネル・ループは、一覧の「完全性」が運用上の仮定であることを示す。すべてのトンネルルーターを本当に含む一覧ならフィルターに使える。しかし未登録ルーターや別方式のトンネルがあれば、その仮定は崩れる。ファイル名やデータ型が完全性を保証するわけではない。
RFC 9099 は ISATAP がもはや頻繁には使われないと述べつつ、ループやフィルターの教訓を残している。これは 2026 年の導入数調査ではない。本稿も普及率を推計しない。重要なのは、古い移行技術でも「公開された候補」と「観測された実行」を混同する現代的な障害を映すことだ。
運用証跡を一つの時間軸にする
ISATAP の継続または廃止を判断するには、サイト識別子、locator set の範囲、PRL の出所・TTL・取得時刻、各 IPv4 アドレスの責任者、区画ごとの IPv4 経路と ARP、protocol 41 境界、RS/RA、lifetime、NS/NA と NUD、anycast メンバー、IPv6 経路、双方向パケット、外部宛先、代表アプリケーション、旧エントリー撤去を一つの証跡に結ぶ。
これは BTW の編集提案であり、RFC 5214 に新しいメッセージを追加する主張ではない。仕様が区別した事実を、上位の運用画面でも区別し続けるための方法である。
Heng Lu の Running-Code Primacy は、共通層を最小の検証可能規則に限定し、その後の状態を実行主体がローカルに確かめる。PRL は「どこへ聞くか」という共通課題を解く。その答えが届いたか、経路が通るか、サービスが成立したかは、実際にコードとネットワークを動かす側の責任である。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加