public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Mark Rustad <mrustad@mac.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: virtual interface mac adress
Date: Sun, 04 Dec 2005 20:57:35 -0800	[thread overview]
Message-ID: <4393C8BF.9010209@zytor.com> (raw)
In-Reply-To: <4CA89BCD-690D-45F8-864C-E0CE1CCC832C@mac.com>

Mark Rustad wrote:
> 
> Theoretically that is true, however there are usages that have been  
> approved that violate that principal. One was for TI Token Ring  chips. 
> They were completely unable to use "global" MAC addresses -  the local 
> bit always had to be set. Since TI could/would not fix  their chips, 
> using the local address became allowed for a universally  unique address.
> 
> This method was later used by Apple on Ethernet for their DOS card.  The 
> Macintosh environment would get the global address and the DOS  card 
> would get the local one through the shared ethernet port. You  might 
> think that you can ignore the token ring case, but you'd be  wrong - 
> there are ethernet/token ring bridges deployed. The Apple  case is also 
> best not ignored. I don't know how many others may be  doing similar 
> things.
> 
> So, I would not advise anyone to simply believe that they can use the  
> entire local MAC address space safely. You are also very likely to  have 
> trouble if there is any DECnet usage in the area. Anyone else  notice 
> that DECnet kernel patch recently? Someone must still be using  it...
> 
> This is an instance where Linus' comment a few weeks ago regarding  
> specs vs. reality comes into play. This is kind of an obscure area so  
> not a whole lot of people know about some of these things. Don't  
> believe everything you read in magazines regarding MAC addresses  
> either. I've seen some very bad advice there from time to time in  this 
> particular area.
> 
> I would recommend using the same MAC address with the local bit set  (as 
> Apple did) for a single additional address. If you need more  addresses 
> and need them to be visible on the LAN, I don't know of a  reliable, 
> generic solution off the top of my head.
> 

By definition, using local addresses is probabilistic.  There are moron 
hardware manufacturers, as you show above (which aren't even the worst 
of the lot, from what I've seen), but your cross-section with other 
local-address users will be very small (collision only likely around 
2^23 nodes.)

Reducing the address space available to randomly pick from will only 
increase the likelihood of failure.

This is an instance where an understanding of statistics come into play.

	-hpa

  reply	other threads:[~2005-12-05  4:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-04 19:29 virtual interface mac adress anil dahiya
2005-12-04 20:20 ` Rik van Riel
2005-12-04 20:41   ` H. Peter Anvin
2005-12-05  4:05     ` Mark Rustad
2005-12-05  4:57       ` H. Peter Anvin [this message]
2005-12-05 18:01 ` Stephen Hemminger

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=4393C8BF.9010209@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrustad@mac.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox