Hi Ran,
Thanks for your input! On Apr 3, 2009, at 10:14 AM, RJ Atkinson wrote:
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.
How do these mechanisms work with randomly generated privacy IIDs?
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.
That is why I included modifying the IID as a negative in that approach.
(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.
In IPv6, we have the added issue of _finding_ the TCP/UDP checksum. There may be extension headers in the way, and we would need to make sure that a NAT66 device can handle arbitrary extension headers. Otherwise, we are effectively eliminating our ability to add new IPv6 extension headers in the future.
% 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.
That's excellent. I wasn't aware of this RFC. Thanks for pointing it out.
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
Makes sense. We've said it elsewhere, but it wouldn't hurt to keep saying it. We could also point out the potential advantages to sites that have a /48 (and can do IP checksum correction in the subnet bits) in the hope that this will add one more straw to the side of folks (especially enterprises) demanding a /48 from their provider.
[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.
This would be a Good Thing (TM). Margaret _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
