A paper by Trefor Davies and Chris Nicholls
Regular readers of this blog will know that we, the world, are about to run out of the IPv4 addresses that are absolutely crucial to the running of the internet. This notionally apocalyptic event is almost certain to happen over the next three months, maybe even two.
The allocation of IP addresses is managed by an organisation called IANA (Internet Assigned Numbers Authority). IANA hands out these numbers in /8 blocks containing 16,777,216 addresses. Clearly you would have to be a big network provider to need 16 million IP addresses. Because of this IANA hands these large blocks to five regional registries that then manage the distribution of smaller blocks to their customers. In Europe the regional registry is called RIPE NCC.
Whilst I have myself been guilty of (playfully) scaremongering in respect of the exhaustion of the pool of Ipv4 addresses, it is only really IANA that is about to run out. RIPE will not run out for perhaps another year and even after that individual ISPs will have their own existing unused addresses to play with.
Notwithstanding this it behoves all ISPs and network operators to get their house in order with Ipv6 which is the long since identified answer to the problem. Ipv6, a 128 bit protocol supports 2128 (about 3.4×1038) addresses compared the 32 bit IPv4 which only provides 4,294,967,296 (232) . IPv6 is expected to serve us for a very long time.
Few ISPs in the UK have announced IPv6 support. As we approach the IANA Apocalypse I thought I would share with you the engineering work that we have been doing at Timico in respect of IPv6
Timico has been running IPv6 as part of our internal research and development activity for a number of years. The core of the network has been running dual stack IPv4 and IPv6 with external connectivity to the rest of the internet for most of this time. Attempts thus far to bring these services to our customers have been limited due to the lack of demand, vendor support and our core IPv4 operations taking precedence.
Now that IPv4 exhaustion is becoming a reality and IPv6 is maturing more network providers are starting to work seriously with it. In fact apart from the larger number of addresses IPv6 is a much improved protocol over IPv4 with attractive features such as such as stateless auto-configuration, mobile IP, and built-in multicast that are of real interest
Deployment at Timico
Here at Timico our IPv6 deployment has been undergoing consistent evolution since early 2004, the year I got my first IPv6 address on my home DSL router. Rollout plans have been put in place in line with current industry standards and best practice. The biggest restraining factor for IPv6 was until relatively recently limited vendor support.
Early deployment consisted of turning up a native IPv6 service on the Timico backbone, joining UK6x (a BT sponsored IPv6 Internet exchange), interconnecting with other networks for external reachability, and testing with any equipment claiming support for the protocol..
Early attempts of xDSL deployments around 2005 caused unforeseen issues with domestic CPE equipment, causing frequent reconnections and/or loss of sync. The problems were also compounded by issues with passing IPv6 through BTs 20cn network which truncated the v6 packets. These issues were enough to hold us back from any scale deployment.
At the end of 2010 the situation has improved greatly. Vendor support is on the up and more content is being added to the IPv6 internet. The main core of the protocol’s standards have solidified, and over the last year we have been polishing our deployment practices for what will become our next-generation core. Most of the remaining work concerns policy for such things as customer allocation plans, new products etc.
Where are we now – present state of play?
The core of the Timico network currently runs dual stack IPv4 and IPv6 with good external connectivity to hundreds of networks and multiple Internet exchanges. We have full support for IPv6 over MPLS including support for a range of access network types – leased lines/Ethernet circuits and xDSL capabilities (BT 21CN only). We also have customers today using a tunnelled service over their DSL in which we use GRE(protocol 41) tunnels to present native IPv6 to the customer. Our monitoring systems and services such as DNS are also enabled.
The dual stack approach has been the best means of not only getting connectivity throughout the core, but to also gain operation experience and test vendor support. A native IPv6 service is far easier to work with than a system of tunnels or transition mechanisms. Running both protocols at the same time on the same equipment has had many benefits and as the IPv4 and IPv6 behave independently of one another we can safely work on one side of the fence without affecting the other. This system has the added benefit for us in that our IPv6 network topology exactly mirrors our IPv4 topology.
As an ISP we are in the business of connecting people to the internet – ie to other ISP networks. Having obtained an IPv6 allocation from RIPE our first task was to start interconnecting with other networks and gain operational experience with IPv6 routing.
We were present at UK6x, and since the closure of that project have continued to build on the lessons learned. We maintain hundreds of BGP peering sessions with other IPv6 enabled networks big and small, and are proud to maintain a full IPv6 routing table that today consists of somewhere around 3,500 routes. This compares with around 332,000 routes in the Timico IPv4 routing table.
Note we are not comparing like for like in respect of the number of routes. The IPv4 address pool is far more segmented and thus more inefficient leading to the need for more routes.
As an aside 5 years or so ago Timico had to upgrade its core routers to accommodate the fact that the routing table had grown beyond 180,000 routes.
MPLS forms a big part of our core and is the basis upon which Timico’s Private Wide Area Network (PWAN) proposition is delivered. MPLS and IPv6 are two important technologies that need to interoperate and this is currently effected using 6PE – an MPLS technology that allows the manipulation of IPv6 akin to that of IPv4. Mobile IPv6 MPLS services will also be of great interest downstream.
Systems and Infrastructure
Our systems fully support IPv6. Although there are currently no public facing deployments, value added customer services such as e-mail and web hosting are undergoing major platform overhauls will support IPv6 in the near future.
Timico’s main infrastructure enabling customer connectivity and monitoring are all IPv6 enabled. Our anycast DNS platform also fully supports native IPv6.
There are still several areas where systems software has not caught up with networking infrastructure, and is something we keep a close eye on. Products such as the popular MySQL database don’t fully support IPv6 and as such can make implementation a complex process.
The scarcity of IPv4 resources has lead to the implementation of IP address allocation policies geared towards the preservation of addresses. Techniques such as Classless Inter-Domain Routing (CIDR – replaced Classful IPv4 routing in 1993 is now a standard for both v6 and v4), where classful has been deprecated and Network Address Translation (NAT) have been the stock tools of the trade. Whilst NAT has become standard for IPv4 they are not required for IPv6. This gives rise for the need to reconsider deployment policies for IPv6 including the approach to network security
At Timico we want to develop a customer facing service that satisfies the customer’s requirements for size of allocation, ease of management, security, and support. We don’t believe it is down to us to dictate a policy that restricts the customers ability to use the tools provided and ultimately the service they are paying for. These goals are easier to achieve in some access networks than others. Leased lines, fixed Ethernet services and the majority of our MPLS and PWAN solutions can be IPv6 enabled by Timico today!
xDSL services are still undergoing considerable lab testing in order to ensure quality and that the services customers pay for are fully dependable. As such xDSL services using IPv6 are currently only provided on a best-efforts basis.
Our IPv4 > IPv6 transition plans for services look like this:
- Set up a lab; fill this with as many devices represented within use today as possible.
- Allow technical staff time to test, and express ideas, and encourage them to use IPv6 wherever possible- for example tunnelled access at home etc.
- Distribute IPv6 knowledge throughout technical departments.
- Upgrade/Enable DNS services where possible to enable resolution natively over IPv6.
- Enable IPv6 throughout links within the network, taking care not to impact current IPv4 servers, clients and business processes.
- Dual stack internal servers so that they support both protocols, and use to test internal application support with selected internal clients.
- Deploy internally with the help of DNS records, enabling IPv6 connected clients to use IPv6 services natively. IPv4 will still be very common regarding external connectivity for some time to come so dual stack on these clients will still be essential.
- Once testing of applications, systems and network links has been considered stable and well supported for some time, initiate a move to make IPv6 the primary source of connectivity.
Over the next few years we envision a slow and steady uptake of more and more IPv6 based services. Our biggest concern currently is the ability of our customers to interact with networks and organizations that come online in the near future that are unable to gain IPv4 address resources. Because of this we are working on means for our customers to transparently communicate with both networks, with zero effort on the customers part. This will require us and many other networks to include one or several of the following transition mechanisms.
There are many ways in which to fill the gaps during transition, and consideration needs to be paid to the various methods as moving from one protocol to the other will be a matter of years, thus all options should be considered and the “best tool” for the job must be selected for each case that arises.
Some examples are:
• Native IPv6,
This is the most straightforward means; apply to your provider of choice for an allocation, whether for purely internal testing or bundled with some form of connectivity. This may require the organizations edge to be dual stacked where possible.
• Automatic Tunneling (6to4)
This method allows isolated IPv6 networks to communicate via an IPv4 infrastructure. It enables a 6to4 node or network to speak to other 6to4 nodes or networks and communicate with native IPv6 networks. 6to4 uses a globally routable IPv4 address and an IPv6 prefix to generate a routable IPv6 address for communication.
Teredo is tunnel designed to connect nodes behind IPv6 NAT devices using IPv6 in IPv6 UDP which are tunnelled over the IPv4 internet. Basically Teredo is IPv6 in IPv4 UDP.
Several other mechanisms are available that achieve similar goals via different means, and all have their place, the newest of these being 6RD. However, these will require support at the customer edge as well as within a providers network. A more comprehensive list can be found at http://en.wikipedia.org/wiki/IPv6_transition_mechanisms
IPv4 and IPv6 are similar in many ways and learning IPv6 should come easily for most v4 savvy engineers – routing and packet handling are all similar. However new concepts like auto-configuration, neighbour discovery, address planning and sub-netting can be cryptic and have unexpected results for engineers.
For this reason, lab tests are invaluable for reinforcing these principles in a safe environment. Training should cover all systems and network disciplines, with departments sharing information interchangeably. The same also goes for sharing with other organizations, as this often leads to a win-win situation.
The implementation of IPv6 has not been difficult. Starting early allowed us to continually update plans, evolve deployment practices, and budget for new features/software/hardware as they have become available.
We are aiming to work closely with selected customers in order to better understand end users’ requirements and share experience on this new technology, with the aim of allowing both Timico and our customers to build better products and services based on real world situations.
• Transition methods http://en.wikipedia.org/wiki/IPv6_transition_mechanisms
• IPv6 http://en.wikipedia.org/wiki/IPv6
• SIXXS http://www.sixxs.net/main/
• IPv6 RFC2460 http://tools.ietf.org/html/rfc2460
• ND RFC2461 http://tools.ietf.org/html/rfc2461
• SLAAC RFC4862 http://tools.ietf.org/html/rfc4862
• Dual Stack Model RFC4241 http://tools.ietf.org/html/rfc4241
• IPv6 Theory, Protocol, and Practice 2nd Edition ISBN:1558608109
• IPv6 Essentials 2nd Edition ISBN:0596100582
• IPv6 Network Administration ISBN:9780596009342
Trefor Davies is CTO of UK ISP Timico
Chris Nicholls is an engineer in the Network Design team at Timico