On Monday, September 20, 2004, at 06:09 PM, Bob Hinden wrote:
I think this ship has left port a long time ago and the likelihood
that the IETF can now effect enough change to make it possible to
write new applications that work consistently in the presence of NATs
is very low. The installed base is much to large and NAT is showing
up in devices being built by people who don't pay too much attention
to the IETF. The same folks who do not build in IPv6, who break path
MTU discovery, who strip out TCP options, etc. Now we expect them to
build "good" NATs...
I'm ambivalent about it for some of the reasons you mention, plus
others.
I think it's important to understand that NAT really is going to be with
us for the foreseeable future. It's fairly common now to have corporate
security auditors require the use of NAT as a security device. That's
a big fat training and cultural problem, and I don't see how the IETF
would be able to change it. I don't think that it's completely
unthinkable
that the *unavailability* of v6 NAT might hold up a transition to v6 in
some corporate environments because of their undereducated security
auditors.
The other thing that's important to understand is that there are often
big changes between firmware releases for many consumer NAT products,
and
that NAT vendors tend not to see making those changes as a terrificly
huge
deal. I don't think I agree with your concerns about lack of interest
in
implementation.
That said, this work in the IETF is being driven by people whose
protocols
break when they have a NAT in the path. I have some concerns about
underinvolvement by people who build NATs for a living, but I think that
it's important to at least get some requirements laid out so that it's
clear what NAT manufacturers could be doing if they were interested.
And
I think they are interested - they're hearing complaints from their
customers. My biggest concerns are about 1) scope creep, and 2) a bunch
of workarounds being cobbled together and interfering with getting
something
better deployed. People who attended the IETF 60 BOF showed some
enthusiasm
for specifying inspection behaviors, which is pretty appalling on
several
levels. On the second point, I think there's legitimate concern that
this
is part of a process of developing a big jumble of duct tape and baling
wire. Part of the problem here is that there's not yet a deployed
solution
for communicating directly with NATs, so in the interim we're doing
STUN.
STUN, however, doesn't work across certain varieties of NATs, so "good"
NAT
behavior has to be specified. And so it goes.
Melinda
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf