Re: [dhcwg] RFC3315 DECLINE definition

[Simon Hobson <[e-mail]>]

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

> 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.

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.