IPv6が優れた設計だった世界 (2017)

 (apenwarr.ca)
11 ポイント 投稿者 GN⁺ 2026-04-21 | 1件のコメント | WhatsAppで共有
  • 初期のネットワークはポイントツーポイント接続が中心だったため、アドレス体系はほとんど不要だったが、コスト削減のためにバスネットワークが広がると、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のポイントツーポイントリンクを直接ブリッジングする方式には望みがなく、フラッディングベースの経路探索も低速リンクでは浪費が大きすぎた
  • ローカル環境では我慢できた非最適ルーティングも、低速で高価な長距離リンクでは致命的で、スケーラビリティがなかった
  • この問題群は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自体がすでにsoftware-defined networkだったという意味で、根本的に滑稽な面があると指摘されている
  • 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→ステーション方向を示し、2つのビットが同時に真なら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パケットごとに12バイトの送受信MACアドレス、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がクッキーを送り、Qがそれを受け取って処理し、再びYへ返すようにすれば、少なくとも単純な外部攻撃者ではなく中間者レベルでなければ攻撃できなくなる
    • QUICのような暗号化プロトコルを使う場合、そのハンドシェイクもセッション鍵で保護できる

  • 2017-10-24 修正

    • QUIC以外にも、このようなroaming対応TCP代替プロトコル候補があり、MinimaLTが例として挙げられている
    • MinimaLTはroaming問題を優雅に解決した最初のプロトコルだと聞いたと書かれており、今後採用される解決策もこの構造を手本にする可能性があると述べられている

  • 2020-07-09 修正

    • IPv4/IPv6移行と相互運用性についての追加の考えを別記事に投稿したという言及のみがあり、本文中の追加説明はない

関連記事

1件のコメント

 
GN⁺ 2026-04-21
Hacker News の意見

  • 私の見方では、IPv6 は完璧なプロトコル設計の頂点とまでは言えなくても、人々がより良いとして出してくる代案は結局 IPv6 に近い形へ収束していく。みなが継続的にこれより良いものを作れないのなら、IPv6 は結局かなり良い設計だということだと思う

    • 私には、それよりさらに強い話に見える。人々が出してくるほとんどすべての より良い代案 は、実際には IPv6 の設計過程ですでに検討され、たいていは十分な理由をもって却下されたアイデアだった
    • 振り返ると IPv4 に 16 ビットか 32 ビットを足すだけでも十分だったようにも思えるが、それでも IPv6 が悪くなく、ちゃんと動いているという点には同意する。私が聞く不満の大半は無知から来ているが、例外が一つあって、それが 長いアドレス だ。これは本当に不便で、人間向けのエンコーディングとしても今ひとつなので、可読性の高い表記方法に変えるだけでもかなり助けになると思う
    • 私はその解釈には同意しない。世界は変わり続けていて、IPv6 は 1998 年に ネットワーク機器ベンダー の必要を中心に設計されたと見ている。エンドユーザーやネットワーク管理者、アプリ開発者の視点は十分に反映されていなかったと感じる。今まで残っている理由も、かなりの部分が 埋没コスト と古い技術的負債のためだと思う。今日新たに設計するなら、SD-WAN、モバイル需要、チップ価格の変化といった条件はまったく異なるので、別のプロトコルが出てくる可能性が高い。私はソースアドレスと宛先アドレスという概念そのものも見直すべきだと思う。2026 年に、デフォルトで 0RTT 暗号化のないネットワーク層は時代遅れに感じる。ND、ARP、RA、DHCP のように基本的に信頼を前提とする要素も、認証がないので不安だ。隣のデバイスが特定のアドレスを持っていると主張したら、なぜ私のデバイスがそのまま信じなければならないのか疑問だ。有線でも無線でも、ネットワークに接続するときになぜ相手ネットワークの安全性や身元体系を検証しないのかももどかしい。セキュリティ、信頼、アイデンティティの問題が中心であるべきなのに、そうなっておらず、新機能も結局はベンダーの収益構造に合わせられている感じが強い。セキュリティ以外でも、数字ベースのアドレスではなく identity-based addressing に向かう方向が重要だと思う。この技術への依存度があまりに大きいだけに、政府の関与も必要だと感じるし、未来の世代や火星植民地にまで 2005 年式のアドレスとセキュリティ問題を引き継がせるのはやるせない
    • 私は、彼らがこれ以上うまくできなかったというような解釈には同意しない。単に 出して終わり だった感じが強い。IPv6 のように大きく変えるより、もっと何度も磨いて IPv4 の延長線に近い ipv4+ を作るべきだったと思う

  • 過去の Hacker News の議論を集めてみると、2017 年のスレッド、2019 年のスレッド、2020 年のスレッド、2023 年のスレッド のように、この話題が数年おきに繰り返し現れている

  • 私は、この記事が ARP をあまりに否定的に見ている点は気に入らない。ARP のおかげで、ルーターなしでも LAN 内で IP ネットワーキングが可能になり、デフォルトゲートウェイも同じ一般的な LAN IP 通信の特殊ケースとして扱える。ただ、ネットワーキングの歴史の説明自体は本当に素晴らしく、まだ IPv6 の部分を読んでいるところだ

    • もちろん、レイヤー 2 アドレスを解決する方法が ARP だけだとは思わない。ARP は 階層違反 と過剰なブロードキャストトラフィックを生み、それが WiFi のような環境で追加の問題を引き起こすと感じる。たとえば IPv6 の NDP は ICMPv6 ベースの実際の IPv6 パケット上で動くので、こうした違反がなく、マルチキャストのおかげでレイヤー 2 全体にブロードキャストを撒く必要も減る

  • 私は、この記事が正確に何を言おうとしているのか少し混乱している。私のネットワーク機器が MAC アドレスを基に自動で IPv6 アドレスを設定するという話なのか、それが stateless IPv6 の核心なのか気になる。私の理解では、IPv6 は IPv4 枯渇と NAT の問題を解決するために出てきたものでもある。ところが私の Xbox は IPv6 がないとネットワークがいまひとつだと言ってくるが、これもかなり 北米中心的 な見方に思える

    • 正確に言うと、最近のほとんどのサーバー以外の機器は、MAC アドレスや EUI64 の代わりに RFC8064 と RFC7217 で述べられている semantically opaque interface identifiers を使う傾向にある。安定したアドレスは主にインバウンド向けに使われ、アウトバウンドには時間とともに変わる一時的な privacy address を使える。そして stateless というのは、DHCPv6 のような中央設定なしに、機器が SLAAC で自分でアドレスを構成するという意味で成り立っている
    • 私は、Xbox が文句を言っているのは IPv6 自体より UPnP の欠如 である可能性が高いと思う。もちろん IPv6 があれば、その種の問題の一部は減らせるかもしれない。ただ皮肉なことに、コンソール側は IPv6 対応がむしろ遅かった方なので、Xbox が実際にどこまでうまく対応しているのか私も気になる
    • むしろ私は、IPv4 なしで Xbox がちゃんと動くのか気になる。私の会社の Windows 機はそうではないし、他のゲーム機にも IPv4 依存が残っていることを知っている

  • IPv6 で SLAAC と DHCPv6 の両方 を残したのは大きな失敗だったと、私はますます感じている。SLAAC 自体は素晴らしいが、設定メカニズムが二つあるのはあまりに分かりにくい。Android が DHCPv6 をサポートしていない点も混乱をさらに大きくしている。私の推測では、SLAAC はコンピューターが高価で DHCP サーバーが別個の機器だった時代の産物だ。しかし今はコンピューターが安く、ほとんどのルーターが DHCP を動かせるので状況が違う。DHCPv6 が基本的に MAC ベースのアドレスを配る方向に進んでいれば、設定はもっと単純だった気がするし、リンクローカルでは自動設定もそのまま維持できただろう

    • ちなみに Android 11 からは Prefix Delegation 形式の DHCPv6 サポートはある。ただ、関連する記事 を見ると、依然としてプラットフォーム側の 自分たちの方がよく分かっている 式のアプローチに感じられる部分があると思う

  • この記事はとても興味深かったが、一点よく理解できないところがある。著者は WiFi でも今は CSMA/CD を使わないと言っているが、では実際にはどう動いているのか気になる。著者は、同じアクセスポイントに接続された二つの WiFi ステーション同士も互いに直接通信しないと説明している。だとすると、各ステーションは自分が聞いている信号が自分宛てなのか、別のステーションが AP に送っているものなのか、あるいは AP が別のステーションに送っているものなのかを、どこかの時点で区別しなければならないはずだ。だとすれば、名前が違うだけで似たようなメカニズムは依然として必要なのではないかと思う

    • 私の知る限り、WiFi はもともと CSMA/CA を使っており、802.11ax からは OFDMA も併用している。この背景は Hidden node problem の説明 でよく分かる

  • 以前は IPv6 が避けられない次の段階のように見えたのに、今こうして勢いを失っているのを見ると、そもそも解決しようとしていた問題はそれほど重要ではなかったのではないかと思えてくる。実際の利用者の観点では、とにかく IPv4 アドレスを何とか十分確保してインターネットが回っているように見えたわけで、だから本当に IPv6 が必要だったのか自分でも疑問に思う。この結論が間違っているのか知りたい

    • 私は、ここで言う 私たち が誰を指すのか曖昧だと感じる。昔は申請すれば /24 ももらえたが、今では閉鎖されたスパマーネットワークが使っていた帯域を中古で買うしかなく、そのせいで IP レピュテーション が最悪ということも多い。自分で何かをホスティングしようとしても、大規模ネットワーク単位でなければ、実質的に米国企業から IPv4 を 1 つ借りるしかない状況がよくある。私には、これはウランが理論上は市場にあると言いながら、実際には極めて手に入りにくい状況に少し似ている
    • 私はその問題は今でも重要だと思う。NAT のような回避策が存在すること自体がその証拠だと感じる。人々はますます劣悪な環境に慣れてしまい、高遅延の通話品質や Cloudflare のようなインフラが止まったときに通信全体が止まる状況さえ当然のように受け入れている。しかしインターネットは本来、そうした中央依存を避けるために設計されたものだ。私には、これを問題ではないと言うのは、今日出勤できたから 交通渋滞 は問題ないと言うようなものに聞こえる。もっと長いスパンで、もっと大きな視点で見るべきだと感じる