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:
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.
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.
I never understood that T-shirt even when it was IPv4; “There’s no place like loopback”?
Of course, if it were “There’s no place like ~/” it would be closer, but then fails as an IP joke.
I use SIXXS for my tunnel, mainly because they provided better support for router-terminated tunnels at the point at which I set it up; he.net were doing a brisk trade in host-based tunnels at that point, but clearly have more established options now.
Using he.net DNS servers is important too – they’re part of Google’s IPv6 trial (assuming they didn’t go public yet) so they can resolve google ipv6 site addresses even though they dont resolve ipv6 from regular (non-participant) DNS. In other words, your YouTube streams will tend to be IPv6. Look, there’s something on the IPv6 Internet!
John I would say it’s ‘my own’ rather than home 🙂 “There’s no place like my own” makes more sense.
Do you have any problems with MTU and DF bit? Windows XP and lower tend to set those to 1 in outbound connections.
Win XP isn’t very good at IPv6 _period_- too many hacks to make it play nicely. I’m mainly Windows 7 and Mac now, and they all work very nicely. On most machines I have MTU lowered already courtesy of the Cisco VPN client, so I’m less likely to hit that problem.
Great post; for most people an IPv6 tunnel is the only way to get started with IPv6.
One thing to remember, most of us have a single IPv4 address and use NAT to connect all of our computers. NAT blocks unsolicited connections by default. With IPv6, there is no NAT and unsolicited connections are allowed unless specifically blocked.
I use a Vyatta router with a HE.net ipv6 tunnel and have the following ipv6 firewall rules:
firewall ipv6-name OUTSIDEIN6 rule 10 action accept state established enable
firewall ipv6-name OUTSIDEIN6 rule 20 action accept protocol icmpv6
This allows only established connections and ICMPv6 packets.
Do you apply that to your tunnel interface (traffic leaving the interface) or to your “internal facing” ethernet interface (traffic leaving the interface)?
I’m thinking about blogging about he icmpv6 rules I set up sometime, but I’m glad to see others testing with hurricane tunnels. I have the following post on how to used a Hurricane Tunnel with a Cisco even when you only have a dynamic ip address.
Great post. I now have a Vyatta router sitting on my desk with a IPv6 Tunnel to HE. I’ve been wanting to get my hands on IPv6 and start getting a better grasp on things. Now I can. Thanks Tom.