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 defines a new PCP (Port Control Protocol) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses (known as "Pref64::/n"). The Security Considerations for this draft are a good start but they are missing some key information. 1) The second paragraph of the Security Considerations section points out that if an attacker can fool a host into using the wrong value for Pref64::/n, the traffic generated using that value will be delivered to the wrong location. That's right but not all the implications are mentioned. A MITM (Man In The Middle) attack can be performed in this manner, permitting alterations to the traffic (not just eavesdropping). This should be mentioned. 2) The next paragraph of the Security Considerations section suggests defenses to prevent the attacker from substituting the wrong value for Pref64::/n. However, the defense that is suggested (IP-based ACLs on the PCP server, client, or network) won't help much. Attackers can just place the PCP server's IP address in the source address of the fake PCP response packet sent by the attack. The nonce in the MAP or PEER response means that the attacker must capture or predict this value but no nonce is present in the ANNOUNCE response so that would probably be the preferred attack method, especially since ANNOUNCE responses can be sent out via multicast at any time. I suggest that the spec prohibit sending the PREFIX64 option in a multicast ANNOUNCE response, unless effective countermeasures for this attack are found. In addition to these security issues, I found some other issues that are not related to security: 1) You should explain that RFC 6146 defines Pref64::/n. Otherwise, that term is quite cryptic. 2) Several places in the document, you say that PREFIX64 is a PCP "extension". The PCP spec doesn't define what a PCP extension is. Say "PCP option" instead. 3) In section 3.2.1, say "synthesize" not "synthesizes". 4) In section 4.1 and several other places, the field Pref64 is also called Prefix64. Come up with one name for the field and stick with it. 5) Split section 4.2 into Client Behavior and Server Behavior. The current text is too confusing. For example, the text at the bottom of page 7 is a confusing mishmash of server and client handling of multiple PREFIX64 options. 6) Text near the top of page 8 says "The PCP server can be configured with a customized IPv6 prefix list" but that won't work when PREFIX64 is added to a multicast ANNOUNCE response. That's another reason not to permit this, in addition to security issue 2) above. 7) When IPv4 prefix lists are configured and multiple IPv6 prefix lists are also configured, the first PREFIX64 option includes the IPv4 prefix lists. Can the later PREFIX64 options also include their own IPv4 prefix lists? If one or more of those later PREFIX64 options does NOT have its own IPv4 prefix list, what does that mean? Does it inherit the IPv4 prefix list of the previous PREFIX64 option? The current text is not clear. 8) The example in section 5.1 says that it "depicts a typical usage of the PREFIX64 option when a DNS64 capability is embedded in the host." Did you mean "is not embedded"? I don't see how DNS64 is being used in this example. 9) Is this document still relevant? RFC 7051 says: Our conclusion is to recommend publishing the Well-Known DNS Name heuristic discovery-based method as a Standards Track IETF document for applications and host implementors to implement as-is. With that, is there still a need for this document? I hope that you find these comments useful. Thanks, Steve