RE: [PATCH] IGMP: Inhibit reports for local multicast groups

From: Philip Downey
Date: Fri Aug 14 2015 - 04:55:51 EST

Sorry for the duplication - I responded in a similar manner before seeing this.



> -----Original Message-----
> From: Thadeu Lima de Souza Cascardo [mailto:cascardo@xxxxxxxxxx]
> Sent: Thursday, August 13, 2015 7:08 PM
> To: Andrew Lunn
> Cc: Philip Downey; David Miller; kuznet@xxxxxxxxxxxxx; jmorris@xxxxxxxxx;
> yoshfuji@xxxxxxxxxxxxxx; kaber@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] IGMP: Inhibit reports for local multicast groups
> On Thu, Aug 13, 2015 at 07:01:37PM +0200, Andrew Lunn wrote:
> > On Thu, Aug 13, 2015 at 04:52:32PM +0000, Philip Downey wrote:
> > > Hi Andrew
> > > IGMP snooping is designed to prevent hosts on a local network from
> receiving traffic for a multicast group they have not explicitly joined. Link-
> Local multicast traffic should not have an IGMP client since it is reserved for
> routing protocols. One would expect that IGMP snooping needs to ignore
> local multicast traffic in the reserved range intended for routers since there
> should be no IGMP client to make "join" requests.
> >
> > The point of this patch is that Linux is sending out group membership
> > for these addresses, it is acting as a client. What happens with a
> > switch which is applying IGMP snooping to link-local multicast groups?
> > You turn on this feature, and you no longer get your routing protocol
> > messages.
> >
> > I had a quick look at RFC 3376. The only mention i spotted for not
> > sending IGMP messages is:
> >
> > The all-systems multicast address,, is handled as a special
> > case. On all systems -- that is all hosts and routers, including
> > multicast routers -- reception of packets destined to the all-systems
> > multicast address, from all sources, is permanently enabled on all
> > interfaces on which multicast reception is supported. No IGMP
> > messages are ever sent regarding the all-systems multicast address.
> >
> > IGMP v2 has something similar:
> >
> > The all-systems group (address is handled as a special
> > case. The host starts in Idle Member state for that group on every
> > interface, never transitions to another state, and never sends a
> > report for that group.
> >
> > But i did not find anything which says all other link-local addresses
> > don't need member reports. Did i miss something?
> >
> > Andrew
> From RFC 4541 (Considerations for Internet Group Management Protocol
> (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches):
> 2) Packets with a destination IP (DIP) address in the 224.0.0.X range
> which are not IGMP must be forwarded on all ports.
> This recommendation is based on the fact that many host systems do
> not send Join IP multicast addresses in this range before sending
> or listening to IP multicast packets. Furthermore, since the
> 224.0.0.X address range is defined as link-local (not to be
> routed), it seems unnecessary to keep the state for each address
> in this range. Additionally, some routers operate in the
> 224.0.0.X address range without issuing IGMP Joins, and these
> applications would break if the switch were to prune them due to
> not having seen a Join Group message from the router.
> So, it looks like some hosts and routers out there in the field do not send
> joins for those local addresses. In fact, IPv4 local multicast addresses are
> ignored when Linux bridge multicast snooping adds a new group.
> static int br_ip4_multicast_add_group(struct net_bridge *br, ...
> if (ipv4_is_local_multicast(group))
> return 0;
> Cascardo.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at