[e2e] use of MAC addresses

[John Day]

This has been an unbelievable discussion.  That in 2006, there is 
still such confusion.

Fahad asked a perfectly reasonable theoretical question.  First, 
Fahad please read carefully Jerry Saltzer's 1982 paper, RFC1498. 
Most of what you want is in there.  Saltzer gets it right.

In addressing, one has a choice of naming interfaces or protocol 
machines.  It doesn't matter which as long as you are consistent. 
Naming the interface is equivalent to naming the lower protocol 
machine it is bound to.  So to answer your question, yes, the IP 
address and the MAC address do name the same thing.

As has been pointed out, strictly speaking on a point to point media 
one does not need the lower address, but one does on a shared media. 
Actually for authentication purposes, you probably always want to 
have some identifier from the new device to ensure that he is who you 
think he is. Something like a serial number.  And given that MAC 
addresses were originally assigned at the factory, that is precisely 
what it is, a serial number, not an address.  (And as someone pointed 
out, the MAC address has greater scope than the IP address, which is 
strange since scope should increase as one goes up in the 
architecture.)

Saltzer says that a complete addressing architecture needs 
Application Names, Node Addresses, Point of Attachment Addresses and 
from all of this we get routes.  There is one refinement I would make 
to Saltzer which I think was overlooked because it hadn't occurred 
when he wrote the paper.  Salzter talks about the mappings of 
application names to node addresses, node addresses to point of 
attachment addresses and points of attachments to routes.

The refinement is that routes are sequences of node addresses.  The 
routers must also maintain the mappings of node addresses to points 
of attachment addresses for all nearest neighbors.  Once the next hop 
is determined from the route, this last mapping is used to determine 
the choice of *path* to the next hop.  Multiple paths between next 
hops were rare or non-existent in 82, so it isn't surprising Saltzer 
missed it.  Actually, this refinement brings a very nice symmetry to 
the whole structure.

The implications are interesting.  If you carefully read Saltzer's 
description and construct what he says and then hold it up to our 
current situation, you find that we are missing half of the necessary 
elements.  We have no application names and no node addresses.  IP 
addresses by naming the interface are points of attachments. And as 
you figured out we name the point of attachment twice.  There are a 
number of implications that fall out of this that explain why some 
things are so cumbersome in the current architecture and would be 
no-brainers if it were complete.

(For those who were worrying about an identifier that doesn't change, 
it is the application name.  All the others do change.)

When I worked through this and was quite surprised by the outcome, I 
began to wonder on how we got here.  As I turned over in my head 
those early events that was even more surprising.  Basically the 
Internet addressing architecture is an unfinished demo.  And the demo 
was ICCC 72!  ;-) We jury-rigged stuff for the demo and never went 
back to finish the job.

It is almost criminal that none of this is explained in any textbook 
currently out there, especially given that it is something we have 
known for almost a quarter century.  This is the scientific 
explanation, now of course the engineering explanation is a bit 
different.

Take care,
John

At 14:45 +0500 2006/04/14, Fahad Dogar wrote:
>On 4/14/06, Joe Touch <touch at isi.edu> wrote:
>>
>>
>>  Fahad Dogar wrote:
>>  > On 4/13/06, Joe Touch <touch at isi.edu> wrote:
>>  ...
>>  > IMHO, we have to change these protocols because they have been
>>  > designed keeping in view the presence of MAC addresses and how they
>>  > work.
>>
>>  You need to change the protocols only if they don't do something you
>  > need to do. What is it you need to do?
>>
>>  > If we were to redesign Internet and networking technologies
>>  > (clean slate approach), do we need to have a different MAC address.
>>  > Shouldn't IP address be sufficient? It is like assigning a globally
>  > > unique name to every person and then asking him to maintain an
>>  > additional name for 'local' identification.
>>
>>  The locally unique address is how you know you're different from someone
>>  else before you get (or pick a random, possibly colliding) IP address.
>
>I think this is one very valid answer to my question.  My question was
>not on whether we should do away with MAC addresses. As has been
>rightly pointed out in this thread there is no need to do this ---
>both from cost and efficiency point of view. I was interested in
>knowing whether we can do this in 'theory' i.e. if we can identify an
>interface by an IP address then in theory we should be able to reach
>that interface without requiring any other form of identification.
>
>You have right mentioned the need for another address during the phase
>when the IP address is not assigned (DHCP). Any other alternative
>based on (name, address) combination is effectively an alternate to
>MAC address which shows that we DO need an identifier in addition to
>the IP address.
>
>Thanks,
>Fahad
>
>>  The reason for that need is the MAC protocol - bridging, backoff,
>>  spanning tree, etc. If you design a multi-access subnet that doesn't
>>  need unique a-priori addresses, then you might be able to reuse IP
>>  addresses.
>>
>>  I.e., this needs to be motivated at the MAC layer.
>>
>>  Joe
>>
>>