[e2e] 0% NAT - checkmating the disconnectors
dga+ at cs.cmu.edu
Tue Mar 7 11:11:53 PST 2006
On Mar 7, 2006, at 1:12 PM, Dave Crocker wrote:
> Note that routers do address translation too. They change the
> current link-layer address to be a new one. (Dontcha just luv
> For all of the implied lessons in distinguishing internal routing
> from exterior routing, we seem to resist re-applying the lesson to
> other parts of the architecture.
> I've come to believe that most of the approach to dealing with NATs
> almost comes for free if we do locator/identifier properly and
> provide a useful 'session' layer (or equivalent function with the
> app layer.)
Most, but not all. The "session" identifier or other equivalent end-
to-end identity tokens (e.g., the identifiers used in HIP, in TCP
Migrate, etc.) are great for improving communication between two
endpoints. They have all sorts of benefits other than NATs: they
facilitate mobility, multi-homing, and probably other things that
begin with "m" (but not multicast, thank you).
Unfortunately, they aren't enough by themselves to provide a global
identifier that retains its validity when passed between hosts (i.e.,
the introduction problem with NATs: You tell me to talk to David P
Reed, but the identifier "David P. Reed" is not valid in my scope).
Note that I said "by themselves" - you can certainly add extra things
(e.g., the way i3 does) to enable this. But most such solutions are
really changing the fundamental unit of addressing, not just adding
This situation is parallel to the one you cited. Layer two addresses
are not global (though by fate of manufacturing they are mostly
unique), and have no validity outside the local scope. If we make IP
behave the same way, then we'll just end up replacing it with some
higher layer addressing and routing space. I like overlays, and I
still think it's a waste to have to use them in this manner when
we've got a perfectly salvagable addressing scheme in ipv6.
Yours in additional levels of indirection,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060307/de8bde22/PGP.bin
More information about the end2end-interest