If you have a Linux gateway router terminating your ISP feed supporting IPv6, this may be just what you need. To summarise the problem it solves: your ISP has given you an /64 (or some [...]]]> As per previous posts and discussions, my project to develop npd6 (Neighbor Proxy Daemon 6) is now advancing very rapidly.

If you have a Linux gateway router terminating your ISP feed supporting IPv6, this may be just what you need. To summarise the problem it solves: your ISP has given you an /64 (or some other size) IPv6 prefix, with the last 64 bits (or whatever) entirely for your own use on a private-side of the network. The IPv6 addresses in use by your own devices may well not even be known to you – it’s possible that you use DHCP6 to statically pre-allocate them (yuck!) or more likely you are using radvd on the gateway to advertise the ISP-supplied IPv6 prefix and let the devices themselves choose what they wish to tag on to that. It may be vaguely predictable (based upon the device’s Ethernet MAC address) or totally unpredictable (as per the Windows 7 box I looked at the other day!)

For these devices to be able to reach the outside IPv6 world, there is a good chance that your ISP will use the ICMP6 Neighbor Solicitation mechanism – and your gateway needs to play along. Other articles on this site go into painful details about this mechanism, so let’s sum it up as: in a very vaguely similar way to IPv4 ARPs, a device may receive an IPv6 Neighbor Solicitation for a specific global address and, if it knows how to reach it, respond with a Neighbor Advertisement. So for example, your ISP has given you the global prefix:

AAAA:AAAA:AAAA:AAAA:

and your home devices thus all end up with addresses using this prefix plus a variable suffix, of the form:

AAAA:AAAA:AAAA:AAAA:BBBB:BBBB:BBBB:BBBB

So the Windows workstation which has chosen the 128-bit global address AAAA:AAAA:AAAA:AAAA:BBBB:BBBB:BBBB:BBBB tries to connect to ipv6.google.com. Out goes the connection, and when the response comes back, the ISP’s router says to your gateway: “Neighbor Solicitation: Do you know how to reach AAAA:AAAA:AAAA:AAAA:BBBB:BBBB:BBBB:BBBB?”

And you want to say back “Neighbor Advertisement: Sure, AAAA:AAAA:AAAA:AAAA:BBBB:BBBB:BBBB:BBBB is known to me – send me his traffic.”

And to do this today you need to statically pre-configure that full address into the Linux system. And if it changes, you need to change it. And if a new one appears, you need to ad it. And so on. Oh, and to add insult to injury, you cannot even display a list of which ones you have already configured in the system!!

And thus I offer npd6 as a solution: it runs on the gateway, and requires little configuration. You tell it your prefix and which is the ISP’s interface. There are a few optional knobs and levers. Then it runs and automatically responds to any Neighbor Solicitation received from the ISP for a device with your prefix.

Status

The code today is working well. It is easy to build on any typical Linux system. Soon I will package it and offer .debs, RPMs etc. It is highly efficient and low-impact in terms of CPU an so on.  Also, extensive debug options are built in, to assist if any problems occur.

To get it, please visit the GoogleCode hosting site at: http://code.google.com/p/npd6/ and specifically the code at: http://code.google.com/p/npd6/source/checkout (Subversion) or a tarball at https://code.google.com/p/npd6/downloads/list

If you want to try it out, please do download and build it. If you need help, please ask! Feel free to raise issues via: http://code.google.com/p/npd6/issues/list

Good luck!

EDIT: 22 July – The project has really taken shape. Version 0.3 is now useful enough to be considered a working beta version. Building is very simple – do please try it out [...]]]> As threatened in article IPv6 neighbor proxy daemon – npd6 and the associated design ramblings here, the npd6 project now lives and breathes.

EDIT: 22 July – The project has really taken shape. Version 0.3 is now useful enough to be considered a working beta version. Building is very simple – do please try it out and let me know of any issues, good or bad.

It’s absolutely early days, but, with plenty of limits and as-of-yet-unknown bugs, it does work…

I’m hosting it on Googlecode. It’s here. For a while yet I’ll not be making any binary or packaged versions available, or even autoconf/configure shenanigans – strictly source + Makefile.

If you want to give it a spin, do feel free. It’s going to change a LOT – we’re probably a month or so away from something I’d call “a usable, early beta“. Today it’s a “works for me pre-alpha“!

EDIT: 22 July [...]]]> I admit defeat… You know how it is: you’re searching for a solution to a technical problem, and you KNOW that someone else has had the same problem. In fact thousands of people have had the same problem. And it was fixed years ago. If I can just find that solution…

EDIT: 22 July – The project has really taken shape. Version 0.3 is now useful enough to be considered a working beta version. Building is very simple – do please try it out and let me know of any issues, good or bad.

And find it, eventually (Google, Bing et al – Thank You!)  you do.

Except when you don’t. Back in this post I wrote about a specific, but key, problem in implementing an IPv6 firewall/router on a Linux box, when attached to a “normal” ISP.

What was the problem?

In a nutshell, it was as follows. My ISP gives me a full IPv6 service, with a staticically allocated (i.e. fixed) global IPv6 address. They give me a /64, so I in turn have a full /64 to play with in my private net. Enough to network every dust particle in the house. (And this is one dusty house).

As I found, not surprisingly the ISP does not let me advertise address space back to them regarding which devices in my private-but-globally-addressed network actually exist. Given that, I rather naively hoped that they would thus blindly forward anything that was addressed to my (global prefix + private part) network to me regardless, and treat my gateway device as, in effect, a sort of default route for my IPv6 prefix.

Could you give an example?

Sure. Say my ISP has given me the IPv6 prefix of 2a01:e35:8b25:7ea9:… A device inside my network then, by the magic of radvd, gets an address of, say: 2a01:e35:8b25:7ea9:1111:2222:3333:4444.

(If you need a primer on this stuff, read all about it here!)

Then assuming all the other myriad options are set up right, from that inside device I do a test ping6 of ipv6.google.com. And it fails.

As per my earlier article, it’s all down to my ISP, when they get traffic from the remote host (in fact in this case the ICMP6 echo reply from Google) destined for 2a01:e35:8b25:7ea9:1111:2222:3333:4444 rather than just “knowing” that such a global address must, by definition, be behind my connection, they go to the irritating lenghts of instead doing the whole Neighbor Solicitation dance with me.

And I find that unless I have performed the following command on my Linux gateway:

ip -6 neigh add proxy 2a01:e35:8b25:7ea9:1111:2222:3333:4444 dev eth0

the gateway device will not reply to the neighbor solicitation. And hence nothing works.

OK, does it matter much?

Heck yes.

1. Each inside device must be statically configured on the gateway.
2. It is currently not possible (I know this seems implausible…) from user-space to list or show what devices you have configured in this way.
3. The biggie: if you are dynamically allocating addresses in the network, you will not even KNOW what the end-point address is.

Item 3 is in large part a consequence of using radvd. But even if one used (at the cost of a lot more work) an IPv6 DHCP server, you still have to statically pre-configure the end devices addresses on it, and lose the ability to add devices on-the-fly.

So we have a real stumblin block. Sure, for test purposes I can dig out the IPv6 address which my end station has picked, and bang in the neighbor proxy command on the gateway. And it works fine.

But in terms of manageability and scalability it’s a freakin’ disaster.

Must be easy to fix, surely?

Well if it is, no one I’ve spoken to has any idea! It’s a great, glaring black-hole. IPv6 on Linux simply currently appears to have no support for automating the proxying of global/private addresses using the Neighbor Solicitation mechanism. I can only assume that it was never thought this would be a problem, and Neighbor Solicitation would only ever be used to directly connected devices.

The ability to force a neighbor proxy as shown here is pretty obviously an after-thought. The real give away is the inability to list current defined proxies…

So what we gonna do?

I intend to fix it!! I’m going to use the article linked to HERE as a working document to put together a rough and ready design for a user-space daemon to fix this. It’s going to be simple to use – that’s key.

The main elements I can think of as a start are as follows:

1. Run in user-space (I hope!)
2. Have a single, simple config file.
3. To have no prior knowledge of devices inside the networks.
4. Only prior knowledge, via static config, is the IPv6 prefix.
5. If a neighbor solicitation is received for our prefix, regardless of the suffix, we respond positively.

Easy? No idea! I’m a useful enough network programmer but not at all familiar with the Linux IPv6 stack from the code perspective. But the functionality is, conceptually, not complex.

The key gotchas I forsee are:

1. How we hook incoming neighbor solicitations. Period.
2. Then as per (1), but now with the “I want to run in user-space” goal.
3. What I do when someone points out (and they will…) that I’m going to violate several dozen RFCs by doing this.

Piece of cake. As per above link, the working design doc will be here. Very soon. All contributions welcome – and I really do mean that!

The daemon needs to receive incoming neighbor solcitations from a designated port(s). I currently have no idea if this is an easy hook to make [...]]]> So what must npd6 do in functional terms?

• See Neighbor Solicitations.
• EITHER respond to them directly
• OR respond via the existing mechanisms.
• Log activity.
• Report status.

Receive Neighbor Solicitations

The daemon needs to receive incoming neighbor solcitations from a designated port(s). I currently have no idea if this is an easy hook to make from user-space or whether we need to hook much lower. Kernel module? iptables? Main area for investigation this one!

Act upon Neighbor Solicitations

OK, so we receive an NS. What do we do about it?

Validate

First off, we validate it to a small degree. Likely scenario here is that in a conf file we have defined out static IPv6 prefix (in my scenario this will be 64-bits) We check it matches that. Likely in the conf we also want options to either explicitly include only defined addresses (ranges?) as valid (i.e. define valid suffixes) and/or exclude certain addresses/ranges?

Action

Key decision to be made is in what manner we act to a valid NS. The obvious two approaches are to either respond directly ourselves or instead to use the existing kernel mechanism to, in effect, add the address via the “ip -6 neigh proxy add…” command.

Pros and cons? Currently I have no idea how easy it is to spoof out a response. If easy, do I want to bother, when there’s an existing kernel mechanism do do so? So using that existing mechnaism seems attractive. We then, however, face the issue of how to manage the proxied addresses via that mechanism. Have we already added it? Should we check? Or blindly (re)add it? If we are to be stateful about it, how do we handle a restart situation, since I currently do not know how to get the kernel to cough out the current state of proxied addresses…

Needs a little investigation.

Logging and info

Pretty much goes without saying that we want our daemon to log meaningful data. Also optional debug logging.

And if we’re going down the route of using the existing kernel neighbor proxy mechanism, then we would also want a feature to signal the daemon and have it spit out the current state of neighbor proxying.

9 June

So my first steps here will be to dig around the kernel code currently handling NS. Get the feel of what’s going on there and see how it looks. Will update back here with impressions.

Update 1:

Just started having a read of the radvd code. I note that it appears you can open a socket to hook ICMP6 messages, which is highly promising if true! Since NSs are ICMP6 it would make a really neat, easy, user-spacey way to integrate with them. Have to look more closely at the code. Also need to think about whether you could do this in parallel with radvd doing it too. Still, at least it’s a line of investigation to follow.

14 June

Just a brief update: I put together a skeleton npd6 prototype/framework with which to investigate. Did the dull part, setting up an environment for parameters, simple logging, debug, etc. Can now start really looking at the interesting bits.

16 June

So spent a lot of time looking at how netlink and IPv6 biff along together in Linux. Turns out the answer is: not so well! Reading the radvd code had given me false optimism, as it does use netlink to hook router advertisements. However the summary seems to be that netlink and IPv6 are only really fully developed for IPv6 ICMp routing messages, and hence doesn’t seem to let me extend things to e.g. neighbor solicitations as we need.

So out of that blind alley, and back to good ol’ raw sockets. I can now happily hook any and all IPv6 ICMP and read the message. I don’t actually DO anything useful with it yet, but that’s no big deal. That fact that I can reliably (?) receive IPv6 ICMP in my user-space daemon is fine so far.

Next? Extend the processing of those received messages: spot the ones I’m interested in and decode them into debug logs.

23 June

OK, this rocks! The radvd code is an excellent crash course in IPv6 ICMP packet handling. LEarned a lot about how best to play the cmsg, iovec, mshhdr chain-game. Gave myself a headache in the process, but it’s good stuff. So my prototype is almost doing something useful now: it receives all NS sent to the gateway, and can compare their target against the user-defined prefix. If the target and prefix match up to the full prefix length it moves on and replies. The logic is very simple at this early stage: we don’t filter out, white/blacklist, etc. If the target matches the prefix, we’re going to respond. At the moment the bulk of NSs I receive on this device are actually for the interface’s address itself, so the box anyway NAs them in return. So for now, we’ll send an extra (dupe) NA for these. Obviously that would not be the long-term behaviour, but for now no harm -ICMP is stateless, and a dupe response is no big deal. Also, as a fun extra, it lets me benchmark my code by measuring the delay between the kernel-generated NA reply and my daemon reply!!

The NA I send back is almost right. Few fields and bits I need to understand a bit more, but this daemon is almost ready for alpha!

Anyone fancy testing it soon….? (I’ve a colleague lined up to test on his home network, but would love to see it outside of the Free network.)

24 June

A very difficult issue pops up. Code so far can trap any unicast ICMP arriving at the gateway, and respond with a NA. Great! It works. Then remember that the NS coming in to us can be either directed unicast (what I’ve tested with so far) or, actually more likely, multicast. OK, no biggie. But then we see that the multicast is directed in terms of having the bottom 48 bits set to the target address contained within the solicitation. So…. from the socket level we need to pick up these “directed multicasts” (or solicited-node messages)  And that’s where things get tricky. To pick up a multicast I need (from socket level) to first join the multicast group. BUT these NSs, remember, don’t come in on a fixed multicast group.. So you cannot join the multicast group. It’s chicken + egg. You only know what multicast group will be used AFTER you’ve joined the right multicast group… I cannot believe this. But that’s how it seems right now. And makes me fear if the existing IPv6 socket layer can let this problem be overcome…. Ow. This is ugly.

The solicited-node address facilitates efficient querying of network nodes during address resolution. IPv6 uses the Neighbor Solicitation message to perform address resolution. In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment regardless of whether a node is running IPv4. For IPv6, instead of disturbing all IPv6 nodes on the local link by using the local-link scope all-nodes address, the solicited-node multicast address is used as the Neighbor Solicitation message destination.

The solicited-node multicast address consists of the prefix FF02::1:FF00:0/104 and the last 24-bits of the IPv6 address that is being resolved.

The following steps show an example of how the solicited-node address is handled for the node with the link-local IPv6 address of FE80::2AA:FF:FE28:9C5A, and the corresponding solicited-node address is FF02::1:FF28:9C5A:

1. To resolve the FE80::2AA:FF:FE28:9C5A address to its link layer address, a node sends a Neighbor Solicitation message to the solicited-node address of FF02::1:FF28:9C5A.
2. The node using the address of FE80::2AA:FF:FE28:9C5A is listening for multicast traffic at the solicited-node address FF02::1:FF28:9C5A. For interfaces that correspond to a physical network adapter, it has registered the corresponding multicast address with the network adapter.

As shown in this example, by using the solicited-node multicast address, address resolution that commonly occurs on a link can occur without disturbing all network nodes. In fact, very few nodes are disturbed during address resolution. Because of the relationship between the network interface MAC address, the IPv6 interface ID, and the solicited-node address, in practice, the solicited-node address acts as a pseudo-unicast address for efficient address resolution.

tcpdump tip

Here’s a useful one, to tcpdump only NAs and NSs:

tcpdump -v -i eth0 ip6[40] == 135 or ip6[40] == 136

Ugly, ugly…

So turns out that, to the very best of my ability to discover, IPv6 sockets do not let me pick up any and all ICMP sent to the interface(s). If it’s to a multicast address, I must join the group beforehand. Which I cannot do. I have to say it’s a pretty glaring omission, IMHO. It’s “glaring” not maybe in the general case, but given IPv6 uses “unique multicast” addresses for Neighbor Solicitations, to not provide an IP-socket-level mechanism for receiving them is pretty crap.

So I assume I’m going to have to instead receive on a simple Packet level socket, and build a packet filter on it.

Packet filters

The more I look at it, the more it seems that until the IPv6 socket API expands, I’m going down this path. Easy enough to create a null filter. Done. 2 mins work. Now to get to grips with the BSD packet Filter VM language to actually write the filter. I know that, in general, BSD-PF semantics for IPv6 are problematic… However I should be OK here, as I am just interested in IPv6 ICMP – I think that should be a straightforward enough packet dissect.

Update: 1 July BSD PF VM syntax. Wow. Kinda funky, but now almost makes sense. Hope to have a working ICMP6 packet filter working soon!!

3 July

Yes. Can now reliably capture ALL ICMP neighbor solcitations on my gateway box. Now working on restoring the functionality lost by not having the socket feed us ICMP – since we now get a raw packets we must work a bit harder to find out who sent it, interface, etc. – the pktinfo mechanism is not available to us (well, the mechanism itself is, but the context make the information is supplies not useful) so we must do that manually. So lost of casting away of IPv6 headers and so forth!

Multicast…

During development, so far I’ve almost always had tcpdump running on my WAN interface while testing code. Today was not running it and noted, much to my confusion, that the daemon saw NO multicast neighbor solicitations.Makes sense: tcpdump sets the interface to promiscuous mode. So we see everything. Since many of the NSs are multicast, if we haven’t signed up to the multicast group (as per above ad nauseam, we can’t…) we don’t see them at the packet filter level.

For now (and maybe for ever!) the compromise is that the interface has the ALLMULTI flag set on it. Setting PROMISC permanently would be a touch too ugly, but I think nominally receiving all multicast is acceptable. In these days of switched point-to-point Ethernet, all of this gets fairly academic anyway, as being in effect now a non-shared medium in so many instances the “extra” traffic handled by setting PROMISC is low-to-zero. But anyway, the Linux interface option of ALLMULTI is just fine.

In fact when I found out about the ALLMULTI interface flag, I even wondered if it would let my original design of having an ICMP6 socket open would now work… But no – even in full PROMISC mode the OCMP6-level socket does not receive multicast unless the socket has explicitly joined the specific group first.

RFC time

OK, so we can now kick out a Neighbor Advertisement in response to a Neighbor Solicitation received on the multicast group address. Cool.

Now to pay attention to the nature of it. As per the RFC 2461:

A node sends a Neighbor Advertisement in response to a valid Neighbor
   Solicitation targeting one of the node's assigned addresses.  The
   Target Address of the advertisement is copied from the Target Address
   of the solicitation.  If the solicitation's IP Destination Address is
   not a multicast address, the Target Link-Layer Address option MAY be
   omitted; the neighboring node's cached value must already be current
   in order for the solicitation to have been received.  If the
   solicitation's IP Destination Address is a multicast address, the
   Target Link-Layer option MUST be included in the advertisement.
   Furthermore, if the node is a router, it MUST set the Router flag to
   one; otherwise it MUST set the flag to zero.

Soooooooooo, given all of that, the simplest logic will be to set Destination Link-Layer option for all our NAs.

11 August 2011

Haven’t updated this for a while – as the project has really taken off and is now living in its own right!!! Mt post at http://www.ipsidixit.net/2011/08/04/npd6/ indicates where it’s at and how to obtain it.

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 [...]]]> Previous articles have detailed various aspects of getting IPv6 running on a home-gateway router. The aim is to migrate as much as possible towards an IPv6-only situation.

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:

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

To recap:

All of this has, so far, made use only of one network interface (in my case eth0) [...]]]> Following on from my first tutorial, we have a box set up which has basic IPv6 connectivity. There’s a firewall in place with a simple but sufficient configuration. And we can ping6 from this box to remote IPv6 destinations.

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 128
gateway fe80::207:cbff:aaaa:bbbb

[EDIT: 2 Aug 2011: "netmask 128" previously read "netmask 64" It *could* be 64, but more likely 128!!]

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

Now this need not be a “blocker” for everyone, but I take my firewall logging duties quite seriously…!

Currently I have IPv4 shorewall configured to log not using the standard syslog mechanism, [...]]]> Following on from my early success at get IPv6 running, I soon hit a significant issue: firewall logging.

Now this need not be a “blocker” for everyone, but I take my firewall logging duties quite seriously…!

shorewall IPv4 logging

Currently I have IPv4 shorewall configured to log not using the standard syslog mechanism, but instead to use ulogd. This allows me to easily log firewall activity to an entirely separate set of log files very easily. It is absolutely not mandatory, but it’s neat and tidy. I then have fwlogwatch to nightly analyse the logs and automatically email the interesting bits to me for occasional checking.

To enable this I have appropriate pointers to use of ULOG in shorewall’s policy and rules files as follows:

policy

.

.

.

ext all DROP ULOG

.

.

.

and, for example:

rules

.

.

.

ACCEPT:ULOG all fwall 47
.
.
.

One then has an appropriate config in /etc/ulogd.conf to file things where you want them.

shorewall6 IPv6 logging

• syslog
• nflog

The syslog option I specifically did not want, so I decided I’d better find out about nflog (Net Filter Log). It turns out that nflog is actually more commonly referred to as ulogd2, and is a dramatically enhanced version of the original ulog. In fact it’s so different that it is, for all practical purposes, an entirely different thing. Trying to relate ulog to ulog2 is a pretty futile exercise. Work on the basis that they are unrelated and it’ll prove less frustrating.

Implementing NFLOG (aka ulogd2) on a Ubuntu firewall

The first step to follow is to get hold of the ulogd2 source tree and build it. I worried that this would take me some time, but found a tremendously helpful article someone had already written which aided me a lot. (Thank you Pollux!)

• I’d suggest leaving the build PREFIX unspecified (i.e. default) so it will ultimately install in the /usr/local/ hierarchy. This means you can get it all working in parallel with an existing ulogd installation – much cleaner and safer!
• Since we want to emulate ulogd just in so far as we are able to log to a disk file, disable any of the Postgres or MySQL build options to make things more compact and simple (unless of course you want to make use of these neat new features within ulogd2!)
• Much of the article referenced assume that you will be logging to a database – keep it simple for now and ignore that.

ulogd2 config highlights

• IPv6 to be logged to one file
• IPv4 to be logged to another file (this used to be done using the original ulogd)

plugins section

plugin="/usr/local/lib/ulogd/ulogd_inppkt_NFLOG.so"
plugin="/usr/local/lib/ulogd/ulogd_inppkt_ULOG.so"
plugin="/usr/local/lib/ulogd/ulogd_inpflow_NFCT.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_IFINDEX.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_IP2STR.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_IP2BIN.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_PRINTPKT.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_HWHDR.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_PRINTFLOW.so"
#plugin="/usr/local/lib/ulogd/ulogd_filter_MARK.so"
plugin="/usr/local/lib/ulogd/ulogd_output_LOGEMU.so"
plugin="/usr/local/lib/ulogd/ulogd_output_SYSLOG.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_OPRINT.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_NACCT.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_PCAP.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_PGSQL.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_MYSQL.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_DBI.so"
plugin="/usr/local/lib/ulogd/ulogd_raw2packet_BASE.so"

stacks section

# this is a stack for logging packets to syslog after a collect via NFLOG
stack=log4:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu4:LOGEMU
stack=log6:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu6:LOGEMU

log section

# Using log4 for IPv4
[log4]
group=4
numeric_lable=4
# Using log6 for IPv6
[log6]
group=6
numeric_label=6

log-specific sections

# IPv4
[emu4]
file="/var/log/firewall/nflog4.log"
sync=1
# IPv6
[emu6]
file="/var/log/firewall/nflog6.log"
sync=1

Changes to shorewall configs

shorewall6 additions

So my (very very over-logged – but then my IPv6 is still at the experimental stage…!) policy file is now:

#Source         Dest            Policy          Log             Burst/Limit

fwall           all             DROP            NFLOG(6)

int             all             DROP            NFLOG(6)

ext             all             DROP            NFLOG(6)

all             all             DROP            NFLOG(6)

ACCEPT:NFLOG(6) ext     fwall   ipv6-icmp

ACCEPT:NFLOG(6) fwall   ext     ipv6-icmp

shorewall (IPv4) changes

And over in my IPv4 shorewall I just changed any reference to ULOG to read NFLOG(4), for example, where policy previously read:

office all DROP ULOG

office all DROP NFLOG(4)

In Summary

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 [...]]]>

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…

[EDIT: Had to obfuscate parts of addresses below... Sorry, makes reading a tad harder in places...]

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:XXX/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:XXX 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:XXX: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 does 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:XXX:8b25:7ea0::/64 which looks pretty random but of course is not.

The part 2a01:xx is, from previous knowledge, a global unicast prefix (the 2xxx: indicates that) and the full form 2a01:xx 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 XXX XXX XXX. 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:

[EDIT 2 Aug 2011: A booboo... the "netmask 64"  previously on my eth0 config (and resulting displays) is unlikely to be what you want! If this was a single interface machine, that'd be fine (although pedantically incorrect). But given that eth0 here is the WAN port, and there's "the rest" of that IPv6 network behind eth1, the eth0 interface static address should be defined as a full 128 bit mask, while the eth1 should be (probably - your mileage may vary...) the 64 bit one. Otherwise you end up with 2 equal routes for the same network, one out of each interface. Very very unlikely to be what you want!!!!!)

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:

• Enable a default “block almost everything” IPv6 firewall.
• Understand the three major subsystems which might b used on an IPv6 router/firewall (dhcp6c, dhcp6s, radvd)
• Understand that we possibly only need radvd and to install it on the firewall.
• Assign an automatic address to our Internet-facing interface, based upon a received router advertsiement.
• Assign a static address to the same interface, in addition to the automatic address.
• See how we can examine IPv6 information relating to interfaces, route tables and neighbours.
• Monitor IPv6 activity for troubleshooting purposes.
• Do a simple ping test to confirm that we have basic IPv6 connectivity from the firewall out to the IPv6-Internet.

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.