Table 10-7 Description of show ipv6 ospf neighbor detail Command Output in Example 10-9
| Field | Description |
|---|---|
| Neighbor | Neighbor router ID |
| In the area | Area and interface through which the OSPF neighbor is known |
| Neighbor priority | OSPF priority of the neighbor |
| State | OSPF neighbor relationship state |
| State changes | Number of state changes since the neighbor relationship was established |
| Options | Hello packet options field contents (Possible values of the external bit [e-bit] are 0 and 2; 2 indicates that the area is not a stub, and 0 indicates that the area is a stub.) |
| Dead timer due in | Amount of time before the neighbor is declared dead |
| Neighbor is up for | Time, in hours:minutes:seconds, since the neighbor went into two-way state |
| Index | Neighbor location in the area-wide and autonomous system-wide retransmission queue |
| retransmission queue length | Number of elements in the retransmission queue |
| number of retransmission | Number of times update packets have been resent during flooding |
| First | Memory location of the flooding details |
| Next | Memory location of the flooding details |
| Last retransmission scan length | Number of LSAs in the last retransmission packet |
| maximum | Maximum number of LSAs sent in any retransmission packet |
| Last retransmission scan time | Time taken to build the last retransmission packet |
| maximum | Maximum time taken to build any retransmission packet |
show ipv6 ospf database Command
The show ipv6 ospf database command displays the OSPF for IPv6 database, as illustrated in Example 10-10.
Example 10-10 show ipv6 ospf database Command Output
RouterA#show ipv6 ospf database
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
ADV Router Age Seq# Fragment ID Link count Bits
1.1.1.1 485 0x80000005 0 1 B
3.3.3.3 485 0x80000002 0 1 None
Net Link States (Area 0)
ADV Router Age Seq# Link ID Rtr count
1.1.1.1 494 0x80000001 4 2
Inter Area Prefix Link States (Area 0)
ADV Router Age Seq# Prefix
1.1.1.1 1360 0x80000001 3FEE:FFEF:1::/64
Link (Type-8) Link States (Area 0)
ADV Router Age Seq# Link ID Interface
1.1.1.1 1504 0x80000001 4 Fa0/0
3.3.3.3 496 0x80000001 4 Fa0/0
Intra Area Prefix Link States (Area 0)
ADV Router Age Seq# Link ID Ref-lstype Ref-LSID
1.1.1.1 561 0x80000001 1004 0x2002 4
Router Link States (Area 1)
ADV Router Age Seq# Fragment ID Link count Bits
1.1.1.1 1316 0x80000002 0 0 B
Inter Area Prefix Link States (Area 1)
ADV Router Age Seq# Prefix
1.1.1.1 1436 0x80000001 3FEE:FFFF:1::/64
Link (Type-8) Link States (Area 1)
ADV Router Age Seq# Link ID Interface
1.1.1.1 1436 0x80000001 6 Se0/0/0
Intra Area Prefix Link States (Area 1)
ADV Router Age Seq# Link ID Ref-lstype Ref-LSID
1.1.1.1 1436 0x80000001 0 0x2001 0
Table 10-8 provides a description of some of the fields in the output of the show ipv6 ospf database command in Example 10-10.
Table 10-8 Description of show ipv6 ospf database Command Output in Example 10-10
| Field | Description |
|---|---|
| ADV Router | Advertising router ID |
| Age | Link-state age |
| Seq# | Link-state sequence number (detects old or duplicate LSAs) |
| Link ID | Interface ID number |
| Ref-lstype | Referenced link-state type (as described in Table 10-3) |
The show ipv6 ospf database database-summary command displays a summary of the OSPF for IPv6 database, as illustrated in Example 10-11.
Example 10-11 show ipv6 ospf database database-summary Command Output
RouterA#show ipv6 ospf database database-summary
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Area 0 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
Unknown 0 0 0
Subtotal 7 0 0
Area 1 database summary
LSA Type Count Delete Maxage
Router 1 0 0
Network 0 0 0
Link 1 0 0
Prefix 1 0 0
Inter-area Prefix 1 0 0
Inter-area Router 0 0 0
Type-7 External 0 0 0
Unknown 0 0 0
Subtotal 4 0 0
Process 1 database summary
LSA Type Count Delete Maxage
Router 3 0 0
Network 1 0 0
Link 3 0 0
Prefix 2 0 0
Inter-area Prefix 2 0 0
Inter-area Router 0 0 0
Type-7 External 0 0 0
Unknown 0 0 0
Type-5 Ext 0 0 0
Unknown AS 0 0 0
Total 11 0 0
Transitioning IPv4 to IPv6
The successful market adoption of any new technology depends on its easy integration with the existing infrastructure without significant disruption of services. The Internet consists of hundreds of thousands of IPv4 networks and millions of IPv4 nodes. The challenge for IPv6 lies in making the integration of IPv4 and IPv6 nodes and the transition to IPv6 as transparent as possible to end users.
The transition from IPv4 to IPv6 does not require upgrades on all nodes at the same time; IPv4 and IPv6 will coexist for some time.
The two most common techniques to transition from IPv4 to IPv6 are dual stack and tunneling. Alternatively, mechanisms that allow communication between IPv4 and IPv6 nodes can be used. These techniques and mechanisms are described in the following sections.
Dual Stack
Dual stack is an integration method where a node has connectivity to both an IPv4 and IPv6 network; thus the node has two protocol stacks, as illustrated in Figure 10-18. The two stacks can be on the same interface or on multiple interfaces.
Devices Can Be Dual-Stacked to Communicate with Both IPv4 and IPv6
A dual-stack node chooses which stack to use based on destination address; the node should prefer IPv6 when available. The dual-stack approach to IPv6 integration will be one of the most commonly used methods. Old IPv4-only applications will continue to work as before, while new and modified applications take advantage of both IP layers.
A new application programming interface (API) supports both IPv4 and IPv6 addresses and Domain Name System (DNS) requests and replaces the "gethostbyname" and "gethostbyaddr" calls. A converted application will be able to make use of both IPv4 and IPv6. An application can be converted to the new API while still using only IPv4.
Past experience in porting IPv4 applications to IPv6 suggests that, for most applications, it is a minimal change in some localized places inside the source code. This technique is well-known and has been applied in the past for other protocol transitions, enabling gradual application upgrades one-by-one to IPv6.
Cisco IOS Software is IPv6-ready: As soon as IPv4 and IPv6 configurations are complete on an interface, the interface is dual-stacked and it forwards both IPv4 and IPv6 traffic.
As discussed earlier, using IPv6 on a Cisco IOS router requires that you use the ipv6 unicast-routing global configuration command to enable the forwarding of IPv6 datagrams. All interfaces that forward IPv6 traffic must have an IPv6 address, which is configured with the ipv6 address address/prefix-length [eui-64] interface configuration command. This command specifies the IPv6 network assigned to the interface and enables IPv6 processing on the interface.
Figure 10-19 illustrates an example of a router with both IPv4 and IPv6 addresses connected to a network that is running both protocols.
When Both IPv4 and IPv6 Addresses Are Configured, the Interface Is Dual-Stacked
Tunneling
Tunnels are often used in networking to overlay incompatible functions over an existing network. For IPv6, tunneling is an integration method in which an IPv6 packet is encapsulated within another protocol, such as IPv4. Tunneling IPv6 inside of IPv4 uses IPv4 protocol 41. When tunneling IPv6 traffic over an IPv4 network, one edge router encapsulates the IPv6 packet inside an IPv4 packet and the router at the other edge decapsulates it, and vice versa. This enables the connection of IPv6 islands without the need to convert the intermediary network to IPv6.
As illustrated in Figure 10-20, a 20-byte IPv4 header (if there are not any options in the header) is included before the IPv6 header and payload (data). The routers involved are dual stacking.
Tunneling IPv6 Inside IPv4 Packets
When tunneling, the MTU is effectively decreased by 20 octets (or more if the IPv4 header contains any optional fields). Because of this restriction and the fact that a tunneled network is often difficult to troubleshoot, tunneling is an intermediate integration/transition technique that should not be considered a final solution. A native IPv6 network should be the ultimate goal.
Tunneling can be done by edge routers either between hosts as shown in Figure 10-20, or between a host and a router, as shown in Figure 10-21. In Figure 10-21, an isolated dual-stack host uses an encapsulated tunnel to connect to the edge router of the IPv6 network.
Isolated Dual-Stack Host
Note that tunneling will not work if an intermediary node between the two end points of the tunnel, such as a firewall, filters out IPv4 protocol 41, the IPv6 in IPv4 encapsulation protocol.
Configured tunnels require dual-stack end points and IPv4 and IPv6 addresses configured at each end, as illustrated in Figure 10-22.
Tunneling Requires IPv6 and IPv4 Configured at Each End
Tunnels can be either manually or automatically configured.
Manually Configured Tunnels
For a manually configured tunnel, you configure both the IPv4 and IPv6 addresses statically on the routers at each end of the tunnel.
The end routers must be dual-stacked, and the configuration will not change dynamically as network and routing needs change. IPv4 routing must be set up properly to forward a packet between the two IPv6 networks.
The interfaces used as tunnel end points can be unnumbered, but unnumbered interfaces make troubleshooting more difficult. The IPv4 practice of using unnumbered interfaces to save address space is no longer an issue.
Figure 10-23 shows two routers connecting IPv6 networks through IPv4 encapsulation. Example 10-12 and Example 10-13 provide the configurations for the two routers.
Network Used to Illustrate Tunnel Configuration
Example 10-12 Configuration of Router 1 in Figure 10-23
interface Tunnel0 ipv6 address 2001:db8:1::1/64 tunnel source 192.168.2.1 tunnel destination 192.168.30.1 tunnel mode ipv6ip
Example 10-13 Configuration of Router 2 in Figure 10-23
interface Tunnel0 ipv6 address 2001:db8:1::2/64 tunnel source 192.168.30.1 tunnel destination 192.168.2.1 tunnel mode ipv6ip
The command interface Tunnel0 creates the tunnel interface, on which a static IPv6 address is configured with the ipv6 address command. The tunnel source and tunnel destination commands specify the IPv4 source and destination addresses of the tunnel, respectively. These are addresses in the underlying IPv4 network. The tunnel mode ipv6ip command specifies a manual IPv6 tunnel with IPv6 as the passenger protocol, and IPv4 as both the encapsulation and transport protocol.
The clear counters tunnel interface-number command clears the counters displayed in the show interface tunnel command.
Other Tunneling Mechanisms
Several automatic tunneling transition mechanisms exist, including the following:
6-to-4—This mechanism uses the reserved prefix 2002::/16 to allow an IPv4-connected site to create and use a /48 IPv6 prefix based on a single globally routable/reachable IPv4 address. 6-to-4 tunneling is described further in the next section, "6-to-4 Tunneling."
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)—ISATAP allows an IPv4 private intranet (that may or may not be using RFC 1918 addresses) to incrementally implement IPv6 nodes without upgrading the network.
Teredo (formerly known as shipworm)—This mechanism tunnels IPv6 datagrams within IPv4 UDP datagrams, allowing private IPv4 address and IPv4 NAT traversal to be used.
6-to-4 Tunneling
The 6-to-4 tunneling method automatically connects IPv6 islands through an IPv4 network, as illustrated in Figure 10-24.
6-to-4 Tunnels Are Built Automatically by the Edge Routers
Each 6-to-4 edge router has an IPv6 address with a /48 prefix, which is the concatenation of 2002::/16 and the hexadecimal representation of the IPv4 address of the edge router; 2002::/16 is a specially assigned address range for the purpose of 6-to-4 tunneling. The edge routers automatically build the tunnel using the IPv4 addresses that are embedded in the IPv6 addresses. For example, if the IPv4 address of an edge router is 192.168.99.1, the prefix of its IPv6 address is 2002:c0a8:6301::/48, because 0xc0a86301 is the hexadecimal representation of 192.168.99.1.
6-to-4 tunnels enable the fast deployment of IPv6 in a corporate network without the need for addresses from ISPs or registries. The 6-to-4 tunneling method requires special code on the edge routers, but the IPv6 hosts and routers inside of the 6-to-4 site do not require new features.
When the edge router receives an IPv6 packet with a destination address in the range of 2002::/16, it determines from its routing table that the packet must traverse the tunnel. The router extracts the IPv4 address embedded in the third to sixth octets, inclusively, in the IPv6 next-hop address. This IPv4 address is the IPv4 address of the 6-to-4 router at the destination site—the router at the other end of the tunnel. The router encapsulates the IPv6 packet in an IPv4 packet with the destination edge router's extracted IPv4 address.
The packet passes through the IPv4 network. The destination edge router decapsulates the IPv6 packet from the received IPv4 packet and forwards the IPv6 packet to its final destination. (A 6-to-4 relay router, which offers traffic forwarding to the IPv6 Internet, is required for reaching a native IPv6 Internet.)
Translation Mechanisms
Dual stack and tunneling techniques manage the interconnection of IPv6 domains. For legacy equipment that will not be upgraded to IPv6 and for some deployment scenarios, techniques are available for connecting IPv4-only nodes to IPv6-only nodes using translation, an extension of NAT techniques.
As shown in Figure 10-25, NAT-PT is a translation mechanism that sits between an IPv6 network and an IPv4 network. The job of the translator is to translate IPv6 packets into IPv4 packets and vice versa.
IPv4 - IPv6 Translation Mechanism
The Stateless IP/ICMP Translation (SIIT) algorithm translates the IP header fields, while NAT handles the IP address translation. Figure 10-25 shows static NAT-PT translations; NAT-PT translations may also be mapped dynamically based on DNS queries using a DNS-application layer gateway (DNS-ALG). ALGs use a dual-stack approach and enable a host in an IPv6-only domain to send data to another host in an IPv4-only domain. This method requires that all application servers run IPv6.
The example in Figure 10-25 illustrates the translation of an IPv6 datagram sent from node A to node D. From the perspective of node A, it is establishing a communication to another IPv6 node. One advantage of NAT-PT is that no modifications are required on IPv6 node A; all it needs to know is the IPv6 address mapping of the IPv4 address of node D. This mapping can be obtained dynamically from the DNS server. IPv4 node D can also send a datagram to node A by using the IPv4 address mapped to the IPv6 address of node A. Again, from the perspective of node D, it is establishing IPv4 communication with node A; node D does not require modification.
APIs can be installed in a host's TCP/IP stack to intercept IP traffic through the API and convert it for the IPv6 counterpart.