Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!decwrl!ucbvax!HOGG.CC.UOREGON.EDU!jqj
From: jqj@HOGG.CC.UOREGON.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reply to Ethernet Address Uniqueness...
Message-ID: <9010051640.AA26240@hogg.cc.uoregon.edu>
Date: 5 Oct 90 16:40:12 GMT
References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 21

Having the same MAC-level address for all interfaces (phrased differently,
associating the MAC-level address with the NODE rather than with the INTERFACE)
is part of the spec for both DECNET IV and XNS.  It falls out of a design that
has an algorithmic link between the MAC address and the protocol address.

Many people believe that having a protocol address that belongs to the node
rather than to the interface is a Good Idea, and that doing it the other way
was a bad decision in the IP suite.  I don't have a strong opinion, but I
do know that the XNS/DECNET way of doing things makes routing to multihomed
hosts easier.  In the IP world there is no unambiguous way to decide whether
2 IP addresses refer to the same host; sure I can look in the DNS, but there
is no guarantee that either or both addresses will be in the in-addr.arpa
tree.

Other people like the idea of algorithmic mapping from protocol to MAC
address.  It means that you don't need something like ARP, but it also
limits your flexibility substantially, especially on physical networks
like arcnet or 3mb Ethernet where the range of MAC addresses is very 
limited or hardwired in the interface.  And it of course fails to generalize
to cases where one needs to support multiple protocol stacks that each want
to change the MAC address based on the protocol address!