Running Dynamic routing protocols over IPv6 Dynamic tunnels

 IPv6  Add comments
Aug 082013
 

The dynamic tunnels are point to multipoint, virtually treating the underlying IPv4 network as NBMA. This is because the destination IPv4 address is dynamically discovered from the destination IPv6 address. Thus if a protocol uses the destination of multicast address, they will get mapped to an IPv4 address which cannot be routed, there by dropped.

Because of this reason we have to trick the protocol to use unicast IPv6 destination addresses. The implementation of this depends on the routing protocol itself. In this blog I will be demonstrating using OSPFv3 over different tunnel types.

topology

In the above topology R2 which will be the hub is configured for following tunneling methods:

  • Automatic 6to4 tunneling towards R1.
  • ISATAP tunneling towards R3, where it acts as a client.
  • ISATAP tunneling towards R4 where both R2 and R4 are servers.

Caveats: The most important point to take into account is the IPv6 address itself. The transport IPv6 destination address will be automatically discovered with help of the IPv6 destination address. So we must make take care that the IPv6 destination could be properly mapped to the IPv4 destination.

Tunnel configuration between R2 and R1:
R2:
interface ethernet0/0
ip address 10.0.12.2 255.255.255.0
!
interface Tunnel12
 description Automatic 6to4 Tunnel to R1
 ipv6 address 2002:A00:C02::2/64
 tunnel source Ethernet0/0
 tunnel mode ipv6ip 6to4
R1:
interface ethernet0/0
ip address 10.0.12.1 255.255.255.0
!
interface Tunnel12
 description Automatic 6to4 Tunnel to R2
 ipv6 address 2002:A00:C01::1/64
 tunnel source Ethernet0/0
 tunnel mode ipv6ip 6to4

Tunnel configuration between R2 and R3:

R2:
interface Ethernet0/1
ip address 10.0.23.2 255.255.255.0
!
interface Tunnel23
 description ISATAP Tunnel to R3
 ipv6 address 2001:23::/64 eui-64
 no ipv6 nd suppress-ra
 tunnel source Ethernet0/1
 tunnel mode ipv6ip isatap
 
R3:
interface Ethernet0/0
ip address 10.0.23.3 255.255.255.0
!
interface Tunnel23
 description ISATAP Tunnel to R2
 ipv6 address autoconfig
 tunnel source Ethernet0/0
 tunnel destination 10.0.23.2
 tunnel mode ipv6ip

Tunnel configuration between R2 and R4:

R2:
interface Ethernet0/2
ip address 10.0.24.2 255.255.255.0
!
interface Tunnel24
 description Tunnel to R4
 ipv6 address 2001:24::/64 eui-64
 tunnel source Ethernet0/2
 tunnel mode ipv6ip isatap
 
R4:
interface Ethernet0/0
ip address 10.0.24.4 255.255.255.0
!
interface Tunnel24
 description ISATAP Tunnel to R2
 ipv6 address 2001:24::/64 eui-64
 tunnel source Ethernet0/0
 tunnel mode ipv6ip isatap
 
Now as the basic tunnel configuration is setup we could implement OSPF v3. As OSPF v3 or any other IGP uses the Link Local address for peering/exchanging routes let us test connectivity towards it. For this we can send basic pings from R2. The debug ip packet is turned on to see what happens. Using this debug causes a lot of output, so better use it with an ACL matching protocol 41.
R2#ping FE80::A00:C01 repeat 1
Output Interface: Tunnel 12
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to FE80::A00:C01, timeout is 2 seconds:
Packet sent with a source address of FE80::A00:C02
 
IP: s=10.0.12.2 (local), d=0.0.0.0, len 120, unroutable, proto=41.
Success rate is 0 percent (0/1)

The ping to R1 fails because the destination IPv4 address which maps to 0.0.0.0 (derived from 17-48th bit of IPv6 destination address) is not routable/illegal.

R2#ping FE80::A00:1703 repeat 1
Output Interface: Tunnel23
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to FE80::A00:1703, timeout is 2 seconds:
Packet sent with a source address of FE80::5EFE:A00:1702
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms

 

R2#ping FE80::5EFE:A00:1804 repeat 1
Output Interface: Tunnel24
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to FE80::5EFE:A00:1804, timeout is 2 seconds:
Packet sent with a source address of FE80::5EFE:A00:1802
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms
 

Pings to R3 and R4 succeeds because the destination IPv4 address is mapped from the last 32 bits of the IPv6 destination address. To resolve the connectivity issue to R1 link local address we change the Link Local address on R2 and R1 to an address which is reachable at IPv4.

 
R1(config)#interface Tunnel 12
R1(config-if)#ipv6 address FE80:A00:C01::1 link-local
 
R2(config)#interface Tunnel 12
R2(config-if)#ipv6 address FE80:A00:C02::2 link-local
 
R2#ping FE80:A00:C01::1
Output Interface: Tunnel12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80:A00:C01::1, timeout is 2 seconds:
Packet sent with a source address of FE80:A00:C02::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/28 ms
 
This same route recursion problem occurs when we run OSPF v3 because it sends multicast packets to FF02::5. For this we have to manipulate OSPF process to send unicast packets. A workaround for this in the case of OSPF would be to use the network type of non-broadcast and then specify the neighbors.
 
R2 OSPF configuration:
interface Tunnel12
 ipv6 ospf network non-broadcast
 ipv6 ospf neighbor FE80:A00:C01::1
 ipv6 ospf 1 area 0
 
interface Tunnel23
 ipv6 ospf network non-broadcast
 ipv6 ospf neighbor FE80::5EFE:A00:1703
 ipv6 ospf 1 area 0
 
interface Tunnel24
 ipv6 ospf network non-broadcast
 ipv6 ospf neighbor FE80::5EFE:A00:1804
 ipv6 ospf 1 area 0
 
The network type is changed to “non-broadcast” as that would be one of the ways to specify a neighbor, so that unicast packets could be used. The other way to use unicast packets would be by specifying the network type of “point-to-multipoint non-broadcast”.
 
Configurations on other routers:
R1:
interface Tunnel12
 ipv6 ospf network non-broadcast
 ipv6 ospf 1 area 0
 
R3:
interface Tunnel23
 ipv6 ospf network non-broadcast
 ipv6 ospf 1 area 0
 
R4:
interface Tunnel24
 ipv6 ospf network non-broadcast
 ipv6 ospf 1 area 0
 
As OSPF and other IGPs use link local address for peering, the address must be reachable. The tunnel towards R1 is in ipv6ip 6to4 mode, the link local address will be FE80::/64. Thereby we have the reachability problem as the IPv4 tunnel destination will be not reachable. So the link local address is modified accordingly. We do not have this problem with ISATAP tunnels as the IPv4 destination is mapped from the last 32 bytes of IPv6 address.