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@ISI.EDU] Sent: Monday, March 18, 2002 8:08 AM To: Peter Ford Cc: Andrew McGregor; Vivek Gupta; ietf@ietf.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