Now, however, we need to drill down into more specific analysis. Below we consider various influences on a deployment plan. We consider the most important case, existing IPv4 infrastructure, first, then talk about considerations around converting hosts and routers.
This will be by far the most common starting point for IPv6 deployment, and will continue to be for years. The good thing is that IPv6 is, as designed, able to run in parallel on almost any kind of layer 2 media: Ethernet, ATM, and so on. This means that you can start with as minimal a deployment as you want, by connecting IPv6 capable hosts to your existing layer 2 infrastructure. Adding to or changing the IPv6 deployment is very easy, and as time goes on, the amount of administrator effort required for getting IPv6 up and running on new equipment will go down. The tricky element obviously, is managing the two in simultaneously.
As noted above, there are various transition mechanisms that can help with deploying IPv6. One of the most useful for low-overhead connectivity is the dual-stack approach, where the OS can communicate using each protocol (IPv4 and IPv6) separately. We find that in situations where performance is not absolutely paramount, having a dual stack means that experimenting with IPv6 becomes very easy, as we illustrate below. For situations where dual stack is not feasible, there are other mechanisms to deal with IPv6-only hosts, and we look at those too.
In summary, existing IPv4 infrastructure is in general no problem for a deployment plan. One very useful transition mechanism is running dual-stack, and we find it does not introduce interoperability problems.
At some point, you will want all of your equipment, where feasible, to be running IPv6. This is really just a matter of setting up the dual-stack system on each host. Obviously that's a certain amount of work per machine, and while ad-hoc deployments may be suitable for small networks, for large networks being systematic is necessary.
One sensible way to proceed for converting hosts is to create a standard patch distribution for such old machines and operating systems as require it. Apply the patches via your standard systems maintenance or scheduled outage[13] interface and then evaluate the change. (You may prefer to do this with a sacrificial machine or two first, if you run unusual applications or have a particularly different O.S. configuration.) Usually vendors will have extensively stress-tested their stacks before letting the public see them, but occasionally your situation may trigger an obscure problem, so it is wise to evaluate patches before rolling out. Having done that, you can, at your leisure, convert the rest of the hosts on the network. Another option is to allow IPv6 to be deployed as part of your normal upgrade cycleâonce the operating system versions you install supports IPv6, you can just deploy it with IPv6 enabled (again after appropriate testing).
The great benefit of this rolling dual-stacked deployment is that there is no flag day: in other words, a day where everything changes. Experienced network managers know that changes on massive scales quickly expose hidden dependencies that can make life highly exciting for hours or even days. Apart from standard scheduled outage management, the overhead of the gradual roll-out is really quite small. Obviously the more equipment converted in a single session, the more you can amortize the cost (in both time and money).
At the end of this process, you can have systems that can pick up addresses via IPv6 router solicitation and behave as if they were solid citizens of both the IPv4 and IPv6 Internet. This is an important stepping-stone on the way to implementing almost any deployment plan.
Tip
Roy, Durand, and Paugh have a draft, http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-03.txt, about their experiences of turning dual-stack on by default within Sun. One key element they found was that dual-stack machines, numbered privately in IPv4, would experience problems when attempting to make IPv6 connections in networks with no on-link IPv6 routers.
From a network managers perspective, if you are rolling out dual-stack throughout a network, or if dual-stack is mandated for you, as much on-link IPv6 infrastructure as possible is one obvious way to short-circuit many classes of performance or reliability problems experienced by these machines. There are other transition mechanisms which may also help, some relying on existing IPv4 infrastructure; you will find them discussed in Section 4.1 earlier in this chapter.
In summary, we feel the rolling dual-stack method to be quite well understood. Deployment plans that involve converting networks of desktop machines could use it with relatively small risk.
One thing that you'll want to consider before doing an organized large scale roll out of IPv6 is how to provide connectivity. Deploying one or two test hosts with their own tunnels or 6to4 connectivity is relatively easy and sensible. However, it is probably not a good idea to deploy a LAN of many hosts all with their own individual tunnels to the IPv6 Internet! As we saw in Chapter 3, IPv6 routers play an important part in the IPv6 configuration process, so if you are deploying more than a couple of hosts, consider configuring a router and using a tunnel or 6to4 on the router. If you don't have dedicated router hardware, that's fine: most operating systems that support IPv6 can be configured as a router.
Dedicated routers themselves raise different questions. Depending on your manufacturer, you may have to buy an OS upgrade in order to have an IPv6 capable machine. Before that upgrade is bought or borrowed you'll need to do some planning. There are two points to be aware of when doing this planning. First, IPv6 dual stack obviously uses more CPU and memory resources than a single stack and sometimes routers don't have much of either to spare. Check your vendor's specifications to make sure the upgrade will fit on the router in question. (Router memory upgrades in particular can have unpleasant step functions in the financial resources required.)
The second issue that applies particularly to dedicated routers is that, because IPv6 is a younger protocol, the IPv6 path in a router can be less well optimized than the IPv4 path.[14] For core networks that expect to process millions of packets per second, this can be catastrophic, and if your router has this issue, we advise you to look at other options such as using a separate router for IPv6 or using 6PE.[15] Chapter 5 goes into more detail on the level of support in Cisco and Juniper routers. We'll talk more later about network topologies and how to ship traffic around.
With all this in mind, the question arises as to whether to use one's existing IPv4 router(s) for IPv6 traffic. Like always, this decision comes down to a balance of tradeoffs. The two main cases to consider are WAN links and ingress/egress routing, and the issue with both is whether the safety and resilience of a separate infrastructure justifies the management and cost overhead of supporting that infrastructure, even if that infrastructure is a single PC with a tunnel.
If you use a separate router on your LAN for IPv6, then you can gain experience[16] without fear of impacting your production IPv4 systems. As time goes on, however, you may find that this flexibility actually works against providing a reliable IPv6 service. It duplicates the administration and maintenance work involved and can create an easily-ignored support "ghetto" that busy staff without spare time will, despite best intentions, find themselves unable to gain experience with. Face it, who has spare time in this day and age?
Most importantly, it will also prevent you of taking full advantage of any IPv6 support that might become available on your WAN link. Workarounds like IPv6-in-IPv4 tunnels, while great to start with, don't scale very well and are prone to failure in ways that a native network is not. Maintaining it, of course, invites all the same problems of support ghettos. Once you have confidence that you understand IPv6 and its potential impacts on your network, the ideal way to leverage your existing experience and its similarity with IPv4 is to deploy it exactly in parallel, and use all the same troubleshooting and monitoring mechanisms to maintain it.
As a result of this, our observation is that sites that experiment with IPv6 will typically start with an entirely separate infrastructure and move toward integration as time goes on and experience grows. On the other hand, sites looking to save money and have a deployment period with a fixed timescale, generally re-use existing infrastructure where possible.
As above, this is a conversion process allowing your systems to run IPv6. However, in this case, you turn off the IPv4 stack when you have completed IPv6 configuration.[17] This is a scenario that you would probably only contemplate when one part of a network that is already converted to IPv6 is working well or if you need to deploy a large number of hosts but don't have the IPv4 address space available. The most important thing to remember is that routers and infrastructure service systems need to be in place first. IPv6-only machines that do not receive RAs are limited to purely local communication,[18] so you need a working IPv6 router to communicate with the outside world. Even if you do have fully functional IPv6 connectivity, you may need to think about how you will reach IPv4-only sites (including most of the web and DNS servers currently on the Internet). Your conversion plan will therefore need to address these dependencies very carefully.
You will very probably encounter problems in the act of performing the conversion. You could expect the issues to broadly fall into the following categories:
- The IPv4 stack that wouldn't die
In some cases, particularly with the older commercial operating systems, removing IPv4 is actually not yet possible. More accurately, removing it while retaining IPv6 can be problematic. However with popular, more modern operating systems, we're glad to say it is in general possibleâfor example, Windows allows you to bind and unbind protocols from an interface, and there was some work done on modularization of IPv4 in Linux. If you can't actually remove IPv4 you can always choose not to configure any IPv4 addresses.[19]
- Too simple
There may be devices within your network (one classic example being network-enabled printers) that only speak IPv4 and will only ever speak IPv4. In this case it will require certain servers to retain their IPv4 addresses to front-end these devices.
Another possibility in this category is software that only supports IPv4 and an IPv6 version will not be available in the near future. In some cases it is possible to work around these issues; have a look at Chapter 7.
- Low service availability
The service that you thought was available over IPv6 turns out to be available in the approximately twenty minutes that it stays up without crashing. In this case it may be possible to isolate the users of the service such that they continue to use dual-stack hosts while the rest of the network moves toward IPv6 alone. Sometimes the crashing problem may be easy to fix: a programming or configuration error. Sometimes there is another daemon that effectively achieves the same thing: samba instead of NFS for file sharing for example.
We have to say that most of the IPv6 services we have deployed have a similar level of reliability to their IPv4 counterparts, which is not surprising given that the transport level is essentially the only thing which is changing.[20]
Your system management process here involves the same test and rollout phase as before, only the dangers of removing IPv4 are significantâyou are not only adding extra capabilities, you are removing old capabilities, and any users that were using the machine via IPv4, or any services that the machine needed to talk to over IPv4, had better be running on IPv6 also or things will get messy. For that reason alone it is probably best to run such infrastructure servers as are necessary (DHCP, DNS, and so on) on dual-stack until everything is running safely on IPv6.
In summary, if your deployment plan has an IPv6-only network in it, and it must communicate with an existing IPv4-only network, proxies or other front-ending should be deployed and tested first. If the IPv6-only network is "green-field" and does not need to communicate with IPv4 services, life is easier. We highly recommend dual-stacking infrastructure servers that provide DNS and DHCP. Additional single-stacked IPv6 servers performing the above functions are acceptable if the management and money overheads are acceptable.
At the moment, and probably for quite some time to come, this is the least likely scenario unless you are setting up a research lab. In many ways, since you have one less transport protocol to worry about, your life becomes much easier: there's no need to have separate firewalling rules, separate routing or anything like that. However, until the time when significant parts of the Internet can be reached via IPv6, you are likely to want to communicate with IPv4 entities somewhere. There are a variety of ways to do this, some of which are covered in this chapter, Chapter 6, and Chapter 7. The most relevant question for this scenario is whether or not you can get IPv4 addresses on the edge of your network. If you can, then you have the option of using various dual-stacked proxy techniques or using a router to do some form of NAT or gatewaying. Otherwise, you may have to rely on an upstream proxy server or some other mechanism to gain access to the IPv4 Internet.
An obvious influence on a deployment plan is the existing network topology. This will dictate where things can be changed, and how expensive and difficult it will be.
Generally, your choice will be whether to modify topology on layer 2 rather than layer 3. If things are routed in your existing network there is generally a good reason for that (WAN links, security) and those reasons will be invariant under the application of IPv6. Of course the routers are a particularly crucial aspect of networking under both IPv4 and IPv6, which means that it may not be possible to change them as easily as we might like. Topology on layer 2 is relevant to intra-site communication, and may require one of the transition mechanisms to properly enable same. In the base case, IPv6 communication can flow naturally over normal switches, and as long as multicast is supported, everything should "just work." If one wants to separate out IPv4 and IPv6 communication, choices begin to appear. You can do it at a VLAN level, in which case your hosts must support the 802.1q VLAN tagging protocol; rare, but not impossible. Examples of how you might do this may be found in the Section 6.6.3 section in Chapter 6.
Historically speaking, it was envisaged that IPv6 would begin to appear in networks in an edge-to-core direction. In other words, given that one of the main benefits of IPv6 was to number large networks natively, it was envisaged that it would be enabled where the maximum benefit accrued. In fact, our experience is that it is going mostly in the opposite direction: the core is only slowly being dual-stacked or otherwise enabled for IPv6, and the edges which previously had to make do with tunnels are switching over to native connections. Based on the realization that most managers are somewhat scared to switch over a well-functioning core, this has prompted a move toward entirely separate IPv4 and IPv6 infrastructure. If existing IPv4 infrastructure and applications absolutely must not be disturbed, this is a good approach. In practice it is very rarely the case that you can have entirely separate infrastructure, especially when the expense of purchasing additional hardware is made clear. (There are of course still cases when it makes sense to buy a limited set of desktops or servers additional network cards, and create a separate switch VLAN for them.)
Conversely, with an edge-to-core implementation, the key question is building support inwards. In the case of ISPs, for example, CPE can often be less flexible and upgrading it to support IPv6 may be problematic. DSL routers are perhaps the canonical example of this, but old equipment is a problem for everyone, not just ISPs. Allowing IPv6 to transit your core until it is natively enabled is a matter for transition mechanisms discussed elsewhere.
With respect to router placement in general or reconfiguration, there are three main cases to consider:
Same IPv4/IPv6 router, with same exit route (i.e., native onward connectivity).
Same IPv4/IPv6 router, with different exit route (e.g., via a tunnel).
Separate IPv4 and IPv6 router (e.g., Figure 6-1).
These differences are important when considering your onward connectivity, but they will be transparent to the end host. In a flat (broadcast) network, such as a single LAN, your router's announcements will ensure that every IPv6-capable host receives an address and connectivity. If you happen to have more than one router on your LAN, both will announce themselves; if they are advertising different prefixes then your hosts will receive separate addresses from each.
Also be aware that if your prefix changes from time to timeâfor example, if you use 6to4 with a dynamic IPv4 address as the endpointâthen the addresses of all your hosts will change as well. This should happen fairly transparently, but you will need to set the lifetime of the advertised prefixes just right; long enough to overcome network instabilities, but short enough to time out when they are no longer valid.
While we like to insist that IPv6 is just like IPv4 in all the best ways, there are some interesting consequences to router advertisement that can catch you out if you use VLANs extensively. When a router turns up on a network, it will typically announce itself and start assigning addresses. If the router is not on the network it is supposed to be onâfor example, by being plugged into a switchport on the wrong VLANâit will start handing out addresses that will, briefly, work (for small values of "work"âthey're not likely to be in the DNS and might not match any access control lists you or others have defined).
When the operator notices the error and pulls out the patch cable, the addresses will suddenly stop working, but they will hang around until they time out, and chances are that the machines that have them will continue to try to use them. Since mistakes happen, you might want to consider configuring reasonably short timeouts for router advertisement; after all, if the router does go away for a bit, its addresses aren't going to be much use anyway. Note also that, even when correctly configured, leakage of packets across VLAN boundaries is a well-documented feature of network equipment.
It all gets even more interesting if your router or switch runs a trunking protocol such as VTP. Rather than simply not working if you plug it into a non-VTP port, it's likely that traffic to the default VLAN will still get through, and you'll start getting addresses from somewhere. Typically , it'll almost certainly be wrong somewhere.
In summary, we have shown a number of the possible influences on a deployment plan. You will need to consider at a minimum addressing, routing and naming in your deployment plan, as well as organizational concerns such as who will pay for it, and who will support it.
[13] For advice on how to manage and plan maintenance properly see The Practice of System and Network Administration by Limoncelli and Hogan (Addison-Wesley), but be prepared to feel embarrassed at how disorganized you are.
[14] Possible examples include processing firewall rules or fast hardware forwarding.
[15] This is a way of tunnelling IPv6 over MPLS.
[16] A euphemism for "break it then learn how to fix it."
[17] Probably removing the very stack that allowed you to install IPv6 in the first place!
[18] Although they may be able to communicate with a proxy on the same link, and hence the outside world.
[19] You may need to configure 127.0.0.1, as some software
becomes distressed if you don't have a loopback
address.
[20] If an application is re-engineered entirely to support IPv6 there is of course the danger of introducing bugs, security problems, etc.
Get IPv6 Network Administration now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
