Subject: [dnsop] WGLC: draft-ietf-dnsop-default-local-zones-00.txt

From: Peter Koch <[email-masked]>
Date: Tue, 8 Aug 2006 15:05:58 +0200

Dear WG,

this initiates a Working Group Last Call for

	draft-ietf-dnsop-default-local-zones-00.txt

to end Thursday, 2006-08-24 23:59:59 UTC

Please review the document and send comments to the WG mailing list. This
draft has a target status of BCP. Please state whether you agree with
this intended status. If you are an implementor of a "full" resolver and/or
recursive nameserver, please indicate whether you are planning to implement
the recommendation made in this draft.

We need at least five reviews to move forward with this document. During the
Dallas IETF, the names of ten people were recorded who volunteered for this
task. Everyone else's contribution is of course welcome as well.

History: this draft started as draft-andrews-full-service-resolvers.
Readers might want to refer to draft-jabley-as112-ops-00.txt for background
information.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Aug 2006 17:59:37 -0400

Dear Colleagues,

> 	draft-ietf-dnsop-default-local-zones-00.txt

I have read this draft.  I support it going forward for the intended
status of BCP.  Thanks to the author for a good document.

After this most recent reading, I have a couple comments and
questions that might be worth considering if there were any
additional revisions to be done, but I would not advocate holding up
the document for any of them.

1.	Given the discussion of AS112, is there any value in
including a reference to draft-jabley-as112-ops-00?  (The obvious
answer is "no", since that would introduce a dependency on what is
currently an individual submission I-D.  I just thought I'd ask for
the record.)

2.	In section 5, we have, "The author believes other methods
would be more applicable for dealing with the excess / bogus traffic
these generate."  Is it worth adding some sort of reference to what
methods those would be?  It seems to raise a question, without
providing guidance about where to look for the answer.  Normally I
don't know that I'd care, but in a BCP it strikes me that maybe such
indications are important.

3.	Nit: section 6.  "This document recommends that IANA
establish a registry of zones which require this default behaviour,
the initial contents are above."  This needs to be altered either to
replace the comma with a semicolon or colon (depending on what one's
views are on those); or, to have the end of the sentence changed to
read "the initial contents of which are above".  As it stands, it's
a comma splice.

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Aug 2006 18:53:12 -0400

On 8-Aug-2006, at 09:05, Peter Koch wrote:

> Please review the document and send comments to the WG mailing list.

See in-line, below.

> This draft has a target status of BCP. Please state whether you  
> agree with
> this intended status.

I agree with that intended status.

> If you are an implementor of a "full" resolver and/or

I am not such an implementer.

I found a few nits that I think should be ironed out before the  
document is sent up the tree, most of them editorial, and all fairly  
inconsequential with respect to the draft's core intention. Those  
nits aside, I support the document going forward.

> 1.  Introduction
>
> [...]
>
>    This recommendation is made because data has shown that significant
>    leakage of queries for these name spaces is occurring, despite

Citing data without a reference is weak. A reference should be supplied.

> 2.  Effects on sites using RFC 1918 addresses.
>
>    Sites using [RFC 1918] addresses should already be serving these
>    queries internally, without referring them to public name  
> servers on
>    the Internet.

"answering these queries", not "serving".

>    The main impact will be felt on sites that make use of recursion  
> for
>    reverse lookups for [RFC 1918] addresses and have populated these
>    zones.  Typically, such sites will be fully disconnected from the
>    Internet and have their own root servers for their own non-Internet
>    DNS tree or make use of local delegation overrides (otherwise known
>    as "forwarding") to reach the private servers for these reverse
>    zones.  These sites will need to override the default configuration
>    proposed in this draft to allow resolution to continue.

I'm not convinced that "running your own root server" is typical for  
operators who make use of RFC 1918 addresses, and it scares me a bit  
to see the inference that this is an everyday thing in a document  
aimed at BCP. (The typical approach taken by operators is to avoid  
the issue altogether, which is why this is a good document.)

Usually these sites are *not* fully disconnected from the Internet,  
in my experience; they are attached through leaky middleware, which  
is why AS112 servers receive traffic.

>    Other sites that use [RFC 1918] addresses and either have local
>    copies of the reverse zones or don't have reverse zones configured
>    should see no difference other than the name error appearing to  
> come
>    from a different source.
>
>
> 3.  Changes Iterative Resolver Behaviour.

"Changes to Iterative Resolver Behaviour". Iterative or recursive?  
Recursive is more usual, I thought.

>    Unless configured otherwise, a iterative resolver will return name
>    errors for queries within the lists of zones covered below.  One
>    common way to do this is to serve empty (SOA and NS only) zones.
>
>    A server doing this MUST provide a mechanism to disable this
>    behaviour, preferably on a zone by zone basis.
>
>    If using empty zones one should not use the same NS and SOA records
>    as used on the public Internet servers as that will make it  
> harder to
>    detect leakage from the public Internet servers.  This document

"Leakage to", rather than "leakage from,", presumably.

>    recommends that the NS record default to the name of the zone  
> and the
>    SOA MNAME default to the name of the zone.  The SOA RNAME should
>    default to ".".  Implementations SHOULD provide a mechanism to set
>    these values.  No address records need to be provided for the name
>    server.
>
>    @ 10800 IN SOA @ . 1 3600 1200 604800 10800
>    @ 10800 IN NS @

Is the use of "@" in this context a BIND-ism, or does it have a more  
implementation-neutral heritage?

> 4.  Lists Of Zones Covered
>
>    The lists below are expected to seed a IANA registry.

"An IANA registry", not "a".

> 4.2.  RFC 3330 Zones
>
>       0.IN-ADDR.ARPA /* IPv4 "THIS" NETWORK */
>       127.IN-ADDR.ARPA /* IPv4 LOOP-BACK NETWORK */
>       254.169.IN-ADDR.ARPA /* IPv4 LINK LOCAL */
>       2.0.192.IN-ADDR.ARPA /* IPv4 TEST NET */
>       255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */

Those comments would be easier to read if this was a two-column table.

> 4.3.  Local IPv6 Unicast Addresses
>
>        
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP
>       6.ARPA
>        
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP
>       6.ARPA

Those line breaks are unfortunate.

> 4.4.  IPv6 Locally Assigned Local Addresses
>
>       D.F.IP6.ARPA

This wants a reference to RFC 4193.

> 4.5.  IPv6 Link Local Addresses
>
>       8.E.F.IP6.ARPA
>       9.E.F.IP6.ARPA
>       A.E.F.IP6.ARPA
>       B.E.F.IP6.ARPA

These want a reference, too.

> 5.  Zones that are Out-Of-Scope
>
>    IPv6 site-local addresses and IPv6 Globally Assigned Local  
> addresses
>    are not covered here.  It is expected that IPv6 site-local  
> addresses
>    will be self correcting as IPv6 implementations remove support for
>    site-local addresses however, sacrificial servers for  
> C.E.F.IP6.ARPA
>    to F.E.F.IP6.ARPA may still need to be deployed in the short  
> term if
>    the traffic becomes excessive.

It seems more proper to describe FEC0::/10 as space reserved by RFC  
3879 than as "IPv6 site-local addresses", since site-local addresses  
have been deprecated.

>    For IPv6 Globally Assigned Local addresses there has been no  
> decision
>    made about whether the registries will provide delegations in this
>    space or not.  If they don't then C.F.IP6.ARPA will need to be  
> added
>    to the list above.  If they do then registries will need to take
>    steps to ensure that name servers are provided for these addresses.

RFC 4193 says "At the present time, AAAA and PTR records for locally  
assigned local IPv6 addresses are not recommended to be installed in  
the global DNS." Your commentary might make reference to that.

>
>    This document is also ignoring the IP6.INT counterpart for the
>    IP6.ARPA addresses above.  IP6.INT is in the process of being wound
>    up with clients already not querying for this suffix.

IP6.INT was deprecated in RFC 4159. It is no longer in the process of  
being wound up.

>    This document has also deliberately ignored zones immediately under
>    the root.  The author believes other methods would be more  
> applicable
>    for dealing with the excess / bogus traffic these generate.

"Zones immediately under the root" is a little cryptic. How about  
referring instead to top-level domains which have no corresponding  
zone delegated from the root, perhaps including examples such as  
"local" and "workgroup"?

> 6.  IANA Considerations
>
>    This document recommends that IANA establish a registry of zones
>    which require this default behaviour, the initial contents are  
> above.

That wants to be two sentences, or one sentence with the comma  
replaced with something stronger (e.g. a semi-colon).

>    More zones are expected to be added, and possibly deleted from this
>    registry over time.

This comment seems superfluous -- if no modifications were required  
then a registry would not be needed, and a static list would suffice.

> 7.  Security Considerations
>
>    During the initial deployment phase, particularly where [RFC 1918]
>    addresses are in use, there may be some clients that unexpectedly
>    receive name error rather than a PTR record.  This may cause some
>    service disruption until full service resolvers have been re-
>    configured.
>
>    When DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
>    namespaces, the zones listed above will need to be delegated as
>    insecure delegations.  This will allow DNSSEC validation to succeed
>    for queries in these spaces despite not being answered from the
>    delegated servers.
>
>    It is recommended that sites actively using these namespaces secure
>    them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
>    anchors.  This is good just on general principles.  It will also
>    protect the clients from accidental leakage of answers from the
>    Internet which will be unsigned.

"This is just good on general principles" seems unconvincing :-) How  
about just "This will protect clients from accidental leakage of  
unsigned answers from the Internet".

> 9.2.  Informative References
>
>    [AS112]    "AS112 Project", <http://as112.net/>.

A reference to one of the as112 drafts might be useful. This seems  
unlikely to delay the progress of this draft, since the as112  
documents will be put forward as informational.

Joe
.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Aug 2006 09:32:10 +1000

> currently an individual submission I-D.  I just thought I'd ask for

	It would be a informational reference to work in progress
	if it went in.  There is a reference to the as112 project.
 
> indications are important.

	That well be the subject of another I-D.  I'm getting the
	non controversial one out of the way first.
 
> read "the initial contents of which are above".  As it stands, it's

	Ack.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Aug 2006 09:58:00 +1000

> is why AS112 servers receive traffic.

	I'm pointing out the sites that will have problems not all
	the ways that people insert answers for RFC 1918 addresses.
	For most RFC 1918 sites that actually maintain there own
	reverse records there won't be problem as they will already
	have explict configuration for these zones and won't need
	to instanciate the automatic ones.
 
> Recursive is more usual, I thought.

	Iterative is correct.  I want to capture more than recursive
	nameservers.  
 
> implementation-neutral heritage?

	It is RFC 1035 master file syntax.

	RFC 1035
    @               A free standing @ is used to denote the current origin.
 
> Those line breaks are unfortunate.

	I agree.

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Thu, 10 Aug 2006 19:53:30 -0400 (EDT)

On Thu, 10 Aug 2006, Joe Abley wrote:

> operators who make use of RFC 1918 addresses, and it scares me a bit to see 
> the inference that this is an everyday thing in a document aimed at BCP. (The 
> typical approach taken by operators is to avoid the issue altogether, which 
> is why this is a good document.)

I have to agree with Joe on this one.  It's been my experience that some 
operators are even brazen enough to understand what the issues are, but 
refuse to work on mitigating them, because it isn't perceived as all that 
of a problem afterall...."Things work anyways."  Echoing Joe, that's why 
it's a good doc and candidate for BCP.

wfms
.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Aug 2006 10:48:46 +1000

> IP6.INT was deprecated in RFC 4159. It is no longer in the process of  

	As long as there are clients which make IP6.INT queries as
	the result of calling getnameinfo(), etc. it is in the
	process of being wound up.  I expect there will be a very
	long tail here but so long as the traffic doesn't get too
	large it should not be a issue.

	Removing "counterpart for the IP6.ARPA addresses above"
	would be appropriate.

	Note: my IPv6 provider [Bcc'd] hasn't yet removed the
	delegation for my /64 under ip6.int.  I'm not going to stop
	serving the zone until that delegation is removed or the
	parent zone is removed.  I suspect most end user sites are
	in the same position.

	Cleaning up IP6.INT has to be a top down process.  The top
	has started by the RIR's should, if they havn't already,
	inform all the old registants under IP6.INT that the
	delegation has been removed and that they no longer need
	to serve the next zone down.  This should ripple down
	from there.

	Yes I could unilaterally stop serving but that would break
	thing rather than resulting in NXDOMAIN being returned for
	the few sites that can still resolve the names.

	Mark

---

From: [email-masked]
Date: Fri, 11 Aug 2006 01:35:04 +0000

hum...   well there are two things here...
	) ip6.int.
	   ICANN has removed that delegation.  Me, i'm still serving 
	   up delegations under that which the zone owners have not 
	   removed.  Same boat Mark is in...  :)  Didn't matter to 
	   ICANN or the v6 zelots.  L(

	) this draft and the whole idea of "special" zones that are
	  automagically created/defined.
		I think this is a horrible idea, a bandaid to try and 
		cover festering sores created by the IETF.  When clean
		up is eventually done, there is zero way to tell all those
		installed configurations that they are broken and should
		be updated/corrected.  Time to start patching ISC bind
		to get resonable behaviour again.. :(

--bill

.

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Aug 2006 23:09:20 -0400

> 	   ICANN or the v6 zelots.  L(

I think Mark's point with respect to that is that the presence or  
absence of a delegation is unimportant in this context so long as  
clients are still sending queries.

Joe

.

---

From: [email-masked]
Date: Fri, 11 Aug 2006 10:17:21 +0000

> clients are still sending queries.

	right.  but that didn't matter to ICANN, IANA, or the v6 zelots.
	they pulled the delegation anyway.

--bill
.

---

From: David Conrad <[email-masked]>
Date: Fri, 11 Aug 2006 07:59:49 -0700

>> clients are still sending queries.

Given the half-life of anything, regardless of how broken, on the  
Internet (how many BIND 4.8 servers are still out there?), clients  
will be sending queries until Paul Vixie becomes president of ICANN  
at least.

> 	they pulled the delegation anyway.

Yep. And the screams of outrage have been deafening.  OK, maybe not.

Let ip6.int rest in peace.

Rgds,
-drc

.

---

From: [email-masked]
Date: Fri, 11 Aug 2006 17:07:30 +0000

> will be sending queries until Paul Vixie becomes president of ICANN  

	so.. paul T is retiring this year?

--bill
.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Aug 2006 09:05:01 -0400

>	to serve the next zone down.  This should ripple down

IP6 has already been removed from the INT zone.  It's gone.

The RIRs have already publicized cessation of IP6.INT service, they 
did this as a run-up to the big event.  In ARIN space, the first 
message on this was December 5, 2005.  I know there were follow ups, 
but don't think chasing them down is worthwhile now.

What I find ironic is that on one hand we complain about people not 
upgrading one day, and then bend over backwards to support those that 
do not upgrade.  If we keep being soft on non-upgraders, we're 
engineering for nothing from here on out.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Aug 2006 09:06:38 -0400

At 7:59 -0700 8/11/06, David Conrad wrote:

>  Quoting someone else:

Amen.

---

From: Peter Koch <[email-masked]>
Date: Thu, 24 Aug 2006 20:33:25 +0200

Dear WG,

> to end Thursday, 2006-08-24 23:59:59 UTC

which is only a few hours away. So far, there have been only three statements
of support (by Andrew Sullivan, Joe Abley and William Maton), also requesting
changes to the text.  These are fewer reviews than expected based on the
discussion during the Montreal meeting. Therefore, the WGLC deadline is
extended to

	Wednesday, 2006-08-30 23:59:59 UTC

> Please review the document and send comments to the WG mailing list. This

If you've read the draft and support it, it is helpful to state that even
if you don't suggest any changes to the text(*).

There will be a -01 version after the WGLC has ended.

-Peter

(*) Just for clarity: If you disagree, please say so, too.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Aug 2006 09:26:47 -0400

I've been reading up on the split-view document, arguing that 
split-view needs recognition.

And this document is another example - it encourages split-view of 
these local zones.

Anyway - regarding
   http://ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-00.txt

Chapter 2 - Isn't RFC 3330 a better reference than 1918?  We don't 
want to see 0.0.0.0/8 PTR requests either.  (You have 3330 mentioned 
later, but why then the special section on 1918?)

Chapter 3 is confusing.  I see the "send text" but first I need to 
ask, what's the point of chapter 3.  It's not just the wording, I 
don't get the point of it.

Chapter 4 needs FQDN's in it.  Also, why the IANA registry reference? 
I don't see that IANA needs to have a list of these "should be 
split-view'ed" zones.

The idea of burning in more and more configured zones does grate 
against my common sense.  In the same vein of seeing certain IP 
addresses burned in as examples in some code, once these zones become 
hardcoded we lose them.  Maybe not so much a problem with the 
namespace (we can always close .arpa and start .bert for reverse map).

Chapter 5 - "sacrificial" servers begs a definition or a reference to 
what is meant.

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Peter Koch <[email-masked]>
Date: Tue, 29 Aug 2006 14:17:25 +0200

> > 	draft-ietf-dnsop-default-local-zones-00.txt

(* no hats, still not counting for the five reviewer threshold *)

I support the document being moved forward to reach BCP status, with some
changes to the text. Suggestions below.

>                           Locally-served Zones

A reference to the DNS is needed in the title.

>    Additionally, queries from clients behind badly configured firewalls
>    that allow outgoing queries but drop responses for these name spaces
>    also puts a significant load on the root servers.  They also cause
>    operational load for the root server operators as they have to reply
>    to queries about why the root servers are "attacking" these clients.
>    Changing the default configuration will address all these issues for
>    the zones below.

Direct reference to section 4 instead of "below" might be more clear.

>    handled locally.  This document extends the recommendation to cover
>    the IN-ADDR.ARPA zones for [RFC 1918] and other well known IN-
>    ADDR.ARPA and IP6.ARPA zones for which queries should not appear on
>    the Internet.

s/Internet/public Internet/ to be consistent with RFC 1918.

>    It should also help DNS responsiveness for sites which are using [RFC
>    1918] addresses but are misconfigured.

Sites ... that are misconfigured -> "not follow the last paragraph in
sectioon 3 of RFC 1918"
The same caveat also holds for users of 169.254/16 address space, should
someone really do dynamic updates with it.

>    queries internally, without referring them to public name servers on
>    the Internet.

"Queries" is an ambiguous term since it could refer to anything with QR=0
or to OPCODE=0. I think it's important to explain that many of the
"queries" seen - at least at AS112 instances - are currently DNS dynamic
update attempts. E.g., "should already be serving the corresponding reverse
mapping namespace authoritatively without leaking DNS queries or DNS dynamic
update messages [RFC 2136] to public name servers ..." 

>    The main impact will be felt on sites that make use of recursion for

"on" -> "at"?

>    Internet and have their own root servers for their own non-Internet

I'd rather not engange into these speculations.

>    proposed in this draft to allow resolution to continue.

Suggestion for clarification:

  Sites that use [RFC 1918] and depend upon a sophisticated DNS resolving
  infrastructure involving so called forwarders will need to override these
  new default values on their forwarders. The authoritative servers for
  their copies of [RFC 1918] reverse space provide for this "override"
  already.

>    should see no difference other than the name error appearing to come
>    from a different source.

"name error" should be clarified to mean "RCODE=3".

> 3.  Changes Iterative Resolver Behaviour.

Changes _to_

>    common way to do this is to serve empty (SOA and NS only) zones.

Only the usual QNAMEs for PTR queries result in NXDOMAIN, queries for
SOA and maybe NS RRs will (now) receive positive responses.

>    A server doing this MUST provide a mechanism to disable this

s/A server doing this/An implementation following this recommendation/

>    as used on the public Internet servers as that will make it harder to
>    recommends that the NS record default to the name of the zone and the

To emphasize that the zone name is not a good default MNAME in general:
s/to the name of the zone/the name of the only NS RR's target/

>    @ 10800 IN SOA @ . 1 3600 1200 604800 10800

Some more explanatory text is necessary here:

   The SOA RR is needed to support negative caching [RFC 2308] of name
   error responses and to point clients to the primary master for
   DNS dynamic updates.

   SOA values of particular importance are the MNAME, the SOA RR's TTL and
   the negTTL value. Both TTL values SHOULD match. (actually I think 3600
   would be sufficient, it only affects the site internal traffic anyway).
   The rest of the SOA timer values may be chosen arbitrarily since it
   they are not intended to control any zone transfer activity.

With AS112 we see lots of updates messages aimed at the master named in
MNAME. With the setup suggested above, that name will not resolve into
an A RR (resulting in NOERROR/NODATA). Do we have evidence that dynamic
update clients will treat this gracefully and _not_ climb the tree further up?

Why do we need the NS RR at all?

I'm not too comfortable to see RNAME=="." as an indication of a non existing
mail address, especially since proposals like this have been flurrying
around for MX RRs. The "additional section processing" problem should be
smaller for the SOA RR, but I fear the bad precedent.
RFC 2606 defined the "invalid" TLD, so nobody.invalid. or, to avoid search
path issues with "invalid", nobody.rfc<this number>.invalid. seem clearer
to me (of course that toches the issue of "serving" the RFC 2606 zones ...).

> 4.2.  RFC 3330 Zones

A (normative) reference to RFC 3330 should be added here.

A question that will likely be raised in Last Call is whether
1.0.0.127.IN-ADDR.ARPA shouldn't own a PTR RR by default. I think we should
have an answer to this if we agree that it shouldn't.

> 4.3.  Local IPv6 Unicast Addresses

Add (normative) reference to RFC 4291, 2.4, 2.5.2, 2.5.3.

> 4.4.  IPv6 Locally Assigned Local Addresses

Another reference needed.

> 4.5.  IPv6 Link Local Addresses

Add (normative) reference to RFC 4291, sections 2.4 and 2.5.6.

>    IPv6 site-local addresses and IPv6 Globally Assigned Local addresses
>    are not covered here.  It is expected that IPv6 site-local addresses

Appropriate references should be added.

>    site-local addresses however, sacrificial servers for C.E.F.IP6.ARPA
>    to F.E.F.IP6.ARPA may still need to be deployed in the short term if
>    For IPv6 Globally Assigned Local addresses there has been no decision

Is there any reference to this discussion? Are the "registries" mentioned
here the RIRs?

>    up with clients already not querying for this suffix.

IP6.INT is dead, I'd suggest to remove this paragraph.

>    the root.  The author believes other methods would be more applicable

While I often trust Mark's wisdom, reference to the author's belief is not
appropriate for a BCP ;-)
As others suggested before: add some reference to how those "other methods"
look like.

>    This document recommends that IANA establish a registry of zones

s/recommends/asks/

>    which require this default behaviour, the initial contents are above.

s/above/section 4/

>    registry over time.  Name server implementors are encouraged to check

s/name server/recursive name server/

>    this registry and adjust their implementations to reflect changes
>    therein.
> 
>    This registry can be amended through IESG reviewed RFC publication.

That is "IETF Consensus" as per RFC 2434 or IETF Review in 2434bis; a reference
to RFC 2434 is needed.

>    service disruption until full service resolvers have been re-

Now we have the third term where consistent terminology would be helpful:

1) recursive name server
2) iterative resolver
3) full resolver

My interpretation of the difference between (1) and (2) is that (1) is
anything that accepts DNS queries with RD=1 and acts upon them to serve
the final answer, either by using another recursive name server (making this
a recursive definition) or by acting as (2).
It's not completely clear to me whether our target objects are (1) and (2)
or only (2).

Also, some text should be added to recommend against implementing this BCP
in stub resolvers or name caches (like nscd or similar).

-Peter
.