• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

How to achieve this IPv6 network configuration (SLAAC + DHCPv6 coexistence [mayb

Started by JenkinsNET, June 21, 2020, 06:13:21 AM

Previous topic - Next topic


I'm trying to setup DHCPv6 on my home network without any success. I'm looking for some detailed guidance. The rest of this post gives the background...

My home network is full IPv4 / IPv6 dual stack. It has a few 'servers' which provide services both internally and externally (i.e. on the Internet), several Macs, one PC and a host of devices (iPhones, iPads, smart home devices, ...). My core network is a 10 GbE wired network. I also have a 1 GbE 'access' network (with 3 Gb/s uplink to the core) and a 802.11ac WiFi network provided by 3 access points (extended over the wired backbone).

My ISP is Virgin Media and may connection is 350 Mbit/s down, 30 Mbit/s up. It provides only IPv4 connectivity. My 'servers' are a mix of macOS (Catalina) and Synology NAS units (DSM 6.2). My router (and additional WiFi access points) are all Apple AirPort Extreme units (802.11ac tower version with latest firmware).

My IPv6 Internet connectivity is provided by a TunnelBroker tunnel which terminates at my AirPort Extreme router. The router provides RAs and SLAAC config for my routed /64 from the tunnel.

My network has two separate IPv4 subnets. One is 'private'; it has no router and can only be used for strictly internal traffic. The other is 'public'; by this I mean that there is a router and addresses in this network can access the Internet. Of course there is a firewall etc. etc. The public network has DHCP with many reservations so all my devices end up with 'known' addresses.

My IPv6 network parallels the IPv4 one. It has a 'private' /64 subnet (fd00::/64) used by my core systems (servers, Macs) and a 'public' routable /64 which is the one provided by the router from the tunnel. All of my IPv6 capably systems connect to the public subnet but only those allowing explicit IPv6 configurations (servers, Macs) connect to the private subnet. Many devices on the public subnet use SLAAC assigned addresses and prefixes but the servers and Macs use well known, explicitly configured addresses for that subnet.

I have internal DNS for my internal domain which has all the 'known' addresses defined, both IPv4 and IPv6.

This all works very nicely and has done for some years now but I have one annoying niggle. I'd like to be able to control the public IPv6 addresses that many of my devices (iPhones, iPads, other things) get assigned (something like DHCP 'reservations') but of course this is not possible with SLAAC. I'm trying to figure out how I can maybe use DHCPv6 instead of SLAAC but I'm not having any luck. I have tried the ISC Kea DHCPv6 server and while it is easy to configure, clients simply do not get addresses from it! AFAIK it is *not* possible to disable SLAAC on the router.

Does anyone have any suggestions for how I can achieve what I want to do?




there are few things which play a role. it actually all starts with RA messages, those are quite essential and i'm afraid your Airport will be failing you here. I have bunch of them myself, I'm still using them because are great as general consumer products, but that's it. The specific setup you want needs configuration details which - unfortunately - Apple decided a user of it's products doesn't need (so are not available within the option set AirPort Utility provides).

So now the specifics you need.
- you need RA messages which will advertise your prefix with:
     - disallowed stateless (SLAAC) configuration
     - allowed stateful configuration

- dhcpv6 daemon + a bit change in configuration (reservations) you are used to as while ip4 runs on MAC addresses, ip6 stateful runs on "client-id" - which is kind of derived from MAC, but basically can be anything, various "dhcpv6 client"s do generate different ids so when you are starting with that it can create a lot of frustration and more frustration...

also, with ipv6, most of the usual configuration values like gateways, search domains, dns servers, IS being configured by SLAAC (only very few of them do have counterpart in dhcpv6), and for those to be configured there is no requirement to have addresses configured via SLAAC also - more confusion, right ?

you have plenty of infra how/where to run those, so you will pick, I will give you basic info/config with the daemons I use myself.
for the RA I use radvd (part of any linux distro repositories). usually expects config file /etc/radvd.conf. its simplest content can be this:

interface br0 {
              AdvSendAdvert on;
              MaxRtrAdvInterval 10;

            AdvManagedFlag on;

            RDNSS 2001:eeff:3a::9999 {

            DNSSL searchdomain1 {
            DNSSL subdomain.searchdomain2 {

            prefix 2001:eeff:3a::/64 {
                     AdvAutonomous off;
                     AdvRouterAddr on;

so this will advertise to your network:
- at max 10second interval
- that DNS resolver is at 2001:eeff:3a::9999
- that there are two search domains - searchdomain1 and subdomain.searchdomain2
- that there is /64 prefix available and that it:
          - should NOT be used for SLAAC address configuration
          - SHOULD be used for DHCPv6 configuration

at this point it is worth mentioning another difference to the usual pattern with ip4 - dhcpv6 addresses are always at prefix length of /128.

it is the definition of the /64 prefix which will create the usual "segment" route on the IF + that the machine which is sending those RA we configured above, will be autoconfigured as default gw for ::/0.
it is not obvious at first (at least I struggled a LOT when I started migration to ipv6), but simply despite the fact we go for stateful configuration, the stateless part STILL plays significant role in the process.

which brings me to one more point - because the dhcpv6 address configuration is basically useless without proper RAs (which deliver all the other stuff without which your machines will have address configured, but will be without real connectivity) - your machines need to accept those RA - on linux it is "accept_ra" (eg net.ipv6.conf.all.accept_ra = 1).
But pay attention here, if you set at the same time ipv6 forwarding (for what ever reason like - k8s, docker containers, lxd etc), the machines won't accept the RAs anymore (so =1 has no effect).
For that combination accept_ra needs to hold value 2.

I suppose this should be enough info for start - perhaps just to save you some more time, let me extract few lines from my dhcpd6 config file.
(I still use the old isc-dhcpv6 daemon, didn't look at the "kea" rework yet, so could be the keys/params do not much fully. in that case, to save yourself struggle, just for POC install the old isc-dhcpv6 reuse the config so that at least you get your model working).


subnet6 2001:eeff:3a::/64 {

        interface "br0";

        do-forward-updates on;
        ddns-updates on;

        ignore-client-uids false;
        echo-client-id true;

        ddns-domainname "homelan.";
        ddns-rev-domainname "";

        # Range for clients
        range6 2001:eeff:3a:0000:ffff:: 2001:eeff:3a:0000:ffff:ffff:ffff:ffff;

        # Range for clients requesting a temporary address
        #range6 2001:db8:0:1::/64 temporary;

        # Additional options
        ##option domain-name "homelan.";
        option dhcp6.rdnss-selection 2001:eeff:3a::9999 0 "homelan.";
        option dhcp6.name-servers 2001:eeff:3a::9999;
        option dhcp6.domain-search "searchdomain1", "subdomain.searchdomain2";

        option dhcp6.sntp-servers 2001:........;
        option router-discovery true;

        option dhcp6.info-refresh-time 150;

        # Prefix range for delegation to sub-routers
        prefix6 2001:.......:: 2001:........:: /xx;

        use-host-decl-names on;

        host monca21 {
            host-identifier option dhcp6.client-id 00:01:00:01:23:05:b7:ca:6c:96:cf:d9:5e:4b;
            fixed-address6 2001:xxxxxxxxxxxxx;
            ddns-hostname "monca21";
            option fqdn.fqdn "monca21.homelan";

just last two remarks:
- as I said before about the client-id - it is fully configurable for isc-dhcpv6 client, many others too, but happens way too often some system (ip configuration daemon) simply generates something - in that case what I do is that I let it configure ip, then I check lease file on dhcp server, grab the client-id from there and put into .conf file as reservation

- I kept the other configurations in the conf file (dns/router/domains) for reference - the point here is that isc-dhcpv6 was created long ago as reference implementation for dhcpv6 which was only draft (and could be most of this details are NOT yet in RFCs.

  so while the isc-dhcpv6 client from the same package IS able to configure also those from the values dhcpv6 (and this configuration) provides, for most of your network equipment it will be the RAs, not the dhcp offerings and their extended conf informations.

so, that's really it, this should get you started. depending on how far you want to go (DDNS registrations, HA on DHCPD etc etc, there is a lot of other quirks to tell about - maybe next time)