Foundation Topics

IPv6 Routing Overview

IPv6 uses updated versions of the same routing protocols that are available for IPv4. The various protocols work much the same as they do with IPv4, with some changes.

IPv6 routing can be accomplished with the following protocols:

Static routes
Routing Information Protocol (RIP) new generation (RIPng), defined in RFC 2080, RIPng for IPv6
Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv6
Intermediate System-Intermediate System (IS-IS) for IPv6
Multiprotocol Border Gateway Protocol Version 4 (MP-BGP4), defined in RFC 2545,Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and RFC 2858, Multiprotocol Extensions for BGP-4
OSPFv3, defined in RFC 2740, OSPF for IPv6

Choosing which of these to run involves considering the same trade-offs as with IPv4: RIPng, OSPFv3, and MP-BGP4 are well-supported standards; EIGRP for IPv6 is proprietary to Cisco; and IS-IS for IPv6 is seldom found in enterprise networks.

The following sections describe these protocols.

Static Routes

Like IPv4 static routes, static routes for IPv6 are easily configured. Default routes are represented by double colons with a prefix of zero (::/0). The command to configure an IPv6 static route is

Code View:

Router(config)# ipv6 route ipv6-prefix/prefix-length {ipv6-address |interface-type interface-number [ipv6-address]} [administrative-distance] [administrative-multicast-distance | unicast | multicast] [next-hop-address] [tag tag]

RFC 2461, Neighbor Discovery for IP Version 6 (IPv6), specifies that a router must be able to determine the link-local address of its neighboring routers. Thus, in static routes, the next-hop address must be configured as the link-local address of the neighboring router.

RIPng

RIPng for IPv6 is the next-generation IPv6 version of RIP, based on RIP version 2 (RIPv2). Like RIPv2, RIPng is a distance-vector routing protocol that uses hop count for the metric, has a maximum hop count of 15, and multicasts periodic updates every 30 seconds. RIPng uses a multicast address of FF02::9, the all-RIP-routers multicast group.

RIPng sends updates, using user datagram protocol (UDP) port 521, within IPv6 packets. These updates include an IPv6 prefix and an IPv6 next-hop address.

EIGRP for IPv6

EIGRP for IPv6 is based on EIGRP for IPv4. Like its predecessor, it is an advanced distance-vector routing protocol that uses a complex metric, reliable updates, and the Diffusing Update Algorithm (DUAL) algorithm for fast convergence. EIGRP for IPv6 is available in Cisco IOS 12.4(6)T and later.

IS-IS for IPv6

As discussed in Chapter 9, "Fundamentals of the Integrated IS-IS Protocol," IS-IS runs directly on the data-link layer and is independent of the Layer 3 protocol. Therefore, changing IS-IS to handle IPv6 only required creating a new protocol identifier and two new type length values (TLV)—IPv6 reachability and IPv6 interface address. IS-IS allows one routing update to contain routes from IPv4 and IPv6, resulting in a more efficient use of link capacity than other protocols, such as OSPF.

MP-BGP4 for IPv6

MP-BGP4 includes new extensions to BGP4 that allows it to carry reachability information for other protocols, such as IPv6 and multiprotocol label switching (MPLS); a new identifier is defined for IPv6. The NEXT_HOP attribute can include a global IPv6 unicast address and a link-local address. The NEXT_HOP and network layer reachability information (NLRI) attributes are expressed as IPv6 prefixes and addresses.

OSPFv3

This section details the similarities and differences between OSPFv3 and its predecessor—OSPF version 2 (OSPFv2)—and examines the types of OSPFv3 LSAs.

OSPFv2 and OSPFv3 Similarities

OSPFv3 shares many features with OSPFv2. OSPFv3 is a link-state routing protocol that uses the Dijkstra shortest path first (SPF) algorithm to select the best paths through the network. OSPFv3 routers are organized into areas, with all areas touching area 0 (the backbone area). OSPFv3 routers communicate with their neighbors using Hellos; exchange Link-State Advertisements (LSAs) and Database Descriptors (DBD); and run the SPF algorithm against the accumulated link-state database (LSDB).

OSPFv3 uses the same packet types as OSPFv2, forms neighbor relationships in the same way, and floods and ages LSAs identically. OSPFv3 supports nonbroadcast multiaccess (NBMA) topologies in the same way as OSPFv2: the RFC-compliant nonbroadcast mode and point-to-multipoint mode are supported, and Cisco IOS devices continue to support Cisco's three proprietary modes (point-to-point, broadcast, and point-to-multipoint nonbroadcast). Capabilities such as the various types of stub areas, including not-so-stubby areas (NSSA), and on-demand circuits are also supported.

Note

Because it would be unproductive to repeat a detailed description of link-state theory or OSPF specifics, you may want to make sure you are familiar with Chapters 5 through 8 before proceeding with the rest of this section.

OSPFv2 and OSPFv3 Differences

OSPFv3 also differs from OSPFv2 in many ways. The most obvious is that OSPFv3 supports 128-bit prefixes.

OSPFv3 runs directly within IPv6 packets and can co-exist with OSPFv2. The two routing protocols do not exchange information or pay attention to each other in any way (this is referred to as "ships in the night" routing in some documentation, because packets from the two versions of OSPF pass each other without knowing of the other's existence, like ships passing in the night).

The OSPFv2 multicast addresses are 224.0.0.5 and 224.0.0.6; OSPFv3 uses the IPv6 multicast addresses FF02::5 (for all OSPF routers) and FF02::6 (for all designated routers [DR] and backup DRs [BDR]).

OSPFv3 IPv6 routers are expected to support many addresses per interface, including the link-local address, global unicast addresses, and multicast addresses, including the two addresses for OSPFv3.

OSPFv2 builds neighbor relationships about subnets, but the terms "network" or "subnet" imply a specific address space on an interface; in contrast, OSPFv3 is only concerned about its connection across a link to its neighbor. Thus, OSPFv3 terminology is discussed in terms of links, and an OSPFv3 router uses its link-local address as the source address of its advertisements—not its global unicast address. It uses the appropriate OSPFv3 IPv6 multicast address as the destination address.

The OSPFv3 packet header is 16 bytes, while the OSPFv2 packet header is 24 bytes. Figure 21-1 illustrates the OSPFv3 packet header.

Figure 21-1. OSPFv3 Packet Header

Authentication is not built-in to OSPFv3; the authentication and authentication type fields in the OSPFv2 header do not appear in the OSPFv3 header. OSPFv3 instead relies on the underlying capabilities of IPv6 to provide authentication and encryption, using extension headers.

OSPFv2 can run multiple processes but can only run one copy of OSPF per link. The new instance ID field in the OSPFv3 header is used to differentiate OSPF processes; two instances need to have the same instance ID to communicate with each other. This allows multiple routing domains to communicate across the same link. Separate neighbor tables, link-state databases, and shortest-path trees are kept for each instance.

Perhaps surprisingly, the OSPFv3 router ID and area ID (and the link-state ID within an LSA) are still 32-bit numbers, and they are written in an IPv4-address dotted decimal format. In the same way that IS-IS requires a Connectionless Network Service (CLNS) address, OSPFv3 reveals its heritage in IPv4 by requiring a 32-bit number for its router ID. The OSPFv3 DR and BDR are identified by their router ID, not by their IP address, as they are identified in OSPFv2.

OSPFv3 LSA Types

OSPFv3 and OSPFv2 use a similar set of LSAs, with some differences. Table 21-2 lists the OSPFv3 LSAs, including the LSA function code, which indicates the function of the LSA.

Table 21-2. OSPFv3 LSAs
LSA Function Code	Name	Description
1	Router-LSA	Advertise router IDs within an area, from a router
2	Network-LSA	Advertise router IDs within an area, from a DR
3	Inter-Area-Prefix-LSA	Advertise prefixes from one area to another
4	Inter-Area-Router-LSA	Advertise location of an autonomous system boundary router (ASBR)
5	AS-External-LSA	Advertise routes redistributed into OSPF
6	Group-Membership LSA	Advertise multicast information
7	Type-7-LSA	Pass external routes through an NSSA
8	Link-LSA	Advertise a router's link-local address to directly attached neighbors and allow the local routers to share prefix and option information
9	Intra-Area-Prefix-LSA	Advertise prefixes associated with a router ID

Note

The LSA link-state (LS) type is created by concatenating 0x200 with the LSA function code. For example, LSA function code 1 has an LS type 0x2001. However, because the 0x200 doesn't really add any new information, the LS function code typically is used when discussing LS types.

LSA types 1 and 2 no longer contain route prefixes; instead, they contain 32-bit IDs. Types 3 and 4 have been renamed but still fulfill the same functions as they do in OSPFv2. Types 8 and 9 are new LSAs in OSPFv3.

In OSPFv3, address prefixes are stored as prefix, options, and prefix length. Addresses are expressed as prefix, prefix length, a more flexible format than the OSPFv2 method of using prefix and mask.

OSPFv3 type 3 and type 9 LSAs carry all IPv6 prefix information; in OSPFv2, IPv4 prefix information is carried in router and network LSAs (type 1 and type 2).

LSAs are sourced from the link-local address of an interface and have an OSPFv3 IPv6 multicast address as the destination address.

Configuring and Verifying IPv6 and OSPFv3

This section describes how to configure and verify IPv6 and OSPFv3.

IPv6 Configuration

Before configuring any routing protocol, IPv6 support must be enabled on the router; it is turned off by default. The command to enable IPv6 is

Router(config)#ipv6 unicast-routing

Enable Cisco Express Forwarding (CEF) for IPv6 (CEFv6) using the following command:

Router(config)#ipv6 cef

CEFv6 is an advanced, Layer 3 IP-switching technology for forwarding IPv6 packets.

Next, configure interfaces with IPv6 unicast addresses, using the following command:

Router(config-if)#ipv6 address ipv6-address/prefix-length [eui-64]

The eui-64 parameter causes the router to complete the lower order 64 bits of the address using an extended universal identifier 64-bit (EUI-64) format interface ID, as described in Chapter 20, "Introduction to IPv6 and IPv6 Addressing."

The IPv6 configuration for Router A in Figure 21-2 is shown in Example 21-1.

Figure 21-2. Sample IPv6 Network

[View full size image]

Example 21-1. IPv6 Configuration of Router A in Figure 21-2

RouterA#configure terminal
RouterA(config)#ipv6 unicast-routing
RouterA(config)#ipv6 cef
RouterA(config)#interface fastethernet0/0
RouterA(config-if)#description Local LAN
RouterA(config-if)#ipv6 address 2001:0:1:1::2/64
RouterA(config-if)#interface serial 1/0
RouterA(config-if)#description point-to-point connection to Internet
RouterA(config-if)#ipv6 address 2001:0:1:5::1/64

OSPFv3 Configuration

The two main configuration and troubleshooting differences between OSPFv2 and OSPFv3 are

The inclusion of the ipv6 keyword in OSPFv3 commands.
The fact that interfaces are enabled for OSPFv3 in interface configuration mode instead of using the network command in router configuration mode, as is done for OSPFv2.

Assuming that IPv6 routing is enabled and IPv6 addresses are configured on the appropriate interfaces, the commands used to implement OSPFv3 are

Code View:

Router(config)#ipv6 router ospf process-id
Router(config-rtr)#router-id 32-bit-router-id
Router(config-rtr)#area area-id range summary-range/prefix-length [advertise | not-advertise ] [cost cost]
Router(config-rtr)#interface type number
Router(config-if)#ipv6 ospf process-id area area-id [instance instance-id]
Router(config-if)#ipv6 ospf priority priority
Router(config-if)#ipv6 ospf cost interface-cost

The router ID must be a 32-bit number in an IPv4-address dotted decimal format, and can be set to the value of an IPv4 address on the router. Priority works the same way it does for OSPFv2. Routers default to a priority of 1; a higher priority means a better chance of being elected DR or BDR, and 0 means that the router will not serve as a DR or BDR.

Cost also has not changed and is by default inversely proportional to the bandwidth of the interface. The default cost may be overridden with the ipv6 ospf cost command.

The area range command provides summarization, which is off by default in OSPFv3 as it is in OSPFv2. Scalability comes from summarization, and summarization comes from assigning addresses in a way that can be grouped, and from building a hierarchical network with natural points where summarization may be implemented. OSPFv3 allows redistribution of routes to and from other IPv6 routing protocols and allows route filtering in the same ways that OSPFv2 does.

Note

For OSPFv3, the cost of the summarized route is the highest cost of the routes being summarized.

To help explain OSPFv3 configuration an example topology is shown in Figure 21-3. Both routers are area border routers (ABRs), and Router B has a loopback interface.

Figure 21-3. A Simple OSPFv3 Network Topology

Example 21-2 shows a simple OSPFv3 configuration on Router A.

Example 21-2. OSPFv3 Configuration on Router A in Figure 21-3

RouterA#configure terminal
RouterA(config)#ipv6 unicast-routing
RouterA(config)#ipv6 cef
RouterA(config)#ipv6 router ospf 1
RouterA(config-rtr)#router-id 10.255.255.1
RouterA(config-rtr)#interface fastethernet0/0
RouterA(config-if)#description Local LAN
RouterA(config-if)#ipv6 address 2001:0:1:1::2/64
RouterA(config-if)#ipv6 ospf 1 area 1
RouterA(config-if)#ipv6 ospf cost 10
RouterA(config-if)#ipv6 ospf priority 20
RouterA(config-if)#interface serial 1/0
RouterA(config-if)#description multi-point line to Internet
RouterA(config-if)#ipv6 address 2001:0:1:5::1/64
RouterA(config-if)#ipv6 ospf 1 area 0
RouterA(config-if)#ipv6 ospf priority 20

Router B is configured similarly. The outputs of the show commands in the following section are from the routers in this same network.

Verifying IPv6 and OSPFv3 Configuration

This section illustrates some of the commands used to verify IPv6 and OSPFv3.

show ipv6 route, clear ipv6, and ping ipv6 Commands

Approach troubleshooting OSPFv3 the same way that you do for OSPFv2: Start by using the show ipv6 route command to verify whether the expected routes are being advertised. Assuming that a route is in the routing table, test reachability to it using the ping [ipv6] ipv6-address command.

Note

The ipv6 keyword in the ping [ipv6] ipv6-address command is optional because if the Cisco IOS recognizes that the address is an IPv6 address it will perform an IPv6 ping.

The clear ipv6 ospf [process-id] {process | force-spf | redistribution | counters [neighbor [neighbor-interface | neighbor-id ]]} command triggers SPF recalculation and repopulation of the routing table.

Example 21-3 provides the routing table on Router A in Figure 21-3. The address of Router B's loopback interface is in this routing table, learned from Router B via the Fast Ethernet 0/0 interface. Connectivity to the loopback interface is verified with a ping.

Example 21-3. IPv6 Routing Table on Router A in Figure 21-3

Code View:

RouterA#show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
C   2001:0:1:2::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:0:1:2::2/128 [0/0]
     via ::, FastEthernet0/0
OI  2001:0:1:6::/64 [110/1010]
     via FE80::213:80FF:FE63:D676, FastEthernet0/0
O   2001:0:1:FFFF::1/128 [110/10]
     via FE80::213:80FF:FE63:D676, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
RouterA#ping ipv6 2001:0:1:FFFF::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:0:1:FFFF::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

show ipv6 interface Command

The show ipv6 interface [brief] [interface-type interface-number] [prefix] command displays IPv6 information about an interface, as displayed in Example 21-4.

Example 21-4. show ipv6 interface brief Command Output

RouterA#show ipv6 interface brief
FastEthernet0/0            [up/up]
    FE80::213:80FF:FE63:D66E
    2001:0:1:1::2
Serial1/0                  [up/down]
    FE80::213:80FF:FE63:D66E
    2001:0:1:5::1

show ipv6 ospf interface Command

One common reason that OSPFv3 routes may not be propagated on an interface is that the interface is not enabled for OSPFv3. A quick way to check this, as well as to get interface-specific OSPFv3 information, is with the show ipv6 ospf interface command. Example 21-5 demonstrates this command. The highlighted lines indicate the link-local address, area ID, and router ID.

Example 21-5. OSPFv3 Interface Troubleshooting

Code View:

RouterA#show ipv6 ospf interface fa0/0
FastEthernet0/0 is up, line protocol is up
  Link Local Address FE80::213:80FF:FE63:D66E, Interface ID 2
  Area 1, Process ID 1, Instance ID 0, Router ID 10.255.255.1
  Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 20
  Designated Router (ID) 10.255.255.2, local address FE80::213:80FF:FE63:D676
  Backup Designated router (ID) 10.255.255.1, local address FE80::213:80FF:FE63
D66E
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:01
  Index 1/1/2, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 10.255.255.2 (Designated Router)
  Suppress hello for 0 neighbor(s)

show ipv6 ospf Command

The show ipv6 ospf command allows you to verify the OSPFv3 router ID and timers, as well as other general routing protocol settings. Example 21-6 provides output of this command.

Example 21-6. OSPFv3 Protocol Troubleshooting

Code View:

RouterA#show ipv6 ospf
 Routing Process "ospfv3 1" with ID 10.255.255.1
 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of areas in this router is 2. 2 normal 0 stub 0 nssa
    Area BACKBONE(0) (Inactive)
        Number of interfaces in this area is 1
        SPF algorithm executed 1 times
        Number of LSA 1. Checksum Sum 0x008A7A
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
    Area 1
        Number of interfaces in this area is 1
        SPF algorithm executed 9 times
        Area ranges are
          2001:0:1::/80 Passive Advertise
        Number of LSA 9. Checksum Sum 0x05CCFF
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

show ipv6 ospf neighbor Command

Another important step in troubleshooting OSPFv3 is to verify that neighbor relationships have been established with the appropriate directly connected routers, using the show ipv6 ospf neighbor [detail] command. Sample output of this command is shown in Example 21-7.

Example 21-7. OSPFv3 Neighbor Troubleshooting

RouterA#show ipv6 ospf neighbor detail
 Neighbor 10.255.255.2
    In the area 1 via interface FastEthernet0/0
    Neighbor: interface-id 2, link-local address FE80::213:80FF:FE63:D676
    Neighbor priority is 20, State is FULL, 6 state changes
    DR is 10.255.255.2 BDR is 10.255.255.1
    Options is 0x81EA8189
    Dead timer due in 00:00:31
    Neighbor is up for 00:03:28
    Index 1/1/1, retransmission queue length 0, number of retransmission 1
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 2, maximum is 2
    Last retransmission scan time is 0 msec, maximum is 0 msec

show ipv6 ospf database Command

The OSPFv3 database may be displayed using the show ipv6 ospf database and show ipv6 ospf database database-summary commands. The first command shows a list of LSAs received that may be helpful in recognizing how routes are propagated, while the second command simply provides totals for the various types of LSAs. However, troubleshooting based on this output can be difficult. Outputs from both of these commands are shown in Example 21-8.

Example 21-8. OSPFv3 Database

Code View:

RouterA#show ipv6 ospf database

            OSPFv3 Router with ID (10.255.255.1) (Process ID 1)

                Router Link States (Area 0)

ADV Router      Age         Seq#        Fragment ID  Link count  Bits
10.255.255.1    799         0x80000003  0            0           None

                Link (Type-8) Link States (Area 0)

ADV Router      Age         Seq#        Link ID    Interface

                Router Link States (Area 1)

ADV Router      Age         Seq#        Fragment ID  Link count  Bits
10.255.255.1    235         0x80000008  0            1           None
10.255.255.2    240         0x80000007  0            1           B
                Net Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Rtr count
10.255.255.2    946         0x80000001  2          2

                Inter Area Prefix Link States (Area 1)

ADV Router      Age         Seq#        Prefix
10.255.255.2    977         0x80000001  2001:0:1:5::/64

                Link (Type-8) Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Interface
10.255.255.1    247         0x80000004  2          Fa0/0
10.255.255.2    980         0x80000002  2          Fa0/0

                Intra Area Prefix Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Ref-lstype Ref-LSID
10.255.255.2    915         0x80000002  1002       0x2002 2

RouterA#show ipv6 ospf database database-summary

            OSPFv3 Router with ID (10.255.255.1) (Process ID 1)

Area 0 database summary
  LSA Type            Count    Delete   Maxage
  Router              1        0        0
  Network             0        0        0
  Link                0        0        0
  Prefix              0        0        0
  Inter-area Prefix   0        0        0
  Inter-area Router   0        0        0
  Type-7 External     0        0        0
  Subtotal            1        0        0

Area 1 database summary
  LSA Type            Count    Delete   Maxage
  Router              2        0        0
  Network             1        0        0
  Link                2        0        0
  Prefix              1        0        0
  Inter-area Prefix   1        0        0
  Inter-area Router   0        0        0
  Type-7 External     0        0        0
  Subtotal            7        0        0
Process 1 database summary
  LSA Type            Count    Delete   Maxage
  Router              3        0        0
  Network             1        0        0
  Link                2        0        0
  Prefix              1        0        0
  Inter-area Prefix   1        0        0
  Inter-area Router   0        0        0
  Type-7 External     0        0        0
  Type-5 Ext          0        0        0
Total                 8        0        0

Transitioning from IPv4 to IPv6

At this point, you might be thinking that IPv6 is exciting, that it represents the future of networking, and you want to deploy it today! Reality sets in when you realize that—although you are clearly a networker of the future—today's Internet still uses IPv4. How will you communicate with the websites and e-mail servers that your business depends on?

One great solution would be to have everyone change all of their systems to IPv6 on a single day—April 1 has been suggested. Since this seems an unlikely solution, this chapter ends with some ideas about managing the transition period which, as a practical matter, may stretch out for years. Success during the transition period means integrating IPv6 nodes into your network, allowing them to communicate to IPv4 nodes, and making the whole process transparent to users.

Several transition mechanisms have been proposed, including

Dual stack
Tunneling
Translation

These transition mechanisms are described in the following sections.

Dual Stack

The dual-stack approach simply means to run IPv6 and IPv4 concurrently, with no communication between the two. Hosts and routers have both IPv4 and IPv6 addresses and use whichever is appropriate to reach a given resource. If a resource, such as a server, is reachable using either protocol, IPv6 should be used.

To implement dual stack on a Cisco router, simply enable IPv6 and configure IPv4 and IPv6 interface addresses, as demonstrated in Example 21-9.

Example 21-9. Dual-Stack Configuration

RouterA#configure terminal
RouterA(config)#ipv6 unicast-routing
RouterA(config)#ipv6 cef
RouterA(config)#interface fastethernet0/0
RouterA(config-if)#ip address 192.168.0.1 255.255.255.0
RouterA(config-if)#ipv6 address 2001:0:1:1::2/64

The dual-stack approach allows servers, clients, and applications to be gradually moved to the new protocol. Global experience with changing applications to support IPv6 has usually resulted in minimal impact on the applications. Furthermore, running two protocols concurrently is a well-known and tested approach to protocol transition that has been used in the past; for example, it was used by many organizations switching from Internetwork Packet Exchange (IPX) to IPv4 in the 1990s.

Tunneling

Dual stack works so long as the infrastructure supports both protocols, but in some cases the core of the network will only support IPv4. Until the core is upgraded, another technique is needed, such as tunneling between IPv6 "islands."

With tunneling, routers that straddle the IPv4 and IPv6 worlds encapsulate the IPv6 traffic inside IPv4 packets. The source of the IPv4 packet is the local router and the destination is the peer router at the other end of the tunnel. When the destination router receives the IPv4 packet, it decapsulates the external IPv4 header and forwards the enclosed IPv6 traffic.

Tunneling is effective, but decreases the maximum transmission unit (MTU) because of the 20 bytes consumed by the IPv4 header on the intermediate links. Tunneling can also be difficult to troubleshoot.

Four types of tunneling are described in this section: manual, 6-to-4, Teredo, and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

Manual Tunnels

Configuring manual tunneling is not difficult, as shown in Example 21-10 for Router A in Figure 21-4.

Example 21-10. Manual Tunnel Configuration of Router A in Figure 21-4

RouterA#configure terminal
RouterA(config)#interface tunnel0
RouterA(config-if)#ipv6 address 2001:0:1:5::1/64
RouterA(config-if)#tunnel source 192.168.1.1
RouterA(config-if)#tunnel destination 192.168.7.1
RouterA(config-if)#tunnel mode ipv6ip

Figure 21-4. Manual Tunneling

[View full size image]

The tunnel mode ipv6ip command specifies that the manual IPv6 tunnel has IPv6 as the passenger protocol and IPv4 as both the encapsulation and transport protocols.

Note

The show interface tunnel command shows the details of the tunnel interface; the clear counters tunnel interface-number command clears the counters displayed in the show interface tunnel command.

Tunneling also works between a PC and a router. For instance, a dual-stack workstation can send tunneled traffic that is removed from the tunnel by the router it is communicating with.

IPv6-to-IPv4 (6-to-4) Tunnels

A 6-to-4 tunnel works similarly to a manual tunnel, except that the tunnel is set up automatically. 6-to-4 tunnels use IPv6 addresses that concatenate 2002::/16 with the 32-bit IPv4 address of the edge router, creating a 48-bit prefix.

An example of 6-to-4 tunneling is shown in Figure 21-5. The tunnel interface on Router A has an IPv6 prefix of 2002:C0A8:501::/48, where C0A8:501 is the hexadecimal equivalent of 192.168.5.1, the IPv4 address of its interface in the IPv4 network. The tunnel interface on Router B has an IPv6 prefix of 2002:C0A8:122::/48, where C0A8:122 is the hexadecimal equivalent of 192.168.1.34, the IPv4 address of its interface in the IPv4 network. Note that the prefixes are subnetted appropriately on each side of the tunnel and each router has a static route across the tunnel to the prefix of the other router. When Router A receives traffic with an IPv6 destination address of 2002:C0A8:122:1::2, the following occurs:

Router A extracts the IPv4 address from the IPv6 address. In this case, the IPv4 address is C0.A8.01.22, which in dotted decimal format is 192.168.1.34.
Router A encapsulates the IPv6 packet in an IPv4 packet with a destination address of 192.168.1.34; the packet is routed normally through the IPv4 network to Router B.
Router B receives the IPv4 packet, decapsulates the IPv6 packet, and routes it normally to its final IPv6 destination.

Figure 21-5. 6-to-4 Tunneling

[View full size image]

Teredo

Another type of tunnel is called Teredo (also known as shipworm). Teredo encapsulates IPv6 packets in IPv4/UDP segments and works similarly to other tunnels but with the added benefit of being able to traverse network address translation (NAT) devices and firewalls. Teredo is described in RFC 4380, Teredo: Tunneling IPv6 over UDP through Network Address Translations (NAT).

ISATAP

ISATAP treats the IPv4 network as an NBMA network and allows an IPv4 private network to incrementally implement IPv6 without upgrading the network. ISATAP is documented in RFC 4214, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

Translation

The problem with tunneling, whether manually or automatically configured, is that it is a dual-stack solution. IPv6 clients must continue to support IPv4 to contact IPv4-only devices.

Translation is a different type of solution, allowing IPv6 devices to communicate with IPv4 devices, without requiring either to be dual stack.

Stateless IP/ICMP Translation (SIIT) translates IP header fields, and NAT Protocol Translation (NAT-PT) maps IPv6 addresses to IPv4 addresses. If IPv6 is used on the inside of a network and IPv4 is used on the outside, a NAT-PT device receives IPv6 traffic on its inside interface and replaces the IPv6 header with an IPv4 header before sending it to an outside interface. Reply traffic follows the mapping backwards, enabling two-way communication.

Good NAT implementations interpret application traffic and understand when IP information is included in the application data; NAT-PT inherits this capability. For example, DNS packets include IP addresses; therefore, NAT-PT must recognize DNS traffic and change the IPv4 addresses into IPv6 addresses, and vice-versa.

IPv4 and IPv6 routing domains can also be connected using application-level gateways (ALG) or proxies. A proxy intercepts traffic and converts between the two protocols; it can increase the transmission speed by responding to some requests using information in its cache. A separate ALG is required to support each protocol, so this method only solves specific types of translation problems.

Bump-in-the-API (BIA) and Bump-in-the-Stack (BIS) are NAT-PT implementations within a host. BIA/BIS intercepts system calls to IPv4 functions and dynamically responds with IPv6 information, allowing, for example, a server to be converted to IPv6 without rewriting applications. This approach will not work, however, for applications that embed IP addresses in the payload, such as the file transfer protocol (FTP).