Automatic v6 over v4 tunnels: ISATAP vs 6to4

Let's compare Cisco's ISATAP and automatic 6to4 tunneling methods.

Here's the diagram:

The square represents an IPv4-only service provider, and the circles are IPv6 islands.  The goal is to have any-to-any IPv6 connectivity between the circles, via the IPv4 only-network.

All relevant IP addresses are on the diagram.  IPv4 routing is being accomplished via EIGRP.  The IPv4 network has any-to-any connectivity in place already.

Let's try out ISATAP first.

The configuration is actually rather easy.  In fact, the initial part of it is the same on all three devices:

R2, R3 & R4:
interface Tunnel0
 ipv6 address 2001:234::/64 eui-64
 tunnel source Loopback0
 tunnel mode ipv6ip isatap

The IPv6 network address I chose was completely arbitrary.  The eui-64 is deliberate.  This should look a little funny to you, because eui-64 is an Ethernet option.  No Ethernet here...

R2#show ipv6 int Tunnel0 | s Global
  Global unicast address(es):
    2001:234::5EFE:202:202, subnet is 2001:234::/64 [EUI]

So eui-64 got us 2001:234::5EFE:202:202.  The 5EFE (which actually has some zeros in front of it as well) is indicating ISATAP.  The 202:202 should be more formally read as 0202:0202, or a conversion of my IPv4 source address (2.2.2.2) to IPv6 hexidecimal.  You can probably predict what the other addresses will look like at this point.  Obviously, 2.2.2.2 needs to be reachable from R3 and R4 for this to work, and vice-versa.  In our case, they already are.

So if we wanted R2 to reach R3, we would use:

R2#ping 2001:234::5EFE:303:303

...and we would be successful...

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:234::5EFE:303:303, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/80/88 ms

ISATAP works as an NBMA network - packets are "tunneled", packet-by-packet, towards their destination, which is selected by manipulating those last 32 bits. Contrary to what I originally thought, dynamic routing protocols can be run over ISATAP.  For example, OSPFv3 can be run by using NBMA mode and neighbor statements to the link-local addresses.  If using static routing, you must specify the IPv6 next-hop with every static route.  Otherwise the ISATAP tunnel has no idea which gateway your internal addresses are behind.

(In my case, the "internal" IPv6 network on the diagram is represented by Lo100 on each device.)

R2:
ipv6 route 2001:CC1E:3:3::/64 Tunnel0 2001:234::5EFE:303:303
ipv6 route 2001:CC1E:4:4::/64 Tunnel0 2001:234::5EFE:404:404

R3:
ipv6 route 2001:CC1E:2:2::/64 Tunnel0 2001:234::5EFE:202:202
ipv6 route 2001:CC1E:4:4::/64 Tunnel0 2001:234::5EFE:404:404

R4:
ipv6 route 2001:CC1E:2:2::/64 Tunnel0 2001:234::5EFE:202:202
ipv6 route 2001:CC1E:3:3::/64 Tunnel0 2001:234::5EFE:303:303

A quick ping from R4 to R2 will verify connectivity:

R4#ping 2001:CC1E:2:2::2 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:2:2::2, timeout is 2 seconds:
Packet sent with a source address of 2001:CC1E:4:4::4
!!!!!

That's ISATAP in a nutshell.  Now for 6to4.

I've erased all the ISATAP configuration, and changed the inside IPv6 addresses.  Here's the new diagram:

The configuration is actually quite similar to ISATAP:

R2:

interface Tunnel0

 ipv6 address 2002:202:202:1::2/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 Tunnel0

R3:
interface Tunnel0
 ipv6 address 2002:303:303:1::3/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 Tunnel0

R4:
interface Tunnel0
 ipv6 address 2002:404:404:1::4/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 Tunnel0

I'm sure you already see the identifying IPv4 factor here:  The IPv4 loopback address is once again embedded in the IPv6 address.  In R2's case, 2002:202:202:1::2/64.  The :1 directly thereafter is an arbitrary number I used for clarity which will be explained in a moment. 

I'm sure you also noticed the ipv6 static route on each router.  This is what makes 6to4 so cool.  Rather than having to add a static route to your inside networks, if you IPed them correctly (make note that I changed my inside IPs for this exercise), you can dynamically route to them.

The way 6to4 works, in a nutshell, is that the 2002::/16 prefix is reserved for 6to4.  That static route instructs anything that is associated with 6to4 to go over Tunnel0.  At that point, the 6to4 tunnel locates the endpoint in the next 32 bits (for example, 303:303 = 3.3.3.3), and tunnels the packet at it.  It doesn't give a lick what you put after 2002:XXXX:YYYY.  The receiving end cares about the rest.

When the packet is received by the neighboring 6to4 router, it looks past 2002:XXXX:YYYY and figures out which interface the packet belongs to, dynamically.  If your inside IP addresses are 2002:XXXX:YYYY:A::X, then you get a simplistic form of dynamic routing.

I promised an explanation on the :1 of 2002:202:202:1::2 above.  This number isn't really necessary, I just stuck it in to make things easier to read.  Obviously you can't have overlapping subnets on two interfaces on the same router.  So, I made the tunnel :1 and the inside subnet :2 on Lo100.  These could have been any numbers, in fact, the tunnel could've just been 2002:202:202::2/64.

On that note, let's test this thing out:

R3#ping 2002:202:202:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:202:202:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/70/92 ms

We have a winner!

Cheers,

Jeff Kronlage