RE: Stupid NAT tricks and how to stop them.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]