IPv6 が優れた設計であった世界（2017 年）。

IP ベースの優れた設計を可能にすべきだった世界

昨年、私は IETF（インターネットエンジニアリングタスクフォース）の会議に参加しました。IETF は面白い場所です。大まかに言えば、現状維持のための地味な作業が約 1/3、既存技術の拡張が約 1/3、そして青い空を夢想する狂気的なアイデアが約 1/3 という割合で構成されています。私が主に出席した理由は、そこで初めて提示される TCP BBR（BBR は新しい TCP の congestion control アルゴリズム）に対する人々の反応を見てみたいと考えたからです。（答えは：概ね肯定的だったが、疑念に包まれていた。「あまりにも良くできすぎているように思える」という感じでした。）

さて、IETF の会議には IPv6 に関する多数の発表がありました。IPv4 を置き換えるために考案されたのが IPv6 で、インターネットの基盤となっているものです。（一部では「置き換えは既に始まっている」と言う人もいれば、「既に完了してしまった」と言う人もいるでしょう。）これらの IPv6 に関する発表 alongside に、IPv6 が素晴らしいと絶賛し、人類最大の発明であると信じ込み、いつだって今日中に一般化して IPv4 が廃れると確信している人々も大勢いました。彼らにとって IPv4 はただの巨大なハックの山であり、インターネットをエレガントなものとして蘇らせるために即座に死ねると考えているようです。

私はこの機会を活かし、事態の本質を理解しようと考えました。なぜ IPv6 は IPv4 に比べてこんなに複雑で混乱しているのでしょうか。単にアドレスビット数を増やした IPv4 があればよかったですよね。でも、そうではなかったのです。「ああだめだめ」という感じです。そこで私は周囲の人たちに聞き込みを始めました。以下が私が得た結論です。

バスのせいですべてが台無しになった

かつては電話網があり、物理的な回路交換を使用していました。つまり、コンector を移動させて電話の接続を文字通り長い一本の線（「OSI 第 1 層」）として実現するというものでした。「専用回線」とは電信局から借りた超長距離ケーブルのことです。線の一端にビットを入力すると、固定された時間後に另一端から同じビットが出てくる仕組みです。アドレスは不要で、線の両端にはそれぞれ正確に 1 つの端末しか存在しませんでした。

やがて電信側はその仕組みを改良し、時分割多重化（TDM）と「仮想的な回路交換」が生まれました。電信局は、複数の低速回線からのビットを透明に集約し、多重器と復調器を使ってまとめて処理することで、以前よりも少ないケーブル数で電話システム全体を通過させることができました。これを機能させるのは少し複雑でしたが、当時のモデムユーザーにとっては「線の一端にビットを入れて另一端から出てくる」という点さえあれば何ら不都合はありませんでした。アドレスも不要でした。

インターネット（当時の名称はこれではなく）はこの回路網の上に構築されました。ビットを入れられる多数の線があり、そこから他の端に出てくることができました。もし一つのコンピュータが 2 つまたは 3 つのインターフェースを持っていれば、適切な指示を与えられれば、1 つの線のビットを別の線に転送することができ、各ペアのコンピュータ間の独立した回線を敷設するよりもはるかに効率的な通信が可能になります。こうして IP アドレス（「第 3 層」）、サブネット、ルーティングが生まれました。なお、この時点でもポイントツーポイントリンクであっても MAC アドレスは不要でした。パケットが線に入ったら、出てくるのはあて先のみですので。IP アドレスを使ってパケットが出た後の行き先を決定したのです。

同時に、LAN という別の選択肢も登場しました。自分の局所的な場所でコンピュータ（あるいは端末とメインフレーム）を接続したい場合、衛星のような複数のコンピュータそれぞれに専用の線を引き、スター状に配置する必要があるのは不便でした。電子機器のコスト削減の観点から、「バスネットワーク」（後に重要になる用語「ブロードキャストドメイン」と呼ばれることもありますが）を採用した人がいました。これは多数のステーションを単一の線に接続し、その線上にある他のどのステーションとも通信できるようにするためのものでした。これらの LAN を構築する人々はインターネットを構築する人々とは異なり、IP アドレスはこの用途には使いませんでした。各自が独自のプロトコル（「第 2 層」）を発明しました。

初期のバス型ローカルネットワークの一つに ARCNET がありました。私にとって非常に懐かしく、1990 年代（ARCNET が廃止された後ですが）にも Linux용 ARCNET ドライバや ARCNET ポエミを書きました。ARCNET の第 2 層アドレスは極めて単純で、ネットワークカード背面のジャンパまたは DIP スイッチで設定される 8 ビットだけでした。ネットワーク所有者として、アドレスの設定と重複の回避を自分で管理する必要があり、失敗すると大災害が待っていました。これは面倒でしたが、ARCNET ネットワークは通常比較的小規模だったため、それほど致命的ではなかったのです。

数年后に登場したイーサネット（Ethernet）は、第 2 層アドレスでより多くのビット（実際には 48 ビット）を使うことでこの問題を一度とくことに成功しました。製造されたすべてのデバイスに対して重複のない「シャード化シークエンス」のアドレスを割り当てることができ、これだけあれば十分です。つまり、イーサネット MAC アドレスが誕生したのです。

様々な LAN 技術が登場して姿を変えましたが、私のfavoriteの一つである IPX（Internetwork Packet Exchange）や Netware もその一部です。（ただし、「真実の」インターネットとは関係はありませんでした。）これらはクライアントとサーバーが単一のバスネットワーク上の場合のみ非常にうまく機能しました。アドレスの設定は一度も必要なく、美しく、信頼性が高く、実用的でした。まさにネットワークの黄金時代といって過言ではありません。

もちろん、それを壊す者が現れました：大規模企業や大学のネットワークです。彼らは столько のコンピュータを共有する必要があり、単一のバスネットワークで 10 Mbps を共有するのは大きなボトルネックになったので、複数のバスを持ち、それらをインターコネクト（「インターネット」という言葉そのものです）する方法が必要でした。「当然と言えば当然！」と思うかもしれません。「Internet Protocol を使えばいいでしょう？」と。しかし、そうではありませんでした。当時、Internet プロトコルはまだ成熟しておらず、一般にも普及しておらず、誰もそれを真剣に受け止めませんでした。Netware-over-IPX（および当時の他の多数の LAN プロトコル）は本気のビジネスであり、すでに一般的なイーサネットを拡張する方法として独自の技術を開発しました。イーサネット上のデバイスには既に MAC アドレスがあり、これが様々な LAN プロトコルの間で唯一合意できたものでしたが、ルーティングメカニズムのキーとしてイーサネットアドレスを使うことに決めたのです。（実際にはルーティングではなく「ブリッジング」と「スイッチング」と呼んでいました。）

問題なのは、イーサネットアドレスが工場出荷時に連続して割り当てられるため階層構造を持つことができないことです。これは現代の IP ルーティング表（サブネット全体を一度に処理できる）ほどの使いやすさはありません。「ブリッジテーブル」の効率を下げる結果となりました。MAC アドレスごとにどのネットワークバスにあるかを記憶する必要があります。人間が手動でこれらを設定するのは面倒なので、自動で自分自身を見つけ出す必要がありました。複雑なインターネットワークでブリッジを構成すると、少し複雑になります。私には、これが「スパンニングツリーアルゴリズム」という有名なものを生んだのだと思います。网络における詩は非常に重要です。

いずれにせよ、概ね機能しましたが、かなり混乱していました。ブロードキャスト洪水が時々発生し、経路も必ずしも最適ではなく、デバッグするのもほぼ不可能でした。（ブリッジングに対して traceroute のようなツールを書くことはできませんでした。中間のブリッジ自体がアドレスを持っていたりする基本的な前提すら、通常のイーサネットでは存在しないからです。）

一方で、これらのブリッジはハードウェア最適化されていました。システム全体を設計したのは基本的にハードウェアエンジニアであり、ソフトウェア（マルチバスとそれらの間でのブリッジングについて何も知らない）を欺いて大規模ネットワークで動作できるようにしました。「ハードウェアブリッジング」と言えば、イーサネットの速度そのものに相当する非常に高速な転送が可能になりました。現在はそれほど特別に見えませんが、当時は非常に画期的でした。イーサネットは 10 Mbps で動作しましたが、これは単一のコンピュータが 10 Mbps を飽和させるのではなく、ネットワークに多数のコンピュータを接続することで飽和させられる速度だったのです。当時の常識からすれば荒唐無稽な話でした。

いずれにせよ、要点は「ブリッジングは混乱しておりデバッグ不能だが、非常に高速であった」ということです。

バス上へのインターネットの導入

その間、インターネット関係者は忙しくありましたが、もちろん優れた安価な LAN 技術の発明には目をつぶりませんでした。おそらくこの頃か、ARPANET が正式に「Internet」と改名された時期だったと思われます。（私は確信がありませんが、こう書くと話がよくなります。）

やがて、個々のインターネット接続されたコンピュータをポイントツーポイント長距離リンクでつなぐことから、全体としての LAN をポイントツーポイントリンクでつなぐという願望に進化した時期がありました。つまり、長距離ブリッジを作りたいと思いました。

「さあ、長距離ブリッジを作るだけで済むでしょう」と思われるかもしれません。そう簡単にできるとは限りません。ここで詳しく説明することはできませんが、基本的な問題は輻射制御（congestion control）です。イーサネットブリッジの深淵で恐ろしい秘密は、すべてのリンクが同じ速度であるか、あるいは完全に輻輳していないことを前提としていることです。なぜなら、減速する手段がないからです。データを出し惜しみせず、できるだけ速く流して「到着してくれる」と期待します。しかし、イーサネットが 10 Mbps でポイントツーポイントリンクが 0.128 Mbps の場合、これは完全に絶望的です。さらに、経路を決定するためにすべてのリンクにブロードキャストを送り正しいものを見つけるというアイデア（これが典型的なブリッジングの動作方法ですが）は、低速リンクにとっては極めて非効率的です。低レイテンシで高スループットのローカルネットワークではわずかな不具合に過ぎない「最適ではない経路選択」も、低速で高価な長距離リンク上では深刻な問題となります。つまり、スケールしないのです。

幸いなことに、当時のインターネット関係者（まだ Internet と呼ばれていたかどうかは別として）は、まさにこの問題のセットに取り組んでいました。もしイーサネットバスを互いにつなぐために Internet の仕組みを使えるなら、素晴らしい状況になるはずです。

そこで、イーサネット（ARCNET やその他の LAN についても同様です）上でインターネットパケットを送るための「フレーム形式」が設計されました。

そのときからすべてが悪化し始めました。

解決する必要があった最初の問題：イーサネット上に Internet パケットを送出した際、どのマシーンがそれを「聞く」必要があり、あるいは中継すべきかは明確ではなくなりました。同じイーサネットセグメント上にある複数のインターネットルーターがあると、すべてがパケットを受け取ろうとするとパケットストームやループが発生します。いいえ、イーサネットバス上のどのルーターを拾うべきか選らばなければなりません。IP 宛先フィールドを使えません。なぜならそれは最終宛先に使っており、ルーター宛先としては不適切だからです。代わりに、イーサネットフレーム内の MAC アドレスを使って希望するルーターを特定します。

つまり、ローカルの IP ルーティング表を設定する際、「MAC アドレス 11:22:33:44:55:66 のルーターを経由して、IP アドレス 10.1.1.1 にパケットを送信」と表現できる必要があります。これが本当の意図です。重要です！宛先は IP アドレスですが、ルーターは MAC アドレスです。しかし、もしかつてルーティング表を設定したことがあれば、「そう書かれていない」ことに気づいたでしょう。代わりに、OS の TCP/IP スタックを開発者たちが頑固であるため、「IP アドレス 192.168.1.1 を持つルーターを経由して IP アドレス 10.1.1.1 にパケットを送信」といった形で書くことになります。

実際には、これは問題を複雑にしています。OS はまず 192.168.1.1 のイーサネットアドレスを検索し、それが 11:22:33:44:55:66 であることを確認し、最後に宛先イーサネットアドレス 11:22:33:44:55:66 と宛先 IP アドレス 10.1.1.1 を持つパケットを生成する必要があります。192.168.1.1 はパケット中に何処にも現れません。人間レベルでの抽象化に過ぎません。

その無駄な中間ステップを行うには、ARP（アドレス解決プロトコル）を追加する必要があります。これは IP とは異なる単純な非 IP プロトコルで、IP アドレスをイーサネットアドレスに変換するのが役割です。これはローカルのイーサネットバス上の全ステーションにブロードキャストし、「この IP アドレスを持っていますか？」と問い合わせて実現します。もしブリッジがあれば、ARP パケットはすべてエーサネットブロードキャストパケットなので、すべてのインターフェースへ転送しなければなりません。それがブロードキャストの定義です。大規模で忙しく多くの LAN が相互接続されたイーサネットでは、過剰なブロードキャストが最大の悪夢の一つになります。特に Wi-Fi では深刻です。時間とともに、人々は ARP を技術的に指定されている範囲で転送しないように特殊なハックを施したブリッジ/スイッチを開発し始めました。一部のデバイス（特に Wi-Fi アクセスポイント）は、問題を軽減するために偽の ARP 応答を出すこともありました。いずれにせよ、これらはすべてハックであり、時に必要なハックです。

レガシーによる死

時間が経過しました。やがて（実際にはかなり時間がかかりましたが）、イーサネット上の非 IP プロトコルを使うことはほぼなくなりました。つまり、すべてのネットワークは物理的な線（第 1 層）上に多数のステーションがバスとして配置され（第 2 層）、複数のバスがブリッジで接続され（お見通し！まだ第 2 層！）、それらのバス間の接続が IP ルーター（第 3 層）によって行われる構造になりました。

しばらくして、IP アドレスを手動で ARCNET のように設定することに疲れた人々が、自動設定（イーサネット風）を望むようになりました。しかし、物理的にイーサネット風にはならなかったのは、a) デバイスは既に製造され、IP アドレスではなく MAC アドレスが搭載されており、b) IP アドレスは 32 ビットしかなく、永続的な重複のない製造には不十分であり、c) サブネットを使わずに単に IP アдресを連続して割り当てると、元に戻るだけで、すでにイーサネットがある状態に戻ってしまうからです。

そこで BOOTP と DHCP が誕生しました。実はこれらも ARP と同様に特別なプロトコルですが、IP パケットであることを prettending しています（技術的には IP パケットです）。特殊である必要があります。なぜなら、IP ノードは IP アドレスをまだ持っていない状態でこれらのパケットを送信できる必要があるからです。これは当然不可能なので、IP ヘッダーに本質的に無意味な内容（ただし RFC で指定された無意味）を埋め込みます。ヘッダー自体を削除しても良かったはずですが。もし新たな非 IP プロトコルを開発すると誰も満足しないので、「IP である」とpretending し、それで心地よくなりました。まあ、DHCP を考案する者が感じる心地よさは別として。

さて、ここで話は脱線します。

重要な点は、リアルな IP サービスとは異なり、BOOTP と DHCP はイーサネットアドレスを知っていなければならないことです。なぜなら彼らの仕事はあなたのイーサネットアドレスを聞き取り、それに合う IP アドレスを割り当てることだからです。基本的には ARP の逆ですが、「そんなことは言えない」のです。ARP の完全な逆のプロトコルが「RARP」という名前があるためです。実際、RARP は BOOTP や DHCP と同じことをしてはるかにシンプルでしたが、私たちはその話をするではありません。

ここで重要な点は、イーサネットと IP がさらにさらに混ざり合ってきていることです。今ではほぼ分離不可能です。48 ビットの MAC アドレスなしのネットワークインターフェース（PPP0 の場合を除く）を想像するのは難しく、IP アドレスなしで動作するそのインターフェースも想像できません。IP ルーティング表は IP アドレスを使って記述しますが、もちろんルーターを IP アドレスで呼んでいるのは嘘であることを知っています。MAC アドレス経由でルーティングしたいと間接的に言っているだけです。ARP は実際にはブリッジされていませんが、DHCP は IP パケットながら本質的にはイーサネットプロトコルであり、そのように続いています。

さらに、ブリッジングとルーティングの両方が存在しており、LAN とインターネットがそれぞれ複雑になるにつれて、どちらもさらに複雑になっています。ブリッジングは主にハードウェアベースで IEEE（イーサネット標準を制御する人々）によって定義されています。ルーティングは主にソフトウェアベースで IETF（インターネット標準を制御する人々）によって定義されています。両団体は相手が存在しないかのようにpretending します。ネットワークオペレーターは、必要な速度と DHCP サーバーの設定に対する憎しみ（非常に苦手）に基づいてブリッジング対ルーティングを選択します。つまり、できるだけブリッジングを使い、必要に応じてルーティングを使います。

実際、ブリッジングは完全に脱制御になりすぎて、第 2 層のブリッジング決定を完全に上位レベルに抽出することに決めました。（当然ながら、この決定は IP を上層のプロトコルで通信します！）それが「ソフトウェア定義ネットワーク（SDN）」と呼ばれるものです。スイッチやブリッジが勝手にやらないよりはよっぽど良いですが、根本的に愚かしいのも事実です。「ソフトウェア定義ネットワーク」って知っていますか？それは IP です。歴史的に、大きくなりすぎたネットワークを相互接続するためのソフトウェア定義ネットワークこそが IP でした。問題は、IPv4 は当初ハードウェア加速が難しく、しかもハードウェア加速もされなかったこと、そして DHCP の設定は本当に地獄のような作業なので、ネットワークオペレーターはブリッジングを使ってより大きなものを扱う方法を学びました。現在では大規模データセンターはほぼ完全に SDN 化されており、データセンター内で IP を使わなくても良さそうです。なぜならパケットをルーティングしていないからです。すべてが一つの巨大な仮想バスネットワークです。

要するに、混乱しています。

さあ、あの話は忘れてください……

面白いですね？いいですねえ。さて、それらは全て起きなかったとして、1990 年代初頭に戻ってください。実際にはその大半は既に起きていましたが、IETF の人々はそれが起きていないふりをして、「近い将来」の災害をすべて回避できるとpretending していました。これが良いところです！

上記の長い話で忘れ去ったことがあります：一連のイベントの中で、私たちはバスネットワークの使用を完全にやめました。イーサネットはもうバスではありません。ただバスのふりをしているだけです。基本的には、イーサネットの有名な CSMA/CD が速度増加に伴い機能し続けることができなかったので、昔ながらのスーパートポロジに戻りました。スイッチからケーブル束を走らせて、各ステーションから中心点まで一直線の配線を行う仕組みです。壁や天井、床は太く高価なイーサネットの束で埋め尽くされています。バスがうまく機能しないことができないためです……第 1 層においてです。考えてみると可笑しいですよね。悲しいことが可笑しいと思えるなら。

実際、Wi-Fi という究極のバスネットワーク（文字通り誰でも同じオープンエアの「バス」を共有）でも、例外なく「インフラストラクチャモード」と呼ばれるモードで使われ、巨大なスタートポロジをシミュレートしています。同じアクセスポイントに接続された 2 つの Wi-Fi ステーションは、互いに聞こえても直接通信せず、パケットをアクセスポイントに送り、宛先 MAC アドレスを別のノードに設定します。アクセスポイントがそれを目的地ノードに戻し送ります。

ホースを止めて、一度だけこれを見直してみましょう。 少し注意が必要です。ノード X が IP ルーター Y を通じて Wi-Fi アクセスポイント A を介してインターネットノード Z に送信する時、パケットはどうなるでしょうか？画像を描くと、以下のように起こりたくなります：

X -> [wifi] -> A -> [wifi] -> Y -> [internet] -> Z

Z は IP 宛先なので、当然 IP 宛先フィールドは Z です。Y はルーターで、前述の通りイーサネット宛先フィールドに Y のイーサネット MAC アドレスを使うことで指定します。しかし Wi-Fi では、X が Y に直接パケットを送ることはできません（WPA2 暗号鍵を共有していないなどの理由から）。A に送らなければなりません。では A のアドレスはどこに入れるのかとお思いでしょうか？

問題ありません！802.11 には「3 アドレスモード」という機能があります。フレームごとに 3 つ目のイーサネット MAC アドレスを追加し、実際のイーサネット宛先と中間のイーサネット宛地について話せます。さらに、"to-AP" と "from-AP" というビットフィールドがあり、パケットがステーションからアクセスポイントへ、あるいは逆方向かを示します。しかし、両方同時に真になることがあり、それは Wi-Fi リピータ（AP が AP にパケットを送る）を作るための仕組みです。

Wi-Fi リピータについて！もし A がリピーターなら、ベースステーションである B に向けて中継する必要があります：

X -> [wifi] -> A -> [wifi-repeater] -> B -> [wifi] -> Y -> [internet] -> Z

X->A は 3 アドレスモードを使いますが、A->B では問題があります。イーサネット送信元アドレスは X で、宛先アドレスは Y ですが、空中で実際にパケットを送るのは A から B です。X と Y は全く関与していません。十分なことを言えば、「4 アドレスモード」というものがあり、思いつく通り機能します。

（802.11s メッシュネットワークでは 6 アドレスモードもあり、それ以上理解しようとするとここで放棄しました。）

Avery、IPv6 を約束してくれたのにまだ出てこない！

ああ、失礼しました。この投稿は少し脱線してしまいましたね。

全体の要点です。IETF の人々が IPv6 を考えながら、この混乱を見て（もしかしたらいくつかの追加的な混乱も予見していたかもしれませんが、SDN や Wi-Fi リピータモードまでは予測できなかったでしょう）、と言いました。「ちょっと待て、ここで止めてほしい。これら全てのゴミは必要ない！じゃあ世界はこうならんか？」

• 物理的バスネットワークを廃止（既に完了！）
• 第 2 層のインターネットワークを廃止（これが第 3 層の役割だ）
• ブロードキャストを廃止（第 2 層は常にポイントツーポイントなので、ブロードキャストを誰に送るのか？マルチキャストで置き換える）
• MAC アドレスを廃止（ポイントツーポイントネットワークでは送信元・宛先が明らかで、IP アドレスを使ってマルチキャストできる）
• ARP と DHCP を廃止（MAC アドレスがないため、IP アドレスと MAC アドレスのマッピング也不需要）
• IP ヘッダーの複雑性を廃止（IP ルーティングのハードウェア加速のため）
• IP アドレス不足を解消（大きなサブネットを再度ルーティングできるようになる）
• 核心を除いては手動での IP アドレス設定を廃止（大量の IP アドレスがあるため、そこから再帰的にサブネットを配れる）

想像してみましょう：そのような世界に住んでいましたら、Wi-Fi リピータも IPv6 ルーターです。Wi-Fi アクセスポイントもそうです。イーサネットスイッチも SDN も同様です。ARP ス torm はなくなります。「IGMP スヌーping ブリッジ」も消えます。ブリッジループも消えます。すべてのルーティング問題は traceroute で追跡可能になります。そして何より、各イーサネットパケットから 12 バイト（送信元・宛先イーサネットアドレス）、各 Wi-Fi パケットから 18 バイト（送信元・宛先/AP アドレス）を削除できます。確かに IPv6 は IP アドレス自体に 24 バイト追加していますが、イーサネットから 12 バイト削除するので、追加オーバーヘッドはたったの 12 バイト而已。IPv4 で 2 つの 64 ビット IP アドレスを使うのにイーサネットヘッダーを保持する必要と同じくらいです。「 someday イーサネットアドレスを削除できる」というアイデアが、膨大な IPv6 アドレスサイズを正当化するのに役立ちました。

それは素晴らしかったはずです。しかし一つの問題：それは決して起こりませんでした。

夢のためのレクイエム

職場の誰かが最も端的に表現しました。「レイヤーは常に追加され、削除されることはあり得ない」。この素晴らしい話は、過去に構築したレガシーなゴミを捨ててやり直す能力に依存していました。残念ながら、それはほぼ不可能です。IPv6 が 99% の浸透率になっても IPv4 を排除できる保証はありません。もし IPv4 を排除できなければ、イーサネットアドレスや Wi-Fi アドレスも排除できません。IEEE 802.3 や 802.11 フレーミング標準を使い続ける限り、そのバイトを節約することはないでしょう。したがって、「IPv6 ネイバーディスカバリー」プロトコル（ARP のより複雑なバージョン）は常に必要です。バスネットワークがなくなったとしても、ARP が機能する方法であるブロードキャストのシミュレーターは常に必要です。家庭にローカルの DHCP サーバーを稼働させ続ける必要があります（レガシーな IPv4 のライトバルブを動かすため）。NAT を使い続ける必要があります（レガシーな IPv4 のライトバルブがインターネットにアクセスするため）。

それどころではありません。最悪なのは、IPv6 チームが見落とした別のミスのせいで、第 2 層のブリッジングという無限の悪魔仍然存在することです。不幸にも、1990 年代に IPv6 を青い空で考えていた時、「モバイル IP」の問題を解決することを怠りました。私の理解では、当初は IPv6 のデプロイを先に進め（数年しかかからないはず）、IPv4 と MAC アドレスが排除された後にそれを処理する予定でした。その時点で解決しやすくなるはずで、その間はまだ「モバイル IP デバイス」を持っている人は誰もいなかったでしょう。「モバイル IP」とは一体何を意味するのか：ラップトップを持って複数のイーサネットポートを順番に繋ぎながらファイルを転送する？愚かな話です。

キラーアプリ：モバイル IP

もちろん、さらに数世紀の歴史を経て、今ではコンピュータ（スマートフォン）を持ち歩き、無線アクセスポイントを次々に接続することをいくつかの使用ケースを知っています。常にそれをしています。LTE ではほぼ機能します！Wi-Fi でも時々機能します。良いですよね？

残念ながら、インターネットの秘密の恥ずかしげのない事実があるためです：それらの機能はすべて第 2 層ブリッジングに依存しています。インターネットルーティングは.mobility を全く処理できません。IP ネットワーク上を移動すると IP アドレスが変更され、オープンなすべての接続が切断されます。

企業の Wi-Fi ネットワークはこの問題を欺きます。第 2 層で WAN の全体をブリッジして、中央の巨大な DHCP サーバーがどの企業 Wi-Fi アクセスポイントに繋がっても同じ IP アドレスを割り当て、その後パケットをあなたに到達させます（ブリッジ再構成による最大数秒の混乱のみ）。新しい家庭用 Wi-Fi システム（複数のエクス tender/リピータ）も同様のトリックを使います。しかし、通りを歩く途中で一つの Wi-Fi ネットワークから別のネットワークに切り替える場合（例えば一連の店舗にある「パブリックWi-Fi」サービス）は残念ながらできません。それぞれが新しい IP アドレスを与え、IP アドレスが変わるたびにすべての接続を失います。

LTE はさらに努力します。モバイルネットワークでは通常 IPv6 アドレスですが、何マイルも移動して多数のセルタワーを転々としてでも IP アドレスを維持します。どうでしょうか？それは……通常、あなたのトラフィックをすべて中央地点にトンネルして、その後ファイアウォールを介して一つの巨大なバーチャル第 2 層 LAN にブリッジ化（非常に複雑で、本当に恥ずかしいほどの余分なレイテンシをもたらします）することで実現しています。接続は維持されます。

モバイル IP を実際に機能させること

さて、この話は長かったですが、最終的に IETF の人々から引き出しました。ここに来た時（モバイル IP という問題）、思わず尋ねました。何が間違っていたのか？なぜ機能させられないのか？

答えは驚くほどシンプルです。有名な「4 タプル」（送信元 IP、送信元ポート、宛先 IP、宛先ポート）の定義に大きな設計上の欠陥がありました。4 タプルを使って特定の TCP または UDP セッションを識別します。パケットがその 4 つのフィールドを持つ場合、それは特定のセッションに属し、それを処理するソケットへ配信できます。しかし、4 タプルは二つのレイヤーを跨いでいます：インターネットワーキング（第 3 層）とトランスポート（第 4 層）。もしセッションを第 4 層のデータのみで識別していれば、モバイル IP は完璧に機能したでしょう。

簡単な例を見てみましょう。X ポート 1111 が Y ポート 80 と通信している場合、4 タプル (X,1111,Y,80) を持つパケットを送ります。応答は (Y,80,X,1111) で返り、カーネルが元のパケットを生成したソケットへ配信します。X がさらに (X,1111,Y,80) でタグ付けされたパケットを送ると、Y はそれらを同じサーバーソケットへ全て配信し、そのように続きます。

次に、X が IP アドレスを変更して Q になる場合、新たに (Q,1111,Y,80) のパケットを送ります。Y はそれが何を意味するのか理解できず、捨ててしまいます。一方、Y が (Y,80,X,1111) でタグ付けされたパケットを送っても、それらは失われます。なぜなら X はもうそこにいないからです。

今、ソケットを IP アドレスに関連付けずにタグ付けすることを想像してください。これにははるかに大きなポート番号（現在は 16 ビット）が必要です。例えば 128 または 256 ビットのユニークなハッシュにしましょう。X が Y へ (uuid,80) でタグ付けされたパケットを送ります。パケット自体には第 3 層レベルの (X,Y) アドレシング情報が含まれており、これが正しくルーティングされる理由です。しかしカーネルは第 3 層の情報を使ってどのソケットに配信するかを決定しません。uuid を使用しますのみ。宛先ポート（ここでは 80）は新しいセッションを開始するために必要なだけで、それ以降は無視または省略できます。

戻り方向では、Y のカーネルは (uuid) 宛のパケットが IP アドレス X から送られてきたことをキャッシュし、それが最近受信した (uuid) パケットのアドレスとなります。

次に、X が Q に変更された場合を考えましょう。引き続き (uuid,80) でタグ付けされ IP アドレス Y へパケットを送りますが、現在はアドレス Q から送られています。機械 Y ではパケットを受信し、(uuid) と関連付けられたソケットと一致させ、そのソケット用のパケットが今 Q から来ていることに気づいてキャッシュを更新します。返信パケットは (uuid) でタグ付けされ X ではなく Q へ送信できるようになります。全て機能します！（假冒による接続ハイジャックを防ぐための注意点を除く）

唯一の罠：UDP と TCP はそうやって動作せず、更新しすぎる時機を逸しました。UDP と TCP を更新することは IPv4 から IPv6 に変更するのと似ており、1990 年代には単純なように聞こえましたが、数十年後にはまだ半分も達成されておらず（最初の半分は容易で、後の長尾がはるかに難しい）です。

良いニュースは、レイヤ違反をさらに追加することで workaround できる可能性があることです。TCP を放棄し（もはや古すぎる）、代わりに UDP 上の QUIC を使う場合、UDP 4 タプルを接続識別子として一切使用することを止めることができます。代わりに、UDP ポート番号が「特別なモビリティ層」ポートであれば、コンテンツを展開し、適切な uuid タグを持つ別のパケットに分解して、正しいセッションと一致させ、適切なソケットへ配信します。

さらに良いニュース：実験的な QUIC プロトコルは既に理論上、このように動作するための適切なパケット構造を持っています。ステートレスなパケット暗号化と認証を使用したい場合、ユニークなセッション識別子（キー）が必要であることを考えると、QUIC はそれをすでに実装しています。おそらくあまり作業せずに、QUIC が透明なロミングをサポートできるかもしれません。どんな世界か！

その時点で、インターネットから残存するすべての UDP と TCP を排除すれば、本当に今回こそ第 2 層ブリッジングを廃止でき、さらにブロードキャストや MAC アドレス、SDN や DHCP などそれらも全て廃止できます。

そしてインターネットは再びエレガントになります。

---

1. 修正 2017-08-16：このセクションの何一つ IPv6 を必要としません。IPv4 と NAT（複数の NAT を跨ぐロミングも含めて）でも問題なく動作します。
2. 修正 2017-08-15：いくつかの人が「一部の注意」がどのようなものか尋ねました。方法は複数ありますが、最も単純な方法は TCP の接続開始時に行う SYN-ACK-SYNACK 交換のようなものをすることです。Y が新しいホスト Q から来た最初のパケットだけを信頼すれば、インターネット上のどこからでもパケットを送るだけで X->Y の接続を乗っ取られるのが簡単になりすぎます。（ただし、どの 256 ビット uuid を埋めるかは少し推測が難しい）。しかし、Y がクッキーを送り、Q がそれを受け取り処理して Y に戻すなら、Q が少なくとも中間者の攻撃者ではなく外部の攻撃者であることを保証できます（TCP はそもそもそれを保証します）。暗号化されたプロトコル（QUIC など）を使用する場合、ハンドシェイクもセッションキーで保護できます。
3. 修正 2017-10-24：QUIC の他にも、MinimaLT など他の候補があります。最初 MinimaLT は IETF の人々との私の元々の会話の一部ではなかったので紹介しませんでした。QUIC がロミング対応可能な TCP 代替の唯一の選択肢であることを意味するわけではありません。実際、MinimaLT はロミング問題をエレганantly解決した最初のプロトコルでした。将来的に採用される可能性のあるソリューション（QUIC など）は、おそらく MinimaLT の解決策をモデルにするでしょう。

更新 2020-07-09：IPv4/IPv6 の移行と互換性に関するさらなる考察を Tailscale ブログに掲載しました。