illumos gate

What impact does joining this multicast group have? Is this something we might still need or want to disable under some circumstances once we support it? Would we do that via an ipadm interface property?

Good question! Initial reference: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

Unlike its all-systems counterpart (224.0.0.1/ff02::1), the IANA document refers to Jon Postel, the former head of IANA, and not an RFC.

All-systems multicast (224.0.0.1) exists all the time today. Every interface joins the all-systems multicast (part of this fix will follow closely with how all-systems handles itself today). We have two NDD switches:

nowhere(0)# ndd -get /dev/ip \? | grep multicast
ip_respond_to_echo_multicast   (read and write)
ip6_respond_to_echo_multicast  (read and write)
nowhere(0)# 

that can stop pings from being responded-to, which protect 224.0.0.1 against flooding. These same switches apply to any multicast address:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/inet/ip/ip.c#1398

I believe we will solve more problems than we cause by adding this feature: if an illumos netstack is acting as a router today, it cannot be located via 224.0.0.2 unless it's running in.rdisc (network/routing/rdisc). If an application joins 224.0.0.2 (like in.rdisc) it should still succeed in its join (part of testing this fix would be to insure in.rdisc in responder-mode still works).