A staged approach to rolling out IPv6/IPv4 dual stack is proposed, starting with easier services like DNS and email that are already IPv6 compatible, and testing the dual stack backbone. This allows costs to be spread out over time while gaining experience with IPv6. The suggested approach aims to make the transition to IPv6 seamless if started immediately.
This document is an introduction towards a step by step approach to IPv6 migration in a corporate network. Contrary to popular belief, IPv6 implementation is not the “great big unknown”. Done correctly, it can be a seamless process causing as little disruption as possible to a corporate network. Here’s how.
These are some of the questions we can all ask ourselves today.
The total Regional Internet Registry address allocation is the thick blue line. It is clear that this figure is rising.
The red line denotes the Internet Address Numbering Authority (IANA) pool of IPv4 addresses. The RIR pool of addresses starts declining 6-8 months after the IANA pool has reached NIL. Can you see how it’s all aiming to hit the ground? When it does, things will get painful.
Not developing a policy for IPv6 adoption in time, will make it a lot more “painful” when IPv4 addresses run-out. How averse to pain are you?
IPv6 implementation should not be a question of “if” but of “when”. Traditionally, the backbone was built first and services were then migrated. The trouble with this order of events is that a high entry cost in building the network is a barrier of entry. In the current economic climate and cost cutting, this is less acceptable to corporates.
So here’s a typical corporate network. Say, this is ACME Co.’s network, run by Joe the Plumber. Where do we start testing IPv6?
In a textbook roll-out, we build the backbone first, following the tradition of: design, build, implement. This means a large upfront investment with no initial wins. Great for a company with great cash reserves evolving in a boom market, but it might not be acceptable to shareholders in 2009.
It is the traditional way of implementing a network. Start with the plumbing, including getting IPv6 connection from the outside world, get your staff educated with IPv6, and then roll-out local services, including email, Web servers etc. Great in theory. In practice, there are no quick wins and early difficulty might slow down implementation, with no visible results.
Displaying the traditional roll-out order graphically, it is clear that the early steps, 1, 2, 3 are both costly and bear technical complexity. So-called “quick wins”, minimum cost, maximum effect implementations, only appear at stage 6, 7 and 8. By that time, so many hurdles have already appeared and there is friction between finance & engineering.
One common misconception is that migration to IPv6 needs to be done all at once. As a result, stumbling blocks with the more complex migration scenarios also hinder migration of services which might be easy to migrate. This is not an un-surmountable mountain! Like any strategic engagement, start with “quick wins”.
First things first: a network starts with a central router. So the first step is to get some of your backbone routers to run dual IPv4/IPv6 stacks. Start with a subset of your network. Your servers etc. will be able to link onto this. This “test network” is your first step to IPv6 adoption. This is also where you design your new numbering plan. Design it carefully!
Designing the numbering plan is very important. All addresses will be directly routable from the outside world, so you need to get it right. What you are doing here will influence your company’s network for the foreseeable future and should last well into the future. Remember sub-netting and make provisions for future services such as IP telephony etc.
The key to any network is DNS. Before you implement any kind of IPv6 network in your company, get your DNS server to run dual stack and include what’s called “IPv6 glue”, that is, it has an IPv6 address, and responds to queries on its IPv6 address. Once that works well, the ball is rolling.
Custom-written front end software is often used in Registrars, Registries, and larger corporate networks, in order to stop employees from doing things they should not do to the DNS. It might also be a Web interface. This will need to be re-written in order to accept IPv6 addresses.
Once your DNS is working on dual IPv4 / IPv6 stack, it’s time to get your E-mail servers running IPv6. Connect them to your IPv6 backbone and you’ve got a useful IPv6 network running.
The advantage of running E-mail servers with IPv6 is that it introduces some IPv6 traffic in your network, as well as with outside networks, but should any connection fail, traffic automatically falls back to IPv4.
So now you’ve got a test IPv6 network running, it’s time to get connected to the outside world. Traditionally, this is done using a Firewall and/or Network Address Translation (NAT), where most IPv4 addresses inside the network are not routable to/from the outside. Using NAT as a Firewall is *wrong*. There, I’ve said it.
Now that every IPv6 address is routable from/to the outside world, Firewall rules need to be precisely defined for each address and block of addresses. This is where security can be tightened, if done right. Make sure this is done correctly, because if not, this is where things are likely to go very wrong, resulting in network intrusions.
In an ideal world, every Internet Service Provider (ISP) would be offering IPv6 connectivity today (May 2009). Alas, the chicken and egg scenario plays a great part in the currently poor offering by ISPs. Ask for native IPv6 connectivity from your ISP, and soon enough they will offer it. In the meantime, use IPv6 tunneling in IPv4 – but only for smaller networks.
Once your company intranet is working, and there’s access to the outside world, and you’ve tested the network with a little bit of traffic, it’s time to step up to the next level by getting your Web Servers on the IPv4/IPv6 dual stack. The good thing is that by this stage, your IT personnel has already acquired some real IPv6 experience and exposure.
For standard Web servers, it’s pretty much straight forward. Complex systems with Load Balancing are more tricky. But then, if you have such a system, you’re relying on recent technology and critical applications require critical investment.
By then, most “off the mill” services will be running IPv4/IPv6 dual stack quite smoothly. It is time to attack the next challenge: database servers, some of which are legacy servers which might *never* be able to run IPv6.
The IPv6 – IPv4 NAT implementation will evolve into a small island of IPv4 connectivity in a few years, until that server will be replaced through natural replacement cycle.
Expanding your company’s intranet to run dual stack IPv4 / IPv6 is the next step. Please note that IPv6 runs on the same cables as IPv4. You can also start connecting a few client PCs through the network – probably your IT personnel.
Some hardware needs to be replaced. However, by that time, you and your network support staff have experience in implementing and running IPv4/IPv6 dual stack. Upgrading of local hubs can become integrated in the natural replacement cycle during standard maintenance periods.
It is finally time to get the bulk of the clients connected! By that time, they’re probably eagerly waiting to “get onto IPv6”. Why? Because this will open the door to the new VPN services in Windows 7 & MAC OSX – without requiring a VPN. It’s more secure and it requires less overheads.
The cost associated with this stage are directly related to the (lack of) investment in hardware & software end-user client systems. All new hardware & software will support IPv6 by the time you reach this stage, so costs might even be lower than they are estimated today. Unsupported Legacy software and hardware might be a problem.
After the testing phase, comes the full roll-out, bringing resilience to the IPv6 network cohabiting with the IPv4 network.
Experience acquired during the testing phase reduces risk during company-wide roll-out. Well done – your enterprise network now runs IPv6!
It is now time to connect all remaining devices to your IPv6 network. This might include specialized legacy servers for storage/applications which might require front-end IPv6 – IPv4 NAT. This might also include IP telephony, WIFI networks and any remaining device. Some services might take much effort to migrate, but at least you’ve not missed the boat.
Full IPv6 allows for a complete integration of all services, whether desktop computers, hand-held devices, sensors, cameras, telephones, and many others. Gradually, more devices will communicate using IPv6. Then, some will offer turning IPv4 off. This will start IPv4’s decline in some applications. Well done, you’ve completed the transition!
This is a summary of our proposal for steps required to transit from IPv4 to IPv6. It is a long road, so your organization needs to start now. For a smoother transition, count about 12 to 18 months, including time to train your staff to run an IPv6 network. Once you’re through it, you will never look back at IPv4 in the same way again.
This shows reduced early costs and ease of implementation in the early phases in order to kick-start transition to IPv6.
YES WE CAN!
We hope that this presentation has been helpful and look forward to see you on the IPv6 Internet! Please do not hesitate to contact us for professional services on IPv6 planning and implementation.
![IPv6 Roll-out Where do we start ? Olivier MJ Crépin-Leblond PhD http://www.gih.com/ocl.html - [email_address] Version 200908.1 © 2009 Global Information Highway Ltd](https://image.slidesharecdn.com/crepin-leblondipv6roll-out-090930120701-phpapp02/85/Suggestion-for-an-IPv6-Roll-Out-1-320.jpg)
![IPv4 address depletion ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],© 2009 Global Information Highway Ltd](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)