end2end? (was: RE: Where NAT disenfranchises the end-user ...)

Fri Sep 7 23:10:12 UTC 2001

steve uurtamo wrote:

> when you write a protocol, regardless of the application, that tries
> to make requirements _in the data portion_ about how the remote side
> should write its _header portion_, you really are asking for trouble.

Explain how to build a protocol for the following:

     A -|
        |-Nat-<>-C
     B -|

A wants to tell C how to contact B for a multi-party app. 
A 'knows' the address of B, so why should it require C to 
take several seconds to look it up by name? Even if C were
to look up the name, it would map back to A as far as C is
concerned, so C might not go into multi-party mode because
it has one name and single matching locator.

> NAT != evil, so let's try to be a little bit more evenhanded 
> about this.

NAT is just a technology, so your statement is arguably 
true. As long as the end user has elected NAT as the tool 
for solving the current problem, he accepts the associated
drawbacks. The evilness appears when humans get involved
and NAT is forced on the end user. This could either 
explicitly, or (to be truly evil) unannounced by the service 
provider, while at the same time claiming that they are 
selling Internet service. (This is the point that started 
the original thread)

> and the understanding that if there are such restrictions, 
> it might be a little while (i.e. until all NAT implementations 
> everywhere plug in a handler for the new protocol in question) 
> before all networks in the world are going to be able to pass 
> their packets around with ease and zen-like harmony.  
> is that really so much to ask?  

Actually it is. It is equivalent to insisting that my PI
prefix be distributed globally. From an end user perspective
there is no reason a little pain on the ISPs part should 
prevent me from having continuous connectivity through
full prefix announcement multi-homing. Yet ISPs are 
fat-&-happy pointing out that developers should never 
require a protocol to carry locator information in the 
data stream. There are reasons to do it, so it is 
incumbent on the service providers that enforce NAT to be
straight with their customers about the fact the service
is not full capability transparent Internet access.

Tony