Network Working Group J. Arkko Internet-Draft A. Keranen Intended status: Informational Ericsson Expires: April 30, 2012 October 28, 2011 Experiences from an IPv6-Only Network draft-arkko-ipv6-only-experience-04 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 road blocks 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 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." This Internet-Draft will expire on April 30, 2012. Copyright Notice 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 Arkko & Keranen Expires April 30, 2012 [Page 1]

Internet-Draft IPv6-Only Experiences October 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4 3. Network Setup . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 5 3.2. DNS Operation . . . . . . . . . . . . . . . . . . . . . . 6 4. General Experiences . . . . . . . . . . . . . . . . . . . . . 7 5. Experiences with IPv6-Only Networking . . . . . . . . . . . . 9 5.1. Operating Systems . . . . . . . . . . . . . . . . . . . . 9 5.2. Programming Languages and APIs . . . . . . . . . . . . . . 10 5.3. Instant Messaging and VoIP . . . . . . . . . . . . . . . . 10 5.4. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Music Services . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Appliances . . . . . . . . . . . . . . . . . . . . . . . . 13 5.7. Other Differences . . . . . . . . . . . . . . . . . . . . 13 6. Experiences with NAT64 . . . . . . . . . . . . . . . . . . . . 13 6.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 14 6.2. Comparison of Web Access via NAT64 to Other Methods . . . 14 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Conclusions and Recommendations . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Arkko & Keranen Expires April 30, 2012 [Page 2]

Internet-Draft IPv6-Only Experiences October 2011 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 and Section 8 draws conclusions and makes recommendations on when and how one should employ IPv6-only networks. Arkko & Keranen Expires April 30, 2012 [Page 3]

Internet-Draft IPv6-Only Experiences October 2011 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 Expires April 30, 2012 [Page 4]

Internet-Draft IPv6-Only Experiences October 2011 the IPv6-only network. The number of users is small: there are roughly five permanent users and a dozen users who have been in the network at least for some amount of time. Each user had to connect to the IPv6-only wired or wireless network, and depending on their software, possibly configure their computer by indicating that there is no IPv4 and/or setting DNS server addresses. The users were also asked to report their experiences back to the organizers. 3.1 . The IPv6-Only Network 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 an additional /63 of address space. This space was easily available in our networks, as IPv6 allocations are on purpose 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 increase from one block to multiple also made it necessary to employ an improved routing configuration. In addition to routing, the new prefixes have to be listed in the appropriate firewall rules. Arkko & Keranen Expires April 30, 2012 [Page 5]

Internet-Draft IPv6-Only Experiences October 2011 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 be reached via IPv6 as well. When a host served by the DNS64 asks for a domain name that does not have an AAAA (IPv6 address) record, but has an A (IPv4 address) record, an 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 network can contact the destination over IPv6. Destinations with only an A record will be given a synthesized AAAA record as explained above. However, in one of our open visitor networks that is sharing the infrastructure with the home network we needed a special arrangement. Currently, the home network obtains its IPv6 connectivity through a tunnel via the office network, and it is undesirable to allow outsiders using the visitor network to generate traffic through the office network, even if the traffic is just passing by and forwarded to the IPv6 Internet. As a result, in the visitor network there is a special IPv6-only to IPv4-only configuration where the DNS64 never asks for AAAA records and always generates synthesized records. Therefore no traffic from the visitor network, even if it is destined to the IPv6 Internet, is routed via the office network but traffic from the home network can still use the IPv6 connectivity provided by the office network. Arkko & Keranen Expires April 30, 2012 [Page 6]

Internet-Draft IPv6-Only Experiences October 2011 Note: This configuration may also be useful for other purposes. For instance, one drawback of standard behavior is that if a destination publishes AAAA records but has bad IPv6 connectivity, the hosts in the IPv6-only network have no fallback. In the dual- stack model a host can always try IPv4 if the IPv6 connection fails. In the special configuration IPv6 is only used internally at the site but never across the Internet, eliminating this problem. This is not a recommended mode of operation, but it is interesting to note that it may solve some issues. Note that in NAT64 (unlike in its older variant [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 used 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 Expires April 30, 2012 [Page 7]

Internet-Draft IPv6-Only Experiences October 2011 needed from their computing environment. These issues fall in several categories: Bugs We saw many issues that can be classified as bugs, likely related to so few people having tried the software in question in an IPv6- only network. For instance, some operating system facilities support IPv6 but have annoying problems that are only uncovered in IPv6-only networking. Lack of IPv6 Support We also saw many applications that do not support IPv6 at all. These range from minor, old tools (such as the Unix dict(1) command) to major applications that are important to our users (such as Skype) and even to entire classes of applications (many games have issues). As our experiment continued, we have seen improvements in some areas, such as gaming. Protocol, Format, and Content Problems There are many protocols that carry IP addresses in them, and using these protocols through a translator can lead to problems. In our current network setup we did not employ any ALGs except for FTP [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 couple of times during real-life web browsing. Firewall Issues We also saw a number of issues related to lack of features in IPv6 support in firewalls. In particular, while we did not experience any Maximum Transmission Unit (MTU) and fragmentation problems in our networks, there is potential for generating problems, as the support for IPv6 fragment headers is not complete in all firewalls and the NAT64 specifications call for use of the fragment header (even in situations where fragmentation has not yet occurred, e.g., if an IPv4 packet that is not a fragment does not have the Don't Fragment (DF) bit set). In general, most of the issues relate to poor testing and lack of IPv6 support in some applications. IPv6 itself and NAT64 did not Arkko & Keranen Expires April 30, 2012 [Page 8]

Internet-Draft IPv6-Only Experiences October 2011 cause any major issues for us, once our setup and NAT64 software was stable. In general, the authors feel that with the exception of some applications, our experience with translation to reach the IPv4 Internet has been equal to our past experiences with NAT44-based Internet access. While translation implies loss of end-to-end connectivity, in practice direct connectivity has not been available to the authors in the IPv4 Internet either for a number of years. It should be noted that the experience with a properly configured set of ALGs and work-arounds such as proxies may be different. Some of the problems we encountered can be solved through these means. For instance, a problematic application can be configured to use a proxy that in turn has both IPv4 and IPv6 access. 5 . Experiences with IPv6-Only Networking 5.1 . Operating Systems Arkko & Keranen Expires April 30, 2012 [Page 9]

Internet-Draft IPv6-Only Experiences October 2011 though the system displays them as current DNS server addresses. Latest versions of the Android operating system support IPv6 on its wireless LAN interface, but due to lack of DNS discovery mechanisms, this does not work in IPv6-only networks. We corrected this, however, and prototype phones in our networks work now well even in an IPv6-only environment. This change, DNS Discovery Daemon (DDD) now exists as open source software. Interestingly, all applications that we have tried so far seem to work without problems with IPv6- only connectivity, though no exhaustive testing was done, nor did we try known troublesome applications. While all these operating systems (or their predecessors) have supported IPv6 already for a number of years, these kind of small glitches seem to imply that they have not been thoroughly tested in networks lacking IPv4 connectivity. At the very least their usability leaves something to be desired. 5.2 . Programming Languages and APIs 5.3 . Instant Messaging and VoIP Arkko & Keranen Expires April 30, 2012 [Page 10]

Internet-Draft IPv6-Only Experiences October 2011 SYSTEM STATUS Facebook on the web (http) OK Facebook via a client (xmpp) OK Jabber.org chat service (xmpp) OK Gmail chat on the web (http) OK Gmail chat via a client (xmpp) OK Google Talk client NOT OK AIM (AOL) NOT OK ICQ (AOL) NOT OK Skype NOT OK MSN NOT OK Webex NOT OK Sametime OK (NOW) Table 1. Instant Messaging Applications in an IPv6-Only Network Packet tracing revealed that the issues in AIM, ICQ, and MSN appear to be related to passing literal IPv4 addresses in the protocol. It remains to be determined whether this can be solved through configuration, proxies, or ALGs. The problem with the Google Talk client is that the software does not support IPv6 connections at this moment. We are continuing our tests with additional applications, and we have also seen changes over time. For instance, a new version of Sametime suddenly started working with IPv6-only networks, presumably due to the new version being more careful with the use of DNS names as opposed to IPv4 addresses. One problem in running these tests is to ensure that we can distinguish IPv6 and NAT64 issues from other issues, such as a generic issue on a given operating system platform. Some of these problems are solvable, however. For instance, we used localhost as a proxy for Skype, and then used SSH to tunnel to an external web proxy, bypassing Skype's limitations with regards to connecting to IPv6 destinations or even IPv6 proxies. 5.4 . Gaming Arkko & Keranen Expires April 30, 2012 [Page 11]

Internet-Draft IPv6-Only Experiences October 2011 SYSTEM STATUS Web-based (e.g. armorgames) OK Runescape (on the web) NOT OK Flat out 2 NOT OK Battlefield NOT OK Secondlife NOT OK Guild Wars NOT OK Age of Empires NOT OK Star Wars: Empire at War NOT OK Crysis NOT OK Lord of the Rings: Conquest NOT OK Rome Total War NOT OK Lord of the Rings: Battle for Middle Earth 2 NOT OK Table 2. Gaming Applications in an IPv6-Only Network Most web-based games worked well, as expected from our earlier good general web experience. However, we were also able to find one web- based game that failed to work (Runescape). This particular game is a Java application that fails on an attempt to perform a HTTP GET request. The reason remains unclear, but a likely theory is the use of an IPv4-literal in the application itself. The experience with standalone games was far more discouraging. Without exception all games failed to enable either connections to ongoing games in the Internet or even LAN-based connections to other computers in the same IPv6-only LAN segment. This is somewhat surprising, and the result require further verification. Unfortunately, the games provide no diagnostics about their operation, so it is hard to guess what is going on. It is possible that their networking code employs older APIs that cannot use IPv6 addresses [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 were IPv6-capable, the situation has improved during the experiment. For instance, a popular on-line game, World of Warcraft, now has IPv6 support in its latest version and some of the older games that have been re-released as open source (e.g., Quake) have been patched IPv6-capable by the open source community. Arkko & Keranen Expires April 30, 2012 [Page 12]

Internet-Draft IPv6-Only Experiences October 2011 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 have in reality some problems. For instance, a popular short URL forwarding service has advertised a deprecated IPv4-mapped IPv6 address 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 Expires April 30, 2012 [Page 13]

Internet-Draft IPv6-Only Experiences October 2011 The rest of this section discusses our measurements on specific issues. 6.1 . IPv4 Address Literals I-D.wing-behave-http-ip-address-literals]) can help to cope with them. 6.2 . Comparison of Web Access via NAT64 to Other Methods Section 6.1, again downloading everything needed to render their front page. The Arkko & Keranen Expires April 30, 2012 [Page 14]

Internet-Draft IPv6-Only Experiences October 2011 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 Section 3.2. Arkko & Keranen Expires April 30, 2012 [Page 15]

Internet-Draft IPv6-Only Experiences October 2011 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 Expires April 30, 2012 [Page 16]

Internet-Draft IPv6-Only Experiences October 2011 distributions. Our hope is that recent standardization of the RA- based DNS discovery at the IETF will help this happen. Similar issues face other operating systems. The authors believe that at this time, prudent operational practices call for maximizing the number of offered automatic configuration mechanisms on the network side. It might be useful for an IETF document to provide guidance on operating DNS in IPv6-only networks. Network Managers Other key software components are the various network management and attachment tools in operating systems. These tools generally have the required functionality, but do not always appear to have been tested very extensively on IPv6, or let alone IPv6-only networks. Further work is required here. Application Support But by far the most important action, for at least our group of users, would be to bring some key applications (e.g., instant messaging and VoIP applications and also games) to a state where they can be easily run on IPv6-only networks and behind a NAT64. In some cases, it may also be necessary to add support for new types of ALGs. IPv4 Literals The web should be cleaned from IPv4 literals. Measurements and Analysis It is also important to continue with testing, measurements, and analysis of what Internet technology works in IPv6-only networks, to what extent, at what speed, and where the remaining problems are. Guidelines It is also useful to provide guidance for network administrators and users on how to turn on IPv6-only networking. As can be seen from the above list, there are only minor things that can be done through standardization. Most of the effort is practical and centers around improving various implementations. Arkko & Keranen Expires April 30, 2012 [Page 17]

Internet-Draft IPv6-Only Experiences October 2011 Komu have provided useful discussion and comments on the document. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Arkko & Keranen Expires April 30, 2012 [Page 20]