Re: [dnsop] new WGLC on "IPv6 Host Configuration of DNS Server Information Approaches"

[Iljitsch van Beijnum <[e-mail]>]

On 30-sep-04, at 14:36, David Meyer wrote:

> 	This note starts the (hopefully last) WG Last Call for
> 	comments on draft-ietf-dnsop-ipv6-dns-configuration-04.txt,
> 	"IPv6 Host Configuration of DNS Server Information
> 	Approaches".

I'm glad we now at least have a document that documents the approaches. 
However, this document fails to provide a good basis for deciding which 
approaches should be followed through. Many of the pros and cons listed 
are questionable, and are only applied to one option while they are 
equally (in)valid with regard to another option. For example, under ND 
there are remarks about multicast difficulties in wireless 
environments, but the fact that DHCP for IPv6 also uses multicast isn't 
mentioned, while a thorough discussion of the differences would be 
illuminating. I believe this document can be improved with regard to 
bias (there is some bias in same places) and structure, as there is 
arguing for and against approaches in different places rather than in 
an evaluation or conclusions part.

Also, 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. 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. (Although there is no reason why it couldn't be implemented on 
routers, of course.) 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 a management and debugging standpoint as 
well.)

Additionally, 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.

Also, not being very familiar with DNSSEC, I'd be interested to learn 
about the usefulness of DNSSEC for hosts that only support DNS queries 
over IPv6 transport.

Last but not least, 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. I think 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.

Specific comments:

On page 4: "When advertising more than one RDNSS options" this should 
be "option" singular.

Also page 4: "However, it is worth noting that some link layers (e.g., 
WLAN) need to acknowledge multicast packets, which may increase the 
amount of link-layer traffic." I don't believe that in 802.11b link 
layer multicast are acknowledged. However, there is another detrimental 
effect: multicasts are sent at an artificially low speed, taking up a 
lot of bandwidth.

Still on page 4, I find the following statement interesting: "RFC2461 
[3] states, however, that there may be some link type on which ND is 
not possible; on such a link, some other mechanism will be needed for 
DNS configuration." This disqualifies DHCP as well as ND.

On page 5: "4) This mechanism works over a broad range of scenarios and 
leverages IPv6 ND.  This works well on links that support broadcast 
reliably (e.g., Ethernet LANs) but not necessarily on other links 
(e.g., Wireless LANs)." I can tell you from personal experience that ND 
and any other multicast or broadcast based discovery protocol such as 
ARP or multicast DNS work just fine over 802.11b and 802.11g. (Actual 
multicast applications are another story, some limited testing with 
this (a single vendor) failed fairly spectacularly.)

Still page 5: "Because it is unacceptable to write and rewrite the DNS 
configuration file (e.g., resolv.conf) from the kernel, another 
approach is needed." Huh? Why is this unacceptable? Note that Apple 
already does this (well, I can't tell if it's the actual kernel that 
writes the file, but it's certainly something buried deep inside the 
system.) Also note that the actual resolv.conf file is there just for 
backward compatibility: the "real" information is kept elsewhere where 
user land programs can't easily modify it. The same for Windows: DNS 
management is part of the system.

"3.2.3.  Observations

    In the general case, on general-purpose networks, stateless DHCPv6
    provides significant advantages and no significant disadvantages."

This statement is absolutely not supported by the earlier text, as 
there IS an additional delay.

Page 12: "According to either RA or DHCP mechanism, the well-known 
addresses can be obtained by IPv6 host." An article would be 
appropriate here: "by an IPv6 host". But I'm not sure what this 
sentence is supposed to say anyway.

Page 13: "Well-known anycast addresses approach is also a feasible and 
simple mechanism for ISP [9]." Grammar.

Page 14: "IPv6 host can decide which approach is or may be used in its 
subnet with O flag in RA message [8]." More grammar.

(A final note: nearly all lines end in a space. Otherwise empty lines 
contain 4 spaces.)

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html