Sebastian Nohn

Weblog

IPv6 enabling your network with the Hurricane Electric Tunnelbroker using a Linux router

After waiting years for my ISP to introduce native IPv6 to his clients, which still hasn't happened, I decided to enable IPv6 in my home LAN via Hurricane Electric's Tunnel Broker service. The setup was quite easy:

First, I registered for their service, which only took a few minutes and then registered a new "regular" tunnel. HE offers you a number of tunnel endpoints in several countries on three continents and you should pay attention to choose the one with the lowest latency to your v4 IP (they offer a check for this).

After you successfully registered your tunnel, the party begins. You are now able to set up the tunnel on your Debian/Ubuntu/Voyage Linux router (you get all the information you need from the tunnel details page at Tunnelbroker). To add the tunnel to your config, add

auto hev6tunnel
iface hev6tunnel inet6 v4tunnel
    # this is the amsterdam endpoint. change it to your endpoint
    endpoint 216.66.84.46             
    # beware, you get assigned two prefixes from HE, a tunnel prefix and a route prefix 
    address 2001:your:tunnel:prefix::2 
    netmask 64
    # this makes traceroute work
    ttl 255                            
    up ip -6 route add default dev hev6tunnel
    down ip -6 route del default dev hev6tunnel

to your /etc/network/interfaces. If you now ifup hev6tunnel your IPv6 tunnel, you should already be able to ping IPv6 destinations:

ping6 ipv6.google.com -n -c 3
PING ipv6.google.com(2a00:1450:4016:800::1010) 56 data bytes
64 bytes from 2a00:1450:4016:800::1010: icmp_seq=1 ttl=56 time=33.6 ms
64 bytes from 2a00:1450:4016:800::1010: icmp_seq=2 ttl=56 time=33.3 ms
64 bytes from 2a00:1450:4016:800::1010: icmp_seq=3 ttl=56 time=34.1 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 33.326/33.708/34.110/0.320 ms

If it doesn't work, you may have to register your tunnel endpoint at HE: curl "https://ipv4.tunnelbroker.net/nic/update?username=youruser&password=yourpassword&hostname=yourtunnelid". To persist this, you should add the call to your PPP interface configuration:

auto dsl-provider
iface dsl-provider inet ppp
  pre-up /sbin/ifconfig eth0 up
  provider dsl-provider
  post-up curl "https://ipv4.tunnelbroker.net/nic/update?username=youruser&password=yourpassword&hostname=yourtunnelid"

Before bringing up the route to your LAN, it's time to configure your firewall. IPv6 doesn't know NAT, instead all your clients get assigned a routed IP. So to let your experiment not end in a disaster, you should filter all traffic before enabling the routed network. The easiest way is to get Fabio Baltieri's IPv6 Firewall, change WAN to hev6tunnel and adjust LAN and WLAN to whatever matches your configuration.

After that you extend your tunnel config to look like this:

auto hev6tunnel
iface hev6tunnel inet6 v4tunnel
    endpoint 216.66.84.46              # this is the amsterdam endpoint. change it to your endpoint
    address 2001:your:tunnel:prefix::2 # beware, you get assigned two prefixes from HE, a tunnel prefix and a route prefix
    netmask 64
    up ip -6 route add default dev hev6tunnel
    up ip -6 addr add 2001:your:tunnel:prefix::1/64 dev eth1 # beware, you get assigned two prefixes from HE, a tunnel prefix and a route prefix
    down ip -6 route del default dev hev6tunnel
    down ip -6 addr del 2001:your:tunnel:prefix::1/64 dev eth1 # beware, you get assigned two prefixes from HE, a tunnel prefix and a route prefix
    post-up /etc/init.d/rc.firewall6 start
    post-down /etc/init.d/rc.firewall6 stop

You can check if it works by bringing the tunnel down and back up again: ifdown hev6tunnel; ifup hev6tunnel. The output of ip6tables -L -n should look similar to this:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all      ::/0                 ::/0                
ACCEPT     all      ::/0                 ::/0                
ACCEPT     tcp      ::/0                 ::/0                tcp dpt:22
ACCEPT     icmpv6    ::/0                 ::/0                
ACCEPT     all      ::/0                 ::/0                state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all      ::/0                 ::/0                
ACCEPT     tcp      ::/0                 ::/0                tcp dpt:22
ACCEPT     icmpv6    ::/0                 ::/0                
ACCEPT     all      ::/0                 ::/0                state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   

Now you are ready to enable the routed network without harming your unpatched computers, smartphones and tablets. To do this, enable your routed prefix on your internal network interface:

iface eth1 inet6 static
    address 2001:your:route:prefix::2
    netmask 64

ifdown eth1; ifup eth1 to enable it. To advertise the routes to your clients using NDP install radvd with apt-get install radvd and configure it in /etc/radvd.conf to advertise your route:

interface eth1
{
   AdvSendAdvert on;
   prefix 2001:your:route:prefix::2/64 
   {
        AdvOnLink on;
        AdvAutonomous on;
   };
};

A few seconds later, your clients should start bringing up IPv6 addresses on their interfaces. ifconfig | grep inet6 sould output something like this:

inet6 addr: ::1/128 Scope:Host
inet6 addr: 2001:your:route:prefix:your:local::address/64 Scope:Global
inet6 addr: a::b:c:d:e/64 Scope:Link
inet6 addr: 2001:your:route:prefix:your:temporary:local:address/64 Scope:Global

To get to know what this temporary addresses are, please read about the IPv6 Privacy Extension.

Now you should be able to ping IPv6 destinations from your local machine:

ping6 ipv6.google.com -n -c 3
PING ipv6.google.com(2a00:1450:4016:801::1010) 56 data bytes
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=1 ttl=55 time=31.9 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=2 ttl=55 time=31.3 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=3 ttl=55 time=32.5 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 31.361/31.955/32.539/0.502 ms

If this also works, you should see the dancing turtle, be able to SSH to your local machine from some remote location etc.

Normally your tunnelled IPv6 connection should not have much less bandwidth than your native IPv4 connection, which you can check for example on http://ipv6-test.com/speedtest/. If you do, you should try lowering the MTU in our tunnel's advanced configuration settings on the Tunnel Broker website.

Update

People were asking me, why I didn't extend my delegation to a /48 and stay with the default /64. Well, the /64 allows me to put 56759212534490928 devices per cubic metre in my flat which should be enough for now).

Posted Oct 20, 2012 by Sebastian Nohn
Tagged as: Internet, IPv6, Linux, Networking

<<< Page 1 of 1 >>>