Just a quick post to flag up this software, which deserves recognition. It’s a VMware lookalike, but entirely Free (as in beer and as in GNU GPL)

Digiblue boo

As owner of a Digital Blue QX5 microscope (one of the cheapest, greatest,  ”serious educational toys” you can lay your hands on – and it’s not even clear if they still make it) my daughter wanted to use it the other day. It’s been unused for a while and during that period my only Windows machine has moved to Windows 7 64-bit. And the QX5 driver software supplied is, of course, Windows XP 32-bit. Off to the Digiblue web-site and relieved to see that they assure me that they have Windows 7 64-bit drivers available. Turns out to be a big fat lie. They have them available for a slightly revised model of the QX5. Not the original (different USB ids, etc.)

WINE?

Thoughts turn to Linux WINE. Hmmmm. Nope. USB drivers and WINE are one area that still doesn’t really do what it needs to do.

I need XP

OK – I realise that to get the thing working I need a Windows XP machine. Simple. Yet I can’t be arsed to set up a dual-boot or anything like that. So remember how neat VMware was all those years ago when I used to use it. I even bought a license for some early version! But I don’t fancy buying a new license which would cost about €130.

I have the dimmiest recollection of some sort of freebie workstation VM called virtual-something. Google around a bit and quickly find VirtualBox. And it’s just like the VMware I remember, but without the credit card requirement.

Now I’ve only used it in the simplest of manners: running an XP 32-bit VM on a Windows 7 64-bit host. Not tried any other permutation of host/VM, of which there are all sorts claimed. (Linux hosts, MAC, different Windows – and even more VMs, extending to the BSD and so on) But for what I wanted it’s absolutely spot on. Really neat.

Oracle, not a company I’ve ever been a fanatical supporter of, earns a few brownie points from me.

Here I cover the steps required to implement a simple point-to-point OpenVPN (SSL) VPN tunnel using PSK over IPv6 infrastructure.

One key element for me is to migrate my VPN connection to a remote host I own off IPv4 and entirely onto IPv6. This was not entirely straightforward! In fact it took hours and hours of research and experimentation to get this working. The eventual config required is not so mind-boggling. But getting there was tricky. As I’ve found out so many times before with regard to IPv6, the building bricks are lying around, but there are very few sources of information to help you stack them up. Once the steps are laid out, as you’ll see below, it’s actually pretty easy.

Migrating from what to OpenVPN IPv6?

We’re going to migrate an IPv4 OpenVPN point-to-point PSK VPN tunnel on Linux to an equivalent on native IPv6 infrastructure. We’re not trying to have an IPv4 tunnel over IPv6, nor an IPv6 tunnel over IPv4 (both of which are possible and useful in different situations). Here I aim to have an IPv6 OpenVPN SSL tunnel over pure IPv6 infrastructure.

My current VPN set up is:

• Home gateway running Ubuntu 10.04 (Lucid)
• Remote host running the same
• Fixed public IPv4 and IPv6 (global) addresses on each.
• OpenVPN point-to-point tunnel between them.
• Simple PSK authentication.
• Shorewall config as appropriate to OpenVPN.

To put some detail on it, there is a standard build of OpenVPN installed, with a config file such as /etc/openvpn/otherhost.conf:

At the other host we’ve a similar config, without the “remote <address>” part, and with the VPN addresses specified by the ifconfig flipped around.

This all works a treat. It’s about as plain an OpenVPN config as you could really get – a simple point to point tunnel using private IPv4 addressing.

OpenVPN and IPv6

This is really where things go all over the place. My starting point was over at the OpenVPN site, looking for details on IPv6. I found that:

Is IPv6 support planned/in the works?

Currently, there’s limited support for IPv6.

Point-to-point IPv6 tunnels are supported on OSes which have IPv6 TUN driver support (this includes Linux and the BSDs). IPv6 over TAP is always supported as is any other protocol which can run over Ethernet.

When OpenVPN 2.0 is run in server mode, IPv6 is currently only supported in TAP mode, not TUN mode (Server mode IPv6 TUN support will likely be added post-2.0).

The VPN carrier connection must currently use IPv4 endpoints, however there’s a patch which can be found in the openvpn-devel archives which adds IPv6 support. This patch will probably be merged into the mainline post-2.0.

So just what do we conclude from that? It says that point-to-point works with the TUN driver. But I couldn’t find any useful information about how to set it up.

Researching further, I find that the version of OpenVPN we’re using with Ubuntu (which is the latest) has very limited IPv6 support indeed. Indeed somewhat less than the OpenVPN web-site led me to believe! Now it may well be that the problem is my inability to understand the nuances of what the OpenVPN folks are saying. But I sure couldn’t get it working with the installed, standard version.

So I then find a lot more information here, which strongly suggests that I need to use a special IPv6 payload patch to achieve what I want to achieve. Specifically it says:

in point-to-point TUN mode, OpenVPN can transport IPv6 packets with the –tun-ipv6 option. No support for configuring the IPv6 endpoints and routes from within OpenVPN either, you need to run external “up” scripts.

That implies that I could use the unpatched OpenVPN and then manual scripts. As we’ll see below, in fact I had to use the patched version and external scripts! Again, likely due to a lack of knowledge on my part. But as a network engineer, I figure if I can’t work it all out then others will be in the same predicament.

VPN addressing

With IPv6, as discussed previously, the whole notion of private and public is done away with. Or at least, the meaning is seriously changed. Since we no longer have NAT in IPv6 (due to the address space being so very large) we do not have private address ranges for use inside a NATted network. So when choosing IPv6 addresses to use on our VPN it would seem that we can use any values. Well, yes and no. Back in IPv4 we could also have used any values too, while running the risk of accidentally using addresses which do really exist in the public Internet. So it is with IPv6, where we might collide with real addresses. It’s unlikely in these early days of IPv6, but we want to avoid it.

Another point to note, as with IPv4, is security. If VPN traffic inadvertently ”leaks” out of a public interface (and this is easier to achieve than you might think, particularly when you are setting things up!) then it would be good to use addresses which any compliant adjacent router will simply drop as unroutable, rather than propagate them in to the wider world. Indeed this desire to avoid “leaks” is also a reason to not simply use a chunk of IPv6 addresses out of your allocated pool. It’s not as if they are scarce – but mixing VPN addresses and public addresses so intimately is just asking for trouble. In a perfect world, then fine. But I do not live in that world. So an arbitrary addressing barrier betwen my VPN and the Internet is no bad thing.

So for this IPv6 VPN, we shall use so-called Unique Local Addresses, (Over here I touched upon Link Local addresses which are, as the name suggests, valid only within a single network.) as per RFC 4193. The history of all this is damn messy, but the bottom line is you should choose addresses in the range fd00::/8. So I will, merrily ignoring all the rest of RFC 4193, with its try-and-make-it-random stuff, use the following:

• fd22::22 – the gateway device
• fd22::1 – the remote host

What does good look like

What’s our definition of a working IPv6 VPN? How will I know when “it’s working”? My criteria include:

• if I do an ifconfig I see a discrete VPN interface.
• I can ping6 from one host to another.
• during a ping6 I can tcpdump the tunnel interface and see clear traffic.
• during a ping6 I can tcpdump the real WAN interface and see encrypted traffic.

Install a patched OpenVPN

As mentioned in the introduction, I ended up using a patched OpenVPN. I still believe that, based upon what the OpenVPN website says that this should not be required! But I ended up doing it. If you trust the use of a pre-built binary (I did) then it’s actually pretty easy to install. Bearing in mind that the system being used are running Ubuntu Lucid, follow these steps and you should be good to go:

• Go to this page and have a bit of a read.
• Towards the bottom, you should find a link that takes you to this page.
• At the time of writing, this page only has builds for Intrepid and Karmic. And we’re Lucid. But fear not, and assume Karmic is correct…
• As per the instructions, add the repository and signing key as per karmic.
• Then perform the usual apt-get update followed either by a apt-get install openvpn or just a apt-get upgrade if openvpn was already installed.

And you should be all set with the required version.

Ancillary config

I’m just going to cover the IPv6-specific OpenVPN config file. I’m not going to go in to every last detail required “around the edges”. Just a few reminders:

• You will point to your new IPv6 OpenVPN config from /etc/default/openvpn
• You need to add the required config, just as for IPv4, to your shorewall6 config.

Core config

Here we get to the details. The configs used will actually be very similar to the IPv4 versions, with obvious changes for IPv6.

I’ll say again: I simply do not understand why the config has to be this way. Based upon the documents and info above, I should be able to put this all neatly within the OpenVPN config. But I could not, and hence the configs below reference simple ‘helper’ script to bring the tunnel up correctly.
Here is the config for the home gateway device:

local local6address_as_per_hosts_file
remote remote6address_as_per_hosts_file

# Local and remote unique-local addresses
ifconfig-ipv6   fd22::22 fd22::1
# Allow external script to be run
script-security 2
# Script to do the rest of the work...
up /etc/openvpn/helper.up

proto udp6
dev tun
tun-ipv6
secret topsecret.psk
comp-lzo
keepalive 60 180
ping-timer-rem
persist-tun
persist-key
user root
group root
daemon


And here is the referenced helper script helper.up:

#!/bin/bash
ip -6 link set tun0 up
ip -6 addr add fd22::22 dev tun0
ip -6 route add fd22::1 dev tun0


And here’s one for the remote server:

# Local and remote addresses
ifconfig-ipv6 fd22::1 fd22::22

# Allow external script to be run
script-security 2
# Script to do the rest of the work...
up /etc/openvpn/helper.up
proto udp6
dev tun
tun-ipv6
secret supersecret.psk
comp-lzo
keepalive 60 180
ping-timer-rem
persist-tun
persist-key
user nobody
group nogroup
daemon

#!/bin/bash
ip -6 link set tun0 up
ip -6 addr add fd22::1 dev tun0
ip -6 route add fd22::22 dev tun0


Note that each makes use of names, where posible, rather than IPv6 addresses, which have been added to /etc/hosts to make everything easier to read and less prone to typos!

Static addressing

Yes, the addressing scheme is kinda static, I know. I wanted to keep this as simple as possible (which already isn’t so very simple…) and have everything point-to-point, with all routing being host-specific routing, rather than ranges. The obvious way to slightly adapt this is to allocate two IPv6 subnets within the unique-local adresses being used, and then of course adapt the helper scripts to add the route for the subnets rather than the specific hosts. I’m sure anyone who has got this far can make that change.

Success!

That’s about all that’s required. With the above config in place and the firewall set up correctly an ifconfig on the home router returns:

Not self-build?

I wanted a device with similar functionality, to play my large collection of videos stored on a server and also allow occasional photo browsing. I didn’t have many hard and fast requirements, but as far as they went they were:

• support a wide range of media formats, particularly DivX variants and MKV hi-def.
• support a wide range of output (today we still have a large but rather old normal-def TV – I am sure in the lifetime of a new device our TV will get replaced with something HDMI-ish)
• smart networking: my house is a mixture of Ethernet-over-power and wi-fi, with little cabled Ethernet)
• Open. Very important. No proprietary crap, either in terms of what it can play or what I am allowed to do with it.

Given this and my propensity for building my own kit, a self-build seemed like an obvious idea. I toyed with the obvious mini-ITX options, with appropriately funky video cards and one of the Linux TV-based distros. But when I did a rough calculation of both the cost and the work required I couldn’t help but check if there was anything ready-built which would also do the job. I didn’t expect to find anything, to be honest. It was almost a “Due Diligence” exercise which I had to perform so that when I then spent day after day getting my self-build working OK I could mentally justify the effort. However the formality of proving there was nothing which met my needs turned out to have a surprise ending.

Netgear EVA9150

To cut a long story short, I came across the Netgear EVA 9150. Lovely device. Absolutely spot on. And no, I have no affiliation with Netgear! I paid € 270 of my hard-earned cash for it. I’ll not run through the spec (you can get that here) but will mention some key features it has which make it rather special and ideal for my requirements.

Server support

Go back to the recent past and devices such as the Pinnacle Showcenter used a web-based client-server architecture. The mediaplayer was, for many purposes, a web-client. It obtained metadata, menus, etc. from the server which had to run either proprietary software or, thanks to some open-source projects, a web server. Either way, you had to run “special” software on the media server. Then, to actually play something, the mediaplayer would initiate a web-streaming transfer of the data. Given the limited buffering capability available this meant that the server and network had to, more or less, deliver the required bit-rate in real-time. Any variations (due to a server hit or a network glitch) would result in degraded or completely stopped video playback.

The EVA9150, as I gather with many of the newer generation of mediaplayers, has a quite different architecture. They are actually simpler. The player itself is now much smarter and so demands correspondingly less smarts of the server. All the server has to be is what it already is: a network file server. The mediaplayer runs a local operating system (Linux in the case of the EVA9150) and just scans the server and, when required, copies stuff across. See below where I talk about caching for what this means in practice…

The version of firmware that came installed on my EVA9150 only supported Samba (i.e. Windows) shared file systems from the server. However the EVA9150 software seems to be under pretty active development, and a newer version (easy install: USB key in the front panel) now provides NFS support too. Since I run a Linux-based file server, this is great.

Networking

It has the almost obligatory 10/100 wired Ethernet port. I’m currently using that into a Ethernet-over-power adapter. The box also has built-in (and it really is built-in: the antennae are completely hidden inside the casing) 802.11a/b/g/n. That last one is interesting: nominal 300Mbps, 5GHz band, wi-fi. I’ve not tested it yet, but it could be useful in the future.

Caching

Ahhhh. This is, for me anyway, the killer feature. My home network works OK most of the time. Like most home networks, it will occasionally hiccup. And during a 2 hour movie even the occasional hiccup or two can become madly apparent when one is streaming in near-real time. Here the EVA9150 does something so simple. It’s not at all unique, it’s just done so well and transparently. It caches to the local 500GB disk. So you start a 2 hour movie and, probably within a few minutes of the start, it’s cached the whole thing successfully to the local disk. Network glitches be dammed. Simple. Perfect. Me like.

Media formats supported

The independent reviews of the EVA9150 make this point pretty strongly: try and find something, anything, it can’t play. OK, I best they exist. But it does everything I’ve chucked at it. I’ve got the output connected to a low-def standard TV. I start playing a hi-def Matroska file. Apart from the fact that is support MKV in the first place, I don’t get any crap about “this is hi-def, the output is not” etc. It just PLAYS IT, and down-specs (or, apparently, up-specs under other conditions) as required.

Physical support

There’s a plug on the back for anything I’ve ever heard about. From SCART up to HDMI, with loads in between.

Value for money?

All in all, it’s a very good mediaplayer. Not cheap, but if I’d built a box with the same spec myself, quite apart from my time, I don’t think the parts would have come to less than the €270 I paid anyway.

Interesting appeal court decision in the UK yesterday. A certain Gary McFarlane, a “

The story seems fairly well covered here, here and here (lefties, right-wing and The BBC!) with similar reporting.

First off one cannot but wonder what a “Christian relationship counsellor” actually is. Is it like a “Christian car mechanic”, who we wonder is a car mechanic who goes to church, or a car mechanic who only works on Christian cars? And given, as we soon discover, that Mr McFarlane objects, in at least some form or another, to homosexuality, you have to wonder just who would choose to become a sex therapist when you have a hang up about a common sexual orientation.

But that is not the main issue here – the real issue is whether Mr McFarlane can claim supernatural beliefs permit him to discriminate against people in his working life. And the English courts have emphatically said “No”. In essence the court says that your beliefs are your own business, not anyone else’s. And if you choose to apply them to others you may find that they contradict the laws of the country. And at that point you have a problem.

So so far, so fairly dull. Today it is homosexuality. 30 years ago it might have been the perceived right to be a racist. 80 years ago the right to be openly sexist. And so on. The litmus test for bigots changes as time goes on. What’s much more interesting here is that Mr McFarlane claims that he is right simply due to his arbitrary religious beliefs.

And, as the reports make clear, the courts very firmly rejected that and have caused considerable annoyance amongst those who do wish to have their superstitious beliefs imposed upon others.

The quote that really caught my eye was Lord Carey (a former Archbishop of Canterbury – the deputy head of the Church of England) saying of the ruling: “ It heralded a ‘secular’ state rather than a ‘neutral’ one. “

That is extraordinary. In one short sentence he implies firstly that today the UK is not a place where religion affects those who do not believe in it, and also that “secularism” is in some way anti-religion and generally negative.

Taking his suggestion that the UK is a “neutral” place already: one could write a book refuting that. But a few that spring to mind are:

And the list goes on. The point being that for Carey to claim that, religiously, the UK is today “neutral” is ridiculous. And his interesting suggesion that, even if it was neutral, we’ve now tipped over into secularism! It’s dishonest of him. He is not a stupid man, and is well aware of the dishonesty of that statement. Secularism is the very essence of neutraility, as it applies to government.

Take supernatural beliefs out of government. Stop bleating about religious discrimination. You are the one who wishes to practice religious discrimination Carey, not the secularists. And stop subtly  insinuating that lack of religion equates in some way with lack of morality. That’s dishonest. And dishonesty is bad. I would have thought you might have known that.

When in my IPv6 environment I perform a test ping to, say, Google, it seems to work great:

Which is lovely. But I then ask myself how the ping6 command actually gets to know that name ipv6.google.com lives at IPv6 global address 2a00:1450:8006::6a. How is the domain name being resolved? And I find that I actually don’t know. I’m perfectly familiar with IPv4 DNS. So what’s going on here?

I’m cheating

I discover, upon investigation, that in fact I’m “cheating”. By that I mean that my attempt to set up a “pure” IPv6 environment (albeit in parallel with IPv4) that does not rely upon or touch IPv4 in any way has not been achieved – It turns out that my DNS is currently entirely dependent upon the existing IPv4 infrastructure! And before going ahead and trying to rectify that, it’s actually rather educational to understand how it is actually working at all.

So I run tcpdump on the IPv6 interface and take a look at what’s going on when I kick off the ping6:

• A DNS query (UDP – port 53 – IPv4 – standard stuff) goes out for ipv6.google.com. The odd looking bit is the DNS query type: “AAAA”. What’s that? That actually signifies that this is an IPv6 query. Special.
• And sure enough we get a response from the IPv4 DNS. It does not decode it here, but in the CNAME response data is the full IPv6 address required.
• In fact it returns, as DNS queries often do, more than one address. It returns a selection of 6 of them, of which one gets selected for use.
• And we then get a rather odd repeating pattern of subsequent PTR resolution attempts, which is a bit confusing. We’ll ignore that bit for now.

So: in fact our IPv6 DNS is running (with great success!) but…………. over an entirely IPv4 infrastructure.

It’s fabulous that it all works so easily and seamlessly. However, for the purposes of my voyage in to IPv6, I’d actually rather not use the IPv4 side of things at all. What if IPv4 wasn’t available to me? So what to do?

Pure IPv6 Name Resolution – IPv6 DNS

So we want to shift the DNS function off IPv4 and to make use of the IPv6 infrastructure. Where to being? Well, since setting up all the IPv6 I had noticed some new bit ‘n bobs appearing in my logs, as you do with new things. And I’d mostly ignored them for now. Again, as you do. But this one was appearing rather regularly, and now seemed rather interesting…

Mar 30 09:45:30 xxxxx radvd[2351]: RDNSS address 2a01:e00::1 received on eth0 from fe80::207:cbff:fea5:1a68 is not advertised by us

What’s that all about? Looking at the elements:

Grabbing the incoming packet that seems to generate these logs I see more when fully decoded. The packet concerned is an expected Router Advertisement (RA) but it has some options on it:

Source link-layer address: we can ignore that.

Manual test of IPv6 DNS

Before jumping in to new software subsystems, let’s try a manual test and see what happens. Just as one can use nslookup on the command line to check name resolution for IPv4, so one can use it for IPv6 too. Specify the name to be resolved and the server to us (or else we will default as per /etc/resolv.conf) and see what happens, checking with tcpdump:

 nslookup ipv6.google.com 2a01:e00::1

And I see the following packet sequence result:

Key here are the first and fourth packets: DNS request out, and DNS response back. All in IPv6. No IPv4 there at all. That’s good. We can see our IPv6 DNS server and, in principle, they work.

A secret – ndisc6

Time to let you in on a little secret to make life much easier… While tcpdumps and so on are instructive up to a point, and force one to think a little about what is being seen, they are also pretty tedious. A lot of what we need to achieve here can be done using much more accessible tools! Do yourself a big favour and install the ndisc6 package on your linux system. The creator’s web page gives you a little more information, but just as an example, look at this command + output:

Wow. Look at all that! Useful.

Now to move on to integrating this into the system so all IPv6 names get resolved this was.

rdnssd – Recursive DNS Server daemon

I think I should start out with a warning here: this next step is the entirely logical and sensible thing to do. But in fact read through to the end: it’s not going to work – the Linux IPv6 userspace tools are simply not quite here they should be yet… But it’s instructive to look at this, if only for the learning it provides.

Let’s set up the required sub-system to handle IPv6 DNS requests from this system and the users who will later traverse it. The first step is simply to install the required package:

apt-get install rdnssd

This package may have other dependencies, which should get automatically fulfilled, e.g. resolvconf)

rdnssd is a daemon program providing client-side support for DNS configuration using the Recursive

DNS Server (RDNSS) option, as described in RFC 5006. Its purpose is to supply IPv6 DNS resolvers

through stateless autoconfiguration, carried by Router Advertisements.

That pretty much sums it up. It’s just what we need here!

rdnssd parses RDNSS options and keeps track of resolvers to write nameservers entries to a

resolv.conf(5) configuration file. By default, it writes its own separate file, and may call an

external hook to merge it with the main /etc/resolv.conf. This is aimed at easing coexistence with

concurrent daemons, especially IPv4 ones, updating /etc/resolv.conf too.

So, we’ve installed it. What’s it doing? Straight after installing the package a ps -ef shows me that the process is running. I rerun my ping6 and nslookup (without specifying th IPv6 DNS this time) and tcpdump shows me no change: the DNS is still taking place over IPv4.

As mentioned at the start of thus sub-section, we have a problem here. A big, fat problem. We want this daemon to pick up our DNS server from the RA and use them. Which is fine. But check out the last para of the rdnssd man page:

When rdnssd uses a raw socket instead of the netlink kernel interface, it does not validate received

Neighbor Discovery traffic in any way. For example, it will always consider Router Advertisement

packets, whereas it should not if the host is configured as a router. When the netlink interface is

used, such validation is done by the kernel.

What that boils down to is that if we’re running as a router (and we are, since in /etc/sysctl.conf we have net.ipv6.conf.all.forwarding=1) the kernel will simply not pass the RA up to user-space at all. So rdnssd never gets the chance to see it, and thus never acts upon it. Which is a bummer.

Just to experiment, you can dynamically drop down to /proc/sys/net/ipv6/conf/all/forwarding and set it to ’0′. (radvd will bitch and moan, but ignore that.) Force a RA refresh if required, using rdisc eth0, and you will see rdnssd do its stuff and change the /etc/resolv.conf to point at the IPv6 servers. But we can’t leave it that way, alas. We’ve hit a bit of a blocker here – picking up the IPv6 DNS servers automatically from the ISP seems to not be achievable at the moment using rdnssd – the kernel’s policies for what is allowed and when prevent it.

So what do we do?

We now understand what we’re trying to do. We also understand how it should be doable. But currently there’s a blocker. What to do?

As always in such matters, there’s an easy, pragmatic way forward and a tricky, hacky way forward! The sensible path to take is very simple indeed. We know the IPv6 addresses of our DNS servers (and if we forget we can just do a rdisc eth0 to find them out again) The obvious thing to do it to statically configure them in to the existing /etc/resolv.conf and then, when we later use IPv6 from a device on the internal network, configure them there too.

That’s what I would recommend. That’s what you should do. You can specify a mixture of IPv6 and IPv4 name-server in the /etc/resolv.conf file. If you specify the IPv6 servers first, then all DNS on the system will (if available) use the IPv6 name servers. I suppose this does slightly violate still our desire to keep IPv4 and IPv6 separate (since IPv4 name resolution will now also use IPv6) but since it tilts the bias in favour if IPv6, with a seamless fallback to IPv4, I think I can live with that.

OK – but what about more wacky solutions?

One approach that would give us a partial solution would be to admit we were wrong originally, and instead of using radvd to propagate simple prefix information into our internal networks we should instead use a fully-fledged IPv6 DHCP server that can propagate addressing and DNS information. This would solve the problem of devices inside the network needing to have the IPv6 DNSs statically configured on them. However even this would not solve the root issue here: our inability to automatically pick up the IPv6 DNS information from received RAs when we’re configured to operate as a router.

The problem there is not, directly, rdnssd itself. The problem is the kernel. An architectural decision has been taken to stop the kernel sending RA DNS data up to userspace if the system is functioning as a router. Good or bad decision? Bad in my view. I can understand why it is sensible default behaviour, yes. But I do not understand why it’s been made unchangeable. But that’s how it is, for now anyway.

The solution I’m going to go for is to actually bypass the policing mechanism itself. The kernel only manages to stop the DNS being sent to userspace when userspace uses the Netlink mechanism to talk down. So why not just bypass that and get the raw data we want? This should bre easy enough to do, as rdnssd itself used to work this way, before the kernel started using Netlink to talk to userspace. So we might be able to build rdnssd to behave as it used to and get the data, right?

Hack and build rdnssd

The existing rndssd code makes provision for kernels with the netlink capability which causes us problems and for older kernels without that capability. So all the code we need is already in place. All we really need to do is change the default behaviour of rdnssd to the old way and we’ll be all set. One could of course do this properly and completely using command line options. Here’s what you might do in terms of changes to the rdnssd code-base:

Edit rdnssd.c

In usage(), ad a line such as:

”  -n  –no-netlink  use old method to pick up kernel notificationsn”

In main() drop in appropriate parameter parsing:

static const struct option opts[] =

{

{ “foreground”,         no_argument,            NULL, ‘f’ },

{ “no-netlink”,         no_argument,            NULL, ‘n’},

.

.

.

and an appropriate global:

bool nonetlink = false;

and then in the main parsing switch add:

case ‘n’:

nonetlink = true;

break;

Then finally up in worker() we act upon it.

Before we had:

static int worker (int pipe, const char *resolvpath, const char *username)

{

sigset_t emptyset;

int rval = 0, sock = -1;

const rdnss_src_t *src;

#ifdef __linux__

src = &rdnss_netlink;

sock = src->setup ();

#endif

if (sock == -1)

{

src = &rdnss_icmp;

sock = src->setup ();

}

.

.

.

Change it to something like:

static int worker (int pipe, const char *resolvpath, const char *username)

{

sigset_t emptyset;

int rval = 0, sock = -1;

const rdnss_src_t *src;

#ifdef __linux__

if (!nonetlink) {

src = &rdnss_netlink;

sock = src->setup ();

}

#endif

if (sock == -1)

{

src = &rdnss_icmp;

sock = src->setup ();

}

.

.

.

and we’re good. Build, install and use as before, but using the new cli parameter “-n” as required to force the old behaviour.

Attached is a version of rdnssd.c based off version 0.9.9 for reference.

For finishing touches, set up an rdnssd hook-file which puts the IPv6 nameservers first in /etc/resolv.conf, and then have the original IPv4 servers appended after them.

To recap:

• Here I covered a lot of ground, getting basic IPv6 running on a Linux gateway box connected to an ISP providing native IPv6, while remembering stuff like the need to set up a firewall.
• Here I looked at the issue of IPv6 firewall logging
• And here I looked at the need to set up a default route out of the gateway device pointing back towards the internet.

And what can I now actually do? Well……. from the gateway box I can ping out successfully to any IPv6 device on the Internet. In other words, logged in to the device in green on this diagram, I can ping out of eth0 over the Internet. And from an IPv6 device on the Internet I can successfully ping towards my green box, using the address of eth0. So I can ping from the Internet to (these are of course made-up addresses!) 123::456.

However if from my remote Internet location I ping instead the IPv6 address of eth1 (here 123::789) does it work? I might expect it to: after all, eth1 has a global IPv6 address on it, not a private address. So surely I can ping it?

Needless to say, as it stands I cannot. Here we look at why not – in the process covering an important element of turning our gateway device in to an IPv6 router (which, grand though it sounds, is exactly what we are doing here!) which receives very little coverage elsewhere on the Internet. In fact when researching this I came to a conclusion that the vast majority of folks who have dabbled with IPv6 in the domestic environment have terminated their ISP IPv6 connection on their workstation, and very few have gone the step further and used a device as a gateway to a home network!!

How to get through the gateway –  or Come back ARP, all is forgiven

So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, right? A quick trip to the shorewall6 log (glad we set that up, eh?) shows us: nothing. Nowt. Zilch. Nada. Surprisingly, we’re not dropping the ping. (In fact the firewall config we set up in the first of these articles contains enough already to allow, from a firewall perspective, for this ping to succeed.)

So we now run tcpdump on eth0 to see just what is going on. Here’s an example:

From the remote host

From my remote IPv6 host I do and see:

ping6 2a01:e35:8b25:7ea0::22

PING 2a01:e35:8b25:7ea0::22(2a01:e35:8b25:7ea0::22) 56 data bytes

From 2a01:e35:8b25:7ea0::1 icmp_seq=1 Destination unreachable: Address unreachable

From 2a01:e35:8b25:7ea0::1 icmp_seq=2 Destination unreachable: Address unreachable

From 2a01:e35:8b25:7ea0::1 icmp_seq=3 Destination unreachable: Address unreachable

.

.

.

Which doesn’t tell me a lot.

On the gateway

On my gateway, from tcpdump, I see:

tcpdump -i eth0 -v ip6

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

08:51:35.315038 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

08:51:36.315002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

08:51:37.315001 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

What does this tell me?

So the ping is reaching the gateway device alright. Sort of. Well, not really. But there’s something going on there! What we see in that tcpdump trace is the ISP’s router to which I’m connected is sending me a Neighbor Solicitation for the ::22 address (i.e. the global IPv6 address of my eth1 interface on the “far side” of my gateway which I’m trying to ping) While I’m not keen to draw too many parallels and comparisons with IPv4, it is useful to do so here: A Neighbor Solicitation is, at least as we see it here, pretty much analogous to a good ol’ ARP Request. The ISP is saying to us “I think this address is somewhere over with you – Please confirm and let me know how to reach it”. Which is great, except for the glaring fact that we appear to ignore this NS (Neighbor Solicitation) and hence the ping fails.

So you can guess we need to set something up on the gateway that tells it to reply to such a NS. (Kinda vaguely analogous to a Proxy ARP, if you’re familiar with that)

IPv6 Proxy

A couple of steps here. Firstly the system needs to be told globally to perform the required IPv6 proxying, and we then need to enable it for specific addresses.

proxy_ndp

In the /etc/sysctl.conf file add a line:

net.ipv6.conf.all.proxy_ndp = 1

To set this dynamically (without a reboot) you can also do:

sysctl -w net.ipv6.conf.all.proxy_ndp=1

Neighbor proxy

Then perform:

ip -6 neigh add proxy 2a01:e35:8b25:7ea0::22 dev eth0

Note that here the IPv6 address is the address of the interface on the private side of the gateway (eth1 for me). The end part “…dev eth0″ is to say “Proxy that address from this interface”.

You also, of course, will need to make such configuration permanent. Numerous approaches to that: I settled upon adding this from the interface-up scripts in /etc/network/if-up.d/ but there are so many other methods too. Pick yours.

(Interestingly, I have yet to discover any way at all to display the list of proxied neighbors added in this manner! I’ve looked pretty hard, but there appears to be no way I can find to have them listed. There must be a way, but I can’t find it.)

Success!

And the ping now works, with a tcpdump like this now showing to us:

09:18:18.644817 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

09:18:18.868550 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::240:63ff:fef5:f93c > fe80::207:cbff:fea5:1a68: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a01:e35:8b25:7ea0::22, Flags [solicited]

destination link-address option (2), length 8 (1): 00:40:63:f5:f9:3c

09:18:18.868958 IP6 (hlim 56, next-header ICMPv6 (58) payload length: 64) ipsi6 > 2a01:e35:8b25:7ea0::22: ICMP6, echo request, length 64, seq 5

09:18:18.869107 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:e35:8b25:7ea0::22 > ipsi6: ICMP6, echo reply, length 64, seq 5

Which has 4 elements:

1. The same sort of Neighbor Solicitation we had previously.
2. This time we send back a Neighbor Advertisement for the ::22 address
3. With that done, the ping itself can come to us (the ICMP6 echo request)
4. And we of course respond to the ping with ICMP6 echo reply.

Conclusions and summary

In the world of IPv6, with no ARP or NAT, life is different. Devices which in IPv4 are thought of as private (both in terms of addressing and functionality) are now, at least from the perspective of addressing, public. We need to make sure that if we want “The World” to be able to reach them, we must in turn tell the world about them. Hence the need for IPv6 neighbor proxying. And, thinking ahead a little, the need to take our firewalling ever more seriously. If I make the addresses of a “private” workstation globally reachable I’d better make sure that it’s protected…

The last point to make is about scalability: do we really need to add an “ip -6 neigh add proxy” for each private device we wish to be able to reach from the Internet? If there are only a few devices (as in the typical home network) then it may well be easiest to do this. However in situations where the private side of the network has many IPv6 addresses which need to be globally reachable, other solutions may be more appropriate and manageable, but will not be covered here. Here we’re trying to get a small home network IPv6 enabled, not migrate a corporation to IPv6. If you really want to get in to the area of automating these functions you need to read up on implementations of Neighbor Discovery Protocol,  look at “zeroconfig” networking, Apple’s Bonjour service, and so on..

There will come a time when such automation will be required at the domestic level, with the eventual proliferation of networked devices. But for now we keep it simple and statically configure the required addresses.

All of this has, so far, made use only of one network interface (in my case eth0) to set things up. However looking ahead to the next step I am aware that I will want devices inside my network (i.e. my workstations, etc.) to have IPv6 connectivity through this device I am setting up. In other words, this device must, as it does today for IPv4, act as a router.

With IPv4 this is, at a basic level (so forgetting about firewalling and so on) very easy: enable IPv4 forwarding and away you go.

For IPv6? A little more complicated…

sysctl.conf

My first step was to jump in to /etc/sysctl.conf and, just as I have IPv4 forwarding enabled here, do the same for IPv6. There’s even a (likely commented out) entry already there to help you. So I change it to show:

net.ipv6.conf.all.forwarding = 1

Reboot (or if you prefer manually involve the same change via sysctl or simply dropping the value in via /proc/sys/) and it takes effect.

Why has it all stopped working?

After doing this, the first thing I noticed was that suddenly I could no longer ping6 to my test destination. I find that the default route has disappeared from the route table (ip -6 route show)

It turns out that once the device is defined to be a router (i.e. that IPv6 forwarding is enabled) it stops acting on received Router Advertisements from the ISP, arriving on my WAN link eth0.

I was pretty miffed at first, but of course on reflection this is entirely sensible behaviour – I do not actually know who is sending me a given router advertisement. I have no knowledge of how the ISP has built its IPv6 infrastructure, and while I would hope that only the ISP can send an IPv6 Router Advertisement towards me, maybe not? What if someone else manages to do it too?

That’s why an IPv6 router, even in this context, as a home gateway, needs to treat a Router Advertisement with care!

What to do?

With IPv6 forwarding enabled it is possible to allow the RA to be accepted. In sysctl.conf set:

net.ipv6.conf.all.accept_ra = 1

However this then permits the interface(s) to autoconfig so far as addressing is concerned, but still does not pick up a default route. There is also a sysctl of net.ipv6.conf.all.accept_ra_defrtr which could be useful (if you trust your RA in the first place, that is) but anyway I could not make it work as I’d expect.

So really it comes down to making sure that, once IPv6 forwarding is enabled, that a default route is manually defined. Something along the lines of:

ip -6 route add default via fe80::207:cbff:aaaa:bbbb dev eth0

seems to do the trick
Of course the difficulty here is how you obtain the address of the required gateway. My ISP had not told me what it was. I obtained it by looking at what the default route had been prior to enabling IPv6 forwarding. Of course I could also have simply run tcpdump -i eth0 ip6 and waited for a to show up.To make this permanent, a suitable line can be added to /etc/network.interfaces, so mine now looks similar to:

iface eth0 inet6 static
address 2a01:e35:8b25:aaaa::1
netmask 64
gateway fe80::207:cbff:aaaa:bbbb

So with IPv6 forwarding enabled and a default route successfully restored, we can now proceed.

With IPv6 slowly becoming more visible, it was time to get to grips with it. While absolutely not essential (yet!) it seemed like a fun idea: my ADSL provider offers native IPv6 in parallel with IPv4, and my hosting provider is running an IPv6 beta. So I can do native IPv6 end to end between my home and a remote host. “Home” in this case consists of a Linux firewall running iptables, fronted by shorewall. Two ethernet ports: one to the ADSL modem (my “external” interface) and one to the house infrastructure (“internal”)

The Ubuntu server distribution in use is, like most Linux distros, fully IPv6 ready. For example, do an ifconfig and we see

Now I may not know much about IPv6 on Linux yet, but I can see that I’ve got a line beginning “inet addr” which looks kinda IPv6-ish. Good start. Let’s go…

IPv4 – today

As it stands, my home firewall performs the following functions:

• It acts as a DHCP client on its external interface, in order to pick up from the ISP the IPv4 address, plus the DNS server(s) being offered. In fact my IPv4 address is fixed, so strictly speaking I don’t need to act as a DHCP client on this interface, but it’s no real effort to do so and it means I get the DNS servers automatically.
• It acts as a DHCP server on its internal interface, in order to supply IP addresses to the many and various client devices within the house, along with DNS information. (I actually use dnsmasq for this purpose – tremendous piece of software)
• It performs NAT between the internal devices and the Internet, courtesy of iptables.
• It acts as a firewall between the internal devices and the Internet, again courtesy of iptables.

Since no one in their right mind writes “raw” iptables configs of any complexity, I use shorewall to administer the NAT and firewall functions – mostly using the shorewall cli, sometimes using the shorewall GUI within Webmin.

To top things off, I also have a VPN tunnel running between the firewall and a host machine, using OpenVPN.

So what do I need to know even before I think of starting with IPv6?

So as far as I know all the raw elements are available to me: ISP support, host support and all the bit ‘n bobs that Linux offers. So how do I string them together? In fact, hang on a sec before that: Just what is my goal?? The engineer in me frankly just wants to have a damn good play with IPv6, but it’s still good to have an initial goal to provide some sort of framework and direction.

Hence I set myself the somewhat arbitrary goals as follows:

• Between my firewall and my remote host enable simple IPv6 connectivity. ping, ssh, etc.
• Between my firewall and my remote host enable VPN connectivity (i.e. shift the existing IPv4 tunnel to IPv6)
• While leaving the rest of the household blissfully ignorant (and hence unaffected) by IPv6, enable two specific workstations (one Windows, one Linux) to have dual IPv4/IPv6 stacks such that they default to using IPv4 except for traffic destined to the remote host or some other IPv6 end-point, which will go IPv6 end-to-end (i.e. workstation <–> firewall <–> host)

Note that there are a lot of things that I am not yet trying to do. Specifically I am not setting up any gateways to allow IPv4 <–> IPv6 inter-working. For now I will have all my existing IPv4 functionality, with an entirely optional layer of IPv6 for those clients who (a) can talk native IPv6 and (b) have an IPv6 end-point to which they wish to connect. The inter-working side of things is a level of complication that in the first instance I want to avoid. Start simple and build up.

IPv6 Basics

Before anything else there are some IPv6 “basics” that need a little explanation and clarification. As with any technology, the problem is not with finding information. The problem is with finding out which information is useful and which is entirely irrelevant.

IPv6 Addresses

The one thing everyone knows about IPv6 is that it’s got funny looking, and rather large, addresses. Where once we had stuff like good old 192.168.0.1, now I might have fe80::240:63ff:fef5:f93c/64. And that’s one of the shorter ones…!

So what do I really need to know about IPv6 addresses, leaving aside the stuff that’s not required? Here goes.

IPv6 addresses consist of 128 bits. Why? Simple: to provide enough addresses that we’re not likely to run out, as we are perilously close to doing with IPv4. Just how big is “128 bits”? In decimal terms, such numbers have up to 39 digits. Here’s one:

340282366920938463463374607431768211455

In order to make things more manageable, IPv6 addresses are not written as long, decimal numbers. Instead they are written in hexadecimal, broken up in to 16-bit fields by colons. Here’s an IPv6 address lifted from the official IPv6 HowTo:

2001:0db8:0100:f101:0210:a4ff:fee3:9566

To further simplify things, leading zeros can be omitted. Also, contiguous blocks of zeros can also be omitted. For example:

2001:0db8:0100:f101:0000:0000:0000:0001

can be reduced down to

2001:db8:100:f101::1

The most extreme example of this is when the localhost address is considered (analogous to IPv4′s 127.0.0.1) and can be condensed down from

0000:0000:0000:0000:0000:0000:0000:0001

to

::1

Note, however, that the use of ‘::’ and leading-zero suppression is purely a shorthand. All IPv6 addresses are 128-bits in length – these are just cosmetic tricks to make the writing and typing of them a little more friendly.

Just as IPv4 addresses have netmasks, so with IPv6 addresses. More of that when we look specifically at routing later on.

Also, normally we find that the upper 64 bits are considered to be “network” bits and the lower 64 bits are “host” bits.

Network bits

The leading 16 bits of the network portion of an IPv6 address are “special” in so far as some values are reserved as having special meaning. I am not here going to define all the possible values in use. I am confining myself to what matters within the context of the exercise at hand. And for those purposes the two values might be seen.

Local link addresses prefix

fecx (where x is any hex digit, but is normally 0) – Such addresses are local link addresses. Under Linux, when an IPv6-capable interface is enabled, such an address “automatically” appears. It is used solely to talk with other devices on the same link: hi, anything there? anyone looking for a router? Note that such addresses are not used for “normal” data – they are purely for local link management. And now we know where that IPv6-looking address came from in my original ifconfig command:

inet6 addr: fe80::240:63ff:fef5:f93c/64 Scope:Link

(and notice that friendly Linux even puts the “Link” there to remind you that it’s a link address)

Host bits

The bottom 64 bits of an IPv6 address are, essentially, whatever you want them to be. They can be manually defined or, more often, are computed by using the interfaces MAC address (if it has one).

So here’s a simple enough address:

2001:0db8:100:f101::1

Given the 2001:prefix, so we know it’s a global unicast address from an ISP. And the bottom 64 bits consists of just ’1′ (all the zeros are magic’ed away by the ‘::’)

But what of this “computed from the MAC address”? Recalling the ifconfig I showed back at the start:

Note the hardware MAC address: 00:40:63:f5:f9:3c (and remember that those digits and colons are nothing at all to do with IPv6 notation – they are bog-standard, traditional L2 MAC address format)

What have we got? The interesting parts break down as follows:

1. The interface has a L2 MAC address of 00:16:3e:2e:50:36
2. The IPv4 addressing is as it always has been – No change there.
3. We have a Link address of fe80::216:3eff:fe2e:5036 which should now look familiar: the fe80: prefix and the appearance of the L2 MAC address.
4. And we now have a Global address of 2001:4b98:41::d946:bf36:54 which is familiar at least in so much as it has a prefix of 2001: The rest of the address’s derivation is not of direct concern here. (In fact, after the ISP-specific part, other elements of it are derived from VLAN addresses and other such stuff. No matter.)

Goodbye ifconfig, hello ip

Since time immemorial Linux users have been familiar with the command ifconfig. Thus far in this document I’ve used it too, for the sake of familiarity. But dear ifconfig has actually been deprecated now for many years. It lives on, and we all still use it, but with the advent of IPv6 it does now seem an appropriate moment to bid it goodbye. It’s time to use the ip command, in its many forms. While it’s true that ifconfig can still achieve most of what is required, it sometimes falls short. Also, using ip let’s us more clearly and easily distinguish between IPv4 and IPv6, which is maybe not a bad thing!

Compare the ifconfig output from above with a couple of examples of the ip command:

This is analogous to the simple ifconfig: we’ve got L2 MAC, IPv4, and a couple of IPv6 addresses showing.

Look how much neater that is, even just for IPv4: no L2 MAC, no IPv6, just the IPv4-related information.

And similarly here: we just get IPv6-related information, and nothing else.

alias ip6=’ip -6′

and then you can just enter:

which is quite neat.

Key subsystems

The last part of this IPv6 Basics section is to introduce the functional building blocks within Linux which seem to get mentioned in connection with IPv6.

We now know about IPv6 addresses types that matter to us, we have met the command(s) we will use to inspect and manipulate things such as interfaces, routes and so on. We have also assumed that there is something similar to IPv4 iptables (and we’ll come back to that in some detail later as to how we actually use iptables under IPv6). However what subsystems such as DHCP exist and are of interest to us? When reading up on IPv6 Linux implementation one comes across the following mentioned frequently, and you may quickly form the impression that they are three important elements in an IPv6 firewall/router. They are:

• dhcp6c
• dhcp6s
• radvd

dhcp6c

dhcp6c is a Linux DHCP IPv6 client. It is directly comparable to the IPv4 dhclient or dhclient3. It will, for a nominated interface, call out and ask for an IPv6 address which it can allocate to that interface. It may also, optionally, pick up other information, typically DNS-related.

dhcp6s

dhcp6s is a Linux DHCP IPv6 server. It is comparable to the IPv4 dhcpd or, in my network, dnsmasq. Just as in the IPv4 environment, it hands out addresses to other devices and, optionally, other information such as DNS data.

radvd

radvd is a Router Advertisement Daemon. This is less easy to directly compare to the IPv4 environment. It can hand out, to requesting devices, an IPv6 prefix (not a full address…) and a default route to be used. From this the receiving device can then automatically decide upon a host portion to add to the prefix to give it a full IPv6 address. So at first sight, it seems to be a rather inadequate imitation of a DHCP server!

One might very easily conclude that all three are required. After all, we may well use a DHCP client on the Internet side, and a DHCP server for the private network sounds pretty much essential. And a router advertisement daemon? Not entirely sure what it is, but gets a lot of mentions so I probably need that too! In actual fact the only one of these you are likely to need is readvd. You might need any combination of them, depending upon your precise circumstances. But probably not.

DHCP client I get, but what’s with DHCP server versus radvd?

This is an area of considerable confusion! When bouncing around Google trying to find information on setting up IPv6 one minute we appear to be required to use DHCP server, the next minute we appear to need radvd. Which is which and when do I use them? Do I need both?

Well, the answer to the last question, “Do I need both of them?”, it “Probably not, but you might…”

Coming from familiarity with the world of IPv4 one instinctively tends to feel comfortable with the concept of dhcp6s – and while it can be used, radvd may well be simpler and easier in practice. Or, maybe, both… The attraction of rad is that the server does not need to concern itself with any state: no records of addresses allocated – since it dos not allocate any. It just says “Hey, this is the prefix, work the rest out for yourelf.” which is attractively simple! The DHCP server alternative has to remember which address is where and when. The case where you might want both would be where you want to have rad handle the job of initiating address allocation, and then have DHCP pick up to add some icing on the cake: DNS information being the common case.

And us here? We’re going to go with the simpler case, and have radvd handle the job of responding to IPv6-capable devices within our internal network and tell them just enough to allocate addresses themselves and use a default route.

So it actually seems to come down to a pair of subsystems being required:

• dhcp6c talks out to the ISP to handle “outside” IPv6 addressing.
• radvd talks internally to all devices to handle “inside” IPv6 addressing.

Well, maybe… But in these early days of IPv6 there is far from a standard view of how these things are to work. And, as I discovered, your ISP may not actually themselves offer an IPv6 DHCP server at all! In my case that was the situation, although I have little doubt that as time progresses and IPv6 implementations mature such services will become more standard.

But for now, my implementation will be reduced down to simply running radvd on the firewall, with the IPv6 configuration on Internet side being handled semi-statically.

Just one subsystem to be used: radvd. No DHCP client. No DHCP server. Who said IPv6 was complicated?!?

Setting up the firewall box

So at last we get to the actual practicalities of getting IPv6 up and running on the home firewall. The system in question is a Ubuntu-based device. The differences for another Linux system should be fairly negligible (package names maybe, some config file locations, etc.)

Packages to install

All we need to install is radvd if its not already present. Under Ubuntu something like:

sudo apt-get install radvd

should do the job.

Careful now….

And already we come to potentially our first issue!!! Once radvd is up and running on the firewall it will, potentially, start chatting to devices on the home network which are, by default, on the look out for IPv6 routers. Whether it does this by default depends upon the installed configuration file used, and which interface points where, but it’s a real possibility. And that may not be entirely a good thing. Be on the look out for workstations suddenly getting really really slow when, for example, browsing the web. I would suggest disabling IPv6 on any devices which may be susceptible to it. There are numerous ways to do that. On Windows in all its flavours? I have not the faintest idea. Under Linux? Here are some suggestions. Depending upon what is on your home network this may not be required, but if you do run in to the “slow web” issue, be alert to it.

Technical note: for the curious, if you do hit the IPv6 crawl of death issue, it’s actually due to certain services on clients stations being IPv6 aware and thus trying to resolve DNS requests via IPv6. They try, take an age to fail, and eventually fall back to IPv4. But it’s ugly. I wish I could say that I foresaw the issue and planned accordingly. More truthful would be to say that during my diddling around with radvd I got loud complaints from another user on the home network…

Setting up the connection towards the Internet… no hang on, actually not yet…

The first task is to get the public (in my case eth0) interface up and running IPv6. Before actually doing that we need to pause for a moment and consider the implications of what might happen if we indeed succeed in bringing up the IPv6 ISP-connected interface! We are then wide-open to the world, and just asking to be attacked. The only sensible thing to do is to first set up an IPv6 firewall to provide some level of protection before we throw ourselves open.

Sorry. But that’s life. Of course if your public-side connection is already protected via some firewall, then you can skip this. But it probably isn’t, so pay attention. With IPv4 most home networks make use of, by necessity, NAT. While not done for reasons of security it does nonetheless provide as a side-effect a modest level of security in so far as it tends to block unsolicited incoming connections. So even with a poorly configured firewall under IPv4, the use of NAT hides a multitude of nasties from us. But in the brave new world of IPv6 one hugely important difference from IPv4, but one that everyone seems to gloss over, is that NAT is not required. And indeed since not required, it does not exist. All IPv6 devices on the “inside” network will have, in effect, public addresses. No port-forwarding, no NAT, none of that. And while that’s actually a very refreshing thing in general (NAT and large firewalls are a real pain) it does means we can no longer rely on the default level of safety that NAT provides. A tightly configured firewall is absolutely essential.

To drive IPv6 iptables I use shorewall6. I highly recommend it. Here I am going to run through, without too much explanation, the steps to set up a very basic “block almost everything except a bit of stuff for testing” IPv6 firewall on the system. Here goes.

Install the package:

apt-get install shorewall6

The basic level of configuration then has to take place. Navigate to the configuration files:

cd /etc/shorewall6/

Set up the following files in a similar manner as shown here:

rules
# Allow only ping – for testing

Within shorewall6.conf ensure these lines as as follows:
.
.
.
STARTUP_ENABLED=Yes
.
.
.
IP_FORWARDING=Keep

What we have there is a minimal firewall configuration, which blocks absolutely everything except pings to and from the firewall box itself.

Start up the firewall with e.g.:

/etc/init.d/shorewall6 start

And then

shorewall6 show config

should give you a pretty lengthy IPv6 iptables config.

So, with precautions now in place, we may proceed.

[EDIT: shorewall6 and logging may or may not be an issue... See my article here: http://www.ipsidixit.net/2010/02/25/231/]

OK, finally setting up the connection towards the Internet…

Here is the starting point, with an automatically assigned, MAC-derived, link address:

Configuring the addressing

My ISP is free.fr (a French ISP) From them I have a fixed IPv4 address and a fixed IPv6 address. My IPv6 address prefix is 2a01:e35:8b25:7ea0::/64 which looks pretty random but of course is not.

The part 2a01:e3 is, from previous knowledge, a global unicast prefix (the 2xxx: indicates that) and the full form 2a01:e3 is the RIPE-allocated prefix used by Free. The next part, 58 b2 57 ea? Well, I write is deliberately in that format to show that it breaks down to (decimal): 88 178 87 234. This, by no coincidence at all, is my current IPv4 address! Of course Free mapping subscribers’ IPv4 addresses into their IPv6 prefix is entirely arbitrary on their part. It indeed seems like a good idea, but is absolutely not required. In the future, for example, IPv4 addresses will not be used in the first place, so no such mapping would be possible.

Of course their network prefix is, as per standard IPv6, 64 bits in length. So the second 64 bits (the host portion) is entirely mine to use as I see fit. That is a seriously large amount of address space, all globally routable, and all entirely mine to use as I wish.

Since my ISP themselves run radvd (or some equivalent) on their routers, when everything is IPv6 enabled on my firewall system, the Internet-facing interface, eth0, should automatically pick up the required prefix and use it. However in addition to the ISP-prefix + MAC-derived host portion I also want a simplified address on the interface. It’s absolutely not required, but I want it to make my life slightly easier.

So prior to the reboot I edit

/etc/network/interfaces

and add a section as follows:

With this I am specifying that in addition to any automatic address the interface picks up, I also want to statically assign a PREFIX+::1 address to the interface.

After the boot I inspect the results and see:

Excellent! We see the link address that was there previously. And now we have two global addresses. The one marked dynamic which is clearly the MAC-derived address (notice how the prefix is as expected – this was picked up not from any of our config but from a remotely received router advertisement from the ISP) and the one marked tentative which is as manually configured by me.

Testing

When we set up the shorewall6 firewall, everything was marked as blocked except for ipv6-icmp. Ostensibly this was to permit what we are about to do now, a ping test, which makes use of ICMP. However it was also in the knowledge that the Router Advertisements which we picked up from the ISP, and which gave us the prefix to be used for the dynamic address, are also, coincidentally, ICMP6. Two birds with one stone: we allow pings to go in and out, and also allow IPv6 Router Advertisements to pass unhindered.

So, to test our interface, let’s try something:

It works!!

Which is great, but where’s the routing and so forth that is being used here? Let’s look at that too:

That’s kind of like our IPv4 ARP table: where is, in Layer 2 terms, the next hop? And we see it at the given link address, with a corresponding MAC address, and a marker of REACHABLE. That REACHABLE can change as entries get set up and then age out, and values such as DELAY or STALE might also be seen.

Note that the default route is, automatically, via the adjacent router we learned about from the router advertisement.

.
.
.

So at this point we now know that we have basic IPv6 connectivity in and out of the firewall.

Summary

What we’ve done here, after a quick recap of IPv6 addressing techniques, is to:

In the next part I will look at extending IPv6 inside the private network, and examining options for moving the VPN to a native IPv6 implementation.

The judge said “You are a religious man and you know this is not acceptable behaviour.”

The fact that the judge in question is Cherie Blair, wife of former-prime minister Tony Blair, just confirms that this couple appear able to justify almost anything in their own minds based upon their beliefs and superstitions.

Apparently the UK’s National Secular Society has complained about it, but in true British don’t-kick-up-a-fuss tradition not much more will happen.

So remember: before violently assaulting someone in Britain, say a prayer. No, not to ask for any sort of forgiveness for what you will do, just pray that you get this lunatic women as your judge afterwards.