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
next prev parent 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