Home > Articles > Cisco Certification > CCNP > CCNP Self-Study: Advanced IP Addressing

CCNP Self-Study: Advanced IP Addressing

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jun 11, 2004.

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 Addressing

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 24Figure 1-24 IPv6 Address Summarization

IPv6 Autoconfiguration

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 25Figure 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.

IPv6 Renumbering

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 26Figure 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 27Figure 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 layers—for 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 28Figure 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:

  • Version—A 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 Class—An 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 Label—A 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 Length—A 16-bit field similar to the Total Length field in IPv4. This field indicates the total length of the packet's data portion.

  • Next Header—An 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 Limit—This 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 Address—This field has 16 octets or 128 bits and contains the packet's source address.

  • Destination Address—This 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 limitations—for 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 29Figure 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:

  1. IPv6 header

  2. Hop-by-Hop Options header

  3. Destination Options header (when using the Routing header)

  4. Routing header

  5. Fragment header

  6. Authentication header

  7. Encapsulating Security Payload header

  8. Destination Options header

  9. Upper-layer 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 stack—IPv4 and IPv6 stacks run on a system. The system can communicate with both IPv4 and IPv6 devices.

  • Tunneling—The 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.

Dual-Stack Transition

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 xxxFigure 1-30 Assigning IPv4 and IPv6 Addresses Creates a Dual-Stack Interface

Overlay Tunnels

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.

Figure 31Figure 1-31 Tunneling Encapsulates an IPv6 Packet in an IPv4 Packet

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 32Figure 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.

6to4 Tunneling

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 33Figure 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, the prefix of its IPv6 network is 2002:c0a8:6301::/48, because c0a86301 is the hexadecimal representation of

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:

  • IGPs:

    • RIP new generation (RIPng)

    • OSPF version 3 (OSPFv3)

    • Integrated IS-IS version 6 (IS-ISv6)

  • EGP—BGP4+


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.

Integrated IS-ISv6

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 reachability

    • 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.

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020