Subject: Updated V3 "Revised ULA DNS text"

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

Here is what I hope to be the final update.

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 locally assigned 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 locally assigned 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 locally assigned 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 locally assigned 
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 locally assigned 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: Margaret Wasserman <[email-masked]>
Date: Mon, 14 Mar 2005 07:22:45 -0500

This looks good to me, Bob.

Let me know when the IPv6 WG is comfortable with the text, and I will 
put in an RFC Editor note and approve the document.

Thanks,
Margaret

At 5:58 PM -0800 3/10/05, Bob Hinden wrote:
>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 
>locally assigned 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 locally assigned 
>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 locally assigned 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 locally assigned 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 
>locally assigned IPv6 Local addresses in use, returning RCODE 3 is 
>in fact the correct answer.
>
>-----------------
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Mar 2005 23:46:43 +1030

Hi Margaret, Bob,

On Mon, 14 Mar 2005 07:22:45 -0500

> put in an RFC Editor note and approve the document.

I think it explains the DNS issues well.

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.