Project

General

Profile

Bug #12702

Join all-routers multicast when ILLF_ROUTER is enabled

Added by Dan McDonald 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
networking
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

We have per-interface routing flags in illumos already. It should not be too hard to handle joining or leaving the all-routers multicast groups (224.0.0.2 for IPv4, ff02::2 for IPv6) when ILLF_ROUTER is {en,dis}abled on the interface.

Not bite-sized, but it might be a good introductory bug. A possible place to put it is the ill_forward_set_on_ill() function.

History

#1

Updated by Joshua M. Clulow 2 months ago

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?

#2

Updated by Dan McDonald 2 months ago

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).

Also available in: Atom PDF