Understanding IP Version 6
The ability to scale networks for future demands requires a new generation of IP addresses. IPv6 combines expanded addressing with a more efficient and feature-rich header to meet the demands for scalable networks in the future. This section describes the functionality and benefits of IPv6.
Benefits of IPv6
IPv6 is a powerful enhancement to IPv4. Its primary features are as follows:
The larger address space provides new global reachability, flexibility, aggregation, multihoming, autoconfiguration, plug and play, and renumbering. IPv6 increases the IP address size from 32 bits to 128 bits, allowing more support for addressing hierarchical levels, a much greater number of addressable nodes, and simpler autoconfiguration of addresses.
The simpler, fixed-size header enables better routing efficiency, performance, and forwarding rate scalability.
The numerous possibilities to transition from IPv4 to IPv6 allow existing IPv4 capabilities to exist with the added features of IPv6. Various mechanisms are defined for transitioning to IPv6, including dual stack, tunneling, and translation.
Mobility and security ensures compliance with Mobile IP and IP Security (IPSec) standards.
Mobility is an important feature in networks. Mobile IP is an Internet Engineering Task Force (IETF) standard available for both IPv4 and IPv6. This standard lets mobile devices move without breaks in current connections. In IPv6, mobility is built in, which means that any IPv6 node can use it when necessary. However, mobility is not provided in IPv4; you must add it. IPv6's routing headers make mobile IPv6 much more efficient for end nodes than mobile IPv4.
IPSec is the IETF standard for IP network security. It enables integrity, authentication, and confidentiality. IPSec is available for both IPv4 and IPv6. Although the functionality is essentially identical in both environments, IPSec is mandatory in IPv6.
IPSec is enabled on every IPv6 node and is available for use, resulting in the IPv6 Internet being more secure. IPSec also requires keys for each party, which implies global key deployment and distribution.
RFC 2460, Internet Protocol, Version 6 (IPv6) Specification (available at http://www.cis.ohio-state.edu /cgi-bin/rfc/rfc2460.html), defines the IPv6 standard.
You can find information on IPv6 features supported in specific Cisco IOS releases by following the links on the Cisco IOS IPv6 page, at http://www.cisco.com/warp/public/732/Tech/ipv6/.
IPv6 increases the number of address bits by a factor of 4, from 32 to 128. During the IPv6 design specification, factoring to 64, 128, and 160 bits was considered. Ultimately, the design team selected 128 bits as the most appropriate factoring choice, resulting in a very large number of addressable nodes. (However, as in any addressing scheme, not all the addresses are used.)
Key Point: IPv6 Addresses Are 128 Bits
The 128 bits of an IPv6 address provide a much larger address space than IPv4.
IPv6 can provide approximately 3.4 * 1038 addresses (340,282,366,920,938,463,374,607,432,768,211,456), or approximately 5 * 1028 addresses for every person on the planet!
Increasing the number of bits for the address also increases the header size. Because each IP header contains a source and a destination address, the sizes of the header fields that contain the addresses are 64 bits for IPv4 and 256 bits for IPv6.
IPv6 allows hosts to have multiple IPv6 addresses and networks to have multiple IPv6 prefixes, thereby facilitating connection to multiple ISPs, for example.
IPv6 Address Format
IPv6 addresses are represented as a series of 16-bit hexadecimal fields separated by colons (:), in the format x:x:x:x:x:x:x:x. Techniques are available to shorten written IPv6 addresses:
The leading 0s within a field are optional.
IPv6 addresses often contain successive hexadecimal fields of 0s. To shorten IPv6 addresses, two colons (::) may be used to compress and represent successive hexadecimal fields of 0s. This can be done at the beginning, middle, or end of an IPv6 address, but it is allowed only once in an address. To determine the number of missing 0s in an IPv6 address, write the two parts of the address separately, and fill in between with 0s until you have 128 bits.
An address parser identifies the number of missing 0s by separating the two parts and entering 0 until the 128 bits are complete. If two :: notations are placed in the address, there is no way to identify the size of each block of 0s.
For example, the IPv6 address 2031:0000:130F:0000:0000:09C0:876A:130B can be written as 2031:0:130F::9C0:876A:130B. An incorrect way to write this address is 2031::130F::9C0:876A:130B; two colons are allowed only once in an address.
The address 0:0:0:0:0:0:0:0 can be written as :: because it contains all 0s.
The IPv6 addressing architecture is described in RFC 2373, IP Version 6 Addressing Architecture, available at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2373.html.
Like the IPv4 prefix, the IPv6 prefix represents the network part of the address. The IPv6 prefix is written in prefix/prefix-length format; the prefix-length is a decimal value indicating the number of higher-order bits in the address that are included in the prefix. For example, 1080:5E40::/32 indicates that the higher-order 32 bits represent the network part of the address.
IPv6 Address Types
Key Point: IPv6 Address Types
IPv6 addresses can be unicast (one-to-one), anycast (one-to-nearest), or multicast (one-to-many); IPv6 has no concept of a broadcast address.
Broadcasting in IPv4 results in a number of problems, including interrupting every computer on the network and, in some cases, completely hanging up an entire network (this is called a broadcast storm).
IPv6 unicast addresses are the same as IPv4 unicast: A single source sends data to a single destination. A packet sent to a unicast IPv6 address is delivered to the interface identified by that address.
An IPv6 multicast address is the same as in IPv4 multicast: an address for a set of interfaces (in a given scope) that typically belong to different nodes. A packet sent to a multicast address is delivered to all the interfaces identified by the multicast address (in a given scope). (IPv6 uses a 4-bit scope ID to specify address ranges reserved for multicast addresses for each scope.) Multicast addresses enable efficient network operation by using a number of functionally specific multicast groups to send requests to a limited number of computers on the network. The multicast groups prevent the majority of problems related to broadcast storms in IPv4. The range of multicast addresses in IPv6 is larger than in IPv4. For the foreseeable future, allocation of multicast groups is not being limited.
IPv6 defines a new type of address called an anycast address. It identifies a list of interfaces that typically belong to different nodes. A packet sent to an anycast address is delivered to the closest interface, as defined by the routing protocols in use, identified by the anycast address. In other words, devices that share the same characteristics are assigned the same anycast address. A sender interested in contacting a device (a receiver) with those characteristics sends a packet to the anycast address, and the routers deliver the packet to the receiver nearest to the sender. Anycast can be used for service location. For example, an anycast address could be assigned to a set of replicated FTP servers. A user in China who wants to retrieve a file would be directed to the Chinese server, and a user in Europe would be directed to the European server.
Anycast addresses are allocated from the unicast address space and must not be used as the source address of an IPv6 packet. To devices that are not configured for anycast, these addresses appear as unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the anycast address is assigned must be explicitly configured to know that it is an anycast address.
An example of anycast use in a Border Gateway Protocol (BGP) multihomed network is when a customer has multiple connections to multiple ISPs. The customer uses a different anycast address for each ISP; each router for that ISP has the same configured anycast address. The source device can choose which ISP to send the packet to. However, the routers along the path determine the closest router to reach that ISP using the anycast address.
Another use for an anycast address is when a LAN is attached to multiple routers, and the routers are all configured with the same anycast address. Distant devices need to specify only the anycast address, and then intermediate devices can choose the best path to reach the closest entry point to that LAN.
IPv6 Address Aggregation
A larger address space means that larger address allocations can be made to ISPs and organizations. As for IPv4, IPv6 summarization (or aggregation) reduces the routing table size and results in an efficient and scalable routing table. Scalable routing is necessary to connect to various devices and networks on the Internet in the future.
An ISP aggregates all its customers' prefixes into a single prefix and announces that single prefix to the IPv6 Internet, as shown in Figure 1-24.
Figure 1-24 IPv6 Address Summarization
A much larger address space allows IPv6 engineers to design a better way to enable autoconfiguration of the addresses and maintain their global uniqueness. The stateless autoconfiguration method is one way to do this. With stateless autoconfiguration, a router on the local link sends network-type information, such as the prefix of the local link and the default route, to all its nodes. An IPv6-enabled host uses the prefix advertised by the router as the top 64 bits of the address; the remaining 64 bits contain the 48-bit MAC address in an extended universal identifier 64-bit (EUI-64) format. This autoconfiguration produces a full 128-bit address that can be used on the local link and that guarantees global uniqueness.
IPv6 detects duplicate addresses in special circumstances to avoid address collision.
The EUI-64 Format
The EUI-64 format interface ID is derived from the 48-bit link-layer MAC address by inserting the hex number FFFE between the upper 3 bytes (the Organizational Unique Identifier [OUI] field) and the lower 3 bytes (the serial number) of the link-layer address. To make sure that the chosen address is from a unique MAC address, the seventh bit in the high-order byte is set to 1 (equivalent to the IEEE G/L bit) to indicate the uniqueness of the 48-bit address.
Autoconfiguration enables a plug-and-play feature, which connects devices (such as DHCP servers) to the network without configuration. Plug and play is a key feature to deploy new devices on the Internet, including cell phones, wireless devices, home appliances, and networks.
Stateless autoconfiguration is accomplished via a handshake between the host and the router. As illustrated in Figure 1-25, the host sends a router solicitation (RS) at boot time to ask the router to send an immediate router advertisement (RA) on the local link. The router sends an RA immediately after the host sends an RS. The host therefore receives the autoconfiguration information without waiting for the next scheduled RA.
Figure 1-25 Stateless Autoconfiguration Means That IPv6 Can Be Plug and Play
Routers also send RAs periodically, upon request, on all their configured interfaces. The router sends an RA to the all-nodes multicast address. Information contained in the RA message includes the following:
One or more prefixes to use on the link
A prefix's lifetime
Flags that indicate the kind of autoconfiguration that hosts perform
Default router information, including existence and lifetime
Other types of host information
RA timing and other parameters can be configured on the routers.
RAs may announce the pending retirement of an old node prefix with a short lifetime and the use of a new node prefix. Decreasing the lifetime of the old prefix tells the nodes to begin using the new prefix and, at the same time, to continue maintaining connections opened with the old prefix for a period. During that period, nodes have two unicast addresses that they can use. When the old node prefix is retired (its lifetime decreases to 0), the RA announces only the new node prefix.
If you are renumbering an entire site, you must also renumber the routers. A router renumbering protocol is currently under review by the IETF. Renumbering an entire site also requires changes to the DNS entries; the introduction of new DNS records for IPv6 facilitates this process.
IPv6 Packet Format
As illustrated in Figure 1-26, the new IPv6 header is less complicated than the IPv4 header in the following ways:
It contains half of the previous IPv4 header fields. Fewer fields means easier packet processing, enhanced performance, and routing efficiency.
It enables direct routing data storage and faster routing data retrieval with 64-bit aligned fields.
Figure 1-26 The IPv6 Header Is Simpler and More Efficient Than the IPv4 Header
IPv6 header enhancements enable hardware-based processing that provides forwarding rate scalability for the next generation of high-speed lines. In the long term, it is clear that IPv6 improves routing efficiency. In the short term, however, the impact of the larger, 128-bit addressing remains unclear.
IPv4 Header Format
As illustrated in Figure 1-27, the IPv4 header contains 12 basic header fields, followed by an Options field and a data portion (usually the transport layer segment). The basic IPv4 header has a fixed size of 20 octets. The variable-length Options field increases the size of the total IP header.
Figure 1-27 IPv4 Header Format
IPv6 contains fields similar to seven of the 12 IPv4 basic header fields. The IPv6 header does not require the other fields for the following reasons:
Routers handle fragmentation in IPv4, which causes a variety of processing issues. IPv6 routers no longer perform fragmentation. Instead, a discovery process is used to determine the most optimum maximum transmission unit (MTU) to use during a given session, as follows:
In the discovery process, the source IPv6 device attempts to send a packet at the size specified by the upper IP layersfor example, the transport and application layers. If the device receives an "ICMP packet too big" message, it tells the upper layer to discard the packet and to use the new MTU. The "ICMP packet too big" message contains the proper MTU size for the pathway. Each source device needs to track the MTU size for each session. Generally, the tracking is done by creating a cache based on the destination address; however, it also can be built using the flow label. If source-based routing is performed, the tracking of the MTU size can be built using the source address.
The discovery process is beneficial because as routing paths change, a new MTU can be more appropriate. When a device receives an "ICMP packet too big" message, it decreases its MTU size if the ICMP message contains a recommended MTU less than the device's current MTU. A device can perform MTU discovery every 5 minutes to see if the MTU has increased along the path.
Applications and transport layers for IPv6 accept MTU reduction notifications from the IPv6 layer. If they do not, IPv6 has a mechanism to fragment packets that are too large. However, upper layers are encouraged to avoid sending messages that require fragmentation.
Most currently implemented link-layer technologies already do checksum and error control. Because link-layer technologies are relatively reliable, an IP header checksum is considered redundant. Without the IP header checksum, the upper-layer optional checksums, such as UDP, are now mandatory.
IPv6 Header Format
The IPv6 header is illustrated in Figure 1-28.
Figure 1-28 IPv6 Header Format
Key Point: IPv6 Header
The IPv6 header has 40 octets in contrast to the 20 octets in IPv4. IPv6 has a smaller number of fields, and the header is 64-bit aligned to enable fast processing by current processors. The IPv6 address fields are four times larger than in IPv4.
The IPv6 header contains these fields:
VersionA 4-bit field, the same as in IPv4, that indicates the IP version. It contains the number 6 for IPv6 instead of the number 4 for IPv4.
Traffic ClassAn 8-bit field similar to the ToS field in IPv4. It tags the packet with a traffic class that it uses in differentiated services. These functions are the same for IPv6 and IPv4.
Flow LabelA new 20-bit field. It tags a flow for IP packets. It can be used for multilayer switching techniques and faster packet-switching performance.
Payload LengthA 16-bit field similar to the Total Length field in IPv4. This field indicates the total length of the packet's data portion.
Next HeaderAn 8-bit field similar to the Protocol field in IPv4. The value of this field determines the type of information following the basic IPv6 header. It can be a transport layer segment, such as TCP or UDP, or it can be an extension header.
Hop LimitThis 8-bit field specifies the maximum number of hops that the IP packet can traverse. It is similar to the Time To Live (TTL) field in IPv4. Each hop or router decreases this field by 1. Because the IPv6 header has no checksum, the router can decrease the field without recomputing the checksum. (On IPv4 routers, the recomputation costs processing time.)
Source AddressThis field has 16 octets or 128 bits and contains the packet's source address.
Destination AddressThis field has 16 octets or 128 bits and contains the packet's destination address.
The extension headers, if any, and the packet's data portion follow the eight fields. The number of extension headers is not fixed, so the total length of the extension header chain is variable.
Stream Control Transmission Protocol
IPv6 also uses Stream Control Transmission Protocol (SCTP) at the transport layer. SCTP is a reliable transport service like TCP and supports sequence and acknowledgment functions. SCTP was built to overcome TCP's limitationsfor example, the TCP requirement for a strict order of transmission that can cause head-of-line blocking.
The main difference between the two protocols lies in SCTP's purpose. SCTP is used for multihomed nodes and to combine several streams within a single data connection. TCP sends a stream of bytes, and SCTP sends a stream of messages. In TCP, the application has to know how to divide the stream of bytes into usable segments. SCTP is designed to provide a general-purpose transport protocol for message-oriented applications, such as signaling used in the public telephone network. If multiple streams are integrated into one connection and one of these streams has reliability problems, all the streams in TCP have difficulty. SCTP is aware of the messages in the connection, and functionality is provided with SCTP to selectively acknowledge SCTP packets.
In multihoming, clients and servers can have multiple network interface cards (NICs), and each can be reached through a variety of physical pathways. During SCTP setup, the client informs the server of all its IP addresses. The client needs to know only a single address for the server, because when the server responds to the client, it has in its acknowledgment a list of addresses to use to reach it. SCTP monitors all paths between the devices with a heartbeat function and identifies one path as the primary. Secondary paths can be used for retransmissions or in case the primary path fails.
SCTP has greater security than TCP, because SCTP uses a cookie function for each session and is immune to a TCP SYN attack. For example, if Device A wants to set up an SCTP session with Device B, the following steps occur:
Device A creates an initialization request and sends it to Device B. Device A then waits for a message from Device B.
Device B receives the request, generates an encrypted key and a message authentication code (indicating who created the message), and puts these into a cookie message. It sends the cookie to Device A.
Device A receives the cookie and sends it back to Device B in a cookie echo message. Device A again waits for a message from Device B.
Device B receives the cookie echo message and examines it to ensure that the message authentication code indicates that it was indeed Device B that created the cookie. It sends a cookie acknowledgment to Device A. Only then does Device B initiate the SCTP session; it is now in a state in which it can accept and send data.
Device A receives the cookie acknowledgment and enters a state in which it can accept and send data.
RFC 2960, Stream Control Transmission Protocol, available at http://www.cis.ohio-state.edu/cgi-bin /rfc/rfc2960.html, further describes SCTP.
IPv6 Extension Headers
There are many types of extension headers. Each extension header is 64-bit aligned. The extension headers form a chained list of headers; the Next Header field of the previous header identifies each header, as shown in Figure 1-29.
Figure 1-29 IPv6 Extension Headers Form a Chained List of Headers
When multiple extension headers are used in the same packet, their order is as follows:
Hop-by-Hop Options header
Destination Options header (when using the Routing header)
Encapsulating Security Payload header
Destination Options header
IPv6 to IPv4 Interoperability
The transition from IPv4 to IPv6 will be a slow process, but fortunately it does not require upgrades on all nodes at the same time. Meanwhile, IPv4 and IPv6 must coexist.
Many transition mechanisms enable smooth integration of IPv4 and IPv6. Other mechanisms that allow IPv4 nodes to communicate with IPv6 nodes are available.
Key Point: IPv6 Transition Techniques
The two most common techniques to transition from IPv4 to IPv6 are as follows:
Dual stackIPv4 and IPv6 stacks run on a system. The system can communicate with both IPv4 and IPv6 devices.
TunnelingThe most common type of tunneling used is IPv6 to IPv4 (6to4) tunneling to encapsulate IPv6 packets in IPv4 packets.
A third method uses an extension of IP NAT to translate an IPv4 address to an IPv6 address and an IPv6 address to an IPv4 address.
A dual stack enables both the IPv4 and IPv6 protocols. Cisco IOS software is IPv6-ready. As soon as IPv4 and IPv6 basic configurations are complete on an interface, the interface is dual stacked, and it forwards IPv4 and IPv6 traffic.
As shown in Figure 1-30, using IPv6 on a Cisco IOS software router requires the global configuration command ipv6 unicast-routing. This command enables the forwarding of IPv6 datagrams. All interfaces that forward IPv6 traffic must have an IPv6 address, assigned with the interface configuration command ipv6 address IPv6-address [/prefix length]. This command specifies the IPv6 address to be assigned to the interface and enables IPv6 processing on the interface.
Figure 1-30 Assigning IPv4 and IPv6 Addresses Creates a Dual-Stack Interface
Tunnels are often used to overlay an incompatible protocol on an existing network. Tunneling IPv6 traffic over an IPv4 network requires one edge router to encapsulate the IPv6 packet inside an IPv4 packet and another router to decapsulate the packet. This process lets you interconnect IPv6 islands without converting the entire network to IPv6, as illustrated in Figure 1-31.
When you tunnel, remember the following:
If the IPv4 header does not contain an optional field, the MTU effectively decreases by 20 octets.
A tunneled network is often difficult to troubleshoot. Tunneling is a transition technique that should be used only where it is appropriate; do not consider it a final architecture. Using native IPv6 throughout the network is still the final goal.
Tunnels can be either manually or automatically configured.
Manually Configured Tunnel
In a manually configured tunnel, you configure both the IPv4 and IPv6 addresses statically on the routers at each end of the tunnel, as illustrated in Figure 1-32. These end routers must be dual-stacked, and the configuration does not change dynamically as network and routing needs change. Routing must be set up properly to forward a packet between the two IPv6 networks.
Figure 1-32 A Manually Configured Tunnel Has Static Addresses
Tunnel endpoints can be unnumbered, but unnumbered endpoints make troubleshooting difficult. The IPv4 practice of saving addresses by using unnumbered tunnel endpoints is no longer an issue.
The 6to4 tunneling method automatically establishes and enables the connection of IPv6 islands through an IPv4 network, as illustrated in Figure 1-33. The 6to4 tunneling method assigns a valid IPv6 prefix to each IPv6 island, which enables the fast deployment of IPv6 in a corporate network without obtaining addresses from the ISPs or registries.
Figure 1-33 6to4 Tunneling Automatically Establishes Connections
The 6to4 tunneling method requires configuration of the edge routers, but the IPv6 hosts and routers inside the 6to4 site do not require new features to support 6to4.
Key Point: 6to4 Tunnel Addresses
The 6to4 tunnel treats the IPv4 network as a virtual link. Each 6to4 edge router has an IPv6 address with a /48 prefix, which is the concatenation of 2002::/16 and the edge router's IPv4 address (in hexadecimal); 2002::/16 is a specially assigned address range for the purpose of 6to4. The edge routers automatically build the tunnel using the IPv4 addresses imbedded in the IPv6 addresses.
For example, if the edge router's IPv4 address is 192.168.99.1, the prefix of its IPv6 network is 2002:c0a8:6301::/48, because c0a86301 is the hexadecimal representation of 192.168.99.1.
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 go through the tunnel. The router extracts the IPv4 address embedded as the third to sixth octets inclusive in the IPv6 next-hop address; this is the IPv4 address of the 6to4 router at the other end of the tunnel. The router encapsulates the IPv6 packet in an IPv4 packet with the extracted IPv4 address of the destination edge router. The packet then goes 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. (To be able to reach a native IPv6 Internet, a 6to4 relay router, which offers traffic forwarding to the IPv6 Internet, is needed.)
IPv6 Routing Protocols
This section introduces IPv6 routing protocols and compares them to their IPv4 counterparts.
The routing protocols available in IPv6 include interior gateway protocols (IGPs), for within an autonomous system, and exterior gateway protocols (EGPs), for between autonomous systems. The following routing protocols or draft proposals are available:
RIP new generation (RIPng)
OSPF version 3 (OSPFv3)
Integrated IS-IS version 6 (IS-ISv6)
Routing protocols for IPv4 are discussed in detail in other chapters.
RIPng is a distance-vector protocol with a limit of 15 hops that uses split horizon and poison reverse to prevent routing loops. IPv6 features include the following:
RIPng is based on the IPv4 RIPv2 and is similar to RIPv2.
RIPng uses an IPv6 prefix and next-hop IPv6 address.
A multicast group, FF02::9, is the all-RIP-routers multicast group and is used as the destination address for RIP updates.
RIPng uses IPv6 for transport.
RIPng is defined in RFC 2080, RIPng for IPv6, available at http://www.cis.ohio-state.edu/cgi-bin/rfc /rfc2080.html.
OSPFv3 is a new protocol implementation for IPv6. It has the following features:
OSPFv3 is similar to the IPv4 version of OSPF.
OSPFv3 carries IPv6 addresses.
OSPFv3 uses IPv6 link-local unicast addresses as source addresses. (A link-local unicast address can serve as a method of connecting devices on the same local network without the need for either site-local or globally unique addresses.)
OSPFv3 uses IPv6 for transport.
OSPFv3 is defined in RFC 2740, OSPF for IPv6, available at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2740.html.
The large address support in Integrated IS-ISv6 facilitates the IPv6 address family. IS-ISv6 is the same as IS-IS for IPv4, with the following extensions added for IPv6:
Two new types, lengths, values (TLVs):
IPv6 interface address
A new protocol identifier
Multiprotocol extensions for BGP4 let other protocols besides IPv4 be routed, including IPv6. Other IPv6-specific extensions also are included in BGP4+, including the definition of a new identifier for the IPv6 address family.
Multiprotocol extensions to BGP are defined in RFC 2858, Multiprotocol Extensions for BGP-4, available at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2858.html. BGP4+ for IPv6 is defined in RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, available at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2545.html.
Cisco routers support the RIPng, IS-ISv6, and BGP4+ routing protocols. OSPFv3 is also supported on some platforms. You can find information on IPv6 features supported in specific Cisco IOS releases and platforms by following the links on the Cisco IOS IPv6 page, at http://www.cisco.com/warp/public/732/Tech/ipv6/.
In the Cisco 12000 Internet Router Series, IPv6 routing is supported in the Cisco IOS 12.0(22)S configuration and later. In all other platforms, the IPv6 routing protocols are supported in IOS 12.2(2)T and later. Redistribution is not supported between IPv4 routing protocols and IPv6 routing protocols.
The largest use of IPv6 is across the Internet using BGP extensions for IPv6.