Subject: Updated "Revised ULA DNS text"

From: Bob Hinden <[email-masked]>
Date: Wed, 09 Mar 2005 15:08:55 -0800

Based on the comments on the mailing list and yesterday's discussion at the 
IPv6 session in Minneapolis an updated version of the ULA DNS text is 
included below.

Please review and respond if it looks OK (or not).  The current plan is to 
have the text replace the content of Section 4.4 "DNS Issues" in the draft 
as a note to the RFC editor from the IESG.

Thanks,
Bob

----------------------------

The changes from the earlier version Margaret Wasserman sent to the list were:

   s/must not/MUST NOT/
   s/c.f.ip6.arpa/d.f.ip6.arpa/			
   s/bothered to//

---------------------------

Updated text:

4.4 DNS Issues

At the present time AAAA and PTR records for locally assigned local
IPv6 addresses are not recommended to be installed in the global DNS.

For background on this recommendation, one of the concerns about
adding AAAA and PTR records to the global DNS for locally assigned
Local IPv6 addresses stems from the lack of complete assurance
that the prefixes are unique.  There is a small possibility that
the same IPv6 Local addresses will be used by two different organizations
both claiming to be authoritative with different contents.  Due to this
concern, adding AAAA records for these addresses to the global
DNS is thought to be unwise.

Reverse (address-to-name) queries for IPv6 Local addresses MUST
NOT be sent to name servers for the global DNS, due to the load that such
queries would create for the authoritative name servers for the
ip6.arpa zone.  This form of query load is not specific to Local IPv6
addresses; any current form of local addressing creates additional
load of this kind, due to reverse queries leaking out of the site.  However,
since allowing such queries to escape from the site serves
no useful purpose, there is no good reason to make the existing
load problems worse.

The recommended way to avoid sending such queries to nameservers
for the global DNS is for recursive name server implementations to
act as if they were authoritative for an empty d.f.ip6.arpa zone
and return RCODE 3 for any such query.  Implementations that
choose this strategy should allow it to be overridden, but
returning an RCODE 3 response for such queries should be the
default, both because this will reduce the query load problem and
also because, if the site administrator has not set up
the reverse tree corresponding to the IPv6 Local addresses in use,
returning RCODE 3 is in fact the correct answer.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2005 13:32:02 +1030

Hi Bob,

On Wed, 09 Mar 2005 15:08:55 -0800

> as a note to the RFC editor from the IESG.

Maybe a "SHOULD NOT" rather than "are not recommended to" in the first
sentence ? "not recommended" reads to me that, well, it isn't
recommended, however, if you do, the consequences aren't all that great.
While that may actually be the case in this scenario, I'd think people
would be looking for a bit more definite position on whether it is ok to
do or not, hence, SHOULD NOT.

Just to be clear :

"At the present time AAAA and PTR records for locally assigned local
IPv6 addresses SHOULD NOT be installed in the global DNS."

I'd think that would leave room for installing them in the global DNS at
a later date if the issues are resolved.

In addition, or as an alternative, in the second paragraph, a small
addition describing the consequences of two organisations announcing the
same ULA AAAA record. Something like : 

"For background on this recommendation, one of the concerns about adding
AAAA and PTR records to the global DNS for locally assigned Local IPv6
addresses stems from the lack of complete assurance that the prefixes
are unique.  There is a small possibility that the same IPv6 Local
addresses will be used by two different organizations both claiming to
be authoritative with different contents. ***In this scenario, it is
likely there will be a connection attempt to the closest host with the
corresponding ULA address. This may result in connection timeouts,
connection failures indicated by ICMP Destination Unreachable messages,
or successful connections to the wrong host.*** Due to this concern,
adding AAAA records for these addresses to the global DNS is thought to
be unwise."

(is "contents" in the sentence before supposed to be "contexts" ?)

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 9 Mar 2005 23:39:48 -0500

Isn't the reason more basic ... As these are not globally administered,
there are no plans to build out the zones to contain the reverse delegations
(since there's no one to officially designate the zones to).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Smith
> Sent: Wednesday, March 09, 2005 10:02 PM
> To: Bob Hinden
> Cc: [email-masked]
> Subject: Re: Updated "Revised ULA DNS text"
> 
> Hi Bob,
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2005 15:32:08 +1030

Hi Bernie,

On Wed, 9 Mar 2005 23:39:48 -0500

> (since there's no one to officially designate the zones to).

I think the zone(s) you are thinking about are the (ula).ipv6.arpa,
where the PTR records would possibly created, or not, as per the text.

My comments, and the text in the first two paragraphs, are related to
putting ULA AAAAs in the global organisation domain zones e.g., ULA
AAAAs for www.cisco.com. If somebody else put their ULA AAAA's in their
DNS for www.example.com, and the ULA prefixes happened to by chance be
the same for cisco.com and example.com organisations, you might look up
www.example.com, and then actually end up accessing the www.cisco.com
web server, as routing wise, that would be closer for you. IOW, the ULA
AAAA in question has effectively become a global anycast address for a
subset of Internet users, dependent on their topological position, which
is obviously not the intent.

Regards,
Mark.

--

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Mar 2005 07:27:59 +0200 (EET)

On Thu, 10 Mar 2005, Mark Smith wrote:
> recommended,
[...]
> IPv6 addresses SHOULD NOT be installed in the global DNS."

The uppercase should not be used here; the "magic keywords" should 
only be used for something that we're requiring the implementations to 
do (this isn't), and this is operational advice.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Mar 2005 16:16:23 +1030

On Thu, 10 Mar 2005 07:27:59 +0200 (EET)

> do (this isn't), and this is operational advice.

Ok, thanks for that. I haven't quite got around to reading the "SHOULD
NOT" etc. RFC yet, I think I MUST :-).

Regards,
Mark.

--

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Mar 2005 08:31:33 -0800

Mark,

>a later date if the issues are resolved.

I have a small preference for "not recommended" instead of a lower case 
"should not" (lowercase for the reasons Pekka stated) because I think "not 
recommended" is stronger.  But it's not a big issue either way and I am 
happy to make the change if someone else feels strongly about it.

>adding AAAA records for these addresses to the global DNS is thought to

I agree this improves the text and will add the "In this scenario...." 
sentences to the next version.

>(is "contents" in the sentence before supposed to be "contexts" ?)

I read it to mean the contents of the DNS record.

Thanks,
Bob

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 10 Mar 2005 11:20:23 -0600

Thus spake "Bob Hinden" <[email-masked]>
> happy to make the change if someone else feels strongly about it.

Perhaps it's a quirk of English, but "not recommended" to me means we are
neutral on it; the failure to endorse doesn't imply opposition.

> > Due to this concern, adding AAAA records for these addresses to
> > the  global DNS is thought to be unwise."

However, stating the practice is "thought to be unwise" implies we
disapprove of the practice, not just fail to approve of it.

Maybe the text could be made more self-consistent, but when read in its
entirety it gets the point across.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Thomas Narten <[email-masked]>
Date: Fri, 18 Mar 2005 12:24:16 -0500

Note: not being an AD anymore, I might even find time to read mailing
lists again and (gasp!) comment on occasion!!! :-)

> do (this isn't), and this is operational advice.

Pekka, where did you come up with the above? I just checked the
wording in 2119 and it is not restricted to "implementation only"
advice. There are plenty of BCP documents on operational topics that
use the 2119-language (I would bet...).

Quoting from 2119:

> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.

IMO (and I thought you agreed when we chatted in the hallway about
this!) is that the 2119-terms are quite appropriate to use in this
context.

(Note: I don't have strong feelings about the usage in this case, but
disagree with the above argument for why SHOULD NOT is not
appropriate.)

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Mar 2005 20:20:16 +0200 (EET)

> use the 2119-language (I would bet...).

See below.

> disagree with the above argument for why SHOULD NOT is not

In the hallway, the discussion was about the "other" upper/lowercase:

"Reverse (address-to-name) queries for locally assigned IPv6 Local 
addresses MUST NOT be sent to name servers for the
global DNS [...]"

.. and we did indeed agree that uppercase is appropriate.

....

For the SHOULD NOT case you mention above, you're right that RFC2119 
does not explicitly restrict the uppercase keywords for 
implementations (in the sense, "code") only, but if you read the 
document, it seems that it was implicitly intended (e.g., the wording 
in section 6 and 7.)

Again, you're right that a lot of specs have been published, using 
uppercase keywords with operational guidance, but the trend has been 
to move away from that, ultimately because they haven't been used 
carefully enough.

In any case, I wouldn't have really strong objection to using the 
uppercase keywords even for requirements on the operators, as long as 
it's blindingly obvious from the context which requirements are placed 
on the implementers (in the sense, "coders") and which on the 
operators of the protocol.

For example, if the above said,

  At the present time the administrators SHOULD NOT install AAAA and
  PTR records for locally assigned local in the global DNS.

instead of:

  At the present time AAAA and PTR records for locally assigned local
  IPv6 addresses SHOULD NOT be installed in the global DNS.

.. it would be much clearer.  However, I doubt the operators would be 
reading the spec in any case, especially if such guidance is not put 
in one clear place in the spec, but that's a separate issue.

I.e., the implementor ("coder") of the specification must be able to 
easily figure out which requirements apply to him/her, and likewise 
for the operators.

That's the reason why it may be better to avoid using the uppercase 
keywords for operational guidance.