IPv6 Part 3 - Routing

Routing for IPv6 is pretty similar to routing for IPv4. If your comfortable with routing, you should pick up IPv6 routing quickly. Since IPv6 has underlying differences in how it operates you just need to adjust your thinking a little to grasp IPv6 routing.

As for routing protocols, not much has changed and the basics for all of them still operate the same. But there are some differences and we will go over those today. Im not going into detail about each protocol and  I am assuming you already have a solid understanding of how the IPv4 version of each operates.


RFC 2080 - RIPng for IPv6
RFC 5348 - OSPF for IPv6
RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

The first thing you need to keep in mind with IPv6 routing is how next-hops are handled by the IPv6 router. Like IPv4, IPv6 still points routes to the next router who can handle the traffic, and will recurs the address until it knows the interface used to get to that destination. None of this has changed.

What has changed though is IPv6 routing always points to the link-local address of the next hop. This is true for all interior gateway protocols, static routing excluded. This is also true with BGP but it is a little different (as usual) and we will get there in a bit

Since IPv6 enabled interfaces will have multiple addresses you must insure layer2 to layer3 resolution for the link-local neighbors is squared away before your traffic can flow. You can be setup for your global addresses all day long but if your router does not know how to reach the next-hop link-local address you are hosed.

Also, If your running Frame-Relay and need frame-maps for your neighbors, you will need a frame-map for your link-local address and your global addresses in order for traffic to route.

Another gotcha with IPv6 routing that can drive you insane, if skipped over, is IPv6 routing is disabled by default. You would imagine Cisco will change the default behavior down the line but for now you must enable routing.

Static Routing

Static routing is pretty straight forward. Just create a static route and point it towards the next-hop IPv6 address.

You also have the option to point static routes to an interface just like IPv4 but there is a caveat. With IPv4, when pointing a static route to a broadcast interface (Ethernet) ARP will be used to determine the next-hop. Since IPv6 does not use ARP it is unable to learn a next-hop for anything outside the local subnet. The static route will show up in the RIB but traffic will not resolve a next hop.

To solve this issue either don't use interfaces in your static routes (unless they are point-to-point) or add a next-hop address to the static route.

Dynamic Routing Protocols

The following routing protocols support IPv6.
  •  RIPng (RIP next generation)
  •  OSPFv3
  •  EIGRPv6 (as of 12.4(T) )
  •  IS-IS
  •  BGP

Lets dig in and see what is going on with each.

  • RFC 2080
  • UDP port 521 multicast to FF02::9
  • No classfull routing
  • Configured at the interface level

Keep in mind since RIPng is enabled at the interface level you must configure it on all interfaces you want advertised to neighbors.

Lets see if we are learning routes.

Notice how both learned routes are pointing to the link-local address (FE80::) of the neighbor?

Also new to IPv6 is "L" and "LC" routes. The router will generate a local (L) /128 route for each interface. Local Connected (LC) means this is a loopback interface.

One last place to check to make sure RIPng is up and listening to neighbors is the show ipv6 interface command. For RIPng to function properly the interface must be joined to the RIPng multicast group (FF02::9) 

Show Commands
show ipv6 route local
show ipv6 route rip
show ipv6 int f0/0  (joined multicast FF02::9)


  • Transport via protocol 88 to FF02::A
  • Not supported until IOS 12.4(T) 
  • Configured at the interface level
  • Must manually enable EIGRP process
  • Must specify a 32-bit RID (Router-ID)

Routes will show up in the RIB just as they did with RIPng, but with EIGRP metrics and AD (90).

Now we can check to make sure the proper interfaces are enabled for EIGRPv6 and neighbors are being learned.

Show Commands
show ipv6 route eigrp
show ipv6 protocols
show ipv6 eigrp neighbor
show ipv6 int f0/0  (joined multicast FF02::A)


OSPF had to make a number of changes to accommodation IPv6. The changes are nothing major just a few new topics to keep in mind.

  • RFC 5340 
  • Transport via protocol 89 to unicast or multicasts FF02::5 and FF02::6 
  • Uses IPv4 address for RID 
  • Configured at the interface level
  • Supports advertising multiple networks on an interface
  • Supports multiple OSPFv3 instances per interface
  • New LSA types 
    • Type 8 - Link LSA - Advertises link-local address and prefixes
    • Type 9 - Intra-Area Prefic LSA - Two functions:
      • Associates IPv6 prefixes with a transit network via Network LSA
      • Associates IPv6 prefixes with a router via Router LSA
Configuration is almost identical to RIPng and EIGRP. Notice how OSPF network types are still configured at the interface? Nothing has changed with regard to network types.

OSPFv3 can now utilizes IPv6's built-in IPsec feature for both authentication and encryption. You just need to configure it.

The same commands are used to verify OSPFv3, just replace "ip" with "ipv6"

Notice the Type-8 LSAs for the Link-local addresses?

Show Commands
 show ipv6 ospf neighbors
 show ipv6 route ospf
 show ipv6 ospf database
 show ipv6 ospf interface

BGP for IPv6

  • RFC 2545
  • Transport and advertisement (NLRI) are independent
  • Transport can be IPv4 or IPv6
    • NLRI advertised via AFI 2 SAFI 1
  •  Uses AFI (Address Family Identifier) ipv6 unicast
  • Normal BGP rules still apply

BGP for IPv6 uses what is called MP-BGP (MultiProtocol-BGP). Even though the name sounds different and the configuration is changed up, BGP is still the same underlying protocol. The multiprotocol part of the name does exactly what it says, it allows multiple protocols or AFIs (IPv4, IPv6, CLNS and VPNv4) to pass over the same adjacency. Each AFI maintains its own BGP database, allowing you to manage policies independently for each AFI.

With that said, it is completely possible to establish adjacencies over IPv4 and distribute and learn IPv6 prefixes over these same adjacencies. The problem you run into is when the next-hop information is updated per eBGP. You then face the issue of trying to communicate with a IPv6 prefix via a IPv4 next-hop.

There are design solutions for this scenario but they are out of the scope of this post. Just keep in mind the pitfalls you can face with this design scenario.

For now we will keep it simple and setup peering over IPv6. So lets get to the configurations.

First we will configure BGP and a neighbor

Yay the neighbor is up, but not for IPv6. Since this neighbor is only configured in the default IPv4 unicast address family then it only supports IPv4. We can verify this with the following:

Under Neighbor capabilities, notice it only list IPv4 unicast?

We need to add this neighbor to the IPv6 address family to add IPv6 support.

Keep in mind when working with production systems the adjacency will be restarted when you add a neighbor to an address-family. Forgetting this aspect could mess up your week pretty quick.

What does the neighbor show now?

Now that the neighbor is in the correct address family, we need to advertise some prefixes

The prefixes should now be populated in the ipv6 AFI database. Lets see.

They are!

Show Commands
show bgp ipv6 unicast
show bgp ipv6 unicast summary
show ipv6 route bgp