IPv6: Why you should use it and setting up a tunnel

A story, about our trusty friend IPv4, why we should become friends with IPv6 and how to get IPv6 connectivity using a Hurricane Electric IPv6 tunnel on a OpenWRT router.

I have been using IPv6 for quite a while, learning about it, deploying it and enjoying it most of the time as I go along. Unfortunately my ISP does not offer IPv6 yet, perhaps yours doesn’t either, but that does not have to be a show stopper.

Trouble

You might have heard about it: we are running out of IPv4 address space, and if you ask me: we already have. The usability of IPv4 has already been stretched out by the use of NAT (Network Address Translation) in routers. Most PCs do not have a routable internet address nowadays, they use a private address and the actual routable IPv4 address is tied to a router. Which means two PCs (or other devices with internet connectivity) cannot talk to each other directly over the Internet, but instead they talk to a router on the local network and have it translate traffic from and to the internet. The routers keeps track what connection originated from which device behind it in a big table, and translating the IP addressed used on the internet to internal addresses and vice versa to deliver said traffic (fffew what a sentence). This works fine most of the time when you are simply making connection from the internal network to the outside, because there is an entry in the table that keeps track of connections that we can relate incoming traffic from the outside world to. But what if some device on the outside wants to talk to us? Their traffic reaches our router and gets rejected or dropped because the router cannot relate the incoming connection to an outgoing one made by us.

If I had to come up with a real world example for this: You decide to throw a big party somewhere nice, and have to provide a guest list to the place so security only lets in people you invited. Guests appear, security confirms they’re on the list and they are allowed in. But then some old friends show up, they heard about your party and want to celebrate with you, but you forgot to put them on the list. Meanwhile you partying hard and are unreachable, for both the door guy and your friends, so you don’t know about all of this. So they are denied entry by security because they aren’t on the guest list. Wouldn’t it have been nice to party with some old friends?

And that’s just a small bit of the whole problem. Nowadays we use NAT pretty much everywhere, if we hadn’t the Internet would have stopped growing some time ago (or moved to IPv6 sooner?). With it we have invented lots of tricks to work around the problems this creates, and most of those tricks do work: you can access the internet just fine, watch some cute cat pictures and chat about them with friends, right? So we have been able to extend our love affair with IPv4 a fair bit longer by deploying NAT in lots of cases, and with it put multiple devices behind a single routable IP address.

Just how much longer can we keep this up? The Internet is always growing, but the amount of IPv4 addresses is fixed. Once they run out, we are going to have to NAT the NAT, which is something you can actually do (NAT-ception!) but from a networking point of view should avoid. With one layer of NAT, you can still provide services to the Internet from the home, like I do with this website for example. It does require some knowledge, as you have forward a port on your external IP to an internal IP so the packets from the web can be forwarded to your machine by the router. This is a sphere that is still in your (the user) control. When the IPv4 addresses in possession of the ISPs run out, they might have to resort to something called Carrier Grade NAT (CG-NAT). This adds another layer of NAT at their end, which is outside of your control. Want to some incoming outside traffic to reach your web server? Tough luck, it’s not even going to reach the router in your home because the NAT layer at the ISP won’t know where to forward the traffic to. Another thing to remember is that you are going to share an IP address with other clients of the ISP. Could be just 2 other clients, could also be 50 other clients all sharing the same IP address. Suppose one of those other clients visits the same websites you do, or plays the same games you play. Now suppose that client does not play nice with other people, or is engaged in some illegal activity (spamming, hacking, DoS attacks, phishing, abusing services, selling stolen goods, etc) and gets caught by administrators of the website or game in question. They decide to ban him, which is often done by banning an IP address. Now you are banned as well, together with all the other clients sharing the IP at the ISP.

IPv6

A technology to advance the internet into the next era, whatever that may be. The “Internet of Things” is a concept that’s popping up when people talk about IPv6 and it’s huge address space (2^128 addresses, look up how many zeroes that has) being able to provide a unique IPv6 address to every device. So, no need for NAT any more! Want to talk to your coffee pot directly over the Internet? Now you can without any problems. This is where some start to feel uneasy and mentioning security vulnerabilities, because when everything has a globally routable IP address we could reach any device from anywhere and how that could be potentially dangerous. I come across this fear of being connectible a lot actually. People see NAT as some kind of security blanket, which isn’t! Yes, NAT is a layer between you and the internet, but not a security layer, it just translates addresses. What protects you is some other magic: the firewall. People seem to forget that it’s actually the firewall protecting them, and this applies to IPv6 as well. You can prevent incoming traffic from just reaching the devices on your LAN by using a firewall on your router. And it’s actually less confusing to configure than IPv4+NAT because the addresses are the same on the outside and inside, you don’t have to look up the private IPv4 address of a machine behind the router. And when you configure DNS or want to serve your own website from inside the LAN, you no longer have to remember to use internal IPs or hostnames, compared to what it looks like on the WAN side. So no more trickery required to use the same URLs from the inside and outside.

From a user perspective there isn’t any noticeable difference between IPv4 and IPv6. Browsing websites, fetching mail and chatting with friends works the same. So it’s not something revolutionary on that level, but it kind of is for (networking) engineers. Because it’s incompatible with IPv4 it is in essence a different “new” network. This raises another question: “Why should I support IPv6? Everybody is on IPv4 anyway.” First I would say to that: “Because you can.” and “Why not?” as I see only gains for doing so. You do not lose IPv4 connectivity, you are adding IPv6 connectivity and can offer the same services over the new net. Remember: You add support for IPv6. You do not replace IPv4 with IPv6 (yet?). So there are only things to gain here. And there are already clients that surf the Internet over (native) IPv6 and/or are behind a form of Carrier-Grade NAT for their IPv4 connectivity.

I have been running ‘dual-stack’ (IPv4 & IPv6 enabled) for quite a while now, and can recommend everybody to try and do so as well. It helps me to gain experience with IPv6, so I can be better prepared when the rest of the world adds support for it as well. At first I just ran it as an experiment, to try it. Over time I started to enable more services over IPv6, and now IPv6 connectivity is something more than an experiment as I use it everyday now and I see more websites and services becoming available over IPv6. A nice extension for Firefox can show you whether you are connecting over IPv4 or IPv6, it’s called: SixOrNot

IPv6 Tunnelling

When you want IPv6 connectivity but your ISP does not offer it, like mine, don’t worry. You can get IPv6 connectivity over a existing IPv4 connection by use of a tunnel, which sends encapsulated IPv6 packets over the IPv4 network to a gateway (tunnel endpoint) with native IPv6, which in turn forwards those packets over the IPv6 network. This might sound a bit complicated to set up, but it’s actually not that hard.

If you are interested in getting such a tunnel and aren’t afraid of doing some network configuration: Check out Hurricane Electric’s tunnelbroker, which is my favourite. Of course there are alternatives as well, such as the also popular SixXS. Every tunnel broker does basically the same thing, but they can use different tools to reach that goal.

At Hurricane Electric (and most other tunnel brokers) you register and apply for a tunnel. They offer examples on how to set it up for lots of operating systems, so you can get an idea of what tasks you will have to perform to get it running. If, like me, you use OpenWRT it’s really easy to add an HE.net IPv6 tunnel to your router. The UCI framework makes configuring their 6in4 tunnel easy and there is even support for the dynamic IP updater service, so your tunnel gets pointed at the right IPv4 address in case it changes. Even better is the fact that there is support in the LuCI WebUI for this, so it’s possible to perform all required tasks using the web interface. But for the sake of providing a more universal example, I will use the UCI config files in my examples. If you use the LuCI WebUI, you can still follow this guide because the concepts are very similar.

Hurricane Electric also offers a IPv6 certification program. As you learn about IPv6, you can answer questionnaires to gain levels and as you set up services using IPv6 you can gain even more levels and at the same time test you set things up correctly. I recently acquired the highest level of the certification, called “IPv6 Sage”, and received a cool t-shirt to show it off!

Requirements

When you use one of my recent builds (at time of writing) you don’t have to do any extra checking, although you of course may, because everything you will need is in there. My builds include the (new) OpenWRT native IPv6 stack destined for OpenWRT 12.09.1, required components for the supported connection types and the luci-proto-ipv6 package so LuCI can be used as well. So you can continue to the next section if you want or have a look at OpenWRT native IPv6 stack documentation.

Do you use trunk builds? Or compile your own OpenWRT from recent AA branch code? Have a look at IPv6 Essentials - OpenWRT Wiki and the OpenWRT native IPv6 stack documentation for the requirements and packages you will need for this.

In case you are using stock OpenWRT 12.09 or the older Backfire 10.03 (lacks 6rd support, but that’s not an issue for a HE.net tunnel) you can still follow this guide, although you will have to adapt for some differences in configuration yourself. You will want to have a look at IPv6 Essentials - OpenWRT Wiki as well, and check out IPv6 HowTo for Backfire and Attitude Adjustment until 12.09 for instructions. Or consider upgrading of course ;-)

IPv6 connectivity to the router

Met the requirements? Good. Registered at Hurricane Electric Free IPv6 Tunnel Broker as well? Yes? Read on.

Set up a Regular Tunnel

  1. Log in using the account you just made at tunnelbroker.net.
  2. Click “Create Regular Tunnel” on the left in the “User Functions” box.
  3. Fill out your current IPv4 address in the “Tunnel Endpoint” box. The IPv4 address you are using to currently view the page is conveniently displayed below, so you probably just have to copy and paste it.
  4. Select a Tunnel Server, use the one closest to you or follow the recommendation. It will try to ping your current address, so you will have to allow ICMP Echo requests. The website will inform you about this. Configuring your router to allow for ICMP Echo requests is outside of the scope of this HOWTO. OpenWRT by default should allow ICP Echo requests as far as I know.
  5. Your tunnel will be created and you will be taken to a page that displays the tunnel information. You’ll want to keep this page open because it contains the information you will need to configure the tunnel at your end.
  6. Optional: Have a look at “Example Configurations”, and “OpenWRT Backfire 10.03.1” in the list.

Configure OpenWRT

Now you to add the IPv6 tunnel connection to your OpenWRT router. This is done by creating a new interface, usually called wan6, and setting it up with the parameters found on the page with the tunnel details and/or the example configuration.

Edit the /etc/config/network file to add a new interface (or use LuCI to do so) and add the following with your details filled in-place of the examples:

config globals globals
        option ula_prefix fd00:db80::/48                    # Unique Local Address prefix range (this is a private range)

config interface 'wan6'
        option proto '6in4'                                 # HE tunnel is a 6in4 type
        option peeraddr '216.66.84.46'                      # Tunnel detail: Server IPv4 Address
        option ip6addr '2001:470:1f14:120::2/64'            # Tunnel detail: Client IPv6 Address
        option ip6prefix '2001:470:1f15:121::/64'           # Tunnel detail: Routed /64 
        option tunnelid '123456'                            # Tunnel detail: Tunnel ID
        option username 'ab1cd2ef345g67h8.87654321'         # User ID, can be found on "Account Menu > Main Page" or look at example configuration for OpenWRT 10.03.1
        option password 'YourAw3s0mePassword1'              # Your tunnelbroker.net password

And in the same file, add a piece to the lan configuration so that interface also gets an IPv6 address.

config interface 'lan'
        ...
        option proto 'static'               # Probably already there
        option ip6assign '64'               # Delegate a prefix of this length to this interface

You can find some extra details about these settings at OpenWRT native IPv6 stack - 6in4 tunnel. There is also a setting for Unique Local Address which can be used as a private network, for internal use only, just like IPv4 private addresses (192.168.0.0\16, 172.16~31.0.0\12, 10.0.0.0\8 ranges).

You also might want to confirm your firewall configuration includes the wan6 interface in the wan zone, so the firewall rules are applied to it. Have a look at /etc/config/firewall to see if it contains the following:

config zone
    option name 'wan'
    list network 'wan'
    list network 'wan6'
    ...                             # other options applied to WAN below...

If you had to add this it might be a good idea to look at Migration from Attitude Adjustment 12.09 and earlier information. Your configuration might be a bit older, perhaps by being preserved throughout upgrades of OpenWRT, other settings might be out-dated and worth checking as well, especially firewall configuration (IPv6 requires ICMP traffic to work properly while IPv4 does not, so many of those should not be blocked). This list is far from exhaustive so you might have to run after some loose ends yourself. Another possibility is to simply reset the configuration from scratch when running recent AA or trunk code, which should provide the right set of defaults, but you will have to perform your customizations once more by doing so.

IPv6 connectivity?

Now you can restart the network and see if the IPv6 tunnel get configured automatically. If you used LuCI to configure the wan6 interface and you applied the changes, it will have restarted the network for you and you should probably see a working WAN6 interface with a configured IPv6 address in the list of interfaces.

To perform the same restart from the console:

# /etc/init.d/network restart

Reload firewall rules as well for good measure, especially if you made changes:

# /etc/init.d/firewall reload

And wait for the command to complete. Now have a look at the interfaces and see if a 6in4-wan6 exists and has been configured with your settings. A command you can use for this on the router is # ip addr show 6in4-wan6 , which will list the details for an interface called 6in4-wan6. If it returns a result and it should show the IPv6 address you configured.

Now let’s see if you can reach IPv6 connected hosts over the internet:

root@iris:~# ping6 -c 4 ipv6.google.com
PING ipv6.google.com (2a00:1450:4005:809::1012): 56 data bytes
64 bytes from 2a00:1450:4005:809::1012: seq=0 ttl=55 time=19.504 ms
64 bytes from 2a00:1450:4005:809::1012: seq=1 ttl=55 time=19.483 ms
64 bytes from 2a00:1450:4005:809::1012: seq=2 ttl=55 time=20.480 ms
64 bytes from 2a00:1450:4005:809::1012: seq=3 ttl=55 time=19.125 ms

--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 19.125/19.648/20.480 ms

If that succeeded for you as well: congratulations, your router can now communicate with the internet over IPv6. If this did not work for you, you have some problem solving to do. In case you get a bad address error, it seems to be a DNS issue. Try to ping the IPv6 address directly. If that works, you now know what to diagnose: your DNS. Perhaps your (DNS) provider does not provide AAAA (IPv6) records? Try another DNS server and you might want to have a look at OpenWRT Wiki - IPv6 DNS. It’s no problem if a DNS server is contacted over IPv4 only. A DNS server can provide AAAA (IPv6) records and A (IPv4) records over a IPv4 connection without problem. My primary DNS-server is IPv4 only and resolves IPv6 address records (AAAA) fine. If the ping does not work using a IPv6 address directly, check your configuration, perhaps you made a mistake. Confirm you do not block ICMP Echo requests IP protocol 41 (called proto 41 in OpenWRT firewall config) in your firewall.

IPv6 connectivity for the LAN

So the router can reach the internet using IPv6, now it’s time for the clients: They need IPv6 addresses as well. On OpenWRT this is currently done by using 6relayd. On my builds this package is already installed, on others you might have to install it.

Configuration is done in /etc/config/6relayd and a good starting config can found at OpenWRT native IPv6 stack - Router Advertisement & DHCPv6 and I copied it (without guest network) here for reference:

config server default
        option network  'lan'
        option rd       'server'
        option dhcpv6   'server
        option management_level 1
        option master   'wan6'
        option fallback_relay   'rd dhcpv6 ndp'

Save the file and (re)rtart 6relayd to have it delegate IPv6 addresses to the LAN network using SLAAC and DHCPv6.

# /etc/init.d/6relayd start                 # or use "restart" in case 6relayd is already running

Test IPv6 connectivity from the LAN

You can now try to use IPv6 from the LAN. Of course make sure your network configuration accepts IPv6 Router Advertisements and auto-configuration. On some operating systems IPv6 is disabled by default, so you might have to enable it manually. It might also be necessary to restart the network interface on your computer before it accepts an IPv6 address. But I have also seen enough cases where the defaults are sane and as soon as a IPv6 Router Advertisement hits the network the OS configures IPv6 automatically.

There are lots of ways to test your IPv6 connectivity, a popular, reliable and easy way is to point a browser to http://ipv6.google.com. Does the Google Search page open? If it does: congratulations, you can now browse the web over IPv6. To test your connection with a bit more details you can go to http://test-ipv6.com, which will perform several tests on your connection.

blogroll

social