Re: 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.

<snip>
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.