Re: [dhcwg] RFC3315 DECLINE definition

["Mudric, Dusan (Dusan)" <[e-mail]>]

Hi Bernie,

That is the current use of DECLINE (only for DAD). https://tools.ietf.org/html/rfc3315#section-17.1.3 only focuses on the server selection after ADVERTISE is received. It does not mention that DHCPv6 client might not be happy with the advertised addresses. IPv6 defines different kinds of addresses and allows multiple addresses, making it more complex to handle. If a server offers IPv6 address that client cannot use (e.g. a multicast address, a second address), the client should be able to decline it.

Again, if the server sends REPLY or REBIND with an address the client cannot use, the client should be able to DECLINE it.

DECLINE should be defined as a response for the addresses that cannot be assigned. 

These are the issues I identified during DHCPv6 testing and analysis and they need to be addressed with the new definition for DECLINE.

Regards,
Dusan.

-----Original Message-----
From: Bernie Volz (volz) [mailto:[e-mail]] 
Sent: Thursday, February 09, 2017 9:06 AM
To: Mudric, Dusan (Dusan)
Cc: dhcwg
Subject: Re: RFC3315 DECLINE definition

Again, DECLINE Is only after REPLY received. Not Advertise.

- Bernie

On 2/9/17, 8:57 AM, "Mudric, Dusan (Dusan)" <[e-mail]> wrote:

    Hi Bernie,
    
    I agree with the definition: " DECLINE means address is bad". What I am saying is that "bad" does not only mean "duplicated". Applications and devices can have other reasons to thing about the offered address to be "bad". If they find the address  is "bad" for any reason, they can send DECLINE. Even the current DHCPv6 protocol does not prevent the DHCPv6 client to send DECLINE for ADVERTISE and REPLY. It is the server that should use it efficiently.
    
    Regards,
    Dusan.
    
    -----Original Message-----
    From: Bernie Volz (volz) [mailto:[e-mail]] 
    Sent: Wednesday, February 08, 2017 5:52 PM
    To: Mudric, Dusan (Dusan)
    Cc: dhcwg
    Subject: RE: RFC3315 DECLINE definition
    
    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=