The ISP Column
An occasional column on things Internet
Transitioning Protocols – Part 1
In a previous article, in November 2010, I looked at some common myths associated with the transition to IPv6. This month I'd like to look behind the various opinions and perspectives about this transition, and look in a little more detail at the nature of the technologies being proposed to support the transition to IPv6.
After some time of hearing dire warnings about the imminent exhaustion of the stocks of available IPv4 address space, we've now achieved the first milestone of address exhaustion, the depletion of the central pool of IANA-managed address space. The last 5 /8s were handed out from IANA to the RIRs on the 3rd February. After some years of industry-wide general inattention and inaction with IPv6 perhaps it's not unexpected to now see a panicked response along the lines of "Maybe we should do something now!"
But what exactly should be done? It's one thing to decide to "support" IPv6 in a network, but quite another to develop a specific plan, complete with specific technologies, timelines, costs, vendors, and a realistic assessment of the incremental risks and opportunities. While working through some of this detail has the normal levels of uncertainty that you would expect to see in any environment that is undergoing constant change and evolution, an additional level of uncertainty here is a by-product of the technology itself.
There's not just one approach to adding support for IPv6 in your network, but many. And it's not just one major objective you need to address, namely incremental deployment of IPv6 as second protocol into your operational network without causing undue disruption to existing services, but two, as the second challenging objective is how to fuel continued growth in your network service platform when the current supply lines of readily available IPv4 addresses effectively dry up.
The good news is that many folk have been busy thinking about these inter-twined objectives of extending the useful lifetime of IPv4 in the Internet and simultaneously undertaking the IPv6 transition, and there are a wealth of possible measures you can take, and a broad collection of technologies you can use. Fortunately, we are indeed spoilt with choices here!
The not so good news is that many folk have been busy thinking about these inter-twined objectives, and there are a wealth of possible measures you can take, and a broad collection of technologies you cans use. These options may, or may not, be optimal for your particular circumstances, and may, or may not, be useful for you in mitigating address depletion and may, or may not, be consistent with your chosen longer term network objectives. Unfortunately, we are spoiled for choices here!
Let's have a look at each of the major transitional technologies that are currently in vogue, and look at their respective strengths and weaknesses and their intended area of applicability. In this column we'll look at this from the perspective of the end user. In the next part of this article we'll look at this from the other side, looking at options for ISPs.
If your service provider provides a dual stack service with both IPv6 and IPv4 then your task should be relatively straightforward. Configure your modem/router with IPv6 in addition to IPv4 and you are done, assuming of course that your local modem/router unit actually supports IPv6, which may not be the case in many of the older and, unfortunately, all too many of the currently available devices.
The conventional approach in this form of environment is to use IPv6 Prefix Delegation, where the ISP provides the client with an IPv6 prefix, usually a /48 or a /56 IPv6 address prefix, which is then passed into the client network via an IPv6 Router Advertisement. Local hosts should be configured to configure their IPv6 stack automatically, and your system should be connected as a dual protocol system.
There are, however, some caveats you probably need to be aware of, of which the most important difference is likely to relate to the probable absence of a NAT function in IPv6. These days most commercial IPv4 Internet services assign a single IP address to each client. To allow this address to be shared within the client's network, most IPv4 'edge' devices auto-configure themselves as a NAT device, permitting outgoing connections using TCP, UDP, and allowing some ICMP message types to traverse the NAT, but not much else. For many clients this NAT configuration becomes the default local security framework, as it permits outbound connections via TCP and UDP to be made, but not much else, and permits no sessions to be initiated as incoming sessions. With iPv6 the local network is probably going to be configured with an entire subnet, and instead of a NAT, this subnet will be directly connected to the Internet.
The local network is then in a mixed situation of being behind a NAT in IPv4, but being directly connected to the Internet using IPv6. This asymmetric configuration with respect to IPv4 and IPv6 raises some questions about the impact to the security of your local network. You need to think about adding appropriate filter rules to the gateway's IPv6 configuration that performs the same level of access control to your local site that you have already set up with IPv4 and the NAT. The best advice here is the need to configure some filter rules for IPv6 that limit the extent of exposure of your internal network to the broader Internet to be directly comparable to the configuration you are using with IPv4.
Even today, when the IPv4 pools are running dry, its really not very common to have an ISP offering dual stack IPv4 and IPv6 services. Lets look at the more common situation when your ISP is still only offering IPv4. As an end user, can you still set up some form of IPv6 access?
The answer is "Yes", but you are going to have to resort to tunnels, and the story can get somewhat ugly.
If you have public IPv4 addresses on your local network you may elect to configure your local system to use the 6to4 tunnelling protocol.
In general, 6to4 is a relatively poor approach to provisioning IPv6, and really should be avoided if at all possible. Indeed, the user experience will probably be better overall if you stay running IPv4 and avoid accessing IPv6 via 6to4.
The major issue here is that a successful connection relies on the assistance of both an outbound and an inbound 6to4 third party relay. On the IPv4 side a 6to4 connection relies on the presence of a useable route to a IPv4-to-IPv6 relay, and preferably one that is as close as possible to the IPv4 endpoint. On the IPv6 side a 6to4 connection relies on a useable relay advertising a route to 2002::/16. Again, to avoid extended path overheads, this relay should be as close as possible to the IPv6 endpoint. This path asymmetry can cause connection 'black holes' where one party can deliver packets to the other but not the reverse.
Also, such configurations have problems if the IPv4 host is configured with stateful filters that insist that the IPv4 source address in incoming packets match the destination address of outgoing packets, which is not necessarily the case in a 6to4 connection.
Finally, it seems that many sites operate with firewall filters that disallow incoming packets other than TCP and UDP (and possibly some forms of ICMP). 6to4 packets using protocol 41, and there appears to be widespread use of filter rules that block such packets.
Tunnelling also adds an additional packet header to a packet, which inflates the size of the packet. Such an expansion of the packet on certain path elements of the network may cause path packet size issues, increasing the risk of encountering path MTU 'black holes' due to the increase of the packet size by 20 bytes when the IPv4 packet header is attached to the packet.
If the local network is behind an IPv4 NAT, and the NAT gateway does not support 6to4, then all is not lost, as there is another form of tunnelling that could be a possible answer. Teredo is described in RFC 4380.
Teredo represent a different set of design trade-offs as compared to 6to4. In its desire to be useful in an environment that includes NATs in the IPv4 path Teredo is a per-host connectivity approach, as compared to 6to4's approach which can support both individual hosts and entire end sites within the same technology. Also, Teredo is a host-centric multi-party rendezvous application, and Teredo clients require the existence of dual stack Teredo servers and relays that exist in both the public IPv4 and IPv6 networks. Teredo is more of a connectivity tool than a service solution, and one that is prone to many forms of operational failure.
On the other hand, if you are an isolated IPv6 host behind an IPv4 NAT, and you want to access the IPv6 network then 6to4 is not an option, and you either have to set up static tunnels across the NAT to make it all work, or you can turn on Teredo in your dual stack host and you if everything goes according to theory, you should be able to establish IPv6 connectivity.
In contrast to these auto-tunnel approaches, the simplest form of tunnelling IPv6 packets over an IPv4 network is the manually configured IPv6-in-IPv4 tunnel.
Here an IPv6 packet is simply prefixed by a 20 octet IPv4 packet header. In the outer IPv4 packet header the source address is the IPv4 address of the tunnel ingress, the destination address is the IPv4 address of the tunnel egress and IP protocol field uses value 41, indicating that the payload is an IPv6 packet. The packet is passed across the IPv4 network from tunnel ingress to egress using conventional IPv4 packet forwarding, and at the egress point the IPv4 IP packet header is removed and the inner IPv6 packet is routed in an IPv6 network as before. From the IPv6 perspective the transit across the IPv4 network is a single logical hop.
Alternatively, like VPN tunnels, the tunnel can be configured using UDP or TCP, and with some care, the tunnel can be configured through NATs in the same way as VPN tunnels can be configured through NATs.
The advantage of this approach is that the need to manually configure the tunnel endpoints ensures that the tunnel relay function is not provided, intentionally or unintentionally by third parties through some well-intentioned, but ultimately random, act of goodwill. The need to perform a manual configuration also reduces the chances that the tunnel is broken through local firewall filters. Of course the need to perform a manual configuration does not lend itself to a plug-and-play environment, nor is this a viable approach for a larger mass market of consumer devices and services.
None of these approaches to offer IPv6 connectivity to end hosts behind an IPv4-only service provider offer the same level of robustness and performance as compared to native IPv4 services. All of these approaches require a significant degree of local expertise to set up and maintain, and often require a solid understanding of other aspects of the local environment, such as firewall and filter conditions and path MTU behaviour to maintain. With the exception of the tunnel broker approach, they also require third party assistance to support the connection, which further adds to the set of potential performance and reliability issues.
It appears that the most robust and reliable way to provision IPv6 to end hosts is for the service provider to provision IPv6 as an integral part of their service offering, and offer clients a dual stack service in both IPv4 and IPv6.
In the second part of this article we'll look at the options for service providers to provision dual stack services to their clients.
The above views do not necessarily represent the views of the Asia Pacific Network Information Centre.
GEOFF HUSTON is the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region.