Re: [dhcwg] RFC3315 DECLINE definition

[Tim Chown <[e-mail]>]

> On 9 Feb 2017, at 17:23, Simon Hobson <[e-mail]> wrote:
> 
> "Mudric, Dusan (Dusan)" <[e-mail]> wrote:
> 
>> -          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.

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.

> "Mudric, Dusan (Dusan)" <[e-mail]> wrote:
> 
>> 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.)
> 
> 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.

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