[arin-ppml] The role of NAT in IPv6

[Lee Dilkie]

Owen DeLong wrote:
> Actually, the places that most need to deploy IPv6 at this point being eye-ball ISPs and the public-facing portions of content and services providers, I don't think that NAT has been an actual barrier to adoption in either of those spaces. The vast majority of people calling for NAT66 are the enterprise interior, which is, IMHO, the least critical and least likely group to get on the IPv6 bandwagon quickly regardless of what is done to appease them.
>   

This is a critical observation. The very same folks who will, for
various reasons besides NAT even, be slow to adopt IPv6 are also
relatively small users of IPv4 and aren't really our target for early
adopters. We're trying to get the big ticket users, consumers, to move
over and for that there is no need to discuss NAT.

> If NAT lives only at a few enterprise borders, that's fine. Having generalized support for NAT in the protocol specs, OTOH, would encourage a much wider deployment of it and worse, cruft in software to support NAT traversal all over again.  If we can just avoid ISVs producing stuffing NAT traversal code into their software, it's a win for the industry in general, and, the damage by NAT become a consequence to your network instead of the rest of the world. I can live with that.
>
>   
I don't think anyone expects enterprises to throw open their borders and
allow unrestricted access to internal hosts. Border control gateways
will exist and can exist without address translation. It can also exist
with address translation for selected protocols, if that makes one feel
better. However, it's generally impossible to create a "generalized
support for NAT in the protocol specs". These things will always end up
being specific application-layer gateways that exist as
man-in-the-middle solutions. Enterprises can pay for that. For the
consumer and small business endpoints, avoiding NAT will go a long way
to helping avoid the costs it inflicts on others.

-lee