I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the translation algorithm between ipv6 and ipv4. The security considerations section say: The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator. There are potential issues that might arise by deriving an IPv4 address from an IPv6 address - particularly addresses like broadcast or loopback addresses and the non IPv4-translatable IPv6 addresses, etc. The [I-D.ietf-behave-address-format] addresses these issues. This text is fine but the next paragraph describing the AH is bit misleading: As the Authentication Header [RFC4302] is specified to include the IPv4 Identification field and the translating function is not able to always preserve the Identification field, it is not possible for an IPv6 endpoint to verify the AH on received packets that have been translated from IPv4 packets. Thus AH does not work through a translator. The Authentication Header includes also the addresses etc in the ICV thus it is not only the IPv4 Identification field that causes problems also the changing the IPv4 address to IPv6 addresses and vice versa, changing the IP version field, payload length etc makes AH incompatible with this translation. If the text was supposed to say that some implementation which knows both AH and this translation could be made to know that this packet has gone through this translation and could then check the ICV by reversing the translation before checking the ICV, then this text should more clearly say that. I.e instead of saying that endpoing cannot verify AH and that AH does not work (standard AH as defined in RFC4302 will always fail the verification), it should be said that it is not possible to make specification which specifies how AH should be modified to understand this translation and even then it would be impossible to completely reverse translation as some information (like parts of the Identification field) is not available. I also think that in addition to the Identification field the translation is loosing information about the IP extensions. The last paragraph of security considerations section talks about ESP: Packets with ESP can be translated since ESP does not depend on header fields prior to the ESP header. Note that ESP transport mode is easier to handle than ESP tunnel mode; in order to use ESP tunnel mode, the IPv6 node MUST be able to generate an inner IPv4 header when transmitting packets and remove such an IPv4 header when receiving packets. Even with ESP there is complications, as in transport mode the transport layer protocols inside the ESP do contain checksums which cannot be modified by the translator, thus they will keep the original IP addresses in there, and if the translation is not checksum neutral then end node will throw away the packet after ESP processing as the transport layer checksums are incorrect. For tunnel mode the transport layer protocol checksums contains the inner IP header thus they are ok. Actually for ESP the situation is even more different, as the IPsec will detect this kind of translation as NAT along the path, and will enable NAT-Traversal, meaning ESP packets will get UDP encapsulated, and the IPsec itself will do the checksum fixup as specified in the RFC3847. On the other hand I do not know how many existing implementations know how to handle checksum fixup when changing from IPv4 address to IPv6 address or other way around, altough some of them do full checksum recalculation (or simply skip the transport layer checksum checking) anyways so they might work. -- kivinen at iki.fi