Until recently, NAT44 was not well documented and as a result implementations vary regarding features and extensions. This further makes it difficult to build applications that work over NAT44.
IPv6 was designed to eliminate the need for NAT to solve the address scarcity and expense issues by creating a much larger block of available addresses (i.e., 2^^128 vs. 2^^32). IPv6 has not, by itself, provided solutions for address independence and implicit security properties of NAT44. One approach for using IPv6 without NATs is described in RFC4864 Local Network Protection for IPv6
However, the use of NATv4 has become so universal that there is a sizable number of people who require there to be a NAT for IPv6 (NAT66) as well. NAT is the way many people deploy networks today. The lack of a NAT66 solution may become a hindrance to IPv6 deployment and there is good reason to think that NAT66 will be implemented in IPv6 without a stable specification as happened with NAT44.
The technical advantage NAT66 brings to IPv6 is in the area of address independence. This has the potential to provide a site with stable IPv6 addresses independent of it's ISP and simpler form of multi-homing than can be achieved with the current IPv6 multi-prefix approach. The trade-off that the BOF needs to discuss is if the advantages of address independence outweigh the problems introduced by NAT.
The main goal of the BOF is to determine if there is a community consensus to start a working group to specify a NAT66 specification. If a working group is formed, it would discuss the appropriate status of the specification (i.e., standards track, informational, etc.). The focus of the work is to be on IPv6 address independence. As a side-effect, depending on how address independence is provided, it may also provide additional address hiding.
This BOF will use IPv6-to-IPv6 Network Address Translation (NAT66) draft-mrw-behave-nat66-02.txt as the basis discussion of address independence for IPv6 solution. Other IPv6 address independence solutions will be considered if a working group is formed, but for the purpose of determining consensus to form a working group, only this solution will be in scope.
NAT66 (as defined in draft-mrw-behave-nat66-02.txt ) differs from the the most common NAT44 solutions as NAT66 provides an algorithmic 1:1 mapping between the inside and outside IPv6 addresses. NAT66 is not a port mapping style of NAT. The differences between NAT66 and NAT44 are hoped to provide the
An important part of reaching a consensus is to understand how and if a NAT66 solution can eliminate or reduce the known problems with NAT44. The BOF will generate a list of NAT44 problems and show which of these can be solved with NAT66 and which can not be solved. The intent of this approach is to get beyond the repeating IETF NAT is evil level of discussion and move the discussion to what we understand about the features and problems of NAT (i.e. a discussion of a set of facts).
While a NAT66 solution may possibly provide a framework that could facilitate a solution to the global Internet route scaling problem, that topic is out of scope for this BOF. Note that address independence by itself provides some benefits related to route scaling, such as ability of smaller sites to acquire stable address space independent from their ISPs. It may also be possible to employ NAT66 to multi-homed sites, without requiring the site to obtain provider independent IPv6 addresses and advertise these addresses to it's ISPs with BGP.
Others forms of NAT relating to IPv6 to IPv4 translation (NAT64) are out of scope for this BOF.