Tutorial: IPv6 Tunnels Part 2 – Automatic 6to4 Tunnels

R3

hostname R3
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.30.30.30 255.255.255.0
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:3:3:3::3/64
!
interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.30.30.30
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

This is the same basic configuration we used in our previous article on IPv6 tunnels. We have a hub-and-spoke frame-relay topology with R1 acting as the hub. Looking at the route table, we should have full connectivity between all the hubs and spokes and their corresponding loopbacks over IPv4.

R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O       10.10.10.10/32 [110/65] via 10.1.123.1, 00:15:53, Serial1/0
C       10.30.30.0/24 is directly connected, Loopback0
O       10.20.20.20/32 [110/129] via 10.1.123.1, 00:15:53, Serial1/0
C       10.1.123.0/24 is directly connected, Serial1/0
O       10.1.123.1/32 [110/64] via 10.1.123.1, 00:15:53, Serial1/0
O       10.1.123.2/32 [110/128] via 10.1.123.1, 00:15:53, Serial1/0

R1#ping 10.30.30.30 source lo0 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.30.30.30, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.10
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/100/160 ms

Looks good we have complete IPv4 connectivity. Excellent! But what about IPv6?

R3#ping 2001:1:1:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1:1:1::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R3#sh ipv6 route
IPv6 Routing Table - 4 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   2001:3:3:3::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:3:3:3::3/128 [0/0]
     via ::, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

The routers don't have any connectivity between IPv6 because the IPv6 stack of the router doesn't have any routes to the other IPv6 networks.

We had the exact same problem in our previous article on IPv6 Tunnels. We solved this using manual GRE and IPv6IP tunnels but wouldn't it be cool if we could do something like this:

ipv6 route 2001:1:1:1::/64 10.10.10.10

The command above will not work but it demonstrates the basic premise of the need for 6to4 tunnels. We want to get to the 2001:1:1:1::/64 network via an IPv4 address. The ipv6 route command above won't work because we must have an IPv6 destination. 6to4 tunnels get around this by representing the IPv4 address as an IPv6 address.

Representing an IPv4 Address as a IPv6 Address in 6to4 Tunnels

6to4 tunnel addresses have the format 2002:. Following the embedded IPv4 site address are 16 bits that can be used to number networks within the site, so we end up with:

2002::::/64

The easiest way to demonstrate this is to look at an example:

R1

interface Loopback0
 ip address 10.10.10.10 255.255.255.0
 ipv6 address 2002:0A0A:0A0A:0000::1/64

Here we have converted the 10.10.10.10 address to a hexadecimal number of 0A0A:0A0A (IOS will truncate the leading zeros of all the hexadecimal fields, but I have included them here for clarity). We will call this our site address because we want everyone that wants to get to R1's IPv6 network (2001:1:1:1::/64), our IPv6 site, to go via the IPv4 address of 10.10.10.10. We have also allocated the Loopback0 interface to be in the 0000 (ie. the first) network of the site.

R2

interface Loopback0
 ip address 10.20.20.20 255.255.255.0
 ipv6 address 2002:0A14:1414:0000::2/64

R3

interface Loopback0
 ip address 10.30.30.30 255.255.255.0
 ipv6 address 2002:0A1E:1E1E:0000::3/64

Here we have converted the 10.20.20.20 address on R2 to a hexadecimal number of 0A14:1414 (10.20.20.20 in hexadecimal). This will be R2's site address. We want everyone that wants to get to R2's IPv6 network to go via the IPv4 address of 10.20.20.20. R3's loopback0 has been also been given an 6to4 address. Both R2 and R3's Loopback0 interfaces have been put int he 0000 network of their corresponding IPv6 site address.

Cool so now we have our Loopback address allocated with IPv6 6to4 addresses. These addresses are the IPv6 representation of the IPv4 addresses. We will use them in our static routes to say that to get to the IPv6 networks use these IPv4 addresses represented as IPv6 addresses.

Time to get to the tunnel!

6to4 tunnels

6to4 tunnels are not point-to-point tunnels like manual GRE or manual IPv6IP tunnels. 6to4 tunnels are multi-point tunnels. The tunnel interfaces just need a source address and the destination address is derived from the destination of a packet. When I first started analyzing 6to4 tunnels, I kept thinking "what do you mean the tunnels don't need a destination address?!!". This was usually followed by various expletives about why this stuff didn't work. It was only when it clicked that the 6to4 tunnels are multipoint tunnels that it made sense.

Let's take a look at an example:

The diagram above shows what will be implementing in this tutorial. We will be creating a tunnel interface (tu0) on R1, R2, and R3. These tunnel interfaces will be given a 6to4 IPv6 address that matches there corresponding Loopback IPv4 address. Remember that the routers already have IPv4 connectivity between there loopback address because OSPF is advertising the loopback address into the OSPF area. We want to be able to get to the IPv6 networks via these addresses.

Let's have a look at R1's configuration for this:

R1

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A0A:A0A:FFFF::1/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.0
 ipv6 address 2002:A0A:A0A::1/64
!
ipv6 route 2002::/16 Tunnel0

You can see above that the Tunnel0 interface of R1 has an IPv6 6to4 address. Both Loopback0 and Tunnel0 have been assigned addresses in 2002:0A0A:0A0A::/48. Loopback0 is in the 2002:0A0A:0A0A:0000::/64 network. Tunnel0 is in the 2002:0A0A:0A0A:FFFF::/64. We have added a route that says, anything with an IPv6 6to4 address (2002::/16) send it out tu0.

R2

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A14:1414:FFFF::2/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 ip address 10.20.20.20 255.255.255.0
 ipv6 address 2002:A14:1414::2/64
!
ipv6 route 2002::/16 Tunnel0

R3

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A1E:1E1E:FFFF::3/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 ip address 10.30.30.30 255.255.255.0
 ipv6 address 2002:A1E:1E1E::3/64
!
ipv6 route 2002::/16 Tunnel0

Why don't we need a destination address for the tunnel? Let's have a look at the basic packet flow. Lets say on R3 we issue a ping 2002:A0A:A0A::1 (trying to get to R1's Lo0 IPv6 address). R3 looks up its route table and sees the output interface for the destination packet is tu0. This is because we have a static route that says anything that starts with 2002::/16 send it out tu0. This interface has 6to4 tunnel encapsulation turned on. R3 takes the IPv6 destination Address of the ping packet (2002:A0A:A0A::1) and converts it into an IPv4 address. This results in an IPv4 destination address of 10.10.10.10. The IPv6 ping packet is then encapsulated in an IPv4 header. and sent along to 10.10.10.10.

We end up with a packet that looks like this:

Let's verify this:

R3#debug ip packet detail
IP packet debugging is on (detailed)
R3#ping 2002:A0A:A0A::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:A0A:A0A::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/146/224 ms
R3#
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41

Take a look at the source and destination addresses of that debug. Even though we pinged an IPv6 address, you can see that the IPv6 icmp packet is encapsulated into an IPv4 packet. We now have connectivity between our Loopback0 IPv6 addresses!

We still cannot ping the internal IPv6 addresses:

R3#ping 2001:1:1:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1:1:1::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R3#sh ipv6 route
IPv6 Routing Table - 9 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   2001:3:3:3::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:3:3:3::3/128 [0/0]
     via ::, FastEthernet0/0
S   2002::/16 [1/0]
     via ::, Tunnel0
C   2002:A1E:1E1E::/64 [0/0]
     via ::, Loopback0
L   2002:A1E:1E1E::3/128 [0/0]
     via ::, Loopback0
C   2002:A1E:1E1E:FFFF::/64 [0/0]
     via ::, Tunnel0
L   2002:A1E:1E1E:FFFF::3/128 [0/0]
     via ::, Tunnel0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

Why? Take a look at that route table. If I try to ping 2001:1:1:1::1 what will it match? Nothing. We need routes for those networks. Remember earlier in the tutorial when we said we needed something like:

ipv6 route 2001:1:1:1::/64 10.10.10.10

Well, after we create our tu0 interface on R1, we could rewrite this route on R2, and R3 as:

ipv6 route 2001:1:1:1::/64 2002:A0A:A0A::1

This effectively means, anything we get for the 2001:1:1:1::/64 network send it to 10.10.10.10. We know that we have connectivity to 2002:A0A:A0A::1. We proved that above. After we add the route above, when we try to ping 2001:1:1:1::1 from R3 the router looks at the route table and matches a destination address of 2002:A0A:A0A::1. We need to perform route recursion to an interface, so we then do a lookup of 2002:A0A:A0A::1 and we match the tu0 interface. This interface has 6to4 tunnel encapsulation turned on. R3 takes the IPv6 destination Address of the ping packet (2002:A0A:A0A::1) and converts it into an IPv4 address. This results in an IPv4 destination address of 10.10.10.10. The IPv6 ping packet is then encapsulated in an IPv4 header and sent along to 10.10.10.10.

Lets set up the routes for each of the IPv6 networks and test it:

R1

ipv6 route 2001:2:2:2::/64 2002:A14:1414::2
ipv6 route 2001:3:3:3::/64 2002:A1E:1E1E::3

R2

ipv6 route 2001:1:1:1::/64 2002:A0A:A0A::1
ipv6 route 2001:3:3:3::/64 2002:A1E:1E1E::3

R3

ipv6 route 2001:1:1:1::/64 2002:A0A:A0A::1
ipv6 route 2001:2:2:2::/64 2002:A14:1414::2

R3#ping 2001:2:2:2::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:2:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/180/260 ms

Woohoo! Awesome! We have successfully implemented 6to4 automatic tunnels! This can be quite a difficult concept to grasp, so I recommend implementing the above in dynamips and playing around with the concepts. Once you understand how to convert IPv4 address to 6to4 address and that 6to4 tunnels are multipoint tunnels the rest is pretty easy.

I really hope this helps. Please leave a comment below if you have any questions or comments. Now back to labs!

Summary:

• IPv6 6to4 Automatic tunnels allow you to join up IPv6 networks segregated by an IPv4 network.
• IPv6 6to4 Automatic tunnels are a multipoint tunnel
• IPv6 6to4 Automatic tunnels represent an IPv4 address endpoint as an IPv6 address to join segregated IPv6 networks

Resources:

• Dynamips/Dynagen .net configuration file

About the Author

Arden Packeer

Arden Packeer currently is a Cisco Certified Internetwork Expert (CCIE #20716) working in the Advanced Services team at Cisco Systems (Melbourne, Australia). He has more than 10 years with specialisations in datacentre networks, large scale service provider networks, and more recently virtualisation and cloud deployments. Arden also likes writing about himself in the third person because it makes him sound important. :)

CONTACT THE AUTHOR: