World IPv6 Day Call to Arms
draft-chown-v6ops-call-to-arms-00

Abstract

The Internet Society (ISOC) has declared that June 8th 2011 will be World IPv6 Day, on which organisations are being encouraged to test their production IPv6 deployment capability. Many significant content providers and networks have stated they will take part. Given this date is likely to see more IPv6 traffic flowing across the Internet than has ever been seen before, it seems timely to issue a call to arms to review the status of ongoing open issues in IPv6 deployment. In this discussion document we list identified issues in IPv6 operations that may give rise to observed problems on June 8th. The World IPv6 Day should also create an excellent opportunity to observe the behaviour and performance of IPv6; it is thus very desirable to have appropriate measurement tools in place.

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on September 08, 2011.

Copyright Notice

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

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

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Introduction
• 2. Connectivity
• 2.1. Unmanaged Tunnels
• 2.2. Connection Timeouts
• 2.3. PMTU Discovery
• 2.4. Rogue Router Advertisements
• 3. Instrumentation
• 3.1. IPv6 traffic levels
• 3.2. Client Web Access Success Rate
• 3.3. IPv4 Performance Comparison
• 4. IPv6-only testing
• 5. Conclusions
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgments
• 9. References
• Author's Address

1. Introduction

Despite the recent exhaustion of the available IPv4 address pool, deployment of IPv6 remains limited. To help encourage organisations to trial production deployment, ISOC has declared June 8th 2011 as World IPv6 Day. Organisations are encouraged to use this day to test IPv6 in production, either by enabling clients in their network, or by making externally-facing services available over IPv6. This does not generally mean turning off IPv4 at this stage, rather enabling dual-stack networking. However IPv6-only networks are inevitable, and some sites may choose to use June 8th to undertake some focused tests on that deployment model.

The purpose of this document is two-fold. One is to discuss common IPv6 deployment issues that are likely to arise on June 8th, with a focus on dual-stack deployment (which is likely to be how the vast majority of sites take part). This should help raise awareness of those problems and possible mitigations. The other is to encourage organisations to think about how they might get useful instrumentation on what happens in and to/from their networks on the day. Such measurement tools are likely to also be useful longer term - once deployed they could be left in place.

For most sites providing content, June 8th will be a chance to make some public facing services available over IPv6, such as web content using their production domain (e.g. www.example.com) rather than a contrived IPv6 test domain (e.g. www.ipv6.example.com). Some enterprise sites may choose to enable IPv6 in user/client subnets, in which case the performance of those systems and the applications they run will be of paramount interest.

This document is not intended to cover all IPv6 deployment issues, e.g. debates on DHCPv6 versus RAs, rather to focus on those that affect IPv6 connectivity, to raise awareness of these, and potential mitigations.

NB. This is a very rough first draft of the document; feedback is welcomed. The scope of the document is purely informational to provoke discussion.

2. Connectivity

In this section we review causes of some common connectivity issues.

2.1. Unmanaged Tunnels

One cause of connectivity problems is the use of unmanaged tunnels, in particular 'automated' methods that are not provisioned by the user's ISP. The most common example is 6to4 [RFC3056], or more specifically the 6to4 relay approach described in [RFC3068]. If a host in a native IPv6 network has no route to 2002::/16 it cannot respond to 6to4 traffic it receives. Similarly, a 6to4 router that cannot reach the well-known IPv4 anycast relay address cannot respond to traffic it receives from native IPv6 networks.

One approach to this problem is to encourage sites/ISPs to run local relays, as discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory]. The alternative to reduce such problems is simply to obsolete 6to4, as proposed in [I-D.troan-v6ops-6to4-to-historic].

It is worth noting that IPv6 tunnel brokers, such as those provided by SixXS (http://www.sixxs.net) and Hurricane Electric (http://tunnelbroker.net) provide a more robust, managed approach to IPv6-in-IPv4 tunnelled access.

2.2. Connection Timeouts

Where dual-stack systems - or rather the applications running on them - have a choice of IPv4 or IPv6 connectivity, timeouts can occur if there is no connectivity on the preferred protocol. For example, if a AAAA DNS record exists for a web server, and IPv6 connectivity is broken, there is likely to be some timeout for the browser before the connection drops back to IPv4.

The author has undertaken some informal tests at his own site, which shows that shows how different operating systems handle ICMP unreachables. On Linux, web connections timeout after 20 seconds for 'no response', but immediately for unreachables. In contrast, Windows Vista was 20 seconds regardless of unreachables being received. Any non-trivial delay will cause significant user frustration.

An interesting solution to the problem is the 'happy eyeballs' approach described in [I-D.ietf-v6ops-happy-eyeballs]. This approach is now also being suggested for multiple interface systems. However some people feel this 'workaround' is simply masking underlying problems that should be fixed.

2.3. PMTU Discovery

IPv6 mandates that fragmentation is only undertaken by the sending node, and thus IPv6 requires working PMTU Discovery. An existing RFC gives Recommendations for Filtering ICMPv6 Messages in Firewalls [RFC4890]. If this guidance is not followed, connectivity problems are likely to arise. Blindly filtering all ICMPv6 messages is not good practise. The minimum MTU for IPv6 is 1280 bytes.

2.4. Rogue Router Advertisements

Within a site, hosts may use IPv6 Stateless Address Autoconfiguration (SLAAC). However, it is possible for accidental (or malicious) rogue RAs to cause connectivity issues, as described in Rogue Router Advertisement Problem Statement [RFC6104].

One solution to this problem is RA Guard [RFC6105], another is use of SEcure Neighbour Discovery (SEND) [RFC3971]. However neither of these is widely implemented yet. Indeed, any reported operational experience of SEND in an enterprise network would be very welcome.

3. Instrumentation

In this section we discuss potential instrumentation approaches that may be configured for World IPv6 Day, and then retained longer term after the event.

3.1. IPv6 traffic levels

It should be possible to measure IPv6 traffic levels independently on dual-stack switch/router platforms, given implementations of appropriate MIBs.

Application level measurement is also desirable, e.g. the ability of web log analysis packages to differentiate IPv4 and IPv6 visits. If a site is making a specific application available for World IPv6 Day, it should be able to measure the IPv6 activity seen on that service.

3.2. Client Web Access Success Rate

There have been some recent studies on the capabilities of web clients to access content on dual-stack servers by IPv4, IPv6 or IPv6 in the presence of both A and AAAA records existing for a web domain.

This section will be expanded to include examples of measurement approaches.

3.3. IPv4 Performance Comparison

Where a dual-stack service is deployed, measuring the relative performance of both protocols is desirable. This may primarily be a measurement of throughput or delay, but may also include availability/uptime measurement.

Sites enabling IPv6 in clients should be aware that the volume of IPv6 traffic they may use on World IPv6 Day may be somewhat higher than normal, if in particular they are not part of the existing Google IPv6 programme and they start viewing all YouTube conent over IPv6. A site's IPv6 capacity should thus match its available IPv4 capacity; software tunneling of IPv6 over IPv4 may cause problems if traffic levels do rise significantly.

4. IPv6-only testing

The long-term IPv6 deployment plan is IPv6-only networking, rather than dual-stack. It is not clear how quickly significant IPv6-only networks will emerge, but testing of approaches to IPv6-only operation is desirable as soon as possible.

Some experience of NAT64 has been described in [I-D.tan-v6ops-nat64-experiences], though this appears to have used only NAT-PT so far. An implementation of NAT64 is available at http://ecdysis.viagenie.ca. Operational experience of IVI is also desirable. An implementation of IVI is available at http://www.ivi2.org/IVI.

5. Conclusions

With the ISOC World IPv6 Day event due on June 8th 2011, this document aims to help focus attention on both improving awareness and mitigations of common causes of IPv6 connectivity problems, and encouraging sites and organisations to introduce appropriate instrumentation into their networks so they can observe traffic behaviour appropriately.

This is the first version of the text, and is very drafty. All comments are very welcome.

6. Security Considerations

There are no extra security consideration for this document.

7. IANA Considerations

There are no extra IANA consideration for this document.

8. Acknowledgments

To be added.

9. References

Author's Address