idnits 2.17.1 draft-arkko-ipv6-only-experience-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft A. Keranen 4 Intended status: Informational Ericsson 5 Expires: August 10, 2012 February 7, 2012 7 Experiences from an IPv6-Only Network 8 draft-arkko-ipv6-only-experience-05 10 Abstract 12 This document discusses our experiences from moving a small number of 13 users to an IPv6-only network, with access to the IPv4-only parts of 14 the Internet via a NAT64 device. The document covers practical 15 experiences as well as road blocks and opportunities for this type of 16 a network setup. The document also makes some recommendations about 17 where such networks are applicable and what should be taken into 18 account in the network design. The document also discusses further 19 work that is needed to make IPv6-only networking applicable in all 20 environments. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 10, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4 58 3. Network Setup . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 5 60 3.2. DNS Operation . . . . . . . . . . . . . . . . . . . . . . 6 61 4. General Experiences . . . . . . . . . . . . . . . . . . . . . 7 62 5. Experiences with IPv6-Only Networking . . . . . . . . . . . . 9 63 5.1. Operating Systems . . . . . . . . . . . . . . . . . . . . 9 64 5.2. Programming Languages and APIs . . . . . . . . . . . . . . 10 65 5.3. Instant Messaging and VoIP . . . . . . . . . . . . . . . . 11 66 5.4. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.5. Music Services . . . . . . . . . . . . . . . . . . . . . . 13 68 5.6. Appliances . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.7. Other Differences . . . . . . . . . . . . . . . . . . . . 13 70 6. Experiences with NAT64 . . . . . . . . . . . . . . . . . . . . 13 71 6.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 14 72 6.2. Comparison of Web Access via NAT64 to Other Methods . . . 15 73 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8. Conclusions and Recommendations . . . . . . . . . . . . . . . 16 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 80 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 This document discusses our experiences from moving a small number of 86 users to an IPv6-only network, with access to the IPv4-only parts of 87 the Internet via a NAT64 device. This arrangement has been done with 88 a permanent change in mind rather than as a temporary experiment, 89 involves both office and home users, heterogeneous computing 90 equipment, and varied applications. We have learned both practical 91 details, road blocks and opportunities, as well as more general 92 understanding of when such a configuration can be recommended and 93 what should be taken into account in the network design. 95 The networks involved in this setup have been in dual-stack mode for 96 considerable amount of time, in one case for over ten years. Our 97 IPv6 connectivity is stable and in constant use with no significant 98 problems. Given that the IETF is working on technology such as NAT64 99 [RFC6144] and several network providers are discussing the 100 possibility of employing IPv6-only networking, we decided to take our 101 network beyond the "comfort zone" and make sure that we understand 102 the implications of having no IPv4 connectivity at all. This also 103 allowed us to test a NAT64 device that is being developed by 104 Ericsson. 106 The main conclusion is that it is possible to employ IPv6-only 107 networking, though there are a number of issues such as lack of IPv6 108 support in some applications and bugs in untested parts of code. As 109 a result, dual-stack [RFC4213] remains as our recommended model for 110 general purpose networking at this time, but IPv6-only networking can 111 be employed by early adopters or highly controlled networks. The 112 document also suggests actions to make IPv6-only networking 113 applicable in all environments. In particular, resolving problems 114 with a few key applications would have a significant impact for 115 enabling IPv6-only networking for large classes of users and 116 networks. It is important that the Internet community understands 117 these deployment barriers and works to remove them. 119 The rest of this document is organized as follows. Section 2 120 introduces some relevant technology and terms, Section 3 describes 121 the network setup, Section 4 discusses our general experiences, 122 Section 5 discusses experiences related to having only IPv6 123 networking available, and Section 6 discusses experiences related to 124 NAT64 use. Finally, Section 7 presents some of our ideas for future 125 work, Section 8 draws conclusions and makes recommendations on when 126 and how one should employ IPv6-only networks, and Section 9 discusses 127 relevant security considerations. 129 2. Technology and Terminology 131 In this document, the following terms are used. "NAT44" refers to 132 any IPv4-to-IPv4 network address translation algorithm, both "Basic 133 NAT" and "Network Address/Port Translator (NAPT)", as defined by 134 [RFC2663]. 136 "Dual-Stack" refers to a technique for providing complete support for 137 both Internet protocols -- IPv4 and IPv6 -- in hosts and routers 138 [RFC4213]. 140 "NAT64" refers to a Network Address Translator - Protocol Translator 141 defined in [RFC6144], [RFC6145], [RFC6146], [RFC6052], [RFC6147], and 142 [RFC6384]. 144 3. Network Setup 146 We have tested IPv6-only networking in two different network 147 environments: office and home. In both environments all hosts had 148 normal dual-stack native IPv4 and IPv6 Internet access already in 149 place. The networks were also already employing IPv6 in their 150 servers and DNS records. Similarly, the network was a part of 151 whitelisting arrangement to ensure that IPv6-capable content 152 providers would be able to serve their content to the network over 153 IPv6. 155 The office environment has heterogeneous hardware with PCs, laptops, 156 and routers running Linux, BSD, Mac OS X, and Microsoft Windows 157 operating systems. Common uses of the network include e-mail, Secure 158 Shell (SSH), web browsing, and various instant messaging and Voice 159 over IP (VoIP) applications. The hardware in the home environment 160 consists of PCs, laptops and a number of server, camera, and sensor 161 appliances. The primary operating systems in this environment are 162 Linux and Microsoft Windows operating systems. Common applications 163 include web browsing, streaming, instant messaging and VoIP 164 applications, gaming, file storage, and various home control 165 applications. Both environments employ extensive firewalling 166 practices, and filtering is applied for both IPv4 and IPv6 traffic. 167 However, firewall capabilities, especially with older versions of 168 firewall software, dictate some differences between the filtering 169 applied for IPv4 and IPv6 since some features commonly supported for 170 IPv4 were not yet implemented for IPv6. In addition, in the home 171 environment the individual devices are directly accessible from the 172 Internet on IPv6 (on select protocols such as SSH) but not on IPv4 173 due to lack of available public IPv4 addresses. 175 In both environments, volunteers had the possibility to opt-in for 176 the IPv6-only network. The number of users is small: there are 177 roughly five permanent users and a dozen users who have been in the 178 network at least for some amount of time. Each user had to connect 179 to the IPv6-only wired or wireless network, and depending on their 180 software, possibly configure their computer by indicating that there 181 is no IPv4 and/or setting DNS server addresses. The users were also 182 asked to report their experiences back to the organizers. 184 3.1. The IPv6-Only Network 186 The IPv6-only network was provided as a parallel network on the side 187 of the already existing dual-stack network. It was important to 188 retain the dual-stack network for the benefit of those users who did 189 not decide to opt-in and also because we knew that there were some 190 IPv4-only devices in the network. A separate wired access network 191 was created using Virtual Local Area Networks (VLANs). This network 192 had its own IPv6 prefix. A separate wireless network, bridged to the 193 wired network, was also created. In our case, the new wireless 194 network required additional access point hardware in order to 195 accommodate advertising multiple wireless networks. The simple 196 access point model that we employed in these networks did not allow 197 this on a single device, although many other access points support 198 this. All the secondary infrastructure resulted in some additional 199 management burden and cost, however. An added complexity was that 200 the home network already employed two types of infrastructure, one 201 for family members and another one for visitors. In order to 202 duplicate this model for the IPv6-only network there are now four 203 separate networks, with several access points on each. 205 A stateful NAT64 [RFC6146] with integrated DNS64 was installed on the 206 edge of the IPv6-only networks. No IPv4 routing or Dynamic Host 207 Configuration Protocol (DHCP) was offered on these networks. The 208 NAT64 device sends Router Advertisements (RAs) [RFC4861] from which 209 the hosts learn the IPv6 prefix and can automatically configure IPv6 210 addresses for them. Each new IPv6-only network needed one new /64 211 prefix to be used in these advertisements. In addition, each NAT64 212 device needed another /64 prefix to be used for the representation of 213 IPv4 destinations in the IPv6-only network. As a result, one IPv6- 214 only network requires /63 of address space. This space was easily 215 available in our networks, as IPv6 allocations are on purpose made in 216 sufficiently large blocks. Additional address space needs can be 217 accommodated from the existing block without registry involvement. 218 Another option would have been to use the Well-Known Prefix [RFC6052] 219 for the representation of IPv4 destinations in the IPv6-only network. 220 In any case, the prefixes have to be listed in the intra-domain 221 routing system so that they can be reached. In one case the increase 222 from one block to multiple also made it necessary to employ an 223 improved routing configuration. In addition to routing, the new 224 prefixes have to be listed in the appropriate firewall rules. 226 Setting up NAT64 and DNS64 by itself is easy and can be done quickly 227 by experienced network manager. However, when duplicate 228 infrastructure is needed for dual-stack and IPv6-only networks, the 229 additional switches, cables, access points, etc., will take some 230 amount of installation effort. In addition, if whitelisting 231 agreements or IPv6 ISP connectivity is needed, setting these up 232 requires negotiations with external partners. 234 3.2. DNS Operation 236 Router Advertisements are used to carry DNS Configuration options 237 [RFC6106], listing the DNS64 as the DNS server the hosts should use. 238 In addition, aliases were added to the DNS64 device to allow it to 239 receive packets on the well-known DNS server addresses that Windows 240 operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0: 241 0:0:ffff::3). At a later stage support for stateless DHCPv6 242 [RFC3736] was added. We do recommend enabling RFC 6106, well-known 243 addresses, and stateless DHCPv6 in order to maximize the likelihood 244 of different types of IPv6-only hosts being able to use DNS without 245 manual configuration. DNS server discovery was never a problem in 246 dual-stack networks, because DNS servers on the IPv4 side can easily 247 provide IPv6 information (AAAA records) as well. With IPv6-only 248 networking, it becomes crucial that the local DNS server can be 249 reached via IPv6 as well. This is in principle exactly same as 250 needing IPv4-based DNS and DNS discovery in IPv4-only networks. 251 However, in IPv6 the discovery mechanisms are somewhat more 252 complicated because there are several alternative techniques. 254 When a host served by the DNS64 asks for a domain name that does not 255 have an AAAA (IPv6 address) record, but has an A (IPv4 address) 256 record, an AAAA record is synthesized from the A record (as defined 257 for DNS64 in [RFC6147]) and sent in the DNS response to the host. IP 258 packets sent to this synthesized address are routed via the NAT64, 259 translated to IPv4 by the NAT64, and forwarded to the queried host's 260 IPv4 address; return traffic is translated back from IPv4 to IPv6 and 261 forwarded to the host behind the NAT64 (as described in [RFC6144]). 262 This allows the hosts in the IPv6-only network to contact any host in 263 the IPv4 Internet as long as the hosts in the IPv4 Internet have DNS 264 address records. 266 The NAT64 devices have standard dual-stack connectivity and their 267 DNS64 function can use both IPv4 and IPv6 when requesting information 268 from DNS. A destination that has both an A and AAAA records is not 269 treated in any special manner, because the hosts in the IPv6-only 270 network can contact the destination over IPv6. Destinations with 271 only an A record will be given a synthesized AAAA record as explained 272 above. However, in one of our open visitor networks that is sharing 273 the infrastructure with the home network we needed a special 274 arrangement. Currently, the home network obtains its IPv6 275 connectivity through a tunnel via the office network, and it is 276 undesirable to allow outsiders using the visitor network to generate 277 traffic through the office network, even if the traffic is just 278 passing by and forwarded to the IPv6 Internet. As a result, in the 279 visitor network there is a special IPv6-only to IPv4-only 280 configuration where the DNS64 never asks for AAAA records and always 281 generates synthesized records. Therefore no traffic from the visitor 282 network, even if it is destined to the IPv6 Internet, is routed via 283 the office network but traffic from the home network can still use 284 the IPv6 connectivity provided by the office network. 286 Note: This configuration may also be useful for other purposes. 287 For instance, one drawback of standard behavior is that if a 288 destination publishes AAAA records but has bad IPv6 connectivity, 289 the hosts in the IPv6-only network have no fallback. In the dual- 290 stack model a host can always try IPv4 if the IPv6 connection 291 fails. In the special configuration IPv6 is only used internally 292 at the site but never across the Internet, eliminating this 293 problem. This is not a recommended mode of operation, but it is 294 interesting to note that it may solve some issues. 296 Note that in NAT64 (unlike in its older variant [RFC4966]) it is 297 possible to decouple the packet translation, IPv6 routing, and DNS64 298 functions. Since clients are configured to use a DNS64 as their DNS 299 server, there is no need for having an Application Layer Gateway 300 (ALG) on the path sniffing and spoofing DNS packets. This decoupling 301 possibility was used by one of our users, as he is outside of our 302 physical network and wants to communicate directly on IPv6 where it 303 is possible without having to go through our central network 304 equipment. His DNS queries go to our DNS64 and to establish 305 communications to an IPv4 destination our central NAT64 is used. If 306 there is a need to translate some packets, these packets find the 307 translator device through normal IPv6 routing means since the 308 synthesized addresses have our NAT64's prefix. However, for non- 309 synthesized IPv6 addresses the packets are routed directly to the 310 destination. 312 4. General Experiences 314 Based on our experiences, it is possible to live (and work) with an 315 IPv6-only network. For instance, at the time of this writing, one of 316 the authors has been in an IPv6-only network for about a year and a 317 half and has had no major problems. Most things work well in the new 318 environment; for example, we have been unable to spot any practical 319 difference in the web browsing (HTTP and HTTPS) experience. Also 320 e-mail, software upgrades, operating system services, many chat 321 systems and media streaming work well. On certain Symbian mobile 322 handsets that we tried all applications work even on an IPv6-only 323 network. In another case with Android operating system, all the 324 basic applications worked without problems. In order to make the 325 latter handset architecture support IPv6-only networks, however, a 326 small change was needed in the operating system so that it could 327 discover IPv6-only DNS servers. 329 However, in general there is some pain involved and thus IPv6-only 330 networking is not suitable for everyone just yet. Switching IPv4 off 331 does break many things as well. Some of the users in our environment 332 left due to these issues, as they missed some key feature that they 333 needed from their computing environment. These issues fall in 334 several categories: 336 Bugs 338 We saw many issues that can be classified as bugs, likely related 339 to so few people having tried the software in question in an IPv6- 340 only network. For instance, some operating system facilities 341 support IPv6 but have annoying problems that are only uncovered in 342 IPv6-only networking. 344 Lack of IPv6 Support 346 We also saw many applications that do not support IPv6 at all. 347 These range from minor, old tools (such as the Unix dict(1) 348 command) to major applications that are important to our users 349 (such as Skype) and even to entire classes of applications (many 350 games have issues). As our experiment continued, we have seen 351 improvements in some areas, such as gaming. 353 Protocol, Format, and Content Problems 355 There are many protocols that carry IP addresses in them, and 356 using these protocols through a translator can lead to problems. 357 In our current network setup we did not employ any ALGs except for 358 FTP [RFC6384]. However, we have observed a number of protocol 359 issues with IPv4 addresses. For instance, some instant messaging 360 services do not work due to this. Finally, content on some web 361 pages may refer to IPv4 address literals (i.e., plain IP addresses 362 instead of host and domain names). This renders some links 363 inaccessible in an IPv6-only network. While this problem is 364 easily quantifiable in measurements, the authors have run into it 365 only a couple of times during real-life web browsing. 367 Firewall Issues 369 We also saw a number of issues related to lack of features in IPv6 370 support in firewalls. In particular, while we did not experience 371 any Maximum Transmission Unit (MTU) and fragmentation problems in 372 our networks, there is potential for generating problems, as the 373 support for IPv6 fragment headers is not complete in all firewalls 374 and the NAT64 specifications call for use of the fragment header 375 (even in situations where fragmentation has not yet occurred, 376 e.g., if an IPv4 packet that is not a fragment does not have the 377 Don't Fragment (DF) bit set). 379 In general, most of the issues relate to poor testing and lack of 380 IPv6 support in some applications. IPv6 itself and NAT64 did not 381 cause any major issues for us, once our setup and NAT64 software was 382 stable. In general, the authors feel that with the exception of some 383 applications, our experience with translation to reach the IPv4 384 Internet has been equal to our past experiences with NAT44-based 385 Internet access. While translation implies loss of end-to-end 386 connectivity, in practice direct connectivity has not been available 387 to the authors in the IPv4 Internet either for a number of years. 389 It should be noted that the experience with a properly configured set 390 of ALGs and work-arounds such as proxies may be different. Some of 391 the problems we encountered can be solved through these means. For 392 instance, a problematic application can be configured to use a proxy 393 that in turn has both IPv4 and IPv6 access. 395 5. Experiences with IPv6-Only Networking 397 The overall experience was as explained above. The remainder of this 398 section discusses specific issues with different operating systems, 399 programming languages, applications, and appliances. 401 5.1. Operating Systems 403 Even operating systems have some minor problems with IPv6. For 404 example, in Linux Router Advertisement (RA) information was not 405 automatically updated when the network changes while the computer is 406 on and required an unnecessary suspend/resume cycle to restore its 407 proper state. We have also had issues with the rdnssd daemon, which 408 first does not come as a default feature in Ubuntu and does not 409 always appear to work reliably. To resolve these issues we had to 410 configure the network manager to use a specific server address. 411 Later, a new version of the Linux distribution that we used solved 412 these problems, even if some problems still remained. For instance, 413 in the latest Ubuntu Long Term Support release (10.04) we have 414 experienced that the network manager by default returns to an 415 available IPv4 wireless network even if there is a previously used 416 IPv6-only network available and the IPv4 network has no global 417 connectivity before a web-based login is completed. 419 In Mac OS X (Snow Leopard) the network manager needed to be 420 explicitly told to not expect IPv4. A more annoying issue was that 421 in order to switch between an IPv6-only and IPv4-only networks, these 422 settings had to be manually changed, making it undesirable for Mac OS 423 X users to employ IPv6-only networks. 425 Also on Microsoft Windows 7 we experienced problems when relying on 426 default, well-known DNS server addresses: without manual 427 configuration, the host was unable to use the DNS addresses, even 428 though the system displays them as current DNS server addresses. 430 Latest versions of the Android operating system support IPv6 on its 431 wireless LAN interface, but due to lack of DNS discovery mechanisms, 432 this does not work in IPv6-only networks. We corrected this, 433 however, and prototype phones in our networks work now well even in 434 an IPv6-only environment. This change, DNS Discovery Daemon (DDD) 435 now exists as open source software. Interestingly, all applications 436 that we have tried so far seem to work without problems with IPv6- 437 only connectivity, though no exhaustive testing was done, nor did we 438 try known troublesome applications. 440 While all these operating systems (or their predecessors) have 441 supported IPv6 already for a number of years, these kind of small 442 glitches seem to imply that they have not been thoroughly tested in 443 networks lacking IPv4 connectivity. At the very least their 444 usability leaves something to be desired. 446 5.2. Programming Languages and APIs 448 For applications to be able to support IPv6, they need access to the 449 necessary APIs. Luckily, IPv6 seems to be well supported by majority 450 of the commonly used APIs. The Perl programming language used to be 451 an exception with only partial IPv6 support up to the version 5.14 452 (released May 14th 2011). This version finally includes full IPv6 453 support also in the core libraries and older modules are being 454 updated as well. With previous versions of Perl, while IPv6 socket 455 support is available as an extension module, it may not be possible 456 to install this module without administrative rights. This has also 457 resulted in other networking core libraries (such as FTP and SMTP) 458 not being able to fully support IPv6 and thus many existing Perl 459 programs using network functionality may not work properly in an 460 IPv6-only environment. 462 5.3. Instant Messaging and VoIP 464 By far the biggest complaint from our group of users was that Skype 465 stopped working. In some environments even Skype can be made to work 466 through a proxy configuration, and this was verified in our setting 467 but not used as a permanent solution. More generally, we tested a 468 number of instance messaging applications in an IPv6-only network 469 with NAT64 and the test results can be found from Table 1. The 470 versions used in the tests were the latest versions available on 471 summer 2010. 473 SYSTEM STATUS 475 Facebook on the web (http) OK 476 Facebook via a client (xmpp) OK 477 Jabber.org chat service (xmpp) OK 478 Gmail chat on the web (http) OK 479 Gmail chat via a client (xmpp) OK 480 Google Talk client NOT OK 481 AIM (AOL) NOT OK 482 ICQ (AOL) NOT OK 483 Skype NOT OK 484 MSN NOT OK 485 Webex NOT OK 486 Sametime OK (NOW) 488 Table 1. Instant Messaging Applications in an IPv6-Only Network 490 Packet tracing revealed that the issues in AIM, ICQ, and MSN appear 491 to be related to passing literal IPv4 addresses in the protocol. It 492 remains to be determined whether this can be solved through 493 configuration, proxies, or ALGs. The problem with the Google Talk 494 client is that the software does not support IPv6 connections at this 495 moment. We are continuing our tests with additional applications, 496 and we have also seen changes over time. For instance, a new version 497 of Sametime suddenly started working with IPv6-only networks, 498 presumably due to the new version being more careful with the use of 499 DNS names as opposed to IPv4 addresses. One problem in running these 500 tests is to ensure that we can distinguish IPv6 and NAT64 issues from 501 other issues, such as a generic issue on a given operating system 502 platform. 504 Some of these problems are solvable, however. For instance, we used 505 localhost as a proxy for Skype, and then used SSH to tunnel to an 506 external web proxy, bypassing Skype's limitations with regards to 507 connecting to IPv6 destinations or even IPv6 proxies. 509 5.4. Gaming 511 Another class of applications that we tried was games. We tried both 512 web-based gaming and standalone gaming applications that have a 513 "network" / "Internet" or "LAN" gaming modes. The results are shown 514 in Table 2. 516 SYSTEM STATUS 518 Web-based (e.g. armorgames) OK 519 Runescape (on the web) NOT OK 520 Flat out 2 NOT OK 521 Battlefield NOT OK 522 Secondlife NOT OK 523 Guild Wars NOT OK 524 Age of Empires NOT OK 525 Star Wars: Empire at War NOT OK 526 Crysis NOT OK 527 Lord of the Rings: Conquest NOT OK 528 Rome Total War NOT OK 529 Lord of the Rings: Battle for Middle Earth 2 NOT OK 531 Table 2. Gaming Applications in an IPv6-Only Network 533 Most web-based games worked well, as expected from our earlier good 534 general web experience. However, we were also able to find one web- 535 based game that failed to work (Runescape). This particular game is 536 a Java application that fails on an attempt to perform a HTTP GET 537 request. The reason remains unclear, but a likely theory is the use 538 of an IPv4-literal in the application itself. 540 The experience with standalone games was far more discouraging. 541 Without exception all games failed to enable either connections to 542 ongoing games in the Internet or even LAN-based connections to other 543 computers in the same IPv6-only LAN segment. This is somewhat 544 surprising, and the results require further verification. 545 Unfortunately, the games provide no diagnostics about their 546 operation, so it is hard to guess what is going on. It is possible 547 that their networking code employs older APIs that cannot use IPv6 548 addresses [RFC4038]. The inability to provide any LAN-based 549 connectivity is even more surprising, as this must mean that they are 550 unable to use IPv4 link local connectivity, which should have been 551 available to the devices (IPv4 was not blocked; just that no DHCP 552 answers were provided on IPv4). 554 While none of the standalone games we tested on summer 2010 were 555 IPv6-capable, the situation has improved during the experiment. For 556 instance, a popular on-line game, World of Warcraft, now has IPv6 557 support in its latest version and some of the older games that have 558 been re-released as open source (e.g., Quake) have been patched IPv6- 559 capable by the open source community. 561 5.5. Music Services 563 Most of the web-based music services appear to work fine, presumably 564 because they employ TCP and HTTP as a transport. One notable 565 exception is Spotify, which requires communication to specific IPv4 566 addresses. A proxy configuration similar to the one we used for 567 Skype makes it possible to use Spotify as well. 569 5.6. Appliances 571 There are also problems with different appliances such as webcams. 572 Many of them do not support IPv6 and hence will not work in an IPv6- 573 only network. Also not all firewalls support IPv6. Or even if they 574 do, they may still experience issues with some aspects of IPv6 such 575 as fragments. 577 Some of these issues are easily solved when the appliance works as a 578 server, such as what most webcams and our sensor gateway devices do. 579 We placed the appliance in the IPv4 part of the network (in this 580 case, in private address space), added its name to the local DNS, and 581 simply allowed devices from the IPv6-only network reach it through 582 NAT64. 584 5.7. Other Differences 586 One thing that becomes simplified in an IPv6-only network is source 587 address selection [RFC3484]. As there is no IPv4 connectivity, the 588 host only needs to consider its IPv6 source address. For global 589 communications there is typically just one possible source address. 591 Some networks that advertise IPv6 addresses in their DNS records have 592 in reality some problems. For instance, a popular short URL 593 forwarding service has advertised a deprecated IPv4-compatible IPv6 594 address [RFC4291] in its AAAA record, making it impossible for this 595 site to be reached unless either IPv4 or NAT64 translation to an IPv4 596 destination is used. 598 6. Experiences with NAT64 600 After correcting some initial bugs and stability issues, the NAT64 601 operation itself has been relatively problem free. There have been 602 no unexplained DNS problems or lost sessions. With the exception of 603 the specific applications mentioned above and IPv4 literals, the user 604 experience has been in line with using IPv4 Internet through a NAT44 605 device. These failures with the specific applications are clearly 606 very different from the IPv4 experience, however. 608 The rest of this section discusses our measurements on specific 609 issues. These tests and measurements were performed during year 2011 610 and present a snapshot of the situation on that time. More up-to- 611 date measurement information can be found from various on-line tools 612 such as [HE-IPv6]. 614 6.1. IPv4 Address Literals 616 While browsing in general works, IPv4 literals embedded in the HTML 617 code may break some parts of the web pages when using IPv6-only 618 access. This happens because the DNS64 can not synthesize AAAA 619 records for the literals since the addresses are not queried from the 620 DNS. Luckily, the IPv4 literals seem to be fairly rarely 621 encountered, at least so that they would be noticed, with regular web 622 surfing. The authors have run into this issue only few times during 623 the entire experiment. Only two of those cases had a practical 624 impact (in YouTube, some of the third-party applications for 625 downloading content did not work and one hotel's web page had a 626 literal link to its reservation system). 628 We have attempted to measure the likelihood of running into an IPv4 629 literal in the web. To do this, we took the top 1,000 and 10,000 web 630 sites from the Alexa popular web site list. With 1,000 top sites, 631 0.2% needed an IPv4 literal to render all components in their top 632 page (e.g., images, videos, JavaScript, and Cascading Style Sheet 633 (CSS) files). With 10,000 top sites, this number increases to 2%. 635 However, it is not clear what conclusions can be made about this. It 636 is often the case that there are unresolvable or inaccessible 637 components on a web page anyway for various reasons, and to 638 understand the true impact we would have to know how "important" a 639 given page component was. Also, we did not measure the number of 640 links with IPv4 literals on these pages, nor did we attempt to search 641 the site in any thorough manner for these literals. 643 As noted, personal anecdotal evidence says that IPv4 literals are not 644 a big problem. But clearly, cleaning the most important parts of the 645 web from IPv4 literals would be useful. With tools such as the 646 popular web site list, some user pressure, and co-operation from the 647 content providers the most urgent part of the problem could hopefully 648 be solved as a one-time effort. While IPv4 literals still exist in 649 the web, using a suitable HTTP proxy (e.g., 650 [I-D.wing-behave-http-ip-address-literals]) can help to cope with 651 them. 653 6.2. Comparison of Web Access via NAT64 to Other Methods 655 We also compared how well the web works behind a NAT64 compared to 656 IPv4-only and native IPv6 access. For this purpose, we used wget to 657 go through the same top web site lists as described in Section 6.1, 658 again downloading everything needed to render their front page. The 659 tests were repeated and average failure rate was calculated over all 660 of the runs. Separate tests were conducted with an IPv4-only 661 network, an IPv6-only network, and an IPv6-only network with NAT64. 663 When accessed with the IPv4-only network, our tests show that 1.9% of 664 the sites experienced some sort of error or failure. The failure 665 could be that the whole site was not accessible, or just that a 666 single image (e.g., an advertisement banner) was not loaded properly. 667 It should also be noted that access through wget is somewhat 668 different from a regular browser: some web sites refuse to serve 669 content to wget, browsers typically have DNS heuristics to fill in 670 "www." in front of a domain name where needed, and so on. In 671 addition to missing advertisement banners, temporary routing glitches 672 and other mistakes, these differences also help to explain the reason 673 for the high baseline error rate in this test. It should also be 674 noted that variations in wget configuration options produced highly 675 different results, but we believe that the options we settled on bear 676 closest resemblance to real world browsing. 678 When we tried to access the same sites with native IPv6 (without 679 NAT64), 96% of the sites failed to load correctly. This was as 680 expected, given that most of the Internet content is not available on 681 IPv6. The few exceptions included, for instance, sites managed by 682 Google. 684 When the sites were accessed from the IPv6-only network via a NAT64 685 device, the failure rate increased to 2.1%. Most of these failures 686 appear to be due to IPv4 address literals, and the increased failure 687 rate matches that of IPv4 literal occurrence in the same set of top 688 web sites. With the top 10,000 sites the failure rate with NAT64 689 increases similarly to our test on IPv4 address literals. 691 7. Future Work 693 One important set of measurements remains for future work. It would 694 be useful to understand the effect of DNS64 and NAT64 to response 695 time and end-to-end communication delays. Some users have anecdotal 696 reports of slow web browsing response times, but we have been unable 697 to determine if this was due to the IPv6-only network mechanisms or 698 for some other reason. Measurements on pure DNS response times and 699 packet round-trip delays does not show a significant difference to a 700 NAT44 environment. It would be particularly interesting to measure 701 delays in the context of dual-stack vs. NAT64-based IPv6-only 702 networking. When using dual-stack, broken IPv6 connectivity can be 703 repaired by falling back to IPv4 use. With NAT64, this is not always 704 possible as discussed in Section 3.2. 706 Also more programs, especially VoIP and Peer-to-Peer (P2P) 707 applications should be tested with NAT64. In addition, tunneling and 708 mobility protocols should be tested and especially Virtual Private 709 Network (VPN) protocols and applications would deserve more thorough 710 investigation. 712 8. Conclusions and Recommendations 714 The main conclusion is that it is possible to employ IPv6-only 715 networking. For large classes of applications there are no downsides 716 or the downsides are negligible. We have been unable to spot any 717 practical difference in the web browsing experience, for instance. 718 And IPv6 usage -- be it in dual-stack or IPv6-only form -- comes with 719 inherent advantages, such as enabling direct end-to-end connectivity. 720 In our case, we employed this by enabling direct connectivity to 721 devices in a home network from anywhere in the (IPv6) Internet. 722 There are, however, a number of issues as well, such as lack of IPv6 723 support in some applications or bugs in untested parts of the code. 725 Our experience with IPv6-only networking confirms that dual stack 726 should still be our recommended model for general purpose networking 727 at this point of time. However, IPv6-only networking can be employed 728 by early adopters or highly controlled networks. One example of such 729 controlled network is a mobile network with operator-driven selection 730 of handsets. For instance, on some handsets that we tested, we were 731 unable to see any functional difference between IPv4 and IPv6, today. 733 Our recommendations apply at the present time. With effort and time, 734 deployment barriers can be removed and IPv6-only networking becomes 735 applicable in all networking situations. 737 Some of the improvements are already in process in the form of new 738 products and additional IPv6 support. For instance, we expect that 739 the handset market will have a much higher number of IPv6-capable 740 devices in the near future. But some of the changes do not come 741 without the community spending additional effort. We have identified 742 a number of actions that should be taken to improve the state of 743 IPv6-only networking. These include: 745 DNS Discovery 747 The state of DNS discovery continues to be one of the main 748 barriers for easy adoption of IPv6-only networking. Since DNS 749 discovery is not a problem in dual-stack networking, there has 750 been too little effort in testing and deploying the necessary 751 components. For instance, it would be useful if RA-based DNS 752 discovery came as a standard feature and not as an option in Linux 753 distributions. Our hope is that recent standardization of the RA- 754 based DNS discovery at the IETF will help this happen. Similar 755 issues face other operating systems. The authors believe that at 756 this time, prudent operational practices call for maximizing the 757 number of offered automatic configuration mechanisms on the 758 network side. It might be useful for an IETF document to provide 759 guidance on operating DNS in IPv6-only networks. 761 Network Managers 763 Other key software components are the various network management 764 and attachment tools in operating systems. These tools generally 765 have the required functionality, but do not always appear to have 766 been tested very extensively on IPv6, or let alone IPv6-only 767 networks. Further work is required here. 769 Firewalls 771 More work is needed to ensure that IPv6 is supported in equal 772 manner in various firewall products. 774 Application Support 776 But by far the most important action, for at least our group of 777 users, would be to bring some key applications (e.g., instant 778 messaging and VoIP applications and also games) to a state where 779 they can be easily run on IPv6-only networks and behind a NAT64. 780 To facilitate this, application programmers should use IP version 781 agnostic APIs so that applications automatically use IPv4 or IPv6 782 depending on what is available. In some cases, it may also be 783 necessary to add support for new types of ALGs. 785 IPv4 Literals 787 The web should be cleaned of IPv4 literals. Also IPv4 literals 788 should be avoided in application protocol signaling messages. 790 Measurements and Analysis 792 It is also important to continue with testing, measurements, and 793 analysis of what Internet technology works in IPv6-only networks, 794 to what extent, at what speed, and where the remaining problems 795 are. 797 Guidelines 799 It is also useful to provide guidance for network administrators 800 and users on how to turn on IPv6-only networking. 802 As can be seen from the above list, there are only minor things that 803 can be done through standardization. Most of the effort is practical 804 and centers around improving various implementations. 806 9. Security Considerations 808 The use of IPv6 instead of IPv4 by itself does not make a big 809 security difference. The main security requirement is that, 810 naturally, network security devices need to be able to deal with IPv6 811 in these networks. This is though already required in all dual-stack 812 networks. As noted, it is important, e.g., to ensure firewall 813 capabilities. Security considerations for NAT64 and DNS64 are 814 discussed in [RFC6146] and [RFC6147]. 816 In our experience many of the critical security functions in a 817 network end up being on the dual-stack part of the network anyway. 818 For instance, our mail servers obviously still have to be able to 819 communicate with both the IPv4 and IPv6 Internet, and as a result 820 they and the associated spam & filtering components are not in the 821 IPv6-only part of the network. 823 10. IANA Considerations 825 This document has no IANA implications. 827 11. References 829 11.1. Normative References 831 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 832 Translator (NAT) Terminology and Considerations", 833 RFC 2663, August 1999. 835 [RFC3484] Draves, R., "Default Address Selection for Internet 836 Protocol version 6 (IPv6)", RFC 3484, February 2003. 838 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 839 (DHCP) Service for IPv6", RFC 3736, April 2004. 841 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 842 for IPv6 Hosts and Routers", RFC 4213, October 2005. 844 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 845 "IPv6 Router Advertisement Options for DNS Configuration", 846 RFC 6106, November 2010. 848 11.2. Informative References 850 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 851 Castro, "Application Aspects of IPv6 Transition", 852 RFC 4038, March 2005. 854 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 855 Architecture", RFC 4291, February 2006. 857 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 858 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 859 September 2007. 861 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 862 Address Translator - Protocol Translator (NAT-PT) to 863 Historic Status", RFC 4966, July 2007. 865 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 866 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 867 October 2010. 869 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 870 IPv4/IPv6 Translation", RFC 6144, April 2011. 872 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 873 Algorithm", RFC 6145, April 2011. 875 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 876 NAT64: Network Address and Protocol Translation from IPv6 877 Clients to IPv4 Servers", RFC 6146, April 2011. 879 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 880 Beijnum, "DNS64: DNS Extensions for Network Address 881 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 882 April 2011. 884 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 885 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 887 [I-D.wing-behave-http-ip-address-literals] 888 Wing, D., "Coping with IP Address Literals in HTTP URIs 889 with IPv6/IPv4 Translators", 890 draft-wing-behave-http-ip-address-literals-02 (work in 891 progress), March 2010. 893 [HE-IPv6] Hurricane Electric, "Global IPv6 Deployment Progress 894 Report", February 2012, 895 . 897 Appendix A. Acknowledgments 899 The authors would like to thank the many people who have engaged in 900 discussions around this topic, and particularly the people who were 901 involved in building some of the new tools used in our network, our 902 users who were interested in going where only few had dared to 903 venture before, or people who helped us in this effort. In 904 particular, we would like to thank Martti Kuparinen, Tero Kauppinen, 905 Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu 906 Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and 907 Cameron Byrne. Also Marcelo Braun, Iljitsch van Beijnum, Miika Komu, 908 and Jouni Korhonen have provided useful discussion and comments on 909 the document. 911 Authors' Addresses 913 Jari Arkko 914 Ericsson 915 Jorvas 02420 916 Finland 918 Email: jari.arkko@piuha.net 920 Ari Keranen 921 Ericsson 922 Jorvas 02420 923 Finland 925 Email: ari.keranen@ericsson.com