Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Dec 2004 11:41:24 +0100

Mark,

I don't think "wait and see" is a cop-out, actually. Since these
addresses are by definition useless on the Internet in general,
I think local pragmatic decision taking is the best way to find
out what we *should* recommend. It's not obvious to me that
a typical corporate deployment of ULAs will need any reverse
lookup at all. It may simply be a non-problem (apart from the load
problem that as112 addresses as I understand it).

     Brian

Mark Andrews wrote:
>>Mark,
>>
>>At 03:16 PM 11/29/2004, Mark Andrews wrote:
>>
>>
>>>        Section 4.4 DNS Issues
>>>
>>>        This sections appears to be a real cop out.
>>>
>>>        It is perfectly natural for clients to want to make queries and
>>>        have these addresses returned from the DNS.
>>
>>There is a wide range of views on what is appropriate for putting these 
>>addresses in the global DNS.  For now, I think the best way to move this 
>>document forward is to leave it as is and wait until we have operational 
>>experience.  Once there is some operational experience it would be good if 
>>V6OPS or DNSOPS wrote a document about the best way to do it.
>>
>>Bob
> 
>  
> 	I think there is plenty of IPv4 experience that translates to
> 	this area.  This is basically saying that the as112 should be
> 	the default treatment for these reverse zones.
> 
> 	See http://www.as112.net/
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Dec 2004 00:34:07 +1100

> problem that as112 addresses as I understand it).

	It's not a question of how many sites will populate the reverse
	zones.  It's a question of how many sites will *not* setup the
	reverse zone and how many applications will make a reverse
	lookup on these addresses.

	You are arguing above that most sites won't setup the reverse
	zone.  This is the situation where you need the preconfigured
	reverse zones the most.

	It costs real money to absorb the load.  Money for servers.
	Money for bandwidth to the servers.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Dec 2004 16:51:24 +0100

> It costs real money to absorb the load.

Well understood. But it will be a while before this goes mainstream.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Dec 2004 08:22:00 +1100

> Well understood. But it will be a while before this goes mainstream.

	The point is that we really will want to legitimise what
	as112 will have to do.  To tell the users of these addresses
	that they SHOULD / MUST configure their nameservers to cover
	atleast the ULA addresses they can route to (not only their
	own addresses).  To tell ISP's that they can configure their
	caching servers to respond to any queries that leak from
	their clients.  To tell those that don't use ULA's that they
	can configure their servers to answer these queries and that
	they won't cause problems.

	To tell users of ULA's that it is safe for them to setup
	their own versions of C.F.IP6.ARPA and D.F.IP6.ARPA.

	To make it legitimate for nameserver vendors to pre-configure
	there servers to block these zones with appropriate knobs
	to turn them off.

 	Mark

---

From: Bob Hinden <[email-masked]>
Date: Thu, 02 Dec 2004 15:05:41 -0800

Mark,

>         there servers to block these zones with appropriate knobs

I think what you are proposing is a good idea, but it is out of scope for 
the ULA draft itself.   It would be good if you put it into a new internet 
draft that described this and the general issues regarding putting ULAs in 
the global DNS.   DNSOPS is a probably a better venue as there are more DNS 
experts there than in IPv6, but the first step is to produce the draft.

Bob

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Dec 2004 10:30:30 +1100

> experts there than in IPv6, but the first step is to produce the draft.

	The section deals with how ULA's interact with the DNS.
	This sort of detail needs to be there otherwise it will not
	be read. One can argue whether auto configuring nameservers
	needs to be there but the gist of the rest does.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Dec 2004 15:27:41 +1100

> 	needs to be there but the gist of the rest does.

	Some text.  

	Changing the NS records to point to BLACKHOLE-1.IANA.ORG
	and BLACKHOLE-2.IANA.ORG is one possible change for the
	example zones.

--- draft-ietf-ipv6-unique-local-addr-08.txt	Mon Nov 29 23:58:52 2004
+++ draft-ietf-ipv6-unique-local-addr-08.txt.new	Fri Dec  3 15:22:43 2004
@@ -469,19 +469,51 @@
 
 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
+   Sites using ULAs need to ensure that reverse DNS queries for ULAs do not
+   leak out of the site(s) using the ULAa.  This is best ensured by
+   configuring the sites DNS servers to serve both C.F.IP6.ARPA and
+   D.F.IP6.ARPA in addition to anymore specific zones under these used for
+   local reverse lookups.
 
+   Leaking reverse queries will put extreme loads on the infrastructure
+   servers and has in the past required sacrificial servers to be
+   deployed to absorb the load cause by leaking queries.
+   
+   e.g.
+	The following "empty" zones will prevent queries leaking from the
+   zone.
+
+   C.F.IP6.ARPA:
+        C.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. <contact-address>. (
+                                  1 7200 3600 604800 3600 )
+        C.F.IP6.ARPA. 3600 IN NS  C.F.IP6.ARPA.
+        C.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX
+        C.F.IP6.ARPA. 3600 IN NS  ::1
+
+   D.F.IP6.ARPA:
+        D.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. <contact-address>. (
+                                  1 7200 3600 604800 3600 )
+        D.F.IP6.ARPA. 3600 IN NS D.F.IP6.ARPA.
+        D.F.IP6.ARPA. 3600 IN TXT Generated as per RFCXXXX
+        C.F.IP6.ARPA. 3600 IN NS  ::1
+
+    Multiple sites connecting using ULAs may want maintain common 
+    C.F.IP6.ARPA and D.F.IP6.ARPA zones and use them delegate more specific
+    zones.  It is not expected that centrally addresses will have delegations
+    in the global DNS tree.
+
+    Advertising locally assigned ULA AAAA records in the global DNS is
+    MUST NOT occur as they are not globally unique and will lead
+    to unexpected connections.
+
+    Advertising centrally assigned ULA AAAA records in the global DNS is
+    not encouraged at this point in time as not all applications recover
+    well from attempting to reach a non-reachable addresses.
+    
+    Populating the reverse zones with appropriate PTR records is at the
+    site's disgression.  One should note that many applications will not
+    accept a PTR record without the associated AAAA record also being
+    available.  Supplying this may require a split DNS configuration.
 
 4.5 Application and Higher Level Protocol Issues

---

From: Tim Chown <[email-masked]>
Date: Fri, 3 Dec 2004 14:01:01 +0000

Hi,

Can I also add we have some discussion on this issue in the (now obsolete) 
draft draft-ietf-dnsop-dontpublish-unreachable-03, which can be found at:

http://www.watersprings.org/pub/id/draft-ietf-dnsop-dontpublish-unreachable-03.txt

After Washington IETF, a couple of us (at least myself and Alain) discussed 
taking this one up.   One important issue is who is harmed by such publishing
beyond the site advertising and sites connecting to it.  What is the 3rd
party impact?

The above text mentions ambiguity as the key concern foor private addresses,
but also talks about otehr types on unreachables.

Regarding lack of uniqueness, if we cannot assume that CA ULAs are unique,
then should we bother with them at all? :)   Mark's mail suggests lack of
such a guarantee is an issue, but that is only for non-CA prefixes, where
people will be tempted to use the minimal prefix, i.e. all 0s most likely 
instead of a random 40 or 41 bit number (whichever it is :), because they
will have to type these addresses in on an operational basis.

Tim

-- 
Tim