Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!ncar!noao!arizona!arizona.edu!leonard
From: leonard@arizona.edu
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ethernet Address Uniqueness...
Message-ID: <1990Oct5.123350.145@arizona.edu>
Date: 5 Oct 90 19:33:49 GMT
References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>
Organization: University of Arizona
Lines: 29

In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET 
writes:
> In the DEC VAX environment the unique Ethernet address on each board is
> overridden by DECNET when it starts to use that board.  The address is set
> to four bytes of a constant value plus two bytes which contain the DECNET
> area and node numbers.  Lots of opportunity for duplication!
> Does anyone know why DEC chose this scheme?

Sure, it saves DECnet having to have an address resolution protocol a la
ARP ... if a DECnet node wants to find the MAC address for a given DECnet
address, it already knows what the address *should* be.

There's a couple of problems with this approach:

1. If you are running different network protocols on the same Ethernet
board, then obviously they can't *all* do this!  I believe that Novell's
IPX similarly hacks the Ethernet address, which (if true) means that DECnet 
and IPX can't share the same board.

2. A DECnet node can't have multiple Ethernet interfaces running DECnet on
the same bridge-extended Ethernet.  (Because the bridges will see the
same Ethernet addr on both sides!)  This may seem like a perverse topology
to IP oriented folks, but given DEC's historical MAC layer uber alles 
approach, in some situations this can be exactly what you would want.

In DECnet Phase V (due out twelve months from any given point in
time ;-) ), DECnet is supposed to stop resetting the hardware
addresses on its Ethernet adapters, and will presumably adopt some
ARP protocol.