Mailing List Archive: DHCP versus DHCPv6 Release behaviour

DHCP versus DHCPv6 Release behaviour

Aug 6, 2017, 3:34 PM

Post #1 of 3 (1245 views)

Hi All,

I’ve an issue with different DHCP client behaviour for IPv4 versus IPv6.

When my dual-stack (residential broadband) CPE router's WAN interface settings are changed in any way its DHCP client does not send a DHCP Release but its DHCPv6 client always sends a Release. Consequently the DHCP lease remains at the server but the DHCPv6 lease is deleted.

The end user finds that their dynamic IPv4 address changes less than their IPv6 delegated prefix. As long as the CPE remains connected and renewing they get the same IPv4 address. They can mess with the WAN settings or reboot the CPE and the DHCP client will still get the same IPv4 address. For DHCPv6 the server appears to increment to the next prefix rather than immediately give the previously Released prefix back out again even when the next Solicit it receives is from the same client.

The sequence for DHCP after saving changes is

Client DHCP does not send Release
Client DHCP Discover
Server DHCP Offer
Client DHCP Request
Server DHCP ACK

and for DHCPv6 it is

Client DHCPv6 Release
Server DHCPv6 Reply
Client DHCPv6 Solicit
Server DHCPv6 Reply

The DHCPv6 client does not send a Release if the CPE is given a soft or hard reboot. When the CPE comes back up it sends a DHCPv6 Solicit and gets the same delegated prefix.

The DHCPv6 server has the capability to ignore Releases and remember a lease beyond the lease's preferred lifetime which could be used to make the DHCP & DHCPv6 behaviour the same for the end user.

The choices seem to be

1. Do nothing and accept dynamic IPv6 delegated prefixes changing more often than the IPv4 address
2. Make the DHCP client send Releases when DHCPv6 sends them
3. Make the DHCPv6 client not send Releases under the same conditions DHCP doesn’t send them
4. Remember the DHCPv6 lease for some duration after a Release comes in so that it may be given out again

I’m leaning towards option 4 and with that the lease's stickiness could also be further increased to make it a pseudo static assignment. Although on the other hand some users have got used to dynamic IPv4 addresses and actually want their addresses to change. I think option 2 makes IPv4 behaviour worse so probably isn’t acceptable. Option 3 seems worse too as it is better to inform the server and let it decide what to do with the lease.

Regards,
Ross

Re: DHCP versus DHCPv6 Release behaviour [ In reply to ]

ola at nlogic

Aug 6, 2017, 11:34 PM

Post #2 of 3 (1242 views)

Permalink

(Sorry for top posting, this client is a bit stupid)

Technically, the server is correct in that after a "release" is received, it is free to assign the address to another client, and as such, the client should not expect to receive the same address on the next assignment.
However, following the principle of least surprise, I agree that the user probably expects to receive the same address, especially if they are just changing some settings on the wan interface.

If you are free to change both server and client behavior, I believe a combination of 2 and 4 is probably the "most correct" solution.
The client should probably send a release both for v4 and v6 at the same time.
But on the other hand, it would be nice if the server would remember the previous lease, at least for a while, and reassign it to the client if another request comes in within a reasonable time.

The last part should be configurable on the server side, as there are scenarios where you want your clients to not have this kind of semi static assignment.
Also, the server should obviously be allowed to assign a cached lease to a different client if the pool is otherwise empty.

Rgds

Ola (T)

________________________________
Fra: Ross Chandler <ross@eircom.net>
Sendt: 7. aug. 2017 00:34
Til: IPv6 operators forum
Emne: DHCP versus DHCPv6 Release behaviour

(...)

The choices seem to be

1. Do nothing and accept dynamic IPv6 delegated prefixes changing more often than the IPv4 address
2. Make the DHCP client send Releases when DHCPv6 sends them
3. Make the DHCPv6 client not send Releases under the same conditions DHCP doesn’t send them
4. Remember the DHCPv6 lease for some duration after a Release comes in so that it may be given out again

Re: DHCP versus DHCPv6 Release behaviour [ In reply to ]

ross at eircom

Aug 7, 2017, 4:26 AM

Post #3 of 3 (1242 views)

Permalink

> On 7 Aug 2017, at 07:34, Ola Thoresen <ola@nlogic.no> wrote:
>
> Technically, the server is correct in that after a "release" is received, it is free to assign the address to another client, and as such, the client should not expect to receive the same address on the next assignment.
> However, following the principle of least surprise, I agree that the user probably expects to receive the same address, especially if they are just changing some settings on the wan interface.
>
> If you are free to change both server and client behavior, I believe a combination of 2 and 4 is probably the "most correct" solution.
> The client should probably send a release both for v4 and v6 at the same time.
> But on the other hand, it would be nice if the server would remember the previous lease, at least for a while, and reassign it to the client if another request comes in within a reasonable time.

Yes, option 5 might be “2+4”. In options 2 & 5 to avoid a change in service level for IPv4 the DHCP server would also need to remember the IPv4 lease for a period long enough to keep the address the same after the Release followed shortly afterwards by a Discover. That is a configuration option at my DHCP server. The IPv4 pools, unlike the large IPv6 prefix pools, are run pretty hot close to capacity to maximise the v4 pool utilisation.

Ross