Re: [v6ops] IPv6-Only Preferred DHCPv4 option

["Bernie Volz (volz)" <[e-mail]>]

Perhaps as a middle ground, draft could allow a server to return 0.0.0.0 as “assigned” address and then client MUST NOT send a DHCPREQUEST.

But I do not see this as being a requirement.


When responding to a DHCPDISCOVER that requested the ipv6-only option in the PRL and that the server includes it in the DHCPOFFER, a server can either;

- return an address that it is willing to offer a client should the client proceed. Or,
- MAY return the 0.0.0.0 address, in which case the client MUST NOT proceed with DHCPREQUEST.

- Bernie

On Dec 9, 2019, at 9:34 AM, [e-mail] wrote:

No, I am strongly arguing for no change.

Again, the things I suggested are optimizations if you feel there is a need to reduce the impact if lots of clients come online at same time. You don’t have to do any of these things.

If a server commits lease to disk with full lease time on an offer, yes you have to change that. Rfc 2131 already states that this is appropriate to do (not commit, use short time to hold lease).

Sure, we can document that as something that is a consideration if you have lots of clients and not much address space.

Sending 0 address is bad:
- might impact middleboxes
- has issues if option has been hijacked for other purposes and is in prl
- doesn’t allow client to continue with lease if it changes its configuration between discover & offer

And even if addresses all used, retransmissions will allow client to eventually proceed.

- Bernie

On Dec 9, 2019, at 9:18 AM, Ted Lemon <[e-mail]> wrote:


On Dec 9, 2019, at 06:00, Bernie Volz (volz) <[e-mail]> wrote:

We already don’t commit to disk per rfc2131 and use a short, tuneable time-out. So, again, we are all set without server changes.

Does rfc2131 actually say that?

You can also classify these devices into a separate client class to reduce timeout for them (such as to a few seconds).


That’s a special server change.

Again, I see no need for special server changes.

If a server doesn’t provide for these mechanics, the server should. But this is configuration issue, not protocol issue.

So servers other than yours should be the ones that have to change?  :)

The reason I think this merits a change is that we actually want different behavior. The change is trivial.

You aren’t actually arguing for no change: you are arguing for a change that is minimally inconvenient assuming a certain existing implementation.

That is a good short term move, but this is a long term solution. So I’m arguing to do it right.

One way to resolve this impasse would be to specify it do it would work with your minimal change, but also allow the server to send no address in the offer. That way you can implement the full change at your leisure, but we still get a good long term outcome.