In article <1fednYDifbVWOh_anZ2dnUVZ_gKdnZ2d@comcast.com>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Nico Coesel wrote:
> (snip)
> 
> > Besides, if you are going to generate random MAC addresses you may get
> > intermittant errors because fixed MAC addresses are expected. Those
> > kind of errors are the last you want on a network.
> 
> Not so much network errors as administration problems.  It is harder
> to track down devices with variable MAC addresses.
> 

The intent was never to have MAC addresses generated at random *in the 
field*, i.e., upon interface initialization. The idea was to generate 
them at random in the *manufacturing process*; there would not be 
"variable" MAC address for a given device over time. We only wanted to 
avoid the OUI administration problem.



--
Rich Seifert              Networks and Communications Consulting
                          21885 Bear Creek Way
(408) 395-5700            Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Nico Coesel wrote:
> 
> Yes and no. Like others already pointed out, devices need a serial
> number anyway. Not just for administration but also to keep track of
> devices. So having a fixed number (MAC address) assigned to unit xyz
> generally saves a lot of trouble.
> 
> Besides, if you are going to generate random MAC addresses you may get
> intermittant errors because fixed MAC addresses are expected. Those
> kind of errors are the last you want on a network.
> 

A bigger issue is that randomness is frequently a premium resource in 
real-life systems.

	-hpa

MikeShepherd564@btinternet.com wrote:
> 
> The options seem to be:
> 
> 1) Buy a batch of unique addresses (which isn't cheap and involves
> administrative hassle).  If you're designing a LAN for an airliner I'm
> going to fly on, I'd like you to use this method.
> 

Costs $1,650 for 16,777,216 unique addresses.

http://standards.ieee.org/regauth/oui/forms/

	-hpa

Nico Coesel wrote:
(snip)

> Yes and no. Like others already pointed out, devices need a serial
> number anyway. Not just for administration but also to keep track of
> devices. So having a fixed number (MAC address) assigned to unit xyz
> generally saves a lot of trouble.

As the subject is FPGAs, I believe it isn't hard to change data in
a synthesized ROM after the bit file has been generated.  That should
be pretty convenient for generating the packet.  Getting the IP
address is a little harder.

> Besides, if you are going to generate random MAC addresses you may get
> intermittant errors because fixed MAC addresses are expected. Those
> kind of errors are the last you want on a network.

Not so much network errors as administration problems.  It is harder
to track down devices with variable MAC addresses.

-- glen

Rich Seifert wrote:

(snip)

> We *did* consider using randomly-chosen addresses, but in a 64-bit 
> address space; the probability of a clash in a 48-bit space was 
> considered too high. I wrote a paper on the subject back in 1979-80, 
> which is probably lost to history.

Higher than the actual clash rate on the current system?

> Although properly-implemented random addresses would have worked, we 
> chose the administered-vendor-space 48-bit scheme of today as being more 
> "politically palatable"; I am sure we would have been hammered even 
> worse about letting randomness control network addressing than we were 
> about letting randomness control the backoff algorithm.

I have heard stories about NICs produced with the same address,
most likely in the same batch with a high probability of being
installed on the same net.

We once had a Sun system that the local computer hardware people
sent back to Sun to be fixed.  The rule at the time was that one
should remove the ROM (or battery backed RAM) before sending it
in.  In this case, it was reinstalled backwards destroying the
stored address.  Losing the stored address from battery backed
RAM can't be that uncommon.  (The battery life tends to be
less than the processor life.)

Also, I once knew a net with a device with address 00:00:00:00:00:00.
As there was only one, it was decided to leave it alone.

-- glen

In article <B_KdnWf0IICN1hzanZ2dnUVZ_t6onZ2d@comcast.com>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> John McCaskill wrote:
> 
> > While I agree that the MAC ID space is so large that the chance of a
> > collision for a random address is very low, I do not agree with that
> > statement.  Buying a range of unique addresses is cheap and easy, and
> > no administrative hassle is involved.
> 
> There is a story that in the beginnings of ethernet using random 48 bit
> MAC addresses was considered, but rejected because of the (small)
> probability of two accidentally choosing the same address.
> 
> As I understand it, in the current system there have been devices
> produced that accidentally had the same address.  As the current system
> involves humans, such as programming ROMs and installing them in cards,
> there is a relatively high probability of accidents.
> 
> Choosing a random 46 bit number with the local administration bit
> on and the multicast bit off might not be so bad.
> 

We *did* consider using randomly-chosen addresses, but in a 64-bit 
address space; the probability of a clash in a 48-bit space was 
considered too high. I wrote a paper on the subject back in 1979-80, 
which is probably lost to history.

Although properly-implemented random addresses would have worked, we 
chose the administered-vendor-space 48-bit scheme of today as being more 
"politically palatable"; I am sure we would have been hammered even 
worse about letting randomness control network addressing than we were 
about letting randomness control the backoff algorithm.


--
Rich Seifert              Networks and Communications Consulting
                          21885 Bear Creek Way
(408) 395-5700            Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

In article <B_KdnWf0IICN1hzanZ2dnUVZ_t6onZ2d@comcast.com>,
	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> There is a story that in the beginnings of ethernet using random 48 bit
> MAC addresses was considered, but rejected because of the (small)
> probability of two accidentally choosing the same address.
> 
> As I understand it, in the current system there have been devices
> produced that accidentally had the same address.  As the current system
> involves humans, such as programming ROMs and installing them in cards,
> there is a relatively high probability of accidents.

In the early days, address allocations were notified to
applicants in the order the bits are transmitted in an
ethernet frame on the wire, and a significant number of
the early vendors produced loads of kit using completely
the wrong OUI as a consequence (with the bits in every
octet of the OUI in reverse order).

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>John McCaskill wrote:
>
>> While I agree that the MAC ID space is so large that the chance of a
>> collision for a random address is very low, I do not agree with that
>> statement.  Buying a range of unique addresses is cheap and easy, and
>> no administrative hassle is involved.
>
>There is a story that in the beginnings of ethernet using random 48 bit
>MAC addresses was considered, but rejected because of the (small)
>probability of two accidentally choosing the same address.
>
>As I understand it, in the current system there have been devices
>produced that accidentally had the same address.  As the current system
>involves humans, such as programming ROMs and installing them in cards,
>there is a relatively high probability of accidents.
>
>Choosing a random 46 bit number with the local administration bit
>on and the multicast bit off might not be so bad.

Yes and no. Like others already pointed out, devices need a serial
number anyway. Not just for administration but also to keep track of
devices. So having a fixed number (MAC address) assigned to unit xyz
generally saves a lot of trouble.

Besides, if you are going to generate random MAC addresses you may get
intermittant errors because fixed MAC addresses are expected. Those
kind of errors are the last you want on a network.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

John McCaskill wrote:

> While I agree that the MAC ID space is so large that the chance of a
> collision for a random address is very low, I do not agree with that
> statement.  Buying a range of unique addresses is cheap and easy, and
> no administrative hassle is involved.

There is a story that in the beginnings of ethernet using random 48 bit
MAC addresses was considered, but rejected because of the (small)
probability of two accidentally choosing the same address.

As I understand it, in the current system there have been devices
produced that accidentally had the same address.  As the current system
involves humans, such as programming ROMs and installing them in cards,
there is a relatively high probability of accidents.

Choosing a random 46 bit number with the local administration bit
on and the multicast bit off might not be so bad.

-- glen

On Jan 6, 2:54 am, John McCaskill <jhmccask...@gmail.com> wrote:
> <snip>
>
> > 1) Buy a batch of unique addresses (which isn't cheap and involves
> > administrative hassle).  If you're designing a LAN for an airliner I'm
> > going to fly on, I'd like you to use this method.
>
> Mike,
>
> While I agree that the MAC ID space is so large that the chance of a
> collision for a random address is very low, I do not agree with that
> statement.  Buying a range of unique addresses is cheap and easy, and
> no administrative hassle is involved.
>
> The IEEE administers MAC IDs, and you can buy a range of them for a
> one time fee online.  I bought the OUI package online with a credit
> card and have no regrets. Take a look at:
>
> http://standards.ieee.org/regauth/oui/index.shtmlhttp://standards.ieee.org/regauth/oui/pilot-ind.htmlhttp://standards.ieee.org/regauth/oui/forms/
>
> You can buy a 4K block of MAC IDs for $500 USD, or a 2^24 block of IDs
> for $1650.  That is lost in the noise for producing a commercial
> product.
>
> This is a far better deal than I get from the PCI SIG where I have to
> pay every year to retain my vendor ID. For the MAC IDs, I pay once and
> it is mine for ever.
>
> While I am a small business owner and complain about every penny
> spent, I think that the IEEE gives me a fair deal.

Another option is to let the customer set the ID through some
configuration option. That way collisions can be avoided post
manufacture. And the administrator can't claim that you used an ID
"without permission".