I think it's both because of the point made in the last few messages
that the issue is usability. Noel pointed out that MACs as
administered
are not _usable_ as locators because of their structure.
If MACs are used to find a location of an end-system, then they are
locators. When a MAC moves from one location to another, the layer-2
network readjusts to forward packets *in a new direction*. If that is
not a locator, then what is. Just because the value of the 48-bit
address doesn't change doesn't mean it's not a locator.
We do find cases where IP addresses move away from their subnet and
attach to another cable which is assigned another subnet. In that
case, the IP address value of the host doesn't change and with a more
specific route, there is a new location for that IP address.
Both these cases are the same. Both these cases use the address as a
locator.
From a network perspective, if a switching node makes a forwarding
decision based on an address in a packet header, then that address is
a locator.
For example, I would argue that a MAC address meets condition (1) -
i.e.
it names a location in a topology - but it does not meet (2),
because it
does not encode in the name (value) itself any topological
information.
Aha ... A MAC names an interface but not an attachment point. A MAC
is
a property of the device, not the network.
No, a MAC can name a system. MACs are used all the time as serial
numbers for systems. In these cases, sometimes they are used to reach
the system and other cases they are not.
In the case a MAC is used as a serial number purely, it is simply an ID.
On the other end of the spectrum is a
switched ethernet, where knowing the location name (MAC) tells you
nothing about the relative topological position of the point being
named
by the MAC. However, the MAC (in my mind) still serves as the name
of a
location.
A MAC is a property of the device, not the network. Contrast it
with an
attachment point name.
Disagree.
Dino
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
