I've been in the Internet Service Provider business long enough to survive at least two waves of IPv6 urgency.
 |
|
|
|
|
It's very hard to find any non-vendor information about mobile IPv6 or any real-world deployment success stories.
Ivan Pepelnjak
Chief Technology Advisor, NIL Data Communications
|
|
|
|
|
|
|
|
|
|
The first happened almost 10 years ago, when projections of public IP address usage and Internet growth indicated that IPv4 addresses would run out in a few years. The scare, while resulting in IPv6 specifications, turned out to be a false alarm, as most enterprise customers and even some service providers started to use private IPv4 addresses and Network Address Translation (NAT) to overcome the shortage of public IP address.
The second "IPv6-is-coming-soon" call to action was caused by widespread deployment of mobile devices. It was expected that mobile phones with unique IP addresses would force everyone to convert to IPv6. After the initial flurry of activities, everyone went back to business-as-usual.
It's very hard to find any non-vendor information about mobile IPv6 or any real-world deployment success stories. Some interesting side effects of that scare included handset vendors implementing IPv6 in their high-end devices, so at least some handsets are IPv6-ready today. But obviously IPv6 is considered a non-issue. For example, it's impossible to figure out which Nokia phones support IPv6 (it's not listed in any comparison tables) unless you read the actual user's guide.
In recent months, the "IP addresses are running out" messages have become more common. It looks like it's for real this time. Most projections claim IPv4 addresses will get really scarce around 2010, according to the IPv4 address report and a year-by-year fractal map. Reusing already allocated but potentially unused public IP addresses could give us another five to 10 years.
Do you care about moving to IPv6?
Before answering, consider a few facts:
- IPv4 addresses are not going away. Even when IPv6 is deployed in production environments worldwide, millions of IPv4-only hosts will still be operational.
- NAT is not going away. It will be impossible for all newly connected Internet hosts to have dual stack (IPv6 and IPv4 active at the same time) due to the shortage of IPv4 addresses. The only way an IPv6-only host and an IPv4-only host can communicate is through a NAT gateway.
- Applications are becoming NAT-aware. Even recent peer-to-peer applications like Skype work seamlessly (although not optimally) across firewalls and NATs.
Therefore, if you're an enterprise network manager already using private IP addresses internally and using NAT to connect to the Internet, you don't need to care about IPv6 for a long time. The first impact of IPv6 on your network will happen when you'll have to upgrade your firewalls and public servers to support dual stack (but that will happen after the service providers offer production-grade IPv6).
Note that the situation is drastically different for U.S. government agencies that are required to have operational IPv6 Backbones by June 2008. Accordingly, U.S. service providers are advancing with their IPv6 plans.
If you work for a service provider, your perspective should be different, as this market will be the first to see IPv6 in production. You might decide to implement the wait-and-see strategy (which is the safest choice if your strategic planning does not extend beyond your quarterly results) and risk playing catch-up later. This strategy is not working too well for some of the traditional voice telecoms that decided it's safe to ignore Internet, so it might be better to get ready.
Last but not least, you might get government funds for IPv6-related projects or tax breaks to help you deploy IPv6 in your network, in which case it would be irresponsible to ignore them.
How do I get ready?
If there's no pressure to implement IPv6 in your production network at this point in time, it makes no sense to start training your technicians (they will most likely forget everything months before their first on-site deployment). But your network designers and high-level experts should definitely start building proof-of-concept networks and deploy IPv6 on test servers:
- Before you can start any end-to-end tests, you have to deploy IPv6 domain name servers (DNS).
- You need to test dual-stack deployment on your servers and the availability of applications you offer your customers and the general public (for example, web and email service) over IPv6; not all applications work seamlessly over IPv6 transport.
- Your networking experts should get familiar with IPv6-specific protocols (for example, while IS-IS and BGP are mostly unchanged, OSPFv3 is a completely new protocol), as well as dual-stack configuration and troubleshooting.
- If you've already deployed MPLS in your network, you should test the IPv6-over-MPLS solution (6PE) that allows you to deploy IPv6 services without enabling IPv6 on all nodes in your network.
- You should test your entire configuration, provisioning and billing tools to make sure they support IPv6 addresses and prefixes. These applications don't have to run over IPv6 (you can still use IPv4 internally), but they have to be able to assign IPv6 addresses or prefixes to customers and bill them accordingly.
- You should design and test the IPv6-to-IPv4 NAT service you'll offer to your customers.
While a lot of your peers have already started to walk down the same path (almost 2,000 public IPv6 prefixes have been assigned), don't expect miracles. The support you get from some equipment vendors (at least in the area of traditional instructor-led training) is still marginal compared to what they offer in the IPv4 space. For example, Cisco has a five day course that touches most aspects of IPv6 network deployment, while Juniper believes you can learn everything there is to know about IPv6 in a day. And I haven't found a single IPv6-focused course in the Microsoft curriculum.
The best way to proceed is thus through peer-to-peer communication: Join IPv6 focus groups, participate in IPv6-related forums, and attend industry meetings (for example, IPv6 was clearly one of the focuses of the latest NANOG meeting.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Read his blog here: http://ioshints.blogspot.com/index.html.
