openwrt
FR: dhcpv6: support RECONFIGURE incl. all needed infrastructure (RFC8415)
Feature request
As a OpenWrt user with a dynamic IPv6 prefix delegation I want to use stateful DHCPv6 to my hosts.
Current behavior
If a new prefix is detected RA messages are send to deprecate the PIO of the stale prefix delegation. DHCPv6 leases are not updated and hosts which do not use SLAAC for an additional IP address can no longer communicate.
Desired behavior
Additionally to the new RA content the DHCPv6 server SHALL send RECONFIGURE with REBIND messages to the hosts in its lease table.
References
RFC3315 - 15.11 RFC6644 RFC8415 RFC8415bis
Server support:
- odhcpd: supported
- KEA: Does NOT support it yet https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#supported-dhcpv6-standards
- ISC-DHCP-Server: Does NOT support it.
- Wide-DHCPv6-Server: Does NOT support it.
- Proprietary implementations from network vendors support it to my research.
Client support:
- odhcp6c
Relates to: https://github.com/openwrt/odhcpd/issues/26
RFC3315 is pretty ancient, I think you want RFC8514bis :)
This is actually already supported in odhcpd both for DHCPv4 and DHCPv6. But it's only supported if the client supports RKAP/FR-Nonce (which is required by the RFCs to protect against spoofing...see e.g. the last bullet point of RFC8415bis, §16.11.
The problem is that few clients support it...
RFC3315 is the first RFC on this topic, RFC6644 updates specifically RECONFIGURE, and yes RFC8514bis is the latest clean version and would be preferred if implemented.
Yes Layer 2 mechanisms are needed to prevent nasty things. Unfortunately today there is no easy knob in CPEs to enable such things.
I drafted this FR to collect feedback. Thank you for yours!
RFC3315 is the first RFC on this topic, RFC6644 updates specifically RECONFIGURE, and yes RFC8514bis is the latest clean version and would be preferred if implemented.
I think you read my message too fast :) It is implemented in odhcpd...both for DHCPv4:
https://github.com/openwrt/odhcpd/blob/cf51aeb93220672d54d0d0f3707710bf544801e2/src/dhcpv4.c#L183-L292
And for DHCPv6:
https://github.com/openwrt/odhcpd/blob/cf51aeb93220672d54d0d0f3707710bf544801e2/src/dhcpv6-ia.c#L161-L251
Yes I did read to fast or overlooked this.
So we have no clients that support this? As we have no protection for rouge RA messages, is there a knob to relax the requirements?
Yes I did read to fast or overlooked this.
So we have no clients that support this?
odhcp6c supports it (I haven't tried it yet):
https://github.com/openwrt/odhcp6c/blob/5212a1019d75db47a03c95c12e385e4625dda3d0/src/dhcpv6.c#L1057-L1098
You can check the per-client status in your network by running ubus call dhcp ipv6leases and grepping for accept-reconf.
As we have no protection for rouge RA messages, is there a knob to relax the requirements?
Unfortunately it's not that easy...if the client doesn't express support for reconfiguration (which they typically don't), then relaxing requirements won't bring anything because the client is anyway not ready to receive any reconf messages. And clients which support reconf will typically implement the authentication/RKAP part.
IOW, the only potential puzzle piece that's missing from OpenWrt's side is DHCPv4 client support (since we use the DHCP client from busybox, and I haven't checked but I doubt it supports reconf/auth)
Speaking of odhcpd as server and odhcp6c as client.
What needs to be configured that this works? Maybe it is only the lack of documentation. Which I happily help to improve.
ubus call dhcp ipv6leases | grep accept-reconf
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": true,
"accept-reconf": false,
"accept-reconf": true,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": true,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": false,
"accept-reconf": true,
"accept-reconf": true,
"accept-reconf": true,
"accept-reconf": true,
"accept-reconf": true,
"accept-reconf": false,
"accept-reconf": true,
9 of 27 support it in my current lease file.
Clients:
- odhcp6c
- Amazon Echo Dot
Speaking of
odhcpdas server andodhcp6cas client. What needs to be configured that this works? Maybe it is only the lack of documentation. Which I happily help to improve.
It shouldn't need configuration, per se. I took a quick look, and the reconf should be triggered automatically when the IPv6 prefix changes on an interface where odhcpd is acting as a DHCPv6 server.
There's of course the problem that this would (for many users, at least) make the most sense in a crash/reboot/new PD/flash-renumbering scenario. There we need some puzzle pieces that are missing. We'd need to implement storage of DHCPv6 state (so that we have the nonces and the information about the old clients available across reboots; that also requires a suitable disk to write the state to, like a cheap external USB stick, there will be a lot of writes, as in, every time a lease is created or renewed). Persisting state is issue #26.
That, in turn, requires changes to unrelated packages (e.g. LuCI, or rpcd-mod-luci, to be exact; and unbound, there might be more) to get them to stop poking around in our statefiles (so that the format can be changed to include "all" data). I have a rough plan in mind for that, but it's definitely post-25.12 stuff.