| Behavior Engineering for Hindrance Avoidance (BEHAVE) | J. Korhonen, Ed. |
| Internet-Draft | Nokia Siemens Networks |
| Intended status: Informational | T. Savolainen, Ed. |
| Nokia | |
| 2011 |
Analysis of solution proposals for hosts to learn NAT64 prefix
draft-ietf-behave-nat64-learn-analysis-02.txt
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Copyright (c) 2011 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.
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) [RFC6052] used by the NAT64 [RFC6146] and the DNS64 [RFC6147] devices.
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.
Secondly, finding 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.
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'.
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.
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 [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:
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) [RFC4566], as used by Real Time Streaming Protocol (RTSP) [RFC2326] and Session Initiation Protocol (SIP) [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.
It is a known issue that passing IP address referrals, often fails in today's Internet [I-D.carpenter-referral-ps]. 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.
Section 3 of [I-D.savolainen-heuristic-nat64-discovery] 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.
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.
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.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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.
Section 3 of [I-D.korhonen-edns0-synthesis-flag] defines a new EDNS0 option [RFC2671], which contain 3 flag bits (called SY-bits). The EDNS0 option serves 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 tell the NSP prefix length. Only the DNS64 server can insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA Resource Record.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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.
Section 3 of the version -00 of [I-D.korhonen-edns0-synthesis-flag] defines 3 new flag bits (called SY-bits) into EDNS0 OPT [RFC2671] header, which serve as an implicit indication of the presence of DNS64 server and a NAT64 device. SY-bit values other than '000' or '111' explicitly tell the NSP prefix length. Only the DNS64 server can insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA Resource Record.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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.
Section 4 of [I-D.boucadair-behave-dns-a64] defines a new DNS Resource Record (A64) that is a record specific to store a single IPv4-Embedded IPv6 address [RFC6052]. Using a dedicated Resource Record allows 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.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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.
Section 4.1 of the version -04 of [I-D.wing-behave-learn-prefix] actually proposes two DNS-based method for discovering the presence of a DNS64 server and a NAT64 device, and then a mechanism for discovering the used NSP. First, a host may learn the presence of a DNS64 server and a NAT64 device, by receiving a TXT Resource Record with a well-known (TBD IANA registered?) string followed by the NAT64 unicast IPv6 address and the prefix length. The DNS64 server would add the TXT Resource Record into the DNS response.
Second, Section 4.1 of the version -04 of [I-D.wing-behave-learn-prefix] also proposes specifying a new U-NAPTR [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 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.
[Editor' note: can this be made to solve issue #5 by having multiple NSPs in TXT record?]
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
The implementation of this solution requires some changes to the applications and resolvers in a similar fashion as in solutions in Section 4.2, Section 4.3 and Section 4.4. 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.
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.
Two individual drafts specify DHCPv6 based approaches.
Section 4.2 of the version -04 of [I-D.wing-behave-learn-prefix] describes a new DHCPv6 [RFC3315] option (OPTION_AFT_PREFIX_DHCP) that contains the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64.
Section 4 of [I-D.boucadair-dhcpv6-shared-address-option] defines a DHCPv6 option that can 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.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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 nor CON.
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.
Section 3.3 of the version -03 of [I-D.wing-behave-learn-prefix] describes a new Router Advertisement (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that contains 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 Section 4.6.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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 nor CON.
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 the impact on both network node side and end host IP stack implementations.
Compared to the DHCPv6 equivalent solution in Section 4.6 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.
Application layer protocols, such as Session Traversal Utilities for NAT (STUN) [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.
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).
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.
This solution is relatively similar as described in section 4.3, but instead of using DNS uses STUN to get input for heuristic algorithms.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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 section 4.3, synthesize IPv6 representation of STUN server's IPv4 address, and then tests connectivity to the STUN server.
As an additional benefit the STUN improvement could be used for NAT66 discovery.
Several link layers on different access systems have an attachment time signaling protocols to negotiate various parameter used later on the established link layer connection. Examples of such include 3GPP Non-Access-Stratum (NAS) signaling protocol [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.
The PROs of the proposal are listed below:
The CONs of the proposal are listed below:
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 router, and yet is access technology/system specific.
Compared to the RA equivalent solution in Section 4.7 the management overhead is equivalent or even less than RA-based solution.
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.
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.
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 Section 4.6, support learning of possible new or indicating support for multiple algorithms for address synthesis other than the one described in [RFC6052].
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.
The security considerations are essentially similar to what is described in DNS64 [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.
This document is informative and has no actions to IANA.
The following people have contributed text to this document.
Authors would like to thank Dan Wing and Christian Huitema especially for the STUN idea for their valuable comments and discussions.
| [RFC6144] | Baker, F., Li, X., Bao, C. and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. |
| [RFC5507] | IABFaltstrom, P., Austein, R. and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009. |
| [I-D.venaas-behave-mcast46] | Venaas, S, Asaeda, H, SUZUKI, S and T Fujisaki, "An IPv4 - IPv6 multicast translator", Internet-Draft draft-venaas-behave-mcast46-02, December 2010. |
| [I-D.venaas-behave-v4v6mc-framework] | Venaas, S, Li, X and C Bao, "Framework for IPv4/IPv6 Multicast Translation", Internet-Draft draft-venaas-behave-v4v6mc-framework-03, June 2011. |
| [I-D.korhonen-edns0-synthesis-flag] | Korhonen, J and T Savolainen, "EDNS0 Option for Indicating AAAA Record Synthesis and Format", Internet-Draft draft-korhonen-edns0-synthesis-flag-02, February 2011. |
| [I-D.savolainen-heuristic-nat64-discovery] | Savolainen, T and J Korhonen, "Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name", Internet-Draft draft-savolainen-heuristic-nat64-discovery-01, February 2011. |
| [I-D.boucadair-behave-dns-a64] | Boucadair, M and E Burgey, "A64: DNS Resource Record for IPv4-Embedded IPv6 Address", Internet-Draft draft-boucadair-behave-dns-a64-02, September 2010. |
| [I-D.wing-behave-learn-prefix] | Wing, D, "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", Internet-Draft draft-wing-behave-learn-prefix-04, October 2009. |
| [I-D.boucadair-dhcpv6-shared-address-option] | Boucadair, M, Levis, P, Grimault, J, Savolainen, T and G Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Internet-Draft draft-boucadair-dhcpv6-shared-address-option-01, December 2009. |
| [I-D.carpenter-referral-ps] | Carpenter, B, Jiang, S and Z Cao, "Problem Statement for Referral", Internet-Draft draft-carpenter-referral-ps-02, February 2011. |
| [NAS.24.301] | 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) ", 3GPP TS 24.301 8.8.0, December 2010. |