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
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
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
maybe you are the one who needs to get his head out of a dark place.