[134277] in North American Network Operators' Group
Re: The tale of a single MAC
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Sun Jan 2 17:39:59 2011
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <20110103084554.6421c76c@opy.nosense.org>
Date: Sun, 2 Jan 2011 17:38:54 -0500
To: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 2, 2011, at 5:15 54PM, Mark Smith wrote:
> Hi,
>=20
> On Sun, 2 Jan 2011 08:50:42 -0500
> Steven Bellovin <smb@cs.columbia.edu> wrote:
>=20
>>=20
>> On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote:
>>=20
>>> On Sat, 01 Jan 2011 20:59:16 -0700
>>> Brielle Bruns <bruns@2mbit.com> wrote:
>>>=20
>>>> On 1/1/11 8:33 PM, Graham Wooden wrote:
>=20
> <snip>
>=20
>>>>=20
>>>> Excellent example is, IIRC, the older sparc stuff, where the =
ethernet=20
>>>> cards didn't have MAC addresses as part of the card, but were =
stored in=20
>>>> non-volatile or battery backed memory.
>>>=20
>>> This was actually the intended way to use "MAC" addresses, to used =
as
>>> host addresses rather than as individual interface addresses, =
according
>>> to the following paper -
>>>=20
>>> "48-bit Absolute Internet and Ethernet Host Numbers"
>>> Yogan K. Dalal and Robert S. Printis, July 1981
>>> http://ethernethistory.typepad.com/papers/HostNumbers.pdf
>>=20
>> Yup.
>>>=20
>>> That paper also discusses why 48 bits were chosen as the size, =
despite
>>> "Ethernet systems" being limited to 1024 hosts.=20
>>>=20
>>> I think things evolved into MAC per NIC because when add-in NICs
>>> were invented there wasn't any appropriate non-volatile storage on =
the
>>> host to store the address.=20
>>>=20
>> On really old Sun gear, the MAC address was stored on a separate ROM =
chip; if the
>> motherboard was replaced, you'd just move the ROM chip to the new =
board.
>>=20
>> I'm not sure what you mean, though, when you say "when add-in NICs =
were
>> invented" -- the Ethernet cards I used in 1982 plugged into Unibus =
slots
>> on our VAXen, so that goes back quite a ways...
>>=20
>=20
> More that as add-in cards supplied their own "storage" for the MAC
> address, rather than expecting it from the host (e.g. something like
> MAC addresses set by init scripts at boot or the ROM chip you
> mentioned on Suns), this has now evolved into an expected model of a
> MAC address tightly bound to an Ethernet interface and supplied by the
> Ethernet interface e.g. by an add-in board if one is added. Now that
> this model as been around for a long time, people find it a bit =
strange
> when MAC addresses aren't as tightly bound to a NIC/Ethernet =
interface.
> This is all speculation on my part though, I'd be curious if the
> reasons are different.
>=20
> When I first read that paper, it was really quite surprising that =
"MAC"
> addresses were designed to be more general host addresses/identifiers
> that were also to be used as Ethernet addresses. One example they talk
> about is using them as unique host identifiers when sharing files via
> floppy disk.
>=20
If you read the XNS specs, you'll see that they liked 64-bit addresses =
--
a 16-bit network number and a 48-bit host address. In other words, they
had id/locator separation...
--Steve Bellovin, http://www.cs.columbia.edu/~smb
