Wednesday, January 27, 2010

IPv6 Transition Mechanisms

Hey Guys

An IPv6 Update just for a change. Today I am going to talk about your IPv6 transition mechanism's as I feel we are getting to that stage now.


First a brief rundown of the different methods:

  • Dual Stack
  • IPv6-Over-IPv4
  • 6to4
  • Terodo
  • ISATAP
Since I work for an integrator I will be looking at this more from an enterprise migration standpoint rather than an ISP standpoint. (You ISP guys have it fairly easy, enable all your routers for IPv6, start advertising your IPv6 Prefixes via BGP, bang done :P (I Joke ofcourse))

Okay, so: First method is dual-stack. fairly self explanatory. Every device in your network routes both IPv6 and IPv4, your hosts have both IPv6 and IPv4 addresses, and by setting up AAAA records in your DNS servers eventually all your hosts will be talking IPv6 natively to each other and IPv6 out to the internet when the other end is IPv6 and IPv4 when they can't.

Sounds great huh?

Meanwhile, back in the real world:


"Bugger, our firewall that we MUST use only supports IPv4"
or
"Bugger, our remote offices connect to the main site through an MPLS cloud and the MPLS cloud hasn't been enabled for IPv6"

I am sure you can think of many other scenarios: The point is, having end to end IPv6 from one end of your network to the other and into your ISP, you'd have to be quite fortunate. So here are some solutions:



First, the vanilla plain old "IPv6 over IPv4" Tunnel. Very simple:

interface tunnel0
ipv6 address <>
tunnel source <>
tunnel dest <>
tunnel mode ipv6ip
!

This config obeys all the normal rules of a GRE tunnel (and in actual fact, you can actually also just use a GRE tunnel, not even requiring the words "tunnel mode ipv6ip" like we have shown here.)

So, just like you might use a tunnel to enable multicast traffic to flow over a non-cooperative ISP's cloud for your WAN sites, here you can use a tunnel to encapsulate your IPv6 traffic. Fairly effective and simple.

What if the situation was, you had no remote sites, but at your head office you had a Cisco IPv6 capable router, and a non-ipv6 upgradable Juniper firewall sitting behind that infront of your users?

Internet <---> Router <---> Firewall <---> Users

ISATAP is your friend at this point.

ISATAP is just a tunneling mechanism too. But it is an automatic tunneling mechanism, basically the IPv6 Node with ISATAP enabled will have a dual-stack host assign itself an address where the last 32 bits are the hexadecimal representation of its own IPv4 address, it will then communicate with other ISATAP nodes by encapsulating its IPv6 traffic in IPv4 when trying to talk to other hosts with IPv6, so now all traffic from that host using IPv6 is actually sent across the wire using IPv4 and can therefore be routed as normal. The only issue with this implementation is that multicast is not supported and ISATAP treats the network like it is one big NBMA network. So you may see that ISATAP is really only useful for the purpose of giving a machine an ADDRESS in the IPv6 space; all its actual traffic will still come out as IPv4.

Now, in saying that however, the next enhancement for ISATAP is when you add your Cisco Router: if your Cisco router has a global IPv6 Address and its own assigned prefix (it will have one) the ISATAP clients can see this and will pick there address from this range. Meaning now they can route out to the global IPv6 Internet. Pretty cool hey

The ISATAP clients discover the closest IPv6 capable router using DNS (since, as we mentioned, no multicast method can be used to discover this as ISATAP is NBMA.)

The final option is 6to4 tunnels, basically they encapsulate IPv6 inside IPv4 but tunnels are setup automatically. A future blog post will address this and teredodo (which is a solution for home users or people who do not have IPv6 capable routers (can I interest you in a nice 2911?)

Until next time.

Pete




2 comments: