idnits 2.17.1 draft-arkko-ipv6-only-experience-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (July 12, 2010) is 5037 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 5006 (Obsoleted by RFC 6106) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-09 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-09 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-10 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-20 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-11 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-04 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: January 13, 2011 July 12, 2010 7 Experiences from an IPv6-Only Network 8 draft-arkko-ipv6-only-experience-01 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 to IETF 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 13, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4 64 3. Network Setup . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 5 66 3.2. DNS Operation . . . . . . . . . . . . . . . . . . . . . . 6 67 4. General Experiences . . . . . . . . . . . . . . . . . . . . . 7 68 5. Experiences with IPv6-Only Networking . . . . . . . . . . . . 9 69 5.1. Operating Systems . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Instant Messaging and VoIP . . . . . . . . . . . . . . . . 9 71 5.3. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.4. Appliances . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.5. Other Differences . . . . . . . . . . . . . . . . . . . . 12 74 6. Experiences with NAT64 . . . . . . . . . . . . . . . . . . . . 12 75 6.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 12 76 6.2. Comparison of Web Access via NAT64 to Other Methods . . . 13 77 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8. Conclusions and Recommendations . . . . . . . . . . . . . . . 14 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 This document discusses our experiences from moving a small number of 90 users to an IPv6-only network, with access to the IPv4-only parts of 91 the Internet via a NAT64 device. This arrangement has been done with 92 a permanent change in mind rather than as a temporary experiment, 93 involves both office and home users, heterogeneous computing 94 equipment, and varied applications. We have learned both practical 95 details, road blocks and opportunities, as well as more general 96 understanding of when such a configuration can be recommended and 97 what should be taken into account in the network design. 99 The networks involved in this setup have been in dual stack mode for 100 considerable amount of time, in one case for over ten years. Our 101 IPv6 connectivity is stable and in constant use with no significant 102 problems. Given that the IETF is working on technology such as NAT64 103 [I-D.ietf-behave-v6v4-framework] and several network providers are 104 discussing the possibility of employing IPv6-only networking, we 105 decided to take our network beyond the "comfort zone" and make sure 106 that we understand the implications of having no IPv4 connectivity at 107 all. This also allowed us to test a NAT64 device that is being 108 developed by Ericsson. 110 The main conclusion is that it is possible to employ IPv6-only 111 networking, though there are a number of issues such as lack of IPv6 112 support in some applications and bugs in untested parts of code. As 113 a result, dual-stack [RFC4213] remains as our recommended model for 114 general purpose networking at this time, but IPv6-only networking can 115 be employed by early adopters or highly controlled networks. The 116 document also suggests actions to make IPv6-only networking 117 applicable in all environments. In particular, resolving problems 118 with a few key applications would have a significant impact for 119 enabling IPv6-only networking for large classes of users and 120 networks. It is important that the Internet community understands 121 these deployment barriers and works to remove them. 123 The rest of this document is organized as follows. Section 2 124 introduces some relevant technology and terms, Section 3 describes 125 the network setup, Section 4 discusses our general experiences, 126 Section 5 discusses experiences related to having only IPv6 127 networking available, and Section 6 discusses experiences related to 128 NAT64 use. Finally, Section 7 presents some of our ideas for future 129 work and Section 8 draws conclusions and makes recommendations on 130 when and how one should employ IPv6-only networks. 132 2. Technology and Terminology 134 In this document, the following terms are used. "NAT44" refers to 135 any IPv4-to-IPv4 network address translation algorithm, both "Basic 136 NAT" and "Network Address/Port Translator (NAPT)", as defined by 137 [RFC2663]. 139 "Dual Stack" refers to a technique for providing complete support for 140 both Internet protocols -- IPv4 and IPv6 -- in hosts and routers 141 [RFC4213]. 143 "NAT64" refers to a Network Address Translator - Protocol Translator 144 defined in [I-D.ietf-behave-v6v4-framework], 145 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 146 [I-D.ietf-behave-address-format], [I-D.ietf-behave-dns64], and 147 [I-D.ietf-behave-ftp64]. 149 3. Network Setup 151 We have tested IPv6-only networking in two different network 152 environments: office and home. In both environments all hosts had 153 normal dual stack native IPv4 and IPv6 Internet access already in 154 place. The networks were also already employing IPv6 in their 155 servers and DNS records. Similarly, the network was a part of white 156 listing arrangement to ensure that IPv6-capable content providers 157 would be able to serve their content to the network over IPv6. 159 The office environment has heterogeneous hardware with PCs, laptops, 160 and routers running Linux, Mac OS X, and Microsoft Windows operating 161 systems. Common uses of the network include e-mail, Secure Shell 162 (SSH), web browsing, and various instant messaging and Voice over IP 163 (VoIP) applications. The hardware in the home environment consists 164 of PCs, laptops and a number of server, camera, and sensor 165 appliances. The primary operating systems in this environment are 166 Linux and Microsoft Windows operating systems. Common applications 167 include web browsing, streaming, instant messaging and VoIP 168 applications, gaming, file storage, and various home control 169 applications. Both environments employ extensive firewalling 170 practices, and filtering is applied for both IPv4 and IPv6 traffic. 171 However, firewall capabilities, especially with older versions of 172 firewall software, dictate some differences between the filtering 173 applied for IPv4 and IPv6 since some features commonly supported for 174 IPv4 were not yet implemented for IPv6. In addition, in the home 175 environment the individual devices are directly accessible from the 176 Internet on IPv6 (on select protocols such as SSH) but not on IPv4 177 due to lack of available public IPv4 addresses. 179 In both environments, volunteers had the possibility to opt-in for 180 the IPv6-only network. The number of users is small: there are 181 roughly five permanent users and a dozen users who have been in the 182 network at least for some amount of time. Each user had to connect 183 to the IPv6-only wired or wireless network, and depending on their 184 software, possibly configure their computer by indicating that there 185 is no IPv4 and/or setting DNS server addresses. The users were also 186 asked to report their experiences back to the organizers. 188 3.1. The IPv6-Only Network 190 The IPv6-only network was provided as a parallel network on the side 191 of the already existing dual stack network. It was important to 192 retain the dual stack network for the benefit of those users who did 193 not decide to opt-in and also because we knew that there were some 194 IPv4-only devices in the network. A separate wired access network 195 was created using Virtual Local Area Networks (VLANs). This network 196 had its own IPv6 prefix. A separate wireless network, bridged to the 197 wired network, was also created. With the devices that were used in 198 our environment the new wireless network required additional access 199 point hardware in order to accommodate advertising multiple wireless 200 networks. The simple access point model that we employed in these 201 networks did not allow this on a single device. All the secondary 202 infrastructure resulted in some additional management burden and 203 cost, however. An added complexity was that the home network already 204 employed two types of infrastructure, one for family members and 205 another one for visitors. In order to duplicate this model for the 206 IPv6-only network there are now four separate networks, with several 207 access points on each. 209 A NAT64 with integrated DNS64 was installed on the edge of the IPv6- 210 only networks. No IPv4 routing or Dynamic Host Configuration 211 Protocol (DHCP) was offered on these networks. The NAT64 device 212 sends Router Advertisements (RAs) [RFC4861] from where the hosts 213 learn the IPv6 prefix and can automatically configure IPv6 addresses 214 for them. Each new IPv6-only network needed one new /64 prefix to be 215 used in these advertisements. In addition, each NAT64 device needed 216 another /64 prefix to be used for the representation of IPv4 217 destinations in the IPv6-only network. As a result, one IPv6-only 218 network requires an additional /63 of address space. This space was 219 easily available in our networks, as IPv6 allocations are on purpose 220 made in sufficiently large blocks. Additional address space needs 221 can be accommodated from the existing block without registry 222 involvement. Another option would have been to use the Well-Known 223 Prefix [I-D.ietf-behave-address-format] for the representation of 224 IPv4 destinations in the IPv6-only network. However, the additional 225 prefixes have to be listed in the intra-domain routing system so that 226 they can be reached. In one case the increase from one block to 227 multiple also made it necessary to employ an improved routing 228 configuration. In addition to routing, the new prefixes have to be 229 listed in the appropriate firewall rules. 231 3.2. DNS Operation 233 The RAs are also used to carry DNS Configuration options [RFC5006], 234 listing the DNS64 as the DNS server the hosts should use. In 235 addition, aliases were added to the DNS64 device to allow it to 236 receive packets on the well-known DNS server addresses that Windows 237 operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0: 238 0:0:ffff::3). DHCPv6 was not enabled in our networks due to lack of 239 time, but we do recommend enabling RFC 5006, well-known addresses, 240 and DHCPv6 in order to maximize the likelihood of IPv6-only hosts 241 being able to use DNS without manual configuration. DNS server 242 discovery was never a problem in dual stack networks, because DNS 243 servers on the IPv4 side can easily provide IPv6 information (AAAA 244 records) as well. With IPv6-only networking, it becomes crucial that 245 the local DNS server can be reached via IPv6 as well. 247 When a host served by the DNS64 asks for a domain name that does not 248 have an AAAA (IPv6 address) record, but has an A (IPv4 address) 249 record, an AAAA record is synthesized from the A record (as defined 250 for DNS64 in [I-D.ietf-behave-dns64]) and sent in the DNS response to 251 the host. IP packets sent to this synthesized address are routed via 252 the NAT64, translated to IPv4 by the NAT64, and forwarded to the 253 queried host's IPv4 address; return traffic is translated back from 254 IPv4 to IPv6 and forwarded to the host behind the NAT64 (as described 255 in [I-D.ietf-behave-v6v4-framework]). This allows the hosts in the 256 IPv6-only network to contact any host in the IPv4 Internet as long as 257 the hosts in the IPv4 Internet have DNS address records. 259 The NAT64 devices have standard dual stack connectivity and their 260 DNS64 function can use both IPv4 and IPv6 when requesting information 261 from DNS. A destination that has both an A and AAAA records is not 262 treated in any special manner, because the hosts in the IPv6-only 263 network can contact the destination over IPv6. Destinations with 264 only an A record will be given a synthesized AAAA record as explained 265 above. However, in one of our open visitor networks that is sharing 266 the infrastructure with the home network we needed a special 267 arrangement. Currently, the home network gets its IPv6 connectivity 268 through a tunnel via the office network, and it is undesirable to 269 allow outsiders using the visitor network to generate traffic through 270 the office network, even if the traffic is just passing by and 271 forwarded to the IPv6 Internet. As a result, in the visitor network 272 there is a special IPv6-only to IPv4-only configuration where the 273 DNS64 never asks for AAAA records and always generates synthesized 274 records. Therefore no traffic from the visitor network, even if it 275 is destined to the IPv6 Internet, is routed via the office network 276 but traffic from the home network can still use the IPv6 connectivity 277 provided by the office network. 279 Note: This configuration may also be useful for other purposes. 280 For instance, one drawback of standard behavior is that if a 281 destination publishes AAAA records but has bad IPv6 connectivity, 282 the hosts in the IPv6-only network have no fallback. In the dual 283 stack model a host can always try IPv4 if the IPv6 connection 284 fails. In the special configuration IPv6 is only used internally 285 at the site but never across the Internet, eliminating this 286 problem. This is not a recommended mode of operation, but it is 287 interesting to note that it may solve some issues. 289 Note that in NAT64 (unlike in its older variant [RFC4966]) it is 290 possible to decouple the packet translation, IPv6 routing, and DNS64 291 functions. Since clients are configured to use a DNS64 as their DNS 292 server, there is no need for having an Application Layer Gateway 293 (ALG) on the path sniffing and spoofing DNS packets. This decoupling 294 possibility was used by one of our users, as he is outside of our 295 physical network and wants to communicate directly on IPv6 where it 296 is possible without having to go through our central network 297 equipment. His DNS queries go to our DNS64 and to establish 298 communications to an IPv4 destination our central NAT64 is used. If 299 there is a need to translate some packets, these packets find the 300 translator device through normal IPv6 routing means since the 301 synthesized addresses have our NAT64's prefix. However, for non- 302 synthesized IPv6 addresses the packets are routed directly to the 303 destination. 305 4. General Experiences 307 Based on our experiences, it is possible to live (and work) using an 308 IPv6-only network. For instance, one of the authors has been in an 309 IPv6-only network for about three months and has been able to do all 310 his work successfully. Most things work well in the new environment; 311 for example, we have been unable to spot any practical difference in 312 the web browsing experience. Also e-mail, software upgrades, 313 operating system services, many chat systems and media streaming work 314 well. On certain mobile handsets that we tried all applications work 315 flawlessly even on an IPv6-only network. 317 However, there is some pain involved and thus it is not suitable for 318 everyone just yet. Switching IPv4 off does break many things as 319 well. Some of the users in our environment left due to these issues, 320 as they missed some key feature that they needed from their computing 321 environment. These issues fall in several categories: 323 Bugs 325 We saw many issues that can be classified as bugs, likely related 326 to so few people having tried the software in question in an IPv6- 327 only network. For instance, some operating system facilities 328 support IPv6 but have annoying problems that are only uncovered in 329 IPv6-only networking. 331 Lack of IPv6 Support 333 We also saw many applications that do not support IPv6 at all. 334 These range from minor, old tools (such as the Unix dict(1) 335 command) to major applications that are important to our users 336 (such as Skype) and even to entire classes of applications (many 337 games have issues). 339 Protocol, Format, and Content Problems 341 There are many protocols that carry IP addresses in them, and 342 using these protocols through a translator can lead to problems. 343 In our current network setup we did not employ any ALGs except for 344 FTP [I-D.ietf-behave-ftp64]. However, we have observed a number 345 of protocol issues with IPv4 addresses. For instance, some 346 instant messaging services do not work due to this. Finally, 347 content on some web pages may refer to IPv4 address literals 348 (i.e., plain IP addresses instead of host and domain names). This 349 renders some links inaccessible in an IPv6-only network. While 350 this problem is easily quantifiable in measurements, the authors 351 have only run into it once during real-life web browsing. 353 Firewall Issues 355 We also saw a number of issues related to lack of features in IPv6 356 support in firewalls. In particular, while we did not experience 357 any Maximum Transmission Unit (MTU) and fragmentation problems in 358 our networks, there is potential for generating problems, as the 359 support for IPv6 fragment headers is not complete in all firewalls 360 and the NAT64 specifications call for use of the fragment header 361 (even in situations where fragmentation has not yet occurred, 362 e.g., if an IPv4 packet that is not a fragment does not have the 363 Don't Fragment (DF) bit set). 365 In general, most of the issues relate to poor testing and lack of 366 IPv6 support in some applications. IPv6 itself and NAT64 did not 367 cause any major issues for us, once our setup and NAT64 software was 368 stable. In general, the authors feel that with the exception of some 369 applications, our experience with translation to reach the IPv4 370 Internet has been equal to our past experiences with NAT44-based 371 Internet access. While translation implies loss of end-to-end 372 connectivity, in practice direct connectivity has not been available 373 to the authors in the IPv4 Internet either for a number of years. 375 It should be noted that the experience with a properly configured set 376 of ALGs and work-arounds such as proxies may be different. Some of 377 the problems we encountered can be solved through these means. For 378 instance, a problematic application can be configured to use a proxy 379 that in turn has both IPv4 and IPv6 access. 381 5. Experiences with IPv6-Only Networking 383 The overall experience was as explained above. The remainder of this 384 section discusses specific issues with different operating systems, 385 applications, and appliances. 387 5.1. Operating Systems 389 Even operating systems have some minor problems with IPv6. For 390 example, in Linux RA information was not automatically updated when 391 the network changes while the computer is on, in Ubuntu and Mac OS X 392 the network manager needed to be explicitly told to not expect IPv4, 393 and RA-based DNS discovery does not come as a default feature in 394 Ubuntu. Also on Microsoft Windows 7 we experienced problems when 395 relying on default, well-known DNS server addresses: without manual 396 configuration, the host was unable to use the DNS addresses, even 397 though the system displays them as current DNS server addresses. 399 While all these operating systems (or their predecessors) have 400 supported IPv6 already for a number of years, these kind of small 401 glitches seem to imply that they have not been thoroughly tested in 402 networks lacking IPv4 connectivity. 404 5.2. Instant Messaging and VoIP 406 By far the biggest complaint from our group of users was that Skype 407 stopped working. In some environments even Skype can be made to work 408 through a proxy configuration, and this was verified in our setting 409 but not used as a permanent solution. More generally, we tested a 410 number of instance messaging applications in an IPv6-only network 411 with NAT64 and the test results can be found from Table 1. 413 SYSTEM STATUS 415 Facebook on the web (http) OK 416 Facebook via a client (xmpp) OK 417 Jabber.org chat service (xmpp) OK 418 Gmail chat on the web (http) OK 419 Gmail chat via a client (xmpp) OK 420 Gtalk client NOT OK 421 AIM (AOL) NOT OK 422 ICQ (AOL) NOT OK 423 Skype NOT OK 424 MSN NOT OK 426 Table 1. Instant Messaging Applications in an IPv6-Only Network 428 Packet tracing revealed that the issues in AIM, ICQ, and MSN appear 429 to be related to passing literal IPv4 addresses in the protocol. It 430 remains to be determined whether this can be solved through 431 configuration, proxies, or ALGs. The problem with the Gtalk client 432 is that the software does not support IPv6 connections at this 433 moment. We are continuing our tests with additional applications 434 such as Webex and Sametime, but have either not completed the work or 435 have so far inconclusive results. One problem in running these tests 436 is to ensure that we can distinguish IPv6 and NAT64 issues from other 437 issues, such as a generic issue on a given operating system platform. 439 5.3. Gaming 441 Another class of applications that we tried was games. We tried both 442 web-based gaming and standalone gaming applications that have a 443 "network" / "Internet" or "LAN" gaming modes. The results are shown 444 in Table 2. 446 SYSTEM STATUS 448 Web-based (e.g. armorgames) OK 449 Runescape (on the web) NOT OK 450 Flat out 2 NOT OK 451 Battlefield NOT OK 452 Secondlife NOT OK 453 Guild Wars NOT OK 454 Age of Empires NOT OK 455 Star Wars: Empire at War NOT OK 456 Crysis NOT OK 457 Lord of the Rings: Conquest NOT OK 458 Rome Total War NOT OK 459 Lord of the Rings: Battle for Middle Earth 2 NOT OK 461 Table 2. Gaming Applications in an IPv6-Only Network 463 Most web-based games worked well, as expected from our earlier good 464 general web experience. However, we were also able to find one web- 465 based game that failed to work (Runescape). This particular game is 466 a Java application that fails on an attempt to perform a HTTP GET 467 request. The reason remains unclear, but a likely theory is the use 468 of an IPv4-literal in the application itself. 470 The experience with standalone games was far more discouraging. 471 Without exception all games failed to enable either connections to 472 ongoing games in the Internet or even LAN-based connections to other 473 computers in the same IPv6-only LAN segment. This is somewhat 474 surprising, and the result require further verification. 475 Unfortunately, the games provide no diagnostics about their 476 operation, so it is hard to guess what is going on. It is possible 477 that their networking code employs older APIs that cannot use IPv6 478 addresses [RFC4038]. The inability to provide any LAN-based 479 connectivity is even more surprising, as this must mean that they are 480 unable to use IPv4 link local connectivity, which should have been 481 available to the devices (IPv4 was not blocked; just that no DHCP 482 answers were provided on IPv4). 484 5.4. Appliances 486 There are also problems with different appliances such as webcams. 487 Many of them do not support IPv6 and hence will not work in an IPv6- 488 only network. Also not all firewalls support IPv6. Or even if they 489 do, they may still experience issues with some aspects of IPv6 such 490 as fragments. 492 Some of these issues are easily solved when the appliance works as a 493 server, such as what most webcams and our sensor gateway devices do. 495 We placed the appliance in the IPv4 part of the network (in this 496 case, in private address space), added its name to the local DNS, and 497 simply allowed devices from the IPv6-only network reach it through 498 NAT64. 500 5.5. Other Differences 502 One thing that becomes simplified in an IPv6-only network is source 503 address selection [RFC3484]. As there is no IPv4 connectivity, the 504 host only needs to consider its IPv6 source address. For global 505 communications there is typically just one possible source address. 507 6. Experiences with NAT64 509 After correcting some initial bugs and stability issues, the NAT64 510 operation itself has been relatively problem free. There have been 511 no unexplained DNS problems or lost sessions. With the exception of 512 the specific applications mentioned above and IPv4 literals, the user 513 experience has been in line with using IPv4 Internet through a NAT44 514 device. These failures with the specific applications are clearly 515 very different from the IPv4 experience, however. 517 The rest of this section discusses our measurements on specific 518 issues. 520 6.1. IPv4 Address Literals 522 While browsing in general works, IPv4 literals embedded in the HTML 523 code may break some parts of the web pages when using IPv6-only 524 access. This happens because the DNS64 can not synthesize AAAA 525 records for the literals since the addresses are not queried from the 526 DNS. Luckily, the IPv4 literals seem to be fairly rarely 527 encountered, at least so that they would be noticed, with regular 528 surfing. 530 We have attempted to measure the likelihood of running into an IPv4 531 literal in the web. To do this, we took the top 1,000 and 10,000 web 532 sites from the Alexa popular web site list. With 1,000 top sites, 533 0.2% needed an IPv4 literal to render all components in their top 534 page (i.e., images, videos, JavaScript and Cascading Style Sheet 535 (CSS) files, etc.). With 10,000 top sites, this number increases to 536 2%. 538 However, it is not clear what conclusions can be made about this. It 539 is often the case that there are unresolvable or inaccessible 540 components on a web page anyway for various reasons, and to 541 understand the true impact we would have to know how "important" a 542 given page component was. Also, we did not measure the number of 543 links with IPv4 literals on these pages, nor did we attempt to search 544 the site in any thorough manner for these literals. 546 As noted, personal anecdotal evidence says that IPv4 literals are not 547 a big problem. But clearly, cleaning the most important parts of the 548 web from IPv4 literals would be useful. With tools such as the 549 popular web site list, some user pressure, and co-operation from the 550 content providers the most urgent part of the problem could hopefully 551 be solved as a one-time effort. While IPv4 literals still exist in 552 the web, using a suitable HTTP proxy (e.g., 553 [I-D.wing-behave-http-ip-address-literals]) can help to cope with 554 them. 556 6.2. Comparison of Web Access via NAT64 to Other Methods 558 We also compared how well the web works behind a NAT64 compared to 559 IPv4-only and native IPv6 access. For this purpose, we used wget to 560 go through the same top web site lists as in section Section 6.1, 561 again downloading everything needed to render their front page. The 562 tests were repeated and an average was calculated over all runs. 563 Separate tests were done with an IPv4-only network, an IPv6-only 564 network, and an IPv6-only network with NAT64. 566 When accessed with an IPv4-only network, our tests show that 1.9% of 567 the sites experienced some sort of error or failure. The failure 568 could be that the whole site was not accessible, or just that a 569 single image (e.g., an advertisement banner) was not loaded properly. 570 It should also be noted that access through wget is somewhat 571 different to access via a regular browser: some web sites refuse to 572 serve content to wget, browsers typically have DNS heuristics to fill 573 in "www." in front of a domain name where needed, and so on. In 574 addition to missing advertisement banners, temporary routing glitches 575 and other mistakes, these differences also help to explain the reason 576 for the high baseline error rate in this test. It should also be 577 noted that variations in wget configuration options produced highly 578 different results, but we believe that the options we settled on bear 579 closest resemblance to real world browsing. 581 When we tried to access the same sites with native IPv6 (without 582 NAT64), 96% of the sites failed to load correctly. This was as 583 expected, given that most of the Internet content is not available on 584 IPv6. The few exceptions included, for instance, sites managed by 585 Google. 587 When the sites were accessed from IPv6-only network via a NAT64 588 device, the failure rate increased to 2.1%. Most of these failures 589 appear to be due to IPv4 address literals, and the increased failure 590 rate matches that of IPv4 literal occurrence in the same set of top 591 web sites. With the top 10,000 sites the failure rate with NAT64 592 increases similarly to our test on IPv4 address literals. 594 7. Future Work 596 One important set of measurements remains for future work. It would 597 be useful to understand the effect of DNS64 and NAT64 to response 598 time and end-to-end communication delays. Some users have anecdotal 599 reports of slow web browsing response times, but we have been unable 600 to determine if this was due to the IPv6-only network mechanisms or 601 for some other reason. Measurements on pure DNS response times and 602 packet round-trip delays does not show a significant difference to a 603 NAT44 environment. It would be particularly interesting to measure 604 delays in the context of dual stack vs. NAT64-based IPv6-only 605 networking. With dual stack, broken IPv6 connectivity can be 606 repaired by falling back to IPv4 use. With NAT64 this is not always 607 possible as discussed in Section 3.2. 609 Also more programs, especially VoIP and Peer-to-Peer (P2P) 610 applications should be tested with NAT64. In addition, tunneling and 611 mobility protocols should be tested and especially Virtual Private 612 Network (VPN) protocols and applications would deserve more thorough 613 investigation. 615 8. Conclusions and Recommendations 617 The main conclusion is that it is possible to employ IPv6-only 618 networking. For large classes of applications there are no downsides 619 or the downsides are negligible. We have been unable to spot any 620 practical difference in the web browsing experience, for instance. 621 And IPv6 usage -- be it in dual stack or IPv6-only form -- comes with 622 inherent advantages, such as enabling direct end-to-end connectivity. 623 In our case we employed this by enabling direct connectivity to 624 devices in a home network from anywhere in the (IPv6) Internet. 625 There are, however, a number of issues as well such as lack of IPv6 626 support in some applications or bugs in untested parts of code. 628 Our experience with IPv6-only networking confirms that dual stack 629 should still be our recommended model for general purpose networking 630 at this time. But IPv6-only networking can be employed by early 631 adopters or highly controlled networks. One example such controlled 632 networks are mobile networks with operator-driven selection of 633 handsets. For instance, on some handsets that we tested we were 634 unable to see any functional difference between IPv4 and IPv6, today. 636 Our recommendations apply at the present time. With effort and time, 637 deployment barriers can be removed and IPv6-only networking becomes 638 applicable in all networking situations. 640 Some of the improvements are already in process in the form of new 641 products and additional IPv6 support. For instance, we expect that 642 the handset market will have a much higher number of IPv6-capable 643 devices next year. But some of the changes do not come without the 644 community spending additional effort. We have identified a number of 645 actions that should be taken to improve the state of IPv6-only 646 networking. These include: 648 DNS Discovery 650 The state of DNS discovery continues to be one of the main 651 barriers for easy adoption of IPv6-only networking. Since DNS 652 discovery is not a problem in dual stack networking, there has 653 been too little effort in testing and deploying the necessary 654 components. For instance, it would be useful if RA-based DNS 655 discovery came as a standard feature and not as an option in Linux 656 distributions. Our hope is that ongoing standardization of the 657 RA-based DNS discovery at the IETF will help this happen. Similar 658 issues face other operating systems. The authors believe that at 659 this time, prudent operational practices call for maximizing the 660 number of offered automatic configuration mechanisms in the 661 network side. It might be useful for an IETF document to provide 662 guidance on operating DNS in IPv6-only networks. 664 Network Managers 666 Another key software component are the various network management 667 and attachment tools in operating systems. These tools generally 668 have the required functionality, but do not always appear to have 669 been tested very extensively on IPv6 or let alone IPv6-only 670 networks. Further work is required here. 672 Application Support 674 But by far the most important action, for at least our group of 675 users, would be to bring some key applications (e.g., instant 676 messaging and VoIP applications and also games) to a state where 677 they can easily run on IPv6-only networks and behind a NAT64. In 678 some cases it may also be necessary add support for new types of 679 ALGs. 681 IPv4 Literals 683 The web should be cleaned from IPv4 literals. 685 Measurements and Analysis 687 It is also important to continue with testing, measurements, and 688 analysis of what Internet technology works in IPv6-only networks, 689 to what extent, at what speed, and where the remaining problems 690 are. 692 Guidelines 694 It is also useful to provide guidance for network administrators 695 and users on how to turn on IPv6-only networking. 697 As can be seen from the above list, there are only minor things that 698 can be done through standardization. Most of the effort is practical 699 and centers around improving various implementations. 701 9. Security Considerations 703 The use of IPv6 instead of IPv4 by itself does not make a big 704 security difference. The main security requirement is that, 705 naturally, network security devices need to be able to deal with IPv6 706 in these networks. This is though already required in all dual-stack 707 networks. As noted it is important, e.g., to ensure firewall 708 capabilities. 710 In our experience many of the critical security functions in a 711 network end up being on the dual stack part of the network anyway. 712 For instance, our mail servers obviously still have to be able to 713 communicate with both the IPv4 and IPv6 Internet, and as a result 714 they and the associated spam & filtering components are not in the 715 IPv6-only part of the network. 717 10. IANA Considerations 719 This document has no IANA implications. 721 11. References 722 11.1. Normative References 724 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 725 Translator (NAT) Terminology and Considerations", 726 RFC 2663, August 1999. 728 [RFC3484] Draves, R., "Default Address Selection for Internet 729 Protocol version 6 (IPv6)", RFC 3484, February 2003. 731 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 732 for IPv6 Hosts and Routers", RFC 4213, October 2005. 734 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 735 "IPv6 Router Advertisement Option for DNS Configuration", 736 RFC 5006, September 2007. 738 11.2. Informative References 740 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 741 Castro, "Application Aspects of IPv6 Transition", 742 RFC 4038, March 2005. 744 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 745 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 746 September 2007. 748 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 749 Address Translator - Protocol Translator (NAT-PT) to 750 Historic Status", RFC 4966, July 2007. 752 [I-D.ietf-behave-v6v4-framework] 753 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 754 IPv4/IPv6 Translation", 755 draft-ietf-behave-v6v4-framework-09 (work in progress), 756 May 2010. 758 [I-D.ietf-behave-address-format] 759 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 760 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 761 draft-ietf-behave-address-format-09 (work in progress), 762 July 2010. 764 [I-D.ietf-behave-dns64] 765 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 766 "DNS64: DNS extensions for Network Address Translation 767 from IPv6 Clients to IPv4 Servers", 768 draft-ietf-behave-dns64-10 (work in progress), July 2010. 770 [I-D.ietf-behave-v6v4-xlate] 771 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 772 Algorithm", draft-ietf-behave-v6v4-xlate-20 (work in 773 progress), May 2010. 775 [I-D.ietf-behave-v6v4-xlate-stateful] 776 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 777 NAT64: Network Address and Protocol Translation from IPv6 778 Clients to IPv4 Servers", 779 draft-ietf-behave-v6v4-xlate-stateful-11 (work in 780 progress), March 2010. 782 [I-D.ietf-behave-ftp64] 783 Beijnum, I., "IPv6-to-IPv4 translation FTP 784 considerations", draft-ietf-behave-ftp64-04 (work in 785 progress), July 2010. 787 [I-D.wing-behave-http-ip-address-literals] 788 Wing, D., "Coping with IP Address Literals in HTTP URIs 789 with IPv6/IPv4 Translators", 790 draft-wing-behave-http-ip-address-literals-02 (work in 791 progress), March 2010. 793 Appendix A. Acknowledgments 795 The authors would like to thank the many people who have engaged in 796 discussions around this topic, and particularly the people who were 797 involved in building some of the new tools used in our network, our 798 users who were interested in going where only few had dared to 799 venture before, or people who helped us in this effort. In 800 particular, we would like to thank Martti Kuparinen, Tero Kauppinen, 801 Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu 802 Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and 803 Cameron Byrne. 805 Authors' Addresses 807 Jari Arkko 808 Ericsson 809 Jorvas 02420 810 Finland 812 Email: jari.arkko@piuha.net 813 Ari Keranen 814 Ericsson 815 Jorvas 02420 816 Finland 818 Email: ari.keranen@ericsson.com