Le 13/05/2011 18:25, Thomas Narten a écrit :
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.)
YEs have we a WG item in that group dealing with that sort of thing -
but it is not yet solved, at least with respect to the default route:
- should the lifetime of the default route sent by DHCP be 32 or 16bit
long? (ND prefers the latter DHCP the former).
(your dhcp-should text seems to be saying operators dont like RA for
some cases, hence they dont know how to configure the default route for
these cases, hence DHCP should, and MIF doesnt lifetime).
Etc.
Alex
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
