Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver"

[Ralph Droms]

Based on the comments and questions about the intended use for this proposed mechanism, I suggest some clarification might be needed to explain that (if I have this correct) this mechanism:

* is intended for ongoing use (not
just for bootstrapping)
* is intended to populate a stub resolver's list
of available recursive servers only if that list
is otherwise unpopulated (or, perhaps used if none
of the servers in the otherwise populated list
has responded?)
* uses three unicast addresses to provide reliability
through redundancy

I found the use of the phrases "pre-configured" (section 2) and "hard-coded" (section 3) in the descriptions of this mechanism confusing when I read the next-to-last paragraph in section 2, which describes this mechanism as a "last resort". I think I understand the intention, but perhaps the other phrases (which imply something about the implementation, I think) could be re-worded for consistency reduction of confusion?

I have the same confusion with the phrase "find a DNS resolver" in the abstract (which may be an artifact of previous incarnations of this document). I think the mechanism might be more accurately described as: "...specifies three reserved addresses that a node may use to communicate with DNS resolvers."

What is the impact on scaling of using three reserved addresses? Is this mechanism suitable for sites that want to use more than 3 recursive servers?

Item (b) in section 4 includes the following reason for choosing a site-local address:

"...making sure that such queries are first sent to a DNS
resolver within the site perimeter increase their likelyhood
of success".

I infer from this text that queries could go to a DNS
resolver outside the site perimeter. How is that possible
if the queries have a site-local destination address?

In section 5.1, what is the significance of the "full flavor general purpose DNS resolver" and "a large number of nodes" in the example?

Section 5.2 points out one of the drawbacks in using site-local addresses (that should be pointed out in section 4): this mechanism won't work in a site that has no recursive resolvers. The proposed solution assumes that the site boundary between the ISP and the customer goes through the customer CPE. Suppose the boundary is in the ISP PE or on one of the links between the ISP PE and the customer site?

In section 5.3, why would the CPE not pass along the address of the ISP recursive resolver to customer DHCP clients, so those clients contact the ISP resolver directly? (I see where this alternative is mentioned in the closing sentence in section 5.3).

(Philosophical/soapbox) I don't agree with the third paragraph in section 1. Common practice for hosts using IPv4 is to use DHCP, which also does not require that the user perform any manual configuration. If this doc is going to contrast the proposed auto-configuration mechanism with other available mechanisms, it should make that contrast with other auto-configuration mechanisms rather than the manual configuration straw-person.

(Philosophical/soapbox) The intended usage scenarios are weakly described in the last paragraph of section 1. What does "local resources available on the network to autoconfigure" mean? Isn't an SLP service or a DHCP service such a local resource? Why are cellular networks specifically called out? Why not other scenarios that exhibit mobility and transience, such as WLAN "hotspots"

(Philosophical/soapbox) I'm concerned about control and interoperability of this mechanism; specifically, are there cases in which a host might rely on this mechanism when some other DNS resolvers might be available? Is this mechanism controlled or otherwise affected by the 'O' bit; for example, if the 'O' bit is set, should this mechanism not be used?

(Philosophical/soapbox) Others have raised, and I will chime in on, the issue of balancing complexity in the host versus complexity in the network. The section on injection of routes glosses over the complexity of solutions b, c and d. How many different routing protocols must be supported to "run a routing protocol" or developed to use "an 'announcement' protocol"? In practice, I think option (a) is the only viable option.

Nits:

The document would benefit from a pass through a spell-checker.

"Customer CPE (Customer Provided Equipment)" is redundant.

The latest DHCPv6 draft is rev -27 (as of today or tomorrow), and the latest DHCPv6 prefix delegation draft is rev -01.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------