Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

No, it is not ridiculous. This is because this is the defined behavior as per RFC2131. 0.0.0.0 is not a valid address to assign to a device. And, your proposal would change that behavior which has been well established for over 20 years (since RFC2131 and probably even back to BOOTP). That is why it is not a good idea to change this well-established behavior.

Your analogy to Windows 95 is also bad as this was incorrect behavior which is different than changing the behavior.

- Bernie

-----Original Message-----
From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Ted Lemon
Sent: Thursday, December 12, 2019 11:16 AM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

On Dec 12, 2019, at 8:05 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> Just to add one additional point regarding middleboxes … I did confirm (not by actual testing but checking with developers) that at least one middlebox will not pass the DHCPOFFER if the address in the yiaddr field is not appropriate to the network segment the client is on. So, it would not let the DHCPOFFER with yiaddr of 0.0.0.0 go to the client. This is exactly the reason I think this is a bad idea and we MUST NOT do it; the address in the yiaddr must be a “normal” address that the client COULD use. (And asking the middlebox to change to allow an “invalid” address if the IPv6-only option is present in the DHCPOFFER would require a software/firmware update which is not desirable.)

Can you tell us what brand of middlebox this is?   What software version?   How long ago this behavior was last seen?

What you are saying here is effectively that for all eternity, we must configure this broken middlebox to believe that some IPv4 address that will never be assigned on a link is valid on the link, and configure the DHCP server to know what IPv4 subnet is valid on a particular link, even when IPv4 is no longer in use on that link.

This is, frankly, ridiculous.   If software is broken, we should not design our protocols around that brokenness.  Remember back when we did that for Microsoft’s broken implementation of ASCII strings in their DHCP client back in ~Windows 95?   And now that code is still in every DHCP server?  This is a similar situation.

The reality is that if a network operator wants to be able to disable IPv4 for clients that can use IPv6, they are going to be motivated to fix brokenness on their network.   If they don’t care to do that, they probably aren’t going to bother with this anyway.   And if they don’t care to do that, it’s really not our problem.

You, as a Cisco employee, can perfectly well configure your DHCP server to always send an IP address that works on the link, and this middlebox will still work.   But if we say that DHCP servers MUST not use a fixed address (e.g. 0.0.0.0), then we are saying not that you can choose to do this, but that we are all forced to do this.   That’s the wrong call.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg