Technical Summary
This document defines an IPv6 unicast address format, called Unique
Local IPv6 Unicast Addresses, that is globally unique and is intended
for local communications. This document defines thes subset of
Unique Local Addresses that can be allocated locally by the site.
These addresses are intended to be the replacement for the Site-Local
IPv6 addresses that are being deprecated. The ULA addresses offer a
similar facility without the drawbacks associated with Site-Local
unicast addresses.
Working Group Summary
The IPv6 working group has done extensive review of this document and
this document reflects the consensus of the group.
Protocol Quality
This document has been reviewed by members of the ipv6@ietf.org
mailing list and by the working group chairs. This document has been
reviewed for the IESG by Margaret Wasserman.
RFC Editor Note
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 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.