netdev - Re: [PATCH 2/2] bridge: allow forwarding some link local frames

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Oct 2011 16:36:07 -0700
From:	Ed Swierk <eswierk@...switch.com>
To:	Ross Brattain <ross.b.brattain@...el.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] bridge: allow forwarding some link local frames

On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
<ross.b.brattain@...el.com> wrote:
> 802.1AB-2009  Section 7.1 Destination address:
>
> NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
> intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
> identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
> are free to use the same addresses.
> ...
> If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
>
> 802.1AB-2009  Section 7.1 Destination address:
>
> In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
> implementations of LLDP may support the following destination addresses for LLDPDUs:
> d) Any group MAC address.
> e) Any individual MAC address.
> Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
> is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
> LLDP is implemented, as shown in Table 7-2.

Thanks for the references. I need to read the updated standards specs
before jumping to conclusions...

> I have no idea if any LLDP agents support the optional group MAC addresses.

In our application we're both generating and consuming the LLDP
frames. We're worried about standards conformance to the extent that
we don't break other tools that might receive the LLDP frames we
generate. As long as they don't care about the destination MAC address
of the frames they receive (and they shouldn't), it's definitely
feasible for us to use the "nearest customer bridge" address
(01-80-C2-00-00-00) to ensure our LLDP frames traverse Linux bridges.

--Ed
--
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