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
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
[email protected]
