Introduction

In this month's article we will take a look at IPv6, mostly focusing on the big question, "Why Do I Care About IPv6?" We'll also talk about the management issues surrounding IPv6 deployment. In next month's article (and perhaps following articles) we will then take a brief tour of the technical side of IPv6.

The reason I personally care about IPv6 is that we're doing some work concerning IPv6 for a large U.S. government entity. I've discussed IPv6 with some folks at another agency, especially "Why Support It" and "What's Involved in  Adding IPv6 Support". And I've done a lot of reading on the topic.

This article is in part intended for the government audience. It contains my interim reactions to and conclusions about IPv6. And thanks to those who have taken the time to discuss it with me, share their insights, etc.!

I try to spend time learning about or improving technical depth on new technical topics based on how likely I am to use them in the near term (but knowing enough about most to handle surprise projects). That way, one does not spend a lot of  time on skills that will never be used. There are exceptions: controller-based wireless and IPsec are ubiquitous, they are now "infrastructural", meaning everyone needs to know them, similar to the situation routing and switching. I won't claim IPv6 is in that category, except for federal networkers. IPv6 is at the point where everybody should know a little IPv6 . And that is why I'm writing this short series of articles.

For other reasons why you should care about IPv6, see the next sections. The ultimate reason: medium to large organizations should probably be taking IPv6 capabilities into account in their planning and purchases. For why, see below.

Why Should You Care About IPv6?

In practical terms, that means your networking technology refreshes need to take IPv6 into account. Having a strategic plan to gradually deploy increasing levels of IPv6 support over the next few years is a great way to tackle this.  You need to have IPv6 on your network backbone by 2008. If managed reasonably well, that does not need to be all that painful.

History flash: around  1988, GOSIP was required for all government shops: OSI protocols, CLNS, etc. GOSIP rapidly faded away as agencies continued use of TCP/IP. 

IPv6 is not GOSIP. Due to the IETF connection, IPv6 is available as working code. Microsoft, Linux vendors, and Sun already support it, and major router vendors are on board. Unlike GOSIP, IPv6 seems to be here to stay. The co-existence approaches mean that IPv6 migration need be nowhere near as disruptive as GOSIP potentially was.

Let's now attempt a fair-minded evaluation of IPv6's benefits.

One reason for IPv6 is more address space. The addresses are 128 bits instead of 32 (four times more bits, 2 to the 96th power more addresses). This indeed is a problem for parts of the world, Asia in particular. It also benefits organizations such as the U.S. military, which is reportedly contemplating things like addressable components of soldiers' equipment, personal / body networks (for example, health monitors), scattering small probes each with an address, and so on. One also sees occasional press releases about various research projects, not necessarily military, with low power radio sensor nets, 3D visualization, and other  technologies requiring many addresses. Less exotic consumers of addresses: cell phones doing VoIPv6, Personal Digital Assistants (PDAs), etc. 

On the other hand, for most of us, NAT is working fine at present. Yes, end to end address visibility might be a little more secure, in the long run. Troubleshooting traffic through multiple NAT points is not fun! Generic NAT firewalls general do not "fix up" VoIP protocols to allow them to function transparently. Eliminating NAT makes the protocols and programming simpler.  NAT also assumes oversubscription: fewer online at any one time than total population. As people move to Instant Messaging, presence applications, etc. they are constantly online. Port overloading is the only way to accomodate this, but it has other drawbacks, including more likelihood of protocol problems where other ports are used selectively. Preserving NAT state during failover is also hard if not impossible.

IPv6 does provide two immediate cost-saving benefits: the standard requires support for IPv6 mobility, and for IPsec. One would presumably not have to pay extra to obtain support for those, as is presently the case with IPv4. The standard inclusion of IPsec is does create an end node firewalling issue. Since traffic may well be IPsec encrypted between endpoints, a firewall would not be able to examine it. Is that a benefit or a drawback? In terms of blocking peer-to-peer traffic, HTML tunneling already presents a similar problem.

As far as mobile host, it allows a file or data transfer to continue uninterrupted as one roams. That is not presently the case when you roam and obtain a new address by DHCP. Most of us are getting along fairly well without such capability. For those who prefer more, freeware or commerical IPv4 mobile IP drivers are available.

IPv6 provides for auto-configuration of addresses. The idea is for a device to learn the subnet prefix from an adjacent router, and then build an address using a form of its MAC address. This seems closer to the old Novell IPX prototocol rather than DHCP. DHCP is also possible with IPv6, as is static addressing. The autoconfiguration means simpler support for plug-and-play by devices (refrigerator, cell phone, military personal communications unit, etc.).

There are several more technical benefits of IPv6 cited by proponents.  I view some of these as mixed blessings.

• Simpler headers.
  
• For example, routers do not do fragmentation. While this is a good idea from the performance perspective, it means that IPv6 relies on Path MTU Discovery. The reality I keep encountering is that Path MTU Discovery really doesn't work in practice, because too many firewalls block ICMP replies. IPv6 has somewhat more dependency on ICMP than IPv4. This opens the door for more protocol problems from clueless firewalls.  It also opens the door for exploits since firewalls must pass certain ICMP packets through.
• IPv6 headers allow for a flow id, which may be useful for QoS.  Can I trust it? Spoofing?
  

Any negatives I mention here are the minor sorts of  things that come up as a new protocol is deployed. I'm sure that if they are big enough problems they will be addressed.

There is one key factor that I have not seen much discussion of. Application support was really one factor pundits missed when ATM was coming in. If desktop applications were to make real use of ATM, they needed to be coded with awareness of ATM and how it worked. Not until LAN Emulation (LANE), which made ATM "look like" Ethernet to programs, did campus ATM usage really begin to get some serious traction. Before that, it was just too much work for developers, consuming time and money. ATM might have eventually gotten there, but it got surpassed by faster, cheaper, simpler technologies.

Desktop and server support is not a problem with IPv6. There are already host and server stacks that support both IPv4 and IPv6. The support should be mostly transparent to programs. For example, the coming Windows VISTA release will do DNS, and if an IPv6 address is learned, it will by default try the IPv6 transport before trying the IPv4 transport to that address. There are also multiple good migration techniques, for mixing and matching IPv6 and IPv4. So network support should not be a major problem.

What else should one consider concerning IPv6? Personally, I think it comes down to whether or not there is a "killer application". Internet email and web browsing were big drivers for the Internet and IPv4. What's the compelling reason to use IPv6 instead of IPv4? Right now, little. Instead, there are "speed bumps", minor considerations that anything new entails. For example, remembering 4 byte IPv4 addresses is bad enough -- IPv6 addresses are quite long!

One counter-argument is that the Japanese, Chinese, and Indian markets in particular are getting pushed into IPv6 faster, due to lack of address space, and due to sheer numbers. Their respective cell phone markets may well also use IPv6. These markets are certainly competitive, rapidly evolving, with vast investment in programming.

I once was skeptical. But now I'm not counting "killer application" out.  Maybe it'll be hybrid PDA's, which combine cell phone, 802.11 wireless phone, and more PDA functionality. Or perhaps smart USB memory stick, e.g. MP3 or video player that also does 802.11  and cellular-based wireless file transfers.  Or perhaps something more esoteric?

How Does That Impact My Network?

The latter is in fact wrong. You can tunnel IPv6 over IPv4, for limited IPv6 support. Thus if the IPv6 stack is enabled, you cannot assume that your IPv4-only network protects you from IPv6 vulnerability. So right away we have one reason to learn some IPv6 -- like wireless, if you assume it isn't there, you're probably being hacked or your security is being end-run right at this moment. Denial is not a useful security measure?

I currently see IPv6 as being somewhat like Quality of Service, QoS. I've enjoyed the consulting I've done on QoS. Much as I think QoS is rather important, I do not see many organizations investing in QoS deployment until they are convinced they need it. There are enough other things to get done that most are not going to invest time in something with no obvious and compelling need. The typical reason ("killer app") for needing QoS is Voice over IP (VoIP), IP Telephony (IPT), IP Videoconferencing (IPVC), or IP Video (IPV). Those with good planning purchased QoS-capable infrastructures so as to have the capability if and when they needed it for VoIP, IPT, IPVC, or IPV.

The same applies to IPv6. You might want to start readying your infrastructure for IPv6. You may not wish to invest a lot of effort in deploying IPv6 until the need arises. You might however want to think through the security implications and make sure you put in place appropriate security measures, or plans for interim measures until ready to deploy full-fledged IPv6 security tools.  And you might want to verify capabilities, to make sure your network will be capable of supporting IPv6 (and QoS!) if and when it needs to.

This is what many government agencies are doing right now: getting ready, doing lab work, doing some initial deployment. And managing a gradual and secure deployment of IPv6. If the backbone runs IPv6, then adding support at the edges as-needed becomes much easier. It can all be kept in-house -- common use of IPv6 across the Internet appears to be further out. My current guess is that inter-agency IPv6 will probably arrive around 2010. Also note that federal procurement cycles can be longer than commercial ones, with deployed equipment being used over longer lifecycles.

The general approach I'm seeing is running dual-stack, that is, running IPv4 and IPv6 alongside each other. If one does testing to ensure that enabling IPv6 does not impact IPv4, then this is a clean low risk way to go. Yes, there are IPv6 tunneling approaches, which we may discuss in the next article. The drawback to them is scaling, performance, security, and overall manageability. At some point you will have to go undo the tunneling and "do it right". Why not just "do it right" from the beginning, unless there is some good reason (hardware, budget, time) not to do so?

My impression is that businesses are tending more towards ignoring IPv6. I'm not sure that's wise. Some learning about the topic, and some planning, might be appropriate. If you're in a corporate environment, do you want to have to do a rush IPv6 deployment because the killer application has finally arrived? How about telling the executives that your organization won't be able to run the new killer application for 3-4 years, after the next hardware refresh cycle? 

I would even suggest that deploying IPv6 need not be highly complicated, if done right. That's next month's article!

That still leaves the question of when. I don't know. There is a critical mass problem, and there is the killer application problem. Until enough networks can run IPv6, and until there is a key application, does it matter? On the other hand, the pace of mobile technology adaption has become rapid. So when change comes, it could be relatively quick.

Deploying IPv6

The first thing you run into with this is that "supports IPv6" is a little vague. So you need to determine what that means. Cisco has some great documentation concerning IPv6 support, features and so on, at least for IOS products. One way to proceed is to go through the IPv6 features and figure out which ones are most important. Then lab test to confirm you haven't missed anything. 

The quick answer here is "Cisco IOS 12.4".  If you do OSPFv3 and not EIGRP for IPv6, then late 12.2 to 12.3 may work for you. If you want EIGRP for IPv6, 12.4 T is what you'll need. If you want only very basic IPv6 features, 12.2 T code may work for you. In general, many new IPv6 features were added in the Cisco IOS 12.2 and 12.3 T releases, and incorporated in the mainline 12.4 code. That code is not "General Deployment" (GD) yet, but it's on the way. 

That suggests timing considerations to me as well. If your network really needs IPv6 now, fine, you can run Early Deployment 12.4 or 12.4 T code. If you can wait a little while, getting equipment in place and being prepared to move to a GD 12.4 release might be a good approach. That would get hardware and software in place somewhere in the next year or so, allowing for gradual configuration and enabling of IPv6 across the network.

Routers are not the end of the story, however. You really need to think through all the data paths through your network.

What if you have L2 switches? The short answer is "bridging doesn't care what Layer 3 protocol is being bridged". If you have Multi-Layer Switches (MLS), it is not enough for the software to support IPv6, you really need hardware switching support to be able to support large IPv6 flows.

Wireless Access Points? They act as bridges. The tunnelling to Cisco central controllers is IPv4-based, so IPv6 should be supported, but only if you don't turn off your IPv4. One trusts that support for IPv6 based LWAPP will appear, but I'm not holding my breath.

Firewalls? CheckPoint says they support IPv6. I have not drilled down for the details of what exactly that means yet. Cisco IOS firewall supports IPv6. PIX 7.1 code adds IPv6 support. That somewhat reflects the market: how many of us have made a priority out of obtaining IPv6 Internet or Extranet services? There are some present situations where we might need IPv6 firewalling more urgently:

• If we use internal firewalls, for example to protect servers, then current IPv6 support in firewalls is more urgent for us.
• If we need to connect to external partners using IPv6, then we want to firewall that.

In summary, you need to look for where you can and cannot support IPv6. And then manage the process of upgrading or replacing equipment where IPv6 support is needed. 

Conclusion

I hope you've found this non-technical overview article of interest. It's high time for me to provide you with some links to other good information on IPv6.

The Social Security Administration did early work on IPv6 evaluation, planning, testing, and deployment. They produced some very solid reports concerning motivations, steps, and so on. Federal planners may be able to obtain copies of these reports. As far as I know, they are not publicly available.

There are a couple of IPv6 books available from Cisco Press. For links, see the following table. I have the Regis Desmeules book, which so far has been reasonably good. I believe Regis was one of the authors of the original Cisco IPv6 course a few years back.

Some other references:

I plan to either write about IPv6 security, or provide links to several good articles, in a coming article.

Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher my email address.