On 8 Apr 2009, at 15:06, Fred Baker wrote:
[NAT66] by virtue of doing the TCP/UDP checksum update in the IPv6 address, enables IPsec ESP sessions (AH won't work, and apart from that encrypted sessions don't work with ESP, and even unencrypted sessions are a PITA due to the antics required to find the TCP header).
There is a widely deployed mechanism for IPv4 NAT traversal (i.e. RFC-3948 -- UDP encapsulation of IPsec). This is available in nearly all hosts, and no special firewall/NAT/transit-router support is needed to use it. That same mechanism works fine for a very wide range of IPv6 NAT mechanisms, including but not limited to NAT66. We should use that (short-term) for all IPv6 NAT traversal with IPsec as it is available and works, and it does not depend upon some particular feature of a particular IPv6 NAT approach. It isn't worth the time or energy to try to do something more complex with any of the IPv6 NAT solutions, because the end systems can't ordinarily know whether an IPv6 NAT is present nor which IPv6 NAT approach might have been deployed in a particular location. In the longer term, the IETF community should revise the "IPsec for IPv6" specifications so that the IPv6 routing prefix (specifically the high-order 64 bits) is included neither in the IPv6 IPsec Security Associations, nor in the AH calculations, nor in IKE or the IKE DOI for IPv6 IPsec. [It has been broadly unfortunate that the IESG insisted on moving the AH/ESP work out of IPng WG and into IPsec WG in the middle-1990s; lots of unfortunate consequences came from that decision, including these items that ought to be fixed.] Cheers, Ran _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
