Chapter 10: Implementing IPv6

• RIPng is based on IPv4 RIP Version 2 (RIPv2).

• RIPng uses IPv6 for transport.

• RIPng uses link-local addresses as source addresses.

• RIPng uses an IPv6 prefix and a next-hop IPv6 address.

• RIPng uses the multicast address FF02::9, the all RIP routers multicast address, as the destination address for RIP updates.

• RIPng updates are sent on UDP port 521.

OSPFv3

OSPFv3 is a new protocol implementation for IPv6. It uses the same mechanisms as OSPF Version 2 (OSPFv2), but is a major rewrite of the internals of the protocol.

OSPFv3 distributes (transports) IPv6 prefixes and runs directly over IPv6.

If both OSPFv2 and OSPFv3 are configured on a router, they run completely separate from each other and run a separate shortest path first (SPF) instance. In other words, the two protocols are like "ships in the night," passing without knowing of the other's existence.

OSPFv3 includes the following IPv6-specific features:

• Every OSPFv2 IPv4-specific semantic is removed.

• Uses 128-bit IPv6 addresses.

• Uses link-local addresses as source addresses.

• Multiple addresses and OSPF instances per interface are permitted.

• Supports authentication (using IPsec).

• Runs over a link rather than a subnet.

OSPF for IPv6 is currently an IETF proposed standard.

The configuration of OSPFv3 is described in the "OSPFv3 Configuration" section later in this chapter.

IS-IS for IPv6

The large address support in IS-IS facilitates the IPv6 address family. IS-IS for IPv6 is the same as IS-IS for IPv4, with the following extensions added:

• Two new Types, Lengths, Values (TLVs):

  • IPv6 reachability

  • IPv6 interface address

• A new protocol identifier

IS-IS for IPv6 is not yet an IETF standard.

EIGRP for IPv6

EIGRP for IPv6 is available in Cisco IOS Release 12.4(6)T and later. EIGRP for IPv4 and EIGRP for IPv6 are configured and managed separately; however, the configuration and operation of EIGRP for IPv4 and IPv6 is similar. For more information on this protocol, refer to "Implementing EIGRP for IPv6," available at http://www.cisco.com.

MP-BGP4

To make Border Gateway Protocol Version 4 (BGP-4) available for other network layer protocols, including Multiprotocol Label Switching (MPLS) and IPv6, RFC 2858 defines multiprotocol extensions for BGP-4. RFC 2545 defines how these extensions are used for IPv6.

---

Note - RFC 2858 replaces the now obsolete RFC 2283, also named Multiprotocol Extensions for BGP-4.

---

IPv6-specific extensions incorporated into MP-BGP4 include the following:

• A new identifier for the IPv6 address family.

• Scoped addresses: The NEXT_HOP attribute contains a global IPv6 address and potentially a link-local address (only when there is link-local reachability with the peer).

• The NEXT_HOP and Network Layer Reachability Information (NLRI) attributes are expressed as IPv6 addresses and prefixes. (The NLRI field in a BGP update message lists the networks reachable on the BGP path described by the update message.)

OSPFv3 Compared to OSPFv2

Recall that OSPF is an IP link-state routing protocol. A link is an interface on a networking device, and a link-state protocol makes its routing decisions based on the states of the links that connect source and destination devices. The state of a link is a description of the interface and its relationship to its neighboring networking devices.

For OSPFv3, the interface information includes the IPv6 prefix of the interface, the network mask, the type of network it is connected to, the routers connected to the network, and so forth. This information is propagated in various types of link-state advertisements (LSAs). A router's collection of LSA data is stored in a link-state database (LSDB). The contents of the database, when subjected to Dijkstra's algorithm, result in the creation of the OSPF routing table.

Similarities Between OSPFv2 and OSPFv3

Although most of the algorithms of OSPFv2 are the same as those of OSPFv3, some changes have been made in OSPFv3, particularly to handle the increased address size in IPv6 and the fact that OSPFv3 runs directly over IPv6. The similarities between OSPFv3 and OSPFv2 include the following:

• OSPFv3 uses the same basic packet types as OSPFv2, as shown in Table 10-2: hello, database description (DBD) (also called database description packets [DDP]), link-state request (LSR), link-state update (LSU), and link-state acknowledgment (LSAck). Some of the fields within the packets have changed.

• The mechanisms for neighbor discovery and adjacency formation are identical.

• OSPFv3 operation over nonbroadcast multiaccess (NBMA) topologies is the same. The RFC-compliant nonbroadcast and point-to-multipoint modes are supported, and OSPFv3 also supports the Cisco modes such as point-to-point and broadcast.

• LSA flooding and aging are the same.

Table 10-2 OSPFv3 Packet Types

All of the optional capabilities of OSPF for IPv4, including on-demand circuit support, not-so-stubby areas (NSSAs), and the extensions to Multicast OSPF (MOSPF), are also supported in OSPF for IPv6.

Differences Between OSPFv2 and OSPFv3

Because OSPFv2 is heavily dependent on the IPv4 address for its operation, changes were necessary in the OSPFv3 protocol to support IPv6, as outlined in RFC 2740. Some of the notable changes include platform-independent implementation, protocol processing per-link rather than per-node, explicit support for multiple instances per link, and changes in authentication and packet format.

Like RIPng, OSPFv3 uses IPv6 for transport and uses link-local addresses as source address.

All OSPFv3 packets have a 16-byte header, in comparison to OSPFv2's 24-byte header. The two headers are illustrated in Figure 10-16.

Figure 10-16

OSPFv2 and OSPFv3 Packet Headers

OSPFv2 does not define or allow for multiple instances per link, although similar functionality can be implemented by using other mechanisms such as subinterfaces. In contrast, OSPFv3 has explicit support for multiple instances per link through the instance ID field in the packet header. This feature allows separate autonomous systems, each running OSPF, to use a common link. A single link could belong to multiple areas. Two instances need to have the same instance ID to communicate with each other. By default, the instance ID is 0, and it is increased for any additional instances.

Authentication is no longer part of OSPF; it is now the job of IPv6 to make sure the right level of authentication is in use.

OSPFv2 is primarily concerned with the subnet on which it is operating, whereas OSPFv3 is concerned with the links to which the router is connected. As discussed, IPv6 uses the term link to indicate a communication facility or medium over which nodes can communicate at the link layer; OSPF interfaces connect to links instead of to IP subnets. Multiple IPv6 subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix). OSPF for IPv6 therefore runs per-link instead of the IPv4 behavior of per-IP-subnet, and the terms network and subnet are generally replaced by the term link. This change affects the receiving of OSPF protocol packets, and the contents of hello packets and network LSAs.

OSPFv3 uses IPv6 link-local addresses to identify the OSPFv3 adjacency neighbors.

The multicast addresses used by OSPFv3 are as follows:

• FF02::5—This address represents all SPF routers on the link-local scope; it is equivalent to 224.0.0.5 in OSPFv2.

• FF02::6—This address represents all designated routers (DRs) on the link-local scope; it is equivalent to 224.0.0.6 in OSPFv2.

Address semantics that were in OSPFv2 have been removed in OSPFv3, as follows:

• IPv6 addresses are not present in the OSPF packet header (rather they are part of payload information).

• Router LSAs and network LSAs do not carry IPv6 addresses.

• The router ID, area ID, and link-state ID remain at 32 bits and are written in an IPv4-address format (dotted decimal).

• The DR and backup designated router (BDR) are now identified by their router ID, not by their IP address.

For security, OSPFv3 uses IPv6 AH and ESP extension headers instead of the variety of mechanisms defined in OSPFv2.

OSPF LSA Types for IPv6

Table 10-3 shows the OSPFv3 LSAs. The link-state (LS) type field indicates the function performed by the LSA: The high-order three bits of the LS type indicate generic properties of the LSA, while the remaining bits, called the LSA function code, indicate the LSA's specific functions.

Table 10-3 OSPFv3 LSAs

LSA characteristics include the following:

• An LSA contains a router ID, area ID, and link-state ID. Each of these IDs is 32 bits long; the IDs are not derived from an IPv4 or IPv6 address. (Note, however, that these IDs are written in an IPv4-address dotted decimal format.)

• Router LSAs and network LSAs contain only 32-bit IDs; they do not contain addresses.

• LSAs have flooding scopes that define a diameter to which they should be flooded, as follows:

  • Link-local (flood to all routers on the link)

  • Area (flood to all routers within an OSPF area)

  • Autonomous System (flood to all routers within the entire OSPF autonomous system)

• OSPFv3 supports the forwarding of unknown LSAs based on the flooding scope. This can be useful in an NSSA.

• OSPFv3 takes advantage of IPv6 multicasting, using FF02::5 for all OSPF routers and FF02::6 for the OSPF DR and BDR.

The two renamed LSAs in OSPFv3 are as follows:

• Interarea prefix LSAs for area border routers (ABRs) (type 3)—Type 3 LSAs advertise internal networks to routers in other areas (interarea routes). Type 3 LSAs may represent a single network or a set of networks summarized into one advertisement. Only ABRs generate type 3 LSAs. In OSPF for IPv6, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. The default route is expressed as a prefix with length 0.

• Interarea router LSAs for Autonomous System Boundary Routers (ASBRs) (type 4)—Type 4 LSAs advertise the location of an ASBR. Routers that are trying to reach an external network use these advertisements to determine the best path to the next hop. ASBRs generate type 4 LSAs.

The two new LSAs in OSPFv3 are as follows:

• Link LSAs (type 8)—Type 8 LSAs have link-local flooding scope and are never flooded beyond the link with which they are associated. Link LSAs provide the link-local address of the router to all other routers attached to the link, inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and allow the router to assert a collection of options bits to associate with the network LSA that will be originated for the link.

• Intra-area prefix LSAs (type 9)—A router can originate multiple intra-area prefix LSAs for each router or transit network, each with a unique link-state ID. The link-state ID for each intra-area prefix LSA describes its association to either the router LSA or the network LSA. The link-state ID also contains prefixes for stub and transit networks.

---

Note - The show ipv6 ospf [process-id] database link and show ipv6 ospf [process-id] database prefix commands display the new type 8 and type 9 LSAs.

---

An address prefix is represented by three fields: prefix length, prefix options, and address prefix. As discussed, in OSPFv3, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. Type 3 and type 9 LSAs carry all IPv6 prefix information, which, in IPv4, is included in router LSAs and network LSAs.

---

Note - For more information on address prefixes, refer to RFC 2740, section 3.4.3.7, Intra-Area-Prefix-LSAs.

---

IPv6 Configuration

Before configuring OSPFv3, IPv6 must be enabled with the ipv6 unicast-routing global configuration command.

Use the ipv6 cef global configuration command to enable Cisco Express Forwarding (CEF) for IPv6 (CEFv6). CEFv6 is advanced, Layer 3 IP switching technology for the forwarding of IPv6 packets. When CEFv6 is enabled, network entries that are added, removed, or modified in the IPv6 Routing Information Base (RIB), as dictated by the routing protocol in use, are reflected in the Forwarding Information Bases (FIBs), and the IPv6 adjacency tables maintain Layer 2 next-hop addresses for all entries that are in each FIB.

Use the ipv6 address address/prefix-length [eui-64] interface configuration command to configure an IPv6 address for an interface and enable IPv6 processing on the interface. The eui-64 parameter forces the router to complete the addresses' low-order 64-bits using an EUI-64 format interface ID.

OSPFv3 Configuration

When configuring and verifying OSPFv3 within the Cisco IOS, many interface and EXEC mode commands are similar to those for OSPFv2, with only the ipv6 keyword added.

One difference between OSPFv2 and OSPFv3 configuration is the way that IPv6 networks that are part of the OSPFv3 network are identified. The network area command used in OSPFv2 is not used in OSPFv3. Rather, in OSPFv3, interfaces are directly configured to specify which IPv6 networks are part of the OSPFv3 network.

There is also a separate native IPv6 router mode under which OSPFv3 parameters are defined. To enable an OSPFv3 process on a router, use the ipv6 router ospf process-id global configuration command. The process-id parameter identifies a unique OSPFv3 process.

---

Note - The ipv6 router ospf process-id global configuration command also places you in router configuration mode, which for OSPFv3 is identified by the Router(config-rtr)# prompt, not the Router(config-router)# prompt that is used by OSPFv2 and other IPv4 routing protocols.

---