All of lore.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 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.