ARPへの別れ：IPv6のみのネットワークにおけるIPv4サービス

IPv6のみのネットワークは、しばしばIPv4サブネットとARPに依存しています。この記事では、これら両方を排除し、翻訳やトンネリングなしでIPv6のみのインフラストラクチャ上でサービスとしてIPv4を実行できるようにするIETF提案を紹介します。この記事は、RIPE 91ブカレストでのライトニングトーク「ARPへの別れ」から生まれました。会場での反応と、その後の廊下での会話から、オペレーターコミュニティがすぐに認識する問題であることが明らかになりました。その後に続いたインターネットドラフト、draft-vanmook-intarea-ipv6-resolved-gatewayは、現在IETF IntAreaワーキンググループに第3版として提出されており、ウィーンでのIETF 126での発表が予定されており、会議後には採用呼び出しが期待されています。この記事はその背景を語り、ネットワークを運用しているなら、なぜ気にする必要があるのかを説明します。 IPv6のみ、ただしIPv4を除く ほとんどのオペレーターにとって、IPv6のみのインフラストラクチャは何年も前から手の届くところにありました。ルーティングプロトコルは存在します。アドレス空間は存在します。ツールは成熟しました。多くのデータセンターファブリックとアクセスネットワークは、現在IPv6のみのコントロールプレーンを実行しています。 しかし、それらのネットワークのほぼすべてが、1982年時代の静かな遺物を運んでいます。それは並列IPv4アーキテクチャです。IPv6がその仕事をできないからではなく、ネットワーク上で動作するアプリケーション、デバイス、レガシーシステムがまだIPv4の存在を期待しているからです。そのため、ネットワークチームは、完全にクリーンなIPv6のみのファブリックを構築した後、それと並行してIPv4サブネット、IPv4ゲートウェイアドレス、およびARPを維持することになります。永遠に。 デュアルスタックの隠れたコスト ネットワークエンジニアにデュアルスタックのコストを尋ねると、彼らは明白なことから始めます。2つのアドレスファミリー、2つのACLセット、2つの監視構成、倍増したステート。それは現実ですが、問題は過小評価されています。 ARPは運用上のリスクです。ARPは、数十ホストのLAN向けに設計されたブロードキャストプロトコルであり、数千ホストのネットワーク向けではありません。最新のインフラストラクチャでは、ARPストーム、キャッシュポイズニング、大規模L2セグメントでのテーブル枯渇、フェイルオーバー中の gratuitous ARP レース、およびMACアドレスが予測不能に移動する仮想化インフラストラクチャでのARPデバッグの喜びなど、継続的な苦痛の原因となっています。以前のCTOとしての役割で、私は10,000台の顧客サーバーとVMが、毎秒50万件のARPリクエストを生成しているのを目にしました。その数字がこのドラフトの由来です。 アドレス経済学 IPv4アドレスは二次市場で10ドル以上で取引されており、オペレーターが必要とする小規模ブロックはプレミアム価格で取引されています。従来のIPv4サブネットはすべて、ネットワーク、ブロードキャスト、ゲートウェイのオーバーヘッドでアドレスを消費します。/30のポイントツーポイントリンクはアドレスの半分を無駄にします。ここで説明するメカニズムを使用すると、ホストは正確に1つのIPv4アドレス、つまり自身の/32のみを必要とします。それ以外はありません。 サブネットのスプロール化 各IPv4サブネットは割り当て、文書化、ルーティング、そして最終的には再ナンバリングする必要があります。IPv4をIPv6インフラストラクチャ上の純粋な/32サービスとして扱うネットワークは、ホストアドレス自体以外に割り当てるものはありません。 セキュリティ体制 /24は、攻撃者にARP経由でプローブできる254のターゲットを与えます。ARPがなく、/32ホストのネットワークにはスキャンするサブネットがありません。 すでに本番環境で解決済み、ただし不格好な方法 標準コミュニティにとって不快な事実は、この問題はすでに大規模なホスティングプロバイダーによって解決されているということです。問題は、それらのソリューションが相互運用可能ではないことです。なぜなら、従うべき標準が存在しないからです。 Hetzner、OVHcloud、またはScalewayで専用サーバーまたはクラウドインスタンスをプロビジョニングしたことがあるなら、それを見たことがあるはずです。サーバーには/32（またはプレフィックス外のゲートウェイを持つアドレス）が割り当てられ、プロバイダーのドキュメントには、それを機能させるためのOS固有の呪文が記載されています。 プロバイダーのワークアラウンド プロバイダーの設定 Hetzner ルート：[ to: 0.0.0.0/0, via: 172.31.1.1, on-link: true ] OVHCloud post-up route add <x.y.z.254> dev eth0 Scaleway iface eth0 inet static ... pointopoint 62.210.0.1 3つのプロバイダー。3つの異なるゲートウェイアドレス。3つの異なるOSごとのメカニズム：netplan on-link、post-up host routes、pointopoint。すべてが同じことを強制しています。ホストに、サブネット上にないゲートウェイのARPを要求させます。何百万もの（仮想）サーバーが今日この方法で稼働しています。RFC 2132の著者はおそらくDHCPv4 Router Optionのこの使用法をまったく考慮していなかったでしょうが、それを禁止するものは何もありません。まさにそれが、標準を書く必要性を誰も感じずに広まった理由です。各プロバイダーが独自のゲートウェイアドレスと設定レシピを考案することは、IETFが存在する理由である相互運用性の失敗のまさに例です。 なぜDHCPを修正しないのか？ 明らかな反論：IPv6ネクストホップを運ぶ新しいDHCPv4オプションを定義し、それを適切に行わないのはなぜか？ DHCPv4オプションは簡単な部分です（それさえ数年単位であり、数ヶ月ではありません）。難しいのはその周りのすべてです。すべてのIPAM、すべてのプロビジョニングシステム、すべての請求プラットフォーム、すべての顧客ポータル、すべての監視ツール、すべてのNOCランブック、そして既存のすべてのネットワーキング教科書は、IPv4デフォルトゲートウェイがどのように見えるかを知っています。それは、馴染みのあるフィールドにある4つのオクテットです。その知識は、OSS/BSSエコシステム全体にわたる検証ロジックにエンコードされています。IPv4ゲートウェイの外観を変更することは、数十年単位の業界全体の調整問題であり、プロトコルレベルで何かを変更するたびに、ソフトウェアスタックの残りは、期待される形状と正確に一致しない場合に反発します。 そのため、形状を変更せず、意味を変更します。 メカニズム：1つのセンチネル値 ドラフトは、単一の特殊目的IPv4アドレス、192.0.0.11をセンチネルとして定義しています。DHCPv4サーバーは、通常のRouter Option（Option 3）として、ゲートウェイアドレスと同様にそれを配布します。すべてのDHCPサーバー、リレー、IPAM、およびプロビジョニングシステムは、期待されるものとまったく同じように見えるため、変更なしで今日でもそれを処理します。変更は、知る必要がある唯一の場所にあります。ホストです。ドラフトを実装するホストスタックは、センチネルを認識し、それに対してARPリクエストを送信する代わりに、通常のルーター広告とネイバーディスカバリを通じて学習されたデフォルトルーターのMACアドレスを、IPv6ネイバーキャッシュから解決します。IPv4パケットは、ルーターのMAC宛てのリンクレイヤーフレームで送信されます。ネイティブIPv4、エンドツーエンド。ARPなし、IPv4サブネットなし、ルーターインターフェイス上のIPv4アドレスなし、トンネリングなし、翻訳なし。そして決定的に、更新されていないホストは、常にそうするように192.0.0.11のARPを要求し、ルーターは自身のMACで応答します。ルーターはそのインターフェイス上のアドレスを機能的に所有します。更新されたホストと変更されていないホストは、セグメント上で無期限に共存します。フラグデーや必須の切り替えポイントはありません。オペレーターは、ARPを完全にオフにするかどうか、およびいつオフにするかを決定します。 ルーター側では、このメカニズムはRFC 8950（IPv6ネクストホップを持つIPv4プレフィックス）に直接適合します。これはすでに世界最大級のネットワークの一部で本番稼働しており、IETF Last Call中のdraft-ietf-intarea-v4-via-v6は、ルーター間の側面を処理します。そのドラフトはホストのファーストホップギャップを明示的に開いたままにしており、これはそれを閉じます。これらが組み合わさって、デュアルスタックエンドポイントを提供するシングルスタックネットワークアーキテクチャを形成します。 IPv4は、ネットワーク全体に浸透するアーキテクチャであることをやめ、アプリケーションにとって常にそうであったもの、つまりサービスエンドポイント識別子になります。ただし、それ以外はIPv6のみのトランスポートで運ばれます。 ボーナス：1つのユニバーサルゲートウェイアドレス このソリューションの形状から有用なものが生まれます。設計目標ではありません。192.0.0.11がルーターが応答するよく知られたアドレスになると、上記のテーブルの3つのプロバイダー固有のゲートウェイアドレスは1つに収束します。1つのプロバイダー向けに構築されたサーバーイメージは、次のプロバイダーでも機能します。IPAMテンプレート1つ、プロビジョニングレシピ1つ、どこでも。セキュリティプロパティも無料で付属します。アドレスにはサブネットメンバーシップ情報が含まれておらず、トポロジに関する情報は何も公開しません。IANA登録によれば