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@xxxxxxxxxxxxxxxxxxx [mailto:jnc@xxxxxxxxxxxxxxxxxxx] --> Sent: Tuesday, March 28, 2006 1:17 PM --> To: ietf@xxxxxxxx --> Cc: jnc@xxxxxxxxxxxxxxxxxxx --> Subject: RE: Stupid NAT tricks and how to stop them. --> --> > From: "Gray, Eric" <Eric.Gray@xxxxxxxxxxx> --> --> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf