Chesapeake NetCraftsmen

Introduction to IPv6 -- Part 3

Introduction

This month's article is the third in a series on IPv6. My focus will be on the various migration and co-existence techniques. We'll also look at some of the current hot discussion topics in IPv6. While the basics are solid, there are some things people would like to be able to do that do not fit cleanly into the original vision for IPv6.

The first article in the series looked at why one might care about IPv6. That article can be found at the link Introduction to IPv6 -- Part 1. The second article looked at the address types and formats, and selected other specifics of IPv6. This included some of the flavor of the things that are different than IPv4. It can be found at Introduction to IPv6 -- Part 2. Since writing that article, I've seen some more articles about how many networked devices there will be, all of them requiring an address. (Think sensors with low power wireless, home appliances, etc.)

Co-Existence of IPv4 and IPv6

The simplest, cleanest way to do IPv6 is arguably to run dual-stack wherever possible. In dual-stack mode, all or most network devices route both IPv4 and IPv6, with no interaction between the two ("ships in the night").

This is where the real world comes in. It is expensive to upgrade all devices to IPv6. It makes little sense to upgrade devices in a building that is going to be emptied over the next year. Immediate IPv6 support may be needed while device upgrades are being purchased and installed. And so forth.

This is where co-existence comes in. It seems like there's a type of tunnel for every conceivable need. Here's the list of tunnels supported in Cisco IOS Release 12.4T, along with the documented minimum release for each type of tunnel:

(This information may be found online at http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186a00801d6604.html#wp1027173).

We omit information about 12000 series router IPv6 features, also about CLNS tunnels, since they are Service Provider features that I expect few readers are interested in. And while you can build IPv6 GRE tunnels to tunnel IPv4 or IPv6, also IPv6 over IPv6 tunnels, I think we had best concern ourselves about more mainstream features in this article.

Let's look at the main tunnel variations in more detail.

Overlay Tunnels for IPv6 Traffic

The idea of overlay tunnels is to connect pockets of IPv6 with tunnels across an IPv4 network. There are several variations, summarized in the following table:

The first two tunnel types use a source and destination IPv4 address, as you might expect. They are point to point tunnels. They may be useful for connecting a small number of isolated pockets of IPv6 over an IPv4 network. Building them is not that hard to configure, but scaling is a definite factor with these approaches. The endpoints of the tunnel must be running dual IPv4 and IPv6 stacks.

The latter three tunnel types use an IPv4 address or interface with IPv4 address as source. The destination IPv4 address is determined (somehow) from the IPv6 destination in the packet. These automated tunneling approaches treat the IPv4 network as a NBMA network interconnecting the IPv6 networks.

In the case of IPv4 compatible and 6to4, the IPv4 address is built into the IPv6 address.

With IPv4 compatible tunnels the IPv6 addresses in use on the tunnel interfaces must be of the form ::A.B.C.D, with embedded IPv4 address. That way, the edge dual-stack routers can find each other across an IPv4 network. This technique is known to not scale well, and use is not recommended. ISATAP is considered a preferable technique.

With automatic 6to4 tunnels, IPv6 domains or sites may be interconnected over IPv4. The dual-stack IPv4 routers use addresses of the form 2002:edge-router-IPv4-address::/48, followed by 16 bits for numbering networks within a site. Each such IPv6 site must have an edge router with a unique IPv4 address, and could connected to be company or agency backbone, or the Internet.

ISATAP is for use within a site where a native IPv6 deployment is not yet in place. ISATAP allows IPv4 or IPv6 dual-stack hosts to communicate on a virtual IPv6 link. An ISATAP router provides standard router advertisement to the ISATAP site. The IPv6 hosts can then auto-configure themselves as if connected to Ethernet.

ISATAP allows use of any IPv6 prefix (/64), including global, link local, or 6to4 prefixes. The IPv4 address is encoded as the last 32 bits of the IPv6 address, to enable the automatic tunneling. The full format for ISATAP is [IPv6 prefix][0000:5EFE][IPv4 address]. The last 64 bits are also regarded as an interface identifier.

For Cisco configuration specifics, see the documentation at http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186a00801d6604.html.

Configuring the various kinds of tunnels is not complex!

The Cisco documentation includes the following caveat about use of IPv6 tunnels:

Note Overlay tunnels reduce the maximum transmission unit (MTU) of an interface by 20 octets (assuming the basic IPv4 packet header does not contain optional fields). A network using overlay tunnels is difficult to troubleshoot. Therefore, overlay tunnels connecting isolated IPv6 networks should not be considered as a final IPv6 network architecture. The use of overlay tunnels should be considered as a transition technique toward a network that supports both the IPv4 and IPv6 protocol stacks or just the IPv6 protocol stack.

Microsoft supports 6to4 and ISATAP in Windows XP and Server 2003. See the MS TechNote link below..

Configuring ISATAP on a Cisco router requires the command

no ipv6 nd ra suppress

on the ISATAP tunnel interface. This begs the question, how is the ISATAP router going to do router advertisements? Am I flooding some sort of broadcast throughout my network when I configure this?

The answer: apparently not. Per the RFC on ISATAP, RFC4214, Solicited Router Advertisement messages are sent directly to the soliciting node. That's why in the afore-mentioned TechNote, Microsoft gives two ways for an ISATAP host to be configured with the ISATAP router. One is DNS resolution of "ISATAP". If you name a Microsoft server acting as router ISATAP, it will register that in DNS and WINS (except for Windows XP pre-SP1). The other approach is using netsh to manually configure the IPv4 ISATAP router address.

The Microsoft TechNote also contains a useful picture, showing use of ISATAP locally and 6to4 for Internet IPv6 connectivity, see http://technet2.microsoft.com/QueryWS/GetOpenContent.aspx?assetID=fdc457f2-ccd5-4c0e-9400-37c42b58fce2&DocumentSet=en-US&RenderKey=XML.

Hot Discussion Topics

So far, our discussions have revolved around the more established parts of IPv6. There is a lot that is well-thought out about the protocol. As you can see from the above discussion of tunneling, there is enough there to let sites get started doing IPv6, either hosts-first or by running dual-stack on key routers.

What are some of the problem areas? After all, if you're considering investing time and money in implementing IPv6, you want to know that the investment will be worthwhile.

So far, the conspicuous problem areas seem to be mostly fringe areas.

One of the problem areas revolves around multi-homing. The original discussions apparently emphasized summarizable address prefixes, which built in the implicit assumption that IPv6 would either use geographic addressing in some form, or that multi-homed sites would multi-home via one Internet Service Provider (ISP). In the U.S., multi-homing sites seem to much prefer having multiple ISP's. I imagine other parts of the world would do so if the costs of doing so weren't prohibitive.

One of the alleged advantages of doing IPv6 is end-to-end addressing, doing away with NAT. If you buy into that, then connecting to a second ISP becomes problematic. Which ISP prefix do you use? What addresses do you put in your external DNS?

You're probably thinking, why can't I do what I do now? Approaches in current use:

1. I see small-to-medium sites using two stateful NAT firewalls to NAT to blocks provided by two ISP's. This works, saves having to do BGP, but can't fail over without losing state (and customers!).
2. Larger sites have their own IP prefix, BGP AS number, and talk BGP to multiple ISP's.
3. Some sites also use DNS to advertise prefixes from multiple ISP's. Failover with DNS is slow, however, due in part to caching and buggy cache implementations.

The problem with (1) is that NAT is considered undesirable with IPv6. Concerningg (2), if you wanted to get an IPv6 address block, you could not, until recently. That is not the preferred approach, because of present experience. Adding end-site prefixes to global routing expands routing tables, costing resources and money, and decreases overall stability. And (3) is still available, with AAAA records for IPv6 hostnames. And the attendant drawbacks.

For a good starting point in reading about this, see the relevant IETF working groups, http://www3.ietf.org/html.charters/multi6-charter.html and http://www3.ietf.org/html.charters/shim6-charter.html. The MULTI6 working group laid the framework with discussion of requirements and approaches.

One result was the SHIM6 approach, which uses multiple ISP prefixes, by enabling hosts to shift transport to another IPv6 address. This well-intentioned idea unfortunately opened up several cans of worms, among them having hosts determining network outages and paths, source routing, and even security issues. The group apparently believes it can address these, and is proceeding with it work. See http://www3.ietf.org/proceedings/06nov/minutes/shim6.html for the most recent published minutes at the time of this writing. For an idea of the security issues, see http://www.ietf.org/rfc/rfc4218.txt, which has some rather highly respected authors' names on it.

Wikipedia's entries are interesting on this. See http://en.wikipedia.org/wiki/Multihoming and http://en.wikipedia.org/wiki/Site_Multihoming_by_IPv6_Intermediation. The former link is somewhat amusing for all the cons listed: what we're doing now isn't perfect, apparently, but may be better than the well-intentioned alternatives, which are "not yet ready for prime time".

The good news is that rather than waiting for a perfect solution, ARIN has chosen to issue IPv6 address blocks to end-user sites. See http://www.arin.net/policy/nrpm.html#six58. Whether other Internet Registries will follow remains to be seen.

One expects there to be a similar set of issues revolving around multiple wireless interfaces and mobility. Work on that topic is in progress.

Do note that none of these is a show-stopper for IPv6. They are to some extent difficulties encountered in trying to make IPv6 work better than IPv4.

Conclusion

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

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

12/3/2006
Copyright (C) 2006 Peter J. Welcher