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.
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
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 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 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.
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 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.
This section details the similarities and differences between OSPFv3 and its predecessor—OSPF version 2 (OSPFv2)—and examines the types of OSPFv3 LSAs.
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.
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.
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 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.
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.
This section describes how to configure and verify IPv6 and OSPFv3.
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.
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 |
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
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.
Example 21-2 shows a simple OSPFv3 configuration on Router A.
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.
This section illustrates some of the commands used to verify IPv6 and OSPFv3.
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.
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 |
The show ipv6 interface [brief] [interface-type interface-number] [prefix] command displays IPv6 information about an interface, as displayed in Example 21-4.
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 |
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.
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) |
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.
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
|
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.
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 |
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.
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 |
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.
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.
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.
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).
Configuring manual tunneling is not difficult, as shown in Example 21-10 for 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 |
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.
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.
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 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).
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).