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

[Roy Marples <[e-mail]>]

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