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

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Oct 2002 14:13:45 -0700

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

	Title		: Well known site local unicast addresses for DNS
                          resolver
	Author(s)	: A. Durand, J. Hagino, D. Thaler
	Filename	: draft-ietf-ipv6-dns-discovery-06.txt
	Pages		: 12
	Date		: 2002-9-19

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  This last call period will on 25 
October, 2002.

Bob Hinden / Steve Deering / Margaret Wasserman

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Bill Manning <[email-masked]>
Date: Fri, 11 Oct 2002 14:29:07 -0700 (PDT)

what does the DNS mafia/directorate think of this goofy idea?

-- 
--bill

---

From: Rob Austein <[email-masked]>
Date: Fri, 11 Oct 2002 23:59:45 -0400

At Fri, 11 Oct 2002 14:13:45 -0700, Bob Hinden wrote:
> Title: Well known site local unicast addresses for DNS resolver

I have written about this document at some length before, so I will
summarize rather than repeating the entire thing.  In brief:

My main objection was and remains that this mechanism, if used, moves
state away from the endpoints and into the network in a way that
cripples the resolver's ability to keep track of which of the name
servers it is using are performing properly, since the binding between
any particular well-known-address and the name server behind it might
change at any time and since there is no mechanism by which the
resolver can find out that such a change has taken place.

Furthermore, since this mechanism has enough weaknesses that even its
authors only suggest this mechanism be used as a last resort, I fail
to see what real purpose this mechanism serves.

Finally, I remain unconvinced that this is a problem that the IPv6 WG
ought to be trying to solve at all.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Sat, 12 Oct 2002 09:37:32 -0400

> resolver can find out that such a change has taken place.

What if we applied the principles that Erik and I propose in
draft-haberman-ipv6-anycast-rr-00.txt?  That would allow for the
resolver to bind an address for the server.

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Oct 2002 14:43:41 +0200 (CEST)

One high-level comment I have about the document relates to its
requirement that the mechanism be the last resort.

How is this intended to work with LLMNR (draft-ietf-dnsext-mdns-12.txt)?
One way of using LLMNR is to make *it* be the last resort, but since
we can't have two last resorts this is quite problematic.

Also, looking at the dns-discovery draft in isolation, it is far
from clear to be how one can operationally control this behavior.
The document has an implementation note about recommending that there
be other mechanisms which take precedence over the well-known addresses,
but the document does not require this nor does it specify that a particular
mandatory  override  hence an operator would not be able to control this 
behavior.

  Erik

---

From: Rob Austein <[email-masked]>
Date: Mon, 14 Oct 2002 11:37:48 -0700

> resolver to bind an address for the server.

If the WG were to go ahead with this DNS discovery mechanism in spite
of its flaws, and if the mechanisms you and Erik describe describe
prove out and become available[*], then the mechanisms you describe
might be a useful partial remedy one of the misfeatures of the DNS
discovery mechanism that's currently in WG last call.

Sure seems like a lot of work to go to in order to repair one (not
all) of the fundamental flaws in a DNS discovery mechanism that's less
useful than the pre-existing technology that it's trying to supplant.

[*] My understanding is that the mechanisms in your anycast-rr draft
    are still in the early experimental stage; please correct me if I
    have that wrong.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Rob Austein <[email-masked]>
Date: Mon, 14 Oct 2002 07:00:06 -0700

An additional (and separate) comment on the DNS discovery draft.

Temporarily suspending my disbelief in the mechanism described in this
document for purposes of discussion, there's a terminology problem:
the draft talks about finding DNS resolvers, which is not really right
and which some readers have told me they find confusing.

To be clear: this issue is not the fault of the document authors, the
underlying DNS terminology is somewhat confusing and frequently
misused.  It turns out that there is no good short name for the entity
that this mechanism is trying to locate, because the DNS terms "name
server" and "resolver" really refer to protocol roles rather than to a
particular kind of server.  This draft is talking about finding an
entity that implements both name server and resolver roles, with the
name server role acting as a front end for the resolver role under the
rules described in the protocol spec for queries with the "recursion
desired" bit turned on.

The usual way of referring to this kind of entity is as "a name server
that offers recursive service", often abbreviated as "a recursive name
server" or just "a recursive server".  Some implementations have their
own terminology for the various possible combinations of the name
server and resolver roles, but the terms I'm using here are based on
the protocol specification rather than any particular implementation.

Thus assuming that the WG decides to go forward with this draft in
spite of my objections, for clarity I would recommend that the draft
be changed to use the above terminology (use the full phrase the in
the introduction to define one of the abbreviated terms, then use the
abbreviated term throughout the rest of the document).
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Oct 2002 18:04:44 +0700

Date:        Mon, 14 Oct 2002 14:43:41 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | How is this intended to work with LLMNR (draft-ietf-dnsext-mdns-12.txt)?
  | One way of using LLMNR is to make *it* be the last resort, but since
  | we can't have two last resorts this is quite problematic.

LLMNR isn't really intended to be "last resort" in the same sense.

The "well known address" system can only be defended in way at all,
if you only ever use it (attempt it) if everything else has totally
failed.   That is, rather than giving up and saying "network is
broken, I can't look up that name", a resolver can try this one last
(valiant but probably useless) attempt to get a reply from somewhere.

  | Also, looking at the dns-discovery draft in isolation, it is far
  | from clear to be how one can operationally control this behavior.

That's not surprising, one cannot, or it would be useless.   Or perhaps,
more correctly, it's useless anyway, but if there was an easy way to
disable it (aside from providing some other mechanism which actually
works, which will effectively disable it), it couldn't even hold out the
false hope.

The real problem about the draft is that it is stealing my address space
to allow others to neglect rational configuration.

I agree with all Rob Austein said about this as well (certainly including
the issue of terminology), with the possible exception of ...

Unless a solution emerges from somewhere else, I think this WG does need
to work on the problem, as one of the promises of IPv6 is stateless
autoconfiguration.  And without being able to use DNS names, no matter
how configured the box believes it is, it is useless.   Some workable
solution to this is needed.   Personally I don't think this draft is a
satisfactory answer.  It is more of a "well, we did this, and so the
problem can be handled" type answer, just so there is something.   But
if that's what we really want, just for the IPv6 WG to provide something,
and then to assume that a real workable answer comes from elsewhere,
then, OK I guess.

I know I'll never be running recursive servers on the addresses it
specifies (most likely will never be using those addresses at all, but
who knows, it would be a good place to stick a server that simply
returns a NXDOMAIN reply to every query it receives) but given that
people insist on attempting to define what I'm supposed to do with the
address space allocated to me to manage, this is no worse than any of
the rest of that.

kre

---

From: Alain Durand <[email-masked]>
Date: Tue, 15 Oct 2002 15:50:55 -0700

>we can't have two last resorts this is quite problematic.
Those are two different things. dns-resolver discovery is to be used
to locate a DNS resolver/server in last resort when no other information
for finding this server is available.
LLMNR (at least to my understanding) is to be used
in last resort when the information had not been found in the DNS maps
(meaning you already have found a DNS server/resolver).

>mandatory  override  hence an operator would not be able to control this 
I thought that the IETF was in the business of specifying protocols,
not how people should implement them nor how people should
use them.
The best we can do here is to providing guidelines like
"use it only under those circumstances if you don't want to get hurt"

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 15 Oct 2002 15:59:14 -0700

>resolver can find out that such a change has taken place.
But isn't this already the case today, at least with some root servers
operating with an anycast address? See RFC3258.

    - Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 16 Oct 2002 13:59:59 -0400

I have several technical and organizational comments regarding this
document.

The document states:

"Thus, it is recommended to implement also other mechanisms for
overriding this default, for example: manual configuration, L2
mechanisms and/or DHCPv6."

I think that it should be required (a MUST) that nodes that
implement this specification provide a method to override the
default values manually.

The document should also specify whether the default DNS addresses
will or won't be considered part of the DNS server list when DNS
server addresses are configured via other means.  For example, if
a host receives a single DNS server address via DHCP, will it
fall-back to using these well-known addresses if the DNS server
at the DCHP-configured address fails to respond?

Listing anything as a "last resort" is problematic, because there
may be something that comes along later that should only be
used if this fails.  Instead, I would like to see this document
explicitly define how this mechanism does/doesn't interoperate
with other mechanisms (DHCP, SLP, manual configuration).

The document also states:

"d) Having an "announcement" protocol that the DNS resolver could
use to advertize the host route to the nearby router. Details of
such a protocols are out of scope of this document, but something
similar to [MLD] is possible."

In my opinion, this section points out one major weakness with
this approach.  We _still_ need some way to configure the location
of DNS servers in the network...  Today, we do that on hosts (often
using DHCP to provide the information, effectively moving the
configuration to the DHCP server).  This draft proposes moving
that knowledge off of hosts and DHCP servers, and into the routing
system, but it doesn't actually specify how the routing system
will get the information.

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 21:22:58 +0300 (EEST)

Very good comments; on one point..

> will get the information.

Options a) - c) should be sufficient to describe how the routing system 
will get the information.  Perhaps it should be reworded to be something 
like:

      d) Developing an "announcement" protocol [...]
         [...].  However, the three first mechanisms should
         cover the necessary techniques sufficiently for most cases.
        
-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 16 Oct 2002 14:31:16 -0400

>will get the information.

The three points you mention all indicate that you would "run a
routing protocol" to inject routes into the routing system.  Are
you just assuming that the routing protocol would be manual
configured with the routing information needed for packets to
the well-known addresses to reach the DNS servers?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 21:37:13 +0300 (EEST)

On Wed, 16 Oct 2002, Margaret Wasserman wrote:
> routing protocol" to inject routes into the routing system.  

Yep.  Routing protocol has to be run anyway (static routes can be
considered as a poor man's routing protocol and it works just as well) in
the network to propagate information so this is natural.

> Are

Yes.

a) like 'ipv6 route fec0:000:0000:ffff::1 3ffe:ffff:ffff::1' on the first
hop router(s).

b) run a routing protocol, no biggie (e.g. BGP is ok and you can restrict 
the advertisement so even if the node is compromised, it can't jeopardize 
the whole routing system).

c) run basically b) embedded in the process, or an equivalent (e.g. check 
the DNS server functionality periodically and kill the routing process if 
DNS server is dead)

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 17 Oct 2002 01:40:40 +0100

I think this draft is a poor idea,  and that if people want an
autoconfig mechanism,  then something along the lines of
draft-beloeil-ipv6-dns-resolver-option-00.txt would be nore sensible.

Mind one would still have to configure the router to generate the
above option in a RA,  but then something would always have to be
configured somewhere.

DF

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Oct 2002 12:43:22 +0300 (EEST)

On Fri, 11 Oct 2002, Bob Hinden wrote:

I must chime in to say I dislike this approach a bit, but it could be
salvageable.  (Though, I must admit I like an option in RA's more..)

Most of all, I dislike using *3* well known site local addresses.  One
should suffice just fine.  Remember that this mechanism, at least in my
eyes, is intended for *bootstrapping* only.  After there is something that
works, one could use some other mechanism (e.g. a DNS lookup :-) to
discover *real* DNS server addresses and ignore the site local.  It seems
to me that _3_ addresses just triples delays (5-10 seconds each, per DNS
lookup?) if none of those have been configured in the site.

In addition, I greatly dislike section 5.2, that is DNS forwarding between 
sites.  If we have to implement site-border router behaviour, let's *NOT* 
require it in every cheapo 50$ DSL router.

btw, in introduction: s/usefull/useful/, s/moble/mobile/; in section 3: 
s/as DNS resolver/as DNS resolvers/.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Oct 2002 13:11:18 +0300 (EEST)

> above option in a RA,  but then something would always have to be

Yes, I believe the above draft is a good, simple starting point.

There are still some unnecessary assumptions and extra text, I'll send 
specific comments later.

---

From: Tim Chown <[email-masked]>
Date: Fri, 18 Oct 2002 09:00:50 +0100

> There are still some unnecessary assumptions and extra text, I'll send 

It seems that if you will trust RA's to build your address and select a
default router, then having DNS info (not just server IP) in the RA is
at first approximation a reasonable method (with obvious caveats).

There seem to be many methods applied to discovery in many IPv6 tools, be
it DNS discovery, ISATAP router discovery, etc...  e.g.
	by anycast address
	by router advertisement piggyback 
	by well-known name
	by well-known site-local unicast address
	by well-known site-local multicast address
	by DHCPv6
	by Service Location Protocol
	by ...

none of which may necessarily be secure.

It seems that DNS would be the only additional service required for
discovery via RA(?), but is there any merit to encouraging consistency in
what other discovery tools use?  (e.g. it would maybe seem odd to have
each method used by different tools and to have to support them all, or 
is that seen as preferable for flexibility?)

A review against existing proposals might be interesting?

Tim

---

From: Rob Austein <[email-masked]>
Date: Sun, 20 Oct 2002 14:09:50 -0400

> operating with an anycast address? See RFC3258.

And if you read that RFC you will see that it calls for great care in
making sure that the zone content is identical at every server.  In
the case of root name servers, and assuming that we do get DNSSEC
deployed, that risk may be justified as a way of getting past the
limit on the number of root name servers imposed by UDP packet length
constraints.  I don't see an equivilant case here.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 21 Oct 2002 17:45:29 +0700

Date:        Wed, 16 Oct 2002 13:59:59 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think that it should be required (a MUST) that nodes that
  | implement this specification provide a method to override the
  | default values manually.

If the doc is to remain at all, then yes, and as Brian hinted, "manually"
is not important there.

  | The document should also specify whether the default DNS addresses
  | will or won't be considered part of the DNS server list when DNS
  | server addresses are configured via other means.  For example, if
  | a host receives a single DNS server address via DHCP, will it
  | fall-back to using these well-known addresses if the DNS server
  | at the DCHP-configured address fails to respond?

This all boils down to what is "last resort" which the doc doesn't
really go into.

I'm not absolutely convinced this is crucial, that is, that it doesn't
necessarily matter if everyone does this the same way or not.

What's clearly in issue here is how a new out of the box IPv6 node finds
some back end resolver to handle its DNS queries, as without that, it is
useless.

After having found some way to make DNS queries, the question is really
no longer important - if we get a list of DNS resolvers via DHCPv6 (say)
and they're used, then the node is now operable.   If those servers all
go away/fail (and DHCPv6 hasn't, yet anyway, told us of new ones) then
whether the node falls back to trying the well known addresses or not,
is really just a question of user desire.   Some users will just see packets
being sent to nowhere, and increased timeouts while the app waits for the
reply that will never come.   They won't want the well known addresses used.
Others would see the resolver giving up after its DHCPv6 address(es) have
failed, and wonder why the node didn't just go on and try the well known
addresses which have been carefully set up to provide the service.  Those
people will want the well known addresses retained.   (If it really was
DHCPv6 in that case then one could argue the DHCP server should have just
included the well known addresses, but the "normal" back end resolver may
have been learned via some other mechanism which cannot as easily just
supply many addresses that way).

  | Listing anything as a "last resort" is problematic, because there
  | may be something that comes along later that should only be
  | used if this fails.

I think this is partly a lack of defining "last resort of what".
That is, I didn't think it was really intended to be "last resort of
doing a name resolution" but "last resort of configuring addresses
of back end resolvers that could be used to do name resolution".
That is, this "last resort" is used at boot time only, when some
initial configuration must be found.

Or that's my impression of what it means.   But it isn't very precise.

  | Instead, I would like to see this document
  | explicitly define how this mechanism does/doesn't interoperate
  | with other mechanisms (DHCP, SLP, manual configuration).

That would be a reasonable idea.

  | In my opinion, this section points out one major weakness with
  | this approach.  We _still_ need some way to configure the location
  | of DNS servers in the network...

Yes.   This scheme isn't really all that useful.

  | Today, we do that on hosts (often
  | using DHCP to provide the information, effectively moving the
  | configuration to the DHCP server).  This draft proposes moving
  | that knowledge off of hosts and DHCP servers, and into the routing
  | system, but it doesn't actually specify how the routing system
  | will get the information.

I don't think that's a serious problem either.   Clearly something needs
to be configured somewhere (unless the model is that every node is to be
its own back end resolver, and will come pre-set with the root server
addresses as a place to start - and I certainly hope that's never what
happens).

At the very least, some node needs to be configured as the back end
(recursive) resolver.  A little extra config to inform routing where that
node lives isn't too much to expect really.   It's still config on the
order of the number of DNS back end resolvers (1, 2, or 3 or so), not of
the order of the number of nodes connected to the network.

The truly big problem with this draft is that it is usurping address
assignments that have already been made elsewhere (I'll reply to a
different message and make that point - once more).

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 21 Oct 2002 17:53:28 +0700

Date:        Thu, 17 Oct 2002 01:40:40 +0100
    From:        Derek Fawcus <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think this draft is a poor idea,  and that if people want an
  | autoconfig mechanism,  then something along the lines of
  | draft-beloeil-ipv6-dns-resolver-option-00.txt would be nore sensible.

As a solution for DNS back end resolver discovery, that one is just fine.

Its problem is that it doesn't scale, at all, to other things that also
need to be discovered (we're also going to eventually need NTP servers,
and the whole host of other things that DHCP is able to provide - or many
of them anyway).   Adding a new RA option for every one of those would
eventually mean requiring jumbograms to hold RA packets (perhaps a slight
exaggeration, but you get the point).

But perhaps DNS is just such a fundamental service, that it can be treated
as the one special case worth doing this way.

  | Mind one would still have to configure the router to generate the
  | above option in a RA,  but then something would always have to be
  | configured somewhere.

Yes, that isn't an issue to bother with (just as having to configure the
routing system isn't the issue to worry about with the well known address
"solution").

kre

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Oct 2002 12:26:45 -0400

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.

---

From: Alain Durand <[email-masked]>
Date: Wed, 23 Oct 2002 20:28:25 -0700

Thank you for all those comments.
I will use them and others to generate a -07 revision asap.

	 - Alain.

On Wednesday, October 23, 2002, at 09:26 AM, Ralph Droms wrote:

> proposed mechanism, I suggest some clarification might be needed to 
> explain that (if I have this correct) this mechanism:
>
> "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?
>
> 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?
>
> 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:
>