IPv6が優れた設計だった世界 (2017)
(apenwarr.ca)- 初期のネットワークはポイントツーポイント接続中心だったため、アドレス体系はほとんど不要だったが、コスト削減のためにバスネットワークが広がると、MACアドレス、ブリッジング、ARPのような複雑さが積み重なった
- EthernetとIPが結び付くことで、次ホップ転送のためにMACアドレス指定とARPブロードキャストが必要になり、大規模な相互接続ネットワークやwifiでこの負担が大きく拡大した
- IPv6の構想には、物理バスとlayer 2 internetworkを捨て、ブロードキャスト、ARP、DHCP、MACアドレスまで取り除く単純な世界への期待が反映されていた
- しかし実際の展開環境では、IPv4と既存のフレーミングが残り続け、neighbor discovery、DHCP、NAT、layer 2ブリッジングといった遺産も一緒に維持された
- 移動中の接続維持のため、Internetルーティングの代わりにlayer 2ブリッジングと中央集約トンネリングが使われ続けており、QUICのような代替案がroaming回避策として取り沙汰されている
バスネットワークがすべてを台無しにしたきっかけ
- 電話網の初期の回線交換や専用線環境ではポイントツーポイント接続しか存在せず、アドレス体系は不要で、一方に入れたビットが一定時間後に反対側から出てくる構造だった
- TDMや仮想回線交換の導入後も、利用者から見れば依然として片側の入力がもう片側の出力につながる形であり、この段階でもアドレスは必要なかった
- 複数インターフェースを持つコンピュータが回線間でビットを転送するようになってIPアドレス、サブネット、ルーティングが登場したが、ポイントツーポイントリンクでは依然としてMACアドレスは不要だった
- ローカルサイト接続のコストを下げるため、複数の機器を1本の線にぶら下げるバスネットワークが登場し、Internet系列とは別に独自のlayer 2体系がそれぞれ生まれた
- 初期LANのarcnetは8ビットのlayer 2アドレスをジャンパやDIPスイッチで手動設定する必要があり、重複すると深刻な障害が発生したが、ネットワークが小さかったため不便は限定的だった
- Ethernetは48ビットのMACアドレスを導入し、製造段階でほぼ一意なアドレスを割り当てる方式で重複問題を解決した
- IPXやNetwareのようなLAN技術は、単一のバスネットワーク内ではアドレス設定なしでもうまく動作し、美しく信頼性高く動いていた時代として描写されている
- 大企業や大学のネットワークは、単一の10 Mbpsバスのボトルネックのために複数のバスを相互接続する必要があったが、当時まだ成熟していなかったIPの代わりに、Ethernetアドレスベースのブリッジングとスイッチングを拡張路線として選んだ
- Ethernetアドレスは工場で順番に割り当てられる方式のため階層構造を持たず、ブリッジングテーブルはサブネット単位の経路を扱う現代のIPルーティングテーブルのように効率よく集約できなかった
- 効率的なブリッジングのためには、各MACアドレスがどのバス上にあるかを記憶しなければならなかった
- これを手動設定にしないため、自動学習と複雑な相互作用が必要になった
- 複雑なブリッジネットワークはspanning treeのような仕組みでつながれ、ブロードキャストフラッディング、非最適経路、低いデバッグ容易性が伴った
- 中間ブリッジには通常のEthernetのようなアドレス概念がないため、tracerouteのようなツールを作れず、ブリッジングは実質的にほとんどデバッグ不可能な構造だった
- それでもブリッジングはハードウェア最適化のおかげでEthernetの線速に近い非常に高速な動作を実現しており、当時はそれが大きな利点だった
バスの上で動くInternet
- 長距離のポイントツーポイントリンクで個々のコンピュータを接続していた構造から、徐々にLAN全体の接続が求められるようになり、LAN同士の長距離接続が必要になった
- 単純な長距離ブリッジは輻輳制御の問題により成立せず、Ethernetブリッジングはすべてのリンク速度がほぼ同じか、輻輳がほとんどないという前提でしか動作しなかった
- 10 Mbps Ethernetと0.128 Mbpsのポイントツーポイントリンクを直接ブリッジングする方式には望みがなく、floodingベースの経路探索も低速リンクでは無駄が大きすぎた
- ローカル環境では我慢できた非最適ルーティングも、遅く高価な長距離リンクでは致命的で、スケーラビリティがなかった
- この問題群はすでにInternet側が扱っていた領域であり、LANバスをInternet技術で接続すればはるかに良い構造にできた
- そこで、EthernetやarcnetなどのLAN上にInternetパケットを載せるフレーム形式が設計され、この時点から問題が始まった
- Ethernetセグメント内に複数のIPルータがいると、どのルータがパケットを受け取って転送するのかを区別する必要があり、最終宛先IPだけではその選択を表せなかった
- そのため、最終宛先はIPヘッダに残しつつ、実際の次ホップルータはEthernetフレームのMACアドレスで指定する必要が生じた
- 人が表現したい実際の情報は
宛先IP 10.1.1.1をルータMAC 11:22:33:44:55:66へ送るなのに、OSはこれをルータIP 192.168.1.1経由のような形で扱うようになった - この抽象化のために、OSはまずルータIPのEthernetアドレスを探す必要があり、その中間段階としてARPが追加された
- ARPはローカルEthernet全体にブロードキャストを送って特定IPの所有者を探す方式であり、ブリッジがあればEthernetブロードキャストとしてすべてのインターフェースへ転送しなければならなかった
- 大規模に相互接続されたEthernetでは過剰なブロードキャストが最大級の悪夢の1つとなり、特にwifiではさらに深刻だった
- その後、ブリッジやスイッチはARP転送範囲を減らす特殊なハックを入れ始め、一部の機器、とりわけwifiアクセスポイントは偽のARP応答まで生成したが、いずれも技術的ハックに近かった
遺産による死
- 時間がたつにつれて、Ethernet上の非IPプロトコルはほとんど消え、ネットワークは物理層の回線の上にバス型layer 2、そのバス群をつなぐブリッジ、さらにその上にlayer 3ルータが載る構造として固定化した
- 手動IP設定の疲労が大きくなるにつれて自動設定の要求が生まれたが、機器はすでにEthernetアドレス付きで出荷されており、IPv4 32ビットアドレスは製造段階で永続的に一意割り当てするには足りなかった
- IPアドレスを単純な連番で割り当てると、再びEthernetのような非階層構造に戻ってしまうため、適切な解決策ではなかった
- そこでbootpとDHCPが登場し、これらはARPのように特別扱いが必要なプロトコルになった
- DHCPはIPアドレスを持たないノードが先に送信しなければならないため、RFCで定められた形式の、実質的には意味のないIPヘッダを埋め込む必要があり、DHCPサーバはカーネルのIP層ではなくraw socketでこれを直接組み立てなければならなかった
- bootpとDHCPは、結局Ethernetアドレスを知らなければIPアドレスを割り当てられないため、ARPの逆方向に近い役割を果たした
- RARPが同じことをより単純に実現していたが、ここではほとんど触れられていないと言及されている
- 結果としてEthernetとIPはますます強く絡み合い、今日ではほとんど分離不可能な存在になった
- IPルーティングテーブルはIPアドレスでルータを指定しているふりをしながら、実際にはMACアドレスを迂回的に指定しており、ARPはブリッジ上を通過し、DHCPはIPパケットのように見えても実際にはEthernetプロトコルに近い構造になった
- 同時にブリッジングとルーティングはどちらもさらに複雑になり、ブリッジングはおおむねIEEEとハードウェアの領域、ルーティングはおおむねIETFとソフトウェアの領域として分かれ、互いを存在しないかのように扱ってきた
- ネットワーク運用者は速度要求とDHCPサーバ設定の忌避の程度に応じてブリッジングとルーティングを選び、可能な限りブリッジングを多用し、必要なときだけルーティングを使った
- ブリッジングの複雑さは最終的にlayer 2の意思決定を上位層へ引き上げ、IP上のプロトコルで一元管理するSDNへとつながった
- SDNはスイッチやブリッジがそれぞれ勝手に動くよりは良かったが、そもそも大きくなりすぎたネットワークをソフトウェアで扱うIP自体がすでにソフトウェア定義ネットワークだったという点で、根本的に滑稽な面があると指摘されている
- IPv4は初期にはハードウェア高速化が難しく、実際にも十分なハードウェア高速化がなされず、DHCP設定も非常に煩雑だったため、運用者はますます広い範囲をブリッジングする方法を身につけていった
- 今日の大規模データセンターは、事実上SDNベースの巨大な仮想バスネットワークのように動作しており、パケットを実質的にルーティングしないことも多いと描写されている
では先ほどの話をいったん忘れよう
- 1990年代初頭にIETFがIPv6を構想していた当時、すでに多くの混乱は進行中だったが、迫り来る災厄を避けられるという前提で設計が進められた
- その過程での重要な変化の1つは、すでに物理バスネットワークの利用が事実上終わっていたことだった
- Ethernetはもはや本物のバスではなく、バスのふりをしているだけであり、速度向上によってCSMA/CDを維持できなくなると、再びスタートポロジへ回帰した
- 各ステーションから中央スイッチまで個別のケーブルを引く構造が一般化し、壁も天井も床も大きく高価なEthernetケーブルの束で満たされた
- wifiでさえ共有無線媒体という究極のバスのように見えるが、実際にはinfrastructure modeで巨大なスタートポロジを真似している場合がほとんどだと述べられている
- 同じアクセスポイントにつながる2つのwifiステーション同士でさえ直接通信せず、相手ノードのMACアドレスを入れたパケットをアクセスポイントへ送り、アクセスポイントがそれを再送する方式になっている
- ノードXがInternetノードZへ、IPルータY経由で、wifiアクセスポイントAを通じて送る場合、ZはIP宛先、YはEthernet宛先、Aは実際の無線伝送先となり、アドレス階層が複雑に重なる
- これに対応するため、802.11は実際のEthernet宛先と中間Ethernet宛先を同時に持てる3-address modeを提供している
- さらに
to-AP、from-APビットがあり、ステーション→AP、AP→ステーション方向を示し、両ビットが同時に真ならAP間中継器としての動作も表現できる - Aがrepeaterで、さらに基地局Bへ送らなければならない場合、空中伝送の実際の送受信主体とEthernetの送信元・宛先がすべて異なるため、4-address modeが必要になる
- 802.11s meshには6-address modeまであり、そのあたりで理解を諦めたと書かれている
IPv6が良い設計だった世界
- IPv6を検討していたIETFは、すでに起きていた混乱と今後起こるさらに大きな混乱を見て、既存レガシーを捨てた新しい世界を想像した
- その世界の前提は、物理バスネットワークの排除、layer 2 internetworkの排除、ブロードキャストの排除、MACアドレスの排除、ARPとDHCPの排除、ハードウェア高速化しやすい単純なIPヘッダ、アドレス不足の解消、コアを除く手動IP設定の排除だった
- layer 2が常にポイントツーポイントなら、ブロードキャストの送信先自体が存在しないためマルチキャストで置き換えられ、送受信相手が自明なのでMACアドレスも不要になるという発想だった
- MACアドレスが消えればIPとMACの対応付けも不要になり、ARPやDHCPも消せるし、大きなサブネットルーティングを再び使えるだけの十分なアドレス空間も確保できた
- その世界では、wifi repeater、wifiアクセスポイント、Ethernetスイッチ、SDNまでもがすべてIPv6ルータとして動作していたはずだという想像が示される
- そうなればARP storm、IGMP snooping bridge、bridging loopが消え、あらゆるルーティング問題をtracerouteで追跡できたはずだという期待が続く
- Ethernetパケットごとの送受信MACアドレス12バイト、wifiパケットごとのアドレス情報18バイトを削除できるため、IPv6がIPv4より24バイト大きいアドレスを使っても、Ethernetヘッダの除去を考えれば実質的な追加オーバーヘッドは12バイトにすぎないと計算している
- このように、いつかEthernetアドレスそのものを削除できるという期待が、IPv6アドレス長が過剰に大きいという選択を正当化する助けになったと述べている
- しかし、この美しい設計は現実世界では実現しなかった
夢へのレクイエム
- 「階層は追加されるだけで、削除はされない」という同僚の表現が全体の結論として示されている
- IPv6の利点は既存レガシーを捨てて再出発できることが前提だったが、現実にはそれはほとんど不可能だった
- IPv6普及率が99%に達しても、IPv4が完全に消えない限りEthernetアドレスもwifiアドレスも消えず、IEEE 802.3と802.11のフレーミング標準を維持する限り、そのバイト削減も実現しない
- そのためIPv6には結局、ARPよりさらに複雑なneighbor discoveryが必要になり、バスネットワークが消えた後でもARP的な動作をさせるため、ブロードキャストに似たシミュレーションが引き続き必要になった
- 家庭では古いIPv4電球を動かすためにローカルDHCPサーバを引き続き運用する必要があり、その電球がインターネットへ届くにはNATもなお必要だと書かれている
- さらに悪いことに、IPv6チームはmobile IP問題を解決できないまま残し、その結果としてひどいlayer 2ブリッジングが依然として必要になったと評価されている
- 当時はIPv6をまず数年以内に展開し、IPv4とMACアドレスが消えた後でmobile IPをより簡単に解決する計画だったのだろうと理解されると書かれている
- 当時は移動中のコンピュータ利用事例がほとんどないと見なされており、Ethernetポート間を移動しながらftpを継続する程度のぎこちない想像しかできなかったと描写されている
mobile IPというキラーアプリ
- その後の歴史では、持ち歩くコンピュータ、すなわち電話を複数の無線アクセスポイント間で移動させる利用形態が日常になった
- LTEではこうした移動はたいてい動作し、wifiではときどき動作するが、その秘密はInternetルーティングではなくlayer 2ブリッジングにあるという指摘だ
- Internetルーティングは移動性をまったく扱えず、IPネットワーク上で移動してIPアドレスが変わると、開いていた接続はすべて切れてしまう
- 企業向けwifiはLAN全体をlayer 2でブリッジし、中央DHCPサーバがどのアクセスポイントにぶら下がっても同じIPアドレスを与えるようにし、ブリッジ再構成中の数秒の混乱だけを許容して接続を維持する
- 複数のextenderやrepeaterを持つ家庭用wifiも同じ方式を使う
- 一方、道を歩きながら店舗ごとに提供される公衆wifiのように異なるwifiネットワークをまたぐと、そのたびに新しいIPアドレスが割り当てられ、毎回すべての接続が切れる
- LTEはさらに踏み込み、複数の基地局の間を数マイル移動しても同じIPアドレスを維持し、モバイルネットワークではたいていIPv6アドレスを使っていると述べられている
- その方法は、トラフィックを中央地点へトンネリングし、多数のファイアウォールとともに1つの超巨大な仮想layer 2 LANへブリッジするというもので、その代償として膨大な複雑さと恥ずかしいほどの追加遅延が発生する
- 通信事業者はこれを直したいと思っているが、ほとんど不可能だと述べている
mobile IPを実際に動かす方法 1
- mobile IPがなぜまともに機能しないのかという答えとして、セッション識別に使われる有名な4-tupleの定義が間違っている、という結論へつながる
- TCPとUDPのセッションは
(source ip, source port, destination ip, destination port)で識別されるが、この構造はlayer 3とlayer 4をまたいでおり、IPアドレス変化に弱い - セッション識別がlayer 4データだけで行われていれば、mobile IPは完全に機能したはずだという主張が示される
- 例として、X:1111がY:80と通信しているとき、XがQへアドレス変更すると、パケットは
(Q,1111,Y,80)となり、Yはそれを既存セッションと認識できず破棄し、Yが(Y,80,X,1111)として返すパケットももはやXには届かない - 代案として、ポート番号を現在の16ビットではなく128または256ビット程度の一意なハッシュ値へ拡大し、ソケットをIPアドレスとは無関係なタグで識別する構想が示される
- この場合、パケットは依然としてlayer 3で
(X,Y)アドレス情報を含んでルーティングされるが、カーネルは受信時にlayer 3情報をソケット識別に使わず、uuidだけを使う - 宛先ポート80は新規セッション開始時に希望するサービスを区別するためだけに必要で、その後は無視または省略できると書かれている
- Yのカーネルは
(uuid)セッションパケットが直近ではXから来ていたことをキャッシュし、XがQへ移動した後に同じ(uuid,80)タグ付きで届けば、そのセッションにマッチさせつつ応答先をXではなくQへ更新できる - こうすれば接続は維持できるが、なりすましによる接続乗っ取りを防ぐための追加の注意が必要だという但し書きが付く
- しかしUDPとTCPはそのようには動作せず、今からこれを変えるのは、IPv4をIPv6へ置き換えることのように簡単に見えたが数十年後も半分未満しか終わっていない類のプロジェクトだと評されている
QUICと回避可能な可能性
- 前向きな面として、もう1つの階層違反を通じて回避的な解決の可能性が示される
- 古いTCPを捨ててUDP上のQUICを使えば、UDPの4-tuple自体を接続識別子として使わない方式が可能になる
- UDPポートが特別なmobility layer用ポートであれば、その中身をさらに展開して適切なuuidタグを持つ内部パケットとして解釈し、それを正しいセッションやソケットへ対応付けられる
- 実験的なQUICプロトコルは、少なくとも理論上はこうした構造に合うパケット形式をすでに備えていると述べられている
- QUICが用いるステートレスなパケット暗号化と認証には、もともと一意なセッション識別子または鍵が必要なので、比較的少ない作業で透過的なroaming支援が可能かもしれないという期待が示される
- そうなれば、残るUDPとTCPをInternetからすべて取り除きさえすれば、今度こそ本当にlayer 2ブリッジングは不要になり、ブロードキャストやMACアドレス、SDN、DHCPもなくせるという結論につながる
- 最後はInternetの優雅さの回復という一文で締めくくられる
補足修正事項
-
2017-08-16 修正
- 先のmobile IP関連の構想はIPv6に限定されない
- IPv4とNAT環境、さらには複数NATをまたぐroamingでも動作可能だと修正された
-
2017-08-15 修正
- 接続乗っ取り防止策として、TCP開始時点のSYN-ACK-SYNACKに似た交換が最も単純な例として示される
- Yが新しいホストQの最初のパケットを即座に信頼すると、インターネット上のどこからでも攻撃者がX→Y接続を横取りしやすくなる
- Yがcookieを送り、Qがそれを受け取って処理し、再びYへ返すようにすれば、少なくとも単純な外部攻撃者ではなく中間者レベルでなければ攻撃できなくなる
- QUICのような暗号化プロトコルを使う場合、そのハンドシェイクもセッション鍵で保護できる
-
2017-10-24 修正
- QUIC以外にも、このようなroaming対応TCP代替プロトコル候補があり、MinimaLTが例として挙げられている
- MinimaLTはroaming問題を優雅に解決した最初のプロトコルだと聞いていると書かれており、今後採用される解決策もこの構造を模倣する可能性に言及している
-
2020-07-09 修正
- IPv4/IPv6移行と相互運用性についての追加の考えを別記事に投稿したという言及だけがあり、本文内の追加説明はない
1件のコメント
Hacker News の意見
私の見方では、IPv6 は完璧なプロトコル設計の頂点とまでは言えなくても、人々がより良いとして出してくる代案は結局 IPv6 に近い形へ収束していく。みなが継続的にこれより良いものを作れないのなら、IPv6 は結局かなり良い設計だということだと思う
過去の Hacker News の議論を集めてみると、2017 年のスレッド、2019 年のスレッド、2020 年のスレッド、2023 年のスレッド のように、この話題が数年おきに繰り返し現れている
私は、この記事が ARP をあまりに否定的に見ている点は気に入らない。ARP のおかげで、ルーターなしでも LAN 内で IP ネットワーキングが可能になり、デフォルトゲートウェイも同じ一般的な LAN IP 通信の特殊ケースとして扱える。ただ、ネットワーキングの歴史の説明自体は本当に素晴らしく、まだ IPv6 の部分を読んでいるところだ
私は、この記事が正確に何を言おうとしているのか少し混乱している。私のネットワーク機器が MAC アドレスを基に自動で IPv6 アドレスを設定するという話なのか、それが stateless IPv6 の核心なのか気になる。私の理解では、IPv6 は IPv4 枯渇と NAT の問題を解決するために出てきたものでもある。ところが私の Xbox は IPv6 がないとネットワークがいまひとつだと言ってくるが、これもかなり 北米中心的 な見方に思える
IPv6 で SLAAC と DHCPv6 の両方 を残したのは大きな失敗だったと、私はますます感じている。SLAAC 自体は素晴らしいが、設定メカニズムが二つあるのはあまりに分かりにくい。Android が DHCPv6 をサポートしていない点も混乱をさらに大きくしている。私の推測では、SLAAC はコンピューターが高価で DHCP サーバーが別個の機器だった時代の産物だ。しかし今はコンピューターが安く、ほとんどのルーターが DHCP を動かせるので状況が違う。DHCPv6 が基本的に MAC ベースのアドレスを配る方向に進んでいれば、設定はもっと単純だった気がするし、リンクローカルでは自動設定もそのまま維持できただろう
この記事はとても興味深かったが、一点よく理解できないところがある。著者は WiFi でも今は CSMA/CD を使わないと言っているが、では実際にはどう動いているのか気になる。著者は、同じアクセスポイントに接続された二つの WiFi ステーション同士も互いに直接通信しないと説明している。だとすると、各ステーションは自分が聞いている信号が自分宛てなのか、別のステーションが AP に送っているものなのか、あるいは AP が別のステーションに送っているものなのかを、どこかの時点で区別しなければならないはずだ。だとすれば、名前が違うだけで似たようなメカニズムは依然として必要なのではないかと思う
以前は IPv6 が避けられない次の段階のように見えたのに、今こうして勢いを失っているのを見ると、そもそも解決しようとしていた問題はそれほど重要ではなかったのではないかと思えてくる。実際の利用者の観点では、とにかく IPv4 アドレスを何とか十分確保してインターネットが回っているように見えたわけで、だから本当に IPv6 が必要だったのか自分でも疑問に思う。この結論が間違っているのか知りたい