Re: [dhcwg] RFC3315 DECLINE definition

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

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:[e-mail]] 
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) <[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

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.

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

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

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

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.

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

The network administrator may still want to give out an address for an unadvertised 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?

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.

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

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.

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

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