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 a method of mapping IPv4 unicast packets across an IPv6 network, providing both address and port mapping of the IPv4 packets within the IPv6 network. In other words, a user's packet begins as an IPv4 packet, is translated into a public IPV4 address by a NAPT44, is mapped to an IPv6 address (the "MAP domain") and delivered across the IPv6 network to a border relay. The border relay converts the packet back to an IPv4 packet with the NAPT44 source address and relays it to an IPv4 public network. The border relay uses the same mapping function to turn return packets back into IPv6 packets with the correct IPv6 destination address for delivery back to the original user.

The Security Considerations section lists several attacks. The text seems reasonable. It would be helpful if there was a reference to "Address-Dependent Filtering", which might be RFC 4787.

The main risk to the mapping method seems to be a threat of overlapping address mappings, such that return packets are delivered to the wrong user. This would be a security consideration if users received other users traffic. The algorithm seems designed to avoid this, at least Appendix B indicates this as a requirement. If this is in fact believed to guarantee non-overlapping mappings then this should be stated in this section. The only statement I can find is in Section 5.1, where it is stated that "Different PSIDs guarantee non-overlapping port-sets." But if I'm not mistaken, the PSIDs are also computed so this might not actually be a guarantee. If there was a proof of correctness ensuring that a correct implementation will ensure non-overlapping mappings then this should be mentioned as well. 

The mapping algorithm is a bit complicated, and I do worry about implementation errors that might be hard to detect. If there was any advice you could give to implementors, it would be helpful.

Brian