Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be. Or it
is assumed that mac addresses are being widely reused throughout the world?
All those low cost switches and wifi adapters DO use unique mac addresses?
I've seen duplicate addresses in the wild in the past, I assume there
is some amount of reuse, even though they are suppose to be unique.
-jim
There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
-Dave
Sun, for one, used to assign the same MAC address to every NIC in the
same box.
Technically, they assigned a MAC to the NIC and a MAC to the box.
Unless you configured it otherwise, all NICs in the box defaulted to
using the box's MAC instead of their own.
Made for some interesting problems with early VLAN switches...
Regards,
Bill Herrin
5 percent of the mac addresses in a ADSL population used the same MAC address. Turned out to be some D-link device that didn't have unique address but they all had the same, and had a feature where you could "clone" the internal PC MAC address if you wanted to, otherwise it used some default address.
D-link support responded to customer inquiries with "yes, we know that they're not unique enough". Nuff said, avoid.
Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010:
> There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions.
>
> -Dave
>
>
> > I've seen duplicate addresses in the wild in the past, I assume there
> > is some amount of reuse, even though they are suppose to be unique.
> >
> > -jim
> >
> >> Hi,
> >>
> >> Lots of traffic recently about 64 bits being too short or too long.
> >>
> >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it
> >> is assumed that mac addresses are being widely reused throughout the world?
> >> All those low cost switches and wifi adapters DO use unique mac addresses?
> >>
Sun, for one, used to assign the same MAC address to every NIC in the
same box.
I could see how that *could* work as long as each interface connected to
a different LAN.
Maybe the NICs shared a single MII/MAC sublayer somehow? I've never
borne witness to this though.
Re: MAC address exhaustion, if the the second-to-least significant bit
in the first byte is 0 (Globally Unique / Individually Assigned bit),
then the first three bytes of the MAC should correspond to the
manufacturer's "Organizationally Unique Identifier". These are
maintained by the IEEE, and they have a list of who's who here:
http://standards.ieee.org/regauth/oui/index.shtml
I haven't ever programmatically gone through the list, but it looks like
a lot of the space is assigned.
Cheers,
jof
> There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are
likely to be errors, not accidental collisions.
>
> -Dave
>
>
> > I've seen duplicate addresses in the wild in the past, I assume there
> > is some amount of reuse, even though they are suppose to be unique.
> >
> > -jim
> >
> >> Hi,
> >>
> >> Lots of traffic recently about 64 bits being too short or too long.
> >>
> >> What about mac addresses? Aren't they close to exhaustion? Should be. Or it
> >> is assumed that mac addresses are being widely reused throughout the world?
> >> All those low cost switches and wifi adapters DO use unique mac addresses?
> >>
Sun, for one, used to assign the same MAC address to every NIC in the
same box.
Which is perfectly legal.
There was a socketed ROM IC with the *machine's* MAC address on the motherboard, way back when. If your motherboard needed replacing, the tech would move that IC to the replacement.
Why was this done? The reason was simple: compatibility with other stacks. Remember that circa 1988-1990, it was not obvious that TCP/IP was going to be the winner.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
http://en.wikipedia.org/wiki/MAC_address
The IEEE expects the MAC-48 space to be exhausted no sooner than the
year 2100[3]; EUI-64s are not expected to run out in the foreseeable
future.
Richard A Steenbergen wrote:
Hi,
Lots of traffic recently about 64 bits being too short or too long.
What about mac addresses? Aren't they close to exhaustion? Should be.
Or it is assumed that mac addresses are being widely reused throughout
the world? All those low cost switches and wifi adapters DO use unique
mac addresses?
http://en.wikipedia.org/wiki/MAC_addressThe IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100[3]; EUI-64s are not expected to run out in the foreseeable future.
And this is what happens when you can use 100% of the bits on "endpoint identity" and not waste huge sections of them on the decision bits for "routing topology".
Of course it comes with a privacy problem if you want to use that endpoint identifier globally and not change it for every session (as some protocols that separate routable-address from endpoint-identity do)
Matthew Kaufman
Having around 4 orders of magnitude more addresses probably doesn't hurt
either...
Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are
assignable to/by vendors, with the other 3/4 being assigned to multicast and
local addresses (the MAC equivalent of RFC1918)
Scott.
That was a logic Sun used. Every NIC would be connected to a different
subnet, so duplicate MACs shouldn't be a problem. For the most part
this worked, but some situations required a unique MAC per NIC, and Sun
had a bit you could flip to turn this on. I believe it was an OpenBoot
prom variable called "local-mac-address?" which you'd set to true if you
wanted it to use each NICs MAC instead of the "system MAC".
-Jim
You can set the MAC address to whatever you want in Solaris, using
ifconfig and local-mac-address was (is) the PROM variable.
Hardware MAC-48 addresses are not assigned based on a network
topology. The first 24 bits are used for OUI which is an ID number
applied for [and paid for] by a manufacturer of network devices, the
2nd LSB of the most significant byte is reserved for 'local vs
universal administration flag', and the LSB of the most significant
byte is reserved for unicast/multicast flag. The bottom 24 bits
are assigned by manufacturer.
So there are 22 bits of usable global unicast OUIs, that is
4,194,304 possible.
and each OUI has 16,777,216 MAC address numbers.
Of the possible OUIs, only 13,557 are currently listed as allocated
in the IEEE OUI listing.
http://standards.ieee.org/regauth/oui/index.shtml
So a theoretical maximum of 227,448,717,312 unicast MAC addresses
could be globally assigned today (which is a vast overestimate,
assuming all presently assigned OUIs are already completely
exhausted). Out of 70,368,744,177,664, that is what, 0.3% ?
That actually follows the original MAC addressing model -
"48-bit Absolute Internet and Ethernet Host Numbers"
http://ethernethistory.typepad.com/papers/HostNumbers.pdf
As add-in cards needed their own address, because they couldn't be sure
the host had one, and most likely didn't, I think that has evolved into
unique MAC addresses per-interface rather than per-host.
Regards,
Mark.
> http://en.wikipedia.org/wiki/MAC_address
>>
>> The IEEE expects the MAC-48 space to be exhausted no sooner than the year
>> 2100[3]; EUI-64s are not expected to run out in the foreseeable future.
>>
>>
>
> And this is what happens when you can use 100% of the bits on "endpoint
> identity" and not waste huge sections of them on the decision bits for
> "routing topology".
>Having around 4 orders of magnitude more addresses probably doesn't hurt
either...Although even MAC-48 addresses are "wasteful" in that only 1/4 of them are
assignable to/by vendors, with the other 3/4 being assigned to multicast and
local addresses (the MAC equivalent of RFC1918)
Has anybody considered lobbying the IEEE to do a point to point version
of Ethernet to gets rid of addressing fields? Assuming an average 1024
byte packet size, on a 10Gbps link they're wasting 100+ Mbps. 100GE /
1TE starts to make it even more worth doing.
Actually the minimum 64 byte packet size could probably go too, as that
was only there for collision detection.
If you're lobbying to have the IEEE do something intelligent to Ethernet
why don't you start with a freaking standardization of jumbo frames. The
lack of a real standard and any type of negotiation protocol for two
devices under different administrative control are all but guaranteeing
end to end jumbo frame support will never be practical.
Not that I disagree, given that we use them rather a lot but 7.2usec (at 10Gbe) is sort of a long time to wait before a store and forward arch switch gets down to the task of figuring out what to do with the packet. The problem gets worse if mtu sizes bigger than 9k ever become popular, kind of like being stuck behind an elephant while boarding an elevator.
Wasteful in many ways.
While most of end user devices work with temporarily assigned IP addresses,
or even with RFC1918 behind a NAT, very humble ethernet devices come from
factory with a PERMANENTE unique mac address.
And one of those devices are thrown away – let’s say a cell phone with
wifi, or a cheap NIC PC card - the mac address is lost forever. Doesn’t this
sound not reasonable?
A.b. --