lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110927150155.4b73fd60@nehalam.linuxnetplumber.net>
Date:	Tue, 27 Sep 2011 15:01:55 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC]  bridge: handle bridge group address per 802.1 standards

On Tue, 27 Sep 2011 19:23:05 +0100
Ben Hutchings <bhutchings@...arflare.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ