Subject: Re: Proposed Changes to ULA DNS section

From: Bob Hinden <[email-masked]>
Date: Tue, 08 Mar 2005 08:36:23 -0800

Margaret,

>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.

The new text looks good to me and I have no objections to adding it to the 
document.

Bob

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Mar 2005 16:38:44 +0000

Margaret,

Maybe some of the reverse issue can be embraced in:

http://www.ietf.org/internet-drafts/draft-durand-dnsop-dont-publish-00.txt

which is a second attempt to formalise some form of consensus on these
issues (the previous attempt ground to a halt two years ago).  This
already includes the 'dont publish' aspect.   There are some additional
aspects captured here not listed in your text, but I think the reason
cited is enough.

The text seems OK.  I think "bothered to" can be removed; it smacks a
little of 'religion' from the author ;)

There may be more temptation to use ULAs for IPv6 by sites wishing to be
able to renumber without losing internal connectivity, due to the lack
of availability of PI address space for end sites, and perhaps in some
mobile network scenarios.

Tim

On Tue, Mar 08, 2005 at 11:18:41AM -0500, Margaret Wasserman wrote:
> 
> 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.
> 

-- 
Tim

---

From: Stig Venaas <[email-masked]>
Date: Tue, 8 Mar 2005 17:39:32 +0100

[...]
> no useful purpose, there is no good reason to make the existing

I haven't thought of this before, but I suppose there might be a
similar problem for link-local addresses. As you say, it's any local
addressing. I suppose the number of lookups for link-local is small
compared to what we'll have for ULA though.

Stig

---

From: Mohsen Souissi <[email-masked]>
Date: Tue, 8 Mar 2005 18:00:18 +0100

On 08 Mar, Margaret Wasserman wrote:
 | 
 | Hi All,
 | 
[...]
 | I'd also like to know if there are any objections to making this 
 | change to the ULA document.
 | 
[...]
 | 
 | NEW:
 | 
 | 4.4 DNS Issues
 | 
[...]
 | 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
                                                  ^

Maybe you mean d.f.ip6.arpa?

If my understanding is right c.f.ip6.arpa would correspond to the
future "unique centrally assigned IPv6 addresses", right?

Mohsen.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 8 Mar 2005 11:18:41 -0500

Hi All,

Margaret

---

OLD:

4.4 DNS Issues

NEW:

4.4 DNS Issues

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Mar 2005 10:49:38 +1030

Hi Margaret,

On Tue, 8 Mar 2005 11:18:41 -0500
Margaret Wasserman <[email-masked]> wrote:

<snip>

I think the new text is better too, specifically the idea of setting up
a default authorative zone for (ula).ipv6.arpa. I've been using a similar
technique to "blackhole" ad servers, by locally pretending to be
authorative for the ad server domain, and haven't encountered any issues
of note.

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.

---

From: Zefram <[email-masked]>
Date: Wed, 9 Mar 2005 09:33:48 +0000

>act as if they were authoritative for an empty c.f.ip6.arpa zone

Surely this should be d.f.ip6.arpa.  Should also do this with
0.8.e.f.ip6.arpa?

-zefram

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Mar 2005 01:45:14 +1100

> Surely this should be d.f.ip6.arpa.  Should also do this with

	There are lots of place where this should be done.
	We are talking about ULA only now.  Please do not expand
	the discussion to cover other address spaces.

	There is already drafts in DNSOPS which partially cover this
	though they talk about the old site local.  Please leave
	identifying all the possible spaces to DNSOPS.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 12 Mar 2005 01:06:02 +0100

> http://www.ietf.org/internet-drafts/draft-durand-dnsop-dont-publish 

4. Recommendation

    When publishing several addresses for a DNS label, one must take care
    not to publish at the same time addresses that are designed to
    be globally unique and reachable and addresses that are not.

So you are saying people should use split DNS?

Split DNS is evil.

But I must admit there is no other solution that is simple and works  
well.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 12 Mar 2005 12:06:35 +0100

On 8-mrt-05, at 17:39, Stig Venaas wrote:

>> not be sent to name servers for the global DNS,

> addressing.

The obvious solution is to use link-local DNS for link-local 
addresses... At least one vendor already has a handle on this:

% ftp fe80::203:93ff:fe88:672e%en1
Trying fe80::203:93ff:fe88:672e...
Connected to gapi.local.

(This behavior happens out of the box, no configuration necessary.)

---

From: Kit Plummer <[email-masked]>
Date: Sat, 12 Mar 2005 22:00:19 -0700

For sure.  This is part of Apple's mDNSResponder (mdns) and Porchdog 
Software's Howl...