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

[Roy Marples <[e-mail]>]

On 12/12/2019 21:02, Bernie Volz (volz) wrote:
>> 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.

But yet there is no error assiging the unspecified address to an interface.
On BSD, it shows as an address via ifconfig.
On Linux and Solaris it removes any currently assigned address (via 
ifconfig).

Now on BSD (historically) it actually had a use - it needed to be 
assigned to get DHCP to work (this is no longer an issue, just noting 
it). Some PPP/VPN implementations (on BSD and other OS) also assign the 
unspecified address like so.

Does it go anywhere? No. But that's not the point - the address *as an 
address* is valid. How it's used by the host is entirely upto the host.
Any middleware specifying unspecified behaviour is broken by design.

> 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.

I see an issue with being handed an address and a faulty client which 
implements this option performing DAD, spots a host that's actually 
using it and then declining the lease.

Using the unspecified address clearly works here.

So which is more at fault - trying to validate currently undefined 
behaviour to trying to validate an address offered?

Both are equally at fault in my eyes, thus the better semantic of 
offering an unspecified address wins.

> 
> 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.

Agreed

> 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).

This is true.
However, in this case the standard is currently undefined behaviour for 
this option.
We are talking about defining it - exactly the same as the unspecified 
address here. It's currently undefined and your middleware box has the 
same issue as this vendor with the duplicated code.

> 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?

And the reason we can't take the same stance with your middleware box is?

Also, the breakage I am referring to is no lease offered at all - the 
upstream box is totally silent in all cases.

Roy