Hi, 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. The document reviews possible solutions for the problem of allowing hosts and applications to learn if an IPv6 address is synthesized, which means a NAT64 is used to reach the IPv4 network or Internet. The document analyzes pros and cons of various approaches and also concludes with some recommendations about which approach is recommended. Overall I think the Security Considerations section is reasonable (see some minor comments below). I think it is reasonable for the document to point to RFC 6147 for DSN64 related Security Considerations. The document also talks about Man-in-the-middle and Denial-of-Service attacks caused by forging of information required for IPv6 synthesis from corresponding IPv4 addresses. Additionally, the document says: The DHCPv6 and RA based approaches are vulnerable for the forgery as the attacker may send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 authentication or SEND are used). I think some Informative references to relevant documents should be inserted here in order to help readers find relevant information. If the attacker is already able to modify and forge DNS responses (flags, addresses of know IPv4-only servers, records, etc), ability to influence local address synthesis is likely of low additional value. Also, a DNS-based mechanism is only as secure as the method used to configure the DNS server's IP addresses on the host. Therefore, if the host cannot trust e.g. DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, unless the host has a way to authenticate all DNS responses. Maybe add an explicit DNSSEC reference here? One other possible issue that you should consider: 5.1.2. Analysis and discussion The CONs of the proposal are listed below: I don't know how much of an issue this is in a real world, but one thought: Can use of a well known IPv4-only FQDN be used for tracking applications/hosts which try to employ this algorithm? Such IPv4-only host might be an attractive target for compromise, if such information is valuable to an attacker. (This might also apply to other DNS methods.) Other comments (not really SecDir related): I found the Abstract to be quite hard to read. Maybe reword to use shorter/simpler sentences? 5.1.1. Solution description The Well-Known Name may be assigned by IANA or provided some third party, including application or operating system vendor. The IPv4 address corresponding to the Well-Known Name may be resolved via A query to Well-Known Name, assigned by IANA, or hard-coded. Is IANA already providing one of these? If not, why speculate about this, as there is no action for IANA specified in this document.