IPv6がよく考えられている世界

Googleの従業員の1人であるAvery Pennarunによる、現代のインターネットの現状、IPv6を作成するための歴史と前提条件、理想的なIPv6プロトコルが機能する理由、機能しない理由、および方法に関する記事の翻訳この理想は近づいています。

昨年11月、私は初めてIETFに行きました。 IETFは興味深い場所です。3分の1は難しい付随作業、すでに作成されたものの拡張の3分の1、現実研究とはかけ離れたクレイジーの3分の1で構成されているようです（この場所では、エイブリィは「青空狂気」というフレーズを使用し、 青い空の研究表現から彼によって形成された-約transl。） 。 主に参加したのは、最初に導入されたTCP BBRに対する人々の反応を確認したかったからです。 （回答：ほとんどの部分は前向きだが、信じられない。彼は期待に応えるにはあまりにも良すぎるように見えた。）

IETFの会議には、インターネットの基礎を形成するIPv4プロトコルに代わるものと考えられていたIPv6に関する多数のプレゼンテーションが含まれています。 （置換はすでに進行中であると言う人もいれば、すでに起こっていると言う人もいます。）IPv6についてのこれらのプレゼンテーションに加えて、IPv6を最高、最高と考える多くの人々がいます。 （任意の瞬間）、およびIPv4は、インターネットが再び美しくなるように死ぬ運命にある単なる大量のハックです。

実際に何が起こっているのかを理解しようとする良い機会になると思いました。 IPv4に比べてIPv6が非常に混乱しているのはなぜですか？ アドレスのビット数が増えたIPv4だけだったらもっと良いと思いませんか？ しかし、いや、天国のために、すべてが間違っていました。 だから私は周りのみんなに尋ね始めました、そしてここに私が見つけたものがあります。

タイヤがすべてを破壊した

むかしむかし、物理的な回線交換を使用する電話網がありました。 基本的に、これは、ご使用の電話機が文字通り非常に長いワイヤ（ OSIレベル1 ）で接続されることが判明するような方法でコネクタを移動することを意味しました。 そして、「専用線」は、電話会社からリースした非常に長いワイヤでした。 片側のビットをこのワイヤーに入れ、もう一方の端から一定時間後に出てきました。 各端に車が1台しかなかったため、住所は必要ありませんでした。

電話会社がこれを少し最適化したら。 時分割多重化（TDM）と「仮想チャネルスイッチング」が登場しました。 電話会社は、多くの回線から低速で透過的にビットを取得し、マルチプレクサとデマルチプレクサを使用してそれらをグループ化し、以前よりも少ないワイヤを使用して電話システム経由で送信できます。 これが機能するためには、以前よりも多くの作業が必要でしたが、これまでのところモデムユーザーにとってはすべてが同じままでした。ビットを一方向に配置し、他の方向から飛び出します。 住所は必要ありません。

インターネット（当時はまだ呼ばれていない）は、これらのチャネルの上に構築されました。 ワイヤーを束ねて、ビットを突き刺してキャッチすることができました。 1台のコンピューターに2つまたは3つのネットワークインターフェイスがある場合、適切に指示されていれば、ある回線から別の回線にビットを送信でき、コンピューターの各ペア間で通信回線を分離するよりもはるかに効率的な処理を実行できます。 そのため、IPアドレス（「レベル3」）、サブネット、ルーティングがありました。 その場合でも、これらのポイントツーポイントチャネルでは、MACアドレスは必要ありません。なぜなら、パケットが配線されるとすぐに、そこから出ることができる場所が1つしかないからです。 それ以降はどこに行くべきかを決めるのにIPアドレスのみが必要でした。

一方、代替として、ローカルエリアネットワーク（LAN）が発明されました。 コンピュータ（または端末とメインフレーム）を接続する場合、スタートポロジの各接続に必要な多くのインターフェイスという形で不便を感じました。 電子機器のコストを削減するために、多くのステーションを1本のワイヤで簡単に接続し、接続している人と話すことができるバス型ネットワーク（「ブロードキャストドメイン」、将来的に重要になる概念）が必要でした。それに。 これらは、インターネットを構築したのと同じ人ではなかったため、このためにIPアドレスを使用しませんでした。 彼らは独自のスキーム（「レベル2」）を発明しました。

初期のバス型ローカルエリアネットワークの1つはアークネットでしたが、心から愛していました（アークネットが廃止されてからずっと経って、90年代に最初のLinuxアークネットドライバーとアークネットの詩を書きました）。 レイヤー2のアークネットアドレスは非常に単純でした。ネットワークカードの背面にあるジャンパーまたはDIPスイッチによって設定されるのは8ビットのみです。 それはネットワークの所有者としてのあなたの仕事でした-アドレスを設定し、重複がないようにするか、そうでなければ気の毒なことが起こります。 少し苦痛でしたが、アークネットネットワークは通常非常に小さいため、少し苦痛でした。

数年後、イーサネットがやってきて、この問題を完全に解決し、第2レベルのアドレスにさらに多くのビット（実際には48ビット）を使用しました。 これは十分なビットなので、異なる（シャードシリアル（明らかに、MACアドレスの最初の3バイトが特定の製造業者の範囲として割り当てられていることを意味します-およそTransl。） ）アドレスを各デバイスに割り当てますどちらも解放され、交差点はありませんでした。 それがまさに彼らがしたことです！ これがイーサネットMACアドレスの表示方法です。

私のお気に入りの1つであるIPX（ インターネットワーク-約Transl。）パケット交換（「実際の」インターネットとは何の関係もありませんでした）や、それまでうまく機能していたNetwareなど、さまざまなLANテクノロジーが出入りしました。すべてのクライアントとサーバーが1つのバスからネットワーク上にある限り。 アドレスを設定する必要はありませんでした。 美しく、信頼性が高く、効率的でした。 実際には、ネットワーク構築の黄金時代。

もちろん、誰かがそれを破壊しなければなりませんでした：企業/大学の大規模なネットワーク。 彼らは非常に多くのコンピューターを接続したかったので、単一のバスで10 Mbit / sを共有することがすべてボトルネックになったため、多くのバスを持ち、必要に応じてこれらのバスを相互に接続する方法が必要でした。 あなたはおそらく「もちろん！ これにはインターネットプロトコル（IP）を使用します。 笑 まだそう呼ばれていないインターネットプロトコルは、まだ十分に古くなく、当時人気がなかったため、誰も真剣に受け止めませんでした。 Netware-over-IPX（およびその当時の他の多数のLANプロトコル）は深刻な問題であり、あらゆる深刻なビジネスがそうであるように、ますます人気のあるイーサネットを拡張するために独自のものを発明しました。 イーサネットデバイスには既にアドレス、MACアドレスがありますが、これはおそらく、さまざまなLANプロトコルを使用する人々が同意できる唯一のものであったため、ルーティングメカニズムのキーとしてイーサネットアドレスを使用することにしました。 （実際、「ルーティング」の代わりに、彼らはそれをブリッジングとスイッチングと呼んだ。）

イーサネットアドレスの問題は、工場で順番に割り当てられるため、階層化できないことです。 つまり、「ブリッジングテーブル」は、サブネット全体へのルートの記録をすぐに含むことができる最新のIPルーティングテーブルほど優れていません。 ブリッジングを効率的にするには、各MACアドレスがどのバスネットワークで見つかるかを覚えておく必要がありました。 そして、人々は自分の手でそれぞれを構成したくなかったので、これは自分で理解する必要がありました。 ブリッジを使用した複雑なネットワーク接続がある場合、事態は少し複雑になりました。 私の知る限り、これがスパニングツリーに関する詩につながったものであり、おそらくここに置いておきます。 詩はネットワーキングにおいて非常に重要です。

それは多分、ほとんど混乱していましたが、ほとんどの場合これでうまくいきました。また、あちこちにブロードキャスト「洪水」があり、ルートは必ずしも最適ではなく、デバッグすることはほとんど不可能でした。 （ブリッジにtracerouteのようなものを書くことは絶対にできませんでした。中間ブリッジにアドレスを設定する機能など、機能させるために必要なツールはどれも裸のイーサネットには存在しないためです。）

一方、これらのブリッジはすべてハードウェアに最適化されています。 Zhelezyachnikamiは、システム全体を単に大規模なネットワークで機能するように、多くのバスとそれらの間のブリッジについてはまったく知らなかったソフトウェアを欺くメカニズムとして発明しました。 ハードウェアブリッジングとは、ブリッジがイーサネット自体と同じくらい高速で動作できることを意味します。 今ではそれは目立ったもののようには聞こえませんが、当時は非常に素晴らしいものでした。 イーサネットは10 Mbit / sだったので、複数のコンピューターを一度に接続することでおそらく入手できましたが、1つの10 Mbit / sコンピューターを配ることはできませんでした。 当時、それはおかしく聞こえた。

いずれにせよ、ポイントは、ブリッジングはデバッグできない混乱であったが、高速だったということです。

バスインターネット

これらすべてが行われている間、それらの同じインターネットユーザーは仕事に取り掛かり、そしてもちろん、彼らはクールで安価なLANテクノロジーの登場を見逃しませんでした。 確かではありませんが、ARPANETがインターネットに改名されたのはほぼ同時期だと思います。 自信を持って言われた方が話が良く聞こえるからです。
ある時点で、長距離のポイントツーポイントリンクを介して個々のインターネットコンピューターを接続することから、ポイントツーポイント接続を介してローカルネットワーク全体を一緒に接続することへの進歩が進みました。 一般的に、私は「長い橋」を持ちたかった。

「ええ、問題はありません。長距離のコミュニケーションで橋を架けて、これを終わらせてみませんか？」と思うかもしれませんが、うまく聞こえますが、うまくいきません。 詳細は説明しませんが、要するに、問題は過負荷を制御することです（残念ながら、何らかの理由で、この記事のロシア語版はwikiにありません-およそTransl。） 。 イーサネットブリッジングの恐ろしい暗黒の秘密は、すべての接続がほぼ同じ速度で動作すること、および/またはブレーキ機構がないため、負荷が非常に低いことです。 できるだけ早くデータを吐き出し、それが来ると期待しています。 しかし、イーサネットが10 Mbpsで実行され、ポイントツーポイント接続が0.128 Mbpsである場合、これは完全に絶望的です。 別の問題は、すべてのチャネルを介して送信することでルートを把握し、どちらが正しいかを判断することです（したがって、通常はブリッジングが機能します）。 低速で高価な長距離通信チャネルでの低遅延と高スループットがあるローカルネットワークでは迷惑な非最適ルーティングは、絶対に嫌です。 スケーリングしません。

幸いなことに、インターネットユーザー（インターネットが既にそのように名付けられている場合）は、まったく同じ問題に取り組みました。 インターネットツールを使用してイーサネットバスを相互に接続できれば、良好な状態になります。

そして、彼らはイーサネット上のインターネットパケット（および同時にアークネット、および他のすべてのタイプのLAN）の「フレームフォーマット」を開発しました。

そして、ここですべてがおかしくなりました。

解決する必要がある最初の問題は、バッグをワイヤーに入れると、どのマシンがそれを「聞く」か、場合によっては転送する必要があるかどうかが完全に不明確になったことです。 複数のインターネットルーターが同じイーサネットセグメントにある場合、すべてのルーターがパケットを受信して​​リダイレクトしようとするようにできません。 これは、パケットストームとループルートへのパスです。 いいえ、イーサネットバス上のどのルーターをピックアップするかを選択する必要があります。 ルーターのアドレスではなく、メッセージの受信者のアドレスを既にメモしているため、このために宛先IPアドレスフィールドを使用することはできません。 代わりに、イーサネットフレームのMACアドレスを使用して目的のルーターを決定します。

したがって、ローカルIPルートテーブルを設定するには、「MAC 11：22：33：44：55：66のルーターを介してアドレス10.1.1.1にパケットを送信する」などのように言うことができます。これは同じですが、何を表現したいですか。 重要！ パケットにはIPアドレスが割り当てられていますが、ルーターはMACです。 しかし、ルーティングテーブルを設定したことがある場合は、誰もそのように記述していないことに気づいたかもしれません。 代わりに、「192.168.1.1のルーターを介して10.1.1.1にパケットを送信します」と記述します。

実際、これは物事を複雑にするだけです。 これで、オペレーティングシステムはまず192.168.1.1のMACアドレスを見つけ、それが11：22：33：44：55：66であることを理解し、最後にイーサネット宛先アドレス11：22：33：44：55：66を持つパケットを収集し、宛先アドレスIP 10.1.1.1。 アドレス192.168.1.1はパッケージ内のどこにも指定されていません。これは単に人々を抽象化したものです。

この役に立たない中間ステップを作成するには、ARP（アドレス解決プロトコル）を追加する必要があります。ARPは、IPアドレスをイーサネットアドレスに変換するタスクを持つ単純な非IPプロトコルです。 これは、ローカルイーサネットセグメントの全員にリクエストをブロードキャストし、このIPアドレスを持っているかどうかを尋ねることによって行われます。 ブリッジがある場合、ブロードキャストパケットであるため、すべてのARPパケットをすべてのインターフェイスに転送する必要があります。これは、ブロードキャストという言葉の意味です。 多くのLANが接続された大規模で忙しいイーサネットネットワークでは、冗長なブロードキャストが悪夢の1つになります。 これはWiFiネットワークでは特に悪いです。 時間が経つにつれて、この問題に対処するために、技術的に可能な限りARP転送を回避するための特別なハックを備えたブリッジ/スイッチが登場しました。 一部のデバイス（特にWi-Fiアクセスポイント）は、支援するために偽のARP応答で単純に応答します。 しかし、これはすべて松葉杖ですが、時々必要です。

遺産の死

時間が経ちました。 一度（そして実際にはかなりの時間がかかりました）、人々はイーサネットで非IPプロトコルの使用をほとんど止めました。 したがって、基本的にすべてのネットワークは物理的なワイヤ（レベル1）になり、バス上に多くのステーション（レベル2）があり、バスはブリッジを使用して接続され（捕まえられます！それでもレベル2）、これらのバス間はIPルーター（レベル3）によって接続されます）

しばらくすると、人々は手動でIPアドレスをarcnetスタイルで構成することにうんざりし、イーサネットスタイルで構成することを望んでいましたが、イーサネットスタイルでこれを行うには遅すぎました。 IPではなくイーサネットアドレスを使用します。b）IPアドレスは32ビットのみであり、交差点なしで無限にそれらを生成するのに十分ではありません。c）サブネットを使用する代わりにIPアドレスを単純に順番に割り当てると、最初に戻ります。ゼロから作られたイーサネット、そして既にEtherneがあります t。

そして、bootpとDHCPが登場しました。 ちなみに、これらのプロトコルは特別です-ARPのように（技術的にはIPパケットであり、特別なものにならないようにします）。 IPノードはIPアドレスを受信する前に送信できる必要があるため、特別である必要がありますが、これはもちろん不可能です。したがって、本質的にIPヘッダーをナンセンスで埋めるだけです（RFCで示されていますが）。 。 （DHCPはrawソケットを開いて手動で入力する必要があるため、これらの無意味なヘッダーを認識します。カーネルのIPレベルはこれを行うことができません。）しかし、誰もIPではない別のプロトコルを発明しようとはしませんでした。これはIPであり、誰もが幸せでした。 まあ、できる限りDHCPを発明するとき。

私は少し気を取られました。 ここでの特徴的な機能は次のとおりです。実際のIPサービスとは異なり、bootpおよびDHCPプロトコルはイーサネットアドレスを認識する必要があります。これは、最終的にはイーサネットアドレスをリッスンし、さらなる作業のためにIPアドレスを割り当てることが彼らの仕事だからです。 実際、これはARPプロトコルの魅力です。ただし、そうは言えませんが、文字通り「リバースARP」 （リバースARP-約Transl。）であるRARPプロトコルがすでに存在するためです。 実際、RARPは非常にうまく機能し、bootpおよびDHCPと同じことをし、はるかに単純でしたが、それについてはお話ししません。

このすべてのポイントは、イーサネットとIPがますます絡み合っているということです。 現在、それらは実質的に分離不可能です。 48ビットMACアドレスのないネットワークインターフェイス（ppp0を除く）を想像することは困難であり、IPアドレスなしでこのインターフェイスが機能することを想像することは困難です。 IPルーティングテーブルをIPアドレスを使用して記録しますが、もちろん、そのIPアドレスでルーターを呼び出すことで嘘をついていることを知っています。 MACアドレスを介してルーティングすることを間接的に言っているだけです。 そして、ブリッジを通過するARPがありますが、それはメークビリーブであり、DHCPはIPプロトコルですが、実際にはイーサネットなどです。

さらに、ブリッジングとルーティングがまだあり、どちらもより複雑になっていますが、ローカルネットワークとインターネットはますます複雑になっています。 ブリッジングはまだほとんどがハードウェアであり、イーサネット標準を管理するIEEEによって定義されています。 ルーティングはまだほとんどがソフトウェアであり、インターネット標準を管理するIETFによって定義されています。 両方のグループは、まだ他のグループがいないふりをしようとしています。 ネットワークオペレータは、動作の速さとDHCPサーバーの設定を嫌う度合いに基づいて、単にブリッジングとルーティングを選択します。これは、彼らが本当に嫌いなものです。つまり、可能な限りブリッジとルーティングを使用することを意味します-しなければならないとき。

実際、ブリッジは制御不能になったため、人々はブリッジレベルで行われた決定を完全に高いレベルにすることを決定しました（もちろん、ブリッジ間の構成の交換はIP over Protocolを使用して行われます！） これは、ソフトウェア定義ネットワーク（SDN）と呼ばれます。 これは、スイッチとブリッジが何でもできるようにする場合に比べてはるかに優れていますが、ソフトウェア定義のネットワークが何であるかを知っているので、基本的に愚かでもありますか？ IP これは文字通りそれであり、非常に大きくなったネットワークを接続するために使用するSDNが常にありました。 しかし問題は、IPv4は当初ハードウェアを高速化するのが難しかったことであり、いずれにしてもハードウェアアクセラレーションを受け取らず、DHCP構成は地獄であったため、ネットワークオペレータは大規模なエンティティをブリッジする方法を学習しました。 そして今、ビッグデータセンターはSDNに基づいているだけで、パケットをルーティングする人はいないため、データセンターでIPをまったく使用できませんでした。 これはすべて1つの大きなバスネットワークです。

要するに、これは混乱です。

今、私はこれをすべて言ったことを忘れます...

良い話ですね 良いもの。 さて、これのどれも起こらなかったふりをして、1990年代に戻って、ほとんどすべてが実際に起こったが、IETFの人々は、これが事実ではなく、「差し迫った」災害を避けることができるふりをした。 これは良い部分です！

上記の長い話で、 バスネットワークの使用を完全に停止したこの一連のイベントのどこかで言及するのを忘れました。 イーサネットは、実際にはもはやバスではありません。 彼はタイヤになりすます。簡単に言えば、速度が上がると、よく知られているCSMA / CDを動作させることができなかったため、古き良き星のトポロジーに戻りました。スイッチからのケーブルの束があるので、各ステーションからセンターまで1本のケーブルを引き伸ばすことができます。壁、天井、床はイーサネットケーブルの太くて太い高価な束で埋められています。バスをうまく機能させる方法がわからなかったためです...レベル1で考えると、これは少しおかしいです。もちろん、悲しいことを面白くしない限り。

実際、狂気の攻撃の順に、WiFi（「バス」ネットワークの究極のケース）さえも正しいのです。 -文字通り誰もが同じオープンスペース環境を共有している場合、ほとんどすべての場所で「インフラストラクチャ」と呼ばれるモードでWiFiを使用し、巨大な「星」のトポロジをエミュレートします。同じアクセスポイントに2つのWiFiステーションが接続されている場合、お互いに「聞こえる」ことができる場合でも、直接通信することはありません。アクセスポイントにパケットを送信しますが、別のノードのMACアドレスにアドレス指定されます。アクセスポイントは、それを宛先ノードに反映します。

馬に乗って、説明してくれます。キャッチが1つあります。ノードXがIPノードYを介して、Wi-FiアクセスポイントAを介してインターネットノードZに何かを送信する場合、パケットはどのように見えますか？欲しいものの絵を描いてみましょう：

X-> [wifi]-> A-> [wifi]-> Y-> [インターネット]-> Z

Zは宛先IPアドレスです。したがって、明らかにIP宛先フィールドはZである必要があります。Yはルーターであり、上記で学習したように、イーサネット宛先フィールドにそのイーサネットMACアドレスを示します。しかし、Wi-Fiでは、Xはさまざまな理由（互いのWPA2暗号化キーを知らないという事実を含む）のために、単純にパケットをYに送信できません。Aに送信する必要があります。アドレスAをどこに配置するかを尋ねることができます。

問題ありません！802.11には、3アドレスモードなどがあります。彼らは3番目を追加しました各フレームのイーサネットMACアドレス。これにより、実際のイーサネット宛先と中間イーサネット宛先について話すことができます。さらに、「to-AP」および「from-AP」と呼ばれるビットフィールドもあり、それぞれパケットがステーションからアクセスポイントへ、またはアクセスポイントからステーションへ来ていることを示します。しかし、実際には、Wi-Fiリピーターがこれを行う（TDがTDにパケットを送信する）ため、両方とも当てはまります。

リピーターといえば！Aがリピーターの場合、次のようなパスをたどって、それをベースステーションBに送り返します。

X-> [wifi]-> A-> [wifi-repeater]-> B-> [wifi]-> Y-> [インターネット]-> Z

X-> Aは3アドレスモードを使用しますが、A-> Bでは問題が発生します。ソースイーサネットはX、宛先イーサネットはYですが、パケットはAからBに無線で送信されます。XとYはまったく関係ありません。4アドレスモードのようなものがあると言うだけで十分であり、あなたが思うように正確に機能します。

（802.11sメッシュネットワークには6アドレスモードと呼ばれるモードがあり、この時点で理解しようとしてあきらめました。）

エイブリー、彼らは私にIPv6を約束しました、そしてあなたはまだそれについても言及していません。

ああ、ああ。この投稿は少し軌道に乗っていない、見つかりませんか？
それがこのストーリー全体の目的です。IETFの人々は、IPv6を思いついたとき、この混乱をすべて見ました。おそらく、SDNおよびWiFiリピーターモードを予測できるとは思いませんが、さらに混乱が生じると予測していました。待って このたわごとは必要ありません！代わりに、私たちの周りの世界が次のように機能する場合はどうなるでしょう：

• 物理的なバスネットワークはもうありません（準備完了！）
• レベル2のインターネットはもうありません（これには3番目のレベルがあります）
• ブロードキャストはもうありません（レベル2は常にポイントツーポイントになるため、どこにブロードキャストを送信しますか？マルチキャストで置換-マルチキャスト）
• MAC- ( - , , IP )
• ARP DHCP ( MAC-, IP MAC)
• IP ( )
• IP ( )
• IP , ( — . .) ( IP , )

私たちがそのような世界に住んでいると想像してください。WiFiリピーターは単なるIPv6ルーターになります。そしてアクセスポイントも。イーサネットスイッチ。そしてSDN。 ARPストームは終了します。各ルーティングの問題はトレーサーアウトである可能性があります。そして何よりも、各イーサネットパケットから12バイト（送信元および宛先MACアドレス）、各WiFiパケットから18バイト（送信元/宛先/アクセスポイント）をドロップできます。もちろん、IPv6は（IPv4と比較して）24バイトのアドレスを追加しますが、12バイトのイーサネットをドロップするため、オーバーヘッドは12バイトのみになります-イーサネットヘッダーを残す場合に2つの64ビットIPアドレスを使用する場合と同等です。ある日、イーサネットアドレスを捨てることができるという考えは、IPv6アドレスの肥大化を正当化するのに役立ちました。

それは美しいでしょう。 1つの問題を除いて、これは起こりませんでした。

夢のレクイエム

職場のある同僚は、「レイヤーは常に追加されるだけで、消えることはありません。」と誰よりも言いました。

これらすべての奇跡のために、最初からやり直し、それまでに構築された遺産を捨てる機会が必要です。そして、残念ながら、これはほとんど不可能です。 IPv6の普及率が99％に達したとしても、IPv4を排除したわけではありません。また、IPv4を削除しなかった場合、イーサネットアドレスまたはWiFiアドレスを削除しませんでした。そして、IEEE 802.3および802.11フレーム標準に従う必要がある場合、それらのバイトを捨てることはできません。したがって、常により複雑なARPであるIPv6近隣探索プロトコルが常に必要になります。バスネットワークを使用しなくなったとしても、ARPが機能する方法であるため、常に何らかのブロードキャストが必要になります。従来のIPv4電球が引き続き機能するように、ローカルDHCPサーバーを自宅で実行し続ける必要があります。まだNATが必要です時代遅れのIPv4電球がインターネットに到達できるように。

そして、これは最悪ではありません。最悪の部分は、IPv6チームが修正するのを忘れた別のミスのために、第2レベルブリッジングという形での無限の汚物がまだ必要なことです。残念ながら、1990年代に彼らがIPv6を開発したとき、アイデアは最初にIPv6を開始することでした-それは数年かかるはずでした-そしてIPv4とMACアドレスがすでになくなったときにそれで動作します、そしてこのタスクは解決するのが簡単でしょうが、とにかく、本当に「モバイルIPデバイス」を実際に持っている人はいませんでした。つまり、ファイルがFTP経由でアップロードされている間にラップトップを持ち運び、イーサネットポートに1つずつ挿入するということは、どういう意味ですか？それは馬鹿げているように聞こえます。

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

もちろん、数十年の歴史を経て、ラップトップコンピューター（電話）のいくつかの例を知っており、ワイヤレスアクセスポイントのイーサネットポートに次々と接続しています。私たちは常にこれを行います。また、LTEを使用すると、基本的に機能します！ WiFiでは、これは時々しか機能しません。悪くないよね？

実際には、インターネットの恥ずべき秘密のせいではありません。すべてが機能するのは、第2レベルのブリッジングのためだけです。インターネットルーティングは、モビリティではまったく機能しません。 IPネットワークをナビゲートすると、IPアドレスが変更され、開いているすべての接続が切断されます。

企業のWiFiネットワークは、2番目のレベルのLAN全体をブリッジと組み合わせることでだまされます。そのため、接続している企業のアクセスポイントに関係なく、巨大な中央DHCPサーバーは常に同じIPアドレスを提供します。ブリッジの再構成中に数秒間中断します。複数のリピーター/エクステンダーを備えたこれらの新しいホームWiFiシステムは同じことを行います。しかし、通りを歩きながら1つのWiFiネットワークから別のWiFiネットワークに切り替える場合-パブリックWiFiがすべての店舗に並んでいる場合、すべてが悪いです。それぞれが新しいIPアドレスを提供し、IPアドレスが変更されるたびに、すべての接続が切断されます。

LTEはさらに努力しています。キロメートル単位で移動し、多数のセルタワーがユーザー間を移動する場合でも、IPアドレス（モバイルネットワークの場合は通常IPv6アドレス）を保持します。どうやって？まあ...彼らは通常、トラフィックを中央ポイントにトンネリングし、すべてがブリッジで（ファイアウォールによる強化されたフィルタリングを介して）1つの超巨大な第2レベルの仮想ネットワークに接続します。そして、あなたのつながりは生き続けます。非常に複雑であり、本当に落胆させるほどの追加遅延を犠牲にして、彼らは本当にそれを取り除きたいが、これはほとんど不可能である。

モバイルネットワークを機能させる方法

まあ、それは長い話でしたが、IETFの人々からそれを引き出すことができました。私たちがここに着いたとき、モバイルIPの問題に、私は尋ねるしかありませんでした。何が悪かったのですか？なぜこの作業ができないのですか？

答えは驚くほど簡単であることがわかりました。大きな欠陥は、よく知られている「4」がどのように定義されているか（ソースIP、ソースポート、宛先IP、宛先ポート）にあります。この4つを使用して、特定のTCPまたはUDPセッションを識別します。パケットに同じ4つのフィールドが含まれている場合、パケットはこのセッションに属し、セッションを提供するソケットに送信できます。ただし、この4つのレベルは、ネットワーク（3番目）とトランスポート（4番目）の2つのレベルをカバーしています。代わりにのみを使用してセッションを定義する場合4番目のレベルのデータ、モバイルクライアントは完全に機能します。

以下に短い例を示します。クライアントXのポート1111はYのポート80と通信するため、4（X、1111、Y、80）を送信する必要があります。答えは（Y、80、X、1111）に由来し、カーネルはそれを最初のパケットが作成したソケットに配信します。 Xが指定されたパケット（X、1111、Y、80）をさらに送信すると、Yはそれらを同じサーバーソケットなどに送信します。

その後、XはIPアドレスを変更し、名前（Qなど）を取得します。 4つ（Q、1111、Y、80）。 Yはそれが何を意味するのか分からず、捨ててしまいます。それまでの間、Yがマークされたパケット（Y、80、X、1111）を送信すると、それらを受信する準備ができたXがなくなったため、パケットは失われます。

ここで、IPアドレスを参照せずにソケットをマークすると想像してください。これが機能するには、はるかに大きなポート番号（現在は16ビット）が必要です。たとえば、128または256ビット長で、少しユニークなハッシュにします。

ここで、Xはラベル（uuid、80）を持つパケットYを送信します。パケット自体には、レベル3でのIPアドレス（X、Y）に関する情報が含まれていることに注意してください。これが、パケットが正しいマシンにルーティングされる方法です。ただし、カーネルはレイヤー3情報を使用して、パケットを送信するソケットを決定しません。 uuidを使用するだけです。宛先ポート（この場合は80）は、新しいセッションを開始して接続するサービスを決定するためにのみ必要であり、その後無視または無視できます。
逆の場合、Yカーネルは（uuid）のパケットがIPアドレスXに行くという事実をキャッシュします。これは、（uuid）のパケットが送信された最後のアドレスです。

XがアドレスをQに変更すると想像してください。タグ（uuid、80）のパケットをIPアドレスYに送信しますが、これらのパケットはアドレスQから送信されます。マシンYはこのパケットを受信し、（ uuid）、このソケットのパケットがアドレスQから来てキャッシュを更新することに気づきます。タグ（uuid）を使用して、XではなくQの方向に反対方向のパケットを送信できるようになりました。すべてが機能します。（詐欺師の攻撃を防ぐために必要な措置を考慮に入れる）。


キャッチは1つだけです。UDPとTCPはこの方法では機能せず、更新するには遅すぎます。 UDPとTCPの更新は、IPv4からIPv6へのアップグレードに匹敵します。 1990年代には当時は単純に見えたが、数十年後には半分も半分も完了しなかったプロジェクトです（前半は単純で、残りははるかに複雑です）。

良いニュースは、「バンドル」の別の違反でこれを回避できる可能性があることです。とにかく十分に古いTCPを破棄し、代わりにUDPでQUICを使用する場合、接続識別子として4つのUDPの使用を停止できます。代わりに、UDPポート番号が特定の値（「モビリティレイヤー」）に等しい場合、正しいUUIDタグを持つ別のパケットである可能性があるコンテンツを解凍し、正しいセッションで確認し、これらのパケットを正しいソケットに配信します。

さらに良いニュースがあります。少なくとも理論的には、実験的なQUICプロトコルは、この方法で動作するための正しいパッケージ構造をすでに持っています。いずれの場合でも、QUICのようにステートレス（ステートレス）暗号化と認証を使用する場合は、一意のセッション識別子（キー）が必要であることがわかります。そのため、おそらく微調整を加えることで、QUICは透過的なローミングをサポートできます。そのような世界はどうなるでしょう！

ここで行う必要があるのは、インターネットからUDPとTCPのすべての残りを削除することです。そうすれば、間違いなく第2レベルのブリッジの必要性を失い、今度は実際にブロードキャストとMACアドレスを削除できます。 SDN、DHCP、その他すべて。

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