RE: IPv6 - NS, DAD and MLDv2 interaction

-----Original Message-----
From: Lutz Donnerhacke <lutz@donnerhacke.de> 

> Yup. IPv6 replaced broadcast by multicast on the link layer.
>
>> It appears that some vendors of switches have started to become overly 
>> restrictive in forwarding Ethernet Multicast, and only deliver these 
>> *after* a Host has registered itself to receive / participate in 
>> specific IPv6 Multicast groups.
>
> May you please drop an information about the vendor?
> So that we can warn the community to buy those broken products.

The problem is described - with some workarounds here 

http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf


>> So far, I could not find any guidance (and with my lack of depth into 
>> IPv6, it is also unclear to me, if this would even be possible) if 
>> registering a host into a IPv6 MC group via MLDv2 in order for it to 
>> receive NS, ND, DAD is something that would be expected…
>
> https://datatracker.ietf.org/doc/html/rfc4861#section-7.2.1
>
> The host must join (using MLDv2) the multicast groups for all of its own addresses to be reachable by Neighbor Discovery. This does not include the standard RD group (IIRC).

Is there a known defect in fbsd11 or later, where the solicited-node multicast address is not joined/announced via MLD? Or any way to validate the current entries that are supposed to be announced via MLD on an interface?

Apparently the MLD snooping tables on the affected switch do NOT show any IPv6 host (completely empty) - which is surprising, when an IPv6 host following RFC4861 is supposed to join the solicited-node MC address via MLD...

(it also appears that some other OS may not use the multicast NS process using this Ethernet Multicast addresses - or else issues should have been apparent immediately).

Best regards,
  Richard