doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc7050.txt b/doc/rfc/rfc7050.txt
new file mode 100644
index 0000000..3f25d47
--- /dev/null
+++ b/doc/rfc/rfc7050.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     T. Savolainen
+Request for Comments: 7050                                         Nokia
+Category: Standards Track                                    J. Korhonen
+ISSN: 2070-1721                                                 Broadcom
+                                                                 D. Wing
+                                                           Cisco Systems
+                                                           November 2013
+
+
+      Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
+
+Abstract
+
+   This document describes a method for detecting the presence of DNS64
+   and for learning the IPv6 prefix used for protocol translation on an
+   access network.  The method depends on the existence of a well-known
+   IPv4-only fully qualified domain name "ipv4only.arpa.".  The
+   information learned enables nodes to perform local IPv6 address
+   synthesis and to potentially avoid NAT64 on dual-stack and multi-
+   interface deployments.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7050.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                    [Page 1]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Notation and Terminology ...........................4
+      2.1. Requirements Notation ......................................4
+      2.2. Terminology ................................................4
+   3. Node Behavior ...................................................4
+      3.1. Validation of Discovered Pref64::/n ........................6
+           3.1.1. DNSSEC Requirements for the Network .................7
+           3.1.2. DNSSEC Requirements for the Node ....................7
+      3.2. Connectivity Check .........................................8
+           3.2.1. No Connectivity Checks against "ipv4only.arpa." .....9
+      3.3. Alternative Fully Qualified Domain Names ..................10
+      3.4. Message Flow Illustration .................................10
+   4. Operational Considerations for Hosting the IPv4-Only
+      Well-Known Name ................................................12
+   5. Operational Considerations for DNS64 Operator ..................12
+      5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes ...........13
+   6. Exit Strategy ..................................................14
+   7. Security Considerations ........................................14
+   8. IANA Considerations ............................................15
+      8.1. Domain Name Reservation Considerations ....................15
+      8.2. IPv4 Address Allocation Considerations ....................16
+      8.3. IAB Statement Regarding This .arpa Request ................17
+   9. Acknowledgements ...............................................18
+   10. References ....................................................18
+      10.1. Normative References .....................................18
+      10.2. Informative References ...................................19
+   Appendix A.  Example of DNS Record Configuration ..................20
+   Appendix B.  About the IPv4 Address for the Well-Known Name .......21
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                    [Page 2]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+1.  Introduction
+
+   As part of the transition to IPv6, NAT64 [RFC6146] and DNS64
+   [RFC6147] technologies will be utilized by some access networks to
+   provide IPv4 connectivity for IPv6-only nodes [RFC6144].  DNS64
+   utilizes IPv6 address synthesis to create local IPv6 addresses for
+   peers having only IPv4 addresses, hence allowing DNS-using IPv6-only
+   nodes to communicate with IPv4-only peers.
+
+   However, DNS64 cannot serve applications not using DNS, such as those
+   receiving IPv4 address literals as referrals.  Such applications
+   could nevertheless be able to work through NAT64, provided they are
+   able to create locally valid IPv6 addresses that would be translated
+   to the peers' IPv4 addresses.
+
+   Additionally, DNS64 is not able to do IPv6 address synthesis for
+   nodes running validating DNS resolvers enabled by DNS Security
+   (DNSSEC), but instead, the synthesis must be done by the nodes
+   themselves.  In order to perform IPv6 synthesis, nodes have to learn
+   the IPv6 prefix(es) used on the access network for protocol
+   translation.  A prefix, which may be a Network-Specific Prefix (NSP)
+   or a Well-Known Prefix (WKP) [RFC6052], is referred to in this
+   document as Pref64::/n [RFC6146].
+
+   This document describes a best-effort method for applications and
+   nodes to learn the information required to perform local IPv6 address
+   synthesis.  The IPv6 address synthesis procedure itself is out of the
+   scope of this document.  An example application is a browser
+   encountering IPv4 address literals in an IPv6-only access network.
+   Another example is a node running a validating security-aware DNS
+   resolver in an IPv6-only access network.
+
+   The knowledge of IPv6 address synthesis taking place may also be
+   useful if DNS64 and NAT64 are used in dual-stack-enabled access
+   networks or if a node is multi-interfaced [RFC6418].  In such cases,
+   nodes may choose to prefer IPv4 or an alternative network interface
+   in order to avoid traversal through protocol translators.
+
+   It is important to note that use of this approach will not result in
+   a system that is as robust, secure, and well-behaved as an all-IPv6
+   system would be.  Hence, it is highly recommended to upgrade nodes'
+   destinations to IPv6 and utilize the described method only as a
+   transition solution.
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                    [Page 3]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+2.  Requirements Notation and Terminology
+
+2.1.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.2.  Terminology
+
+   NAT64 FQDN: a fully qualified domain name (FQDN) for a NAT64 protocol
+   translator.
+
+   Pref64::/n: an IPv6 prefix used for IPv6 address synthesis [RFC6146].
+
+   Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any
+   of the locations allowed by RFC 6052 [RFC6052].
+
+   Secure Channel: a communication channel a node has between itself and
+   a DNS64 server protecting DNS protocol-related messages from
+   interception and tampering.  The channel can be, for example, an
+   IPsec-based virtual private network (VPN) tunnel or a link layer
+   utilizing data encryption technologies.
+
+   Well-Known IPv4-only Name (WKN): the fully qualified domain name,
+   "ipv4only.arpa.", well-known to have only A record(s).
+
+   Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and
+   present in an A record for the well-known name.  Two well-known IPv4
+   addresses are defined for Pref64::/n discovery purposes: 192.0.0.170
+   and 192.0.0.171.
+
+3.  Node Behavior
+
+   A node requiring information about the presence (or absence) of
+   NAT64, and one or more Pref64::/n used for protocol translation SHALL
+   send a DNS query for AAAA resource records of the Well-Known
+   IPv4-only Name (WKN) "ipv4only.arpa.".  The node MAY perform the DNS
+   query in both IPv6-only and dual-stack access networks.
+
+   When sending a DNS AAAA resource record query for the WKN, a node
+   MUST set the "Checking Disabled (CD)" bit to zero [RFC4035], as
+   otherwise the DNS64 server will not perform IPv6 address synthesis
+   (Section 3 of [RFC6147]) and hence would not reveal the Pref64::/n
+   used for protocol translation.
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                    [Page 4]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   A DNS reply with one or more AAAA resource records indicates that the
+   access network is utilizing IPv6 address synthesis.  In some
+   scenarios, captive portals, or NXDOMAIN and NODATA hijacking,
+   performed by the access network may result in a false positive.  One
+   method to detect such hijacking is to query a fully qualified domain
+   name that is known to be invalid (and normally returns an empty
+   response or an error response) and see if it returns a valid resource
+   record.  However, as long as the hijacked domain does not result in
+   AAAA resource record responses that contain a well-known IPv4 address
+   in any location defined by [RFC6052], the response will not disturb
+   the Pref64::/n learning procedure.
+
+   A node MUST look through all of the received AAAA resource records to
+   collect one or more Pref64::/n.  The Pref64::/n list might include
+   the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network-
+   Specific Prefixes.  In the case of NSPs, the node SHALL determine the
+   used address format by searching the received IPv6 addresses for the
+   WKN's well-known IPv4 addresses.  The node SHALL assume the well-
+   known IPv4 addresses might be found at the locations specified by
+   [RFC6052], Section 2.2.  The node MUST check on octet boundaries to
+   ensure a 32-bit well-known IPv4 address value is present only once in
+   an IPv6 address.  In case another instance of the value is found
+   inside the IPv6 address, the node SHALL repeat the search with the
+   other well-known IPv4 address.
+
+   If only one Pref64::/n was present in the DNS response, a node SHALL
+   use that Pref64::/n for both local synthesis and for detecting
+   synthesis done by the DNS64 server on the network.
+
+   If more than one Pref64::/n was present in the DNS response, a node
+   SHOULD use all of them when determining whether other received IPv6
+   addresses are synthetic.  The node MUST use all learned Pref64::/n
+   when performing local IPv6 address synthesis and use the prefixes in
+   the order received from the DNS64 server.  That is, when the node is
+   providing a list of locally synthesized IPv6 addresses to upper
+   layers, IPv6 addresses MUST be synthesized by using all discovered
+   Pref64::/n prefixes in the received order.
+
+   If the well-known IPv4 addresses are not found within the standard
+   locations, the DNS response indicates that the network is not using a
+   standard address format or unexpected IPv4 addresses were used in the
+   AAAA resource record synthesis.  In either case, the Pref64::/n
+   cannot be determined and the heuristic procedure has failed.
+   Developers can, over time, learn of IPv6-translated address formats
+   that are extensions or alternatives to the standard formats.  At that
+   point, developers MAY add additional steps to the described discovery
+   procedure.  The additional steps are outside the scope of the present
+   document.
+
+
+
+Savolainen, et al.           Standards Track                    [Page 5]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   In case a node does not receive a positive DNS reply to the AAAA
+   resource record query, the node MAY perform a DNS A resource record
+   query for the well-known name.  Receiving a positive reply to the DNS
+   A resource record query indicates that the recursive DNS server that
+   is used is not a DNS64 server.
+
+   In the case of a negative response (NXDOMAIN, NODATA) or a DNS query
+   timeout, a DNS64 server is not available on the access network, the
+   access network filtered out the well-known query, or something went
+   wrong in the DNS resolution.  All unsuccessful cases result in a node
+   being unable to perform local IPv6 address synthesis.  In the case of
+   timeout, the node SHOULD retransmit the DNS query like any other DNS
+   query the node makes [RFC1035].  In the case of a negative response
+   (NXDOMAIN, NODATA), the node MUST obey the Time to Live (TTL)
+   [RFC1035] of the response before resending the AAAA resource record
+   query.  The node MAY monitor for DNS replies with IPv6 addresses
+   constructed from the WKP, in which case if any are observed, the node
+   SHOULD use the WKP as if it were learned during the query for the
+   well-known name.
+
+   To save Internet resources if possible, a node should perform
+   Pref64::/n discovery only when needed (e.g., when local synthesis is
+   required, when a new network interface is connected to a new network,
+   and so forth).  The node SHALL cache the replies it receives during
+   the Pref64::/n discovery procedure, and it SHOULD repeat the
+   discovery process ten seconds before the TTL of the Well-Known Name's
+   synthetic AAAA resource record expires.
+
+3.1.  Validation of Discovered Pref64::/n
+
+   If a node is using an insecure channel between itself and a DNS64
+   server or the DNS64 server is untrusted, it is possible for an
+   attacker to influence the node's Pref64::/n discovery procedures.
+   This may result in denial-of-service, redirection, man-in-the-middle,
+   or other attacks.
+
+   To mitigate against attacks, the node SHOULD communicate with a
+   trusted DNS64 server over a secure channel or use DNSSEC.  NAT64
+   operators SHOULD provide facilities for validating discovery of
+   Pref64::/n via a secure channel and/or DNSSEC protection.
+
+   It is important to understand that DNSSEC only validates that the
+   discovered Pref64::/n is the one that belongs to a domain used by
+   NAT64 FQDN.  Importantly, the DNSSEC validation does not tell if the
+   node is at the network where the Pref64::/n is intended to be used.
+   Furthermore, DNSSEC validation cannot be utilized in the case of a
+   WKP.
+
+
+
+
+Savolainen, et al.           Standards Track                    [Page 6]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+3.1.1.  DNSSEC Requirements for the Network
+
+   If the operator has chosen to support nodes performing validation of
+   discovered Pref64::/n with DNSSEC, the operator of the NAT64 device
+   MUST perform the following configurations.
+
+   1.  Have one or more fully qualified domain names for the NAT64
+       translator entities (later referred to as NAT64 FQDN).  In the
+       case of more than one Pref64::/n being used in a network, e.g.,
+       for load-balancing purposes, it is for network administrators to
+       decide whether a single NAT64's fully qualified domain name maps
+       to more than one Pref64::/n, or whether there will be a dedicated
+       NAT64 FQDN per Pref64::/n.
+
+   2.  Each NAT64 FQDN MUST have one or more DNS AAAA resource records
+       containing Pref64::WKA (Pref64::/n combined with WKA).
+
+   3.  Each Pref64::WKA MUST have a PTR resource record that points to
+       the corresponding NAT64 FQDN.
+
+   4.  Sign the NAT64 FQDNs' AAAA and A resource records with DNSSEC.
+
+3.1.2.  DNSSEC Requirements for the Node
+
+   A node SHOULD prefer a secure channel to talk to a DNS64 server
+   whenever possible.  In addition, a node that implements a DNSSEC
+   validating resolver MAY use the following procedure to validate
+   discovery of the Pref64::/n.
+
+   1.  Heuristically find Pref64::/n candidates by making a AAAA
+       resource record query for "ipv4only.arpa." by following the
+       procedure in Section 3.  This will result in IPv6 addresses
+       consisting of Pref64::/n combined with WKA, i.e., Pref64::WKA.
+       For each Pref64::/n that the node wishes to validate, the node
+       performs the following steps.
+
+   2.  Send a DNS PTR resource record query for the IPv6 address of the
+       translator (for ".ip6.arpa." tree), using the Pref64::WKA learned
+       in step 1.  CNAME and DNAME results should be followed according
+       to the rules in RFC 1034 [RFC1034], RFC 1035 [RFC1035], and RFC
+       6672 [RFC6672].  The ultimate response will include one or more
+       NAT64 FQDNs.
+
+   3.  The node SHOULD compare the domains of learned NAT64 FQDNs to a
+       list of the node's trusted domains and choose a NAT64 FQDN that
+       matches.  The means for a node to learn the trusted domains is
+
+
+
+
+
+Savolainen, et al.           Standards Track                    [Page 7]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+       implementation specific.  If the node has no trust for the
+       domain, the discovery procedure is not secure, and the remaining
+       steps described below MUST NOT be performed.
+
+   4.  Send a DNS AAAA resource record query for the NAT64 FQDN.
+
+   5.  Verify the DNS AAAA resource record contains Pref64::WKA
+       addresses received at step 1.  It is possible that the NAT64 FQDN
+       has multiple AAAA records, in which case the node MUST check if
+       any of the addresses match the ones obtained in step 1.  The node
+       MUST ignore other responses and not use them for local IPv6
+       address synthesis.
+
+   6.  Perform DNSSEC validation of the DNS AAAA response.
+
+   After the node has successfully performed the above five steps, the
+   node can consider Pref64::/n validated.
+
+3.2.  Connectivity Check
+
+   After learning a Pref64::/n, the node SHOULD perform a connectivity
+   check to ensure the learned Pref64::/n is functional.  It could be
+   non-functional for a variety of reasons -- the discovery failed to
+   work as expected, the IPv6 path to the NAT64 is down, the NAT64 is
+   down, or the IPv4 path beyond the NAT64 is down.
+
+   There are two main approaches to determine if the learned Pref64::/n
+   is functional.  The first approach is to perform a dedicated
+   connectivity check.  The second approach is to simply attempt to use
+   the learned Pref64::/n.  Each approach has some trade-offs (e.g.,
+   additional network traffic or possible user-noticeable delay), and
+   implementations should carefully weigh which approach is appropriate
+   for their application and the network.
+
+   The node SHOULD use an implementation-specific connectivity check
+   server and a protocol of the implementation's choice, but if that is
+   not possible, a node MAY do a PTR resource record query of the
+   Pref64::WKA to get a NAT64 FQDN.  The node then does an A resource
+   query of the NAT64 FQDN, which will return zero or more A resource
+   records pointing to connectivity check servers used by the network
+   operator.  A negative response to the PTR or A resource query means
+   there are no connectivity check servers available.  A network
+   operator that provides NAT64 services for a mix of nodes with and
+   without implementation-specific connectivity check servers SHOULD
+   assist nodes in their connectivity checks by mapping each NAT64 FQDN
+   to one or more DNS A resource records with IPv4 address(es) pointing
+   to connectivity check server(s).  The connectivity check approach
+   based on Pref64::/n works only with NSPs, as it is not possible to
+
+
+
+Savolainen, et al.           Standards Track                    [Page 8]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   register A records for each different domain using a WKP.  The
+   network operator MUST disable ICMPv6 rate limiting for connectivity
+   check messages.
+
+   If multiple connectivity check servers are available for use, the
+   node chooses the first one, preferring implementation-specific
+   servers.
+
+   The connectivity check protocol used with implementation-specific
+   connectivity check servers is implementation specific.
+
+   The connectivity check protocol used with connectivity check servers
+   pointed to by the NAT64 FQDN's A resource records is ICMPv6
+   [RFC4443].  The node performing a connectivity check against these
+   servers SHALL send an ICMPv6 Echo Request to an IPv6 address
+   synthesized by combining discovered Pref64::/n with an IPv4 address
+   of the server as specified in [RFC6052].  This will test the IPv6
+   path to the NAT64, the NAT64's operation, and the IPv4 path all the
+   way to the connectivity check server.  If no response is received for
+   the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo
+   Request a second later.  If still no response is received, the node
+   SHALL send a third ICMPv6 Echo Request two seconds later.  If an
+   ICMPv6 Echo Response is received, the node knows the IPv6 path to the
+   connectivity check server is functioning normally.  If no response is
+   received after three transmissions and after three seconds have
+   elapsed since the last ICMPv6 Echo Request, the node learns this
+   Pref64::/n might not be functioning, and the node MAY choose a
+   different Pref64::/n (if available), choose to alert the user, or
+   proceed anyway assuming the failure is temporary or is caused by the
+   connectivity check itself.  After all, ICMPv6 is unreliable by
+   design, and failure to receive ICMPv6 responses may not indicate
+   anything other than network failure to transport ICMPv6 messages.
+
+   If no separate connectivity check is performed before local IPv6
+   address synthesis, a node MAY monitor success of connection attempts
+   performed with locally synthesized IPv6 addresses.  Based on success
+   of these connections, and based on possible ICMPv6 error messages
+   received (such as Destination Unreachable messages), the node MAY
+   cease to perform local address synthesis and MAY restart the
+   Pref64::/n discovery procedures.
+
+3.2.1.  No Connectivity Checks against "ipv4only.arpa."
+
+   Clients MUST NOT send a connectivity check to an address returned by
+   the "ipv4only.arpa." query.  This is because, by design, no server
+   will be operated on the Internet at that address as such.  Similarly,
+   network operators MUST NOT operate a server on that address.  The
+   reason this address isn't used for connectivity checks is that
+
+
+
+Savolainen, et al.           Standards Track                    [Page 9]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   operators who neglect to operate a connectivity check server will
+   allow that traffic towards the Internet where it will be dropped and
+   cause a false negative connectivity check with the client (that is,
+   the NAT64 is working fine, but the connectivity check fails because a
+   server is not operating at "ipv4only.arpa." on the Internet and a
+   server is not operated by the NAT64 operator).  Instead, for the
+   connectivity check, an additional DNS resource record is looked up
+   and used for the connectivity check.  This ensures that packets don't
+   unnecessarily leak to the Internet and reduces the chance of a false
+   negative connectivity check.
+
+3.3.  Alternative Fully Qualified Domain Names
+
+   Some applications, operating systems, devices, or networks may find
+   it advantageous to operate their own DNS infrastructure to perform a
+   function similar to "ipv4only.arpa." but use a different resource
+   record.  The primary advantage is to ensure availability of the DNS
+   infrastructure and ensure the proper configuration of the DNS record
+   itself.  For example, a company named Example might have their
+   application query "ipv4only.example.com".  Other than the different
+   DNS resource record being queried, the rest of the operations are
+   anticipated to be identical to the steps described in this document.
+
+3.4.  Message Flow Illustration
+
+   The figure below gives an example illustration of a message flow in
+   the case of prefix discovery utilizing Pref64::/n validation.  The
+   figure also shows a step where the procedure ends if no Pref64::/n
+   validation is performed.
+
+   In this example, three Pref64::/n prefixes are provided by the DNS64
+   server.  The first Pref64::/n is using an NSP, in this example,
+   "2001:db8:42::/96".  The second Pref64::/n is using an NSP, in this
+   example, "2001:db8:43::/96".  The third Pref64::/n is using the WKP.
+   Hence, when the Pref64::/n prefixes are combined with the WKA to form
+   Pref64::WKA, the synthetic IPv6 addresses returned by the DNS64
+   server are "2001:db8:42::192.0.0.170", "2001:db8:43::192.0.0.170",
+   and "64:ff9b::192.0.0.170".  The DNS64 server could also return
+   synthetic addresses containing the IPv4 address 192.0.0.171.
+
+   The validation is not done for the WKP; see Section 3.1.
+
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 10]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+    Node                                           DNS64 server
+      |                                                |
+      |  "AAAA" query for "ipv4only.arpa."             |
+      |----------------------------------------------->|"A" query for
+      |                                                |"ipv4only.arpa."
+      |                                                |--------------->
+      |                                                |
+      |                                                | "A" response:
+      |                                                | "192.0.0.170"
+      |                                                | "192.0.0.171"
+      |                                                |<---------------
+      |                                +----------------------------+
+      |                                | "AAAA" synthesis using     |
+      |                                | three Pref64::/n.          |
+      |                                +----------------------------+
+      |  "AAAA" response with:                         |
+      |  "2001:db8:42::192.0.0.170"                    |
+      |  "2001:db8:43::192.0.0.170"                    |
+      |  "64:ff9b::192.0.0.170"                        |
+      |<-----------------------------------------------|
+      |                                                |
+   +----------------------------------------------+    |
+   | If Pref64::/n validation is not performed, a |    |
+   | node can fetch prefixes from AAAA responses  |    |
+   | at this point and skip the steps below.      |    |
+   +----------------------------------------------+    |
+      |                                                |
+      |  "PTR" query #1 for "2001:db8:42::192.0.0.170  |
+      |----------------------------------------------->|
+      |  "PTR" query #2 for "2001:db8:43::192.0.0.170  |
+      |----------------------------------------------->|
+      |                                                |
+      |  "PTR" response #1 "nat64_1.example.com"       |
+      |<-----------------------------------------------|
+      |  "PTR" response #2 "nat64_2.example.com"       |
+      |<-----------------------------------------------|
+      |                                                |
+   +----------------------------------------------+    |
+   | Compare received domains to a trusted domain |    |
+   | list and if matches are found, continue.     |    |
+   +----------------------------------------------+    |
+      |                                                |
+      |  "AAAA" query #1 for "nat64_1.example.com"     |
+      |----------------------------------------------->|
+      |  "AAAA" query #2 for "nat64_2.example.com"     |
+      |----------------------------------------------->|
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 11]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+      |                                                |
+      | "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 |
+      |<-----------------------------------------------|
+      | "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 |
+      |<-----------------------------------------------|
+      |                                                |
+   +----------------------------------------------+    |
+   | Validate AAAA responses and compare the IPv6 |    |
+   | addresses to those previously learned.       |    |
+   +----------------------------------------------+    |
+      |                                                |
+   +----------------------------------------------+    |
+   | Fetch the Pref64::/n from the validated      |    |
+   | responses and take into use.                 |    |
+   +----------------------------------------------+    |
+      |                                                |
+
+                 Figure 1: Pref64::/n Discovery Procedure
+
+4.  Operational Considerations for Hosting the IPv4-Only Well-Known Name
+
+   The authoritative name server for the well-known name SHALL have DNS
+   record TTL set to at least 60 minutes in order to improve
+   effectiveness of DNS caching.  The exact TTL value will be determined
+   and tuned based on operational experiences.
+
+   The domain serving the well-known name MUST be signed with DNSSEC.
+   See also Section 7.
+
+5.  Operational Considerations for DNS64 Operator
+
+   A network operator of a DNS64 server can guide nodes utilizing
+   heuristic discovery procedures by managing the responses a DNS64
+   server provides.
+
+   If the network operator would like nodes to utilize multiple
+   Pref64::/n prefixes, the operator needs to configure DNS64 servers to
+   respond with multiple synthetic AAAA records.  As per Section 3, the
+   nodes can then use them all.
+
+   There are no guarantees on which of the Pref64::/n prefixes nodes
+   will end up using.  If the operator wants nodes to specifically use a
+   certain Pref64::/n or periodically change the Pref64::/n they use,
+   for example, for load balancing reasons, the only guaranteed method
+   is to make DNS64 servers return only a single synthetic AAAA resource
+   record and have the TTL of that synthetic record such that the node
+   repeats the Pref64::/n discovery when required.
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 12]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   Besides choosing how many Pref64::/n prefixes to respond and what TTL
+   to use, DNS64 servers MUST NOT interfere with or perform other
+   special procedures for the queries related to the well-known name.
+
+5.1.  Mapping of IPv4 Address Ranges to IPv6 Prefixes
+
+   RFC 6147 [RFC6147] allows DNS64 implementations to be able to map
+   specific IPv4 address ranges to separate Pref64::/n prefixes.  That
+   allows handling of special use IPv4 addresses [RFC6890].  The example
+   setup where this might be used is illustrated in Figure 2.  The NAT64
+   "A" is used when accessing IPv4-only servers in the data center, and
+   the NAT64 "B" is used for Internet access.
+
+                      NAT64 "A" ----- IPv4-only servers in a data center
+                     /
+   IPv6-only node---<
+                     \
+                      NAT64 "B" ----- IPv4 Internet
+
+                 Figure 2: NAT64s with IPv4 Address Ranges
+
+   The heuristic discovery method described herein does not support
+   learning of the possible rules used by a DNS64 server for mapping
+   specific IPv4 address ranges to separate Pref64::/n prefixes.
+   Therefore, nodes will use the same discovered Pref64::/n to
+   synthesize IPv6 addresses from any IPv4 address.  This can cause
+   issues for routing and connectivity establishment procedures.  The
+   operator of the NAT64 and the DNS64 ought to take this into account
+   in the network design.
+
+   The network operators can help IPv6-only nodes by ensuring the nodes
+   do not have to work with IPv4 address literals for which special
+   mapping rules are used.  That is, the IPv4-only servers addressed
+   from the special IPv4 address ranges ought to have signed AAAA
+   records, which allows IPv6-only nodes to avoid local address
+   synthesis.  If the IPv6-only nodes are not using DNSSEC, then it is
+   enough if the network's DNS64 server returns synthetic AAAA resource
+   records pointing to IPv4-only servers.  Avoiding the need for
+   IPv6-only nodes to perform address synthesis for IPv4 addresses
+   belonging to special ranges is the best approach to assist nodes.
+
+   If the IPv6-only nodes have no choice other than using IPv4-address
+   literals belonging to special IPv4 address ranges and the IPv6-only
+   node will perform local synthesis by using the discovered Pref64::/n,
+   then the network ought to ensure with routing that the packets are
+   delivered to the correct NAT64.  For example, a router in the path
+   from an IPv6-only host to NAT64s can forward the IPv6 packets to the
+   correct NAT64 as illustrated in Figure 3.  The routing could be based
+
+
+
+Savolainen, et al.           Standards Track                   [Page 13]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   on the last 32 bits of the IPv6 address, but the network operator can
+   also use some other IPv6 address format allowed by RFC 6052 [RFC6052]
+   if it simplifies routing setup.  This setup requires additional logic
+   on the NAT64 providing connectivity to special IPv4 address ranges:
+   it needs to be able to translate packets it receives that are using
+   the Pref64::/n used with Internet connections.
+
+                      NAT64 "A" ----- IPv4-only servers in a data center
+                     /
+   IPv6-only host---router
+                     \
+                       NAT64 "B" ----- IPv4 Internet
+
+                  Figure 3: NAT64s with Assisting Router
+
+6.  Exit Strategy
+
+   A day will come when this tool is no longer needed.  A node SHOULD
+   implement a configuration knob for disabling the Pref64::/n discovery
+   feature.
+
+7.  Security Considerations
+
+   The security considerations follow closely those of RFC 6147
+   [RFC6147].  The possible attacks are very similar in the case where
+   an attacker controls a DNS64 server and returns tampered IPv6
+   addresses to a node and in the case where an attacker causes the node
+   to use tampered Pref64::/n for local address synthesis.  DNSSEC
+   cannot be used to validate responses created by a DNS64 server with
+   which the node has no trust relationship.  Hence, this document does
+   not change the big picture for untrusted network scenarios.  If an
+   attacker alters the Pref64::/n used by a DNS64 server or a node, the
+   traffic generated by the node will be delivered to an altered
+   destination.  This can result in either a denial-of-service (DoS)
+   attack (if the resulting IPv6 addresses are not assigned to any
+   device), a flooding attack (if the resulting IPv6 addresses are
+   assigned to devices that do not wish to receive the traffic), or an
+   eavesdropping attack (in case the altered NSP is routed through the
+   attacker).
+
+   Even though a well-known name's DNS A resource record would not
+   necessarily need to be protected with DNSSEC as both the name and
+   IPv4 addresses well-known, DNSSEC protection is required for DNS AAAA
+   resource record queries.  Without DNSSEC, fake positive AAAA
+   responses could cause hosts to erroneously detect Pref64::/n, thus
+   allowing an attacker to inject malicious Pref64::/n for hosts'
+   synthesis procedures.  A signed "ipv4only.arpa." allows validating
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 14]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   DNS64 servers (see [RFC6147] Section 3, Case 5, for example) to
+   detect malicious AAAA resource records.  Therefore, the zone serving
+   the well-known name has to be protected with DNSSEC.
+
+   For Pref64::/n discovery validation, the access network SHOULD sign
+   the NAT64 translator's fully qualified domain name.  A node SHOULD
+   use the algorithm described in Section 3.1 to validate each
+   discovered Pref64::/n.
+
+   The procedure described in Section 3.1.2 requires a node using DNSSEC
+   to validate discovery of Pref64::/n to have a list of trusted
+   domains.  If a matching domain is not found at Step 3 in
+   Section 3.1.2, an implementation might be tempted to ask a user to
+   temporarily or permanently add a received domain as trusted.  History
+   has shown that average users are unable to properly handle such
+   queries and tend to answer positively without thinking in an attempt
+   to move forward quickly.  Therefore, unless the DNSSEC-using
+   implementation has a way to dynamically and reliably add trusted
+   domains, it is better to fail the Pref64::/n discovery procedure.
+
+   Lastly, the best mitigation action against Pref64::/n discovery
+   attacks is to add IPv6 support for nodes' destinations and hence
+   reduce the need to perform local IPv6 address synthesis.
+
+8.  IANA Considerations
+
+8.1.  Domain Name Reservation Considerations
+
+   According to procedures described in [RFC3172] and [RFC6761], IANA
+   has delegated a new second-level domain in the .ARPA zone for the
+   well-known domain name "ipv4only.arpa.".  The intention is that there
+   will not be any further delegation of names below the
+   "ipv4only.arpa." domain.  The administrative and operational
+   management of this zone is performed by IANA.  The answers to the
+   seven questions listed in [RFC6761] are as follows:
+
+   1.  Are human users expected to recognize these names as special and
+       use them differently?  In what way?
+
+       No, although this is a domain delegated under the .arpa
+       infrastructural identifier top level domain.
+
+   2.  Are writers of application software expected to make their
+       software recognize these names as special and treat them
+       differently?  In what way?
+
+       Yes.  Any application attempting to perform NAT64 discovery will
+       query the name.
+
+
+
+Savolainen, et al.           Standards Track                   [Page 15]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   3.  Are writers of name resolution APIs and libraries expected to
+       make their software recognize these names as special and treat
+       them differently?  If so, how?
+
+       Yes, to the extent the API or library is affected by NAT64.
+
+   4.  Are developers of caching domain name servers expected to make
+       their implementations recognize these names as special and treat
+       them differently?  If so, how?
+
+       No.
+
+   5.  Are developers of authoritative domain name servers expected to
+       make their implementations recognize these names as special and
+       treat them differently?  If so, how?
+
+       No.
+
+   6.  Does this reserved Special-Use Domain Name have any potential
+       impact on DNS server operators?  If they try to configure their
+       authoritative DNS server as authoritative for this reserved name,
+       will compliant name server software reject it as invalid?  Do DNS
+       server operators need to know about that and understand why?
+       Even if the name server software doesn't prevent them from using
+       this reserved name, are there other ways that it may not work as
+       expected, of which the DNS server operator should be aware?
+
+       This name has effects for operators of NAT64/DNS64, but otherwise
+       is just another delegated .arpa domain.
+
+   7.  How should DNS Registries/Registrars treat requests to register
+       this reserved domain name?  Should such requests be denied?
+       Should such requests be allowed, but only to a specially-
+       designated entity?
+
+       The registry for .arpa is held at IANA, and only IANA needs to
+       take action here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 16]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+8.2.  IPv4 Address Allocation Considerations
+
+   The well-known name needs to map to two different global IPv4
+   addresses, which have been allocated as described in [RFC6890].  The
+   addresses have been taken from the IANA IPv4 Special Purpose Address
+   Registry [RFC6890], and 192.0.0.170 and 192.0.0.171 have been
+   assigned to this document with the parameters shown below:
+
+          +----------------------+-------------------------------+
+          | Attribute            | Value                         |
+          +----------------------+-------------------------------+
+          | Address Block        | 192.0.0.170/32                |
+          |                      | 192.0.0.171/32                |
+          | Name                 | NAT64/DNS64 Discovery         |
+          | RFC                  | RFC 7050, Section 2.2         |
+          | Allocation Date      | February 2013                 |
+          | Termination Date     | N/A                           |
+          | Source               | False                         |
+          | Destination          | False                         |
+          | Forwardable          | False                         |
+          | Global               | False                         |
+          | Reserved-by-protocol | True                          |
+          +----------------------+-------------------------------+
+
+      The Record for IPv4 Address Allocation for IPv4 Special Purpose
+                             Address Registry
+
+   The zone "ipv4only.arpa." is delegated from the ARPA zone to
+   appropriate name servers chosen by the IANA.  An apex A RRSet has
+   been inserted in the "ipv4only.arpa." zone as follows:
+
+   IPV4ONLY.ARPA.  IN A 192.0.0.170
+
+   IPV4ONLY.ARPA.  IN A 192.0.0.171
+
+8.3.  IAB Statement Regarding This .arpa Request
+
+   With the publication of this document, the IAB approves of the
+   delegation of "ipv4only" in the .arpa domain.  Under [RFC3172], the
+   IAB has requested that IANA delegate and provision "ipv4only.arpa."
+   as written in this specification.  However, the IAB does not take any
+   architectural or technical position about this specification.
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 17]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+9.  Acknowledgements
+
+   The authors would like to thank Dmitry Anipko, Cameron Byrne, Aaron
+   Yi Ding, Christian Huitema, Washam Fan, Peter Koch, Stephan
+   Lagerholm, Zhenqiang Li, Simon Perreault, Marc Petit-Huguenin, Andrew
+   Sullivan, and Dave Thaler for significant improvement ideas and
+   comments.
+
+   Jouni Korhonen would like to acknowledge his previous employer, Nokia
+   Siemens Networks, where the majority of his work on this document was
+   carried out.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
+              Message Protocol (ICMPv6) for the Internet Protocol
+              Version 6 (IPv6) Specification", RFC 4443, March 2006.
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              October 2010.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              April 2011.
+
+   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
+              DNS", RFC 6672, June 2012.
+
+
+
+Savolainen, et al.           Standards Track                   [Page 18]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+10.2.  Informative References
+
+   [RFC3172]  Huston, G., "Management Guidelines & Operational
+              Requirements for the Address and Routing Parameter Area
+              Domain ("arpa")", BCP 52, RFC 3172, September 2001.
+
+   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+              RFC 5735, January 2010.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+   [RFC6418]  Blanchet, M. and P. Seite, "Multiple Interfaces and
+              Provisioning Domains Problem Statement", RFC 6418,
+              November 2011.
+
+   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
+              RFC 6761, February 2013.
+
+   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
+              "Special-Purpose IP Address Registries", BCP 153, RFC
+              6890, April 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 19]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+Appendix A.  Example of DNS Record Configuration
+
+   The following BIND-style examples illustrate how A and AAAA records
+   could be configured by a NAT64 operator.
+
+   The examples use Pref64::/n of 2001:db8::/96, both WKAs, and the
+   example.com domain.
+
+   The PTR record for reverse queries (Section 3.1.1, Bullet 3):
+
+   $ORIGIN A.A.0.0.0.0.0.C\
+   .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
+   @         IN      SOA   ns1.example.com. hostmaster.example.com. (
+                           2003080800 12h 15m 3w 2h)
+             IN      NS    ns.example.com.
+
+             IN      PTR   nat64.example.com.
+
+   $ORIGIN B.A.0.0.0.0.0.C\
+   .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
+   @         IN      SOA   ns1.example.com. hostmaster.example.com. (
+                           2003080800 12h 15m 3w 2h)
+             IN      NS    ns.example.com.
+
+             IN      PTR   nat64.example.com.
+
+   If example.com does not use DNSSEC, the following configuration file
+   could be used.  Please note that nat64.example.com has both a AAAA
+   record with the Pref64::/n and an A record for the connectivity check
+   (Section 3.1.1, Bullet 2).
+
+   example.com.  IN SOA  ns.example.com. hostmaster.example.com. (
+                         2002050501 ; serial
+                         100        ; refresh (1 minute 40 seconds)
+                         200        ; retry (3 minutes 20 seconds)
+                         604800     ; expire (1 week)
+                         100        ; minimum (1 minute 40 seconds)
+                         )
+
+   example.com.  IN NS  ns.example.com.
+
+   nat64.example.com.
+                 IN AAAA  2001:db8:0:0:0:0:C000:00AA
+                 IN AAAA  2001:db8:0:0:0:0:C000:00AB
+                 IN A  192.0.2.1
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 20]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+   For DNSSEC to sign the records, the owner of the example.com zone
+   would have RRSIG records for both the AAAA and A records for
+   nat64.example.com.  As a normal DNSSEC requirement, the zone and its
+   parent also need to be signed.
+
+Appendix B.  About the IPv4 Address for the Well-Known Name
+
+   The IPv4 addresses for the well-known name cannot be non-global IPv4
+   addresses as listed in the Section 3 of [RFC5735].  Otherwise, DNS64
+   servers might not perform AAAA record synthesis when the well-known
+   prefix is used, as stated in Section 3.1 of [RFC6052].  However, the
+   addresses do not have to be routable or allocated to any real node as
+   no communications will be initiated to these IPv4 address.
+
+   Allocation of at least two IPv4 addresses improves the heuristics in
+   cases where the bit pattern of the primary IPv4 address appears more
+   than once in the synthetic IPv6 address (i.e., the NSP prefix
+   contains the same bit pattern as the IPv4 address).
+
+   If no well-known IPv4 addresses would be statically allocated for
+   this method, the heuristic would require sending of an additional A
+   query to learn the IPv4 addresses that would be then searched from
+   inside of the received IPv6 address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 21]
+
+RFC 7050                  Pref64::/n Discovery             November 2013
+
+
+Authors' Addresses
+
+   Teemu Savolainen
+   Nokia
+   Hermiankatu 12 D
+   FI-33720 Tampere
+   Finland
+
+   EMail: teemu.savolainen@nokia.com
+
+
+   Jouni Korhonen
+   Broadcom
+   Linnoitustie 6
+   FI-02600 Espoo
+   Finland
+
+   EMail: jouni.nospam@gmail.com
+
+
+   Dan Wing
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, California  95134
+   USA
+
+   EMail: dwing@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savolainen, et al.           Standards Track                   [Page 22]
+