Speeding up IPv6 Transition: Discovering NAT64 and Learning Prefix for IPv6 Address Synthesis

Yi Ding Teemu Savolainen Jouni Korhonen Markku Kojo University of Helsinki Nokia Research Center Nokia Siemens Networks University of Helsinki [email protected].fi [email protected] [email protected] [email protected].fi

Abstract—During the transition from IPv4 to IPv6 hosts in together with DNS64 allows nodes in IPv6-only networks to IPv6-only networks need to communicate with IPv4 hosts as communicate with nodes in IPv4-only networks. As a grow- most of the services are not yet supporting IPv6. Hosts ing percentage of access network infrastructure is migrating with IPv6 access would benefit from discovering the presence of NAT64 and learning a prefix needed for IPv6 address synthesis. to IPv6, NAT64 enables connectivity to a large number of We propose two mechanisms and systematically evaluate the existing IPv4 services from IPv6 networks. More users are existing solutions in this area. Based on our comparison of the therefore encouraged to adopt IPv6 as the first choice. existing solutions and practical implementation experience, we At the same time, owing to the inherited NAT limitations, recommend the heuristic discovery method which is now adopted NAT64 causes problems to various applications such as indi- in the IETF1 transition toolbox for the IPv6 Internet. vidual end user targeted web advertising. Hopefully NAT64 will indirectly push service and content providers to upgrade I.INTRODUCTION from IPv4 to IPv6 for better service via native IPv6. IPv6 transition is entering a critical phase by facing the pres- When a NAT64 entity is deployed on the edge of an access sure of IPv4 depletion as IANA2 has assigned network, an end host can benefit from learning the information its last available IPv4 address pool in February 2011 [1]. The of IPv6 synthesis for two major reasons. First, by discovering demand for IPv6 is growing strong especially in Europe and the presence of NAT64 the host can choose to avoid network Asia where the proliferations of smartphones, IP connected translation by redirecting traffic to other channels. Second, sensor devices and new broadband subscribers are pleading by deriving the NAT64 prefix from a synthetic IPv6 address, for a larger address space that IPv4 simply cannot offer. For the host can synthesize IPv6 addresses without the support of the merits of IPv6 besides sufficient address space the global the DNS64 entity and also perform DNSSEC [9] validation IPv6 adoption rate is increasing steadily. However, most of successfully. the Internet services are still not ready for IPv6. For instance, Several mechanisms for discovering the presence of NAT64 only a few of the top 1,000 websites provide IPv6 addresses and learning the prefix used for address synthesis are hence (AAAA records) in the (DNS) and proposed in the recent development. The "Framework for merely 4% of service sites are accessible via an IPv6 native IPv4/IPv6 Translation" [10] describes an extensive set of connection [2], [3]. Moreover, until February 27 of 2012 the scenarios for IPv4/IPv6 translation. Among these scenarios percentage of registered domains with AAAA records is no learning the NAT64 prefix is useful, when communication is more than 2.1% of all domains in the listed top level domains initiated from an IPv6 network to the IPv4 Internet or to an (3,247,614 out of 154,840,089) [4]. As pointed out in [5], [6], IPv4 network [11]. 3GPP3 has specified IPv6 as the stan- the key to speed up IPv6 transition is interoperability so that dard addressing scheme. Therefore, the protocol translation both IPv4 and IPv6 nodes are able to coexist and communicate scenario is of particular commercial interest in 3GPP based with each other. cellular networks (3GPP migration guidelines, scenario 3 [12]) To achieve interoperability for the smooth adoption, IETF as an alternative to dual-stack deployments. As of writing this has developed a number of transition mechanisms and stan- paper first commercial IPv6-only cellular networks are already dardized recommended solutions. The once criticized Network being launched. Address Translation (NAT) mechanism is now gaining a In this paper, we study the area of discovering the NAT64 positive role in the IPv6 transition to bridge the gap between function in access networks and learning the NAT64 IPv6 the two ’uncollaborative’ IP versions. IETF has developed prefix used for address synthesis. Our major contributions NAT64 [7] for IPv6 to IPv4 protocol translation and DNS64 include: [8] to make IPv4-only nodes to appear as reachable over IPv6. • An extensive survey of solutions. We summarize our DNS64 achieves this by returning a synthetic IPv6 address analysis in [11] and extend it further with learned de- as a response to a query for an IPv4-only address. NAT64 ployment considerations.

1Internet Engineering Task Force, http://www.ietf.org 2Internet Assigned Numbers Authority, http://www.iana.org 3The 3rd Generation Partnership Project, http://www.3gpp.org • Based on our systematic comparison of solutions, we The solution for allowing a host to cope with IPv4 address recommend the heuristic discovery approach [13]. literals and perform DNSSEC validation in networks having • We implement both of our proposals and share our expe- NAT64 services is obvious: the host needs to implement local rience in mobile networks to guide future development. IPv6 address synthesis functionality. However, before a host The rest of paper is organized as follows. Section II intro- can perform local IPv6 address synthesis it has to learn the duces the architecture and major functions of NAT64/DNS64. NAT64 IPv6 prefix used in a current access network. Section III provides an extensive survey of solutions. In Once a host, with any tool, has learned the IPv6 prefix of Section IV we analyze all proposals and provide our recom- the NAT64 in the attached network, the host can synthesize mendation. The implementation of our proposals is covered in IPv6 addresses from IPv4 addresses as described in the DNS64 Section V. Finally, we conclude the paper and discuss future specification [8]. This means the host can synthesize IPv6 ad- work in Section VI. dresses out of (possible DNSSEC validated) A records or from IPv4 address literals in (e.g. http://192.0.2.1/index.html) II. NAT64 AND DNS64 or from other sources. NAT64 [7] and DNS64 [8] enable nodes in IPv6-only In order to avoid man-in-the-middle attacks, it must be networks to communicate with nodes in IPv4-only networks. possible to secure the NAT64 prefix learning procedure on A typical 3GPP cellular network-based NAT64/DNS64 setup need basis. If an attacker is able to influence what NAT64 is presented in Fig. 1. NAT64 performs stateful translation IPv6 prefix nodes configure, it will be possible to cause very much like ordinary IPv4 NAT, except that in addition to at least denial-of-service and traffic redirection attacks for address translation it also translates packet headers between flooding or eavesdropping purposes. In the worst case the IPv6 and IPv4. DNS64 is an essential part of the overall performs an IPv6 address synthesis by combining a DNSSEC protocol translation system, making IPv4-only reachable nodes [9] validated IPv4 address with the NAT64 IPv6 prefix and to look like being reachable over IPv6. DNS64 does this by thinks the resulting address is securely synthesized. combining IPv4-only node’s real IPv4 address and the prefix NAT64 works best with applications that do not embed of the NAT64 entity together as a synthetic IPv6 address. The IP address literals in the application protocol payload. App- synthetic IPv6 addresses are delivered to an IPv6-only node lications that embed IP address literals in their payload are inside synthetic AAAA records, hence making the node to likely to fail in the presence of NAT64 unless Application believe that the destination is IPv6-reachable, while in reality Layer Gateways (ALGs) are implemented on NAT64s. it is not. Standardized address formats are used in the process [14]. The NAT64 prefix can be a Network-Specific Prefix III.SURVEY ON SOLUTIONS (NSP) which is assigned to a provider and chosen by the network administrator or a Well-Known Prefix (WKP) defined A. Motivation, Challenges, and Solution Categories by IETF as 64:ff9b::/96 to represent IPv4 addresses in IPv6 As dual-stack OSs and multiple interfaces have become namespace (i.e. an IPv4-converted IPv6 address). the main stream, discovering the presence of NAT64 in the

IPv4-only access network can assist such hosts to bypass NAT64 via a server native IPv4 connection or other interfaces. At the same time, IPv4 learning the NAT64 prefix can support hosts in constructing NAT64 internet Gateway valid IPv6 synthesis addresses and hence solving the problem IPv6-only Dual-stack of embedded IPv4 address literals, which has become the connection 3GPP core server network major cause of connection disruption for IPv6-only hosts IPv6 in accessing current Internet services [3]. Such information IPv6 traffic internet also helps applications that do not utilize DNS but obtain IPv4 traffic DNS64 DNS traffic IPv6-only destination addresses via other means. server Based on our investigation [11], we identify two major challenges in this domain. First, how to minimize the imple- Figure 1: NAT64 and DNS64 in cellular network mentation impact on hosts and network entities. This is the key to deploy and integrate the proposed mechanism into existing networks. Second, how to enable security. The solution should The NAT64/DNS64 system works very well when app- provide means for ensuring that NAT64 prefix detection is not lications on IPv6-only connected hosts use only DNS to compromised. To assist analysis, we divide existing solutions resolve domain names for IPv6 addresses in their communi- into five categories: cations and the hosts do not implement validating DNSSEC- capable resolvers [9]. Applications that need to create connec- • Solutions independent of existing deployed technologies. tions using IPv4 address literals face obvious problems when • Application layer solutions. the node has IPv6-only connectivity. Furthermore, DNSSEC- • Network layer solutions. capable validating resolvers cannot successfully validate syn- • Link layer solutions relying on access technology assets. thetic IPv6 addresses received from DNS64 [8]. • Out-of-band solutions relying on manual configuration.

2 B. Technology Independent Solutions Another application layer solution is to utilize application layer signaling protocols such as Session Traversal Utilities for A solution using heuristic methods [13] was designed when NAT (STUN) [19]. With STUN, a host first needs to resolve it became evident that it may be impossible to have all access the synthetic IPv6 address of the target STUN server residing networks with NAT64 to explicitly provide prefix information in the IPv4 Internet. After learning the synthetic IPv6 address required for IPv6 address synthesis. The solution is simple: a of the STUN server, a STUN client on the host sends a request node shall make an AAAA record DNS query against a well- to the STUN server with a new SENDING-TO attribute that known name (such as ipv4only.arpa or any other domain name tells the server the IPv6 destination address the client sent with required properties of top level domain high availability the request to. The server responds with another new attribute and existence in foreseen future) that the node knows not to RECEIVED-AS containing server’s IPv4 address the request have any IPv6 addresses. Hence, any IPv6 address received in arrived at. By comparing the addresses in SENDING-TO a DNS response reveals there is a DNS64 in the network. and RECEIVED-AS, the host can derive the NAT64 prefix The IPv6 prefix and the synthetic address format used by information. the DNS64 and the NAT64 is discovered by searching for an IPv4 address of the well-known name inside the received D. Network Layer Solutions IPv6 address. The location of IPv4 address determines the used address format [14] and what is the prefix used by the At the network layer, two DHCP based mechanisms access network. The learned prefix and address format is then are proposed to hook the discovery and learning pro- used for local IPv6 address synthesis. As the learned prefix cess into general IP configuration phase [18], [20]. The OPTION_AFT_PREFIX_DHCP and format are cached by the node, the time-to-live (TTL) option proposed in [18] con- value of AAAA synthetic record determines how often a node tains necessary information to derive NAT64 prefix, including needs to repeat the heuristic discovery to update the cached the IPv6 prefix, IPv6 any-source prefix, information. source-specific multicast prefix, and their lengths. Another option described in [20] provides similar information for hosts C. Application Layer Solutions to allow them synthesize IPv6 addresses that can be routed through NAT64. At the application layer, a new EDNS0 option serving as A new advertisement (RA) option defined as an implicit indication of NAT64/DNS64 presence has been OPTION_AFT_PREFIX_RA is proposed in [21] to convey proposed [15]. Three are defined in the option to convey information similar to the DHCP based solution, including the prefix length used for IPv6 synthesis. In this solution, both IPv6 unicast prefix, IPv6 any-source multicast prefix, source- hosts and DNS64 servers need to understand the new option. specific multicast prefix, and the length of prefixes for NAT64. Upon receiving valid requests from hosts, only DNS64 servers are able to insert the EDNS0 option with the required bits into E. Link Layer Solutions the synthesized AAAA Resource Record. Many access technologies allow configuration information In the version -00 of [15], a similar solution was proposed to be delivered during link layer establishment phase, such as to add three bits into the EDNS0 OPT header [16] to notify 3GPP Non-Access-Stratum (NAS) signaling protocol [22]. It the prefix length used for synthesis as an implicit indication is possible to utilize such signaling to deliver and negotiate of NAT64/DNS64 presence. This solution also required hosts parameters including all NSPs with their respective prefix and DNS64 servers to understand the new flag bits contained length via generic protocol configuration options. The lack in EDNS0 OPT header. of such options would be treated as implicit indication that no Based on DNS, a new Resource Record (RR), A64, is NAT64 is deployed in the access network. proposed in [17] to store a synthetic IPv6 address. The dedicated A64 record allows hosts to distinguish between real F. Out-of-Band Solutions IPv6 addresses and synthetic IPv6 addresses. To obtain A64 For the final category of possible solutions the information record, hosts need to send a query asking for the new record. needed for the IPv6 address synthesis is delivered via some Positive response from DNS indicates that the resolved address other means than over the node’s Internet connection. This is synthesized rather than native IPv6 address. may include, for example, manual configuration of nodes, Two DNS based mechanisms are proposed in [18] to usage of some provisioning tools such as the Access Network discover the presence of NAT64 and learn the NAT64 prefix. Discovery and Selection Function (ANDSF) [23], or any other The first mechanism utilizes a TXT based Resource Record protocol designed for network administration purposes. to convey a predefined string containing the NAT64 unicast IPv6 address and its prefix length. The second mechanism IV. SYSTEMATIC EVALUATION AND DISCUSSIONS relies on a new U-NAPTR application to conduct U-NAPTR A. Evaluation Metrics and Solution Classification query similar to reverse DNS query. The domain name used in U-NAPTR query is derived from host’s IPv6 address in the In order to compare and evaluate existing solutions, we ".ip6.arpa." tree and response to a successful query contains identify and define eight evaluation metrics. the unicast IPv6 address and the prefix length of the NAT64. 1) Active detection - hosts purposely try to detect NAT64.

3 Table I: Comparison Table for NAT64 Prefix Learning Solutions Active Explicit via Adaptation Multiple NSP Without DNS Transparent Host system Secure Solution detection configuration to changes support protocol to network changes learning Heuristic discovery Yes No Moderate Yes No No if DNSSEC No With DNSSEC EDNS0 option/OPT flags Yes No Fast Yes No No Yes No DNS A64 RR Yes No Fast Yes No No Yes No STUN Yes No Moderate No Possible No No No DNS TXT/U-NAPTR RR Yes No Fast Yes No No No No DHCPv6 No Yes Moderate Yes Yes No Yes No RA No Yes Fast Yes Yes No Yes No L2 No Yes Undefined Yes Yes No Yes With secure L2 Out-of-Band No Yes Undefined Yes Yes Possible No Possible

2) Explicit via configuration - hosts learn prefix passively Due to the restriction of relying on STUN functionality, only as part of the host configuration procedure. the STUN approach is not able to support multiple NSPs in the 3) Capability to adapt to dynamic changes of NSP. access network, while other solutions provide such support. 4) Support for multiple NSPs. For DNS protocol independence, all DNS related solutions 5) Independent of DNS protocol support on hosts. are inherently excluded. Meanwhile, DHCP, RA, link layer, 6) Transparent to existing services and network entities. and out-of-band solutions are able to function without DNS 7) Requiring changes to services/kernel. protocol support. For STUN, it is possible that a host can 8) Secure learning of NAT64 prefix. learn the IPv6 presentation for the STUN server’s IPv4 address without using DNS, e.g. by using DHCPv6. It is hence As our focus is on deployability, we selected the metrics identified as possible. that cover the essential aspects of this domain, including Concerning transparency to network entities, all solutions functionality, transparency, and deployment impact. Table I introduce modifications to existing entities in the network, summarizes the existing solutions against our evaluation met- except the heuristic discovery and out-of-band solution. The rics. heuristic discovery is a transparent procedure for the access The active detection is enabled in heuristic discovery and network, except when it is protected via DNSSEC. To enable all application layer solutions since hosts are able to ini- DNSSEC protection for the heuristic discovery, administrator tiate the NAT64 detection on demand by calling necessary of a NAT64 entity needs to allocate a fully qualified domain function or application. Meanwhile, network layer solutions, name for the NAT64 and also maintain a set of related PTR link layer solutions, and out-of-band solutions rely on the and DNSSEC signed AAAA records. A host then uses these network-generated information passively obtained from the DNS records to protect the heuristic discovery procedures, access network during host configuration. Such solutions are but becomes dependent on network support. The out-of-band identified as explicit via configuration. mechanisms may be transparent to the network from the Regarding to dynamic adaptation to the change of NSP, suite point of view, but obviously do require the analyzed solutions differ on how fast they can adapt to deployment and management of the out-of-band mechanisms possible changes in the NAT64 prefix. In the cases where themselves. the NAT64 prefix detection is based on reception of IPv6 Changes to a host system are inevitable for EDNS0 and prefix information from DNS, a solution must repeat the DNS A64 because the resolver functionality on the host need detection at latest when the received DNS record’s time to to be modified to support the new proposals. DHCPv6, RA, live (TTL) expires. If the solution repeats the detection only and link layer solutions also introduce modifications on the when the TTL is about to expire, we call the rate of adaptation hosts to enable NAT64 discovery and prefix learning. Since moderate. The heuristic discovery, STUN, DHCPv6-based heuristic discovery, STUN, and DNS TXT solutions can utilize solution are included in the moderate category, as the received the existing services on hosts to acquire necessary information information can be associated with a lifetime. Some of the with the support from network side, they do not require host solutions are able to adapt to possible changes in the NAT64 modifications. The out-of-band mechanisms are likely to be prefix faster than the timeout triggered moderate solutions. We implemented at the application layer and hence would not categorize these as fast. The fast solutions include RA-based necessitate host system changes. approach where the network can trigger the NAT64 prefix The secure discovery of a NAT64 prefix is challenging for detection simply by sending a new RA. We also consider the all solutions. The heuristic discovery includes an algorithm EDNS0 and DNS-based solutions fast, as in those cases the that could ensure secure prefix discovery but requires use of host will discover new NAT64 prefix at the moment it receives DNSSEC on a host and signed FQDNs for NAT64 entities synthetic DNS reply to any IPv6 DNS query. For link layer [13]. Furthermore, the algorithm is still subject to changes. and out-of-band solutions, as currently they are speculative The link layer solutions are likely to be able to provide truly approaches without clear defined proposals, we identify them secure discovery assuming the link layer itself is secured. For as undefined. out-of-band solutions secure discovery is also an option.

4 B. Evaluation of Solutions in specific deployment scenarios, but not in the general case. For example, manual configuration does not scale, ANDSF Concerning each solution category, the heuristic discovery is essentially used only for 3GPP deployment scenarios and can be deployed without explicit support by a host or network. hence would not be enough for general purpose nodes, and Hosts interested in learning IPv6 synthesis can proactively special protocols used for network administration would help do the "discovery" at any time. Although the solution is applications only when applications are actually executed in dependent on DNS protocol, it offers moderate adaptation to nodes that support such special protocols and that are under NSP changes and supports multiple NSPs. With the advantage the network administration services. of secure discovery, this solution can be used also as a fall- back mechanism when explicit methods such as EDNS0 and C. Recommendation and Discussions DNS A64 are not supported in the access network. Guided by the principle of minimizing impact on both host Among the application layer solutions, all DNS based and network sides, we recommend the heuristic discovery proposals (EDNS0 OPT flags, EDNS0 option, A64 RR, and solution for its ease of deployment. For IETF standardization, TXT/U-NAPT RR) are light weight in general but suffer the main argument to favor it over other solutions, especially from limitations. For instance, A64 Resource Record lacks the EDNS0 option, is that people will implement and deploy the capability to learn NAT64 prefix for synthesis. The main similar solution in any case. Therefore, having a common concern against such solutions are two fold. First, there are standardized solution is for common benefit. At the same time, already deployed DNS64 implementations without support we are aware of that standardizing a well-known domain name for such solutions, which will cause backward compatibility has a particular operational concern. For instance, who is going issues. Second, changes are required on the host side DNS to operate the infrastructure for the well-known domain name? resolvers. While this is not the case in all situations, the need A domain name server hosting the well-known domain name for possible resolver library or API modifications is strong has practically similar availability requirements as root or enough reason to favor other solutions over the DNS based top level domain name servers. Furthermore, the well-known methods. Furthermore, having all DNS64 servers to support domain name has to be operational for unforeseen number explicit WKP/NSP discovery (ENDS0, A64, and DNS based of years to come. These are not trivial issues especially for approaches) is difficult to arrange. The STUN solution also a non-profit service. Basically the only viable solution is to involves changes and management of network entities that are host the well-known domain name under the IANA managed not part of NAT64/DNS64 deployment. name space, which is used for other Internet wide basic For network layer solutions, both DHCPv6 and RA are infrastructure operations, i.e., under the .arpa domain. In efficient in that they are hooked to general IP configuration addition, all proactive NAT64 prefix determination proposals phase without involving DNS. Both solutions allow easy including our EDNS0 solution can benefit from such well- updates when configuration information changes. However, known domain name. both solutions introduce changes to both host IP stack and net- Multi-homing is a general problem when multiple work components, which is generally unfavored. The DHCPv6 NAT64/DNS64 boxes are deployed on different access net- approach requires that the NAT64, DHCPv6, and possibly works. As stated in [24] the synthesized AAAA record is even DNS64 servers are all synchronized. While DHCPv6 guaranteed to be valid only on the network from which the utilizes centralized management model, RA based solution is knowledge is learned. Nodes with multiple interfaces should expensive in operation as configuration need to be placed and distinguish the learned information from different networks to maintained on all access routers. Furthermore, both DHCPv6 avoid potential conflict and connection failure. and RA involve entities that do not necessarily need to be aware of NAT64 operations. Changes to DHCP and Neighbor V. HEURISTIC DISCOVERY AND EDNS0 Discovery protocols demand extra standardization efforts. A. Protocol Implementations What becomes to link layer solutions, in theory it would be We implemented both EDNS0 [15] and heuristic [13] based possible to define access technology specific methods to pass NAT64 discovery and NAT64 prefix determination methods. on information required for local IPv6 address synthesis. This For the implementation we took two approaches. First one is a approach, however, would come with several disadvantages, standalone solution (a ping64 network diagnostic tool) that such as standards changes required for all access technologies, implements both EDNS0 and heuristic discovery within the upgrades needed to entities involved in the link layer estab- application but leaves the DNS resolver untouched. Second lishment procedures, configuration of information required for one is a modification to glibc and its getaddrinfo() IPv6 address synthesis to all access routers and gateways, DNS resolver function. For the EDNS0 solution to work, and also host changes for passing information from the link we also modified Ecdysis’ open-source implementation of layer to a higher layer. Due to these complex dependencies a BIND9 based DNS64 [25] on to understand our and required changes, the link layer based approaches are ENDS0 additions. The client side of standalone solution is considered to be out of question. implemented on Mac OS X 10.6 Snow Leopard and the The out-of-band solutions, which currently are undefined ac- integrated solution is implemented on Ubuntu 10.04 with cording to authors’ knowledge, could in theory work very well Linux kernel 2.6.32 and glibc-2.13 for resolver function.

5 The EDNS0 approach required a definition of a new EDNS0 ’suffix’ fields are set to zero as per standard. option to inform the end host that IPv6 address synthesis took place and convey the NAT64 prefix length information. The Step A) 127.127.127.127 option is shown in Fig. 2. 2001:0bd8:0000:0000:007f:7f7f:7fab:cdef

+0 (MSB) +1 (LSB) 0 64 72 104 128 0 8 15 Prefix (64) u(8) IPv4 address (32) Suffix (24) OPTION-CODE (tbd) OPTION-LENGTH (2) Reserved Prefix: 2001:0db8:0000:0000 (network specific NAT64 prefix) SY u: 0 IPv4 address: 127.127.127.127 (the well-known address) SY = 000 reserved Suffix: 0xabcdef Step B) SY = 001 prefix length /32 192.0.2.1 SY = 010 prefix length /40 0 64 72 104 128 SY = 011 prefix length /48 SY = 100 prefix length /56 2001:0db8:0000:0000 0x0 IPv4 address (32) 0x00 SY = 101 prefix length /64 SY = 110 prefix length /96 SY = 111 address is not synthesized 2001:0bd8:0000:0000:00c0:0002:0100:0000

Figure 2: EDNS0 option for NAT64 prefix determination Figure 3: NAT64 prefix determination and IPv6 address syn- thesis. IP numbering is for exemple purposes only. The host indicates support for the feature by including the EDNS0 option into the DNS query. The absence of the EDNS0 The ping64 program allows us to test NAT64 and prefix option in the reply means that either no synthesis takes place determination. It also supports pinging IPv4 destinations from or the DNS64 entity does not support the feature. Either way, IPv6-only networks using IPv4 literal destinations (such as when the EDNS0 option is missing, the host cannot conclude 192.0.2.1). In this case the program first issues a DNS query for certain whether the AAAA response is synthetic or not. using the standard libresolv4 API for the known IPv4- Our patched DNS64 server includes the EDNS0 option with only FQDN. If the DNS reply includes an EDNS0 option prefix length information in the DNS response when address with the prefix length information, it is used for learning the synthesis takes place and the host indicates support for the NAT64 prefix and for subsequent IPv6 address synthesis. If the EDNS0 feature. With the prefix length information the host DNS64 server does not support EDNS0, ping64 employs the can easily extract the NAT64 prefix out of the synthetic IPv6 heuristic algorithm and uses the known pattern to learn address. the NAT64 prefix as illustrated in Fig. 3. For the heuristic discovery, we configured a fully qualified For sake of completeness, we also implemented domain name (FQDN) with an A record only into a DNS a backward compatible patch to the glibc and its server under our management. Step A in Fig. 3 illustrates getaddrinfo() DNS resolver function. The application how NAT64 prefix is learned out of a received synthetic IPv6 calling the getaddrinfo() function for a name address. The step B shows how the learned information is resolution would eventually receive the SY bits in struct used to construct a synthetic IPv6 address. Before receiving addrinfo.ai_flags for each returned IPv6 address. the synthetic IPv6 address from DNS64, the node has learned The patched glibc practically implemented equivalent with DNS A record query or by static configuration the functionality as the ping64 but within the host wide well-known name’s IPv4 address (e.g., 127.127.127.127). The (dynamically linked) library, thus making it implicitly node learns the network is performing IPv6 address synthesis available for all applications linking against glibc. when the node receives an IPv6 address, in this example Naturally, an arbitrary application has to know how to make 2001:db8::7f:7f7f:7fab:cdef, to AAAA record DNS query for use of the extended getaddrinfo() functionality. the well-known IPv4-only name. The node searches for the In addition, we implemented an AI_POLICYTABLE hint IPv4 address inside the received synthetic IPv6 address, and flag in the getaddrinfo() for application to express its in this example the IPv4 address can be found encoded into willingness to generally prefer native IPv4 connectivity over bits 72-103. The location of the IPv4 address indicates that the IPv6 connectivity through NAT64. This is important when a NAT64 prefix is 64-bits. Therefore, the node extracts the first dual-stack host in a dual-stack access network would receive 64 bits of the IPv6 address to be used as the NAT64 prefix. both A and synthetic AAAA records for the queried FQDN. If As per [14] the ’u’ and ’suffix’ fields should have been set to the application sets the AI_POLICYTABLE hint upon (any) zero by DNS64, and hence by the current standards the node name resolution request, then the patched getaddrinfo() cannot do anything but initialize these to zero during local would modify the default address selection policy table [26] so IPv6 address synthesis. In the future when some meaning for that IPv4-mapped IPv6 addresses are preferred over synthetic ’u’ and ’suffix’ fields is possibly defined the node doing the IPv6 addresses, thus making the host select IPv4 transport over local synthesis will need to be adjusted as well. Fig. 3 step IPv6 through a NAT64. B shows the result of local synthesis of an IPv6 address that maps to the IPv4 address of 192.0.2.1 and how the ’u’ and 4Standard libresolv originates from BIND distribution.

6 B. Implementation Experience [3] J. Arkko and A. Keränen, “Experiences from an IPv6-Only Network,” IETF, Internet Draft draft-arkko--only-experience-04, October 2011, In our implementation the EDNS0 option on the host work in progress. resolver side (at the application level including DNS query and [4] M. Leber, “Global IPv6 Deployment Progress Report, reply processing) is around 130 lines of uncommented C-code http://bgp.he.net/ipv6-progress-report.cgi.” [Online]. Available: http: //bgp.he.net/ipv6-progress-report.cgi and on the DNS64 server side the patch is of much less code. [5] D. Geer, “To Boost Adoption, IPv6 Proponents Back Once-Shunned Implementation was straightforward. The glibc approach Technology,” in IEEE Technology News, 2008. with a policy table modifications required a considerable effort [6] M. Shin et al., “An Empirical Analysis of IPv6 Transition Mechanisms,” in Proc. of ICACT 2006. and a number of code changes. This is mainly due to the [7] M. Bagnulo, P. Matthews, and I. van Beijnum, “Stateful NAT64: complexity of the glibc integration and additional communi- Network Address and Protocol Translation from IPv6 Clients to IPv4 cation into the kernel space for policy table modifications. On Servers,” Internet RFCs, ISSN 2070-1721, RFC 6146, April 2011. [8] M. Bagnulo, A. Sullivan, P. Matthews, and I. van Beijnum, “DNS64: the other hand, the heuristic-based solution is straightforward DNS Extensions for Network Address Translation from IPv6 Clients to to implement requiring less than 100 lines of uncommented IPv4 Servers,” Internet RFCs, ISSN 2070-1721, RFC 6147, April 2011. C-code. [9] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “DNS Security Introduction and Requirements,” Internet RFCs, ISSN 2070- Based on our feasibility tests in operator networks, the 1721, RFC 4033, March 2005. immediate benefit of the heuristic-based solution over the [10] F. Baker, X. Li, C. Bao, and K. Yin, “Framework for IPv4/IPv6 EDNS0-based solution is its independence of both resolver Translation,” Internet RFCs, ISSN 2070-1721, RFC 6144, April 2011. [11] J. Korhonen and T. Savolainen, “Analysis of solution proposals for hosts and DNS64 modifications. The scalability and interoperabil- to learn NAT64 prefix,” IETF, Internet Draft draft-ietf-behave-- ity are the main challenges for solutions with impact on learn-analysis-02, December 2011, work in progress. both hosts and network entities. For instance, the EDNS0 [12] 3GPP, “TS23.975, IPv6 migration guidelines, http://www.3gpp.org/ftp/Specs/html-info/23975.htm,” June 2011. solution is tightly coupled with the existing deployment in [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/23853.htm terms of selected DNS64/NAT64 software. Even though an [13] T. Savolainen, J. Korhonen, and D. Wing, “Discovery of a Network- implementation should strictly follow the protocol standard, Specific NAT64 Prefix using a Well-Known Name,” IETF, Internet Draft draft-ietf-behave-nat64-discovery-heuristic-05, January 2012, work in a DNS resolver for one system setup may encounter troubles progress. in communicating with other DNS64 servers if they exhibit [14] C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, and M. Li, “IPv6 vendor specific features, e.g., for optimization purposes. The Addressing of IPv4/IPv6 Translators,” Internet RFCs, ISSN 2070-1721, RFC 6052, October 2010. advantage of the heuristic discovery becomes dominant in this [15] J. Korhonen and T. Savolainen, “EDNS0 Option for Indicating AAAA respect due to its minimal impact on external components. Record Synthesis and Format,” IETF, Internet Draft draft-korhonen- edns0-synthesis-flag-02, February 2011, work in progress. VI.CONCLUSIONSAND FUTURE WORK [16] P. Vixie, “Extension Mechanisms for DNS (EDNS0),” Internet RFCs, ISSN 2070-1721, RFC 2671, August 1999. Our work provides an empirical basis for evaluating in- [17] M. Boucadair and E. Burgey, “A64: DNS Resource Record for IPv4- centives and coordination issues surrounding the existing and Embedded IPv6 Address,” IETF, Internet Draft draft-boucadair-behave- dns-a64-02, September 2011, work in progress. upcoming NAT implementation strategies to speed up the tran- [18] D. Wing, “Learning the IPv6 Prefix of a Network’s IPv6/IPv4 Trans- sition from IPv4 to IPv6. According to our best knowledge, we lator,” IETF, Internet Draft draft-wing-behave-learn-prefix-04, October are the first to provide an extensive and systematic evaluation 2009, work in progress. [19] J. Rosenberg et al., “Session Traversal Utilities for NAT (STUN),” of all known proposals in this domain. The impact of our work Internet RFCs, ISSN 2070-1721, RFC 5389, October 2008. is reflected in the adoption of heuristic discovery method by [20] M. Boucadair et al., “Dynamic Host Configuration Protocol (DHCPv6) IETF as the main track of development. Our implementation Options for Shared IP Addresses Solutions,” IETF, Internet Draft draft- boucadair--shared-address-option-01, December 2009, work in also offers a first-hand experience in real networks, revealing progress. potential pitfalls and assisting in understanding of what should [21] D. Wing, X. Wang, and X. Xu, “Learning the IPv6 Prefix of a Network’s be taken into account in protocol design in the transition phase. IPv6/IPv4 Translator,” IETF, Internet Draft draft-wing-behave-learn- prefix-03, July 2009, work in progress. In the future we intend to investigate the security aspects of [22] “Non-Access-Stratum (NAS) protocol for Evolved Packet System the recommended solution. (EPS),” 3GPP, TS 24.301 8.8.0, December 2008. [23] “TS24.302, Access to the 3GPP Evolved Packet Core (EPC) ACKNOWLEDGEMENT via non-3GPP access networks, http://www.3gpp.org/ftp/Specs/html- info/24302.htm,” 3GPP, TS24.302. This work has been carried out in the WiBrA project by [24] M. Blanchet and P. Seite, “Multiple Interfaces and Provisioning Do- University of Helsinki, Nokia, Nokia Siemens Networks, and mains Problem Statement,” Internet RFCs, ISSN 2070-1721, RFC 6418, November 2011. TeliaSonera, funded in part by TEKES Finland. We also [25] Viagenie, “Ecdysis: open-source implementation of NAT64 and DNS64, would like to thank Aki Nyrhinen and Ilpo Järvinen for their http://ecdysis.viagenie.ca/.” [Online]. Available: http://ecdysis.viagenie. implementation support. ca/ [26] R. Draves, “Default Address Selection for Internet Protocol version 6 (IPv6),” Internet RFCs, ISSN 2070-1721, RFC 3484, February 2003. REFERENCES [1] K. Claffy, “Tracking IPv6 evolution: Data We Have and Data We Need,” ACM SIGCOMM Computer Communication Review, vol. 41, no. 3, 2011. [2] A. Keränen and J. Arkko, “Some Measurements on World IPv6 Day from End-User Perspective,” IETF, Internet Draft draft-keranen-ipv6day- measurements-01, July 2011, work in progress.

7