What I did to set up IPv6 on my wireless network

September 15, 2016

Last month I slapped together a home wireless network in a rush. Or more exactly I put together an IPv4 wireless network; as I mentioned at the end, one of the things I had left to do was extend it to IPv6 as well. Today, for no good reason, I decided that I was going to fix that and get at least basic IPv6 up and running. Even though I don't really know what I'm doing here, I succeeded, at least at the basics.

Bearing in mind that I didn't know what I was doing, I started with IPv6 DHCP and DNS service. I have an IPv6 /64 assigned to me by my ISP so I decided to carve off a section and allocate IPs out it. This is where the first 'I don't know what I'm doing' annoyance came in. I set up DHCP as:

# static IPv6 assignments, then:
# Need a subnet6 declaration to make
# things happy:
subnet6 subnet6 2001:1928:1:7:f000::/68 {
    # empty
}

The ISC DHCP server promptly complained:

No subnet6 declaration for enp7s0 (fe80::[...]).

Well. The reason for this was pretty straightforward; I had not attached a public IPv6 address to my Ethernet interface, leaving it with only a link-local IPv6 address. As far as I know, there's no way to tell ISC DHCP to just do DHCP service on a given device (and associated it with a specific client IP range so that it will give out assigned IPs in that range to known clients); you have to attach a specific IP in the client IP range. So I had to glue an otherwise public IPv6 address on to enp7s0.

(I set the DHCP server to tell clients that their router and their DNS server was my machine's fe80:: link-local address.)

I fired up my test device and got exactly nowhere; IPv6 DHCP was running but nothing was making any requests. People who know IPv6 are probably shaking their heads sadly, because if I'd known more I'd have known that DHCP by itself isn't sufficient. In IPv6, you need a route advertisement daemon to kick off the whole process. I followed section 3 of this guide to set up a radvd configuration that delegated everything to DHCP:

interface enp7s0
{
   AdvSendAdvert on;
   AdvOtherConfigFlag on;
   AdvManagedFlag on;
   prefix 2001:1928:1:7:f000::/68
   {
      AdvOnLink on;
      AdvAutonomous on;
   };
};

(I'm including the full configuration so you can laugh at me, because this is cargo cult configuration at its finest. I have minimal understanding of what I'm doing and I'm almost entirely copying things from elsewhere.)

This worked! My test device now got an IPv6 address and I could see traffic flowing. Or rather, I could see traffic attempting to flow but not actually going anywhere.

When I'd started radvd, it had complained:

IPv6 forwarding setting is: 0, should be 1 or 2
IPv6 forwarding seems to be disabled, but continuing anyway

When I saw this I nodded sagely and went off to /proc/sys/net/ipv6/conf to turn IP forwarding on for the two interfaces involved here (the local network and my DSL PPPoE link), because of course I needed to do this in IPv6 just as in IPv4. Surprise! Linux's IPv6 doesn't quite work like IPv4 does here. As I found in this helpful page, you apparently need to set IPv6 forwarding globally, in sys.net.ipv6.conf.all.forwarding. When I did this, everything suddenly worked.

(I don't know enough right now to understand the description of this in the kernel's ip-sysctl.txt.)

On the whole I was reasonably pleasantly surprised by how relatively easily this was to set up. Bearing in mind that I have no real idea what I'm doing, all of my problems were from not knowing what to configure (and how), not from software issues. And the software even told me some of what I was doing wrong.

I haven't currently set up any sort of IPv6 iptables filtering. After recent fun I think I'm going to avoid touching iptables for a while and just rely on IPv6 address obscurity.

(This would work a bit better if I assigned known clients random IPv6 addresses out of the /68 I set up or something, rather than statically giving them a single fixed IP. But I need to set up IPv6 iptables rules for my main machine anyways, which is probably always going to have a static IPv6 address.)

PS: radvd also complained 'enp7s0 prefix length should be: 64', but I'm ignoring that for now because things seem to work. I'm honestly not sure how prefix lengths are supposed to work when you have a big prefix from your ISP and you're carving bits of it up internally. If it doesn't blow up in my face, I'm letting it be.


Comments on this page:

By Kristof Provost at 2016-09-15 05:13:24:

Ideally all of your subnets should be /64s, otherwise stateless address assignments (i.e. without DHCP) won't work. As you've discovered, it's perfectly possible to run with smaller subnets, provided that you do DHCPv6. I'd still recommend always using /64 subnets though. That requires support from your ISP, because you can't just route things with the same /64 on both sides of course.

The magical word here is DHCPv6 Prefix Delegation. It lets your router request a subnet (usually a /48 or /56, but really even a single /64 would work in most cases) that you carve up into as many /64s as you have local networks. The ISP will route all traffic for the delegated prefix to your router. At that point it's up to you. You can set up whatever topology you like. Typically that'll require a little bit of glue on your router, to pass the information from your DHCPv6 client on the WAN interface to the DHCPv6 server on the LAN interface(s).

Written on 15 September 2016.
« When iptables SNAT and routing happens, and how this is annoying
A shell thing: globbing operators versus expansion operators »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Sep 15 00:13:08 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.