Re: [dhcwg] RFC3315 DECLINE definition

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

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

>> - 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.
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:[e-mail]] 
Sent: Friday, February 10, 2017 4:34 PM
To: Mudric, Dusan (Dusan)
Cc: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Fri, Feb 10, 2017 at 12:30 PM, Mudric, Dusan (Dusan) <[e-mail]> wrote:
> 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.

> Did I get it correctly?

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