Routing Protocols

Tutorial: IPv6 Tunnels Part 2 – Automatic 6to4 Tunnels

Thanks for visiting! If you're new here, you may want to subscribe to my RSS feed. This blog posts regular tutorials, news, and study tips about networking, especially about Cisco CCIE related topics. Go ahead, subscribe to the rss feed! You can also receive updates from this blog via email. Thanks for visiting!

In our previous article on IPv6 tunnels, we looked at manual GRE and IPv6IP Tunnels in order to provide connectivity for IPv6 networks segregated by an IPv4 network. By tunneling IPv6 over IP, we can migrate our internal networks to IPv6 and still have communication between these networks, even though we are seperated by an IPv4 network. In this article we will be using another method to provide connectivity for IPv6 networks segregated by an IPv4 network: The Automatic 6to4 Tunnel! Mastering IPv6 is not only an important part of a CCIE candidates journey, but will become increasingly important as the global pool of IPv4 addresses diminishes.

We will be using the following topology for this tutorial:

Dynagen .net configuration:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-ik9o3s-mz.124-7.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[ROUTER R1]]
        f0/0 = LAN 1
        s1/0 = FRAME 1
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 2
        s1/0 = FRAME 2
        console = 2001
        model = 3640

    [[ROUTER R3]]
        f0/0 = LAN 3
        s1/0 = FRAME 3
        console = 2002
        model = 3640

    [[FRSW FRAME]]
        1:102 = 2:201
        1:103 = 3:301

You can download the dynagen/dynamips .net configuration file for this topology here.

Lets have a look at the basic configuration for this topology:

R1

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

R2

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

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:<32 bit IPv4 site address in Hex>. 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:<32 bit IPv4 site address in Hex>:<16 bit network number in Hex>::/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

© 2008 Arden Packeer. All rights reserved. The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. This material is not sponsored or endorsed by Cisco Systems, Inc. Cisco, Cisco Systems, CCIE and the CCIE Logo are trademarks of Cisco Systems, Inc. and its affiliates