要請ノードマルチキャストアドレス
Yota MaruyamaNDP（近隣探索プロトコル）
IPv4でのARPのようなもの
NDPでIP→MACアドレスを解決するには要請ノードマルチキャストアドレスに参加する必要がある。
上記の動画で要請ノードマルチキャストアドレスについて紹介されており、8:05あたりの
おまけの部分でその役割をについてよく分からないと疑問が提起されていたので気になって調べた
Yota MaruyamaマルチキャストMACアドレスとは
このMACアドレスはMACアドレステーブルに保存されない。
これのせいで結局フラッディングが起こり、無駄な通信が発生してしまう。
Yota MaruyamaIGMPスヌーピング
他にフラッディングさせないためにIGMPスヌーピングが役に立つかもしれない。
端末 B と端末 D にマルチキャスト自体を送信させたくない場合には、
L2 スイッチにてIGMP snooping 機能を有効にする必要があります。
下記より引用
https://milestone-of-se.nesuke.com/nw-basic/ethernet/flooding-and-broadcast/
Yota MaruyamaRFC 7342
"Since the majority of data center servers are moving towards 1G or 10G ports, the bandwidth taken by ARP/ND messages, even when flooded to all physical links, becomes negligible compared to the link bandwidth."
とあるように1G,10Gでは大抵はフラッディング程度なら無視できるみたいである
RFC7342ではデータセンターでのケースを挙げ、IGMPスヌーピングを利用すると更に効率が良くなると分かる。
Yota MaruyamaDAD(Duplicate Address Detection:重複アドレス検出)
これで特定のグループを発見し、そのグループにのみRSがRA ルータ広告を返信するから効率がよい？？
（これNDP[近隣探索プロトコル]はARPよりも効率が良くなるのは...）
https://www.nic.ad.jp/sc-sendai/program/iwsc-sendai-d1-4.pdf
Yota MaruyamaNICレベル？？
ARPはCPUを食う
例えば、Who has 192.168.1.1?というARP Requestを投げたとしよう。
このときのdesctination Ethernetアドレスはff:ff:ff:ff:ff:ffでブロードキャスト。
なので、これを受信した同一セグメントの全マシンはEthernetアドレスを見ただけでは「もしかしたら自分かも」と考え、ARPパケットの中身を見て、ようやく自分は関係ない、ということで破棄をする。
ARPの中身を見て判断、という時点でNICレベルでの処理は難しく、CPUまで判断を仰ぐ形になる。
これもふーん、そりゃそうだろ、と思うかもしれないが、IPv6のNSは、要請ノードマルチキャストアドレス(Solicited-Node multicast address)を使うので、賢いNICだったら、NICレベルで破棄できるのだ。
（何でNICレベルで破棄できるのか、書くと長くなるので割愛しますが、もし反響が大きかったら別で記事書きます）
ちなみに、ARPのBroadcast Stormが発生すると、普通のマシンのCPU負荷はおそらく100%近くまで持っていかれるだろう :scream: （昔検証したがトラウマになりその後二度と検証できていない）
引用元
https://qiita.com/inoueissei/items/8d61e675c404ff2ef8d1
というような記述があった。