Home - Courtesy of ThinkGeek (Click to buy this shirt!)

I realized the other day that I’ve done a lot of IPv6-related posts in the past few months, but for one reason or another I keep putting off setting up my own IPv6 presence.  I signed up for a free IPv6 tunnel from Hurricane Electric’s Tunnel Broker service almost a year ago.  However, the Cisco Valet Plus router I have running my home network has zero support for IPv6, let alone tunnels.  Because of that little omission, my tunnel sat unused for a while, gathering 128-bit dust.  As the end of the year approached, I found myself with some extra time on my hands and a bit of spare gear thanks to my local Cisco office.  I decided that maybe it was time to turn up my IPv6 nerdiness to the next level.

I found an old 2821 in my lab that wasn’t serving an immediate purpose.  I erased it and reconfigured it to serve as a gateway for my IPv6 setup.  I logged back into my account at tunnelbroker.net and found that I could create up to 5 tunnels for free.  Who in their right mind would turn that down?  I created a new tunnel for my lab environment.  In this interface, you would create a regular tunnel for basic connectivity.  You input your IPv4 address as one side of the endpoint.  HE.net provides the IP that you’re coming in on if you wanted to set this up with a home connection, for instance.  In my case, I already had a global IPv4 address ready to go.  However, the router wasn’t all the way up yet.  If HE.net can’t ping your IPv4 tunnel endpoint, they won’t reserve the address space.  So:

Tip #1: Don’t start setting up your tunnel until you’ve got your gateway ready.

I picked the closest endpoint to my geographic area – Dallas, TX.  Once the router came all the way up and the ARP caches had settled down, I registered my new tunnel without a hitch.  HE.net provides you with a /64 for your tunnel interface.  ::1 is an interface on their side, ::2 is an interface to assign to your tunnel.  They also provide you with an entirely different /64 to setup for your client devices behind your router/firewall.  If you’re wanting to bring more than one site online, you can even register for a /48.  That’s 1.20892582 × 10^24 addresses.  Per tunnel.  That’s a lot for nothing!

My first attempt with Dallas didn’t work out so well.  For some reason, I couldn’t ping the other side of my tunnel.  I gave it about 15 minutes and then gave up.  I tore down the tunnel and created a new one.  If you’re going to do that, give the HE.net servers about 5 minutes to clean up their side of things, since the tunnel creation script will think that you’re  trying to register an endpoint twice.  I picked a nice little sunny patch of hex addresses in Fremont, CA and this time it worked!  I was able to ping from one side of my tunnel to the other.  For reference, this is the sample config they gave me for the tunnel and it worked quite nicely:

interface Tunnel0
 description Hurricane Electric IPv6 Tunnel Broker
 no ip address
 ipv6 enable
 ipv6 address <Your Tunnel /64 Endpoint>
 tunnel source <Your IPv4 Interface>
 tunnel destination <HE.net's IPv4 Interface>
 tunnel mode ipv6ip
ipv6 route ::/0 Tunnel0

Easy, right?  Once that’s up and running, you can configure the other interface of your router with the routed /64 or /48 they assign you.  I’d suggest starting with the /64 first to get your feet wet.  There is one other piece of configuration you need to enable that seems to be the cause of many issues on HE.net’s forums when configuring Cisco devices.  You need to enable IPv6 routing with this command:

ipv6 unicast-routing

Tip #2: Don’t forget to enable IPv6 routing.

Now that you’ve got two sides up and running and routing between each other, you should be able to launch some packets toward the Interwebz v6.  HE.net sets you up with an IPv6 DNS server you can plug into your devices to test connectivity.  If you want to be able to ping ipv6.google.com from your router, be sure to enter this command:

ip name-server 2001:470:20::2

Now you can test to your heart’s content.  When you’re sure that your tunnel is going to stay up, you need to concentrate on getting desktops working.  That’s where the routed /64 comes into play.

HE.net gives you an additional routed /64 that is different than the tunnel address for the purposes of setting up a site for IPv6.  Most networking people know that you must have two different subnets on the router for routing to occur.  Yet, on the HE.net forums I see a lot of people that are configuring their routers with addresses from the tunnel /64 subnet.  Save yourself the headache and use the other /64 to get started.

The easiest way to setup your client device with an IPv6 address is good old fashioned static addressing.  This is very easy to do in both Windows and OS X.  Lucky for you that both of the latest versions of those OSes have IPv6 enabled by default.  You just have to click on the option for IPv6 and assign a static IP.  You should also use the HE.net IPv6 name server listed above to allow you to resolve addresses like ipv6.google.com.  I tested with an OS X Lion server and was able to get the machine running on a static IP with no real issues.  I gave my Windows 7 workstation an IP in the same range and they were able to happily ping each other with no problems.  I think I’m going to take another post to talk about the fun of configuring DHCPv6 and SLAAC on my tunnel, as that has caused me a bit of heartburn so far making everything play nice with other people’s ideas about security.

Speaking of security…I would be remiss if I didn’t end this little article without a discussion of securing your new tunneling router from the nastiness on the Internet.  I found a great access list on the HE.net forums and thought I’d share it with you:

ipv6 access-list internet_inbound_ipv6
 remark Permit IPv6 Link-Local & Multicast
 permit ipv6 FE00::/7 any
 remark Block IPv6 Bogons
 deny ipv6 ::/3 any
 deny ipv6 4000::/2 any
 deny ipv6 8000::/1 any
 remark Block own assigned IPv6 space
 deny ipv6 <Your HE.net /64>::/64 any
 remark Block anything going to Windows RPC
 deny tcp any any eq 135
 permit icmp any any
!
ipv6 access-list internet_outbound_ipv6
 remark Prohibit any contact with Windows RPC-NetBIOS
 deny tcp any any eq 135
 deny tcp any any eq 137
 deny tcp any any eq 138
 deny tcp any any eq 139
 deny udp any any eq 135
 deny udp any any eq netbios-ns
 deny udp any any eq netbios-dgm
 deny udp any any eq netbios-ss
 remark Allow traffic from own assigned IP space
 permit ipv6 <Your HE.net /64>::/64 any

Of note here, remember that in IPv6, ICMP does a lot more than just pings.  Read RFC4890 for a lot more info on the subject, but right now I’m just allowing the whole stack in.  If you want to permit traffic to servers for things like HTTP or SMTP, be sure to add those servers at the end of the Inbound ACL so the traffic doesn’t get dropped.

Tom’s Take

One of the things that impressed me when I started troubleshooting some of the issues with my HE.net tunnel was the help that people were more than willing to give in the HE.net forums.  Especially where they helped their brethren with things like establishing connectivity.  Lots of posts about being able to ping router tunnel endpoints and things like that.  It shows that setting up your own IPv6 presence isn’t really that hard and should allow you to get out on the wider Internet with IPv6 in short order.  Thanks to all the work that other’s have been more than willing to share, I had an easier time than many.  I just hope my examples here help someone to get their tunnels up and running.