Feature #15016
open
Recursive DHCPv6-PD
0%
Description
I'm reconfiguring my network and have a need for a delegated IPv6 prefix from my pfSense box.
The ISP provides a /56 prefix which pfSense already correctly acquires and assigns a single /64 from this prefix to configure IPv6 for the local network.
With ISC DHCP I can also request a prefix from the pfSense device, however this has a few shortcomings:
- The UI doesn't have a simple place to show what prefix (and what size) the ISP delegated to us.
- Once a prefix is assigned to a DHCPv6 client we should install a route for it, which we currently don't do
- The default pf rules only install a pass rule for the first /64. It would make more sense to allow the entire. delegated prefix (in my case a /56). This is done through the LAN__NETWORK table, which contains the local LAN addresses.
- The delegated prefix could change, but the current configuration UI (services_dhcpv6.php) wants users to specify the prefix in "Prefix Delegation Range". This should perhaps allow a ${COMMON_PREFIX} variable to be used, or in some other way be made independent of the actual prefix, to better cope with renumbering.
I've managed to manually configure things to make the delegation work, but there's more friction than there needs to be.
Updated by Jim Pingle about 1 year ago
Kristof Provost wrote:
I'm reconfiguring my network and have a need for a delegated IPv6 prefix from my pfSense box.
The ISP provides a /56 prefix which pfSense already correctly acquires and assigns a single /64 from this prefix to configure IPv6 for the local network.
With ISC DHCP I can also request a prefix from the pfSense device, however this has a few shortcomings:
- The UI doesn't have a simple place to show what prefix (and what size) the ISP delegated to us.
Because we don't have a way to get that from the client. Lots of DHCPv6 delegation features are blocked by that. The only way to know is to log scrape currently, unless the other clients have improved and we can switch to one.
- Once a prefix is assigned to a DHCPv6 client we should install a route for it, which we currently don't do
Delegation does install routes, at least it does when done manually. There was a problem in 23.05.1 and 2.7.0 where that didn't happen but it was fixed in 23.09 / 2.7.1.
- The default pf rules only install a pass rule for the first /64. It would make more sense to allow the entire. delegated prefix (in my case a /56). This is done through the LAN__NETWORK table, which contains the local LAN addresses.
If they are delegated to clients on LAN that makes sense to include them in the "LAN subnets" macro but usually it's better to err on the side of caution/security here.
- The delegated prefix could change, but the current configuration UI (services_dhcpv6.php) wants users to specify the prefix in "Prefix Delegation Range". This should perhaps allow a ${COMMON_PREFIX} variable to be used, or in some other way be made independent of the actual prefix, to better cope with renumbering.
It would be nice to allow the short form there similar to in rules and DHCP where it fills in the prefix, but that would also require more knowledge about what was delegated, which prefix IDs are being delegated, etc.
Updated by Kristof Provost about 1 year ago
Because we don't have a way to get that from the client. Lots of DHCPv6 delegation features are blocked by that. The only way to know is to log scrape currently, unless the other clients have improved and we can switch to one.
I hope Kea exposes this information. I wouldn't spend any effort on implementing this for ISC DHCPv6, given that it'll go away in the future.
Delegation does install routes, at least it does when done manually. There was a problem in 23.05.1 and 2.7.0 where that didn't happen but it was fixed in 23.09 / 2.7.1.
That's odd. I'm running a recent 23.04 snapshot, and it didn't install the route.
If they are delegated to clients on LAN that makes sense to include them in the "LAN subnets" macro but usually it's better to err on the side of caution/security here.
We could perhaps add LAN subnets as we do the DHCPv6-PD (i.e. along with the route insertion), but I'm not sure we're buying much security by disallowing local subnets. We should of course still do the usual sanity checks (i.e. lan traffic has to come in on the physical lan interface), but once that's satisfied it should be fine to just allow that traffic.
Updated by Jim Pingle about 1 year ago
Kristof Provost wrote in #note-2:
Because we don't have a way to get that from the client. Lots of DHCPv6 delegation features are blocked by that. The only way to know is to log scrape currently, unless the other clients have improved and we can switch to one.
I hope Kea exposes this information. I wouldn't spend any effort on implementing this for ISC DHCPv6, given that it'll go away in the future.
It's not Kea nor ISC it's the WIDE-DHCPv6 dhcp6c client here that obtains the prefix from upstream and acts on it. Currently it applies the configured tracked prefix IDs to interfaces directly and logs the info but it doesn't store it anywhere we could take further action upon it.
Delegation does install routes, at least it does when done manually. There was a problem in 23.05.1 and 2.7.0 where that didn't happen but it was fixed in 23.09 / 2.7.1.
That's odd. I'm running a recent 23.04 snapshot, and it didn't install the route.
Granted my edge is still on 23.09-RELEASE but it is working there. I see the same networks listed in the delegations area of DHCPv6 leases and in the routes