Re: [dhcwg] RFC3315 DECLINE definition

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

Hi Andre,

Please see inlined

Thanks,
Dusan.

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

On Fri, Feb 10, 2017 at 6:35 AM, Mudric, Dusan (Dusan) <[e-mail]<mailto:[e-mail]>> wrote:
> - If the key feature of the stateful DHCPv6 is the address assignment,
> 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
> router prefixes?

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?

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

Be more specific.  ND covers a lot of ground.

[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