Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IBM TCP. Really DECnet and Ethernet addresses
Message-ID: <870811103840.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Tue, 11-Aug-87 10:38:00 EDT
Article-I.D.: KOYAANIS.870811103840.1.DCP
Posted: Tue Aug 11 10:38:00 1987
Date-Received: Thu, 13-Aug-87 02:13:40 EDT
References: <12325522493.139.SY.KEN@CU20B.COLUMBIA.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 23

There are a lot more Ethernet addresses than Internet addresses, and I
don't hear people screaming (yet) that we're running out of Internet
addresses.  (I do remember screaming that there weren't enough class A
subnets, and later screaming that we had to be careful about doling out
class B and C addresses because of fixed-size non-replacable tables in
some older gateway implementations.  Anyway...)  The V1.0 Ethernet
allowed for 2^23 vendors.  That's 8 million vendors.  Each vendor gets
2^24 addresses.  That's 16 million addresses.  It's conceivable that a
vendor could run out of addresses, and my solution would be to give the
vendor another (or several more) chunks of 2^24 addresses.  Even if
every person on the planet (about 2^32 people) had 64 machines (2^6) and
got a new address for each machine every year, the Ethernet address
space (2^47) allows for 2^(47-32-6) = 2^9 = 512 years of such
(farfetched) activity.  This is why the addressing hasn't "blown up
yet," to use your phrase.  There is therefore no need to recycle
hardware addresses if a particular board (e.g., your DEC-20's) is
unfixable.

As for your DEC-20 board, replacing a board and/or changing an Ethernet
hardware address for a host works pretty well if you use a
dynamic protocol->hardware address translation mechanism such as ARP.
The minor problem being the transition time until the hosts learn of the
new address, and this problem is discussed in the RFC.