Noel,
Delivering IP packets _always_ involves a translation
service. Usually, more than one, but - assuming we start
with IP addresses - there is at least one MAC (or other L2)
lookup that must occur before the packets can be delivered.
We should be careful not to assert "layer dependent"
statements in a world in which layering is only locally
unambiguous.
The problem with the "road-network" analog is that I
have no "intrinsic" requirement to relinquish "my" network
address because I've become mobile. The same thing could -
in theory - be said about street addresses, but the current
binding/interpretation of street addresses is entrenched in
centuries of usage that prevents this from (probably) ever
becoming practical.
That is not only NOT true in theory for IP(v4/v6)
addresses, it is not true in practice.
--
Eric
--> -----Original Message-----
--> From: jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu
[mailto:jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu]
--> Sent: Tuesday, March 28, 2006 1:17 PM
--> To: ietf(_at_)ietf(_dot_)org
--> Cc: jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu
--> Subject: RE: Stupid NAT tricks and how to stop them.
-->
--> > From: "Gray, Eric" <Eric(_dot_)Gray(_at_)marconi(_dot_)com>
-->
--> > I think the "street address" analogy is not close
--> enough - anymore
--> > than longitude and latitude numbers or any other
--> description of
--> > physical location.
-->
--> No, it's a very good analogy, because the road network is a
--> very good analog
--> to the data network. To see how, let's do a though-experiment.
-->
--> Embed the road-network, not on the surface of a solid
--> sphere, but on the
--> surface of a flexible hollow spherical surface. Now,
--> distort that surface
--> arbitrarily. The location (in spatial coordinates) of any
--> place on that road
--> network has changed totally - but the set of directions
--> you'd use to get
--> from one point in the road network to another ("go down
--> road A until you
--> meet the junction with B, and turn onto B in the direction
--> of C", etc, etc)
--> remains unchanged.
-->
--> What is most important about both the data network, and the
--> road network, is
--> the *connectivity pattern* - what connects to what. That's
--> because packets
--> are (usually) constrained to travel down links, and
--> vehicles are (usually)
--> constrained to travel down roads.
-->
--> > The problem with physical location portability is
--> that the location
--> > remains even if you're not in it.
-->
--> But the exact same thing is true of a network - Port #0 on
--> ISP A's router R
--> is the same place in the network (i.e. you use the same
--> directions to get to
--> it - see above) whether company X or company Y is plugged
--> in there - just as
--> 126 Main Street is the same building, whether company X or
--> company Y is
--> housed there.
-->
--> > Number assignments, however are substantially more portable.
-->
--> Saying that doesn't make it so. You can easily (sic) change
--> street names
--> too, to make a street name "portable".
-->
-->
--> > It is certainly possible for an IPv6 address pool
--> manager to allocate
--> > personalized IPv6 addresses from an IPv6 address pool
--> that they manage
--> > and thereby assume responsibility for end-delivery
-->
--> That's just a translation service from *virtual* addresses
--> to real ones -
--> those IPv6 "addresses" aren't the names of locations in the
--> network: if the
--> pool manager *actually wants to get packets* to those
--> entities, it is going
--> to have to translate those "addresses" into the real
--> addresses at which
--> those entities can be found.
-->
--> Noel
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf