IPv6 Routing

MP-BGP for IPv6

Multiprotocol BGP (RFC 2858) involves two new extensions to BGP4 that allow BGP to carry reachability information for other protocols, such as IPv6, multicast IPv4, and MPLS. The extensions allow NEXT_HOP to carry IPv6 addresses and NLRI (network layer reachability
information) to an IPv6 prefix.

Example 8-5 shows the BGP commands as they might be applied.


OSPFv3

OSPFv3 is one of the first routing protocols available for IPv6 and. Due to its open-standard heritage, it is widely supported in IPv6. OSPFv3 is the only routing protocol discussed on the BSCI test, so it is covered in more depth here.

OSPFv3, which supports IPv6, is documented in RFC 2740. Like OSPFv2, it is a link-state routing protocol that uses the Dijkstra algorithm to select paths. Routers are organized into areas, with all areas touching area 0.

OSPF speakers meet and greet their neighbors using Hellos, exchange LSAs (link-state advertisements) and DBDs (database descriptors), and run SPF against the accumulated link-state database.

OSPFv3 participants use the same packet types as OSPFv2, form neighbors in the same way, flood and age LSAs identically, and support the same NBMA topologies and rare techniques such as NSSA and ondemand circuits.

OSPFv3 differs from its predecessors principally in its new address format. OSPFv3 advertises using multicast addresses FF02::5 and FF02::6, but uses its link-local address as the source address of its advertisements. Authentication is no longer built in, but relies on the underlying capabilities of IPv6.


OSPFv3 LSAs

OSPFv3 and OSPFv2 use a similar set of LSAs, but version 3 has a few changes from OSPFv2. Types 3 and 4 have been slightly renamed, but still fulfill the same functionality as they did with OSPFv2. Type 8 is new and assists in discovering neighbors. Types 1 and 2 no longer
pass routes. Instead they pass router IDs. Prefixes are associated as leaf objects that hang off those nodes and are advertised using Type 9, which is also new.

LSAs are sourced from the link-local address of an interface and destined for a multicast address. FF02::5 is the “all OSPF routers” address and FF02::6 is the “all OSPF DRs” address.

The OSPFv3 LSA types are collected together in Table 8-1. Notice that types one through seven exactly match their OSPFv2 predecessor, while type 8 and type 9 are new to OSPFv3.


Configuration
OSPF configuration is similar to RIPng and EIGRP. The routing process is created and routing properties are assigned to it. Interfaces are then associated with the process under interface configuration mode. Assuming that ipv6 unicast-routing and interface IP addresses are already in place, the commands to implement OSPFv3 are shown in Example 8-6.


Cost may be overridden with the ipv6 ospf cost command as shown in Example 8-7.

The summary-range command is shown to demonstrate summarization.


Troubleshooting
Troubleshoot OSPFv3 just like OSPFv2. Start by looking at show ipv6 route to verify routes have been advertised. Assuming the route is in the routing table, test reachability using ping ipv6. You can also look at the ospf setup using show ipv6 ospf 1 interface, show ipv6
ospf, or show ipv6 ospf database.


Integrating IPv4 and IPv6

There are several strategies for migrating from IPv4 to IPv6. Each of these strategies should be considered when organizations decide to make the move to IPv6 because each has positive points to aiding a smooth migration. It should also be said that there does not have to be a global decision on strategy—your organization may choose to run dual-stack in the U.S., go completely to IPv6 in Japan, and use tunneling in Europe. The transition mechanisms include:

• Dual stack—Running IPv6 and IPv4 concurrently.
  

• IPv6 to IPv4 tunneling (6-to-4)—Routers that straddle the IPv4 and IPv6 worlds to encapsulate the IPv6 traffic inside IPv4 packets.
  

• Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)—This protocol is similar to 6-to-4, but it treats the IPv4 network as an NBMA network.
  

• Teredo/Shipworm—Encapsulates IPv6 packets in IPv4/UDP segments.

NAT-PT, ALG, and BIA/BIS
Instead of replacing IPv4, there are several ways to coordinate the functioning of IPv4 and v6 concurrently. NAT-protocol translation is an example of this coexistence strategy. NAT-PT maps IPv6 addresses to IPv4 addresses. If IPv6 is used on the inside of your network, a NATPT device will receive IPv6 traffic on its inside interface and replace the IPv6 header with an IPv4 header before sending it to an outside interface. Reply traffic will be able to follow the mapping backward to enable two-way communication. NAT-PT is able to interpret application traffic and understand when IP information is included in the application data. It is also possible to connect IPv4 and IPv6 routing domains using application-level gateways (ALG), proxies, or Bump-in-the-API (BIA) and Bump-in-the-Stack (BIS), which are NAT-PT implementations within a host.