Thanks for writing this draft. I've read it and had a few comments:
The purpose of this document is to standardize IPv6 Router
Advertisement (RA) option for DNS configuration in IPv6 hosts
specified in [RFC5006] and also to define a new RA option for Domain
Name Search lists.
Maybe: ... specified in an earlier experimental specification [RFC5006]
and ...
It is infeasible for nomadic hosts, such as laptops, to be configured
manually with a DNS resolver each time they connect to a different
wireless LAN (WLAN) such as IEEE 802.11 a/b/g [IEEE-802.11]
[IEEE-802.11a][IEEE-802.11b][IEEE-802.11g]. This document defines a
mechanism based on IPv6 RA options to allow IPv6 hosts to perform the
automatic DNS configuration. As an alternative to the DNS
configuration provided by DHCP [RFC3315][RFC3736][RFC3646], the RA-
based DNS configuration can allow network operators or users to
select an appropriate automatic DNS configuration for IPv6 hosts,
depending on the types of their networks [RFC4339].
This rationale has several issues. First, I'm not sure the listing of
different radio types is really relevant here. Second, there are
multiple ways of handling the manual DNS configuration, such as doing it
once, not per network. Finally, I do not think the explanation of the
differences of this vs. DHCP approach really capture the essential
reasons why we believes good standardize this mechanism.
I would suggest the following paragraph instead.
"It is infeasible to manually configure nomadic hosts each time they
connect to a different network. While a one-time static configuration is
possible it is generally not desirable on general purpose hosts such as
laptops. For instance, locally defined name spaces would not be
available to the host if it were to run its own name server software
directly connected to the global DNS. The DNS information can also be
provided through DHCP [RFC3315][RFC3736][RFC3646]. However, access to
DNS is a fundamental requirement for almost all hosts, and stateless
IPv6 autoconfiguration cannot stand on its own as an alternative
deployment model in any practical network without support for DNS
configuration. These issues are not pressing in dual stack networks as
long as a DNS server is available on the IPv4 side, but become more
critical with the deployment of IPv6-only networks. As a result, this
document defines a mechanism based on IPv6 RA options to allow IPv6
hosts to perform the automatic DNS configuration."
RA-based DNS configuration is a useful alternative in networks where
an IPv6 host's address is autoconfigured through IPv6 stateless
address autoconfiguration, where the delays in acquiring server
addresses and communicating with the servers are critical, or where
the network operator or host operator does not want the additional
operational complexity of running DHCPv6 to provide the same
information to all hosts on the network.
Overselling the point. And missing some. And I'm not convinced about any
delay issues. I would just say this:
RA-based DNS configuration is a useful alternative in networks where
an IPv6 host's address is autoconfigured through IPv6 stateless
address autoconfiguration, and where there is either no DHCPv6
infrastructure at all or some hosts do not have a DHCPv6 client.
The intention is to enable full configuration basic networking
information for hosts without requiring DHCPv6. However,
when in many networks some additional information needs to
be distributed, and those networks are likely to employ DHCPv6.
In these networks RA-based DNS configuration may not be needed.
This can be
beneficial in some mobile environments, such as with Mobile IPv6
[RFC3775].
Maybe. Mobile can also be like VPN in the sense that you want your home
environment and home DNS visible. I would just strike this sentence,
because full treatment of the topic will be more complicated than this
simple claim.
To order the RA and DHCP approaches, the O (Other stateful
configuration) flag can be used in the RA message [RFC4861].
To order? As in sequencing them, or as in requesting their use? But the
RA options cannot be negotiated, you will always send them, and I
presume, always accept information, no?
Based on the definition of the O flag above, if RA options for DNS
configuration are included in the RA messages, an IPv6 host may
perform another DNS configuration through DHCPv6 only when the O flag
is set. On the other hand, if no RA options for DNS configuration
are included in the RA messages, an IPv6 host may perform DNS
configuration through DHCPv6 regardless of whether the O flag is set
or not.
And I do not understand the need to talk about the M and O options in
Section 1.2 at all. I know I will not enjoy yet another instance of the
M&O bit discussion on this document. But I fail to see what changes with
respect to the M&O bits in this document. This is RFC 4861 domain, for
better or worse. And I'm not sure RFC4339 really gives any useful rules,
at least in the normative sense. I would just say:
Two protocols exist to configure the DNS information on a host, the
Router Advertisement options described in this document and the DHCPv6
options described in [RFC3646]. They can be used together. The rules
governing the decision to use stateful configuration mechanisms are
specified in RFC 4861. Hosts conforming to this specification MUST
extract DNS information from Router Advertisement messages, unless
static DNS configuration has been specified by the user. If there is DNS
information available from multiple Router Advertisements and/or from
DHCP, the host MUST maintain an ordered list of this information as
specified in Section 5.3.1.
This is for two reasons for the new option, the
first is to maintain parity with the DHCPv6 options for DNS
configuration [RFC3646], so that RA and DHCPv6 do not unnecessarily
diverge and so that RA can provide the same DNS configuration as
DHCPv6. The second reason is that a Domain Search List is useful to
support multi-homed hosts querying DNS servers which provide
different answers [ID-savolainen].
There are functional differences to providing the domain as well, e.g.,
resolving local names. I would just say:
"This is to maintain parity with the DHCPv6 options and to ensure that
there is necessary functionality to determine the search domains."
Existing ND transport mechanisms (i.e., advertisements and
solicitations) are used. This works in the same way that hosts learn
about routers and prefixes. An IPv6 host can configure the IPv6
addresses of one or more RDNSSes via RA messages periodically sent by
a router or solicited by a Router Solicitation (RS).
But this draft -- I hope -- does not change the overall messaging, e.g.,
you would not send extra solicitations. I would just say:
"Existing ND message, Router Advertisement is used to carry this
information. An IPv6 host can configure the IPv6 addresses of one or
more RDNSSes via RA messages."
When the IPv6 host has gathered a sufficient number of RDNSS
addresses (or DNS search domain names), it MAY ignore additional
RDNSS addresses (or DNS search domain names) within an RDNSS (or
DNSSL) option and/or additional RDNSS (or DNSSL) options within an
RA.
I would specify a minimum required number of supported addresses.
o RDNSS address for DNS Server List: IPv6 address of the Recursive
DNS Server, which is available for recursive DNS resolution
service in the network advertising the RDNSS option; such a
network is called "site" in this document.
o DNSSL domain name for DNS Search List: DNS suffix domain names,
which is used to perform DNS query searches for short, unqualified
domain names in the network advertising the DNSSL option; such a
network is called "site" in this document.
Text duplication, and I don't think you actually use the term site in
this sense elsewhere in the document.
Note: An RDNSS address or a DNSSL domain name MUST be used only as
long as both the RA router lifetime and the option lifetime have
not expired. The reason is that the RDNSS may not be currently
reachable, that the DNSSL domain name is not valid any more, or
that these options do not provide service to the host's current
address (e.g., due to network ingress filtering
[RFC2827][RFC5358]).
... and as long as you are still attached to this network.
Missing things:
I think the Section 5.3.1 rules on maintaining the list need to be more
explicit about getting information from multiple sources. E.g., if you
get plenty from one RA maybe you should keep some from that and some
from DHCP, as opposed to throwing away everything from DHCP...
I wonder if some of the steps from Section 6 of this draft should be in
earlier sections as normative behaviour requirements.
Jari
P.S. What would it take to make rdnssd a part of the default Linux
distribution? Its currently a separate piece that must be installed...
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
