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

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

And, having this option just be returned by the server when requested and if configured means no server changes are needed. Servers aren’t swapped out (updated) as frequently as clients, so that’s a big win for deployment. And, that’s a strong reason to allow normal processing – and it also means no middlebox issues.

It is perfectly normal for a client to initiate a DHCPDISCOVER but never follow up with a DHCPREQUEST – the client disconnected or was power cycled or … So there’s nothing wrong with assigning a “real” address.

Again, I think (with any necessary (?) consideration of RFC2563) we can allow 0.0.0.0 to be returned.

See my earlier email on this topic (allowing either a real or 0.0.0.0 address to be returned by the server in yiaddr).


  *   Bernie

From: dhcwg <[e-mail]> On Behalf Of Lorenzo Colitti
Sent: Thursday, December 12, 2019 9:11 PM
To: Roy Marples <roy=[e-mail]>
Cc: [e-mail]; Ted Lemon <[e-mail]>; Bernie Volz (volz) <[e-mail]>
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

On Fri, Dec 13, 2019 at 10:35 AM Roy Marples <roy=[e-mail]<mailto:[e-mail]>> wrote:
> I really don't see why returning a fake address is preferable.

Please.

All documentation refers to the 0.0.0.0 address as UNSPECIFIED.
It's not fake, it's just all zeros.

UNSPECIFIED means just that. You cannot put ANY specification on it
otherwise it would not be UNSPECIFIED.

Starting a terminology discussion will not help settle this issue. What I'm talking about is an address that cannot be used by the client to communicate with the network. We can call an address fake, or green cheese, or whatever. The question is: why is it preferable to return such an address? It seems to me that it is preferable to return an address that could instead be used for communication.

> A real
> address is easier for many servers to return, and is more compatible
> with middleboxes.

We've already agreed that middleboxes HAVE to accept yiaddr unspecified
thanks to RFC2563.

Well, except that the middleboxes themselves don't agree. We can ignore them, but if we do, we run the risk of making things not work. We need to look at those risks and make trade-offs.

If a client changes it mind it can renew out of bounds and omit the new
option. It can say RENEW 1.2.3.4 and the server can OFFER 0.0.0.0.
In just the same way today that a client can request 10.0.0.1 and the
server will OFFER 192.168.0.1.

That doesn't seem very useful since the client doesn't know what to request. Sure, the client can send another discover (or, if it's in renewing or rebinding, another request) without the option. But if it has already received an address from the server, it doesn't need to do that. It can just request it.