Earlier, Margaret Wasserman wrote: % If we do need to address prefixes of longer than /48 in NAT66, % that is fairly easy to do. We just need to pick which sacrifices % we are willing to make. I can think of two choices: % % (1) Add the checksum correction to a 2byte portion of the % lower 64 bits when the prefix is longer than /48, thus modifying % the IID. % % This wouldn't be compatible with (currently unspecified) mechanisms % that require a constant IID, but we would already have that problem % with nodes that generate privacy addresses.
It is not correct that all proposed mechanisms that would use the low-order 64 bits are incompatible with the IPv6 "Privacy Address" extensions. Some of those proposals in fact are *completely* compatible with the "Privacy Address" mechanisms. In fact, modifying the low-order 64-bits (IPv6 Interface ID) will break proposed mechanisms that work fine with IPv6 Privacy IDs. Separately, other things (e.g. deployed IPv6 audit approaches) will break if the low-order 64 bits of a packet get modified by a NAT66 device. So modifying the low-order 64-bits is not a desirable technical approach to the issue of handling NAT66 functions when relatively longer IPv6 routing prefixes have been deployed. % or % % (2) Fix the UDP or TCP checksum instead of performing the % checksum correction algorithm when the prefix is longer than /48. (NOTA BENE: Margaret has not raised checksum recalculation performance as an issue, but other folks have done so. It is on topic for this note, so I'll discuss it here. :-) Widely deployed very-lost-cost residential/small-office gateways that perform NAT re-calculate the UDP/TCP checksums today without any user-visible performance issues. In fact, recalculating the Fletcher checksum (used by UDP/TCP) is very easy to do purely in software on an ordinary very-low-cost CPU. So there are existence proofs that performance would be a non-issue for the kinds of sites that are likely to be given relatively longer IPv6 routing prefixes. % The cost here is that we lose the ability to encrypt/protect % the transport layer headers. In NAT66, we could explicitly % make this correction for UDP/TCP only, passing through other % transport layers unmodified, which might help to reduce the % impact on new innovations at the transportlayer. Note that SSL/TLS does not protect TCP headers. So the above concern is limited narrowly to ESP or AH.[1] IETF standards-track RFC-3948 specifies UDP Encapsulation to enable ESP/AH traversal of existing IPv4 NAT devices. That mechanism is very widely implemented, and is also very widely deployed today. It really works quite well. RFC-3948 works fine with a NAT66 device; no code changes to an RFC-3948 implementation ought to be required. So there this issue has already been solved, existing solutions can be reused, and there is not a new issue arising from NAT66. So for the sites being given longer IPv6 routing prefixes, the specification ought to require that the NAT66 device recalculate the TCP/UDP checksums, and ought to prohibit a NAT66 device from ever modifying the low-order 64-bits. Last, I think this WG ought to explicitly document that one ought never be allocated an IPv6 Routing Prefix longer than 64 bits, and that any IPv6 NAT function that gets specified also ought not support NAT/NAPT/SAT for prefixes longer than 64-bit Yours, Ran [email protected] [1] Separately, IPv6 AH ought to be specified to only include the IPv6 Interface ID bits, not the IPv6 Routing Prefix bits, regardless of NAT66. However, the topic of IPv6 AH belongs to a different mailing list and a different working group. _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
