[e2e] use of MAC addresses
day at std.com
Tue Apr 18 06:54:14 PDT 2006
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
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
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.
>> 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
>> I.e., this needs to be motivated at the MAC layer.
More information about the end2end-interest