Loopback Interface Best Practices for IPv6 / Routing Issues

[caplinktech]

I have been doing some reading on IPv6 and have read a few different best practices guides and all of them seem to have conflicting information on the best way to assign loopback addresses.

In the end I essentially decided to use /128 on loopback interfaces using globally unique IPv6 space out of a /64 reserved for loopback numbering across our entire network.

The issue I am having now is attempting to get the loopback addresses to route between routers.  I was hoping that I would be able to use the link local IPv6 addresses of the port channel between the routers to route the loopback address information, however, this does not seem to be working in Cisco IOS.  Is this not supported?  Am I doing something wrong?

Relevant Config:

R1:

interface Loopback0

ip address 192.168.32.1 255.255.255.255

ipv6 address yyyy:yyyy:100::10:0:1/128

interface Vlan10

  ip address x.x.x.x x.x.x.x

  ipv6 enable

ipv6 route yyyy:yyyy:100::10:0:2/128 Vlan10 FE80::21D:71FF:FE53:6C00

sh ipv6 int brief outputs: FE80::219:7FF:FEFE:FC00 for Vlan10 interface IP

R2:

interface Loopback0

ip address 192.168.32.2 255.255.255.255

ipv6 address yyyy:yyyy:100::10:0:2/128

interface Vlan10

  ip address x.x.x.x x.x.x.x

  ipv6 enable

ipv6 route yyyy:yyyy:100::10:0:1/128 Vlan10 FE80::219:7FF:FEFE:FC00                   

sh ipv6 int brief outputs: FE80::21D:71FF:FE53:6C00 for Vlan10 interface IP

I can ping the link local ips from each respective router to the other but I cannot ping the loopback interface IPs from the either router to the other.  I can ping the loopback IPs locally on each respective router.

Is this setup not supported?  Is it a bug in our IOS version?  Is this a horrible practice?

Last note:

The routes do appear in the routing tables for each respective router:

sho ipv6 route output:

R1:

LC  yyyy:yyyy:100::10:0:1/128 [0/0]

     via ::, Loopback0

S   yyyy:yyyy:100::10:0:2/128 [1/0]

     via FE80::21D:71FF:FE53:6C00, Vlan10

R2:

S   yyyy:yyyy:100::10:0:1/128 [1/0]

     via FE80::219:7FF:FEFE:FC00, Vlan10

LC  yyyy:yyyy:100::10:0:2/128 [0/0]

     via ::, Loopback0

Any help would be appreciated.

[Harold Ritter]

Hi,

Have you enabled "ipv6 unicast-routing"? A lot of people omit this step as routing is enabled by default for ipv4.

Regards

[caplinktech]

Yes I have.

[Harold Ritter]

Hi,

What platform is this? Can you try using the global unicast address (GUA) instead of the link local address (LLA) as the next-hop to see if it works.

Regards

[caplinktech]

It is on a Cisco 6500 platform w/ sup720.

Vlan 10 does not (did not) have GUA addresses configured.  As a test, I added GUA IPv6 addresses to Vlan 10.  Upon doing this, the routing over the link local addresses worked and I could ping the loopback addresses.

Is this expected behavior from IPv6?  Do GUA NEED to be assigned in order for link local addresses to route?  Is there an RFC for this behavior?  Is it a bug on the platform?  I did not expect this behavior as the link local addresses could be pinged across the routers without a GUA assigned.  It does not make sense that they could not route if the other device was reachable unless there is something in the RFC/spacifications for IPv6 I am overlooking.

As an additional general question, is there anything wrong with my numbering decisions based on best practices?

[Harold Ritter]

Hi,

A GUA is not required on the interface and the static routing using the LLA as the next hop address should have worked. I am not sure why the ping to the peer loopback address did not work but this is certainly a supported configuration.

Regards 

[caplinktech]

This must be a bug then.

I just confirmed that removing the GUA makes it so that the interfaces do not route once again.

Putting the GUA back, and I can route with the link local address.  We are on an older IOS version that is set to be upgraded in an upcoming maintenance window so hopefully the issue is corrected then.