IPv6 Host Configuration of DNS Server Information Approaches
draft-ietf-dnsop-ipv6-dns-configuration-06

Comments from David Kessens:

The WLAN discussion is problematic. First problem is that there is no
definition of what WLAN actually is (802.11a/b/g perhaps ?) and
secondly because the problems that 802.11a/b/g supposedly has in the  
RA context can be considered as a general RA issue that is not related
at all to adding the DNS option.   
Specifically, if one already uses route advertisements over a WLAN
anyways, I cannot see why adding a DNS option would really make things
worse. More appropriate wording would be something like: 'The RA
option solution might not work very well on a congested medium that
uses reliable multicast for RA'.
actices, but provides no analysis of the security implications of multihoming.

Comments received from Iljitsch van Beijnum <iljitsch@muada.com> (13 Oct 2004 10:45:15 +0200):

This message is mostly the same as one I posted to the wg list
yesterday. See that one for an additional list of smaller nits.
                                                                                         
First a side issue.
                                                                                         
Under the ND approach there are remarks about multicast difficulties in
wireless environments. There is some additional talk about multicast in
wireless environments in an appendix, but this discussion doesn't
capture the real-world complexities that exist here (and that DHCP also
uses multicast but the issue is very different there). The pertinent
information has been discussed on the list so including it shouldn't be
too hard, or maybe a spin-off informational RFC would be appropriate.
Also note that there isn't much of a real-world issue: ARP in IPv4 also
works, while it suffers from the same broadcast/multicast problems as
IPv6 neighbor discovery.

More to the point, two very important issues are missing.
                                                                                         
The first is that we are living in 2004. If this were 2001, we could
simply identify the best approach and standardize it. However, IPv6 is
already widely implemented in hosts and deployment is growing. The lack
of a recursive resolver configuration mechanism is felt every day. If
we select an approach that needs considerable implementation effort, it
can be as much as two years before this approach is actually available
to users. The worst choice in this regard would be the RA approach.
While in itself this is a very good approach, it suffers from the fact
that both routers and hosts must support it before it can be used.
Implementation cycles vary widely throughout the industry, but it's
safe to say that anyone who doesn't use both routers AND hosts with the
shortest implementation cycle will have to wait at least until 2006
before an RA approach could conceivably be available.
                                                                                         
The DHCP approach has the advantage that it can be implemented on
special purpose servers rather than having to be implemented in
routers. Some systems use a very simple mechanism to configure
recursive resolver addresses, and on those systems it's very easy to
add a userland DHCP client daemon that handles this task. However, on
widely used systems such as Windows and MacOS X reconfiguring recursive
resolvers isn't something that can be easily done by a userland
program. Realistically, users will have to wait until Microsoft or
Apple bundle support for DHCPv6 in their products. Again, this is
likely to take a significant amount of time.

The well-known address approach on the other hand, can be deployed
pretty much immediately. The only thing that's needed is for IANA to
register a set of addresses and within weeks these addresses would be
usable by any IPv6 implementation that supports DNS queries over IPv6
transport.
                                                                                         
The second issue is security.
                                                                                         
One thing that bothers me about a DHCP-only approach is that it
requires networks that have otherwise no interest in DHCPv6 to run
DHCPv6 servers and clients. Past experience shows that complex
UDP-based protocols are often implemented insecurely. So an approach
that doesn't require additional protocols would be preferable from a
security standpoint. (And from management and debugging standpoints as
well.)
                                                                                         
Both DHCPv6 and RA have an inherent security problem because the host
is supposed to trust information that comes in from unknown sources.
This makes it very easy for an on-link attacker to present itself as a
legitimate DHCP server or router and provide clandestine configuration
information. I believe efforts are underway to remedy this situation,
but again, it will be some time before most clients will be able to use
these new mechanisms in practice. In the mean time having recursive
resolver information be available over insecure DHCP or RA means that
attackers gain an additional attack vector. (And heavy crypto doesn't
exactly go hand in hand with autoconfiguration, it remains to be seen
how well this is going to work in practice for nomadic users.)

Last but not least, not about the draft but about the decision that
needs to be made: it worries me that this issue hasn't been resolved
earlier. I believe one of the main reasons for this is that the DHCP
proponents are blocking consensus on the other approaches in order to
arrive at the situation where everyone implements DHCP and the issue
becomes moot. Note that there are several IPR claims on parts of DHCP
that may or may not apply here, adding insult to injury for those who
don't want to run DHCP in the first place.
                                                                                         
The only way to overcome this abuse of the IETF process is for the IESG
to recognize the lack of consensus and decide on the issue itself.
                                                                                         
Iljitsch van Beijnum

---

Comments from the ops directorate (Mar 30 17:21:11 PST 2005):

1. The document would benefit from a grammar edit.  Rather than requiring
the RFC Editor to do this work, I would prefer to see documents correct
grammatical mistakes prior to submission to the IESG.
 
2. The security considerations section (6) does not describe the
security implications of each approach.  This is important
because the approaches have different security implications.
For example, the RDNSS approach would utilize SEND for security,
which implies that the client has a trust anchor configured,
and the server signs RA messages.  On the other hand, the DHCPv6
approach would utilize DHCPv6 security, which has a different
trust model.  The anycast approach does not require
configuration security, since there is no protocol.
 
3. This document does not address the implications of DNS
configuration approaches on the use of link-local DNS
resolution, such as mDNS and LLMNR.  For example, where a
DNS server is not available, in the RDNSS or DHCPv6 case
no DNS server is configured, and link local name resolution
will be used exclusively without DNS queries being sent.
However, in the anycast case, DNS queries will be sent,
and if not answered, DNS clients may agressively retransmit.
Linklocal name resolution will only take place once they
time out.  The difference is particularly important for
dual stack hosts residing on IPv4 native networks, where the anycast
approach could result in persistent (and unnecessary) DNS traffic.