Hi All,
During IESG review, Mark Andrews raised a significant operational concern regarding the DNS section of the ULA document (draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently delaying approval of the document until the issue can be resolved.
The concern, which is shared by other DNS experts, is that widespread use of these addresses could cause a significant, and pointless, load on servers in the ip6.arpa zone -- a problem that could be avoided by different recommendations in the DNS section of this document. The DNS directorate met on Sunday evening and came up with the attached wording (to replace the current DNS section in the ULA draft) that will address this concern.
We will discuss this issue briefly at the IPv6 meeting this afternoon, but I wanted to make sure that you all have a copy of the text for consideration before the meeting (since it can't reasonably fit on a single slide).
I'd also like to know if there are any objections to making this change to the ULA document.
Margaret
---
OLD:
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. The operational issues relating to this are beyond the scope of this document.
For background on this recommendation, the concern 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 PTR record might be registered by two different organizations. Due to this concern, adding AAAA records is thought to be unwise because matching PTR records can not be registered
NEW:
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 c.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 bothered to 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
