diff options
Diffstat (limited to 'doc/rfc/rfc6586.txt')
| -rw-r--r-- | doc/rfc/rfc6586.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc6586.txt b/doc/rfc/rfc6586.txt new file mode 100644 index 0000000..3a48b22 --- /dev/null +++ b/doc/rfc/rfc6586.txt @@ -0,0 +1,1179 @@ + + + + + + +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 + + +Copyright Notice + + Copyright (c) 2012 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. + +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 ................................11 + 5.4. Gaming ....................................................12 + 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 .......15 + 7. Future Work ....................................................15 + 8. Conclusions and Recommendations ................................16 + 9. Security Considerations ........................................18 + 10. References ....................................................19 + 10.1. Normative References .....................................19 + 10.2. Informative References ...................................19 + Appendix A. Acknowledgments .......................................21 + + + + + + + + + + +Arkko & Keranen Informational [Page 2] + +RFC 6586 IPv6-Only Experiences April 2012 + + +1. Introduction + + 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. This arrangement has been done with + a permanent change in mind rather than as a temporary experiment, + involves both office and home users, heterogeneous computing + equipment, and varied applications. We have learned both practical + details, roadblocks and opportunities, as well as a more general + understanding of when such a configuration can be recommended and + what should be taken into account in the network design. Note that + this memo documents our experiences primarily from 2010. As time + goes by, the situation changes with updated software versions, newer + products, and so on. + + The networks involved in this setup have been in dual-stack mode for + a considerable amount of time, in one case, for over ten years. Our + IPv6 connectivity is stable and in constant use with no significant + problems. Given that the IETF is working on technology such as NAT64 + [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 + + In this document, the following terms are used. "NAT44" refers to + any IPv4-to-IPv4 network address translation algorithm, both "Basic + NAT" and "Network Address/Port Translator (NAPT)", as defined by + [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 + + We have tested IPv6-only networking in two different network + environments: office and home. In both environments, all hosts had + normal dual-stack native IPv4 and IPv6 Internet access already in + place. The networks were also already employing IPv6 in their + servers and DNS records. Similarly, the network was a part of + whitelisting arrangement to ensure that IPv6-capable content + providers would be able to serve their content to the network over + IPv6. + + The office environment has heterogeneous hardware with PCs, laptops, + and routers running Linux, BSD, Mac OS X, and Microsoft Windows + operating systems. Common uses of the network include email, Secure + Shell (SSH), web browsing, and various instant messaging and Voice + over IP (VoIP) applications. The hardware in the home environment + consists of PCs, laptops, and a number of server, camera, and sensor + appliances. The primary operating systems in this environment are + Linux and Microsoft Windows operating systems. Common applications + include web browsing, streaming, instant messaging and VoIP + applications, gaming, file storage, and various home control + applications. Both environments employ extensive firewalling + practices, and filtering is applied for both IPv4 and IPv6 traffic. + However, firewall capabilities, especially with older versions of + firewall software, dictate some differences between the filtering + applied for IPv4 and IPv6 since some features commonly supported for + IPv4 were not yet implemented for IPv6. In addition, in the home + environment, the individual devices are directly accessible from the + Internet on IPv6 (on select protocols such as SSH) but not on IPv4 + due to lack of available public IPv4 addresses. + + + + + + +Arkko & Keranen Informational [Page 4] + +RFC 6586 IPv6-Only Experiences April 2012 + + + In both environments, volunteers had the possibility to opt-in for + the IPv6-only network. The number of users was small: there were + roughly five permanent users and a dozen users who had 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 + + The IPv6-only network was provided as a parallel network on the side + of the already existing dual-stack network. It was important to + retain the dual-stack network for the benefit of those users who did + not decide to opt-in and because we knew that there were some IPv4- + only devices in the network. A separate wired access network was + created using Virtual Local Area Networks (VLANs). This network had + its own IPv6 prefix. A separate wireless network, bridged to the + wired network, was also created. In our case, the new wireless + network required additional access point hardware in order to + accommodate advertising multiple wireless networks. The simple + access point model that we employed in these networks did not allow + this on a single device, although many other access points support + this. All the secondary infrastructure resulted in some additional + management burden and cost, however. An added complexity was that + the home network already employed two types of infrastructure, one + for family members and another one for visitors. In order to + duplicate this model for the IPv6-only network, there are now four + separate networks, with several access points on each. + + A stateful NAT64 [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 + + + 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. + + Setting up NAT64 and DNS64 by themselves is easy and can be done + quickly by an experienced network manager. However, when duplicate + infrastructure is needed for dual-stack and IPv6-only networks, the + additional switches, cables, access points, etc., will take some + amount of installation effort. In addition, if whitelisting + agreements or IPv6 ISP connectivity is needed, setting these up + requires negotiations with external partners. + +3.2. DNS Operation + + Router Advertisements are used to carry DNS Configuration options + [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 + + + 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. + + Note: This configuration may also be useful for other purposes. + For instance, one drawback of the 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 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 + + Based on our experiences, it is possible to live (and work) with an + IPv6-only network. For instance, at the time of this writing, one of + the authors has been in an IPv6-only network for about a year and a + half and has had no major problems. Most things work well in the new + + + +Arkko & Keranen Informational [Page 7] + +RFC 6586 IPv6-Only Experiences April 2012 + + + environment; for example, we have been unable to spot any practical + difference in the web browsing (HTTP and HTTPS) experience. Also, + email, software upgrades, operating system services, many chat + systems, and media streaming work well. On certain Symbian mobile + handsets that we tried, all applications work even on an IPv6-only + network. In another case, with the Android operating system, all the + basic applications worked without problems. In order to make the + latter handset architecture support IPv6-only networks, however, a + small change was needed in the operating system so that it could + discover IPv6-only DNS servers. + + However, in general, there is some pain involved and thus IPv6-only + networking is not suitable for everyone just yet. Switching IPv4 off + does break many things as well. Some of the users in our environment + left due to these issues, as they missed some key feature that they + 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 a couple of times during real-life web browsing. + + + +Arkko & Keranen Informational [Page 8] + +RFC 6586 IPv6-Only Experiences April 2012 + + + 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 + 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 also not been + available to the authors in the IPv4 Internet for a number of years. + + It should be noted that the experience with a properly configured set + of ALGs and workarounds 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 + + The overall experience was as explained above. The remainder of this + section discusses specific issues with different operating systems, + programming languages, applications, and appliances. + +5.1. Operating Systems + + Even operating systems have some minor problems with IPv6. For + example, in Linux, Router Advertisement (RA) information is not + automatically updated when the network changes while the computer is + on, and this requires an unnecessary suspend/resume cycle to restore + its proper state. We have also had issues with the rdnssd daemon, + which first does not come as a default feature in Ubuntu and does not + always appear to work reliably. To resolve these issues, we had to + configure the network manager to use a specific server address. + Later, a new version of the Linux distribution that we used solved + these problems, even if some problems still remained. For instance, + in the latest Ubuntu Long-Term Support release (10.04), we have + experienced that the network manager by default returns to an + + + +Arkko & Keranen Informational [Page 9] + +RFC 6586 IPv6-Only Experiences April 2012 + + + available IPv4 wireless network even if there is a previously used + IPv6-only network available and the IPv4 network has no global + connectivity before a web-based login is completed. + + In Mac OS X (Snow Leopard), the network manager needed to be + explicitly told not to expect IPv4. A more annoying issue was that + in order to switch between an IPv6-only and IPv4-only network, these + settings had to be manually changed, making it undesirable for Mac OS + X users to employ IPv6-only networks. + + Also, on Microsoft Windows 7, we experienced problems when relying on + default, well-known DNS server addresses: without manual + configuration, the host was unable to use the DNS addresses, even + 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 well now, 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 + already supported IPv6 for a number of years, these kinds 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 + + For applications to be able to support IPv6, they need access to the + necessary APIs. Luckily, IPv6 seems to be well supported by a + majority of the commonly used APIs. The Perl programming language + used to be an exception with only partial IPv6 support up to the + version 5.14 (released May 14, 2011). This version finally includes + full IPv6 support, with that in the core libraries and older modules + being updated as well. With previous versions of Perl, while IPv6 + socket support is available as an extension module, it may not be + possible to install this module without administrative rights. This + has also resulted in other networking core libraries (such as FTP and + SMTP) not being able to fully support IPv6; thus, many existing Perl + programs using network functionality may not work properly in an + IPv6-only environment. + + + + + +Arkko & Keranen Informational [Page 10] + +RFC 6586 IPv6-Only Experiences April 2012 + + +5.3. Instant Messaging and VoIP + + By far, the biggest complaint from our group of users was that Skype + stopped working. In some environments, even Skype can be made to + work through a proxy configuration, and this was verified in our + setting but not used as a permanent solution. More generally, we + tested a number of instant messaging applications in an IPv6-only + network with NAT64; the test results can be found in Table 1. The + versions used in the tests were the latest versions available in the + summer of 2010. + + 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 + time. 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 regard to + connecting to IPv6 destinations or even IPv6 proxies. + + + + + + +Arkko & Keranen Informational [Page 11] + +RFC 6586 IPv6-Only Experiences April 2012 + + +5.4. Gaming + + Another class of applications that we tried was games. We tried both + web-based gaming and standalone gaming applications that have + "network", "Internet", or "LAN" gaming modes. The results are shown + in Table 2. + + 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 results 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 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 + + + 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. + +5.5. Music Services + + Most of the web-based music services appear to work fine, presumably + because they employ TCP and HTTP as a transport. One notable + exception is Spotify, which requires communication to specific IPv4 + addresses. A proxy configuration similar to the one we used for + Skype makes it possible to use Spotify as well. + +5.6. Appliances + + There are also problems with different appliances such as webcams. + Many of them do not support IPv6; hence, they will not work in an + IPv6-only network. Also, not all firewalls support IPv6. Or even if + they do, they may still experience issues with some aspects of IPv6 + such as fragments. + + Some of these issues are easily solved when the appliance works as a + server, such as what most webcams and our sensor gateway devices do. + We placed the appliance in the IPv4 part of the network (in this + case, in private address space), added its name to the local DNS, and + simply allowed devices from the IPv6-only network reach it through + NAT64. + +5.7. Other Differences + + One thing that becomes simplified in an IPv6-only network is source + address selection [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 + + After correcting some initial bugs and stability issues, the NAT64 + operation itself has been relatively problem-free. There have been + no unexplained DNS problems or lost sessions. With the exception of + the specific applications mentioned above and IPv4 literals, the user + + + + +Arkko & Keranen Informational [Page 13] + +RFC 6586 IPv6-Only Experiences April 2012 + + + experience has been in line with using IPv4 Internet through a NAT44 + device. These failures with the specific applications are clearly + very different from the IPv4 experience, however. + + The rest of this section discusses our measurements on specific + issues. These tests and measurements were performed during the year + 2011 and present a snapshot of the situation on that time. More up- + to-date measurement information can be found from various online + tools such as [HE-IPv6]. + +6.1. IPv4 Address Literals + + While browsing in general works, IPv4 literals embedded in the HTML + code may break some parts of the web pages when using IPv6-only + access. This happens because the DNS64 cannot synthesize AAAA + records for the literals since the addresses are not queried from the + DNS. Luckily, the IPv4 literals seem to be fairly rarely + encountered, at least so that they would be noticed, with regular web + surfing. The authors have run into this issue only few times during + the entire experiment. Only two of those cases had a practical + impact (in YouTube, some of the third-party applications for + downloading content did not work and one hotel's web page had a + literal link to its reservation system). + + We have attempted to measure the likelihood of running into an IPv4 + literal in the web. To do this, we took the top 1,000 and 10,000 web + sites from the Alexa popular web site list. With 1,000 top sites, + 0.2% needed an IPv4 literal to render all components in their top + page (e.g., images, videos, JavaScript, and Cascading Style Sheet + (CSS) files). With 10,000 top sites, this number increases to 2%. + + However, it is not clear what conclusions can be made about this. It + is often the case that there are unresolvable or inaccessible + components on a web page anyway for various reasons, and to + understand the true impact we would have to know how "important" a + given page component was. Also, we did not measure the number of + links with IPv4 literals on these pages, nor did we attempt to search + the site in any thorough manner for these literals. + + As noted, personal anecdotal evidence says that IPv4 literals are not + a big problem. But clearly, cleaning the most important parts of the + web from IPv4 literals would be useful. With tools such as the + popular web site list, some user pressure, and co-operation from the + content providers the most urgent part of the problem could hopefully + be solved as a one-time effort. While IPv4 literals still exist in + the web, using a suitable HTTP proxy (e.g., [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 + + We also compared how well the web works behind a NAT64 compared to + IPv4-only and native IPv6 access. For this purpose, we used wget to + go through the same top web site lists as described in 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 + + One important set of measurements remains for future work. It would + be useful to understand the effect of DNS64 and NAT64 on response + time and end-to-end communication delays. Some users have anecdotal + reports of slow web browsing response times, but we have been unable + to determine if this was due to the IPv6-only network mechanisms or + for some other reason. Measurements on pure DNS response times and + packet round-trip delays does not show a significant difference from + a NAT44 environment. It would be particularly interesting to measure + + + +Arkko & Keranen Informational [Page 15] + +RFC 6586 IPv6-Only Experiences April 2012 + + + delays in the context of dual-stack versus NAT64-based IPv6-only + networking. When using dual-stack, broken IPv6 connectivity can be + repaired by falling back to IPv4 use. With NAT64, this is not always + possible as discussed in 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 + + The main conclusion is that it is possible to employ IPv6-only + networking. For large classes of applications, there are no + downsides or the downsides are negligible. We have been unable to + spot any practical difference in the web browsing experience, for + instance. Additionally, IPv6 usage -- be it in dual-stack or IPv6- + only form -- comes with inherent advantages, such as enabling direct + end-to-end connectivity. In our case, we employed this by enabling + direct connectivity to devices in a home network from anywhere in the + (IPv6) Internet. There are, however, a number of issues as well, + such as lack of IPv6 support in some applications or bugs in untested + parts of the code. + + Our experience with IPv6-only networking confirms that dual stack + should still be our recommended model for general purpose networking + at this point in time. However, IPv6-only networking can be employed + by early adopters or highly controlled networks. One example of such + a controlled network is a mobile network with operator-driven + selection of handsets. For instance, on some handsets that we + tested, we were unable to see any functional difference between IPv4 + and IPv6. + + Our recommendations apply at the present time. With effort and time, + deployment barriers can be removed and IPv6-only networking becomes + applicable in all networking situations. + + Some of the improvements are already in process in the form of new + products and additional IPv6 support. For instance, we expect that + the handset market will have a much higher number of IPv6-capable + devices in the near future. However, some of the changes do not come + without the community spending additional effort. We have identified + a number of actions that should be taken to improve the state of + IPv6-only networking. These include the following: + + + + + + +Arkko & Keranen Informational [Page 16] + +RFC 6586 IPv6-Only Experiences April 2012 + + + DNS Discovery + + The state of DNS discovery continues to be one of the main + barriers for easy adoption of IPv6-only networking. Since DNS + discovery is not a problem in dual-stack networking, there has + been too little effort in testing and deploying the necessary + components. For instance, it would be useful if RA-based DNS + discovery came as a standard feature and not as an option in Linux + distributions. Our hope is that recent standardization of the RA- + based DNS discovery at the IETF will help this happen. Other + operating systems face similar issues. 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. + + Firewalls + + More work is needed to ensure that IPv6 is supported in equal + manner in various firewall products. + + Application Support + + By far, the most important action, at least for our group of + users, would be to bring some key applications (e.g., instant + messaging and VoIP applications and games) to a state where they + can be easily run on IPv6-only networks and behind a NAT64. To + facilitate this, application programmers should use IP-version- + agnostic APIs so that applications automatically use IPv4 or IPv6 + depending on what is available. In some cases, it may also be + necessary to add support for new types of ALGs. + + IPv4 Literals + + The web should be cleaned of IPv4 literals. Also, IPv4 literals + should be avoided in application protocol signaling messages. + + + + + + + +Arkko & Keranen Informational [Page 17] + +RFC 6586 IPv6-Only Experiences April 2012 + + + Measurements and Analysis + + It is also important to continue with testing, measurement, and + analysis of which Internet technologies work 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. + +9. Security Considerations + + By itself, the use of IPv6 instead of IPv4 does not make a big + security difference. The main security requirement is that, + naturally, network security devices need to be able to deal with IPv6 + in these networks. This is already required in all dual-stack + networks. As noted, it is important, e.g., to ensure firewall + capabilities. Security considerations for NAT64 and DNS64 are + discussed in [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] + +RFC 6586 IPv6-Only Experiences April 2012 + + +10. References + +10.1. Normative References + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, August 1999. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, + April 2004. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, + "IPv6 Router Advertisement Options for DNS + Configuration", RFC 6106, November 2010. + +10.2. Informative References + + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and + E. Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network + Address Translator - Protocol Translator (NAT-PT) to + Historic Status", RFC 4966, July 2007. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and + X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", + RFC 6052, October 2010. + + [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework + for IPv4/IPv6 Translation", RFC 6144, April 2011. + + + + + +Arkko & Keranen Informational [Page 19] + +RFC 6586 IPv6-Only Experiences April 2012 + + + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + Algorithm", RFC 6145, April 2011. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, + "Stateful NAT64: Network Address and Protocol + Translation from IPv6 Clients to IPv4 Servers", + RFC 6146, April 2011. + + [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van + Beijnum, "DNS64: DNS Extensions for Network Address + Translation from IPv6 Clients to IPv4 Servers", + RFC 6147, April 2011. + + [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway + (ALG) for IPv6-to-IPv4 Translation", RFC 6384, + October 2011. + + [ADD-LITERALS] Wing, D., "Coping with IP Address Literals in HTTP + URIs with IPv6/IPv4 Translators", Work in Progress, + March 2010. + + [HE-IPv6] Hurricane Electric, "Global IPv6 Deployment Progress + Report", February 2012, + <http://bgp.he.net/ipv6-progress-report.cgi>. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arkko & Keranen Informational [Page 20] + +RFC 6586 IPv6-Only Experiences April 2012 + + +Appendix A. Acknowledgments + + The authors would like to thank the many people who have engaged in + discussions around this topic, and particularly the people who were + involved in building some of the new tools used in our network, our + users who were interested in going where only few had dared to + venture before, or people who helped us in this effort. In + particular, we would like to thank Martti Kuparinen, Tero Kauppinen, + Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu + Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and + Cameron Byrne. Also, Marcelo Braun, Iljitsch van Beijnum, Miika + Komu, and Jouni Korhonen 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 Informational [Page 21] + |