Re: [v6ops] IPv6-Only Preferred DHCPv4 option

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

Comments inline below (BV>).


  *   Bernie

From: Ted Lemon <[e-mail]>
Date: Friday, December 6, 2019 at 11:02 AM
To: Bernie Volz <[e-mail]>
Cc: Philip Homburg <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:
which requires fewer changes on the DHCP server implementation

This is almost certainly not true.  In order for this to work, you’re going to have to have some special-purpose code to support it.  Better to do the clean solution than a hack that minimizes changes to the server at the expense of more complication in the client-server interaction.

BV> Why are any changes needed to the server? It’s normal processing will work just fine … if the network segment has the new option configured, it will return it if the client requests it. Then the server will never see the DHCPREQUEST and the address assigned to the client will just “timeout” in a short period (at least on our server, within 2 minutes or whatever an administrator has configured) and be usable by other clients. End of story as client has turned off DHCPv4 and everyone is happy. And, no changes to anything on the server. This is not different than a case where there the client never sends a DHCPREQUEST or selects a DHCPREQUEST from a different server.

BV> If the client does proceed to a DHCPREQUEST, normal processing would happen, and client would get the lease (or perhaps receive a DHCPNAK is some other device was assigned the lease because the short time it had been held expired).

BV> This is all normal DHCPv4 processing and so no changes are needed.

Existing servers can deploy this without ANY changes (provided you have a means to configure the server with whatever option number is finally assigned).

I think it’s okay to require changes to the server.   This is a significant new feature.

BV> Why there is no need? Yes, you could do optimizations to (1) have perhaps a much shorter temporary assignment time or (2) use a “reserved” address for clients that request this option in the PRL. But these are not necessary, and everything works just fine without the changes.

Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and always include an address because you never know how intermediate devices that may be "snooping" this traffic will handle this; for example, the intermediate device might drop what it feels is an invalid packet.

This is definitely not an issue, though, because the network operator is choosing to deploy this.  They can be responsible for ensuring correct behavior if there are any middleboxes intercepting the DHCPv4 traffic and doing stuff with it.   Expecting this to Just Work with no infrastructure changes seems unnecessary.

BV> Why need this testing to confirm that middleboxes aren’t doing bad stuff. If you stick to normal DHCP semantics, nothing needs to be tested or changed in your infrastructure. Yes, I am expecting this to work with no infrastructure changes as this is STANDARD DHCP. The DHCPOFFER just never turns in to a DHCPREQUEST – so what … this can happen today on all DHCP networks if the client stops (powered down, disconnects from network).

There is a reason why DHCP includes a parameter request list option.  If the client doesn’t ask for this newfangled option, it shouldn’t see it.  And so we can know for sure that the client supports this capability, because it asked for it.

Even if a DHCP server sent the option without it being requested, why would the client use it if it didn't ask for it?

If the DHCP server knows the client supports the feature, it can assume that when it sends the option, the client will implement the specified behavior.   If it doesn’t know for sure that the client supports the feature, then you have to deal with a much more complex set of possible behaviors.   Why add that complexity?

And that’s assuming that the client behaves correctly.  If you just send the new option, another possibility is that the client crashes when it doesn’t recognize the option, as we used to see with certain printers I the manufacturer of which I will not mention.   Or that it does some other random thing.  Why chance it?

BV> If a DHCP client crashes when it receives an unknown option, my guess is that it would be quickly fixed as this just is broken behavior. Again, I’m not saying that a server should send this option if it wasn’t requested by a client, but I’m just clarifying your statements that even if a client were to see some arbitrary option that it didn’t request, it shouldn’t be doing anything with it. And, I would suspect that you would be hard pressed to find a client that crashes when it receives an unknown option.

BV> I will say that one issue that could exist with this option that is a bit unusual is that it is currently 0-length. We have only one other zero-length option that I recall, and that is Rapid Commit (which is client to server, not server to client). So, it is possible that there are clients that are unhappy about zero-length options. But again, in the ideal world no client will see this option unless it has requested it (in the PRL).