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

[Roy Marples <[e-mail]>]

On 13/12/2019 02:10, Lorenzo Colitti wrote:
> 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.

Plently of POSIX documents refer to all zero address as unspecified.
This is long standing.

If you want to call it fake, cheese or green or whatever is your bag.
But lets be clear, I didn't start the discussion, you started the fake news.


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

Because we sent an option to say we don't need an address.
If the server accepts this options any address returned we would just 
discard ....... so the actual use of this address is unspecified - do we 
use it or not?

Neo: WOAH

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

So far we have a middlebox that doesn't agree with *current* RFC's.
I don't see how the proposal to allow the unspecified address here can't 
break what is already broken?

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

Eh?
The client will request it's default set of options. This is what I see

Client - don't need an address if something better, but here I am!
Server - I don't have anything better, here's an address!
Client - I want to renew, but I understand if there's something better!
Server - Here lad, I know something better so deprecate and continue!
Client - I accept the unspecified address so I discard what I have and 
use something better!

In this case we've not made any extra requests, just accepted the 
response into the flow.

Is this not the underlying goal of the new RFC?

Roy