/note/tech

Why is IPv6 so complicated?

要約:

■ 1. IPv6が複雑である理由の概観

  • IPv4のアドレスに単純にビットを追加するだけでは不十分であり IPv6の複雑さには正当な理由が存在する
  • 主な理由は以下の3点に整理される
    • アドレスのビット数拡張は見た目より複雑である
    • 1994年当時 IPv4以外にも多くのネットワーク層プロトコルが存在しIPv4にない機能が求められた
    • IPv6設計者が過剰設計に陥った可能性がある(いわゆるSecond System Syndrome)
  • IPv6開発の意思決定は1991年のIABワークショップを起点とし 1994年7月のIETF会議で正式に採択された

■ 2. アドレスのビット拡張が単純でない理由

  • IPv4の実装はすべて32ビットアドレス形式をコードに組み込んでおり アドレス長を変更すると既存の実装はパケットを廃棄する
  • アドレスサイズを拡張するには必ずプロトコルを変更する必要があり 以下の対応が不可避となる
    • バージョン番号の変更
    • 新バージョンを処理する新規コードの追加
    • 旧バージョンとの共存技術の実装
  • 旧バージョンとの共存方式は数学的に以下の2つしか存在しない
    • デュアルスタック: 新しいマシンがIPv4とIPv6の両方を話す方式
    • トランスレーション: アドレスを旧・新プロトコル間で変換する方式
  • IPv4/IPv6共存の複雑さはすべてこの構造的制約から生じており IPv6の設計詳細とは無関係である
  • 「IPv8」提案者が主張する「IPv4アドレスの先頭にビットを追加する」方式も試みられたが実用性がなく廃止された(RFC3513 → RFC4291)

■ 3. 1990年代初頭のプロトコル環境

  • 1990年代初頭はIPv4がまだ世界を支配しておらず 多数の代替ネットワーク層プロトコルが存在した
    • OSI(開放型システム間相互接続)プロトコル群: 各国政府や大企業が標準として支持
    • DECNET Novell Netware等の独自プロトコル群
  • 新世代IPには単なるアドレス拡張ではなく これらの競合プロトコルを上回る機能が求められた
  • この背景から IPv4単純拡張では市場・技術的ニーズを満たせなかった

■ 4. IPv6設計の過剰複雑化に関する検討

  • IPv6は基本的に保守的な設計であり コネクションレス型パケット交換という基本モデルは維持されている
  • 追加された主な機能は以下の通り
    • フローラベル(長年未使用でも無害)
    • フラグメンテーション機構の調整
    • IPv4「オプション」をIPv6「拡張ヘッダ」へ置き換え
    • ステートレスアドレス自動設定(SLAAC)とルータアドバタイズメント(RA)機構
  • SLAACはDECNET・Netware・Appletalkに着想を得たものであり 手動アドレス設定を不要とする
  • DHCPv6とSLAACが重複するのは SLAAC設計時にDHCPがまだ実績のない新技術だったためであり DHCPv6は後付けで追加された
  • IPsecのサポートを必須とする政治的決定は 当時未成熟な技術を強制したことでIPv6普及の妨げとなり 後に撤回された
  • IPv6展開の問題の大部分はIPv4/IPv6共存領域から生じており 設計の過剰さによるものではない

■ 5. 代替案(IPv8等)の問題点

  • 一部の「IPv8」提案は解決どころか問題を悪化させる要素を含んでいる
    • 地理的アドレッシング: インターネットのドメイン間ルーティングと非互換
    • 自律システム番号に基づくアドレスプレフィックス: ルーティングを破壊する
    • アドレスビットに意味を持たせる設計: サイト再番号付けをさらに困難にする
    • これらは経路制御の破綻 アドレス枯渇の再発 広範囲な監視の容易化等を引き起こすリスクがある

■ 6. 普及に要する時間の必然性

  • IPv6が約50%の普及率に達するまで25年以上を要した
  • これはIPv6固有の問題ではなく インターネット規模の技術移行には例外なく数十年を要する
    • フレームリレーの廃止
    • ATMの置き換え
    • DNSSECの展開
    • RPKIの展開

■ 7. 結論

  • IPv6の存在意義はアドレス空間の拡大にあり それ以外の複雑さは構造的に避けられないものである
  • 32ビットを超えるアドレス長を採用した時点で 共存・移行に関するすべての問題は必然的に発生する
  • デュアルスタックとトランスレーションの両方式は数学的に不可避であり 代替設計によって回避することは不可能である
  • IPv8等の代替提案を検討することはコミュニティにとって時間の無駄である

関連: