Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

[Thomas Narten <[e-mail]>]

Hi John.

> Should we give some guidance on what to do if both mechanisms are available
> on a network, the methods give contradictory information? I don't think it is
> enough to say that both SHOULD be supported, without giving additional
> clarification on what it means when both are supported.

IMO, it is a bit of a myth that the specs don't say anything to this
point.

Here is Section 5.6 from RFC 4862:

>    5.6.  Configuration Consistency
> 
>    It is possible for hosts to obtain address information using both
>    stateless autoconfiguration and DHCPv6 since both may be enabled at
>    the same time.  It is also possible that the values of other
>    configuration parameters, such as MTU size and hop limit, will be
>    learned from both Router Advertisements and DHCPv6.  If the same
>    configuration information is provided by multiple sources, the value
>    of this information should be consistent.  However, it is not
>    considered a fatal error if information received from multiple
>    sources is inconsistent.  Hosts accept the union of all information
>    received via Neighbor Discovery and DHCPv6.
> 
>    If inconsistent information is learned from different sources, an
>    implementation may want to give information learned securely
>    precedence over information learned without protection.  For
>    instance, Section 8 of [RFC3971] discusses how to deal with
>    information learned through Secure Neighbor Discovery conflicting
>    with information learned through plain Neighbor Discovery.  The same
>    discussion can apply to the preference between information learned
>    through plain Neighbor Discovery and information learned via secured
>    DHCPv6, and so on.
> 
>    In any case, if there is no security difference, the most recently
>    obtained values SHOULD have precedence over information learned
>    earlier.

The last sentence is the main one.

I also think that dealing with this issue in more detail may not be so
easy, and it would be better to do that as updates to those documents
(or a standalone document).

E.g., even DHCP by itself has a longstanding vagueness about how to
handle the merging of information received from running DHCP on
different interfaces. (And one reason its hard is that if the two
interfaces are in different management domains, there is no easy way
to merge the information. We now have a separate WG (MIF) dealing with
that sort of thing.)

Thomas