We have been ignoring the fact that NAT could have some interest in IPv6 during the latest 5 years. IPv6 will not fix everything and it may be time to reconsider NAT. There is some reasons for that:
- Dynamic IPv6 prefixes: some ISP decide to not give fixed address to people
- Server load balancing, DMZ
- Uplink Balancing (multi-homing): this is one of the most important reason. IPv6 client can handle multiple addresses but you may want not having your user to choose their internet output.
IPv6 NAT is available in OpenBSD for some years now. It is also available on FreeBSD when using pf. Cisco IOS has not IPv6 NAT support.
Linux status is quite complicated. There is at least three implementations and there is even a official one that come from Linux virtual server.
NAT66 – RFC 6286 is now available. There is no port translation and the mapping must be checksum-neutral (if you change the prefix, it must not change the checksum).
Ulrich proposes some choices for integration into Netfilter:
- No IPv6 NAT
- NAT66 ip6tables target (with or without conntrack dependency)
- Make nf_nat protocol independant and move to net/netfilter (let admin decide if they want 1:1 or n:1)
- Any other solutions?
Main discussion is about the impact of the change introduced by IPv6 NAT. Nobody seemed against the introduction of the feature and this was finally accepted to add IPv6 NAT inside Netfilter. The remaining point is who will do the job.
Typo in the RFC the right one seems to be rfc6296.
http://tools.ietf.org/html/rfc6296