IPv6

Setting up WireGuard IPv6

I’ve been having a quick play with setting up another VPN solution for getting an IPv6 address on my mobile devices this time using WireGuard.

WireGuard is a relatively new VPN tunnel implementation that has been written to be as stripped back as possible to keep the codebase as small as possible to help make it easier to audit.

Setup

A lot of the instructions for running WireGuard on RaspberryPi OS talk about adding debian testing repos or building the code from scratch, but it looks like recent updates have included the packages needed in the core repositories.

# apt-get install wireguard

I set up UDP port forwarding on my router for port 53145 and got my ISP to route another /64 IPv6 subnet to my line, both of these are forwarded on to the Raspberry Pi that is running that is also running my OpenVPN setup. This is useful as it’s already setup to do NAT for the 10.8.0.0/24 range I’m issuing to OpenVPN clients so having it do itfor the 10.9.0.0/24 range for WireGuard is easy enough.

WireGuard on Linux is implemented as a network device driver so can be configured on the command line with the ip command e.g.

# ip link add dev wg0 type wireguard
# ip address add dev wg0 10.9.0.1/24

Which brings the device up and sets the IP addresses but you still need to add the Private Key and remote address and Public Key which can be done with the wg command

# wg set wg0 listen-port 53145 private-key /path/to/private-key peer ABCDEF... allowed-ips 0.0.0.0/0 endpoint 209.202.254.14:8172

Or more easily it can read from a config file

# wg setconf wg0 myconfig.conf

Or the whole setup and configured with wg-quick

# wg-quick up /path/to/wg.conf

Server Config

[Interface]
Address = 10.9.0.1/24, 2001:8b0:2c1:xxx::1/64
ListenPort = 53145
PrivateKey = oP3TAHBctNVcnPTxxxxxxxxzNRLSF5CwII4s8gVAXg=

#nexus
[Peer]
PublicKey = 4XcNbctkGy0s73Dvxxxxxxxxx++rs5BAzCGjYmq21UM=
AllowedIPs = 10.9.0.2/32, 2001:8b0:2c1:xxx::2/128

The Server config includes:

Address is the local address on the VPN tunnel, here has both IPv4 and IPv6.
ListenPort is which port to listen for client connections on. WireGuard doesn’t have a assigned port.
PrivateKey to identify the host.
There can be multiple Peers which represent which clients can connect and the AllowedIPs is the IP addresses for each client.

Client Config

[Interface]
Address = 10.9.0.2/32, 2001:8b0:2c1:xxx::2/128
PrivateKey = UFIJGgtKsor6xxxxxxxxxxxbWeKmw+Bb5ODpyNblEA=
DNS = 8.8.8.8

[Peer]
PublicKey = jMB2oMu+YTKigGxxxxxxxxxxSYcTde/7HT+QlQoZFm0=
AllowedIPs = 0.0.0.0/0, ::0/0
Endpoint = hardill.me.uk:53145

The differences from the Server config are:

Interface has a DNS entry for the client to use while the tunnel is running.
Peer has an Endpoint which is the public address and port to connect to
AllowedIPs are which IPs to route over the tunnel, in this case it’s everything

Key Generation

Both ends of the connection need a PublicKey and a PrivateKey so they can mutually authenticate each other. These are generated with the wg command

# wg keygen > privateKey
# wg pubkey < privateKey > publicKey

The WireGuard Android app that you can manually add all the details in the config file or it supports reading config files from QR codes. This makes it really easy to setup and removes the chance of getting a typo in the Keys and IP addresses.

You can generate QR codes from the config file as follows:

# qrencode -t png -o nexus.png < nexus.conf
# qrencode -t ansiutf8 < nexus.conf

The first generates a PNG file with the QR code, the second prints the code out as ASCII art.

Conclusion

It all looks to be working smoothly. I can see the advantages over OpenVPN being that you don’t need to worry about certificate maintenance and distribution.

I’ll give it a proper work out and see how it holds up running things like SIP connections along with general access to my home network.

As well as running it on the phone, I’ll set up a client config for my laptop to use when out and about. The only issues is that the Gnome Network Manager integration for WireGuard isn’t available in the standard repos for Ubuntu 20.04 so it needs to be started/stopped from the command line.

Contributing to Accel-PPP

I mentioned in a previous post about my desktop ISP project I was using the accel-ppp access concentrator. This provides the main components for allowing my “users” to connect to my network, it handles all the authentication and setting up of PPPoE connections.

While playing with it I wanted to look at settings different DNS servers for different users. For IPv4 this was already built in, you could put entries in the LDAP that get passed on via the Radius lookup when a user connects. But with my messing about with IPv6 only networks I also wanted to set custom IPv6 DNS servers on a per user basis.

You can set a global set of DNS servers in the config file

...
[ipv6-dns]
dns=fd12:3456:789a::1
dns=fd12:3456:789a::2
...

The Radius spec has an entry for holding IPv6 DNS server values (DNS-Server-IPv6-Address from RFC6911), but accel-ppp didn’t support using it. I mentioned it on the accel-ppp forum as a feature request and the developers seemed to think it would be a good idea, so I decided to have a go at implementing it.

First up adding the required bits to the LDAP for the test user, here I have one IPv4 DNS and one IPv6 DNS.

displayName: Ben Hardill
cn: Ben
sn: Hardill
mail: isp1@hardill.me.uk
uid: isp1
radiusReplyAttribute: MS-Primary-DNS-Server := "192.168.5.1"
radiusReplyAttribute: Reply-Message := "Hello World"
radiusReplyAttribute: Delegated-IPv6-Prefix := "fd12:3456:789a:2::/64"
radiusReplyAttribute: Framed-IPv6-Prefix := "fd12:3456:789a:0:192:168:5:2/128"
radiusReplyAttribute: DNS-Server-IPv6-Address := "fd12:3456:789a:ff64::1"
radiusFramedIPAddress: 192.168.5.2
radiusFramedIPNetmask: 255.255.255.0

My first pass was a little naive in that it ended up changing the DNS servers for all subsequent users by overwriting the global settings. It also only supported providing 1 DNS server when the DHCPv6 and RA both support up to 3. So it was back to the drawing board.

First up is to generate a linked list containing the DNS server addresses from the Radius response.

...
			case Framed_IPv6_Route:
				rad_add_framed_ipv6_route(attr->val.string, rpd);
				break;
			case DNS_Server_IPv6_Address:
				a = _malloc(sizeof(*a));
				memset(a, 0, sizeof(*a));
				a->addr = attr->val.ipv6addr;
				list_add_tail(&a->entry, &rpd->ipv6_dns.addr_list);
				break;
		}
	}
...

This gets bound to the users session object so it can be retrieved later. In this case when responding to a DHCPv6 request.

...
	if (!list_empty(&ses->ipv6_dns->addr_list)) {
		list_for_each_entry(dns, &ses->ipv6_dns->addr_list, entry) {
			j++;
		}
		if (j >= 3) {
			j = 3;
		}
		opt1 = dhcpv6_option_alloc(reply, D6_OPTION_DNS_SERVERS, j * sizeof(addr));
		addr_ptr = (struct in6_addr *)opt1->hdr->data;
		list_for_each_entry(dns, &ses->ipv6_dns->addr_list, entry) {
			if (k < j) {
				memcpy(addr_ptr, &dns->addr, sizeof(addr));
				k++;
				addr_ptr++;
			} else {
				break;
			}
		}
...

Now this is not as clean as I would like since we have to walk the list to know how many DNS servers there are in order to allocate the right size chunk of memory to hold the addresses and then walk it again to copy the addresses into the response. I might go back and add the list length to the session structure and update it when adding items to the list so we can avoid this step.

Testing

While working on these changes I wanted something a bit quicker than having to deploy the changes to my physical test rig (a collection of Raspberry Pi and switched hidden under my sofa). To help with this I spun up a VM with a copy of CORE. CORE comes from the NRL and allows you to build virtual networks and run code on nodes within the network.

This means I can start and stop the access coordinator really quickly and spin up as many clients as I want. I can also easily drop in L2TP clients (which use the same Radius and PPP infrastructure in accel-ppp) to check it works there as well. It also lets you attach tools like tcpdump and wireshark to capture packets at any point in the network which can be difficult with home grade switches (enterprise switches tend to have admin interfaces and the ability to nominate ports as taps that can see all traffic).

I have submitted a pull request against the project, so now fingers crossed it gets accepted.

Problems with a IPv6 only network

In my last post I talked about running a pure IPv6 network, as part of my ISP building project, but still allowing access to resources on the internet currently only available via IPv4.

This works well assuming all the clients on the local network are IPv6 capable, unfortunately this is not always the case. There are legacy devices that do not understand IPv6.

This is a real problem with IoT devices that are either no longer being maintained or just that have hardware that is incapable of using anything other than IPv4. There is also a small problem that a IP cam with a IPv6 address is probably available to the world with out some firewall rules or a ACL limiting access to the local /64, but those are problems for another day…

Another issue is hard coded IPv4 addresses in legacy applications, this is a problem even if the OS/device supports both IPv4 & IPv6 but is only connected via IPv6.

There is are a few of solution to both these problems.

Dual Stack networks

The simplest is to just run a dual stack network supplying both IPv4 & IPv6 all the way from the end device to the edge of the ISPs network. While this works it either means using lots of IPv4 addresses in the ISPs internal network and probably 2 layers of NAT (one at the customers router and then CGNAT at the edge of the ISPs network) assuming the ISP is not handing out publicly routed IPv4 addresses directly to customers.

464XLAT

464XLAT -> 4 to 6 to 4 X transLATion and the X can be either a Client or Provider.

464CLAT comes in 2 main types

464CLAT – on host

464CLAT works by doing the conversion from IPv4 to IPv6 on the client. This works for sites that are only available via IPv4 and for hard coded IPv4 addresses. It all happens in the TCP/IP stack on the host OS. For this to work the OS needs a way to work out what the DNS64 prefix is.

This paper discusses methods for a client to determine the NAT64 prefix. It suggests that the simple method of looking up the IPv6 address of a hostname known to only have a IPv4 entry ipv4only.arpa and using returned address (This behaviour is described in rfc7050).

There is an important step to validate that the address is returned is valid, because DNS64 breaks DNSSEC it takes a few extra steps.

Make a IPv6 (AAAA) look up for ipv4only.arp with DNSSEC checking disabled
Make a reverse (PTR) lookup of the IPv6 address 64:ff9b::c000:ab
This should return a pointer to a fully qualified domain name for a host in the ISPs domain (nat64.hardill.me.uk).
Finally make a IPv6 (AAAA) lookup for this hostname, which should return the same IPv6 address and a valid DNSSEC signature (RRSIG AAAA) record signed by the ISPs domain keys.

All of the required parts for this are running on my test network, I just need to attach some client devices to see if it works.

464CLAT – on router (Stateless translation)

This is a form of dual stack network, but it limits the dual stack to just the customer side of their router.

In this case the client network runs both native IPv6 and a RFC1918 range IPv4 and the clients router does the conversion by adding the IPv6 prefix. As well as running DHCPv6/SLAAC for IPv6 addressing it also runs DHCPv4 and hands out IPv4 addresses.

This works for devices that can’t support IPv6 (e.g. cheap IoT devices) and you still get to run a IPv6 only network in the ISP network.

The router generates it’s own prefix from the publicly routed IPv6 range it’s been allocated for it’s client side network. It then uses this prefix to generate 1 to 1 IPv6 addresses for each IPv4 address it hands out.

Jool can also be used to handle this in SIIT mode, you have to tell it what the input IPv4 range is and the IPv6 prefix it can work with.

#!/bin/sh
modprobe jool_siit
jool_siit instance add "example" --iptables
jool_siit -i "example" eamt add fd12:3456:789a:ff46:2::/96 10.99.0.0/24
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.ppp0.accept_ra=2
sysctl -w net.ipv6.conf.all.forwarding=1
ip6tables -t mangle -A PREROUTING -j JOOL_SIIT --instance "example"
iptables  -t mangle -A PREROUTING -j JOOL_SIIT --instance "example"

Here I’ve hardcoded the IPv6 prefix, but for a real deployment we would need to use a delegated IPv6 prefix that is routed to the gateway. This should be run using the script option for dhcp6c when the prefixes are delegated.

interface ppp0 {
	send ia-na 0;
	send ia-pd 0;
	script "/etc/dhcp6c/reply.sh";
};
id-assoc na {
};
id-assoc pd 0 {
  prefix-interface eth1 {
    sla-len 0;
    sla-id 1;
  };
};

This config takes the /64 prefix and assigns it to eth1 for clients to use as part of SLAAC. I’m still working out how to extract the second /96 prefix and pass it to the script.

We can then update the script that starts jool as follows and point to it in the dhcp6c.conf file so it gets run once the network is up.

#!/bin/sh
#IPv6=`ip -o -6 a show dev eth1 | awk '/global/ { print $4 }'`
#PREFIX=`subnetcalc $IPv6 -n | awk '/Network/ { print $3}'`
IPv4=`ip -4 -o a show dev eth1 | awk '/global/ {print $4}'`
SUBNET=`subnetcalc $IPv4 -n | awk '/Network/ {print $3}'`
#need to make sure this only runs once
modprobe jool_siit
jool_siit instance add "example" --iptables
jool_siit -i "example" eamt add fd12:3456:789a:ff46:2::/96 $SUBNET/24
sysctl -w net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.forwarding=1
ip6tables -t mangle -A PREROUTING -j JOOL_SIIT --instance "example"
iptables  -t mangle -A PREROUTING -j JOOL_SIIT --instance "example"

464PLAT

This is usually just the NAT64 we talked about in the last post running in the ISPs network.

IPv6 only network with IPv4 access (DNS64/NAT64)

Continuing the theme of building my own ISP I started looking at running a IPv6 only network.

As IPv4 addresses become increasingly scarce it won’t be possible to hand out publicly routeable addresses to every user. The alternatives are things like CGNAT but that has a bunch of problems.

On the other hand the default suggested IPv6 allocation per user is a /48 subnet (which is 65,5536 /64 subnets each containing 18,446,744,073,709,551,616 addresses) which should be more than enough for anybody. More and more services slowly are making them selves available via IPv6.

So rather than run a dual stack IPv4/IPv6 network with a double NAT’d (at the home router and again at the ISP’s CGNAT link to the rest of the internet ) IPv4 address, we can run a pure IPv6 ISP and offer access to IPv4 via a NAT64 gateways to allow access to those services that are still IPv4 only.

DNS64

This is the part that converts IPv4 addresses to IPv6 addresses.

The local device looking to connect makes a DNS request for the hostname of the remote device. If there is no native AAAA (IPv6 address) entry for the hostname, the DNS64 server will generate one based on converting the IPv4 address to hex and prepending a IPv6 prefix. The prefix can be anything with at least /96 (allowing enough room for all IPv4 addresses) but there is a pre-defined address range of 64:ff9b::/96.

So if looking up the remote hostname returns 192.168.1.5 then the mapped IPv6 address would be 64:ff9b::c0a8:0105 (192.168.1.5 -> c0.a8.01.05 in hex)

As of version 9.8 of bind support for DN64 is built in and configured by adding the following:

...
dns64 64:ff9b::/96 {
  clients { any; };
  mapped { !10/8; any;};
  break-dnssec yes;
};
...

Running your own means you can control who can access the server (using the clients directive and control which IP address ranges are mapped or excluded).

All this IP address mapping does break DNSSEC but since most clients rely on their recursive DNS servers to validate DNSSEC record rather than doing it directly this is less of a problem.

There are also a number of public DNS servers that support DNS64 including one run by Google.

To test you can use dig and point to the DNS64 server. e.g. to get a IPv6 mapped address for www.bbc.co.uk (212.58.233.254 & 212.58.237.254)

$ dig @2001:4860:4860::6464 -t AAAA www.bbc.co.uk

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> @2001:4860:4860::6464 -t AAAA www.bbc.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1043
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.bbc.co.uk.			IN	AAAA

;; ANSWER SECTION:
www.bbc.co.uk.		235	IN	CNAME	www.bbc.net.uk.
www.bbc.net.uk.		285	IN	AAAA	64:ff9b::d43a:edfe
www.bbc.net.uk.		285	IN	AAAA	64:ff9b::d43a:e9fe

;; Query time: 133 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon Feb 03 21:40:50 GMT 2020
;; MSG SIZE  rcvd: 124

We can see that 212.58.233.254 is d43ae9fe in hex and has been added to the 64:ff9b::/96 prefix to make 64:ff9b::d43a:e9fe

NAT64

This is the part that actually does the mapping between the IPv6 address of the initiating device and the IPv4 address of the target device.

There are a few different implementations of NAT64 for Linux

I decided to give Jool a go first based on a presentation I found.

I had to build Jool from source, but this wasn’t particularly tricky and once installed I followed the Stateful NAT64 instructions. There were 2 bits missing from this that caused a few problems.

The first was because my host machine has multiple IPv4 addresses I needed to add the right address to the `pool4`. When adding the the address you also need to specify a range of ports to use and these need to be excluded from ephemeral local port range.

The ephemeral range can be between 1024 and 65535 and you can check what the current range is set to with sysctrl

$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768	60999

For a proper deployment this range needs reducing so that you can commit enough ports for all the NAT64 connections that will pass through the gateway. You can also add multiple IPv4 addresses.

Quick aside: The whole point of this exercise is to reduce the number of publicly routable IPv4 addresses that we need. To make this work we are always going to need some, but we will share a small number at one point at the edge of the network to be used as the NAT64 egress point, but as more and more services move over to supporting IPv6 this number will decrease.

Because I’m only playing at the moment, I’m just going to use the 61000-65535 range and leave the ephemeral ports alone. I will still be able to host 4500 connections.

To make starting it all easier I wrote a short script that

Loads the module
Enables IPv4 and IPv6 routing
Sets up jool with the default IPv6 prefix
Adds the iptables entries to intercept the packets
Adds the IPv4 output address to the jool config with the port range for TCP, UDP and ICMP

#!/bin/sh
modprobe jool

sysctl -w net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.forwarding=1

jool instance add "example" --iptables  --pool6 64:ff9b::/96

ip6tables -t mangle -A PREROUTING -j JOOL --instance "example"
iptables -t mangle -A PREROUTING -j JOOL --instance "example"

jool -i "example" pool4 add -i 192.168.1.94 61000-65535
jool -i "example" pool4 add -t 192.168.1.94 61000-65535
jool -i "example" pool4 add -u 192.168.1.94 61000-65535

Putting it together

To make it all work I need to set the DNS server handed out to my ISP customers point to the DNS64 instance and to make sure that 64:ff9b::/96 gets routed via the gateway machine.

To test I pinged www.bbc.co.uk

$ ping6 -c 2 www.bbc.co.uk
PING www.bbc.co.uk (64:ff9b::d43a:e9fe) 56 data bytes
64 bytes from 64:ff9b::d43a:e9fe: icmp_seq=1 ttl=54 time=18.1 ms
64 bytes from 64:ff9b::d43a:e9fe: icmp_seq=2 ttl=54 time=23.0 ms

--- 64:ff9b::d43a:e9fe ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 18.059/20.539/23.019/2.480 ms

Mobile IPv6 Workaround

As I’ve previously mentioned I’m in the market for a cellular data plan that supports IPv6.

The only mainstream provider in the UK that offers any IPv6 support is EE, but only for their pay monthly plans and I want something for more occasional usage.

While I wait for the UK mobile operators to catch up, I’ve been using OpenVPN on my phone to allow it to behave as if it’s actually on my local network at least from a IPv4 point of view.

This just about works, but it did mean that I have the DNS reply with internal addresses when queried from within and external addresses when queried from addresses outside. Again this is possible to do with bind9 using views, but it leads to a bunch more administration when ever anything needs changing.

It also doesn’t solve the need to access other people’s/organisation’s resources that are only available via IPv6.

OpenVPN can also route IPv6 over the tunnel and hand out IPv6 addresses to the clients that connect. Instructions for how to set it up can be found on the OpenVPN Wiki here.

By adding the following to the OpenVPN server.conf file

tun-ipv6
push tun-ipv6
ifconfig-ipv6 2001:8b0:2c1:xxx::1 2001:8b0:2c1:xxx::2
ifconfig-ipv6-pool 2001:8b0:2c1:xxx::4/64
push "route-ipv6 2000::/3"

I initially was trying to work out how to carve a section out of the initial /64 IPv6 subnet that my ISP had assigned to me. My plan was to take a /112 block (which maps to 65536 addresses) but as a general rule you are not meant to try and use IPv6 subnets smaller than /64.

Luckily A&A assign each customer a /48 range that can be split up across multiple sites/lines. Or you can assign extra /64 or /60 blocks to an existing line.

I choose to add a second /64 to my existing line and then configured my Ubiquiti Edgerouter X.

set protocols static route6 2001:8b0:2c1:xxx::/64 next-hop fe80::92fb:a6ff:fe2e:28a2

Where fe80::92fb:a6ff:fe2e:28a2 is the link local address of the machine running the OpenVPN server.

The added bonus is that I now can get IPv6 access on both my mobile phone and on my laptop when away from home.

The quest for a IPv6 capable mobile data plan

For the last few weeks I’ve been trying to find a UK Mobile data provider that will provide a IPv6 address (well, hopefully a bunch of them that I can share round a few devices, but given how IPv6 normally works this should be trivial).

The reason I want this is because I’m playing with VoIP and SIP at home and I want a reliable way to be able to do direct point to point routing without having to resort to a VPN constantly running on my test devices. While my ISP (the wonderful A&A) have recently started handing out /29 and /30 subnets to make this sort of thing easier for IPV4 most mobile providers don’t provide a routable IP address, they all use CGNAT.

Currently the only major player that claims to support IPv6 is EE. I had a quick search online and found a bunch of forum posts from mid 2017 saying that they had started to roll it out, but only to new pay monthly customers. Given it is now approaching mid 2018 I thought things must have moved on a little but I couldn’t actually find anything more up to date anywhere on line. Having poked around on EE’s website none of the plan information mentions IPv6.

I called into one of EE’s retail stores and had a chat with the staff who didn’t really understand what I was asking for (to be fair it is a bit of a technical question compared to what they normally get asked), but I did manage to convince one of them to disconnect from the WiFi and get android to list their addresses. This showed a IPv6 address so things were looking up.

At a bit of a loss I called EE’s customer service team to see if they could tell me which plan I should pick, the Level 1 agent couldn’t help so passed me to Level 2, unfortunately they weren’t much help either and the best they could suggest was to get hold of a SIM and try.

Since the EE website offers sim cards for free I decided to try and order one and give it a go. At which point I ran into the next problem, the order form is not RFC2822 compliant. Meaning that it will not allow you to include tags in email addresses e.g. foo+ee@example.com where the +ee is a tag allowing you to identify who you gave the email address to.

@EE Please pass this link to your web team, having a + in your email address is perfectly valid. (trying to order a Pay&Go sim and being refused because of a "invalid" email address) https://t.co/Zsvhswq5GN

— Ben Hardill (@hardillb) April 18, 2018

After a little back and forth with EE’s social media team they managed to arrange to send me the Pay & Go Data (Tablet & 4GEE WiFi) SIM I was trying to order and hopefully pass to issue on to their web development team (to be fair validating email addresses is near impossible, which is why you shouldn’t even try).

Given this was explicitly a data SIM I was hopeful it would get a usable address. After topping up £10 to activate the sim and using that to buy £5 200mb data bundle I fired things up and crossed my fingers. And no joy, so back to having to run VPN tunnels on all my devices to effectively put them on my home network.

In conclusion is the IPv6 is basically still not available to the UK mobile data market.

It’s been coming for a while, but we really are getting close to running out of IPv4 addresses. The rate of growth of the internet continues to accelerate with not just more and more people getting online but items such as appliances and sensors. This internet of things has been talked about before (small corporate plug) here, all these things need an IP address in order to interact with the rest of the world.

There are a number of technologies that have been deployed try and help eek out the finite pool of IPv4 addresses such as CIDR and NAT. NAT works well when connections are initiated from behind the NAT gateway, but don’t work when the remote end needs to open the connection, e.g. FTP data connections.

The long term solution is to move to IPv6, this new iteration of the protocol has a much larger pool of addresses (capable of supplying 6.67 * 10^27 addresses per square meter of the planet) which should last a while longer.

Playing

Since we are all going to have to move to IPv6 at some point I thought I’d have a play. My ISP at home does not offer IPv6 support yet but there are companies that offer IPv6 over IPv4 tunnels. Wikipedia has a list here, I picked Hurricane Electric who offer free 6in4 tunnels and have multiple end points in Asia, Europe and the US.

Once you have signed up there is a “Create Regular Tunnel” link in the left hand side bar. To use a tunnel from Hurricane Electric you need a static IPv4 address that can be pinged from the internet. When you have entered your IPv4, the site will suggest the closest end point.

By default Hurricane hand out a IPv6 subnet with a /64 prefix, this means that the top 64bits of the address are considered the network mask and the rest of the address can be used for up to 18,446,744,073709,551,616 hosts. With that many addresses to go at I don’t think I’m likely to run out any time soon. It is possible to get /48 subnets assigned as well if for any reason you think that a /64 will not be enough (actually there are good reasons why you might want this which I’ll mention later).

Once you have completed the tunnel request form you should end up with a page which has information similar to this.

Account: hardillb
	Global Tunnel ID: 53560 	Local Tunnel ID: 1701
	Description:
	Registration Date: 	Tue, Apr 13, 2010
Tunnel Endpoints
	Server IPv4 address: 	216.66.80.26
	Server IPv6 address: 	2001:470:xxxx:xxx::1/64
	Client IPv4 address: 	93.97.xxx.xxx
	Client IPv6 address: 	2001:470:xxxx:xxx::2/64
Available DNS Resolvers
	Anycasted IPv6 Caching Nameserver:	2001:470:20::2
	Anycasted IPv4 Caching Nameserver:	74.82.42.42
Routed IPv6 Prefixes and rDNS Delegations
	Routed /48: 	Allocate /48
	Routed /64: 	2001:470:xxxx:xxx::/64
	RDNS Delegation NS1: 	none
	RDNS Delegation NS2: 	none
	RDNS Delegation NS3: 	none

Hurricane also provide helpful little feature at the bottom of the page that details the configuration details for a bunch of different operating systems. There are 2 different sets for Linux depending which tool chain you are using.


modprobe ipv6
ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.80.26 # Server IPv4 address from above
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:xxxx:xxx::2/64  # Client IPv6 address from above
route -A inet6 add ::/0 dev sit1

Configuration

The configuration hints on the Hurricane page are useful for testing but don’t match up with the various distros methods for establishing the tunnel at startup. The following instructions apply to Fedora 12

The first step is to enable IPv6, this is easily done by adding the last line to /etc/sysconfig/network file:


NETWORKING=yes
HOSTNAME=tiefighter
NETWORKING_IPV6=yes

Next the tunnel interface needs setting up. To do this create the following file as /etc/sysconfig/network-scripts/ifcfg-sit1.


DEVICE=sit1
BOOTPROTO=none
ONBOOT=yes
IPV6INIT=yes
IPV6TUNNELIPV4=216.66.80.26       # the IPv4 addres of your ISP's tunnel server
IPV6TUNNELIPV4LOCAL=192.168.1.5     # your host's local IPv4 address
IPV6ADDR=2001:470:xxxx:xxx::2/64         # your host's public IPv6 address

Once these where set restarting the networking component brought up the tunnel. This now means that this machine can send and receive traffic via IPv6, but that doesn’t get me any further than I had with the static IPv4 address I already had. The next step is to enable the other machines on my network so they can route via IPv6 as well. IPv6 has support for automatic address configuration built in called Stateless address autoconfiguration, the specification allows hosts to generate their own addresses based on the MAC address of the network card that it will use to send the packets over. This generates a 64bit number which acts as the host part of the address, the network part is supplied by the local router using the router announce protocol, as long as network part of the address is larger than /64 then it all works fine. . This all works because of IPv6’s hierarchical routing means that all packets with my prefix will be will be directed to tunnel and from then on it becomes my networks job to route them to the end hosts.

Back to the comment earlier about a /64 network not being enough for some people, if you have multiple network segments behind your tunnel then having a /48 network then you can assign different /64 networks to each segment to allow you to use Stateless address autoconfiguration on each.

To make the tunnel machine act as a router for all the other machines on the network it needs to be configured to forward packets and to make router announcements so the other machine can form correct addresses. Setting up the packet forwarding is easy enough, it’s just a case of adding another line to /etc/sysconfig/network file.


NETWORKING=yes
HOSTNAME=tiefighter
NETWORKING_IPV6=yes
IPV6_ROUTER=yes

To enable Router Announce we need the radvd app, once installed edit the /etc/radvd.conf file


interface eth0 {
	AdvSendAdvert on;
	MinRtrAdvInterval 30;
	MaxRtrAdvInterval 100;
	prefix 2001:470:xxxx:xxx::/64
	{
		AdvOnLink on;
		AdvAutonomous on;
	};
};

The last thing that needs doing is assigning a IPv6 address to the eth0 interface by adding it to /etc/sysconfig/network-scripts/ifcfg-eth0.


DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=none
HWADDR=00:1B:FC:10:0E:E5
ONBOOT=yes
DHCP_HOSTNAME=tiefighter
USERCTL=no
IPV6INIT=yes
PEERDNS=no
IPADDR=192.168.1.5
NETMASK=255.255.255.0
GATEWAY=192.168.1.254
DNS2=213.162.97.66
SEARCH=loc
DNS1=127.0.0.1
IPV6ADDR=2001:470:xxxx:xxx::3
NM_CONTROLLED=no

That should be it, I now have a fully functional IPv6 subnet at home. For Linux machines running NetworkManager it should just be a case of enabling IPv6 for the connection.

The only bit that is missing is DNS because remebering IPv6 addresses is even harder than IPv4 addresses, I’ll save that for the next post.

Resources

Linux IPv6 HOWTO fro the Linux Document Project – http://www.tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/
Useful hints on setting up IPv6 on Fedora (Only reachable via IPv6) – http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html (google cache version accessable via IPv4)