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 discusses formats and algorithms around dealing with the translation of IPv4 addresses to IPv6 addresses and vice versa. Such translation is necessary when two endpoints and the network between them do not all support a single version of IP.

I found the document quite comprehensible, its decisions well considered, and I have only minor comments.

Security Related:

Section 5 discusses two threats related to routers that handle IPv6 addresses that embed IPv4 addresses. I believe an important third attack in the same category is where firewalls filter traffic based on IPv4 addresses. In all such scenarios, admins should assure that packets that embed those IPv4 addresses inside IPv6 addresses perform the same filtering on the IPv6 addresses. Otherwise, lots of traffic that was previously blocked might be able to pass through the firewalls disguised as IPv6 packets.

Section 3.1 says that the Well-Known Prefix MUST NOT be used to represent non global IPv4 addresses, such as those defined in [RFC1918]. First, especially given that this is a MUST, there should be an explicit list of forbidden IPv4 addresses rather than a vague reference to RFC1918. Second, the text should probably explicitly say that any translator that extracts an IPv4 address from an IPv6 address MUST check the IPv4 address against the forbidden list and drop the packet if it has such a forbidden address. Otherwise, the text could be interpreted as only forbidding encapsulation. In most attacks, the attacker does the encapsulation and the good guy does the decapsulation, so forbidding encapsulation doesn't help.

The last sentence of section 2.2 says "These bits are reserved for future extensions and SHOULD be set to zero." In any spec where it says that some bits SHOULD or MUST be set to zero, there should be corresponding text saying what an implementation SHOULD or MUST do if it receives data containing non-zero values. In this case, I couldn't tell whether the intended action was to ignore the non-zero bits or to drop the packet. The bits will be much more useful for future uses if we have confidence about how existing implementations handle them.

Typos:

P5 middle: "prefic" -> "prefix"
P9 middle: "return them message in" -> "return them in"