要約

  • 6rdは事業者のIPv6プレフィックスに顧客側のIPv4アドレスの一部を組み合わせる。従来のアドレス割り当てが、新サービスの容量と継続性にも関わる。
  • 事業者が管理するドメインでも、すべての通信が境界リレーを通るわけではない。同一ドメインの顧客側ルーター同士は直接通信できる。
  • フローごとの状態を持たないことと、運用上の依存がないことは別だ。共通設定、寿命の整合、ネイティブIPv6へ移る際の経路引き継ぎは残る。

更改した設備だけを数えても終わらない

アクセス設備がネイティブIPv6に対応すれば、過渡的な仕組みの役目は終わったように見える。だが6rdの場合、設備の対応状況だけでは移行の完了を判断できない。顧客が使ってきたIPv6プレフィックスを今後どう扱うかという、別の仕事がある。

RFC 5969 は、別のアドレスブロックへ切り替える方法だけでなく、6rdで使っていた委譲プレフィックスをネイティブの経路制御に載せて保持する方法も説明している。顧客の番号を変えない選択肢はある。しかし、番号を変えずに済むことは、ネットワーク側に引き継ぎ作業がないことを意味しない。

この出口から見ると、6rdが入口で何を借りていたのかが分かりやすい。IPv4網を輸送手段として使うだけではない。顧客のIPv4アドレスをIPv6プレフィックスの計算に使い、その割り当て期間にも依存する。古いアドレス設計は、新しいサービスの内部で働き続けている。

本稿は特定事業者の障害調査ではない。現在の導入数や性能を測定したものでもない。仕様と公開された歴史的記録から確認できるのは、依存の仕組みと、それを管理するために区別すべき条件である。

計算で省いたもの、計算に残したもの

6rdは、IPv6パケットを既存のIPv4ネットワーク上にカプセル化して運ぶ。アクセス網全体を先にネイティブIPv6化しなくても、サービスを始められる。境界リレーはフローごとの変換対応表を維持せず、アドレスから転送先に関する情報を導ける。

顧客側ルーターはCEと呼ばれる。その委譲IPv6プレフィックスは、事業者の6rdプレフィックスと、CEのIPv4アドレスの必要な後半部分から構成される。IPv4空間で共通する上位ビットは省略でき、IPv4MaskLenがその数を示す。

委譲プレフィックス長は、6rdPrefixLenに32を加え、IPv4MaskLenを引いた値になる。仕様の例ではIPv4アドレスに10/8を用いる。共通する先頭8ビットを省き、残る24ビットを/32の6rdプレフィックスに加えると、顧客には/56が渡る。

ここで消費したビットは、顧客の内部ネットワークを分割するためには使えない。したがってIPv4の設計は、IPv6でどれだけのサブネットを顧客に提供できるかにも関与する。アドレス利用効率の調整が、別のサービスの商品条件に触れる理由はここにある。

形式上の上限と、顧客向け設計としての適切さも分ける必要がある。DHCPオプションでは関連する長さの合計が128ビットを超えてはならない。一方、アドレス設計の説明では、ステートレスアドレス自動設定を可能にするため、委譲プレフィックスを/64以下の長さにすることが推奨される。前者を満たすだけで、十分な顧客ネットワーク設計ができたことにはならない。

プライベートIPv4空間を使う場合も文脈は必要だ。重複するIPv4空間を別々の6rdドメインに置くなら、それぞれ異なる6rdプレフィックスで区別する。一つのドメインで意味を持つアドレスを、そのまま他のドメインの端点の証明にはできない。また、この方式を、共有IPv4アドレスのポート範囲ごとに別の顧客プレフィックスを与える仕組みと混同してはならない。

「5週間」を支えた運用権限

迅速な導入という期待には、具体的な先例がある。RFC 5569 はFree/Iliadの初期導入について、2007年11月7日の決定から12月11日の稼働まで5週間だったと報告している。150万を超える顧客が、機能を有効にすればIPv6を利用できる状態にあったという。

ただし、利用可能な顧客数は実利用者数ではない。同時接続数や通信品質の測定でもない。この2010年の情報提供文書を、現在の普及率や他社でも実現できる期間の証拠として使うことはできない。

報告に現れるのは、アルゴリズムだけでなく、顧客機器のソフトウェアを変更し、リレーを配置し、既存アクセス網を活用できる組織である。アドレスの条件も変化した。初期の/32割り当てと顧客/64から、後の/26割り当てと顧客/60へ進み、顧客あたり16のLANを使える構成になったと記されている。これは歴史的な構成の記録であり、/26に32ビットを足せば/60になるという計算ではない。

RFC 5569の正誤表 にある検証済みの編集上の訂正2023も、この時系列を明確にしている。後の割り当ては将来の見込みではなく、すでに実現した事柄として書かれるべきだった。他の検証済み項目も編集上の修正であり、新しい性能データではない。

経営上の教訓は、短い期間をそのまま目標にすることではない。その期間を可能にした権限と条件を確かめることだ。計算方法を採用しても、導入済みの顧客機器を同じように更新できるとは限らない。プロトコルの簡潔さと、事業者の実行能力は別に確認する必要がある。

IPv4のリース期間はIPv6にも届く

CEのIPv4アドレスが変われば、そこから導くIPv6プレフィックスも変わる。RFC 5969は、この変化が顧客ネットワークに波及し得ることを指摘し、IPv4アドレスを長く維持することを推奨している。

IPv4リース期間が分かっている場合、LAN側に通知する関連する有効期間やDHCPv6で委譲するプレフィックスの寿命は、その期間を超えてはならない。IPv4側の寿命が不明な場合はRFC 4861の既定値を使うことが推奨される。不明であることを、無期限に安定して使えるという意味に置き換えることはできない。

ここでいうリースは、アドレス割り当てプロトコル上のリースだ。IPv4資産を商取引で借りる契約とは異なる。事業者が同じアドレスブロックを保有し続けても、その中の特定アドレスを別の顧客へ割り当て直すことはあり得る。6rdの計算を支えるのは、その個別の割り当て関係である。

この依存から、すべての顧客に永久固定アドレスが必要だと結論付けるのも行き過ぎだ。仕様は一つの販売条件を決めているのではない。期間を短くするなら、IPv4の管理上の利点だけでなく、IPv6側に生じる変更も評価する必要があると示している。

その評価は部門をまたぐ。IPv4担当はアドレス利用の柔軟性を求め、IPv6担当はプレフィックスの継続性を求め、サポート担当は顧客側の変化に対応する。各部門が正しく働いていても、全体の損得を見ている人がいなければ、局所的な改善が別の部門や顧客へ負担を移す。

境界リレーだけを見てもドメインは分からない

6rdは、固定のグローバルプレフィックスを使う6to4と異なり、事業者自身のIPv6プレフィックスを使う。定義された事業者ドメインで運用できることは重要な違いだ。しかし、それを「全通信が一つの中央装置を通る」と読み替えることはできない。

同じ6rdドメインのCE同士は、IPv4による直接のカプセル化経路で通信できる。境界リレーであるBRは、6rdドメインと外部IPv6網との間をまたぐ通信に必要になる。どの送信元を受け入れるか、どの経路を試験するかは、この区別に左右される。

RFC 5969の検証済み技術訂正3049 は、この点を安全性の説明に反映している。CEが受信すべき相手は既知のBRだけではなく、同一ドメイン内の他のCEも含む。訂正前のリレー限定の表現をそのまま実装上の方針にすると、正当な通信経路を閉じる可能性がある。

同じ正誤表には、却下された技術訂正3869もある。こちらの提案を採用済みの修正として扱ってはならない。検証対象は、内側IPv6送信元アドレスに埋め込まれたIPv4アドレスと、外側IPv4送信元アドレスの一致である。IPv6アドレス全体をIPv4アドレスとして比較するわけではない。不一致は破棄され、送信元偽装の可能性として計数されるが、その数字だけで攻撃や実行者を断定できるわけでもない。

共通設定にも注意が要る。IPv4マスク長、6rdプレフィックスとその長さ、BRのIPv4アドレスに関する情報は、ドメイン内で整合していなければならない。DHCPオプション212は一つのドメインのパラメーターを届ける手段となる。有効なオプションを受けたCEは通常自動設定を行うが、その動作を無効化し、オプションを無視できるようにすることも要求される。

状態を減らしたことは、設定権限をなくしたことではない。少数の共通入力に、多数の機器の解釈が依存する構造になったということだ。自動化が広がるほど、その入力の整合性を説明できる必要がある。

応答のあった経路と、まだ分からない経路

フローごとの状態が不要なため、複数のBRは同じIPv4エニーキャストアドレスを使える。ただし、一つのアドレスから応答があったという観測は、すべてのBR、外部宛先、パケット長について同じ結果を保証しない。

RFC 5969は、多数のCEによる定期的な到達性確認がBRの制御プレーンに負担をかける可能性を指摘する。CEからBRへの到達性検出が必要なら、BRの制御プレーンに特別な処理を求めないデータプレーン方式を使わなければならない。文書のループバック方式は、その転送往復を確認するものだ。外部IPv6網のすべての経路を確認するものではない。

パケット長の問題も残る。共通のIPv4エニーキャストアドレスに返されたICMPエラーは、元のパケットを送ったBRとは別のBRへ届くことがある。動的な経路MTU学習がうまく働かず、ブラックホールが生じる可能性がある。エニーキャストBRのカプセル化ではDFビットの設定が必須であり、共通送信元を使う複数BRの断片が再組み立て時に混同される危険にも対応する。

文書は、IPv4経路が1500バイトを確実に扱える管理された環境で、トンネルMTUを1480バイトとする例を示す。関係するMTUが不明なら1280が推奨される。これらは設計上の条件と指針であって、本稿の実測値ではない。小さなパケットの成功から、大きなパケットの条件まで済んだことにはできない。

算出可能なアドレスは、端点の資格証明ではない

2011年の情報提供文書 RFC 6324 は、自動IPv6-over-IPv4トンネルで、経路情報やアドレス解釈の不整合によってループが生じる条件を分析している。そこで重要なのは、アドレスを計算できることと、正当なトンネル端点が実在することの違いだ。

6rdでは事業者ごとのプレフィックスを知る必要があり、全世界の6rdを見分ける一つの固定プレフィックスはない。プライベートIPv4空間には作用範囲の問題もある。一般的な検査だけで、ドメインの知識を代用することはできない。

文書は運用方法による回避を重視し、適する場合には整合した近隣情報や限定的な端点集合も扱う。一方、ISATAP固有の対処を6rdにも一律に適用してよいわけではない。仕組みが似ているからといって、提案の適用範囲まで同一にはならない。

ここで示されるのは条件付きの失敗機構であり、現在すべての6rd網が攻撃されているという調査結果ではない。IPv6のホップ制限は有限である。本稿では攻撃パケットの送信や現網への試験は行っていない。RFC 6324の正誤表検索 に該当項目がなかったことも、現在の安全性評価の代わりにはならない。

RFC 5969も、BRへの望ましくない外部アクセスを制限し、IPv4ドメイン内の既知の他のリレーを考慮する必要を論じている。「同じ事業者の網だから安全」という呼び方だけでは、その境界が実際に保たれている証拠にならない。逆に、仕様を読んだだけで特定事業者の運用が悪いとも言えない。

入口の省力化を、出口の責任へつなぐ

6rdは旧網の能力を使って新サービスを早めた。その選択自体を否定する必要はない。必要なのは、ネイティブ移行でプレフィックスを変えるのか、保ったまま経路を引き継ぐのかを、顧客の依存と一緒に決めることだ。

旧6rdブロックの回収も、残っている利用者の扱い次第である。目立つリレーを撤去した、アクセス装置を更改したという二つの事実だけでは、すべてのプレフィックスが不要になったとは確認できない。

Lu Hengの代理問題を論じたNote 32 は、意思決定の権限と、その結果を負担する立場を照らし合わせる視点を示す。ここに当てはめれば、IPv4割り当てを変えられる人が、IPv6の継続性や移行費用も把握しているかという問いになる。Lu Hengが6rdを評価したという意味ではなく、特定事業者の動機を推測する根拠でもない。

BTWの役割を説明するNote 36 に沿えば、報道の仕事は賛否の運動ではなく、構造と証拠の限界を明らかにすることだ。迅速な導入の利益を認めたうえで、その後も何がサービスを支えているかを記述できる。

古いアドレス設計が退場しないのは、単なる整理不足とは限らない。まだ新しいサービスのために働いているからだ。その仕事を見える形で引き継ぐことが、IPv6を始めることと、依存を終わらせることの間にある。