If you’re one of the lucky ones, your ISP might provide native IPv6 connectivity (like AAISP), but for most of us, the main way to get connected to the rest of the IPv6 Internet is to use something we’ve already got – IPv4. And we’re going to tunnel over it.

The first thing we need to do is choose a tunnel broker, which is a fancy name for someone who’ll provide us with an IPv4 endpoint we can tunnel IPv6 over. Wikipedia has a list, but the main, globally available ones are Hurricane Electric and SixXS. Either of these will do, and some people prefer HE over SixXS, but that’s a purely personal choice – in my experience, both work equally as well. For this example, though, we’ll go with HE – so head on over to http://tunnelbroker.net/ and create an account.

My first tunnel

Once you’ve created your account, log in and create a tunnel. For some reason, it always seems to pick their New York POP, so you might want to manually choose one geographically closer (in my case – and for our example – London, UK)

Creating a tunnel

The IP address you use as your local end of the tunnel will need to be a public IP address. It’s possible to use a machine behind a NAT device if it’s in a DMZ-style setup where all the traffic destined for the public IP address gets forwarded by the NAT device to the machine behind it, but your mileage may vary.

Once created, view the tunnel details, which should look something like this:-

Editing the tunnel details

Our tunnel has been created! At the bottom of the page, you’ll notice a little drop-down that generates the commands needed to bring up the tunnel. For this example, we’re using iproute2, so the commands go something like this:-

ip tunnel add he-ipv6 mode sit remote 216.66.80.26 local 192.0.2.1 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08:810::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

The first command creates an IPv6-in-IPv4 tunnel between us and HE, and the second command brings up that tunnel. The third command adds our IPv6 address to our end of the tunnel, and finally the fourth command sets the IPv6 default route to be down our newly-created tunnel.

And that’s it – we’re now connected to the global IPv6 internet. To test it, let’s try pinging something:-

mordor:~# ping6 -c 3 www.he.net
PING www.he.net(he.net) 56 data bytes
64 bytes from he.net: icmp_seq=1 ttl=58 time=375 ms
64 bytes from he.net: icmp_seq=2 ttl=58 time=257 ms
64 bytes from he.net: icmp_seq=3 ttl=58 time=255 ms

--- www.he.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 255.562/296.218/375.628/56.158 ms

If you see something like the above, then give yourself a pat on the back, because it’s working!

Next steps

HE by default assigns you a /64 network, which is the smallest size intended to be allocated. This gives you 18,446,744,073,709,551,616 IPs, and whichever way you look at it that’s a lot of addresses. With this in mind, you might be wondering why HE will give you a /48 (that’s 1,208,925,819,614,629,174,706,176 IPs!). The reason is that each network is intended to have a /64, and a /48 allows you to carve up that space into a total of 65,536 separate /64 networks. Now this obviously sounds like overkill to the average user, but autoconfiguration tools such as radvd won’t work with networks smaller than /64, again because of the intentions mentioned previously. This means that if you have more than one network at home (say, a wired network and a wireless network, currently with separate IPv4 networks for each), you can assign a /64 to each one.

With this is mind, let’s ask HE for a /48 by clicking on Allocate in the ‘Routed /48′ section. After a few seconds, you’ll see something like this:-

Allocating our /48

In our example, we’ve been allocated 2001:470:90d3::/48, and now it’s time to plan our IP schema.

Laying it out

Taking my own home network as an example, I have three networks – one for general use (the ‘LAN‘), one for guest use over wireless (the ‘WLAN‘), and finally a DMZ (the… er, ‘DMZ‘). We could lay these out like this:-

• LAN – 2001:470:90d3:1::/64
• DMZ – 2001:470:90d3:2::/64
• WLAN – 2001:470:90d3:3::/64

Nice and simple, and easy to remember. Assuming all three networks are connected to the same gateway machine, we can give the gateway the first IP in the range – 2001:470:90d3:1::1, 2001:470:90d3:2::1 and 2001:470:90d3:3::1.

Routing things further

Before we start, we need to enable IP forwarding for IPv6:-

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

You’ll probably want to add this somewhere so it gets activated on bootup – under Debian this would be in /etc/sysctl.conf (which already has the entry, albeit commented out).

One way to provide connectivity to machines on the individual networks is to manually give each machine an IPv6 address, and to route it through our gateway:-

ip addr add 2001:470:90d3:1::2/64 dev eth0
ip route add ::/0 via 2001:470:90d3:1::1 dev eth0

Again, all being well, you should now be able to route to the wider IPv6 Internet from our newly-configured IPv6 node. More importantly, this also means that the wider IPv6 Internet can route back to you – which brings us to…

Security, not obscurity

Don’t be fooled into thinking that because of the immense range of possible IPv6 addresses that securing your new IPv6 setup isn’t required – IPv6 is no exception when it comes to the Internet Bad Guys, so implementing firewall rules is of the utmost importance.

The problem with IPv4 and NAT is that it’s allowed people to become somewhat complacent about security, because machines behind a NAT device are naturally unreachable from the global Internet. IPv6 does not have NAT, which means you don’t have this (rather lazy) safety net, so we have to do it properly.

Luckily, if you’re familiar with iptables, you’ll be glad to know that there’s an IPv6 equivalent – and it’s called (predicatably) ip6tables. The syntax is identical, and in fact the only noticeable difference is that you’re using IPv6 addresses and networks instead of IPv4 ones.

A quick example would go something like this:-

# Clear our INPUT, OUTPUT and FORWARD chains
ip6tables -F INPUT
ip6tables -F OUTPUT
ip6tables -F FORWARD

# Allow packets related to existing connections
ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow link-local (for neighbour discovery)
ip6tables -A INPUT -s fe80::/10 -j ACCEPT

# Allow SSH inbound to our gateway from our LAN
ip6tables -A INPUT -i lan -s 2001:470:90d3:1::/64 -p tcp
   -m tcp --dport 22 -j ACCEPT

# Allow all outbound from our networks
ip6tables -A FORWARD -i lan -s 2001:470:90d3:1::/64 -j ACCEPT
ip6tables -A FORWARD -i dmz -s 2001:470:90d3:2::/64 -j ACCEPT
ip6tables -A FORWARD -i wlan -s 2001:470:90d3:3::/64 -j ACCEPT

# Allow all outbound from our gateway
ip6tables -A OUTPUT -j ACCEPT

# Allow SSH and HTTPS inbound to our DMZ
ip6tables -A FORWARD -i he-ipv6 -d 2001:470:90d3:1::/64 -p tcp
   -m multiport --dports 22,443 -j ACCEPT

# Set the default policy to drop
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

So there you have it – IPv6 firewalling needn’t be difficult. If you want to make something more complex, you might want to take a look at my previous post about iptables and the ‘mark’ target, which also applies to ip6tables.

IPv6 – automatically

Just like DHCP for IPv4, there are autoconfiguration mechanisms for IPv6 – radvd and DHCPv6. Radvd is the older of the two, but both can be used for the same purpose. Configuration of radvd is relatively straightforward, and if we wanted to provide autoconfiguration on our example LAN, we can do something like this:-

interface lan
{
      AdvSendAdvert on;
      MinRtrAdvInterval 3;
      MaxRtrAdvInterval 10;
      AdvDefaultPreference low;
      AdvHomeAgentFlag off;

      prefix 2001:470:90d3:2::/64
      {
            AdvOnLink on;
            AdvAutonomous on;
            AdvRouterAddr off;
      };
};

Where next?

This only covers the start – there’s more involved in bringing an IPv6 network up to scratch, like setting up forward and reverse DNS, and configuring various daemons to talk over IPv6 as well as IPv4. If you’re interested, you might find some of the following links useful reading:-

• Peter Bieringer’s Linux IPv6 Howto
• IPv6 in the UK
• RFC 2460 – IPv6 Specification
• Deep Space 6

So what options are there? One way is to repeat the same rule for different sources or destinations, but this can quickly get messy, especially if there’s multiple ports involved. If there was a way we could group things together and keep them tidy, maintaining the rulebase would be a lot easier. This is where MARK comes in.

The MARK target lets us set a 32-bit value (or 0xFFFFFFFF) on a packet, which we can then look for later with the mark match. This in itself can be useful, but where it gets really handy is adding the values together.

Starting out

To start off with, here’s an example

# Create a new chain, which will in effect be our source 'group'
iptables -N S-TRUSTED
# Add our sources
iptables -A S-TRUSTED -s 192.168.1.1/32 -j MARK --set-xmark 0x8/0x0
iptables -A S-TRUSTED -s 192.168.2.0/24 -j MARK --set-xmark 0x8/0x0
iptables -A S-TRUSTED -s 192.168.3.3/29 -j MARK --set-xmark 0x8/0x0

# Create a chain for the destination group
iptables -N D-DMZ
# Add our DMZ machines
iptables -A D-DMZ -d 10.1.1.1/32 -j MARK --set-xmark 0x4/0x0
iptables -A D-DMZ -d 10.1.2.0/24 -j MARK --set-xmark 0x4/0x0

# Create a chain for the services
iptables -N D-SRV-MGMT
# Add our service
iptables -A D-SRV-MGMT -p tcp -m tcp --dport 22 -j MARK --set-xmark 0x2/0x0
iptables -A D-SRV-MGMT -p tcp -m tcp --dport 80 -j MARK --set-xmark 0x2/0x0

So what we have now are three chains, which do the following

• If the source matches, add 0×8 to the packet mark
• If the destination matches, add 0×4 to the packet mark
• If the service matches, add 0×2 to the packet mark

If you know your hexadecimal, you’ll already know that if all of these are true, we’ll come out with 0xE (or 14, in decimal).

Making the rule

Hopefully you’ll see where we’re going with this with the next example, which is our actual rule

# Create a new chain for our rule and add it to our FORWARD chain
iptables -N R-ALLOW-DMZ-MGMT
iptables -A FORWARD -j R-ALLOW-DMZ-MGMT
# Zero out the packet mark to make sure no previous rules interfere
iptables -A R-ALLOW-DMZ-MGMT -j MARK --set-xmark 0x0/0x0
# Jump to our 'source group' chain
iptables -A R-ALLOW-DMZ-MGMT -j S-TRUSTED
# Jump to our 'destination group' chain
iptables -A R-ALLOW-DMZ-MGMT -j D-DMZ
# Jump to our 'service group' chain
iptables -A R-ALLOW-DMZ-MGMT -j D-SRV-MGMT
# If the packet mark matches 0xE, then ACCEPT
iptables -A R-ALLOW-DMZ-MGMT -m mark --mark 0xE -j ACCEPT

And there we have it – if the packet matches the source, destination and service, the packet mark will be 0xE. If, say, it matches everything except the destination, it’ll come out as 0xC, which won’t match and so netfilter will carry on along the rest of the rules. If you want processing to stop here, you could always add a LOG and REJECT/DROP target at the end of the R-ALLOW-DMZ-MGMT chain.

Negation

Sometimes we want to be able to say ‘everything but that particular network’, whether it be for accepting or dropping packets. We can do that with this, too

# Add a new chain for negating the source
iptables -N S-NEGATE
# XOR the current packet mark with 0x8 - our 'source match' identifier
iptables -A S-NEGATE -j MARK --xor-mark 0x8

To use it, simply drop it in the R-ALLOW-DMZ-MGMT rule above after the jump to the S-TRUSTED chain, and if S-TRUSTED matched, it won’t any more, and vice versa. To negate the destination and service matches, you’ll need to create similar chains for (for example) D-NEGATE and D-SRV-NEGATE, replacing the 0×8 with 0×4 and 0×2 respectively.

Things to note

One downside of this method is that because of the way IPTables works, if you want to use the same set of networks and hosts as a source and a destination, you’ll need to duplicate them, but match on the source or destination as appropriate. Using the example given above, if we wanted a group with the same entries as S-TRUSTED, but matching on traffic going to them, we’d need to create another group (for example, D-TRUSTED), which will be identical save for the IP matches (which will need changing to -d) and the mask (which will need setting to 0×4 instead of 0×8).

Also, be careful if you’re using packet marks to do something outside of netfilter (say, for traffic control – which I’ll cover in a future post). One way round this is the facility to save the current packet mark to the current connection mark, or vice versa – if you go down this path then having a look at the iptables manpage for the MARK and CONNMARK targets will be useful.

Conclusions

This is an effective way of grouping hosts, networks and services within IPTables. It can be quite a bit of work to start with to add all the groups, but once in place it makes writing rules a lot more logical.

Taking things further

One way which you could take this further would be to group interfaces together in a similar fashion, say by adding 0×10 to the packet, and then matching on 0x1E rather than 0xE.

Usefully, if you send the packet out to syslog with the LOG target, netfilter will print out the current packet mark at the end of the log message as MARK=0xN, which can be useful when debugging.