All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodney Cummings <rodney.cummings@ni.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel@savoirfairelinux.com" <kernel@savoirfairelinux.com>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	David Laight <David.Laight@ACULAB.COM>
Subject: RE: [PATCH net-next v3 0/5] net: dsa: remove .set_addr
Date: Mon, 16 Oct 2017 16:28:04 +0000	[thread overview]
Message-ID: <CY1PR0401MB1536097366C596C42A8B225B924F0@CY1PR0401MB1536.namprd04.prod.outlook.com> (raw)
In-Reply-To: <20171016160941.GA13339@lunn.ch>

Hi Andrew,

I may have misunderstood.

If this MAC address is the destination, a local random MAC address doesn't work. PAUSE is using one of the 802.1Q reserved destination MAC addresses (as does LLDP, MSTP, 1588, etc). PAUSE needs to use that specially assigned address (01-80-C2-00-00-01).

I assumed we were talking about the source MAC address. For the source MAC address, I would agree that a local random MAC address works in some narrow scenarios.

My concern is that for a source MAC address, a local random MAC address is not safe in all networks, because it has the potential for duplication. That topic has been discussed quite a bit in IEEE 802.

Rodney

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, October 16, 2017 11:10 AM
> To: Rodney Cummings <rodney.cummings@ni.com>
> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> kernel@savoirfairelinux.com; David S. Miller <davem@davemloft.net>;
> Florian Fainelli <f.fainelli@gmail.com>; David Laight
> <David.Laight@ACULAB.COM>
> Subject: Re: [PATCH net-next v3 0/5] net: dsa: remove .set_addr
> 
> On Mon, Oct 16, 2017 at 03:23:42PM +0000, Rodney Cummings wrote:
> > I am concerned about this proposed change.
> >
> > According to IEEE Std 802.1Q, a "higher layer entity" (i.e. end
> > station) that is internal to the bridge (i.e. switch) can use the
> > same individual global MAC address that the switch is using. That
> > behavior is common.
> >
> > Use of a local semi-random MAC address is dangerous on
> > Ethernet. Local MAC addresses can only be safely used in very narrow
> > use cases, most of which are Wi-Fi. Generally speaking, local MAC
> > addresses can be duplicated in the network, which causes many
> > Ethernet protocols to break down. Therefore, general-purpose
> > implementations like DSA cannot use a local MAC address in a
> > reliable manner.
> 
> Hi Rodney
> 
> This is interesting. So i did some research. The Marvell Switch only
> uses this MAC address for Pause frames. Nothing else.
> 
> 802.3-2015 Section 2, Annex 31B says:
> 
>   The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has
>   been reserved for use in MAC Control PAUSE frames for inhibiting
>   transmission of data frames from a DTE in a full duplex mode IEEE
>   802.3 LAN. IEEE 802.1D-conformant bridges will not forward frames
>   sent to this multicast destination address, regardless of the state
>   of the bridge’s ports, or whether or not the bridge
>   implements the MAC Control sublayer. To allow generic full duplex
>   flow control, stations implementing the PAUSE operation shall
>   instruct the MAC (e.g., through layer management) to enable
>   reception of frames with destination address equal to this multicast
>   address.
> 
>   NOTE—By definition, an IEEE 802.3 LAN operating in full
>   duplex mode comprises exactly two stations, thus there is no
>   ambiguity regarding the destination DTE’s identity. The use
>   of a well-known multicast address relieves the MAC Control sublayer
>   and its client from having to know, and maintain knowledge of, the
>   individual 48-bit address of the other DTE in a full duplex
>   environment.
> 
>   When MAC Control PFC operation (see Annex 31D and IEEE Std 802.1Q)
>   has been enabled, MAC Control PAUSE operation shall be disabled.
> 
> So, received Pause frames never leave the MAC. They don't get bridged,
> nor do they get passed up for host processing. They are purely point
> to point between two MAC peers. The destination is unambiguous. It is
> simple the other MAC peer. The destination address makes it clear it
> is a pause frame, the the source address seems to be unneeded.
> 
> In this context, a random MAC addresses are safe.
> 
> In the more general case, i would agree with you. Collisions are
> possible, causing problems.
> 
>    Andrew

  reply	other threads:[~2017-10-16 16:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-13 18:18 [PATCH net-next v3 0/5] net: dsa: remove .set_addr Vivien Didelot
2017-10-13 18:18 ` [PATCH net-next v3 1/5] net: dsa: mv88e6xxx: setup random mac address Vivien Didelot
2017-10-13 18:18 ` [PATCH net-next v3 2/5] net: dsa: mv88e6060: fix switch MAC address Vivien Didelot
2017-10-13 18:18 ` [PATCH net-next v3 3/5] net: dsa: mv88e6060: setup random mac address Vivien Didelot
2017-10-16  9:05   ` David Laight
2017-10-13 18:18 ` [PATCH net-next v3 4/5] net: dsa: dsa_loop: remove .set_addr Vivien Didelot
2017-10-13 18:18 ` [PATCH net-next v3 5/5] net: dsa: " Vivien Didelot
2017-10-15  1:30 ` [PATCH net-next v3 0/5] " David Miller
2017-10-16 15:23 ` Rodney Cummings
2017-10-16 16:09   ` Andrew Lunn
2017-10-16 16:28     ` Rodney Cummings [this message]
2017-10-16 16:47       ` Andrew Lunn
2017-10-16 16:52         ` Rodney Cummings
2017-10-16 16:57           ` Andrew Lunn
2017-10-16 18:14             ` Rodney Cummings
2017-10-16 16:30     ` David Laight
2017-10-16 16:44       ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY1PR0401MB1536097366C596C42A8B225B924F0@CY1PR0401MB1536.namprd04.prod.outlook.com \
    --to=rodney.cummings@ni.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kernel@savoirfairelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.