Experiences from an IPv6-Only Network
draft-arkko-ipv6-only-experience-00

Abstract

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as road blocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 6, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Technology and Terminology
3.  Network Setup
    3.1.  The IPv6-Only Network
    3.2.  DNS Operation
4.  General Experiences
5.  Experiences with IPv6-Only Networking
    5.1.  Operating Systems
    5.2.  Instant Messaging
    5.3.  Gaming
    5.4.  Appliances
6.  Experiences with NAT64
    6.1.  IPv4 Address Literals
    6.2.  Comparison of Web Access via NAT64 to Other Methods
    6.3.  Response Times
7.  Conclusions and Recommendations
8.  Security Considerations
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Acknowledgments
§  Authors' Addresses

1.  Introduction

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. This arrangement has been done with a permanent change in mind rather than as a temporary experiment, involves both office and home users, heterogeneous computing equipment, and varied applications. We have learned both practical details, road blocks and opportunities, as well as more general understanding of when such a configuration can be recommended and what should be taken into account in the network design.

The networks involved in this setup have been in dual stack mode for considerable amount of time, in one case for over ten years. Our IPv6 connectivity is stable and in constant use with no significant problems. Given that the IETF is working on technology such as NAT64 [I‑D.ietf‑behave‑v6v4‑framework] (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” May 2010.) and several network providers are discussing the possibility of employing IPv6-only networking, we decided to take our network beyond the "comfort zone" and make sure that we understand the implications of having no IPv4 connectivity at all. This also allowed us to test a NAT64 device that is being developed by Ericsson.

The main conclusions so far indicate that it is possible to employ IPv6-only networking, though there are a number of issues such as lack of IPv6 support in some applications or bugs in untested parts of code. As a result, dual-stack [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.) remains as our recommended model for general purpose networking at this time, but IPv6-only networking can be employed by early adopters or highly controlled networks. The document also suggests actions to make IPv6-only networking applicable in all environments. In particular, resolving problems with a few key applications would have a significant impact for enabling IPv6-only networking for large classes of users and networks. It is important that the Internet community understands these deployment barriers and works to remove them.

The rest of this document is organized as follows. Section 2 (Technology and Terminology) introduces some relevant technology and terms, Section 3 (Network Setup) describes the network setup, Section 4 (General Experiences) discusses our general experiences, Section 5 (Experiences with IPv6-Only Networking) discusses experiences related to having only IPv6 networking available, and Section 6 (Experiences with NAT64) discusses experiences related to NAT64 use. Finally, Section 7 (Conclusions and Recommendations) draws some conclusions and makes recommendations on when and how one should employ IPv6-only networks.

2.  Technology and Terminology

In this document, the following terms are used. "NAT44" refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663] (Srisuresh, P. and M. Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations,” August 1999.).

"Dual Stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.).

"NAT64" refers to a Network Address Translator - Protocol Translator defined in [I‑D.ietf‑behave‑v6v4‑framework] (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” May 2010.) [I‑D.ietf‑behave‑v6v4‑xlate] (Li, X., Bao, C., and F. Baker, “IP/ICMP Translation Algorithm,” May 2010.) [I‑D.ietf‑behave‑v6v4‑xlate‑stateful] (Bagnulo, M., Matthews, P., and I. Beijnum, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,” March 2010.) [I‑D.ietf‑behave‑address‑format] (Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, “IPv6 Addressing of IPv4/IPv6 Translators,” May 2010.) [I‑D.ietf‑behave‑dns64] (Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, “DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers,” March 2010.) [I‑D.ietf‑behave‑ftp64] (Beijnum, I., “IPv6-to-IPv4 translation FTP considerations,” May 2010.).

3.  Network Setup

We have tested IPv6-only networking in two different network environments: office and home. In both environments all hosts had normal dual stack native IPv4 and IPv6 Internet access already in place. The networks were also already employing IPv6 in their servers and DNS records. Similarly, the network was a part of white listing arrangement to ensure that IPv6-capable content providers would be able to serve their content to the network over IPv6.

The office environment has heterogeneous hardware with PCs, laptops, and routers running Linux, Mac OS X, and Microsoft Windows operating systems. Common uses of the network include e-mail, Secure Shell (SSH), web browsing, and various instant messaging (IM) and Voice over IP (VoIP) applications. The hardware in the home environment consists of PCs, laptops and a number of server, camera, and sensor appliances. The primary operating systems in this environment are Linux and Microsoft Windows operating systems. Common applications include web browsing, streaming, instant messaging and VoIP applications, gaming, file storage, and various home control applications. Both environments employ extensive firewalling practices, and filtering is applied for both IPv4 and IPv6 traffic. Firewall capabilities dictate some differences between the filtering applied for IPv4 and IPv6, however. In addition, in the home environment the individual devices are directly accessible from the Internet on IPv6 (on select protocols such as SSH) but not on IPv4 due to lack of available public IPv4 addresses.

In both environments, volunteers had the possibility to opt-in for the IPv6-only network. The number of users is small, there are roughly five permanent users and a dozen users who have been in the network at least for some amount of time. Each user had to connect to the IPv6-only wired or wireless network, and depending on their software, possibly configure their computer by indicating that there is no IPv4 and/or setting DNS server addresses. The users were also asked to report their experiences back to the organizers.

3.1.  The IPv6-Only Network

The IPv6-only network was provided as a parallel network on the side of the already existing dual stack network. It was important to retain the dual stack network for the benefit of those users that did not decide to opt-in. It was also important as we knew there were IPv4-only devices. A separate wired access network was created using Virtual Local Area Networks (VLANs). This network had its own IPv6 prefix. A separate wireless network was also created, bridged to the wired network. With the devices that were used in our environment the new wireless network required additional access point hardware in order to accommodate advertising multiple wireless networks. The simple access point model that we employed in these networks did not allow this on a single device. All the secondary infrastructure resulted in some additional management burden and cost, however. An added complexity was that the home network already employed two types of infrastructure, one for family members and another one for visitors. In order to duplicate this model for the IPv6-only network there are now four separate networks, with several access points on each.

A NAT64 with integrated DNS64 was installed on the edge of the IPv6-only networks. No IPv4 routing or DHCP was offered on these networks. The NAT64 device sends Router Advertisements (RAs) [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) from where the hosts learn the IPv6 prefix and can automatically configure IPv6 addresses for them. Each new IPv6-only network needed one new /64 prefix to be used in these advertisements. In addition, the each NAT64 device needed another /64 prefix to be used for the representation of IPv4 destinations in the IPv6-only network. As a result, one IPv6-only network requires an additional /63 of address space. This space was easily available in our networks, as IPv6 allocations are on purpose made in sufficiently large blocks. Additional address space needs can be accommodated from the existing block without registry involvement. However, the additional prefixes have to be listed in the intra-domain routing system so that they can be reached. In one case the increase from one block to multiple also made it necessary to employ an improved routing configuration. In addition to routing, the new prefixes have to be listed in the appropriate firewall rules.

3.2.  DNS Operation

The RAs are also used to carry DNS Configuration options [RFC5006] (Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, “IPv6 Router Advertisement Option for DNS Configuration,” September 2007.), listing the DNS64 as the DNS server the hosts should use. In addition, aliases were added to the DNS64 device to allow it to receive packets on the well-known DNS server addresses that Windows operating system uses (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0:0:0:ffff::3). DHCPv6 was not enabled in our networks due to lack of time, but we do recommend enabling RFC 5006, well-known addresses, and DHCPv6 in order to maximize the likelihood of IPv6-only hosts being able to use DNS without manual configuration. DNS server discovery was never a problem in dual stack networks, because DNS servers on the IPv4 side can easily provide IPv6 information (AAAA records) as well. With IPv6-only networking, it becomes crucial that the local DNS server can be reached via IPv6 as well.

When a host served by the DNS64 asks for a domain name that does not have an AAAA (IPv6 address) record, but has an A (IPv4 address) record, an AAAA record is synthesized from the A record (as defined in DNS64 [I‑D.ietf‑behave‑dns64] (Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, “DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers,” March 2010.)) and sent in the DNS response to the host. IP packets sent to this synthesized address are routed via the NAT64, translated to IPv4 by the NAT64, and forwarded to the queried host's IPv4 address; return traffic is translated back from IPv4 to IPv6 and forwarded to the host behind the NAT64 (as described in [I‑D.ietf‑behave‑v6v4‑framework] (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” May 2010.)). This allows the hosts in the IPv6-only network to contact any host in the IPv4 Internet as long as the hosts in the IPv4 Internet have DNS address records.

The NAT64 devices have standard dual stack connectivity and their DNS64 function can use both IPv4 and IPv6 when requesting information from DNS. A destination that has both an A and AAAA records is not treated in any special manner, because the hosts in the IPv6-only network can contact the destination over IPv6. Destinations with only an A record will be given a synthesized AAAA record as explained above. However, in one of our open visitor networks we needed a special arrangement. Currently, the home network gets its IPv6 connectivity through a tunnel via the office network, and it is undesirable to allow outsiders to generate traffic through the office network, even if the traffic is just passing by and forwarded to the IPv6 Internet. As a result, in the visitor network there is a special IPv6-only to IPv4-only configuration where the DNS64 never asks for AAAA records and always generates synthesized records.

Note: This configuration may also be useful for other purposes. For instance, one drawback of standard behavior is that if a destination publishes AAAA records but has bad IPv6 connectivity, the hosts in the IPv6-only network have no fallback. In the dual stack model a host can always try IPv4 if the IPv6 connection fails. In the special configuration IPv6 is only used internally at the site but never across the Internet, eliminating this problem. This is not a recommended mode of operation, but it is interesting to note that it may solve some issues.

4.  General Experiences

Based on our experiences, it is possible to live (and work) using an IPv6-only network. For instance, one of the authors has been in this network for about three months and has been able to do all his work. Most things work well in the new environment. We have been unable to spot any practical difference in the web browsing experience, for instance. E-mail, software upgrades, operating system services, many chat systems and media streaming work well. On certain mobile handsets that we tried all applications work flawlessly even on an IPv6-only network.

However, there is some pain involved and thus it is not suitable for everyone just yet. Switching IPv4 off does break many things as well. Some of the users in our environment left due to these issues, as some key feature that they needed from their computing environment did not function. These issues fall in several categories:

Bugs

We saw many issues that can be classified as bugs, likely related to so few people having tried the software in question in an IPv6-only network. For instance, some operating system facilities support IPv6 but have annoying problems that are only uncovered in IPv6-only networking.

Lack of IPv6 Support

We also saw many applications that do not support IPv6 at all. These range from minor, old tools (such as the Unix dict(1) command) to major applications that are important to our users (such as Skype) and even to entire classes of applications (many games have issues).

Protocol, Format, and Content Problems

There are a number of protocols that carry addresses in them, and using these protocols through a translator can lead to problems. In our current network setup we did not employ any Application Layer Gateways (ALGs) except for FTP. However, we have observed a number of protocol issues with IPv4 addresses. For instance, some instant messaging services do not work due to this. Finally, content on some web pages may refer to IPv4 address literals (i.e., plain IP addresses instead of host and domain names). This renders some links inaccessible in an IPv6-only network. While this problem is easily quantifiable in a theoretical sense, the authors have only run into it once during real-life web browsing.

Firewall Issues

We also saw a number of issues related to lack of features in IPv6 support in firewalls. In particular, while we did not experience any MTU and fragmentation problems in our networks, there is potential for generating problems, as the support for IPv6 fragment headers is not complete in all firewalls and the NAT64 specifications call for use the fragment header (even in situations where fragmentation has not yet occurred).

In general, most of the issues relate to poor testing and lack of IPv6 support in some applications. IPv6 itself and NAT64 did not cause any major issues for us, once our setup and NAT64 software was stable. In general, the authors feel that with the exception of some of these applications, their experience of translation to reach the IPv4 Internet has been equal or better than their past experiences of NAT44-based Internet access. While translation implies loss of end-to-end connectivity, in practice such connectivity has not been available to the authors in the IPv4 Internet for a number of years.

It should be noted that the experience with a properly configured set of ALGs and work-arounds such as proxies may be different. Some of the problems we encountered can be solved through these means. For instance, a problematic application can be configured to use a proxy that in turn has both IPv4 and IPv6 access.

5.  Experiences with IPv6-Only Networking

The overall experience was as explained above. The remainder of this section discusses specific issues.

5.1.  Operating Systems

Even operating systems have some minor problems with IPv6. For example, in Linux RA information was not automatically updated when the network changes while the computer is on, in Ubuntu and Mac OS X the network manager needed to be explicitly told to not expect IPv4, RA-based DNS discovery does not come as default setting in Ubuntu, and on Microsoft Windows 7 we experienced problems when relying on default, well-known DNS server addresses. With manual configuration, the host was unable to use the DNS addresses, even though the system displays them as current DNS server addresses.

5.2.  Instant Messaging

By far the biggest complaint in our group of users was that Skype stopped working. In some environments even Skype can be made to work through a proxy configuration, and this was verified in our setting but not used as a permanent solution. More generally, we tested a number of instance messaging applications on IPv6 and the test results can be found from Table 1.

SYSTEM                                 STATUS
Facebook on the web (http)               OK
Facebook via a client (xmpp)             OK
Jabber.org chat service (xmpp)           OK
Gmail chat on the web (http)             OK
Gmail chat via a client (xmpp)           OK
Gtalk client                           NOT OK
AIM (AOL)                              NOT OK
ICQ (AOL)                              NOT OK
Skype                                  NOT OK
MSN                                    NOT OK


Table 1. Instant Messaging Applications in an IPv6-Only Network

Packet tracing revealed that the issues in AIM, ICQ, and MSN appear to be related to passing literal IPv4 addresses in the protocol. It remains to be determined whether this can be solved through configuration, proxies, or ALGs. The problem with the Gtalk client is that the software does not support IPv6 connections at this moment. We are continuing our tests with additional applications such as Webex and Sametime, but at this moment we have either not completed the work or have inconclusive results. One problem in running these tests is to ensure that we can distinguish IPv6 and NAT64 issues from other issues, such as a generic issue on a given operating system platform.

5.3.  Gaming

Another big class of applications that we tried was games. We tried both web-based gaming and standalone gaming applications that have a "network" / "Internet" or "LAN" gaming modes. The results are shown in Table 2.

SYSTEM                                           STATUS
Web-based (e.g. armorgames)                        OK
Runescape (on the web)                           NOT OK
Flat out 2                                       NOT OK
Battlefield                                      NOT OK
Secondlife                                       NOT OK
Guild Wars                                       NOT OK
Age of Empires                                   NOT OK
Star Wars: Empire at War                         NOT OK
Crysis                                           NOT OK
Lord of the Rings: Conquest                      NOT OK
Rome Total War                                   NOT OK
Lord of the Rings: Battle for Middle Earth 2     NOT OK

Table 2. Gaming Applications in an IPv6-Only Network

Most web-based games worked well, as expected from our earlier good general web experience. However, we were also able find some web-based games, such as Runescape that failed to work. This particular game is a Java application that fails on a HTTP GET request. The reason remains a unclear, but a likely theory is the use of an IPv4-literal in the application itself.

However, experience with standalone games was far more discouraging. Without exception all games failed to enable either connections to ongoing games in the Internet or even LAN-based connections to other computers in the same IPv6-only LAN segment. This is somewhat surprising, and the result require further verification. Unfortunately, the games provide no diagnostics about their operation, so it is hard to guess what is going on. It is possible that their networking code employs older APIs that cannot use IPv6 addresses. The inability to provide any LAN-based connectivity is even more surprising, as this must mean that they are unable to use even IPv4 link local connectivity. (IPv4 was not blocked; just that no DHCP answers were provided on IPv4.)

5.4.  Appliances

There are also problems with different appliances, e.g., webcams using IP networking, since many of them do not support IPv6 and hence will not work in an IPv6-only network. Also all firewalls, both hardware and software-based, do not support IPv6 or experience issues with some aspects of IPv6 such as fragments.

6.  Experiences with NAT64

After correcting some initial bugs and stability issues, the NAT64 operation itself has been relatively problem free. There have been no unexplained DNS problems or lost sessions. The user experience has been in line with using IPv4 Internet through a NAT44 device, if one does not take into account issues discussed in the previous section around things that do not work in these types of networks at all (often failing before even attempting any communications). These failures are clearly very different from the IPv4 experience.

The rest of this section discusses our measurements on specific issues.

6.1.  IPv4 Address Literals

While browsing in general works, IPv4 literals embedded in the HTML code may break some parts of the web pages when using IPv6-only access. This happens because the DNS64 can not synthesize AAAA records for the literals since the addresses are not queried from the DNS. Luckily, the IPv4 literals seem to be fairly rarely encountered, at least so that they would be noticed, with regular surfing.

We have attempted to measure the likelihood of running into an IPv4 literal in the web. To do this, we took the top 1,000 and 10,000 web sites from the Alexa popular web site list. With 1000 top sites, 0.2% needed an IPv4 literal to render all components in their top page (i.e., images, videos, JavaScript and Cascading Style Sheet (CSS) files, etc.). With 10.000 top sites, this number increases to 2%.

However, it is not clear what conclusions can be made about this. It is often the case that there are unresolvable or inaccessible components on a web page anyway for various reasons, and to understand the true impact we would have to know how "important" a given page component was. Also, we did not measure the number of links with IPv4 literals on these pages, nor did we attempt to search the site in any thorough manner for these literals.

As noted, personal anecdotal evidence says IPv4 literals are not a big problem. But clearly, cleaning the most important parts of the web from IPv4 literals would be useful. With tools such as the popular web site list, some user pressure, and co-operation from the content providers the most urgent part of the problem could hopefully be solved as a one-time effort.

6.2.  Comparison of Web Access via NAT64 to Other Methods

We also compared how well the web works behind a NAT64 compared to IPv4-only and native IPv6 access. For this purpose, we used wget to go through the same top web site lists as in section Section 6.1 (IPv4 Address Literals), again downloading everything needed to render their top page. The tests were repeated and an average was calculated over all runs. Separate tests were done with an IPv4-only network, an IPv6-only network, and an IPv6-only network with NAT64.

In our tests, when accessed with an IPv4-only network, 1.9% of the sites experienced some sort of error or failure. The failure could be that the whole site is not accessible, or just that a single image (e.g., advertisement banner) was not loaded properly. It should also be noted that access through wget is somewhat different to access via a regular browser: some web sites refuse to serve content to other applications than known real web browsers, browsers typically have DNS heuristics to fill in "www." in front of a domain name where needed, and so on. In addition to missing advertisement banners, temporary routing glitches and other mistakes, these differences also help explain the reason for the high baseline error rate in this test.

When we tried to access all the same sites with native IPv6 (without NAT64), 96% of the sites failed to load correctly. This was as expected, given that most of the Internet content is not available on IPv6. The few exceptions included, for instance, sites managed by Google.

When the sites were accessed from IPv6-only network via a NAT64 device, the failure rate increased to 2.1%. Most of these failures appear to be due to IPv4 address literals, and the increased failure rate matches that of IPv4 literal occurrence in the same set of top web sites. With the top 10,000 sites the failure rate with NAT64 increases similarly to our test on IPv4 address literals.

6.3.  Response Times

One important set of measurements remains for future work, however. It would be useful to understand the effect of DNS64 and NAT64 to response time and end-to-end communication delays. Some users have anecdotal reports of slow web browsing response times, but we have been unable to determine if this was due to the IPv6-only network mechanisms or for some other reason. Measurements on pure DNS response times and packet round-trip delays does not show a significant difference to a NAT44 environment.

It would be particularly interesting to measure delays in the context of dual stack vs. NAT64-based IPv6-only networking. With dual stack, broken IPv6 connectivity can be repaired by falling back to IPv4 use. With NAT64 this is not always possible as discussed in Section 3.2 (DNS Operation).

7.  Conclusions and Recommendations

The main conclusions so far indicate that it is possible to employ IPv6-only networking. For large classes of applications there are no downsides, the downsides are negligible, or that there are benefits such as enabling direct connectivity to all devices in a home network from anywhere in the Internet. We have been unable to spot any practical difference in the web browsing experience, for instance. There are, however, a number of issues as well such as lack of IPv6 support in some applications or bugs in untested parts of code.

Our experience with IPv6-only networking confirms that dual stack should still be our recommended model for general purpose networking at this time. But IPv6-only networking can be employed by early adopters or highly controlled networks. One example such controlled networks are mobile networks with operator-driven selection of handsets. For instance, on some handsets that we tested we were unable to see any functional difference between IPv4 and IPv6.

Our recommendations apply at the present time. With effort and time, deployment barriers can be removed and IPv6-only networking becomes applicable in all networking situations.

But such a change does not come without the community spending effort. We have identified a number of actions that should be taken to improve the state of IPv6-only networking. These include:

DNS Discovery

The state of DNS discovery continues to be one of the main barriers for easy adoption of IPv6-only networking. Since DNS discovery is not a problem in dual stack networking, there has been too little effort in testing and deploying the necessary components. For instance, it would be useful if RA-based DNS discovery came as a standard feature and not as an option in Linux. Our hope is that ongoing standardization of the RA-based DNS discovery at the IETF will help this happen. Similar issues face other operating systems. The authors believe that at this time, prudent operational practices call for maximizing the number of offered automatic configuration mechanisms in the network side. It might be useful for an IETF document to provide guidance on operating DNS in IPv6-only networks.

Network Managers

Another key software component are the various network management and attachment tools in operating systems. These tools generally have the required functionality, but do not always appear to have been tested very extensively on IPv6 or let alone IPv6-only networks. Further work is required here.

Application Support

But by far the most important action for at least our group of users would be to bring some key applications to a state where they can easily run on IPv6-only networks and behind a NAT64. For instance, instant messaging and VoIP applications and games. In some cases it may also be necessary add support for new types of ALGs.

IPv4 Literals

The web should be cleaned from IPv4 literals.

Measurements and Analysis

It is also important to continue with testing, measurements, and analysis of what Internet technology works in IPv6-only networks, to what extent, at what speed, and where the remaining problems are.

Guidelines

It is also useful to provide guidance for network administrators and users on how to turn on IPv6-only networking.

As can be seen from the above list, there are only minor things that can be done through standardization. Most of the effort is practical and centers around improving various implementations.

8.  Security Considerations

The use of IPv6 instead of IPv4 by itself does not make a big security difference. The main security requirement is that, naturally, network security devices need to be able to deal with IPv6 in these networks. This is though already required in all dual-stack networks. As noted it is important to ensure firewall capabilities, for instance.

In our experience many of the critical security functions in a network end up being on the dual stack part of the network anyway. For instance, our mail servers obviously still have to be able to communicate with both the IPv4 and IPv6 Internet, and as a result they and the associated spam & filtering components are not in the IPv6-only part of the network.

9.  IANA Considerations

This document has no IANA implications.

10.  References

10.1. Normative References

10.2. Informative References

Appendix A.  Acknowledgments

The authors would like to thank the many people who have engaged in discussions around this topic, and particularly the people who were involved in building some of the new tools used in our network, our users who were interested in going where only few had dared to venture before, or people who helped us in this effort. In particular, we would like to thank Martti Kuparinen, Tero Kauppinen, Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and Cameron Byrne.

Authors' Addresses