Is a stable IPv6 prefix delegation possible?

[daverand]

I would like to second this request. I observer similar issues with PD, and it is somewhat frustrating. Thank you, though, for the amazing service, and I appreciate what you are doing.

(FWIW, I'm using PFsense, with dhcp6 on FreeBSD).

[rpineau]

I see the exact same thing with my EdgeRouter Infinity.
The /56 being return is ALWAYS a new one, even if I set a DUID in the config.
This makes setting firewall rules impossible (prevent IOT network from talking to main network, allow ipv6 range on remote device and server, ...). It also makes it impossible to set static IPv6 on some specific devices in the internal /64 as these will change/
I never had this issue while I was on AT&T and bot the IPv4 and IPv6 were stable (and not static as AT&T also doesn't provide static IPv4 on their consumer gigabit fiber).
This is not the IPv6 PD expected behavior and the same /56 should be re-issued on refresh and renew, specifically if a DUID is provided.

[msiegen]

daverand, in pfSense you may be able to solve this by setting Do not Allow PD/Address Release.

rpineau, I don't know if a similar option exists in the EdgeRouter. This post suggests it does not, though it's from 4 years ago.

Sonic folks, would it be feasible to just ignore any received DHCP RELEASE messages on your side? That's potentially a simple change, and would give a stable prefix to many more users. Abandoned prefixes would still get recycled when their lease expires.

I can confirm that my prefix, which my router never releases, has been stable across many renew and reboot cycles.

[rpineau]

I checked and even on the most recent EdgeOs version, dhcp6c doesn't have the `-n` option to prevent release of a prefix.
As said, when I was on AT&T this was not an issue as every renew (intentional or after reboot) was always giving me the exact same prefix. So this should be something configurable on the ISP side (dhcp6d or dhcpd3 lease file tweak).

[kgc]

So this should be something configurable on the ISP side (dhcp6d or dhcpd3 lease file tweak).

Unfortunately, this is not as simple configuration change due to limitations in the hardware that's currently used for most dhcpd services or we already would have taken care of it. Resolving the problem would most likely involve a migration to centralized dhcp services from our existing distributed dhcp services setup.

However, I'm not sure we're troubleshooting the right problem.

If we receive a release or the lease goes idle for long enough for the garbage collection to forget about it on our end, you will most likely not receive the same lease back. This should not occur during a healthy dhcp renewal process. It used to be a fairly common problem that firewalls would end up misconfigured and would block unicast dhcp responses to lease renewals which would result in customer's equipment leases to eventually fall back to the initial discovery process. Are we sure that's not what's going on for the OP?

[rpineau]

I tested by doing "renew dhcpv6-pd interface eth1" back to back , so within a few seconds (about 30 seconds, time to get the new prefix and run show ip interfaces to check the IPv6 interface IPs), and each time I get a different prefix. So even renew on short period (less than a minutes) do NOT re-issue the same prefix. And this is indeed the source of our issue as any config changes trigger a renew and we get a new prefix. A reboot.. we get a new prefix.
My router reboot in a few minutes.. not hours... so the same lease is not being re-issued.
I allow all icmpv6 packet as well as well as udp port 546 and 547 so I do not block unicast dhcp responses.
So your DHCP servers do not re-issue the same lease even if a simple renew is done (or multiple).

[gadams]

Thanks, matt.kinkele, for your response, and for valuing sane IPv6! That is very high on my non-negotiables list for choosing an ISP, so I definitely appreciate that you're considering this in your future planning.

Responding to kgc, no, blocking unicast DHCPv6 responses is not the issue I've been seeing. It seems ill-advised to block that. Are you sure you've seen that in IPv6? Interestingly, I'm having a separate issue in which dropped ARP requests end up manifesting in a way that would look very similar from the ISP's view to blocked unicast DHCP requests, eventually falling back to broadcast requests.

In any event, I am happy to report that, since configuring my DHCPv6 client not to send DHCPRELEASE, I have had a stable IPv6 prefix for close to a month!

I'm still very nervous about rebooting or upgrading my router, since a change in prefix would take down my network and require a bunch of gotta-do-it-right-now work to repair. (I'm still dual-homed, but I'm trialing most of my subnets as Sonic-only.) But the situation is certainly much better, now.

Interestingly, even though my DHCP v4 client doesn't have a knob to skip releasing the lease, I also haven't had my IPv4 address change in that time. I can't explain it, but I'm not complaining. (But, as I said before, I don't really care about my IPv4 address changing. IPv4 is just for reaching legacy sites like Reddit and this forum.)