Thanks for your review, Ben!
-- 5.3.1, last paragraph:
"In the case where the DNS options of RDNSS and DNSSL can be obtained
from multiple sources, such as RA and DHCP, the IPv6 host can keep
some DNS options from RA and some from DHCP; for example, two RDNSS
addresses (or DNS search domain names) from RA and one RDNSS address
(or DNS search domain name) from DHCP."
This seems underspecified. For example, can it choose the last value from each?
How is the host to guess which to keep? How can an administrator get
predictable behavior? Mixing some from one source and another from the second
seems, on the surface, like the worst possible behavior. Since using RA for
this was described as an alternative for when DHCPv6 was not available,
wouldn't it make more sense for dhcp to win?
Furthermore, this makes me wonder if the concept here needs more thought. Under
what circumstance would you be both doing stateless autoconfig and getting
DHCPv6 for the _same_ interface?
Let me speak with my "I deployed both mechanisms in my network" hat on
:-) Sometimes you have to enable all possible mechanisms on the network
side to make sure that your Windows/Apple/Linux/BSD computers and
various appliances have a maximum chance of operating correctly.
But lets talk about the issue of underspecification. I think some of
that is intentional, because I don't think we should specify a hard
limit on the number of servers specified or the number of sources the
information can come from.
However, I think I agree with you that it would be good to provide some
predictability and make the language also tighter in other ways. And I
don't think we can rule the DHCP side of this out of scope, because the
DHCP RFC did not specify the interaction. How about this:
OLD: (From Paul's new version)
In the case where the DNS options of RDNSS and DNSSL can be obtained
from multiple sources, such as RA and DHCP, the IPv6 host can keep
some DNS options from RA; the sufficient number of RDNSS addresses or
DNS search domain names is determined as a reasonable number (e.g.,
three) by the local policy. On the other hand, for DHCP DNS options,
the DHCP configuration determines the number of DNS options
advertised to IPv6 hosts, so the sufficient number is out of scope in
this document. With these sufficient numbers of RDNSS addresses and
DNS search domain names, the DNS options from RA and DHCP are stored
into DNS Repository and Resolver Repository in the order that the
latest received RDNSS or DNSSL is most preferably used for DNS
queries.
NEW:
In the case where the DNS options of RDNSS and DNSSL can be obtained
from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
some DNS options from all sources. Unless explicitly specified for the
discovery mechanism, the exact number of addresses and domain names to
keep is a matter of local policy and implementation choice. However,
it is RECOMMENDED that at least three sets of addresses and domain names
can be stored from at least two different sources. The DNS options from
Router
Advertisements and DHCP SHOULD be stored into DNS Repository and Resolver
Repository so that information from DHCP appears there first and therefore
takes precedence.
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf