Subject: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt

From: "Christian Huitema" <[email-masked]>
Date: Fri, 20 May 2005 16:35:11 -0700 (PDT)

A lot of this discussion assumes that "address independent filtering"
makes the design of applications much simpler. Well, that is not really
my experience. 

Even with address independent filtering, sending a packet to the
specified address and port often fails. For example, it fails when two
clients are behind the same NAT that does not support hair-pinning, e.g.
when two clients are on different local networks, but behind the same
ISP NAT. It also fails when there are multiple exit NAT for a local
network, and the peer is not reached through the same NAT as the STUN
server. So, in practice, even with "address independent filtering",
applications have to include a verification step to make sure that the
communication actually works. Another fly in the ointment is, there is
almost no way for an application to ascertain that it is actually behind
an "address independent filtering" NAT. 

I do not personally like "address independent filtering". I don't
believe that the exposure is unduly large. It does make P2P application
more reliable, i.e. they tend to work more often. But it does not make
the applications simpler.

-- Christian Huitema

---

From: Bryan Ford <[email-masked]>
Date: Sat, 21 May 2005 08:58:53 -0700 (PDT)

> makes the design of applications much simpler. Well, that is not really

The goal of making applications simplier was never one of my reasons for 
recommending endpoint-independent filtering: indeed, as you point out, given 
that there's no way we're going to make restricted filtering go away even if 
we want to, many applications will still have to be able to deal with being 
located behind a restricted filter.

The issue at hand is not one of application simplicity, but one of basic 
connectivity: endpoint-independent filtering gives the NATted application a 
first-class public presence on the Internet, while restricted filtering 
forces the application to rely on public rendezvous servers for all of its 
peer-to-peer connectivity needs.  As I pointed out in prior messages, common 
peer-to-peer application protocols can work around some (even many) nodes not 
having a first-class public presence, but would break down if very few nodes 
do.

> believe that the exposure is unduly large.

Did you get something reversed here?  The first sentence seems to be against 
endpoint-independent filtering, while the second seems to be for it.

> It does make P2P application 

Exactly.  My argument in favor of endpoint-independent filtering is one of 
application reliability, robustness, and general connectivity, not one of 
implementation simplicity.

Cheers,
Bryan