> The NAT working group produced a number of documents. Some explained the > limitations, while one explained to application writers how to live in the > real world that includes NATs. Read RFC 3235. nope, RFC 3235 doesn't explain how to make your applications work in the presence of NATs. it essentially says: there are lots of things you can't do in the presence of NATs, so don't do them. never mind that they make the network dysfunctional, the document is written as if this is somehow a feature. > A $50 NAPT box (using terminology from the NAT WG's terminology RFC) > provides sufficient firewalling and purposeful interruption of applications > for the typical DSL or cable modem user. and kills that user's ability to run valuable applications. in fact, the NAT is not a firewall at all. it isn't implementing any policy specified by the user. what it's doing is imposing some arbitrary restrictions on the user's network that may or may not serve the user's interests at all. it's snake oil. > It runs somewhere OTHER than on > the user's computer, so when a virus gets in and tries to disable the > user's firewall software, less damage is done. well, the user's computer gets infected anyway. the NAT is left unharmed, but I don't consider this a feature. > Sadly, the IETF seems to find ways to generate immense amounts of heat over > NAT, while sticking its collective head in the sand with regards to > activity in the marketplace. the NAT vendors are the irresponsible ones. they create a mess out of the network and then expect IETF to clean it up, then claim that IETF is in denial for not doing so. and of course IETF has tried to do so, more than once, and failed. not for lack of effort, but because it's simply not possible to fix NATs. maybe you are the one who needs to get his head out of a dark place. Keith