INFORMATIONAL

Internet Engineering Task Force (IETF) J. Arkko Request for Comments: 6586 A. Keranen Category: Informational Ericsson ISSN: 2070-1721 April 2012 Experiences from an IPv6-Only Network Abstract This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6586. Arkko & Keranen Informational [Page 1]

RFC 6586 IPv6-Only Experiences April 2012 1 . Introduction RFC6144] and several network providers are discussing the possibility of employing IPv6-only networking, we decided to take our network beyond the "comfort zone" and make sure that we understand the implications of having no IPv4 connectivity at all. This also allowed us to test a NAT64 device that is being developed by Ericsson. The main conclusion is that it is possible to employ IPv6-only networking, though there are a number of issues such as lack of IPv6 support in some applications and bugs in untested parts of code. As a result, dual-stack [RFC4213] remains as our recommended model for general purpose networking at this time, but IPv6-only networking can be employed by early adopters or highly controlled networks. The document also suggests actions to make IPv6-only networking applicable in all environments. In particular, resolving problems with a few key applications would have a significant impact for enabling IPv6-only networking for large classes of users and networks. It is important that the Internet community understands these deployment barriers and works to remove them. The rest of this document is organized as follows. Section 2 introduces some relevant technology and terms, Section 3 describes the network setup, Section 4 discusses our general experiences, Section 5 discusses experiences related to having only IPv6 networking available, and Section 6 discusses experiences related to NAT64 use. Finally, Section 7 presents some of our ideas for future work, Section 8 draws conclusions and makes recommendations on when and how one should employ IPv6-only networks, and Section 9 discusses relevant security considerations. Arkko & Keranen Informational [Page 3]

RFC 6586 IPv6-Only Experiences April 2012 2 . Technology and Terminology RFC2663]. "Dual-stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213]. "NAT64" refers to a Network Address Translator - Protocol Translator defined in [RFC6144], [RFC6145], [RFC6146], [RFC6052], [RFC6147], and [RFC6384]. 3 . Network Setup Arkko & Keranen Informational [Page 4]

RFC 6586 IPv6-Only Experiences April 2012 3.1 . The IPv6-Only Network RFC6146] with integrated DNS64 was installed on the edge of the IPv6-only networks. No IPv4 routing or Dynamic Host Configuration Protocol (DHCP) was offered on these networks. The NAT64 device sends Router Advertisements (RAs) [RFC4861] from which the hosts learn the IPv6 prefix and can automatically configure IPv6 addresses for them. Each new IPv6-only network needed one new /64 prefix to be used in these advertisements. In addition, each NAT64 device needed another /64 prefix to be used for the representation of IPv4 destinations in the IPv6-only network. As a result, one IPv6- only network requires /63 of address space. This space was easily available in our networks, as IPv6 allocations are purposefully made in sufficiently large blocks. Additional address space needs can be accommodated from the existing block without registry involvement. Another option would have been to use the Well-Known Prefix [RFC6052] for the representation of IPv4 destinations in the IPv6-only network. In any case, the prefixes have to be listed in the intra-domain routing system so that they can be reached. In one case, the Arkko & Keranen Informational [Page 5]

RFC 6586 IPv6-Only Experiences April 2012 3.2 . DNS Operation RFC6106], listing the DNS64 as the DNS server the hosts should use. In addition, aliases were added to the DNS64 device to allow it to receive packets on the well-known DNS server addresses that Windows operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0: 0:0:ffff::3). At a later stage, support for stateless DHCPv6 [RFC3736] was added. We do recommend enabling RFC 6106, well-known addresses, and stateless DHCPv6 in order to maximize the likelihood of different types of IPv6-only hosts being able to use DNS without manual configuration. DNS server discovery was never a problem in dual-stack networks, because DNS servers on the IPv4 side can easily provide IPv6 information (AAAA records) as well. With IPv6-only networking, it becomes crucial that the local DNS server can also be reached via IPv6. In principle, this is exactly the same as needing IPv4-based DNS and DNS discovery in IPv4-only networks. However, in IPv6, the discovery mechanisms are somewhat more complicated because there are several alternative techniques. When a host served by the DNS64 asks for a domain name that does not have a AAAA (IPv6 address) record, but has an A (IPv4 address) record, a AAAA record is synthesized from the A record (as defined for DNS64 in [RFC6147]) and sent in the DNS response to the host. IP packets sent to this synthesized address are routed via the NAT64, translated to IPv4 by the NAT64, and forwarded to the queried host's IPv4 address; return traffic is translated back from IPv4 to IPv6 and forwarded to the host behind the NAT64 (as described in [RFC6144]). This allows the hosts in the IPv6-only network to contact any host in the IPv4 Internet as long as the hosts in the IPv4 Internet have DNS address records. The NAT64 devices have standard dual-stack connectivity and their DNS64 function can use both IPv4 and IPv6 when requesting information from DNS. A destination that has both an A and AAAA records is not treated in any special manner, because the hosts in the IPv6-only Arkko & Keranen Informational [Page 6]

RFC 6586 IPv6-Only Experiences April 2012 RFC4966]) it is possible to decouple the packet translation, IPv6 routing, and DNS64 functions. Since clients are configured to use a DNS64 as their DNS server, there is no need for having an Application Layer Gateway (ALG) on the path sniffing and spoofing DNS packets. This decoupling possibility was implemented by one of our users, as he is outside of our physical network and wants to communicate directly on IPv6 where it is possible without having to go through our central network equipment. His DNS queries go to our DNS64 and to establish communications to an IPv4 destination our central NAT64 is used. If there is a need to translate some packets, these packets find the translator device through normal IPv6 routing means since the synthesized addresses have our NAT64's prefix. However, for non- synthesized IPv6 addresses the packets are routed directly to the destination. 4 . General Experiences Arkko & Keranen Informational [Page 7]

RFC 6586 IPv6-Only Experiences April 2012 RFC6384]. However, we have observed a number of protocol issues with IPv4 addresses. For instance, some instant messaging services do not work due to this. Finally, content on some web pages may refer to IPv4 address literals (i.e., plain IP addresses instead of host and domain names). This renders some links inaccessible in an IPv6-only network. While this problem is easily quantifiable in measurements, the authors have run into it only a couple of times during real-life web browsing. Arkko & Keranen Informational [Page 8]

RFC 6586 IPv6-Only Experiences April 2012 5.2 . Programming Languages and APIs Arkko & Keranen Informational [Page 10]

RFC 6586 IPv6-Only Experiences April 2012 5.3 . Instant Messaging and VoIP Arkko & Keranen Informational [Page 11]

RFC 6586 IPv6-Only Experiences April 2012 5.4 . Gaming RFC4038]. The inability to provide any LAN-based connectivity is even more surprising, as this must mean that they are unable to use IPv4 link local connectivity, which should have been available to the devices (IPv4 was not blocked; just that no DHCP answers were provided on IPv4). While none of the standalone games we tested in the summer of 2010 were IPv6-capable, the situation improved during the experiment. For instance, a popular online game, World of Warcraft, now has IPv6 Arkko & Keranen Informational [Page 12]

RFC 6586 IPv6-Only Experiences April 2012 5.5 . Music Services 5.6 . Appliances 5.7 . Other Differences RFC3484]. As there is no IPv4 connectivity, the host only needs to consider its IPv6 source address. For global communications, there is typically just one possible source address. Some networks that advertise IPv6 addresses in their DNS records in reality have some problems. For instance, a popular short URL forwarding service has advertised a deprecated IPv4-compatible IPv6 address [RFC4291] in its AAAA record, making it impossible for this site to be reached unless either IPv4 or NAT64 translation to an IPv4 destination is used. 6 . Experiences with NAT64 Arkko & Keranen Informational [Page 13]

RFC 6586 IPv6-Only Experiences April 2012 HE-IPv6]. 6.1 . IPv4 Address Literals ADD-LITERALS]) can help to cope with them. Arkko & Keranen Informational [Page 14]

RFC 6586 IPv6-Only Experiences April 2012 6.2 . Comparison of Web Access via NAT64 to Other Methods Section 6.1, again downloading everything needed to render their front page. The tests were repeated and average failure rate was calculated over all of the runs. Separate tests were conducted with an IPv4-only network, an IPv6-only network, and an IPv6-only network with NAT64. When accessed with the IPv4-only network, our tests show that 1.9% of the sites experienced some sort of error or failure. The failure could be that the whole site was not accessible, or just that a single image (e.g., an advertisement banner) was not loaded properly. It should also be noted that access through wget is somewhat different from a regular browser: some web sites refuse to serve content to wget, browsers typically have DNS heuristics to fill in "www." in front of a domain name where needed, and so on. In addition to missing advertisement banners, temporary routing glitches and other mistakes, these differences also help to explain the reason for the high baseline error rate in this test. It should also be noted that variations in wget configuration options produced highly different results, but we believe that the options we settled on bear closest resemblance to real-world browsing. When we tried to access the same sites with native IPv6 (without NAT64), 96% of the sites failed to load correctly. This was as expected, given that most of the Internet content is not available on IPv6. The few exceptions included, for instance, sites managed by Google. When the sites were accessed from the IPv6-only network via a NAT64 device, the failure rate increased to 2.1%. Most of these failures appear to be due to IPv4 address literals, and the increased failure rate matches that of IPv4 literal occurrence in the same set of top web sites. With the top 10,000 sites, the failure rate with NAT64 increases similarly to our test on IPv4 address literals. 7 . Future Work Arkko & Keranen Informational [Page 15]

RFC 6586 IPv6-Only Experiences April 2012 Section 3.2. Also, more programs, especially VoIP and Peer-to-Peer (P2P) applications should be tested with NAT64. In addition, tunneling and mobility protocols should be tested and especially Virtual Private Network (VPN) protocols and applications would deserve more thorough investigation. 8 . Conclusions and Recommendations Arkko & Keranen Informational [Page 16]

RFC 6586 IPv6-Only Experiences April 2012 Arkko & Keranen Informational [Page 17]

RFC 6586 IPv6-Only Experiences April 2012 9 . Security Considerations RFC6146] and [RFC6147]. In our experience, many of the critical security functions in a network end up being on the dual-stack part of the network anyway. For instance, our mail servers obviously still have to be able to communicate with both the IPv4 and IPv6 Internet, and as a result, they and the associated spam and filtering components are not in the IPv6-only part of the network. Arkko & Keranen Informational [Page 18]