[RFC] bridge: handle bridge group address per 802.1 standards

[RFC] bridge: handle bridge group address per 802.1 standards

[Stephen Hemminger]

The Linux bridge code would process all packets addressed to
the multicast address 01:80:C2:00:00:0X as local and
and never forward. This may have been correct in the ancient past, but
reading the relevant standards, the correct behavior is to handle only
the bridge group address as a special case and leave all other link
local multicast packets alone.

Recently there has been some complaints about forwarding (or not) of
802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the 
802.1 Bridging Working Group for point me in the correct direction.
The 802.1X-2010 standard Table 11-1 details how different
addresses are assigned based on connectivity associations.
      
  Bridge group address:		01-80-C2-00-00-00
  PAE group address:            01-80-C2-00-00-03
  Link Layer Discovery          01-80-C2-00-00-0E

Warning: this may mean that some people using bridge who expect
link local packets to be isolated, now need to add firewall rules.
But in my opinion, following the standard is the correct thing to
do regardless.

This means when using 802.1x with libvirt, there are several options:
  1. Use macvtap not bridge
  2. Turn off STP in libvirt
  3. Use PAE group address for 802.1x
  4. Provide a user level application using AF_LLC to forward
     the 802.2 frames

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

--- a/net/bridge/br_input.c	2011-09-16 13:12:58.061369744 -0700
+++ b/net/bridge/br_input.c	2011-09-26 11:57:41.724554692 -0700
@@ -126,18 +126,6 @@ static int br_handle_local_finish(struct
 	return 0;	 /* process further */
 }
 
-/* Does address match the link local multicast address.
- * 01:80:c2:00:00:0X
- */
-static inline int is_link_local(const unsigned char *dest)
-{
-	__be16 *a = (__be16 *)dest;
-	static const __be16 *b = (const __be16 *)br_group_address;
-	static const __be16 m = cpu_to_be16(0xfff0);
-
-	return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | ((a[2] ^ b[2]) & m)) == 0;
-}
-
 /*
  * Return NULL if skb is handled
  * note: already called with rcu_read_lock
@@ -161,13 +149,10 @@ rx_handler_result_t br_handle_frame(stru
 
 	p = br_port_get_rcu(skb->dev);
 
-	if (unlikely(is_link_local(dest))) {
-		/* Pause frames shouldn't be passed up by driver anyway */
-		if (skb->protocol == htons(ETH_P_PAUSE))
-			goto drop;
-
-		/* If STP is turned off, then forward */
-		if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
+	/* Special handling for bridge group address */
+	if (unlikely(compare_ether_addr(dest, br_group_address) == 0)) {
+		/* If STP is turned off, then act like a hub. */
+		if (p->br->stp_enabled == BR_NO_STP)
 			goto forward;
 
 		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,

Re: [RFC] bridge: handle bridge group address per 802.1 standards

[Ben Hutchings]

On Mon, 2011-09-26 at 15:36 -0700, Stephen Hemminger wrote:
> The Linux bridge code would process all packets addressed to
> the multicast address 01:80:C2:00:00:0X as local and
> and never forward. This may have been correct in the ancient past, but
> reading the relevant standards, the correct behavior is to handle only
> the bridge group address as a special case and leave all other link
> local multicast packets alone.

I disagree.

According to my reading, we must filter at least the addresses ending in
4-D or F, while forwarding of the others should be configurable.

> Recently there has been some complaints about forwarding (or not) of
> 802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the 
> 802.1 Bridging Working Group for point me in the correct direction.
> The 802.1X-2010 standard Table 11-1 details how different
> addresses are assigned based on connectivity associations.
>       
>   Bridge group address:		01-80-C2-00-00-00
>   PAE group address:            01-80-C2-00-00-03
>   Link Layer Discovery          01-80-C2-00-00-0E
[...]

This table is informative, non normative.  The text below refers to
802.1D table 7-9 (apparently should be 7-10) and 802.1Q table 8-1 as the
sources.

802.1D-2004 section 7.12.6, Reserved addresses, says:

        Frames containing any of the group MAC Addresses specified in
        Table 7-10 in their destination address field shall not be
        relayed by the Bridge. They are configured in the Permanent
        Database. Management shall not provide the capability to modify
        or remove these entries from the Permanent or the Filtering
        Databases.

In table 7-10 the reserved addresses are those with last digit in the
range 4-F.

802.1Q-2005 section 8.6.3, Frame filtering, says:

        Each of the Reserved MAC Addresses specified in Table 8-1 shall
        be permanently configured in the Filtering Database in
        VLAN-aware Bridges. The Filtering Database Entries for Reserved
        MAC Addresses shall specify filtering for all Bridge Ports and
        all VLANs. Management shall not provide the capability to modify
        or remove entries for Reserved MAC Addresses.

In table 8-1 the reserved addresses are those with last digit in the
range 4-D or F.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [RFC] bridge: handle bridge group address per 802.1 standards

[Stephen Hemminger]

On Tue, 27 Sep 2011 19:23:05 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:

> On Mon, 2011-09-26 at 15:36 -0700, Stephen Hemminger wrote:
> > The Linux bridge code would process all packets addressed to
> > the multicast address 01:80:C2:00:00:0X as local and
> > and never forward. This may have been correct in the ancient past, but
> > reading the relevant standards, the correct behavior is to handle only
> > the bridge group address as a special case and leave all other link
> > local multicast packets alone.
> 
> I disagree.
> 
> According to my reading, we must filter at least the addresses ending in
> 4-D or F, while forwarding of the others should be configurable.
> 
> > Recently there has been some complaints about forwarding (or not) of
> > 802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the 
> > 802.1 Bridging Working Group for point me in the correct direction.
> > The 802.1X-2010 standard Table 11-1 details how different
> > addresses are assigned based on connectivity associations.
> >       
> >   Bridge group address:		01-80-C2-00-00-00
> >   PAE group address:            01-80-C2-00-00-03
> >   Link Layer Discovery          01-80-C2-00-00-0E
> [...]
> 
> This table is informative, non normative.  The text below refers to
> 802.1D table 7-9 (apparently should be 7-10) and 802.1Q table 8-1 as the
> sources.
> 
> 802.1D-2004 section 7.12.6, Reserved addresses, says:
> 
>         Frames containing any of the group MAC Addresses specified in
>         Table 7-10 in their destination address field shall not be
>         relayed by the Bridge. They are configured in the Permanent
>         Database. Management shall not provide the capability to modify
>         or remove these entries from the Permanent or the Filtering
>         Databases.
> 
> In table 7-10 the reserved addresses are those with last digit in the
> range 4-F.
> 
> 802.1Q-2005 section 8.6.3, Frame filtering, says:
> 
>         Each of the Reserved MAC Addresses specified in Table 8-1 shall
>         be permanently configured in the Filtering Database in
>         VLAN-aware Bridges. The Filtering Database Entries for Reserved
>         MAC Addresses shall specify filtering for all Bridge Ports and
>         all VLANs. Management shall not provide the capability to modify
>         or remove entries for Reserved MAC Addresses.
> 
> In table 8-1 the reserved addresses are those with last digit in the
> range 4-D or F.

There is also a more recent 2011 edition of 802.1Q but it isn't available
for free. Let me see if about getting it.