In addition to the IPv4-embedded IPv6 unicast addresses, a series of other tools and techniques can be used to facilitate a migration. These tools are native to the IPv6 protocol suite and include the following:
Each of these is worth exploring in a bit more detail, although NAT-PT is not yet supported as of Cisco IOS Software Release 12.2(2)T. Dual Protocol StacksA classic technique for migration is to run in a parallel environment. In other words, you establish the new environment in parallel with the old. Both coexist long enough for a graceful and unhurried migration to be completed. Although such a dual mode is more expensive, it is inherently less risky than a flash-cut. In the case of IPv6, a flash-cut is probably not even feasible. Quite simply, too many devices with IP addresses need to be cut over. The quick list might include hosts and servers, but don't forget that management ports on hubs and switches, printers, and countless other devices all use IP and IP addresses. Only the smallest of environments can realistically contemplate a flash-cut to IPv6. For all other networks, product support has been and is being developed that lets a device run both protocol stacks simultaneously. From a client computer's perspective, this affords older applications the opportunity to continue using the IPv4 protocol, while newer applications can be configured to use IPv6. In theory, both would use the same connection to the local-area network. Virtually any device that can be configured to use an IP stack can be configured to support dual stacks. However, routers are particularly useful in this capacity. Such routers function as gateways between IPv4 and IPv6 network regions and can accommodate traffic in either format. To configure a router interface as a dual-stack interface on your Cisco router, start from global configuration mode and use the commands shown in Table 15-4.
IPv6 Tunnels Through IPv4 NetworksIt is possible to encapsulate IPv6 packets with an IPv4 packet for transport through an IPv4 network en route to an IPv6 destination. This is sometimes called overlay tunneling. This moniker derives from the fact that the one protocol is overlaid on the other protocol. Overlay tunneling can be achieved in three ways:
The distinctions between these tunnel types are subtle, but they revolve around how source and destination addresses are formed for the IPv4 packets (which encapsulate the IPv6 datagram) forwarded through the tunnel. Remember, IPv4 doesn't recognize IPv6 addresses, so when you encapsulate an IPv6 datagram with an IPv4 packet structure, you can't use the source address of that IPv6 datagram. It simply won't work in the IPv4 network. So the addresses have to come from somewhere else! Three different mechanisms have been developed to solve this problem, albeit in different ways. All three can be configured only on dual-protocol routers. They are examined a bit more closely in the next three sections. Before perusing those sections, look at Figure 15-4. It demonstrates the typical topology seen in a tunneling scenario. It gives you a picture that might make it easier to understand some of the subtle distinctions between the three types of IPv6-over-IPv4 tunnels. Figure 15-4. Tunneling IPv6 Through an IPv4 NetworkManually Configured TunnelsManually configured tunnels are just what their name implies. An IPv6 address is manually configured on a tunnel interface. IPv4 addresses are then also manually assigned for use as the tunnel's source and destination addresses. That is, IPv6 datagrams passing through the tunnel are wrapped with an IPv4 packet, and the IPv4 source and destination addresses that were manually configured on the tunnel's interface are used as the source and destination addresses of those newly-created datagrams. To help make this a bit more real for you, Table 15-5 contains the syntax required to configure a manual tunnel on a Cisco router interface.
Automatically Configured TunnelsAutomatic tunneling, as you can probably surmise after reading the preceding section on manually configured tunnels, does not rely on statically configured IPv4 addresses to be used as source and destination addresses for the tunnel traffic. Rather, source and destination addresses are dynamically fabricated using IPv4-compatible IPv6 addresses. Of course, this implies that you are actually using IPv4-compatible IPv6 addresses in your IPv6 network. Otherwise, this approach just isn't right for you. The low-order 32 bits of the IPv4-compatible IPv6 address (those to the right of the numeric address) are used to generate the source and destination addresses for use in the tunnel. Configuring this type of tunnel is much simpler, because many steps are omittednotably, those that manually configure the IPv4 addresses. Table 15-6 outlines the syntax and sequence to configure an automatic tunnel.
In theory, the IPv4 packets created via the IPv6 automatic tunneling mechanism can be routed by whichever route is deemed least costly in the IPv4 network. Only the origin and terminus of the tunnels are fixed, and they are referenced by routable IP addresses. 6-to-4 TunnelsA 6-to-4 tunnel is a variation of an automatic IPv6 tunnel in that the addresses used in the tunnel are automatically fabricated. However, this tunnel type requires you to create a static IPv6 route over the tunnel's interface. This type of tunnel is useful when either you aren't using IPv4-compatible IPv6 addresses or you are interconnecting two IPv6 networks that each have only a single egress point to the same IPv4 network (in which case a static route is the most efficient solution). Table 15-7 outlines the configuration syntax for the 6-to-4 tunnel type.
The fact that the last step in the configuration of this tunnel type is a static IPv6 route should tell you that the IPv6 source and destination addresses play no role in the manufacture of the addresses to be used across the tunnel. This concludes our review of the various transition mechanisms developed for IPv6. The fact that so many tools are expressly designed to facilitate a migration, yet so few people are migrating, is quite revealing: Tools to assist a migration are of value only after you decide to migrate. So, the logical question is... |