NAT66: my conclusions

After having debated the virtues of having NAT66 in the first place  
and its features if we were to have it, my conclusion is that we're  
not going to be able to create a NAT66 specification that makes all  
parties happy enough to reach rough consensus.

Having NAT66 at all is hard to swallow for a good number of people.  
The best description of my feelings about the subject are "the only  
good NAT is a dead NAT". But even in IPv4, there's a huge difference  
between different NAT implementations, causing various levels of harm.  
In IPv6, additiotional variations are possible, some causing  
significantly less harm than even the best IPv4 NATs.

For a while I thought it would be a good compromise to standardize one  
of these less nefarious NAT66s in order to avoid ending up with the  
really bad ones. But after the discussion the past few weeks my  
conclusion is that this isn't going to work.

Even within this subset of IETF members who have a decent  
understanding of IPv6 and the internet architecture, there have been  
people arguing for NATs that are more harmful than the minimum  
necessary to implement NAT66. For instance, some people have been  
speaking out for using global unicast or (none-unique) site local  
address space on the inside of a NAT66.

And in practice, people who don't know any better, or don't care, will  
implement even more harmful NAT66s regardless of any IETF consensus.  
For instance, the PF firewall already included a port overloading NAT  
for IPv6 years ago.

So the way I see it, the IETF publishing a NAT66 specification won't  
do much to discourage more harmful NATs, while it will encourage the  
use of the less harmful variant that is specified, but which still  
breaks referrals and end-to-end transparency. As such, doing this work  
will cause more harm than good.

However, I believe there is something useful that the IETF can do, and  
that is mostly what the BEHAVE wg has already been doing: document NAT  
behavior, and create specifications for applications that want to work  
through those NATs.  But with IPv6 we have the opportunity to be  
proactive: rather than describe the harm that existing NATs do, BEHAVE  
could publish a document that describes the various ways IPv6 NATs  
could be implemented, and then order these in order of increasing  
harm, outlining the harmful effects each type of NAT66s would have.  
Along with some easy to understand terminology or numeric ranking,  
this would allow application vendors to communicate what types of NAT  
their products will work with and which they won't, and allow end-
users to specify to their middlebox vendors what kind of NAT they want  
to buy.

So I suggest that when the moment comes that BEHAVE is in the position  
to take on new work, a new charter include this as an item.
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave