Joe,
To a large extent I agree with the goals. And I am not saying NATs are
the cats pajamas, but they do existing and you and I yacking about it
are not going to make them go away. (by the way, most people buying
NATs think they are buying a firewall and often have no clue as how they
work).
Thus, we need to figure out how to get all the nice E2E properties at
the same time living in the world where we have intermediate systems
that need to be convinced to let us do so. What I am suggesting is
that there needs to be a generic way to ask for that permission, get the
request granted, and to operate under that permission. I am proposing
negotiated signaling following the data path, not having the permission
implicitly granted by simply sending data. At a minimum the end system
(application) makes the request, but the architecture should allow
proxies to operate on their behalf as well.
Adding the constraints of preserving dynamic routing (or routing
transparency) is fair. I believe we have seen protocols that can do
that. There have been sightings in networks that implement traffic
management for connectionless networks.
Regards, peterf
-----Original Message-----
From: Joe Touch [mailto:touch(_at_)ISI(_dot_)EDU]
Sent: Monday, March 18, 2002 8:08 AM
To: Peter Ford
Cc: Andrew McGregor; Vivek Gupta; ietf(_at_)ietf(_dot_)org
Subject: Re: Netmeeting - NAT issue
Peter Ford wrote:
If one really believes in end to end architectures, then one probably
would want generalized protocols for supporting hosts telling the
network what to do wrt opening holes at NATs/Firewalls for inbound
traffic.
Actually, if one believes in the E2E arch (more specifically, the STD
documents), we should admit that:
- NATs are _designed_ to make everything behind them
look like a single host
- they work fine exactly where that's sufficient
- they break very badly for EVERY new protocol that
coordinates ports or IP addresses in-band, and in any
other case where everything behind them does NOT
want to work like a single host
A generalized protocol for opening holes would fundamentally alter the
Internet architecture (as specified in the STD docs) to _require_ path
setup, which defeats dynamic routing, and, more specifically, the
fundamentally connection-free property of datagram service.
Joe