The IESG has approved the following document: - 'Analysis of solution proposals for hosts to learn NAT64 prefix' (draft-ietf-behave-nat64-learn-analysis-03.txt) as Informational RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-learn-analysis/ Technical Summary Hosts and applications may benefit from the knowledge of whether an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses a number of proposed solutions for communicating whether the synthesis is taking place, the address format used, and the IPv6 prefix used by the NAT64 and DNS64. The solutions enable both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis. The document concludes by recommending standardization of a heuristic discovery solution. Working Group Summary Concern was raised that we should define a new DNS resource record to retrieve this information, rather than concluding we should do a heuristic. The document explains why the working group reached the consensus to recommend a heuristic approach. Document Quality Authors would like to thank Dan Wing and Christian Huitema especially for the STUN idea and for their valuable comments and discussions. Personnel Document Shepherd: Dan Wing, dwing@cisco.com Responsible Area Director: David Harrington (ietfdbh@comcast.net) RFC Editor Note (1) Please re-include the Informative References that were part of version -02 of the document (section 10.2) but removed in version -03 (section 11.2): http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-nat64-learn-analysis-03.txt (2) In paragraph 5 of section 1, please change: "analyzes all known solutions proposals known" to: "analyzes all proposed solutions known" (3) In section 4, please change: "the Framework document" to: "the IPv4/IPv6 translation framework document" (4) In the Security Considerations, following the reference to RFC 6147, please add: "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." (5) In the Security Considerations, please change: "unless DHCPv6 authentication or SEND are used)."" to: "unless DHCPv6 authentication (described in [RFC3315] or SEND [RFC3971] are used)." and add an Informative Reference to RFC 3315 and RFC 3971. (6) In the Security Considerations, please change: "authenticate all DNS responses" to: "authenticate all DNS responses (e.g. via DNSSEC [RFC4033]" and add an Informative Reference to RFC 4033. (7) In the Section 5.2.2 and 5.3.2 "cons" lists, please add: "- EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0 capable DNS64 is the first DNS server the end host talks to, as it is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between." (8) Please change the Abstract to: Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyses a number of proposed solutions for detection of IPv6 address synthesis, IPv6 address format, and IPv6 prefix used for the protocol translation. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the heuristic discovery based approach. (9) Please remove the 3rd paragraph of Section 5.1.1
