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

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

> You can argue that said boxes are not RFC compliant, but that is the same as the argument here - nothing in the standard says that 0.0.0.0 cannot be offered.

Yes, there is no text that directly says 0.0.0.0 MUST NOT be offered. But it is pretty clear:

Field      DHCPOFFER            DHCPACK             DHCPNAK
-----      ---------            -------             -------
...
'yiaddr'   IP address offered   IP address          0
           to client            assigned to client

Offering 0.0.0.0 is not given the client an address it can use. There's plenty of documents that document 0.0.0.0 is not a destination address on the network. I can't see how in the absence of this use case, 0.0.0.0 would ever be a valid yiaddr in a DHCPOFFER.

And, when given two choices - one that clearly works (offer an address that the client could use) vs offering 0.0.0.0 which could have issues, why would you chose to do something that you know has a chance of breaking things. It just makes no sense to do so. And, this option is for the case where IPv4 service IS available to clients that need it, but if the client doesn't need it and can use IPv6 transition mechanism for IPv4 service.

Nothing we "change" or "enhance" is 100% certain to work everywhere - there are just too many (often broken) assumptions people make. But that's exactly my argument for assigning a real address - one less risk you need to take that something somewhere will break because it wasn't expected. Thank you for your cases where this demonstrates why being conservative in what we do is best.

And, in terms of being conservative, if someone (a vendor, a site) has used whatever option value IANA eventually assigns to the IPv6-only option and a client sends it in the PRL, this will cause problems as the client is not using it as "IPv6-only" and so it will fail because it will either think the server's reply with a yiaddr of 0 is bad or it will try a DHCPREQUEST and fail to get any address (likely will get a DHCPNAK). This process will repeat and the client will not come online. If instead the server sends a usable address, the client will likely be happy and come online (though it may not understand the returned option data).

Finally, if you're hinting that if something is going to break (ignoring the offered address issue) if the IPv6-only option is present, there's not much we can do about that except hope that it is fixed. Or, perhaps we should stop issuing new option assignments?

- Bernie

-----Original Message-----
From: dhcwg <[e-mail]> On Behalf Of Roy Marples
Sent: Thursday, December 12, 2019 3:37 PM
To: Bernie Volz (volz) <[e-mail]>; David Farmer <[e-mail]>; Ted Lemon <[e-mail]>
Cc: [e-mail]
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

On 12/12/2019 16:04, Bernie Volz (volz) wrote:
> Hi:
> 
> 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.)
MUST is such a strong word .....

Taking your view should we scrap these RFC's as there are boxes in the wild that refuse DHCP leases if the option is present:

RFC4039 - Rapid Commit
RFC4361 - Node specific client id
RFC4702 - DHCP FQDN (when DNS encoding is used)

I could spend time trawling the dhcpcd list archives for more (these are just off the top of my head) but I don't have the time right now.

I've always taken the view that dhcpcd should support all RFC's and enable modern defaults. I don't see this changing here...
I can quite easily see the same boxes refusing leases if the client supplies this new option - so again, taking your view - it should not be enabled by default.

You can argue that said boxes are not RFC compliant, but that is the same as the argument here - nothing in the standard says that 0.0.0.0 cannot be offered.

Roy

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg