Subject: Updated V2 "Revised ULA DNS text"

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Mar 2005 09:10:37 -0800

Here is an update to the update with the added text suggested by Mark 
Smith.  Please review.

Thanks,
Bob

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

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.  In this scenario, it is likely 
there will be a connection attempt to the closest host with the 
corresponding IPv6 Local 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.

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: Tim Chown <[email-masked]>
Date: Thu, 10 Mar 2005 17:29:16 +0000

It may be pedantic, but should we not say "Unique Local IPv6 Unicast Addresses"
rather than "locally assigned Local IPv6 addresses" or perhaps "locally
assigned Unique Local IPv6 Unicast Addresses"?

It also isn't wholly clear whether Unique Local IPv6 Unicast Addresses and/or 
Centrally Assigned Unique Local IPv6 Unicast Addresses are included in one 
or both recommendations (forward and reverse) but I appreciate that is 
probably because we can't yet cite CAULAs.

Tim

-- 
Tim

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Mar 2005 11:20:58 -0800

Tim,

>probably because we can't yet cite CAULAs.

Agreed.  I will change the text to "locally assigned local IPv6 
addresses".  I should have caught this earlier.

Bob