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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf