[ih] History of duplicate address tests

Bill Nowicki winowicki at yahoo.com
Thu Dec 1 14:03:22 PST 2022


 Reminds me of this anecdote about Sun's early days (maybe people have already heard it).
The rule for the commercial Ethernet was 24 bits of organization number assigned by IEEE, and 24 bits assigned by vendor. At some point it was realized that Sun's addresses had wrapped around. The quick hack that assigned the addresses in manufacturing was lazy and used 16-bit arithmetic instead of 24 bits for the vendor bits. The person who wrote it (I remember who, but will not name names) assumed that Sun would never sell 65,000 machines, but they did.  Do not think any customer ever found out, let alone had any problems with duplicates, since generally they bought machines in batches which were sequentially numbered in those low bits. 
No idea if they ran out of 24 bits. Some vendors presumably did.
Bill
    On Thursday, December 1, 2022 at 01:20:12 PM PST, John Shoch via Internet-history <internet-history at elists.isoc.org> wrote:  
 
 I've always thought that in networking there is a place for absolutes,
perfection, and "error free."
But a really important part of system engineering is about cost/benefit
tradeoff, probabilities, and error recovery.

When considering going from manual assignment of Experimental Ethernet
addresses to a semi-automatic generation of 48-bit addresses to be blown
into a PROM on a board:
--We thought, "It may not be perfect, but it's certainly more reliable than
trying to scale the manual process!"
--"But what are the odds a bit blown into a PROM will heal, and produce a
duplicate ID?"  "Let's just make sure the odds of that are LESS than the
odds of your machine catching fire or dying from a power surge; or your
building being destroyed by lightning, flood, or earthquake; or someone
typing Delete *.*"
--"Have a backup and recovery plan!"  "And if you don't have a recovery
plan for fire, lightning, flood, earthquake, or fumble-fingers, don't
complain about lower-probability network events....."

John

PS:  In a similar vein, I would sometimes field provocative questions, "Why
don't you have encryption on the Ethernet?"  I would merely observe, "We do
have a project to build a crypto box in front of the Ethernet transceiver,
for serious government customers with Tempest needs.  But do you shred all
your letters and print-outs before they go in the dumpster?  If not, you
have worse problems than your Ethernet....."

On Thu, Dec 1, 2022 at 12:00 PM <internet-history-request at elists.isoc.org>
wrote:

>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 Dec 2022 08:47:19 +1300
> From: Brian E Carpenter <brian.e.carpenter at gmail.com>
> To: Bob Hinden <bob.hinden at gmail.com>, Jack Haverty <jack at 3kitty.org>
> Cc: internet-history at elists.isoc.org
> Subject: Re: [ih] History of duplicate address tests
> Message-ID: <7f330b01-d5be-2f51-c437-ae051dcb0a45 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 02-Dec-22 07:55, Bob Hinden via Internet-history wrote:
> > Hi Jack,
> >
> >> On Dec 1, 2022, at 10:03 AM, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >>
> >> Hi Grant,
> >>
> >> Thanks for the update.  I remember reporting the issue to IETF back in
> the mid 80s and again in the early 90s.  I guess it still hasn't risen to
> the top of anybody's priority list.
> >
> > As was noted earlier, Duplicate Address Detection (DAD) was included in
> IPv6.    Our thinking at the time was to detect broken hardware NICs (all
> with the same mac address) as we were initially using MAC addresses to form
> Interface IDs.  We have moved away from that, see RFC 8064.  I think DAD
> is still useful to detect misconfigured manually assigned addresses.
>
> And you cannot 100% discount a collision between pseudorandom IIDs. Yes,
> very very unlikely, unless you have lousy random number generators, which
> we'll never have, right?
>
>    Brian
>
>
>
>
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
  


More information about the Internet-history mailing list