Persistent DHCPv6 Prefix Delegation at GavleNet

In my previous article, IPv6 Address Planning in GavleNet, I wrote about our IPv6 address plan in GavleNet. This time, I'm going to talk about persistent delegations with DHCPv6 Prefix Delegation (DHCPv6-PD).

For many years, the only DHCP server that was available if you wanted to make intelligent choices about your DHCP leases was ISC's. When GavleNet used this DHCP server for IPv4, we initially investigated using the same DHCP server with our IPv6 design goals in mind. We purchased a D-Link router that supported DHCPv6-PD out of the box, and started testing.

Specifically, we wanted persistent allocations for customers. DHCPv6 Option 37 (Relay Agent Remote-ID), specified in RFC4649, is designed to help with this: the option provides DHCPv6 relays with the ability to add information to DHCPv6 messages to forward to the DHCPv6 server. DHCPv6 Option 37 gives us the opportunity to allocate an IPv6 prefix per customer.

This seems simple enough: Option 37 should allow us to always give the customer the same IPv6 allocation, and so their internal network doesn't need to be renumbered if they're statically configuring their address space at home.

Choosing the DHCP Server

It's easy to make ISC's DHCP server handle DHCPv6-PD requests. But we were never able to get it to log Option 37 / remote ID events. When we couldn't log the events, we couldn't use the server for persistent prefix delegation either.

We tried building from the latest source releases and played with various ./configure options, but we just could not make it work. We didn't submit a bug/feature report to ISC, because we knew that they were working on their new DHCP server software, called Kea.

The release notes for Kea 1.20 listed "using hardware address or DUID in DHCPv6" and that's what we wanted, so we waited for that release. When 1.20 was released on 28 April 2017 we downloaded it, built it, and started testing it.

Configuring Kea

Kea's configuration files are written in JSON, which was for me a new experience, but the source release includes some good examples to use as an initial configuration. The Kea mailing list is also a great resource.

Not having sufficient logging was a problem when we started testing Kea, but --enable-debug and enabling debug options in the config helped us a lot. It creates a mass of log lines, but they're very useful for debugging and learning issues.

You can enabling Kea debugging for DHCPv6 packets as follows:

{
    "name": "kea-dhcp6.packets",
    "output_options": [ {
        "output": "syslog"
    } ],
    "debuglevel": 55,
    "severity": "DEBUG"
},

And you can enable Option 37/Remote ID like so:

"Dhcp6": {
    "mac-sources": [ "remote-id" ],

Those to entries in the config create massive lines of log but they allow us to identify the prefix and Remote ID if we study the text below. The Option 37 section is after the "type=00037" below. I have separated and bolded the important thing in the option. 

Jan 30 15:52:30 nadhcp2VM kea-dhcp6: DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:38:d5:47:bb:78:f0], tid=0x22c8cc, packet details: localAddr=[removed by me]:0 remoteAddr=[2001:b49:80::1]:547
msgtype=6(REBIND), transid=0x22c8cc
type=00001, len=00010: 00:03:00:01:38:d5:47:bb:78:f0
type=00006, len=00008: 23(uint16) 24(uint16) 82(uint16) 83(uint16)
type=00008, len=00002: 0 (uint16)
type=00025(IA_PD), len=00041: iaid=751856, t1=0, t2=0,
options:
  type=00026(IAPREFIX), len=00025: prefix=2001:b49:31:8c00::/56, preferred-lft=0, valid-lft=0
1 relay(s):
relay[0]: msg-type=12(RELAY_FORWARD), hop-count=0, link-address=2001:b49:30::1, peer-address=fe80::3ad5:47ff:febb:78f0, 2 option(s)
type=00018, len=00006: 56:6c:33:32:38:31
type=00037, len=00022: 9 (uint32) 0200 2200 0DBC 000A000 30001001F6CD1DB80 (binary)

We can interpret this as follows:

• The first 2200 identifies slot 2 port 2
• 0DBC represents VLAN 3516 in hex
• 30001001F6CD1DB80 is the DUID from the Cisco 4500 (show ipv6 dhcp)

The reply from the DHCPv6 server looks like below and the prefix 2001:b49:80:5700::/56 is allocated to slot 2 port 2.

Jan 30 15:52:30 nadhcp2VM kea-dhcp6: DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[removed by me]:547 remoteAddr=[2001:b49:80::1]:547
msgtype=7(REPLY), transid=0x22c8cc
type=00001, len=00010: 00:03:00:01:38:d5:47:bb:78:f0
type=00002, len=00014: 00:01:00:01:20:1d:db:60:00:50:56:8c:53:d1
type=00023, len=00032: 2001:b48::2 2001:b48::3
type=00025(IA_PD), len=00041: iaid=751856, t1=1800, t2=1800,
options:
  type=00026(IAPREFIX), len=00025: prefix=2001:b49:80:0100::/56, preferred-lft=3600, valid-lft=3600
1 relay(s):
relay[0]: msg-type=13(RELAY_REPLY), hop-count=0,
link-address=2001:b49:80::1, peer-address=fe80::3ad5:47ff:febb:78f0, 1 option(s)
type=00018, len=00006: 56:6c:33:32:38:31

With that information we were then able to write a script to create a config like below. We assign one "hw-address" per lease as follows:

"subnet6": [ {          
    "subnet": "2001:b49:0080::/48", 
    "pd-pools": [ {
        "prefix": "2001:b49:0080::",
        "prefix-len": 48,
        "delegated-len": 56
    } ]
    "reservations":  [
        # Slot 2 port 1
        {
            "hw-address": ”02:00:21:00:0D:BC:00:0A:00:03:00:01:00:1F:6C:D1:DB:80",
            "prefixes": [ "2001:b49:0080:0100::/56" ]
        },
        # Slot 2 port 2
        {
            "hw-address": ”02:00:22:00:0D:BC:00:0A:00:03:00:01:00:1F:6C:D1:DB:80",
            "prefixes": [ "2001:b49:0081:0100::/56" ]
        },

        (more reservations)

    ]
] }

You can read more in the presentation I gave at the recent RIPE NCC IPv6 Day in Copenhagen.

Conclusion

So now Harkskär, a small village in Gävle kommun, where Gavlenet have deployed FTTH has native DHCPv6 PD.

Now Gavlenet's provisioning system Netadmin needs to create the whole Kea config automatically! Then we are done with FTTH and IPv6 in Gavlenet.

There are ~200 subscribers in Harkskär but only six of them have IPv6. Why is that the case? I'll cover that in my next post about IPv6 here on RIPE Labs!