I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-behave-64-analysis-06 Reviewer: David L. Black Review Date: February 28, 2012 IETF LC End Date: February 20, 2012 IESG Telechat Date: March 1, 2012 Summary: This draft is on the right track but has open issues, described in the review. Comments: This draft summarizes the improvements of stateful 64 techniques over the now-historic NAT-PT techniques for communication between IPv4 and IPv6 networks. The draft does a nice job of summarizing the current situation in a fashion that avoids the reader having to go through the plethora of details in the cited references. The draft is clearly written and reads well. There is one open issue that's almost a nit - unfortunately, the IPsec discussion in item 6 of Section 3.2 is wrong, even though it was copied from RFC 4966 (FWIW, it's wrong there, also): 6. Unless UDP encapsulation is used for IPsec [RFC3948], traffic using IPsec AH (Authentication Header), in transport and tunnel mode, and IPsec ESP (Encapsulating Security Payload), in transport mode, is unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection (Section 4.5 of [RFC4966]). There are four problems with that explanation: (1) AH cannot be UDP-encapsulated. RFC 3948 says: Because the protection of the outer IP addresses in IPsec AH is inherently incompatible with NAT, the IPsec AH was left out of the scope of this protocol specification. (2) The reasons for use of UDP encapsulation with ESP do not include ESP's "usage of cryptographic integrity protection." because ESP's cryptographic integrity protection does not include any IP header fields. The actual reasons are considerably more subtle and involved (e.g., traffic selector issues and NAT implementations that did not work correctly with IKE), see RFC 3715. (3) Nit: The correct RFC 4966 reference is Section 2.1, not 4.5. (4) A number of additional references are needed, starting with RFC 3715. Here's an attempt to propose a text change: OLD 6. Unless UDP encapsulation is used for IPsec [RFC3948], traffic using IPsec AH (Authentication Header), in transport and tunnel mode, and IPsec ESP (Encapsulating Security Payload), in transport mode, is unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection (Section 4.5 of [RFC4966]). NEW 6. IPsec traffic using AH (Authentication Header) [RFC4302] in both transport and tunnel modes cannot be carried through NAT-PT without terminating the security associations on the NAT-PT, due to the inclusion of IP header fields in the scope of AH's cryptographic integrity protection [RFC3715] (Section 2.1 of [RFC4966]). In addition, IPsec traffic using ESP (Encapsulating Security Payload) [RFC4303] in transport mode generally uses UDP encapsulation [RFC3948] for NAT traversal (including NAT-PT traversal) in order to avoid the problems described in [RFC3715] (Section 2.1 of [RFC 4966]). END The Security Area should review the above proposed text change. idnits 2.12.13 noted that RFC 2766 was obsoleted by RFC 4966 - this is fine, as RFC 2766 does need to be cited. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------