IPv6 - The Future of the Internet

Native IPv6 connection to TekSavvy using OpenWRT

by Craig Miller

Jumping on the IPv6 super highway

I have been connected to the IPv6 internet for years using a tunnel to Hurricane Electric, and I recommend this method if your ISP is unable to provide a native IPv6 connection. Hurricane Electric is very stable, with tunnel terminations points in many locations. However a downside of any kind of tunnel, is that it is limited by the IPv4 transport underneath. In my case it meant that my ping6 times where never going to be better than my IPv4 ping times.

Therefore, a Native IPv6 connection is always preferred to a tunneled one. In this article, I'd like to show how to connect to TekSavvy's Native IPv6 service over DSL using a router running OpenWRT.

The OSI Model in Review

Before we get into how to connect natively, let's review the OSI model (Open Systems Interconnection model). The OSI model is the key to understanding networking, and how the different layers interact.

Layer	Description	Examples
7	Application	HTTP, IMAP, NTP
6	Presentation	N/A
5	Session	N/A
4	Transport	TCP, UDP
3	Network	IPv4, IPv6
2	Data-link	Ethernet, 802.11 (wireless), PPP
1	Physical	Wires, Radio links

For the purposes of IP (Internet Protocol), layers 5 and 6 aren't really used. As you can see IPv4 and IPv6 are networking protocols (layer 3).

Scapy Notation

To represent the layers in a textual form, I tend to prefer the slash notation used by scapy, an excellent open source packet test tool. For example a web request packet would look like (physical layer is assumed):
ethernet/IPv6/TCP/HTTP

Another look at tunneling

With the OSI refresher, we can revisit the Idea of Tunneling to Hurricane Electric. A tunnel packet would like like this:

ethernet/IPv4 tunnel/IPv6/TCP/HTTP

As you can see an extra layer (or tunnel) has been inserted, the IPv4 tunnel, and is removed when the packet reaches the tunnel end point at Hurricane Electric.

IPv6 and DSL/PPPoE

You might think that a native connection to the internet via TekSavvy would be as simple as:

ethernet/IPv6/TCP/HTTP

But, alas, almost no one has a native ethernet connection to the internet. Most of us have a Cable or DSL connection to an ISP (Internet Service Provider), which means more encapsulations (or you could think of it as tunneling).

TekSavvy DSL, as many other DSL services uses PPPoE (Point to Point Protocol over Ethernet) over DSL (Digital Subscriber Link). There are several flavours of DSL, such as ADSL, HDSL, and VDSL. But your DSL modem will handle those lower layers (L1 & L2), and present an ethernet jack, where you would plug in your OpenWRT Router. (note: TekSavvy Cable does NOT support Native IPv6 yet)

The WAN interface on the router must be configured for PPPoE (which uses authentication, usually CHAP, Challenge Handshake Protocol). So far, the packets going into the router look like:

xDSL/ethernet/PPPoE/...

Part of the PPPoE negotiations that OpenWRT will do with the TekSavvy server is to assign an IPv4 address on the WAN interface. When IPv6 is enabled as part of PPPoE configuration tab (in Luci, the graphical web interface for OpenWRT), PPPoE will negotiate a pseudo-MAC address for the PPPoE interface, and a link-local address is then assigned.

What is not assigned is a global IPv6 address on the WAN interface. This is a little confusing at first, since IPv4 interfaces always have a familiar IPv4 address. But TekSavvy has decided to just use the link-local addresses for the PPPoE link, rather than use up another /64 for a point-to-point link. This creates kind of a gap (of global addresses) in the link between your home network, and the big Internet. This looks like this:

IPv6 Internet	TekSavvy	PPPoE	OpenWRT	Home LAN
global address	global->	link-local<------->link-local	->global	global

Networking without NAT

You may have noticed that with the exception of the PPPoE link (above) all the rest of the links are using globally routed IPv6 addresses. This is good, because without NAT any-to-any connectivity is restored (they way networks used to be before NAT).

However, the home network needs a globally routable prefix as well. Fortunately, TekSavvy will give you one to use, via DHCPv6-PD (Dynamic Host Control Protocol v6 with Prefix Delegation). The PD is the key, as it tells the router what globally routable address to advertise inside the home network (using Router Advertisements, RAs).

Configuration of OpenWRT

Before configuring your router, you may need to configure the DSL modem/router to be in bridging mode. This is important as PPPoE will not cross a router.

There is an excellent configuration guide for IPv6 on the OpenWRT website. You will need to install odhcp6c on your router to make the DHCPv6-PD request to TekSavvy, and accept the PD (prefix delegation) from them.

However, a couple of changes need to be made from that guide. The primary configuration is in /etc/config/network, a UCI (Universal Configuration Interface) file.

/etc/config/network

config interface wan
        option ipv6 1 # only required for PPP-based protocols
        ...

config interface wan6
        option ifname 'pppoe-wan' # use pppoe-wan or "@wan"
        option proto    dhcpv6
	option reqaddress 'none' # Does not request pppoe-link global address
	option reqprefix 'auto'  # Accept any prefix-length for prefix delegation

In the wan6 stanza, the ifname should be your pppoe interface (or you can use @wan), as you want the DHCPv6-PD request to be encapsulated in PPPoE. The request packet will look like:

ethernet/pppoe/ipv6 (link-local)/dhcpv6 request

Edit 15 June 2016: TekSavvy issues Prefix-Delegation differently based on the DHCPv6 Request Address option (option 3, IA_NA). In the example above option reqaddress 'none' will result in a PD of /56 being allocated to your router (yes that is 256 /64s, lots of room to play). However the default value is option reqaddress 'try' and will result in a PD of /64 allocation (much less fun). In the Luci (web interface) set "Request Address" to Disabled, and sit back and enjoy the /56 from TekSavvy!

Setting up your firewall

You will also want to put the wan6 interface in the same firewall zone as the wan (since you don't want everyone coming into your home LAN). Edit the firewall configuration file in /etc/config/firewall, and add wan6 to the option network line:

/etc/config/firewall

config zone                    
        option name 'wan'      
        option output 'ACCEPT' 
        option masq '1'       
        option mtu_fix '1'    
        option input 'REJECT' 
        option forward 'DROP' 
        option network 'wan wan6'

Of course, you can also use luci (the web interface for OpenWRT) to assign the wan6 interface to the wan zone.

OpenWRT auto-configuring RAs and routes

Once the DHCPv6-PD response come back from the TekSavvy server, OpenWRT will automagically send out RAs with the new prefix on that home LAN (br-lan interface). All hosts connected to the home LAN will use SLAAC (StateLess Address AutoConfig) to create globally routable addresses. OpenWRT will also insert routes to permit the home LAN packets to get out. You can see this route by ssh-ing to OpenWRT and typing:

root@OpenWrt:/tmp# ip -6 route
default from 2607:c000:812f:6f00::/56 via fe80::2a0:a512:85:2940 dev pppoe-wan  proto static  metric 4096 
2607:c000:812f:6f00::/64 dev br-lan  proto static  metric 1024 
fe80::/64 dev br-lan  proto kernel  metric 256 
fe80::/64 dev wlan1  proto kernel  metric 256 
fe80::/64 dev eth1  proto kernel  metric 256 
fe80::/10 dev pppoe-wan  metric 1 
fe80::/10 dev pppoe-wan  proto kernel  metric 256

The key route is the first one, the default route. Let's look at this line a bit more to decode what TekSavvy is doing. It says that any packet from the 2607:c000:812f:6f00::/64 (my home LAN PD) send to fe80::2a0:a512:85:2940 (TekSavvy Server link-local address) via the pppoe-wan interface. This is an excellent use of the link-local address, since it saves having to administer another prefix just for the PPPoE link.

If you have Windows machines on your LAN network, you will want to turn on the DHCPv6 server on the LAN interface. See IPv6 Dual Stack, the good, the bad, and the ugly.

/etc/config/dhcp

config dhcp 'lan'
        option interface 'lan'
        #option ignore '1'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        option ra_default '1'
        option ra_management '1' # 0=M & O bits set to zero

Checking IPv6 connectivity

If you look at the addresses of a machine inside your home LAN, you should now see a global IPv6 address with the new prefix.

~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 10:9a:dd:54:b6:34 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.115/24 brd 10.1.1.255 scope global eth0
    inet6 2607:c000:812f:6f00:56b:6a01:3728:8802/64 scope global temporary dynamic 
       valid_lft 6882sec preferred_lft 1482sec
    inet6 2607:c000:812f:6f00:fc71:1b50:8623:68a0/64 scope global temporary deprecated dynamic 
       valid_lft 6882sec preferred_lft 0sec
    inet6 2607:c000:812f:6f00:e451:232c:9150:b476/64 scope global temporary deprecated dynamic 
       valid_lft 6882sec preferred_lft 0sec
    inet6 2607:c000:812f:6f00:129a:ddff:fe54:b634/64 scope global dynamic 
       valid_lft 6882sec preferred_lft 1482sec
    inet6 fe80::129a:ddff:fe54:b634/64 scope link 
       valid_lft forever preferred_lft forever

And of course, there is ping6, that updated vintage test application.

~$ ping6 -c 2 -n google.com
PING google.com(2607:f8b0:400a:804::1008) 56 data bytes
64 bytes from 2607:f8b0:400a:804::1008: icmp_seq=1 ttl=56 time=14.9 ms
64 bytes from 2607:f8b0:400a:804::1008: icmp_seq=2 ttl=56 time=14.5 ms

Native IPv6, is it worth it? Absolutely!

A key advantage of running Native IPv6, rather than tunneled is much lower ping times, which translates to lower latency. How much faster? Via the Hurricane Electric, I was seeing ping6 to Google at about 120 ms, and Native is just under 15 ms, that is eight times less latency. Why such a big difference? It takes, time to manipulate packets (adding or removing encapsulations). And there is the time to traverse the tunnel, then traverse to the final destination. Going Native removes all of that.

For those who use multi-user games, the reduced latency will make a big difference (e.g. Xbox prefers IPv6 over IPv4).

TekSavvy Caveats

So it is all good news, right? Well not quite. TekSavvy's network setup will work for the masses, which I am sure is why they did it this way. Everytime the PPPoE is renegotiated, a new Prefix-Delegation is sent, which means the network prefix inside you home will change. OpenWRT will send out new RAs to advertise the new prefix, and all the machines on your network will create new global addresses. And most will not even notice.

The PD prefixes appear to be coming from a pool, and everytime PPPoE connects a new PD prefix is pulled from the pool. A friendlier implementation would be to give you the same prefix, like DHCP gives you the same address upon renewal.

DNS Bummer

But for the few of us who run their own DNS (Domain Name Service) in our Home, with AAAA records (IPv6 name to address records) for our internal machines, it breaks horribly. Suddenly without warning, all of the AAAA records are invalid, and your nice naming system for your internal machines are broken. I haven't resolved this issue, and for now, I have kept my Hurricane Electric tunnel up, which keeps my static IPv6 prefix, and I have the Native IPv6 prefix from TekSavvy. I'll have to code up something to update my AAAA records when TekSavy updates my prefix. Apparently (according to TekSavvy) static prefixes are not available for residential customers at this time.

DNS is your friend with IPv6. It is a nice abstraction layer which works world-wide, and can work in your home to help you not remember hexidecimal addresses (which are going to change anyway, since the prefixes change). Setting up AAAA records is the way to go.

Wrong M & O bits in RA

TekSavvy is sending the incorrect M & O (Managed and Other flags) in their RA. According to RFC 3315 (DHCPv6), they should be sending M=0, O=1, to tell the DHCPv6 Client to make a request, but don't try to get an address. Fortunately, OpenWRT allows us to tell the DHCPv6 client the same thing via configuration. By setting the /etc/config/network option reqaddress 'none' you are telling the client not to request an address. The side effect of this, is that TekSavvy will issue a /56 prefix (or the equivalent of 256 end network /64 prefixes) rather than a single /64. A /56 may seem like overkill for now, but as home network become more complex, having multiple subnets on multiple LANs within your home will become very useful (think about having a guest network, and an internal network, where your servers are).

Go Native!

Going Native is the way to go. ISPs will work through some of these operational issues, as they get more experience with IPv6. OpenWRT is an excellent open source router software which as of release 15.05 (Chaos Calmer) has excellent IPv6 support.

14 November 2015
Updated 15 June 2016

*