Re: [dhcwg] RFC3315 DECLINE definition

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

I am going to give up on this debate with you.

There are no plans to change any of this. Perhaps another RFC3315bis author will take this up with you.

- Bernie

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

    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=