[Kea-users] IPv6 PD subnet splitting for multiple prefix lengths / prefix exclude option

[Jaco Kroon]

Hi All,

I'm not able to determine if this is possible, and my tinkering isn't 
working, so by hand of an example:

         "subnet6": [
             {
                 "id": 1,
                 "subnet": "2001:db8:9020::/44",
                 "pd-pools": [
                     {
                         "prefix": "2001:db8:9020::",
                         "prefix-len": 44,
                         "delegated-len": 56
                     }
                 ],
                 "interface": "lo"
             }
         ],

The idea is to have a secondary pool that will obtain it's own space 
from the above pool one /56 at a time, but issue /64s from that.  Not 
sure if that's possible.  Can't seem to find a way.

Alternatively, I need a way to reserve a /52 from the /44 to assign to a 
secondary pool from which to issue /64s.  One could just create a bunch 
of non-overlapping pools one each for prefix-len 45-51 and then two for 
prefix-len=52, where one of the prefix-len=52 pools issues /64s and the 
rest issues /56s - this just feels very error prone and excessively 
verbose in configuration.  Specifically in this case will result in 9 
seperate pd-pool allocations, 8 of which issues /56s, and one which 
issues /64s.

There are indications in the configurations that overlapping subnets are 
possible, but not overlapping prefix pools.  So I suspect I'm going to 
need to create the 9 pools.

Another option (but I need to test if the routers that I need the above 
for will work with that regardless, they're already braindead in that 
even after requesting a PD they will opt to use the link-local on the 
ppp to originate DNS queries from) is to rely on RFC 6603 and to exclude 
a /64 from each issued /56 (and have pppd pick up on that and assign it 
to the link, as will at least dhcpcd referenced below, if asked to do so).

https://kea.readthedocs.io/en/kea-2.6.0/arm/dhcp6-srv.html#prefix-exclude-option 
is however slightly unclear about the functionality here.

Given the pool above, I'm assuming:

1.  The /44 prefix (bits 0-43) from the excluded-prefix option needs to 
match prefix.
2.  The rest of the /56 prefix (bits 44-55) in the excluded-prefix 
option needs to be 0.
3.  The rest of the bits of the excluded-prefix-len prefix (bits 56-63) 
can be anything (but probably safest to use all zeros or all ones).
4.  The rest of the bits (64-127) must be 0 (since these will be the 
host specific bits).

As such, the following should exclude the "last" /64 from each of the 
delegated /56s:

"excluded-prefix": "2001:db8:9020:ff::",
"excluded-prefix-len": 64

Would this correctly vary bits 44 through 55 in the response to match 
the delegated /56?

Does anyone know how well supported RFC6603 is in general?  Looks like 
option 67 needs to be specified by the client, which it will (in the 
case of dhcpcd at least only do if you ask it to configure an address on 
the "upstream" link itself).

In the case where option 67 is proxied back, can anyone imagine a reason 
why the upstream side of the ppp link would actually *need* to configure 
an address in the range on the ppp interface? Specifically, let's say 
2001:db8:9020::/56 is delegated, and 2001:db8:9020:ff::/64 is excluded, 
then dhcpcd configures 2001:db8:9020:ff::1/64 on the ppp interface, but 
I don't see any reason to also configure such an address on the server 
side (which already does sensible address selection and will quite 
happily select the loopback address of the host for responding to 
2001:db8:9020:ff::1?

Given that, I'm thinking that if the client sets option 67, then use the 
excluded address (possibly adding a EUI64 based /64 to the ppp link), 
alternatively have pppd itself request a /64 from the dhcpv6 server, and 
assign that on the link.  Obviously given appropriate configuration options.

Background:  We're bumping into routers that doesn't perform proper 
address selection (at least when originating DNS requests) electing to 
use the IPv6 LL addresses on the PPP interface rather than whatever 
address from the PD it assigned to it's LAN.  It's also possible that 
these routers never performed a PD request and is assuming they can 
configure from RAs on the PPP, so the excluded-prefix here will be used 
to provision a /64 for RA use on the PPP itself (which is the purpose 
from RFC6603 as I understand it).  We're attempting to mitigate.

The DHCPv6 proxy itself is built straight into pppd 
(https://github.com/ppp-project/ppp/pull/551 - with many of my early 
assumptions having been proven wrong during that process).

Kind regards,
Jaco