Re: [dhcwg] RFC3315 DECLINE definition

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

No.

DECLINE means address is bad (duplicated). DECLINE is only valid after Reply, not after Advertise. 

RELEASE means client does not want to use the address provided.

I don't see any benefit to change this.

- Bernie

-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[e-mail]] 
Sent: Wednesday, February 08, 2017 5:38 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: dhcwg <[e-mail]>
Subject: RE: RFC3315 DECLINE definition

Understand the concern. The client should be able to DECLINE addresses in both ADVERTISE and REPLY. Receiving the REPLY does not mean that a unique address must be assigned to the interface. If a client DECLINEs the ADVERTISEd or REPLIEd address, DHCPV6 server should be able to advertise another address.

The client should also be able to tell that is does not want another address. For example, if RENEW/REBIND returns a new address, the client should be able to DECLINE it.

Regards,
Dusan.

-----Original Message-----
From: Bernie Volz (volz) [mailto:[e-mail]] 
Sent: Wednesday, February 08, 2017 5:28 PM
To: Mudric, Dusan (Dusan)
Cc: dhcwg
Subject: RE: RFC3315 DECLINE definition

I'm confused ... advertised vs assigned addresses. Once a Reply is received, the address is assigned -- no longer advertised.

DECLINE means that the address is in use. If the client DECLINEs it and just makes it available immediately, the next client to get that address assigned and does DAD will also find a conflict ... so what’s the value of that.

Generally, declined addresses should not be used for a while (that is policy dependent) since it means some other device is using the address.


I thought you were trying to say a Decline sent in response to an Advertise would tell the server "I don't want those addresses". But that is not meaningful and why would a client even try to do that. Also, an Advertise is just that -- and advertisement; it is not a commitment to assigned those addresses -- the client can only use the addresses in the Reply. (DHCPv4 is a bit different in this respect -- the address in the Offer must be same as in the Ack. DHCPv6 has no such hard requirement -- it usually is, but that's not required.)

- Bernie

-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[e-mail]] 
Sent: Wednesday, February 08, 2017 5:19 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: dhcwg <[e-mail]>
Subject: RE: RFC3315 DECLINE definition


Hi Bernie,

I am talking about DECLINE after REPLY. What I am  proposing is to use DECLINE for "I don't want your Advertised address(es)". I think this will be much cleaner then to let the server timeout the advertised addresses, which can take long.

Thanks,

Dusan

-----Original Message-----
From: Bernie Volz (volz) [mailto:[e-mail]] 
Sent: Wednesday, February 08, 2017 4:57 PM
To: Mudric, Dusan (Dusan); 神明達哉; Lishan Li
Cc: dhcwg
Subject: RE: RFC3315 DECLINE definition

Dusan:

DECLINE is used after a REPLY, not after an ADVERTISE.

A client has not been assigned an address until it receives the REPLY (at which point it does DAD and may send a DECLINE).

There is no mechanism for a client to indicate to a server "I don't want your Advertised address(es)", except by not proceeding to send a REQUEST.

The server may have held the address "reserved" for a short period of time, but does that really matter? IPv6 addresses are not in short supply.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Wednesday, February 08, 2017 4:47 PM
To: 神明達哉 <[e-mail]>; Lishan Li <[e-mail]>
Cc: dhcwg <[e-mail]>
Subject: [dhcwg] RFC3315 DECLINE definition

Hi,

Can DECLINE definition be extended beyond the DAD usage? I think DECLINE should be used every time DHCPV6 client decides not to assign the offered address, for any reason, not just the address is duplicate. When receiving DECLINE, DHCPV6 server should be able to immediately make the same address available in the address pool for the other clients.

Regards,
Dusan.

_______________________________________________
dhcwg mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQIFJg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&s=e5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=