One document matched: draft-ietf-behave-nat64-learn-analysis-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY RFC2671 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml'>
<!ENTITY RFC3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY RFC3596 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596.xml'>
<!ENTITY RFC4848 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml'>
<!ENTITY RFC4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY RFC3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY RFC2782 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml'>
<!ENTITY RFC5389 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml'>
<!ENTITY RFC4033 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY RFC2326 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml'>
<!ENTITY RFC3261 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC4566 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY RFC5507 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5507.xml'>
<!ENTITY RFC6052 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml'>
<!ENTITY RFC6147 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml'>
<!ENTITY RFC6146 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml'>
<!ENTITY RFC6144 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6144.xml'>
<!ENTITY Heuristics-NAT64 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-nat64-discovery-heuristic.xml'>
<!ENTITY GPPIPV6 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.korhonen-v6ops-3gpp-eps.xml'>
<!ENTITY REFERRALPS PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.carpenter-referral-ps.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc category="info"
ipr="trust200902"
docName="draft-ietf-behave-nat64-learn-analysis-03.txt">
<front>
<title abbrev="Learning NAT64 prefix">Analysis of solution proposals for hosts to learn NAT64 prefix</title>
<author initials='J.' surname="Korhonen" fullname='Jouni Korhonen' role='editor'>
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<code>FI-02600 Espoo</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author initials='T.' surname="Savolainen" fullname='Teemu Savolainen' role='editor'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720 Tampere</code>
<country>Finland</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<date year="2012"/>
<area>Internet</area>
<workgroup>Behavior Engineering for Hindrance Avoidance (BEHAVE)</workgroup>
<abstract>
<t>Hosts and applications may benefit from the knowledge if 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, used address format, 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 selection of heuristic discovery based solution.
</t>
</abstract>
</front>
<!-- ==================================================================== -->
<middle>
<section title="Introduction">
<t>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. There are two issues that can be addressed with solutions that allow hosts and applications to learn the Network Specific Prefix (NSP) <xref target="RFC6052"/> used
by the NAT64 <xref target="RFC6146"/> and the DNS64 <xref target="RFC6147"/> devices.
</t>
<t>Firstly, finding out whether a particular address is synthetic and therefore learning the presence of a NAT64. For example, a Dual-Stack (DS) host with IPv4 connectivity could use this information to bypass NAT64 and use native IPv4 transport for destinations that are reachable through IPv4. We will refer this as 'Issue #1' throughout the document.
</t>
<t>Secondly, to find out how to construct from an IPv4 address an IPv6
address that will be routable to/by the NAT64. This is useful when IPv4 literals can be found in the payload of some protocol or applications do not use DNS to resolve names to addresses but know the IPv4 address of the destination by some other means. We will refer this as 'Issue #2' throughout the document.
</t>
<t>Additionally, three other issues have to be considered by a solution
addressing the first two issues: whether DNS is required 'Issue #3', whether
a solution supports changing NSP 'Issue #4', and whether multiple NSPs are
supported (either of the same or different length) for
load-balancing purposes 'Issue #5'.</t>
<t> This document analyses all known solution proposals known at the
time of writing for communicating if the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. Based on the analysis we conclude whether the issue of learning the Network-Specific Prefix is worth solving and what would be the recommended solution(s) in that case.
</t>
</section>
<!-- =================================================================== -->
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="Address Synthesis"><vspace blankLines="1"/>
Address synthesis is a mechanism, in the context of this document, where an IPv4 address is represented as an IPv6 address understood by a NAT64 device. The synthesized IPv6 address is formed by embedding an IPv4 address as-is into an IPv6 address prefixed with a NSP/WKP. It is assumed that the 'unused' suffix bits of the synthesized address are set to zero as described in Section 2.2 of <xref target="RFC6052"/>.
</t>
<t hangText="DNS64"><vspace blankLines="1"/>
DNS extensions for network address translation from IPv6 clients to IPv4 servers: A network entity that synthesizes IPv6 addresses and AAAA records out of IPv4 addresses and A records, hence making IPv4 namespaces visible into IPv6 namespace. DNS64 uses NSP and/or WKP in the synthesis process.
</t>
<t hangText="NAT64"><vspace blankLines="1"/>
Network Address and protocol Translation mechanism for translating IPv6 packets to IPv4 packets and vice-versa: A network entity that a host or an application may want to either avoid or utilize. IPv6 packets hosts send to addresses in the NSP and/or WKP are routed to NAT64.
</t>
<t hangText="NSP"><vspace blankLines="1"/>
Network-Specific Prefix: A prefix chosen by network administrator
for NAT64/DNS64 to present IPv4 addresses in IPv6 namespace.
</t>
<t hangText="WKP"><vspace blankLines="1"/>
Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and configured by a network administrator for NAT64/DNS64 to present IPv4 addresses in IPv6 namespace.
</t>
</list>
</t>
</section>
<section title="Issues">
<t>This document analyses different solutions with a focus to following five issues:</t>
<t>
<list style="hanging">
<t hangText="Issue #1"><vspace blankLines="1"/>
The problem of distinguishing between a synthesized and a real IPv6 addresses, which allows a host to learn the presence of a NAT64 in the network.
</t>
<t hangText="Issue #2"><vspace blankLines="1"/>
The problem of learning the NSP used by the access network and needed for
local IPv6 address synthesis.</t>
<t hangText="Issue #3"><vspace blankLines="1"/>
The problem of learning the NSP or WKP used by the access network by a
host not implementing DNS (hence applications are unable to use DNS
to learn prefix).</t>
<t hangText="Issue #4"><vspace blankLines="1"/>
The problem of supporting changing NSP. The NSP learned by the host may
become stale for multiple reasons. For example, the host might move to a new network that uses different NSP, thus making the previously learned NSP stale. Also, the NSP used in the network may be changed due
administrative reasons, thus again making previously learned NSP stale.</t>
<t hangText="Issue #5"><vspace blankLines="1"/>
The problem of supporting multiple NSPs. A network may be configured with multiple NSPs for address synthesis. For example, for load-balancing purposes each NAT64 device in the same network could be assigned with their own NSP. It should be noted that
learning a single NSP is enough for an end host to successfully
perform local IPv6 address synthesis but to avoid NAT64 the end
host needs to learn all NSPs used by the access network.</t>
</list>
</t>
</section>
<!-- =================================================================== -->
<section title="Background">
<t>Certain applications, operating in protocol translation scenarios, can benefit from knowing the IPv6 prefix used by a local NAT64 of the attached access network. This applies to the Framework document <xref target="RFC6144"/> Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5 ("An IPv6 network to an
IPv4 network"), and Scenario 7 ("The IPv6 Internet to the IPv4 Internet"). Scenario 3("The IPv6 Internet to an IPv4 network") is not considered applicable herein as in that case a NAT64 is located at the front of remote IPv4 network and host in IPv6 Internet can benefit very little of learning NSP IPv6 prefix used by the remote NAT64. The NAT64 prefix can be either a Network Specific Prefix (NSP) or the Well-known Prefix (WKP). Below is (an incomplete) list of various use cases where it is beneficial for a host or an application to know the presence of a NAT64 and the NSP/WKP:
<list style="symbols">
<t>Host-based DNSSEC validation: as is documented in DNS64 <xref target="RFC6147"/> section 5.5. point 3, synthetic AAAA records cannot be successfully
validated in a host. In order to utilize NAT64 a security-aware and validating
host has to perform DNS64 function locally and hence it has to be able to
learn WKP or proper NSP.</t>
<t>Protocols that use IPv4 literals: in IPv6-only access native IPv4 connections
cannot be created. If a network has NAT64 it is possible to synthesize IPv6
address by combining the IPv4 literal and the IPv6 prefix used by NAT64. The
synthesized IPv6 address can then be used to create an IPv6 connection. </t>
<t>Multicast translation, as described on Internet Drafts contributed to behave WG called "An IPv4 - IPv6 multicast translator" by Stig Venaas, Hitoshi Asaeda,
Shinsuke Suzuki, and Tomohiro Fujisaki
at December 2010 and "Framework for IPv4/IPv6 Multicast Translation" by Stig Venaas, Xing Li, and Congxiao Bao at June 2011.</t>
<t>URI schemes with host IPv4 address literals rather than domain
names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1,
ipp://192.0.2.1)): a host can synthesize IPv6 address out of the literal
in URI and use IPv6 to create connection through NAT64.</t>
<t>Updating host's <xref target="RFC3484"/> preference table to prefer native prefixes over translated prefixes: this is useful as applications are more likely able to
traverse through NAT44 than NAT64.</t>
</list>
</t>
<t>DNS64 cannot serve applications that are not using DNS or that obtain referral as an IPv4 literal address. One example application is the Session Description Protocol (SDP) <xref target="RFC4566"/>, as used by Real Time Streaming Protocol (RTSP) <xref target="RFC2326"/> and Session Initiation Protocol (SIP) <xref target="RFC3261"/>. Other example applications include web browsers, as IPv4 address literals are still encountered in web pages and URLs. Some of these applications could still work through NAT64, provided they were able to create locally valid IPv6 presentations of peers' IPv4 addresses.
</t>
<t>
It is a known issue that passing IP address referrals, often fails in
today's Internet, as described in "Problem Statement for Referral" draft
submitted to the IETF by Brian Carpenter in February 2011. Synthesizing IPv6
addresses does not necessarily make the situation any better as the
synthesized addresses utilizing NSP are not distinguishable from public IPv6
addresses for the referral receiver. However, the situation is not
really any different from the current Internet as using public
addresses does not really guarantee reachability (for example due
firewalls). A node 'A' behind NAT64 may detect it is talking
to a node 'B' through NAT64, in which case the node 'A' may want to avoid
passing its IPv6 address as a referral to the node 'B'. The node 'B' on the IPv4 side of the
NAT64 should not see the IPv6 address of a node 'A' from the IPv6 side of NAT64,
and hence the node 'B' should not be able to pass IPv6 address referral to a node 'C'. Passing IPv4
presentation of the IPv6 address of the host 'A' to the node 'C' is bound to similar problems
as passing a public IPv4 address of a host behind NAT44 as a referral. This analysis
focuses on detecting NAT64 presence from the IPv6 side of NAT64.
</t>
</section>
<section title="Proposed solutions to learn about synthesis and Network-Specific Prefix">
<section title="DNS Query for a Well-Known Name" anchor="heuristics">
<section title="Solution description">
<t>Section 3 of <xref target="I-D.ietf-behave-nat64-discovery-heuristic"/> describes a host behavior for discovering the presence of a DNS64 server and a NAT64 device, and heuristics for discovering the used NSP. A host requiring information for local IPv6 address synthesis or for NAT64 avoidance sends a DNS query for an AAAA record of a Well-Known IPv4-only Fully Qualified Domain Name (FQDN). If a host receives a negative reply, it knows there are no DNS64 and NAT64 in the network.
</t>
<t>If a host receives AAAA reply, it knows the network must be utilizing IPv6
address synthesis. After receiving a synthesized AAAA Resource Record, the host may examine the received IPv6 address and use heuristics, such as "subtracting"
the known IPv4 address out of synthesized IPv6 address, to find out the NSP.</t>
<t> 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.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1 and Issue #2.</t>
<t hangText="+">Solves issue #4 via DNS record lifetime.</t>
<t hangText="+">Can partially solve issue #5 if multiple synthetic AAAA records are
included in the response. Can find multiple address formats.</t>
<t hangText="+">Does not necessarily require any standards effort.</t>
<t hangText="+">Does not require host stack or resolver changes. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.</t>
<t hangText="+">The solution is backward compatible from 'legacy' hosts and servers point of view.</t>
<t hangText="+">Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example every time the host attaches to a new network.</t>
<t hangText="+">Does not require explicit support from the network using NAT64</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires hosting of a DNS resource record for the Well-Known Name. </t>
<t hangText="-">Does not provide solution for issue #3.</t>
<t hangText="-">This method is only able to find one NSP even if a network
is utilizing multiple NSPs (issue #5) (unless DNS64 includes
multiple synthetic AAAA records in response).</t>
</list>
</t>
</section>
<section title="Summary">
<t>This is the only approach that can be deployed without explicit support from the network or the host. This approach could also complement explicit methods and
be used as a fallback approach when explicit methods are not supported by an access network.
</t>
</section>
</section>
<!-- =================================================================== -->
<section title="EDNS0 option indicating AAAA Record synthesis and format" anchor="edns0opt">
<section title="Solution description">
<t>The third revision of "EDNS0 Option for Indicating AAAA Record Synthesis and Format", a draft document submitted to the behave WG in February 2011 by Jouni Korhonen and Teemu Savolainen,
defined a new EDNS0 option <xref target="RFC2671"/>, which contained 3 flag bits (called SY-bits). The EDNS0 option served as an implicit indication of the presence of DNS64 server and the NAT64 device. The EDNS0 option SY-bit values other than '000' and '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA Resource Record.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.</t>
<t hangText="+">Solves issue #4 via DNS record lifetime.</t>
<t hangText="+">Can partially solve issue #5 if multiple synthetic AAAA records are
included in the response and all use same format.</t>
<t hangText="+">The solution is backward compatible from 'legacy' hosts and servers point of view.</t>
<t hangText="+">Even if the solution is bundled with DNS queries and responses, a standardization of a new DNS record type is not required, rather just defining a new EDNS0 option.</t>
<t hangText="+">EDNS0 option implementation requires changes only to DNS64 servers.</t>
<t hangText="+">Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses.</t>
<t hangText="+">Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires end hosts to support <xref target="RFC2671"/> EDSN0 extension mechanism.</t>
<t hangText="-">Requires host resolver changes and a mechanism/additions to the host resolver API (or flags, hints etc) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length.</t>
<t hangText="-">Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses.</t>
<t hangText="-">Does not provide solution for issue #3.</t>
</list>
</t>
</section>
<section title="Summary">
<t>The EDNS0 option based solution works by extending the existing EDNS0 Resource Record. Although the solution has host resolver and DNS64 server impacts, the changes are limited to those entities (end host, applications) that are interested in learning the presence of NAT64 and the used NAT64 prefix. The provisioning and management overhead is minimal if not non-existent as the EDNS0 options are synthesized in a DNS64 server in a same manner as the synthesized AAAA Resource Records. Moreover, EDNS0 does not induce any load to DNS servers because no new RRType query is defined.
</t>
</section>
</section>
<section title="EDNS0 flags indicating AAAA Record synthesis and format" anchor="edns0flags">
<section title="Solution description">
<t>The first revision of "EDNS0 Flags Indicating AAAA Record Synthesis and Format", a draft document submitted to the behave WG in July 2010 by Jouni Korhonen and Teemu Savolainen,
defined 3 new flag bits (called SY-bits) into EDNS0 OPT <xref target="RFC2671"/> header, which served as an implicit indication of the presence of DNS64 server and a NAT64 device. SY-bit values other than '000' or '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA Resource Record.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.</t>
<t hangText="+">Solves issue #4 via DNS record lifetime.</t>
<t hangText="+">Can partially solve issue #5 if multiple synthetic AAAA records are
included in the response and all use same format.</t>
<t hangText="+">The solution is backward compatible from 'legacy' hosts and servers point of view.</t>
<t hangText="+">EDNS0 option implementation requires changes only to DNS64 servers.</t>
<t hangText="+">Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses.</t>
<t hangText="+">Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires end hosts to support <xref target="RFC2671"/> EDSN0 extension mechanism.</t>
<t hangText="-">Consumes scarce flag bits from EDNS0 OPT header.</t>
<t hangText="-">Requires a host resolver changes and a mechanism/additions to the host resolver API (or flags, hints etc) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length.</t>
<t hangText="-">Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses.</t>
<t hangText="-">Does not provide solution for issue #3.</t>
</list>
</t>
</section>
<section title="Summary">
<t>This option is included here for the sake of completeness. The consumption of three bits of the limited EDNS0 OPT space
can be considered unfavorable and hence is unlikely to be accepted.</t>
</section>
</section>
<!-- =================================================================== -->
<section title="DNS Resource Record for IPv4-Embedded IPv6 address" anchor="a64">
<section title="Solution description">
<t>An Internet Draft titled "A64: DNS Resource Record for IPv4-Embedded IPv6 Address" by Mohamed Boucadair and Eric Burgey that was contributed
to behave WG at September 2010 proposed a new DNS Resource Record (A64) that would be a record dedicated to storing a single IPv4-Embedded
IPv6 address <xref target="RFC6052"/>. Use of a dedicated Resource Record would allow a host to distinguish between real IPv6 addresses
and synthesized IPv6 addresses. The solution requires host to send a query for an A64 record. Positive answer with A64 record informs
the requesting host that the resolved address is not a native address but an IPv4-Embedded IPv6 address. This would ease the local
policies to prefer direct communications (i.e., avoid using IPv4-Embedded IPv6 addresses when a native IPv6 address or
a native IPv4 address is available). Applications may be notified via new or modified API.
</t>
</section>
<section title="Analysis and discussion">
<t>
</t>
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1 and #5.</t>
<t hangText="+">Solves issue #4 via DNS record lifetime.</t>
<t hangText="+">The solution is backward compatible from 'legacy' hosts and servers point of view.</t>
<t hangText="+">Synthesized addresses can be used in authoritative DNS servers.</t>
<t hangText="+">Maintains the reliability of the DNS model (i.e., a synthesised IPv6 address is presented as such and not as native IPv6 address).</t>
<t hangText="+">When both IPv4-Converted and native IPv6 addresses are configured for the same QNAME, native addresses are preferred.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Does not address Issue #2 or #3 in any way.</t>
<t hangText="-">Requires a host resolver changes and a mechanism/additions to the host resolver API (or flags, hints etc) to deliver a note to the querying application that the address is synthesized.</t>
<t hangText="-">Requires a standardization of a new DNS Resource Record type (A64), and the implementation of it in both resolvers and servers.</t>
<t hangText="-">Requires a coordinated deployment between different flavors of DNS servers within the provider to work deterministically.</t>
<t hangText="-">Additional load the DNS servers (3 Queries, A64, AAAA and A, may be issued by a dual-stack host).</t>
<t hangText="-">Does not help to identify synthesized IPv6 addresses if the session does not involve any DNS queries.</t>
</list>
</t>
</section>
<section title="Summary">
<t>While the proposed solution delivers explicit information about address synthesis taking place solving the Issue #1, a standardization of a new DNS record type might turn out a too overwhelming task for a solution for a temporary transition phase. Defining a new record type increases load towards DNS server as the host issues parallel A64, AAAA and A queries.
</t>
</section>
</section>
<section title="Learning the IPv6 Prefix of a Network's NAT64 using DNS">
<section title="Solution description">
<t>Revision four of "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", a draft document submitted to the behave WG in October 2009 by Dan Wing,
proposed two DNS-based methods for discovering the presence of a DNS64 server and a NAT64 device, and then a mechanism for discovering the used NSP.</t>
<t>Firstly, the document proposed that a host may learn the presence of a DNS64 server and a NAT64 device, by receiving a TXT Resource Record with a well-known
string (that document proposes to be reserved by IANA) followed by the NAT64 unicast IPv6 address and the prefix length.
The DNS64 server would add the TXT Resource Record into the DNS response.
</t>
<t>Secondly, the document proposed specifying a new U-NAPTR <xref target="RFC4848"/> application to discover the NAT64's IPv6 prefix and length. The input domain name is exactly the same as would be used for a reverse DNS lookup, derived from the host's IPv6 in the ".ip6.arpa." tree. The host doing the U-NAPTR queries may need multiple queries until the host finds the provisioned domain name with the correct prefix length. The response to a successful U-NATPR query contains the unicast IPv6 address and the prefix length of the NAT64 device.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1 and Issue #2.</t>
<t hangText="+">Solves issue #4 via DNS record lifetime.</t>
<t hangText="+">Does not require host stack or resolver changes if the required logic and heuristics is implemented in applications that are interested in learning about address synthesis taking place.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires standardization of a well-known name by IANA for TXT Resource Record and/or a standardization of a new U-NAPTR application.</t>
<t hangText="-">Requires a host resolver changes and a mechanism/additions to the host resolver API (or flags, hints etc) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length. However, it is possible that the U-NAPTR application logic is completely implemented by the application itself as noted in PROs list.</t>
<t hangText="-">U-NAPTR prefix learning method may entail multiple queries.</t>
<t hangText="-">U-NAPTR prefix learning method requires provisioning of NSPs in ".ip6.arpa." tree.</t>
<t hangText="-">RFC5507 <xref target="RFC5507"/> specifically recommends against reusing TXT Resource Records to expand DNS.</t>
<t hangText="-">Requires configuration on the access network's DNS servers.</t>
<t hangText="-">Does not provide solution for issue #3.</t>
</list>
</t>
<t>If TXT record would include multiple NSPs issue #5 could be solved as
well, but only if nodes as a group would select different NSPs hence
supporting load-balancing. As this is not clear this item is not yet
listed under PRO or CON.</t>
</section>
<section title="Summary">
<t>The implementation of this solution requires some changes to the applications and resolvers in a similar fashion as in solutions in <xref target="edns0opt"/>, <xref target="edns0flags"/> and <xref target="a64"/>. Unlike the other DNS-based approaches, the U-NAPTR-based solution also requires provisioning information into the '.ip6.arpa.' tree which is not any more entirely internal to the provider hosting the NAT64/DNS64 service.
</t>
<t>The iterative approach of learning the NAT64 prefix in U-NAPTR-based solution may result in multiple DNS queries, which can be considered more complex and inefficient compared to other DNS-based solutions.
</t>
</section>
</section>
<!-- =================================================================== -->
<section title="Learning the IPv6 Prefix of a Network's NAT64 using DHCPv6" anchor="learndhcpv6">
<section title="Solution description">
<t>Two individual IETF Internet-Draft contributions specified DHCPv6 based approaches.</t>
<t>"Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", a draft document submitted to the behave WG in October 2009 by Dan Wing,
described a new DHCPv6 <xref target="RFC3315"/> option (OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64.
</t>
<t>"Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", a draft document submitted to the behave WG in December 2009 by
Mohamed Boucadair, Pierre Levis, Jean-Luc Grimault, Teemu Savolainen, and Gabor Bajko, proposed a DHCPv6 option that could be used to communicate to a
requesting host the prefix used for building IPv4-Converted IPv6 addresses together with the format type and therefore also the used address synthesis
algorithm. Provisioning the format type is required so as to be correctly handled by the NAT64-enabled devices deployed in a given domain.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1, Issue #2, Issue #3 and
Issue #4 via DHCPv6 information lifetime.</t>
<t hangText="+">Does not involve DNS system. Therefore, applications that would not normally initiate any DNS queries can still learn the NAT64 prefix.</t>
<t hangText="+">DHCPv6 is designed to provide various kinds of configuration information in a centrally managed fashion.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Change of NSP requires change to DHCPv6 configuration.</t>
<t hangText="-">Requires at least Stateless DHCPv6 client on hosts.</t>
<t hangText="-">Requires support on DHCPv6 clients, which is not trivial in all operating systems.</t>
<t hangText="-">The DHCPv6-based solution involves changes and management on network side nodes that are not really part of the NAT64/DNS64 deployment (or issues caused by their existence).</t>
<t hangText="-">A new DHCPv6 option is required and the corresponding changes to both DHCPv6 clients and servers.</t>
</list></t>
<t>If DHCPv6 would include multiple NSPs issue #5 could be solved as well, but only if nodes as a group would select different NSPs hence supporting load-balancing. As this
is not clear this item is not yet listed under PRO or CON.</t>
</section>
<section title="Summary">
<t>The DHCPv6-based solution would be a good solution in a sense it hooks into general IP configuration phase, allows easy updates when configuration information changes and does not involve DNS in general. Use of DHCPv6 requires configuration changes on DHCPv6 clients and servers and in some cases may also require implementation changes. Furthermore, it is not obvious that all devices that need translation services would implement stateless DHCPv6. For example, cellular 3GPP networks do not mandate hosts or network to implement or deploy DHCPv6.
</t>
</section>
</section>
<section title="Learning the IPv6 Prefix of a Network's NAT64 using Router Advertisements" anchor="learnra">
<section title="Solution description">
<t>Revision three of "Learning the IPv6 Prefixes of an IPv6/IPv4 Translator", a draft document submitted to the behave WG in July 2009 by Dan Wing, Xuewei Wang, and Xiaohu Xu,
described a new Router Advertisement (RA) <xref target="RFC4861"/> option (OPTION_AFT_PREFIX_RA) that would contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64. The RA option is essentially the same as for DHCPv6 discussed in <xref target="learndhcpv6"/>.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1, Issue #2, and Issue #3.</t>
<t hangText="+">Can solve Issue #4 if lifetime information can be communicated.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires configuration and managements of all access routers to emit correct information in RA. This could, for example, be accomplished somehow by piggybacking on top of routing protocols (which would then require enhancements to routing protocols)</t>
<t hangText="-">In some operating systems it may not be trivial to transfer information obtained in RA to upper layers</t>
<t hangText="-">Requires changes to host operating system's IP stack</t>
<t hangText="-">NSP change requires changes to access router configuration</t>
<t hangText="-">Requires standardization of a new option to Router Advertisement that is generally unfavored approach</t>
<t hangText="-">The RA-based solution involves changes and management on network side nodes that are not really part of the NAT64/DNS64 deployment (or issues caused by their existence).
</t>
</list></t>
<t>If RA would include multiple NSPs issue #5 could be solved as well, but only if nodes as a group would select different NSPs hence supporting load-balancing. As this
is not clear this item is not yet listed under PRO or CON.</t>
</section>
<section title="Summary">
<t>The RA-based solution would be a good solution in a sense it hooks into general IP configuration phase, allows easy updates when configuration information changes and does not involve DNS in general. However, generally introducing any changes to the Neighbor Discovery Protocol that are not absolutely necessary are unfavored due to the impact on both network node side and end host IP stack implementations.
</t>
<t>Compared to the DHCPv6 equivalent solution in <xref target="learndhcpv6"/> the management overhead is greater with RA-based solution. In case of DHCPv6-based solution the management can be centralized to few DHCPv6 servers compared to RA-based solution where each access router is supposed to be configured with the same information.
</t>
</section>
</section>
<section title="Using application layer protocols such as STUN">
<section title="Solution description">
<t>Application layer protocols, such as Session Traversal Utilities for NAT (STUN) <xref target="RFC5389"/>,
which define methods for endpoints to learn their external IP addresses could be used for NAT64 and NSP discovery.
This document focuses on STUN, but the protocol could be something else as well.
</t>
<t>
A host must first use DNS to discover IPv6 representation(s) of STUN server(s) IPv4 address(es),
because the host has no way to directly use IPv4 addresses to contact to STUN server(s).</t>
<t>After learning the IPv6 address of a STUN server the STUN client sends a request to the STUN server
containing new 'SENDING-TO' attribute that tells to the server the IPv6 address the client sent the request to.
In a reply the server includes another new attribute called 'RECEIVED-AS',
which contains server's IP address the request arrived on. After receiving the reply the client compares
'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP candidate.</t>
</section>
<section title="Analysis and discussion">
<t>This solution is relatively similar as described in <xref target="heuristics"/>, but instead of using DNS uses STUN
to get input for heuristic algorithms.</t>
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1 and Issue #2.</t>
<t hangText="+">Does not require host changes or supportive protocols such as DNS or DHCPv6. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.</t>
<t hangText="+">The solution is backward compatible from 'legacy' hosts and servers point of view.</t>
<t hangText="+">Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example every time the host attaches to a new network.</t>
<t hangText="+">Does not require explicit support from the network using NAT64.</t>
<t hangText="+">Can possibly be bundled to existing STUN message exchanges as new attributes and hence client can learn its external IPv4 address
and a NSP/WKP with the same exchange</t>
<t hangText="+">Can be used to confirm the heuristics by synthesizing IPv6 address of another STUN server or by synthesizing IPv6 address of
first STUN server after host has heuristically determined NSP using method from <xref target="heuristics"/>. I.e. the connectivity test
could be done with STUN.</t>
<t hangText="+">True IPv4 destination address is used in NSP determination instead of IPv4 address received from DNS. This may increase reliability.</t>
<t hangText="+">The same STUN improvement could also be used to reveal NAT66 on the data path,
if the 'RECEIVED-AS' would contain different IPv6 address than 'SENDING-TO'.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires a server on the network to respond the queries.</t>
<t hangText="-">Requires standardization if done as extension to STUN.</t>
<t hangText="-">The solution involves changes and management on network side nodes that are not really part of the NAT64/DNS64 deployment (or issues caused by their existence).
</t>
<t hangText="-">Does not solve issue #3 if STUN server's synthetic IPv6 address
is provisioned via DNS.</t>
<t hangText="-">Does not solve issue #4 as the STUN server would not be
aware of learned NSP's validity time.</t>
<t hangText="-">Does not solve issue #5 as the STUN server would not be
aware of multiple NSP prefixes.</t>
<t hangText="-">Heavyweight solution especially if an application does not otherwise support STUN.</t>
</list>
</t>
</section>
<section title="Summary">
<t>The STUN, or similar, protocol based approach is a second way to solve the problem without explicit access network support.
The heuristics for NSP discovery would still be in the client, however, the result may be more reliable as actual IPv4 destination address
is compared to IPv6 address used in sending. The additional benefit of STUN is that the client learns its public IPv4 address
with the same message exchange. STUN could also be used as the connectivity test tool if the client would first heuristically determine
NSP out of DNS as described in <xref target="heuristics"/>, synthesize IPv6 representation of STUN server's IPv4 address, and then tests connectivity
to the STUN server.
</t>
<t>
As an additional benefit the STUN improvement could be used for NAT66 discovery.
</t>
</section>
</section>
<section title="Learning the IPv6 Prefix of a Network's NAT64 using Access Technology Specific Methods">
<section title="Solution description">
<t>Several link layers on different access systems have attachment
time signaling protocols for negotiating various parameters that are used later on
with the established link layer connection. Examples of such include 3GPP
Non-Access-Stratum (NAS) signaling protocol <xref target="NAS.24.301"/> among other link layers and
tunneling solutions. There, using NAS signaling it
could be possible to list all NSPs with their respective prefix lengths in generic protocol configuration option containers during the network access establishment. The lack of NSPs in protocol configuration option containers would be an implicit indication that there is no NAT64 present in the network.
</t>
</section>
<section title="Analysis and discussion">
<t>The PROs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="+">Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #5.</t>
<t hangText="+">Can solve Issue #4 if lifetime information is also communicated.</t>
</list>
</t>
<t>The CONs of the proposal are listed below:
<list style="hanging" hangIndent="2">
<t hangText="-">Requires configuration and managements of all access routers/gateway to emit correct information in "link/lower layer" signaling. In a case the NAT64 functionality is implemented into the access router/gateway itself that terminates the generic protocol configuration exchange, then the configuration management can be automated.</t>
<t hangText="-">In some operating systems it may not be trivial to transfer information obtained in "link/lower layers" to upper layers.</t>
<t hangText="-">NSP change may require changes to access router/gateway configuration.</t>
<t hangText="-">Requires standardization of a new configuration parameter exchange/container for each access system of interest. The proposed solution is indeed specific to each access technology.</t>
</list>
</t>
</section>
<section title="Summary">
<t>The Access Technology-based solution would be a good solution in a sense it hooks into general network access establishment phase, allows easy updates when configuration information changes and does not involve DNS in general. However, generally introducing any changes to the link/lower layers is a long and slow process, and changes would need to be done for all access technologies/systems that are used with NAT64.
</t>
<t>Compared to the RA equivalent solution in <xref target="learnra"/> the management overhead is equivalent or even less than RA-based solution.
</t>
</section>
</section>
</section>
<!-- =================================================================== -->
<section title="Conclusion">
<t>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.</t>
<t>As a general principle we prefer to have as minimal solution as possible,
avoid impacts to entities not otherwise involved in the
protocol translation scheme, minimize host impact, and that requires minimal
to no operational effort on the network side.
</t>
<t>Of the different issues we give most weight for issues #1 and #2. We are not giving
much weight for the Issue #3 'DNS should not be required', as cases
where hosts need to synthesize IPv6 addresses but do not have DNS available
seem rare for us. Even if application does not otherwise utilize DNS, it ought to
be able to trigger simple DNS query to find out WKP/NSP. Issue #4 is handled by
majority of solutions and Issue #5 is considered to be mostly insignificant as
even if individual hosts would use only one NSP at a time, different hosts would
be using different NSPs, hence supporting load-balancing targets.
Only one of the discussed solutions, see <xref target="learndhcpv6"/>, support learning of possible new or indicating
support for multiple algorithms for address synthesis other than the one described
in <xref target="RFC6052"/>.</t>
<t>The DNS64 entity has to be configured with WKP/NSP in order for it to do
synthesis and hence using DNS also for delivering the synthesis information
sounds logical. The fact that the synthesis information fate-shares the
information received in the DNS response is a valuable attribute and reduces the
possible distribution of stale prefix information. However, having all
DNS64 servers to support explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record approaches) is difficult to arrange.
The U-NAPTR-based approach
would require provisioning information into the '.ip6.arpa' tree which would not be entirely internal for the provider.
Use of DHCPv6 would require additional trouble configuring DHCPv6 servers and ensuring DHCPv6
clients are in place, and furthermore that the NAT64, DHCPv6 (and possible even some
DNS64) servers are all in sync. RA-based mechanisms are operationally expensive as
configuration would have to be placed and maintained in the access routers.
Furthermore, both DHCPv6 and RA based mechanisms involve entities that do not
otherwise need to be aware of protocol translation (only need to know DNS server
addresses). Finally, regarding the use of STUN. A host does not need to implement STUN where as DNS is in practice required anyway. Also, STUN protocol would need to be changed on both host and network side to support the discovery of NAT64 and WKP/NSP.
</t>
</section>
<!-- =================================================================== -->
<section title="Security Considerations">
<t>The security considerations are essentially similar to what is described in DNS64 <xref target="RFC6147"/>.
Forgery of information required for IPv6 address synthesis may allow an
attacker to insert itself as middle man or to perform denial-of-service
attack. 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). 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.
</t>
</section>
<!-- =================================================================== -->
<section title="IANA Considerations">
<t>This document is informative and has no actions to IANA.
</t>
</section>
<!-- =================================================================== -->
<section title="Contributors">
<t>The following people have contributed text to this document.
<list>
<t>Mohamed Boucadair<vspace blankLines="0"/>
France Telecom<vspace blankLines="0"/>
Rennes, 35000<vspace blankLines="0"/>
France<vspace blankLines="1"/>
Email: mohamed.boucadair@orange-ftgroup.com
</t>
</list>
</t>
</section>
<section title="Acknowledgements">
<t>Authors would like to thank Dan Wing and Christian Huitema especially for the STUN idea and for their valuable comments and discussions.
</t>
</section>
</middle>
<!-- ==================================================================== -->
<back>
<references title="Normative References">
&RFC6146;
&RFC6147;
&RFC3484;
&RFC4848;
&RFC3315;
&RFC4861;
&RFC6052;
&RFC4566;
&RFC2326;
&RFC3261;
&RFC5389;
&RFC2671;
&Heuristics-NAT64;
</references>
<references title="Informative References">
&RFC6144;
&RFC5507;
<reference anchor='NAS.24.301'>
<front>
<title>Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)
</title>
<author><organization>3GPP</organization></author>
<date day='22' month='December' year='2010' />
</front>
<seriesInfo name='3GPP TS' value='24.301 8.8.0' />
<format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/24301.htm' />
</reference>
</references>
</back>
</rfc> | PAFTECH AB 2003-2026 | 2026-04-23 10:10:09 |