IPv6をマルチキャストなしで使う方法

モチベーション

IPv6はマルチキャストを使うことを前提にしてるのに何変なこと言ってるの？、って話なんだけど、

• マルチキャストに対応できてないスイッチもある

• 対応しててもマルチキャスト用のリソースが小さかったりすることもある

• マルチキャストはWi-Fiと相性が悪い

というのが事実としてある。
大規模Wi-FiでIPv6を使う場合のマルチキャスト対策については以前noteにも書いた。

これ、ちゃんと設定するのは、わりと面倒なんだよね。
なので、こんなことを考えて、ChatGPT 5.1と雑談してみた。

• マルチキャストが多用されるのは、ICMPv6なんだけど、マルチキャストを使わずにブロードキャストを使う、ICMPv6-(マイナス)みたいなプロトコルを作ってやれば、良いんじゃない？

• IPv4のARPはブロードキャストを使うから、IPv6でも同じようにできるはずじゃん

• アドレスの取得もIPv4と一緒でDHCPを使えばいいじゃん

• 重複アドレスの自動検出とか便利な機能はなくなるけど、IPv4にもそんな機能はないし、気にしなきゃいいじゃん

• データ構造としてIPv6は使い続けるとしても、IPv6を制御する方法はICMPv6に限らなくても良いんじゃない？

まとめ

長くなるので、ひとまず結論を書いておく

• ChatGPT的には、IPv6のためのARPを考えるのは強くお勧めしない

• 過去にもマルチキャストの問題は何回か議論されていて、いくつか提案もされていたらしいが、ことごとく却下されている

• ネットワーク機器ベンダは、不要なマルチキャストが流れないように各社それぞれ実装しているが、標準化はされていない

• SRv6 MUPのように、ICMPv6を使わずに、IPv6のパケットを制御するような方法はあるけど、実装が軽いわけじゃない

• 1つのホストに/64のアドレスを割りあてて、ホスト間通信は全部ルーティングをするようにすると、マルチキャスト不要になる、実際にハイパースケーラ事業者で利用されている

• ChatGPT 5.1 との対話は人間臭くて面白いけど時間が溶ける

強く強く抵抗するChatGPT

マルチキャストをやめて、IPv6でもARPを使えないの？、みたいな感じでChatGPTと会話をスタートしたんだけど、

• そもそもIPv6は「ブロードキャストを捨てる」設計

• IPv6ではブロードキャストは許可していない

• マルチキャストのほうがブロードキャストより圧倒的に良い

• ブロードキャストはダメ、絶対

• Wi-Fiでもマルチキャストのほうが軽いはず

• マルチキャストを減らす工夫は各社しているのでそれを使え

みたいな原理主義者みたいな反応をしてくるんだ。

• マルチキャストに対応してないスイッチだと結局ブロードキャストになっちゃうよね

• マルチキャストのためにいろいろ工夫が必要なら、マルチキャストなくすほうが良いのでは？

• ARPって寿命が長いから、そんなに頻繁に流れないよね、NDのほうがまずいのでは？

• Wi-Fiは端末との接続がわかってるから、無線でARPは流さないよね

• IPv4では問題がないんだけど

みたいに反論しても、

• それでもマルチキャストのほうが絶対良い

• 相互運用性が壊れるのでそんな提案はダメ

• L2ドメインではブロードキャストをなくしていくトレンドなのにそれに逆行するのはダメ

• ARPのパケット構造にIPv6は載せられないから現実的ではない

• IPv6の設計思想(SLAAC/ND)と合わないことはそもそもダメ

• ARPは根本的にダメ

• IPv4で動くのは規模が小さいから、たまたま動いてるように見えるだけ

• 規模が大きくなるとIPv4ネットワークはブロードキャストで壊滅するよ

• L2セグメントを分割して小さくすれば問題なし

• MLDやNDが重くなる規模だったら、ブロードキャストはもっと無理

• マルチキャストが使えないスイッチを使うほうが悪い、ちゃんと高いスイッチを買え、ちゃんとしたスイッチはマルチキャストもASIC処理する

• IPv6をARP方式に戻すのは不可能であり、意味もない

とほんとに頑に抵抗してくる。
最後の「意味もない」って本当に言われたんだよね。
なんだろうなあ、きっと過去の人間同士の議論でも、こういうふうに反論されまくったんだろうなあ。
普通だと心折れちゃうよ。

でも相手はLLMだ、グイグイ攻めるよ

• IPv4でWi-Fiを作ったときに大規模に1セグメントに2000台ぐらい繋いでも問題ないよ

• セグメントを分割するとハンドオーバーのときに困るので分割するのは現実的じゃないよ

• ND proxyとか負荷がそこそこ重いしリソースも消費するでしょ？

とか言ってたら、最終的にこんなことを言われた。

• あなたの言うことは現場目線の正しい意識だ

• 過去にも同じような問題意識を持った提案があった

• ただIETF内では反対が強い

• 各機器ベンダのIPv6の実装は、ほぼIPv4アーキテクチャのようになっている

• あなたの言ってることは100%正しい

これはホントなのか？、忖度されているだけなのか？、100%とか言うやつは信用しちゃダメだよね!!

各機器でのマルチキャスト緩和策

ChatGPTに、各機器ベンダでは、どういう対応方法を取ってるの？、と聞いてみた結果をとりあえず貼る。
ND suppression のやり方は各社違うけど、各社ちゃんと必要そうなことは実装している。

Cisco

• IPv6 Multicast → Unicast Conversion (Wi-Fi)

• ND Suppression / Proxy ND（AP 側）

• RA Suppression

• MLD Snooping / Querier

• L3 Edge Isolation

• EVPN Proxy ND (DC ファブリック)

• RA Guard / DHCPv6 Guard

Arista

• Cognitive Wi-Fi の ND/MLD suppression

• RA suppression / RS suppression

• EVPN Proxy ND (Leaf スイッチ)

• IPv6 Neighbor Throttling / Control-Plane Protection

• EVPN Multicast（MLDをEVPN内で最適化）

Mist（HPEに買収されちゃったけどJuniperを書くほうがまだわかりやすいかしら？)

• Cloud-based ND Intelligence

• ND suppression（Wi-Fiでの ND broadcastゼロ化）

• RA throttling + RS proxy handling

• MLD suppression / IGMP proxy

• Cloud analytics for ND visibility

ChatGPTはこんなことを言ってた。

• すべての機器ベンダが、IPv6 ND は、素のまま動かすと破綻する、ということは認めている

• ND / RA / MLD をスイッチ or AP 側で 吸収・変換・抑制 してネットワークに流さない、方向へ動いている。

• つまり彼らは、IPv6 の設計（ND = multicastベース）が現実と合わないことを理解しており、実装で救済している。

わ、わたしが言ったんじゃないからね!!
(言わせたのは私かもしれないけど、なんかごめん)

過去のIETFでの提案

過去に議論はあったの？、というのもChatGPTに聞いてみたら、こんなキーワードが出てきた。

• ARP-like IPv6 ND

• ND broadcast mode

• ND simplification / ND v2

• Stateless GW-based ND / IPv6 ARP emulation

ただ、どれも議論にはなってるけど、draftの提出までは行ってないらしい。
その代わりに「ND をそのまま使うが、効率化する／抑制する」という方向での「妥協／現実解」が産まれて、これが実運用では主流になっているらしい。
それは実際にRFC9898になっている。

https://datatracker.ietf.org/doc/rfc9898/

わりと長いRFCなんだけど、

• IPv6 は使う環境によって最適化が必須ということを教えてくれる

• IPv6 ND の弱点を体系的に整理していて、過去の RFC や設計ミスも含めて包括的に俯瞰できる

• あらゆる場所で安全かつ効率的に IPv6 を運用する設計の教科書として利用できる

というどれも有用なものっぽい。(とChatGPTが言ってた)

ICMPv6を使わずにIPv6パケットを運ぶ方法はあるのか？

松嶋さんがRFCを書いた、SRv6 MUPでは、ICMPv6を使わずに代わりにモバイル用のプロトコルを使って通信制御をしている。

https://datatracker.ietf.org/doc/html/rfc9433

とってもエレガントなので、若者は松嶋さんとお酒を呑めば良いと思う。

カプセル化して配送すれば良いだけで、他にもいろいろな手法でマルチキャストレスなIPv6は作れるとは思うんだ。

1つのホストに/64のアドレスを割りあてる

1つのセグメントに1台しか置かなければマルチキャストとか不要でしょ？、みたいな一見無茶な話もある。
ノード間の通信は全部ルータに任せちゃう。
ちゃんと、RFC8273にもなっている。

https://datatracker.ietf.org/doc/rfc8273/

IPv6の128ビットのうち64ビットしか使わないので、無駄すぎるじゃん、と思うんだけど、ハイパースケールのデータセンターでは普通に使われてるんだとか。
プライバシーアドレスとか全然意味ないじゃん、攻撃受けやすくなるじゃん、みたいな話もあるけど、まあ適材適所で使う分には良いんだろうなあ。
IPv6って面白いなあ。

この記事を書くのにかかった時間

アドベントカレンダーの2日目の記事として書いている。
ルールとして、その日に書きたいことをその日に書く、ということで9時ぐらいから書きはじめた。
2時間ぐらいあれば書けるでしょ、と思ったけど3時間かかった。
やっぱり生産力が落ちてる気はする。
ただ、この件に関して、ChatGPTとの会話は10時間ぐらいはしてる気はするなあ。
ChatGPTとの会話は楽しいけど、ほんとに時間が溶けて良くない。
最近はGeminiも使いはじめてて、そっちのほうが性能が良いような気もしてる。
同じ会話をするとどういう結論になるかねえ。
ヘッダ画像は、Geminiに、「IPv6とマルチキャストで悩む熊」というお題で書いてもらった。