Subject: [dhcwg] RFC3315 DECLINE definition

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 8 Feb 2017 21:46:49 +0000

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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Feb 2017 21:57:03 +0000

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:[email-masked]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Wednesday, February 08, 2017 4:47 PM
To: 神明達哉 <[email-masked]>; Lishan Li <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: [dhcwg] RFC3315 DECLINE definition

Hi,

Regards,
Dusan.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 8 Feb 2017 22:19:20 +0000

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:[email-masked]] 
Sent: Wednesday, February 08, 2017 4:57 PM
To: Mudric, Dusan (Dusan); 神明達哉; Lishan Li
Cc: dhcwg
Subject: RE: RFC3315 DECLINE definition

Dusan:

- Bernie

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

Hi,

Regards,
Dusan.

_______________________________________________
dhcwg mailing list
[email-masked]
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=

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Feb 2017 22:28:29 +0000

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:[email-masked]] 
Sent: Wednesday, February 08, 2017 5:19 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: RE: RFC3315 DECLINE definition

Hi Bernie,

Thanks,

Dusan

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

Dusan:

- Bernie

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

Hi,

Regards,
Dusan.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 8 Feb 2017 22:37:55 +0000

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:[email-masked]] 
Sent: Wednesday, February 08, 2017 5:28 PM
To: Mudric, Dusan (Dusan)
Cc: dhcwg
Subject: RE: RFC3315 DECLINE definition

- Bernie

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

Hi Bernie,

Thanks,

Dusan

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

Dusan:

- Bernie

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

Hi,

Regards,
Dusan.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Feb 2017 22:51:54 +0000

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:[email-masked]] 
Sent: Wednesday, February 08, 2017 5:38 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: RE: RFC3315 DECLINE definition

Regards,
Dusan.

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

- Bernie

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

Hi Bernie,

Thanks,

Dusan

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

Dusan:

- Bernie

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

Hi,

Regards,
Dusan.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 13:57:57 +0000

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:[email-masked]] 
Sent: Wednesday, February 08, 2017 5:52 PM
To: Mudric, Dusan (Dusan)
Cc: dhcwg
Subject: RE: RFC3315 DECLINE definition

No.

- Bernie

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

Regards,
Dusan.

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

- Bernie

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

Hi Bernie,

Thanks,

Dusan

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

Dusan:

- Bernie

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

Hi,

Regards,
Dusan.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Feb 2017 14:05:57 +0000

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

- Bernie

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

    Hi Bernie,

    Regards,
    Dusan.
    
    -----Original Message-----
    From: Bernie Volz (volz) [mailto:[email-masked]] 
    Sent: Wednesday, February 08, 2017 5:52 PM
    To: Mudric, Dusan (Dusan)
    Cc: dhcwg
    Subject: RE: RFC3315 DECLINE definition
    
    No.

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

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

    

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

    Hi Bernie,

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

    

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

    Regards,
    Dusan.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Feb 2017 14:34:09 +0000

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)" <[email-masked]> 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:[email-masked]] 
    Sent: Thursday, February 09, 2017 9:06 AM
    To: Mudric, Dusan (Dusan)
    Cc: dhcwg
    Subject: Re: RFC3315 DECLINE definition

    - Bernie

        Hi Bernie,

        Regards,
        Dusan.
        
        -----Original Message-----
        From: Bernie Volz (volz) [mailto:[email-masked]] 
        Sent: Wednesday, February 08, 2017 5:52 PM
        To: Mudric, Dusan (Dusan)
        Cc: dhcwg
        Subject: RE: RFC3315 DECLINE definition
        
        No.

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

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

        

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

        Hi Bernie,

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

        

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

        Regards,
        Dusan.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 14:31:51 +0000

Hi Bernie,

Regards,
Dusan.

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

- Bernie

    Hi Bernie,

    Regards,
    Dusan.
    
    -----Original Message-----
    From: Bernie Volz (volz) [mailto:[email-masked]] 
    Sent: Wednesday, February 08, 2017 5:52 PM
    To: Mudric, Dusan (Dusan)
    Cc: dhcwg
    Subject: RE: RFC3315 DECLINE definition
    
    No.

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

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

    

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

    Hi Bernie,

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

    

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

    Regards,
    Dusan.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 14:41:47 +0000

How can I contribute to RFC3315bis? What is the process?

Thanks,
Dusan.

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

- Bernie

    Hi Bernie,

    That is the current use of DECLINE (only for DAD). https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3315-23section-2D17.1.3&d=DQIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=va1H3sY0nZfdHc4DGFCUKBibOvOa4LPIc1ocUAnuSGE&s=_xJn0q4zqX9LI5qVJntOoIaKkhd7TLAv7O8O3SmQTOQ&e=  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.

    Regards,

    Dusan.

    -----Original Message-----

    Cc: dhcwg

    - Bernie

        Hi Bernie,

        Regards,

        Dusan.

        -----Original Message-----

        Cc: dhcwg

        No.

        - Bernie

        -----Original Message-----

        Regards,

        Dusan.

        -----Original Message-----

        Cc: dhcwg

        

        - Bernie

        -----Original Message-----

        

        Hi Bernie,

        Thanks,

        Dusan

        -----Original Message-----

        Cc: dhcwg

        Dusan:

        - Bernie

        -----Original Message-----

        Hi,

        Regards,

        Dusan.

        dhcwg mailing list

        [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 09:55:38 -0500

> How can I contribute to RFC3315bis? What is the process?

The first step would be to figure out what you want, why you want it, and why anybody should care about it.   Then you explain that on the mailing list and see if you get some interest.

From reading what you've said so far, what you want is the ability for a client to say it doesn't like a particular address, with the intended effect that if it asks for another address, it will get a _different_ address.   But your intended semantics are unclear, and I don't see how the server can usefully address this use case.   You'd need to explain that.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Feb 2017 15:21:55 +0000

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

The big problem I see here is that you are extending the "cannot use" problem from one where it applies to all clients (eg duplicate address) to one where **THIS** client cannot use for some local (to the client) reason and which may well not apply to other clients. it's already been stated (AIUI) that there is no mechanism for the client to tell the server WHY it's declining, and hence any decline can only be processed as "this address is bad for all clients".

It might help if you gave an example of a setup where a sensibly configured server and client have this problem. You mention getting a multicast address, but (and bear in mind I'm barely at the "crawled of of the primordial ooze" level with DHCP6, so I don't know how the client/server differentiate between different types of addresses) surely if the client can't use a multicast address - why is it asking for one ? If the server is offering multicast addresses routinely, then why is it configured that way ?

If the client "just wants a different address" then surely the way to do that is simply solicit for a new lease, using a different identifier so the server will give it an additional address - and the client can simply stop using the old address and let it's lease lapse.

You've already been told that coming here and just saying "this is wrong" won't work.
You need to explain why it's wrong, why this is an issue for more than just yourself, and most importantly - why it's a big enough issue to justify changing the standards and imposing development load on all creators/vendors of DHCP6 server and client software to implement that change.
Part of the justification involves specific use cases - along the lines of "people who use X to do Y suffer issue Z". You have not done that so far.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 15:38:01 +0000

Hi Ted,

Let's start with the problem statements:

1.       When DHCPv6 client starts it sends SOLICIT with IA option (without or with IPv6 address). The server sends ADVERTISE message offering IPv6 address(es). If the server offers IPv6 address(es) that client cannot use (e.g. an address with wrong semantics, a multicast address, a reserved address, ... , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

2.       After T1 the client needs to RENEW the address. If REPLY from the server has new IPv6 address(es) that client cannot use (e.g. a multicast address, a reserved address, ... , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

3.       After T2 the client needs to REBIND the address. If REBIND from the server has new IPv6 address(es) that client cannot use (e.g. a multicast address, a reserved address, ... , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

4.       If the client cannot use the offered address, it might be left in one of the two states:

a.       Without any IPv6 address, or

b.      Still has IPv6 address in preferred state

a)      The client does not have IPv6 address and needs immediately another offer from the DHCPv6 server with a different address (e.g. a global, unreserved address)

b)      With a valid IPv6 address

a.       The client has IPv6 address it can use during the valid life time and needs another address from DHCPv6 server (e.g. with a different address type) before the valid life time expires

b.      The client cannot handle the address change and does not need the new address from DHCPv6 server

c.       The client has IPv6 address it can use and does not need multiple addresses from DHCPv6 server

5.       DHCPv6 server should

a.       Offer a different address type, or

b.      Make the address available to other clients, or

c.       Block the address for further use (e.g. the address was invalid).

I propose that DECLINE should be defined as a response for the addresses that cannot be assigned. There can be a reason code in DECLINE helping the server interpret the response.

Regards,
Dusan Mudric.

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 9:56 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz (volz); dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 9, 2017, at 9:41 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
How can I contribute to RFC3315bis? What is the process?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 10:40:33 -0500

On Feb 9, 2017, at 10:38 AM, Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 1.       When DHCPv6 client starts it sends SOLICIT with IA option (without or with IPv6 address). The server sends ADVERTISE message offering IPv6 address(es). If the server offers IPv6 address(es) that client cannot use (e.g. an address with wrong semantics, a multicast address, a reserved address, … , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

Let me stop you here.   This is a server misconfiguration.   The server is not artificially intelligent, so the client can't usefully tell the server it is misconfigured.   If the server is configured to hand out addresses with the wrong semantics, the solution is to fix the server, not complicate the protocol with a way for the client to tell the server something it can't do anything about.   This also needlessly complicates the client.

So why do you think this is a useful thing to do?   What non-hypothetical problem are you trying to solve here?

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 15:46:14 +0000

The first problem statement is about the server misconfiguration. Instead of client silently ignoring the offered address, or even worse, assigning the misconfigured address, the server (and administrator) should be informed about the misconfiguration.

Regards,
Dusan Mudric.

Sent: Thursday, February 09, 2017 10:41 AM

On Feb 9, 2017, at 10:38 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
1.       When DHCPv6 client starts it sends SOLICIT with IA option (without or with IPv6 address). The server sends ADVERTISE message offering IPv6 address(es). If the server offers IPv6 address(es) that client cannot use (e.g. an address with wrong semantics, a multicast address, a reserved address, … , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

---

From: "Ted Lemon" <[email-masked]>
Date: Thu, 09 Feb 2017 10:48:17 -0500

On 9 Feb 2017, at 10:46, Mudric, Dusan (Dusan) wrote:
> The first problem statement is about the server misconfiguration. 
> Instead of client silently ignoring the offered address, or even 
> worse, assigning the misconfigured address, the server (and 
> administrator) should be informed about the misconfiguration.

How does this make things better?

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 16:06:08 +0000

Let's say there is a deployment within an enterprise of 20 000 devices, each with DHCPv6 enabled. They are on different locations and use different DHCPv6 servers. One server is configured to statically assign IPv6 addresses (based on the client MAC) or with a pool of IPv6 addresses for the local link. If a client on that location assigns the misconfigured address it becomes unreachable. A user does not even know how to spell DHCPv6 and all he/she experiences is that the device is unusable. The network operator does not get any indication that the device is out of service.

If the client is able to tell the server that the address cannot be used, the administrator should be able to get some notification about the problem (e.g. an alarm), and find in the server log there was the configuration problem. The server might be able to automatically solve the issue. For example, the server can be configured with different address pools (e.g. using different address types) and the server can offer the address from a different address pool.

Regards,
Dusan.

---

From: Andre Kostur <[email-masked]>
Date: Thu, 9 Feb 2017 08:12:58 -0800

> Let's say there is a deployment within an enterprise of 20 000 devices, each with DHCPv6 enabled. They are on different locations and use different DHCPv6 servers. One server is configured to stati…

Assigns what misconfigured address?  The client will either do a naked
SOLICIT and get the reserved IP that the server was configured to give
it, or it will do a CONFIRM with the address it obtained from a
different link and the server will REPLY for that address giving it 0
lifetimes to instruct the client that the address is no longer usable.
Then the client goes back to the SOLICIT and gets the reserved IP that
the server was configured to give it.

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 11:24:34 -0500

> If the client is able to tell the server that the address cannot be used, the administrator should be able to get some notification about the problem (e.g. an alarm), and find in the server log the…

How does the client know that the address "cannot be used"?

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 16:24:54 +0000

” The client will either do a naked SOLICIT and get the reserved IP that the server was configured to give it"

That configured IP might be an address that the client cannot use.

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]] 
Sent: Thursday, February 09, 2017 11:13 AM
To: Mudric, Dusan (Dusan)
Cc: Ted Lemon; dhcwg; Bernie Volz
Subject: Re: [dhcwg] RFC3315 DECLINE definition

> Let's say there is a deployment within an enterprise of 20 000 devices, each with DHCPv6 enabled. They are on different locations and use different DHCPv6 servers. One server is configured to stati…

Assigns what misconfigured address?  The client will either do a naked SOLICIT and get the reserved IP that the server was configured to give it, or it will do a CONFIRM with the address it obtained from a different link and the server will REPLY for that address giving it 0 lifetimes to instruct the client that the address is no longer usable.
Then the client goes back to the SOLICIT and gets the reserved IP that the server was configured to give it.

--
Andre Kostur

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 16:28:24 +0000

The DHCPv6 client gets the address. Since I did not want to change the client, I passed the address to the application to do the validation. The application found out the address is not usable. The client can get a feedback from the application that the address is not usable, or the client can be configured with the policy rules to validate the address itself.

Dusan

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 11:25 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 9, 2017, at 11:06 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
If the client is able to tell the server that the address cannot be used, the administrator should be able to get some notification about the problem (e.g. an alarm), and find in the server log there was the configuration problem. The server might be able to automatically solve the issue. For example, the server can be configured with different address pools (e.g. using different address types) and the server can offer the address from a different address pool.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 11:30:29 -0500

> The DHCPv6 client gets the address. Since I did not want to change the client, I passed the address to the application to do the validation. The application found out the address is not usable. The…

How does the application determine that the address is not usable?   What is the validation process?

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 16:37:11 +0000

The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example, the device has to be globally reachable, the address has to be an unreserved, or not deprecated, global address.

Dusan

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 11:30 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 9, 2017, at 11:28 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
The DHCPv6 client gets the address. Since I did not want to change the client, I passed the address to the application to do the validation. The application found out the address is not usable. The client can get a feedback from the application that the address is not usable, or the client can be configured with the policy rules to validate the address itself.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 11:39:20 -0500

> The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which dev…

OK.   Why can't the DHCP server do this validation?

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Feb 2017 16:46:21 +0000

"Mudric, Dusan (Dusan)" <[email-masked]> wrote:

> One server is configured to statically assign IPv6 addresses (based on the client MAC) or with a pool of IPv6 addresses for the local link. If a client on that location assigns the misconfigured address it becomes unreachable. A user does not even know how to spell DHCPv6 and all he/she experiences is that the device is unusable. The network operator does not get any indication that the device is out of service.

And just how does the client differentiate between that being a deliberate policy choice by the admin (perhaps that location is not supposed to have outside IPv6 connectivity) and a server misconfiguration ?
Besides, just how is that different from other (eg DHCP4) setups ? If I configure the HCP server to give the wrong router address then clients get broken network configs.

At the end of the day, unless you are going to build an all-knowing, globe spanning, AI service that auto-configures everything - then you have to allow for admins to have some intelligence and some competency in their work. So far I've seen nothing in your suggestions that goes beyond "the admin may make a mistake and then things are broken". yes we can make mistakes - but finding and dealing them is part of the job.

So, other than "the admin may make a mistake", what use cases do you have ?

> The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which dev…

You have **NOT** described anything related to whether the address issued is usable at the network level, basically at the level DHCP is working at. By your own admission, the device **DOES** have a valid working address, but for some reason the **APPLICATION** cannot use it. The **APPLICATION** should report that there is a communications problem - this is how it works normally. The address may well be perfectly usable for other traffic.

Part of troubleshooting such an issue is to look at the network connectivity and the requirements of the application. This sounds very much like the refrain you hear from users who declare "the internet is down" because the web page they are trying to reach isn't working.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 16:47:42 +0000

The server can do the same validation. If the server does the validation, it will be a new feature and there will be a mix of servers that do and do-not provide this validation. The client either has to talk to the server that does provide the validation or do the validation itself.

This is the first problem statement. There are two more:

-          Assignment of multiple IPV6 addresses, that the client cannot support

-          A change of IPv6 address, that the client cannot handle

Dusan

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, February 09, 2017 11:39 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 9, 2017, at 11:37 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example, the device has to be globally reachable, the address has to be an unreserved, or not deprecated, global address.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 9 Feb 2017 16:53:18 +0000

" By your own admission, the device **DOES** have a valid working address, but for some reason the **APPLICATION** cannot use it."

I was just saying the validation is done in the application because DHCPv6 client cannot do it. It is about the network reachability and not about the application. Site-Local (FEC0::/10), for example, cannot be used by any device (RFC 3879: Deprecating Site Local Addresses. The prefix MUST NOT be reassigned for other use except by a future IETF standards action.)

Dusan

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Thursday, February 09, 2017 11:46 AM
To: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

_______________________________________________
dhcwg mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=KqFrsW5PMmj9eF_ImRLdVyBEBXnnp1_49yauNwdixwE&s=nl7CEbTMCiHR8hrfTbjU1VqkR6r2wFunbJnd1xj5SKk&e=

---

From: Andre Kostur <[email-masked]>
Date: Thu, 9 Feb 2017 08:59:43 -0800

> -          Assignment of multiple IPV6 addresses, that the client cannot

Already dealt with by the protocol.  The server OFFERs 2 addresses,
the client just REQUESTs one of them.

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Feb 2017 12:13:54 -0500

> The server can do the same validation. If the server does the validation, it will be a new feature and there will be a mix of servers that do and do-not provide this validation. The client either h…

So why is it easier to have the client do the validation than the server?   You're adding protocol to make this work, and in order for this to be useful, changes are required on the server anyway.   These changes are quite a bit more complex than the changes required to simply do whatever validation you are arguing should be done.   So why not do it the easy way instead of the hard way?
 
> -          Assignment of multiple IPV6 addresses, that the client cannot support

Then the client is broken.   Why not fix it instead of adding more protocol?

> -          A change of IPv6 address, that the client cannot handle

Again, the client is broken.   Why not fix it instead of adding more protocol?

---

From: Andre Kostur <[email-masked]>
Date: Thu, 9 Feb 2017 09:14:30 -0800

> I was just saying the validation is done in the application because DHCPv6 client cannot do it. It is about the network reachability and not about the application. Site-Local (FEC0::/10), for examp…

So you don't configure your DHCP server to give out those IP
addresses.  Problem solved.  This doesn't need a protocol change.  And
should it (the FEC0::/10 prefix) be reassigned for other uses in a
future IETF standards action, then one would need to change your
application again, and/or change the DHCP server again.   And, the
application may be in use in some network that already has that prefix
in use because that network has not had the time to renumber that
prefix into something like a Unique Local IPv6 prefix (RFC 4193).

-- 
Andre Kostur

---

From: Simon Hobson <[email-masked]>
Date: Thu, 9 Feb 2017 17:23:18 +0000

> -          Assignment of multiple IPV6 addresses, that the client cannot support

I thought it was part of the spec that a client must be capable of being configured with multiple addresses. As a minimum it must support 2 - one link-local, and one globally unique if external connectivity is needed.

> I was just saying the validation is done in the application because DHCPv6 client cannot do it. It is about the network reachability and not about the application. Site-Local (FEC0::/10), for examp…

1) How does the application know that allocation of such addresses isn't a deliberate policy decision ?
2) It's an "admin error" anyway and it will either a) be spotted fairly quickly due to the lack of connectivity, b) obviously isn't that important.

And as I said before, there is nothing to stop the admin putting (say) an incorrect router address in DHCPv4 - and I can't say I've seen a lot of clamour for "we must handle this automatically" features.

---

From: Tim Chown <[email-masked]>
Date: Fri, 10 Feb 2017 10:13:29 +0000

> On 9 Feb 2017, at 17:23, Simon Hobson <[email-masked]> wrote:
> 

RFC 7934 is a good read on that topic, though as I think Bernie pointed out the DHCP set in Section 6 could have been slightly better written.

> And as I said before, there is nothing to stop the admin putting (say) an incorrect router address in DHCPv4 - and I can't say I've seen a lot of clamour for "we must handle this automatically" fea…

Well, it’s a reason why those who favour hosts fate-sharing router discovery with their router(s) via RAs have objected to adding a DHCPv6 default gateway option. In a changing network topology/scenario, the DHCP server may not be configured with up-to-date information, or even after it is hosts may not have requested it.

I’m with Ted here - I am not sure what problem this suggestion really solves.  Or maybe it’s a reason to use SLAAC.

Tim

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 10 Feb 2017 14:35:03 +0000

Thanks for all the comments. Personally, I don't think DHCPv6 should be used for the address assignment. That topic is already discussed in a different thread. Will not discuss it here. But, if it is used for the address assignment, I would like all of the questions below to be addressed by the protocol.

On  this topic, there are several open questions about DHCPv6 protocol:

- If the key feature of the stateful DHCPv6 is the address assignment, why there is no any address validation?

- Why is the human intervention a part of the protocol? Why the protocol requires an administrator not to make mistakes?

- Why the client must assign every address offered by the server? Why should the client save the advertised leases for every IAADDR in IA's, if the status code is STATUS_Success?

- Why the client must use the address that does not match any of the router prefixes?

- Why the client is not interworking with ND protocol?

- Why the client does not return the address it does not use?

- Why is DECLINE message associated with only one error code (DAD failed)?

In terms of the implementation, when the problems are understood, both the server and the client can be improved. The improvements can be done in flexible ways. For example, DHCPv6 client policies can be configured in the client configuration file. There is no need to change the client code.

Regards,

Dusan.

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Thursday, February 09, 2017 12:23 PM
To: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

> I was just saying the validation is done in the application because

> DHCPv6 client cannot do it. It is about the network reachability and

> not about the application. Site-Local (FEC0::/10), for example, cannot

> be used by any device (RFC 3879: Deprecating Site Local Addresses. The

> prefix MUST NOT be reassigned for other use except by a future IETF

> standards action.)

So you don't configure your DHCP server to give out those IP addresses.  Problem solved.  This doesn't need a protocol change.  And should it (the FEC0::/10 prefix) be reassigned for other uses in a future IETF standards action, then one would need to change your

application may be in use in some network that already has that prefix in use because that network has not had the time to renumber that prefix into something like a Unique Local IPv6 prefix (RFC 4193).

--

Andre Kostur

On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
The server can do the same validation. If the server does the validation, it will be a new feature and there will be a mix of servers that do and do-not provide this validation. The client either has to talk to the server that does provide the validation or do the validation itself.

> -          Assignment of multiple IPV6 addresses, that the client cannot

> support

Already dealt with by the protocol.  The server OFFERs 2 addresses, the client just REQUESTs one of them.

--

Andre Kostur

dhcwg mailing list

[email-masked]<mailto:[email-masked]>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=2pBdk64V6N1NIvcAysqRqvG-d1lULT9TqIVtrbk-o8w&s=1tSJd7nDKcvuC97XDWtrkjskLaJPuQovExyz6N3kI_A&e=

---

From: Andre Kostur <[email-masked]>
Date: Fri, 10 Feb 2017 08:25:20 -0800

> there is no any address validation?

You need to be clear on what you mean by "address validation".  (Oh,
and DHCPv6 is responsible for both address and prefix assignment)

> - Why is the human intervention a part of the protocol? Why the protocol
> requires an administrator not to make mistakes?

Everything is susceptible to human error.  You need to have more
specific use-cases to get anywhere near this question.  Also, the
protocol does not mandate configuration management.  Perhaps your DHCP
server has the capability of comparing its configuration with that on
a router to look for certain potential configuration mismatches.  But
that's a quality of implementation issue, not a protocol issue.

> - Why the client must assign every address offered by the server? Why should
> the client save the advertised leases for every IAADDR in IA’s, if the
> status code is STATUS_Success?

It doesn't have to.  The client can pick and choose, preferably at the
ADVERTISE/REQUEST stage.  The server ADVERTISEs a dozen addresses, the
client decides that it wants only 1 of them and REQUESTs it.   Or a
less well-behaved client could REQUEST them all, but only actually
configure one of them on an interface.

> - Why the client must use the address that does not match any of the router

The router may not be advertising any prefixes, so the client doesn't
know any different.  (Nor should it)

> - Why the client is not interworking with ND protocol?

Be more specific.  ND covers a lot of ground.

> - Why the client does not return the address it does not use?

Talk to your client vendor.  The client can return addresses by
protocol.  Either by not REQUESTing it in the first place (though this
isn't returning an address, it's just not claiming it), or by
RELEASEing it.

> - Why is DECLINE message associated with only one error code (DAD failed)?

No use-case has been presented that the DHC working group has agreed
upon that a DECLINE for other reasons is the appropriate response.

-- 
Andre Kostur

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 10 Feb 2017 17:10:35 +0000

Hi Andre,

Please see inlined

Thanks,
Dusan.

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]]
Sent: Friday, February 10, 2017 11:25 AM
To: Mudric, Dusan (Dusan)
Cc: Simon Hobson; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

> why there is no any address validation?

You need to be clear on what you mean by "address validation".  (Oh, and DHCPv6 is responsible for both address and prefix assignment)

[Dusan] - Syntax checks
              - Semantic checks
              - Prefix checks

> - Why is the human intervention a part of the protocol? Why the
> protocol requires an administrator not to make mistakes?

Everything is susceptible to human error.  You need to have more specific use-cases to get anywhere near this question.  Also, the protocol does not mandate configuration management.  Perhaps your DHCP server has the capability of comparing its configuration with that on a router to look for certain potential configuration mismatches.  But that's a quality of implementation issue, not a protocol issue.

[Dusan] If the server communicates with a router to compare the configuration, it is a protocol

> - Why the client must assign every address offered by the server? Why
> should the client save the advertised leases for every IAADDR in IA’s,
> if the status code is STATUS_Success?

It doesn't have to.  The client can pick and choose, preferably at the ADVERTISE/REQUEST stage.  The server ADVERTISEs a dozen addresses, the
client decides that it wants only 1 of them and REQUESTs it.   Or a
less well-behaved client could REQUEST them all, but only actually configure one of them on an interface.

[Dusan] Which section in RFC3315 defines how DHCPv6 client selects the leases? Which section defines what the client does with non-selected leases?

> - Why the client must use the address that does not match any of the

The router may not be advertising any prefixes, so the client doesn't know any different.  (Nor should it)

[Dusan] What if the router advertised a prefix and the client received an address that does not start with the prefix?

[Dusan] DHCPv6 client does not know about router prefixes and does not know which router is reachable. Which section in RFC3315 defines what the client should do with the address:
- if ND receives prefix P1?
- if the router that advertised P1 is not reachable?

> - Why the client does not return the address it does not use?

Talk to your client vendor.  The client can return addresses by protocol.  Either by not REQUESTing it in the first place (though this isn't returning an address, it's just not claiming it), or by RELEASEing it.

[Dusan] Which section in RFC3315 defines what the client should RELEASE after ADVERTISE and REPLY? Why should RELEASE be used for the address that is not even assigned?

> - Why is DECLINE message associated with only one error code (DAD failed)?

No use-case has been presented that the DHC working group has agreed upon that a DECLINE for other reasons is the appropriate response.

[Dusan] That is why I am presenting these use cases.

--
Andre Kostur

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Feb 2017 19:57:42 +0000

> Please see inlined

If you learned the basics of how to quote stuff properly you wouldn't need to say that ! Bottom quoting is really quite easy if you try ;-)

>  - Syntax checks

What sort of syntax checks ? Apart from custom options, there's very little an admin can do to cause the server to send packets that aren't syntactically correct. So in most cases, for there to be a syntax issue, it would indicate a programming error - ie a bug in rhw software.
There are far more useful ways to detect that than complicating the protocol.

>  - Semantic checks

Ditto ?

>  - Prefix checks

How ? Do you propose to equip the client with ESP as to the network admin's intent ?

> > protocol requires an administrator not to make mistakes?

There is a limit to how far you can, or should, take that. The logical endpoint of that is that "things" come preconfigured with a restricted set of option that the vendor envisaged you might want to use - more reliable, less scope for admin errors. Personally I find such systems a right PITA when they make simple things easy but advanced things impossible.

> What if the router advertised a prefix and the client received an address that does not start with the prefix?

That's not an invalid configuration is it ?

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Feb 2017 20:01:03 +0000

I wrote:

> Bottom quoting is really quite easy if you try ;-)

That should say "bottom posting"

---

From: Andre Kostur <[email-masked]>
Date: Fri, 10 Feb 2017 12:09:57 -0800

On Fri, Feb 10, 2017 at 9:10 AM, Mudric, Dusan (Dusan)
<[email-masked]> wrote:

> You need to be clear on what you mean by "address validation".  (Oh, and
> DHCPv6 is responsible for both address and prefix assignment)
>
> [Dusan] - Syntax checks

All of the addresses are necessarily syntactically correct.  An
address is a 16-byte value.

>               - Semantic checks

Again, covers a lot of ground.  Be more specific.

>               - Prefix checks

A decent DHCP server will only allocate addresses that are appropriate
to where the client is requesting from.  How the DHCP server knows
what prefixes are appropriate is a configuration issue and beyond the
scope of the DHCPv6 protocol.

> Everything is susceptible to human error.  You need to have more specific
> use-cases to get anywhere near this question.  Also, the protocol does not
> mandate configuration management.  Perhaps your DHCP server has the
> capability of comparing its configuration with that on a router to look for
> certain potential configuration mismatches.  But that's a quality of
> implementation issue, not a protocol issue.
>

Just not the DHCPv6 protocol.  Which puts it beyond the scope of the
working group.

> [Dusan] Which section in RFC3315 defines how DHCPv6 client selects the
> leases? Which section defines what the client does with non-selected leases?

Beyond the scope of the protocol.  The client may use whatever logic
it wants to choose which leases it wishes to establish.  It REQUESTs
the ones it wants, does nothing with the rest.  Most servers will
quickly reclaim addresses which have been ADVERTISEd but not
REQUESTed.  That is why it is (by default) a 4-message exchange to
establish a lease.  The server already has to deal with the idea that
its ADVERTISE is never answered.  The client may have chosen a
different server to get its leases from.

> [Dusan] What if the router advertised a prefix and the client received an
> address that does not start with the prefix?

The network administrator may still want to give out an address for an
unadvertised prefix.

> [Dusan] DHCPv6 client does not know about router prefixes and does not know
> which router is reachable. Which section in RFC3315 defines what the client
> should do with the address:

Beyond the scope of the protocol.  Again, the admin may be wishing to
assign addresses for an unadvertised prefix.  Or the admin may be
wishing to give out an address that is intentionally unroutable.  Not
the protocol's role to decide that.

> Talk to your client vendor.  The client can return addresses by protocol.
> Either by not REQUESTing it in the first place (though this isn't returning
> an address, it's just not claiming it), or by RELEASEing it.
>
> [Dusan] Which section in RFC3315 defines what the client should RELEASE
> after ADVERTISE and REPLY? Why should RELEASE be used for the address that
> is not even assigned?

Nothing to RELEASE after the ADVERTISE.  The client does not yet have
the lease.  As you've already pointed out, the address had not yet
been assigned.  Section 18.1.6.

> No use-case has been presented that the DHC working group has agreed upon
> that a DECLINE for other reasons is the appropriate response.
>

And so far none of them have been accepted (as problems) by the
working group.  You need to convince the working group that a problem
exists, why the existing protocol can't deal with it, and what is the
proposed solution to the problem (with at least some specificity), and
why it's worth changing the protocol to deal with the problem.

-- 
Andre Kostur

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 10 Feb 2017 20:30:11 +0000

DHCPv6 is then very light weight:
- address assignment is not a part of the protocol,
- address selection is not part of the protocol, and
- if the client, using its own logic to select from the offered addresses (not part of the protocol), does not select some or any, the protocol should not report that to the server, and
- the fact that this kind of protocol can leave a device unreachable does not matter to the protocol that assigns the address.

Did I get it correctly?

Regards,
Dusan.

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]] 
Sent: Friday, February 10, 2017 3:10 PM
To: Mudric, Dusan (Dusan)
Cc: Simon Hobson; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Fri, Feb 10, 2017 at 9:10 AM, Mudric, Dusan (Dusan) <[email-masked]> wrote:

>> - If the key feature of the stateful DHCPv6 is the address 
>> assignment, why there is no any address validation?
>
> and

All of the addresses are necessarily syntactically correct.  An address is a 16-byte value.

>               - Prefix checks

A decent DHCP server will only allocate addresses that are appropriate to where the client is requesting from.  How the DHCP server knows what prefixes are appropriate is a configuration issue and beyond the scope of the DHCPv6 protocol.

> configuration, it is a protocol

Just not the DHCPv6 protocol.  Which puts it beyond the scope of the working group.

>> should the client save the advertised leases for every IAADDR in 
>> IA’s, if the status code is STATUS_Success?
>

Beyond the scope of the protocol.  The client may use whatever logic it wants to choose which leases it wishes to establish.  It REQUESTs the ones it wants, does nothing with the rest.  Most servers will quickly reclaim addresses which have been ADVERTISEd but not REQUESTed.  That is why it is (by default) a 4-message exchange to establish a lease.  The server already has to deal with the idea that its ADVERTISE is never answered.  The client may have chosen a different server to get its leases from.

> [Dusan] What if the router advertised a prefix and the client received 
> an address that does not start with the prefix?

The network administrator may still want to give out an address for an unadvertised prefix.

> [Dusan] DHCPv6 client does not know about router prefixes and does not 
> know which router is reachable. Which section in RFC3315 defines what 
> the client should do with the address:

Beyond the scope of the protocol.  Again, the admin may be wishing to assign addresses for an unadvertised prefix.  Or the admin may be wishing to give out an address that is intentionally unroutable.  Not the protocol's role to decide that.

> Either by not REQUESTing it in the first place (though this isn't 
> returning an address, it's just not claiming it), or by RELEASEing it.
>
> [Dusan] Which section in RFC3315 defines what the client should 
> RELEASE after ADVERTISE and REPLY? Why should RELEASE be used for the 
> address that is not even assigned?

Nothing to RELEASE after the ADVERTISE.  The client does not yet have the lease.  As you've already pointed out, the address had not yet been assigned.  Section 18.1.6.

> [Dusan] That is why I am presenting these use cases.

And so far none of them have been accepted (as problems) by the working group.  You need to convince the working group that a problem exists, why the existing protocol can't deal with it, and what is the proposed solution to the problem (with at least some specificity), and why it's worth changing the protocol to deal with the problem.

--
Andre Kostur

---

From: Andre Kostur <[email-masked]>
Date: Fri, 10 Feb 2017 13:34:28 -0800

> DHCPv6 is then very light weight:

Well.. I suspect a bunch of us DHCP implementers may not agree with
that statement.

> - address assignment is not a part of the protocol,

Where did you get this idea from?  DHCPv6 assigns addresses all day
long.  What the client does with that assignment is up to the client.

> - address selection is not part of the protocol, and

How the client selects which address to use? Nope.  The protocol
doesn't care, nor should it.  The server determines what its willing
to ADVERTISE to the client and sends it off.  The client REQUESTs what
it wants.  The server REPLYs to complete the "contract" that the
client may use those addresses named in the REPLY for the specified
Valid Lifetime.  This allows different clients to choose different
methods for selecting an address.

> - if the client, using its own logic to select from the offered addresses (not part of the protocol), does not select some or any, the protocol should not report that to the server, and

It does not appear that anybody else here understands why you keep
hammering on this point.  You have not said why this is a problem
beyond "I want to".  A common implementation is that the server holds
aside the ADVERTISEd addresses for a short while (maybe a few minutes,
maybe 10s of seconds, its an implementation detail).  If the client
doesn't come back and REQUEST it, then release it back to the pool.
In an address space that's 2^64 in size, who cares if a handful of
addresses are being held aside for clients that have not yet come to
REQUEST them.  This worked perfectly fine even in the IPv4 cases where
the address space is much smaller (possibly 10s of addresses).

> - the fact that this kind of protocol can leave a device unreachable does not matter to the protocol that assigns the address.

Nope.  And the admin may be intentionally doing so.  Not for the
protocol to decide.

No.

I have to ask: what's the motivation behind asking these questions?
There seems to be a more fundamental misunderstanding underlying this
line of questioning.

-- 
Andre Kostur

---

From: Simon Hobson <[email-masked]>
Date: Fri, 10 Feb 2017 21:44:38 +0000

> - address assignment is not a part of the protocol,

How do you come to that idea ? The primary function of DHCP is to provide IP addresses.

> - address selection is not part of the protocol, and

Correct. The job of DHCP is to issue addresses - it can't know in advance what any client might want to use it for.

> - if the client, using its own logic to select from the offered addresses (not part of the protocol), does not select some or any, the protocol should not report that to the server, and

There can be multiple servers, and no client is obliged to accept an offer that doesn't meet it's requirements. For example, a VoIP phone might be configured to only accept an offer which includes options to configure the telephony aspects of the device.
It's not that uncommon to have two servers on a network - one "general IT" one, and one embedded in the PBX. The phones will only take leases from the PBX, and the PBX will ignore clients other than the phones.
The DHCP protocol specification cannot account for all such eventualities.

> - the fact that this kind of protocol can leave a device unreachable does not matter to the protocol that assigns the address.

"Doesn't matter" isn't the right way to describe it. That there are cases where things won't work is inherent in any general purpose protocol required to work in a flexible manner, with a wide range of network topologies and clients, etc.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 10 Feb 2017 21:49:45 +0000

Thanks for answering these question. I understand what the protocol mandate is so far.

>Where did you get this idea from?  DHCPv6 assigns addresses all day long.  What the client does with that assignment is up to the client.
I mean which address is assigned by the server is not part of the protocol. The administrator  decides that.

The last question:
If REBIND offers a new address and the client decides not to use it, does the serer need to know that? Should the client send DECLINE or RELEASE?

Thanks,
Dusan.

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]] 
Sent: Friday, February 10, 2017 4:34 PM
To: Mudric, Dusan (Dusan)
Cc: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

> DHCPv6 is then very light weight:

Well.. I suspect a bunch of us DHCP implementers may not agree with that statement.

> - address assignment is not a part of the protocol,

Where did you get this idea from?  DHCPv6 assigns addresses all day long.  What the client does with that assignment is up to the client.

> - address selection is not part of the protocol, and

How the client selects which address to use? Nope.  The protocol doesn't care, nor should it.  The server determines what its willing to ADVERTISE to the client and sends it off.  The client REQUESTs what it wants.  The server REPLYs to complete the "contract" that the client may use those addresses named in the REPLY for the specified Valid Lifetime.  This allows different clients to choose different methods for selecting an address.

> - if the client, using its own logic to select from the offered 
> addresses (not part of the protocol), does not select some or any, the 
> protocol should not report that to the server, and

It does not appear that anybody else here understands why you keep hammering on this point.  You have not said why this is a problem beyond "I want to".  A common implementation is that the server holds aside the ADVERTISEd addresses for a short while (maybe a few minutes, maybe 10s of seconds, its an implementation detail).  If the client doesn't come back and REQUEST it, then release it back to the pool.
In an address space that's 2^64 in size, who cares if a handful of addresses are being held aside for clients that have not yet come to REQUEST them.  This worked perfectly fine even in the IPv4 cases where the address space is much smaller (possibly 10s of addresses).

> - the fact that this kind of protocol can leave a device unreachable does not matter to the protocol that assigns the address.

Nope.  And the admin may be intentionally doing so.  Not for the protocol to decide.

No.

I have to ask: what's the motivation behind asking these questions?
There seems to be a more fundamental misunderstanding underlying this line of questioning.

--
Andre Kostur

---

From: Andre Kostur <[email-masked]>
Date: Fri, 10 Feb 2017 13:58:51 -0800

> If REBIND offers a new address and the client decides not to use it, does the serer need to know that? Should the client send DECLINE or RELEASE?

That depends.  Did the client detect that the new address is in use by
another node?  DECLINE (s18.1.7).   Otherwise, RELEASE (s18.1.6).

-- 
Andre Kostur

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 13 Feb 2017 14:02:22 +0000

Thanks to DHCWG group for their comments. I believe the proposals would benefit DHCv6 users.

For the record:

PROBLEM STATEMENTS:
- A network operator can set client IPv6 addresses on DHCPv6 server. An address can be invalid or make a client unreachable.
- A network operator can change an address prefix on a router. A client address can become unreachable
- A default router offering a prefix to a client can become unreachable. A client address can become unreachable on a local link 
- A client does not release unused addresses

PROPOSED FAILURE INDICATIONS
- A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems
- A client returns unused addresses
- DHCPv6 server:
  -- logs error messages (invalid & unreachable addresses with device IDs)
  -- does not assign the invalid addresses
  -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again
- An operator
 -- checks if there are unreachable devices and the reason codes

---

From: Simon Hobson <[email-masked]>
Date: Mon, 13 Feb 2017 14:57:17 +0000

"Mudric, Dusan (Dusan)" <[email-masked]> wrote:

> PROBLEM STATEMENTS:
> - A network operator can set client IPv6 addresses on DHCPv6 server.

That is the primary function of the DHCP server ! I don't see that as a problem.

> An address can be invalid or make a client unreachable.

There are a lot of other ways to bo**ox up a network !
Such configurations may be deliberate. Until recently I did in fact run a network with unroutable (as in valid IP, but no router for that subnet) addresses because there was a policy decision that this particular network would be isolated - it was a backend network to carry traffic independently of the traffic on the public facing front end network.

> - A network operator can change an address prefix on a router. A client address can become unreachable

Ditto.
This is simply failing to co-ordinate network changes. Before removing/changing the prefix, the DHCP admin should have removed the pool IFF it is desired that the addresses be usable for external connectivity. As previously mentioned, this may be deliberate on the part of the Admin.

> - A default router offering a prefix to a client can become unreachable.

"Sh*t happens". Not only that, but what happens if the server hands out a load of IPv6 addresses which are all valid AT THE TIME OF ALLOCATION ? Even if your proposal were implemented, these addresses would be accepted and configured because they would be valid AT THE TIME OF ALLOCATION. The DHCP server and client cannot do anything about it if, say, 5 seconds into a 60 day lease, a router stops advertising a prefix appropriate to that address.

It would be for the OS to detect that situation, and simply stop using that address for outbound connections. IMO it would be inappropriate for all the clients to somehow tell the server that all these addresses are bad - only to have 20,000 clients all contact the server again a few minutes later when the router comes back up and the prefix becomes valid again. That would be designing in network instability.

> A client address can become unreachable on a local link 

?

> - A client does not release unused addresses

So ? There's 2^64 addresses in a minimal IPv6 prefix. How many billion addresses do you intend using for each client ? Even if your 20,000 clients all took and held onto 1000 addresses each, that's still a tiny tiny fraction of the available addresses.

> - A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems

HOW ?
You will need to define the algorithm for validating addresses. So far you've only come up with "isn't on any prefix advertised by a router" (as above, not a valid test) and "in a deprecated prefix" (as mentioned in an earlier message, not a valid test).

You will also need to define a mechanism whereby all clients can have the algorithm updated as policies change - eg prefixes get deprecated (as previously discussed), new prefixes come into use (eg I assume you would expect currently unused prefixes to be rejected, but they could come into use at any time when it's considered that they are needed).
You will also need to define a mechanism for the local admins to over-ride the stock algorithm - eg where the admins have made a policy decision to run isolated networks. This introduces a catch-22 situation where new devices might not be configurable (they won't attach to the network) until they have been configured (policy edited to allow them to connect).

This is critical to your proposal - until you can come up with an easily defined, and robust, algorithm then your proposal CANNOT work. Worse, it may cause far more problems than it is supposed to solve.

>  -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again

Define "valid" and "reachable" here ?
The implication from this and your earlier emails is that you define "reachable" as "has an IP which is routable to/from 'the internet'". See my comment above about running isolated networks, that backend isolated network runs a DHCP service - so the addresses on it are "reachable" in terms of "the DHCP server can reach them", but they aren't globally routable (they are actually RFC1918 IPv4 addresses, but the argument stands).
With a previous hat on, I had 2 Class C public IPv4 allocations which weren't globally routable.

There is also the issue that the server (in the general case) CANNOT determine the reachability/routability of any prefix. There are plenty of network topologies where the server may lose connectivity to "something" while clients don't, or vice-versa, while connectivity between server and client network is still working. Similarly, there are topologies while server-client comms could be lost, while both still have connectivity to "something". This is the reason that, out of the box, DHCP4 servers in failover do NOT automatically go into partner-down state when they lose connectivity between them.

> -- checks if there are unreachable devices and the reason codes

An alternative: The site/organisation admins take care to co-ordinate changes, and test changes in configuration. They should employ monitoring to detect issues, and respond appropriately to helpdesk tickets.
Configuration management (and especially automation) will detect many of the issues you've raised.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 13 Feb 2017 16:00:23 +0000

I would like to get more feedback from DHCPv6 users. Preferably, to prioritize the list below. What would be the number one priority item from this list that DHCPv6 users would like to address?

Thanks,
Dusan

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Monday, February 13, 2017 9:57 AM
To: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

Ditto.

?

HOW ?

_______________________________________________
dhcwg mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=-9s7e0Ks0EQLldj5oI4E9zLJKH-0ehGNzPg6r665zKo&s=yZV16lh2Yih0GhvVieDz2J5SHShPy-iKWBYCkGKJkSo&e= 

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Monday, February 13, 2017 9:02 AM
To: dhcp-users; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

For the record:

PROBLEM STATEMENTS:

PROPOSED FAILURE INDICATIONS
- A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems
- A client returns unused addresses
- DHCPv6 server:
  -- logs error messages (invalid & unreachable addresses with device IDs)
  -- does not assign the invalid addresses
  -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again
- An operator
 -- checks if there are unreachable devices and the reason codes _______________________________________________
dhcwg mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Qxk02ZIjaVguViwH6GFfRlZ1P5VOsYQOjA3jNkynsoA&s=2J3Xq9IQVsoMl7JTQP52olq6E_tc1b6kLGRuJ0RnkWE&e=

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Feb 2017 14:20:27 -0500

> I would like to get more feedback from DHCPv6 users. Preferably, to prioritize the list below. What would be the number one priority item from this list that DHCPv6 users would like to address?

You have gotten as much feedback as you're likely to get on the working group mailing list.   As far as I can tell, the feedback is that none of the things you've listed are priorities, and for good reason.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 13 Feb 2017 21:26:25 +0000

Anyone else that would benefit from a list of devices (their MAC addresses) with assigned IPv6 addresses that are not valid or are unreachable?

Dusan

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, February 13, 2017 2:20 PM
To: Mudric, Dusan (Dusan)
Cc: Simon Hobson; dhcwg; [email-masked]
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 13, 2017, at 11:00 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
I would like to get more feedback from DHCPv6 users. Preferably, to prioritize the list below. What would be the number one priority item from this list that DHCPv6 users would like to address?

---

From: 김우태(Network Innovation Projec) <[email-masked]>
Date: Mon, 13 Feb 2017 23:35:02 +0000

I think IPv6 is co-existed with IPv4 for a while.
Devices have dual stack with IPv4 and IPv6 address.
And there are cases that traces the problem with IPv4 & IPv6 address information.
But, now there have no common key between them.
So, I think IPv6 information is included with device mac address for tracing IPv4.

Utae.

From: dhcwg [mailto:[email-masked]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Tuesday, February 14, 2017 6:26 AM
To: Ted Lemon
Cc: dhcwg; [email-masked]; Simon Hobson
Subject: Re: [dhcwg] RFC3315 DECLINE definition

Dusan

Cc: Simon Hobson; dhcwg; [email-masked]<mailto:[email-masked]>

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 14 Feb 2017 08:43:56 -0500

I do not think any of those statements are problems, or are problems
that should be solved with any changes to the DHCPv6 protocol.