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

From: Bob Hinden <[email-masked]>
Date: Tue, 07 Dec 2004 13:23:08 -0800

Hi,

>OK. Lot of shouting since this was sent but not much new text.
>
>How about
>
>     Locally assigned ULA AAAA records MUST NOT appear in the global DNS,
>     since there is an extremely small probability that the corresponding
>     addresses are not unique. Even though these addresses will be
>     unrouteable in the global Internet, their leakage via DNS is highly
>     undesirable. Such AAAA records MAY appear in local regions of the DNS
>     corresponding to their region of routeability.
>
>(And I would put an equivalent SHOULD NOT on centrally assigned ULAs.)

While I am sure everyone in this discussion has read the DNS text in the 
current draft, here it is just in case:

    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.

This text (in my view) is more or less equivalent to what is proposed 
above.  The text in the draft doesn't use the upper case MUST/SHOULD 
language since this part of the document is operational guidelines and that 
language doesn't seem appropriate.  I suppose something with lower case 
must/should would work.

My personal view is that this is about all we can say now in this 
document.  I continue to think that what is needed is a separate draft that 
discusses this topic in detail.  This document might even relax the 
recommendation if warranted.  It would be a good place to describe 
different approaches to the locally and centrally assigned ULAs as well.

Chair hat on:

The -08 draft is currently in the IESG.  Almost all of the Discuss votes 
have been cleared.  If we can go with the current text it may result in the 
document being approved soon.  The more we try to fine tune it there is a 
risk of further delay.

It would be good if we could move forward on this document.

Bob

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Dec 2004 09:25:15 +1100

> It would be good if we could move forward on this document.

	Which completely ignores the operational problems caused by
	leaking reverse lookups.  We know these will exist and we
	need to take steps to prevent them.

	The only complaint I saw against my proposed text was the level
	of proscription against adding AAAA LAU LAs to the global DNS.

	Don't throw the baby out with the bath water.

	Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Dec 2004 18:22:25 -0500

At 04:23 PM 12/7/2004, Bob Hinden wrote:
>language since this part of the document is operational guidelines and 
>that language doesn't seem appropriate.  I suppose something with lower 
>case must/should would work.

On re-reading the text in the present version of the draft, and reflecting 
on recent discussion, I support your assessment and agree that the language 
presently in the draft is sufficient. I see no reason to hold the document up.

>document.  I continue to think that what is needed is a separate draft 
>that discusses this topic in detail.  This document might even relax the 
>have been cleared.  If we can go with the current text it may result in 
>the document being approved soon.  The more we try to fine tune it there 
>is a risk of further delay.

I strongly endorse this, especially in light of my comments above. Let's 
put this document to bed.

---

From: Alain Durand <[email-masked]>
Date: Tue, 07 Dec 2004 15:46:52 -0800

On Dec 7, 2004, at 1:23 PM, Bob Hinden wrote:
> While I am sure everyone in this discussion has read the DNS text in 
> the current draft, here it is just in case:
>
>    4.4 DNS Issues
>

Bob,

This is unfortunately not the only concern. Actually, i would even say 
this is
a somehow minor issue, as the risk of collision is small.
The real concern is similar to what is explain in the v6ops 
IPv6onbydefault draft.

Say that a well know host publish 2 AAAA in the global DNS, a 'regular' 
one
and a ULA one, apparently to make local things works better.
What is going to happen is that remote hosts have statistically 50% 
chance
to try the ULA first. Then, if TCP is in used, an application will
have to wait up to 3 minutes (according to present TCP specs) before
it can safely fall back to the 2nd address. Note that some 
implementations
I know have lowered this timeout, but this is still a critical issue.

In other words, the concern is not so much with publishing local 
addresses
in a local branch of the DNS, but to publish both local and global
data for the same name.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Dec 2004 10:17:02 +0100

I agree with Bob about the current draft; I still believe
it will be much better to discuss the DNS issues in depth
in a separate (dnsops) document. My piece of text was
intended in that context.

    Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 8 Dec 2004 09:27:50 -0500

On Dec 7, 2004, at 18:46, Alain Durand wrote:

> Say that a well know host publish 2 AAAA in the global DNS, a 
> 'regular' one

I don't see this as being specific to ULAs.  As the above referenced
draft points out, this can happen with a mix of IPv4 and IPv6 addresses.
It happens today with a mix of global IPv4 addresses and net 10 
addresses
being associated with the same name.

I agree that it is a problem, but not one specific to ULAs.

Now, the ULA draft tries to mitigate the issue by recommending that
ULAs not be put in the global view DNS.  I don't think we can do much
more than that.  What people do with their local DNS is their business.

Regards,
Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 8 Dec 2004 14:50:02 +0000

> I agree that it is a problem, but not one specific to ULAs.

Indeed, it's the dont-publish-unreachables's draft space... but that one
never reached consensus or thus publication.

Tim

---

From: Brian Haberman <[email-masked]>
Date: Wed, 8 Dec 2004 14:59:22 -0500

> 	Don't throw the baby out with the bath water.

The concern I have with putting these operational recommendations in
this document is that they are applicable to other scenarios (e.g. net 
10
addresses in the global DNS).

So it seems more reasonable to have a generic guidelines document
that discusses address placement in DNS.

Regards,
Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Dec 2004 08:29:35 +1100

> 
> --===============1586805975==
> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--325288981
> ;
> 	protocol="application/pkcs7-signature"
> 
> 
> --Apple-Mail-2--325288981
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	format=flowed
> Content-Transfer-Encoding: 7bit
> 
> 

	We really should be making a *one stop* document.  Sure the
	same problems apply to RFC 1918 and Link Local (both v4 and
	v6).  We may want a overriding document as well but the
	same information with specific domain names needs to in all
	to the above documents.
	
	Whenever RFC 1918 gets revised (and it is long overdue for
	revision) this sort of thing needs to be added there.  Along
	with filtering out packets with you prefix on entry.

	Most of what is in Section 4 is applicable to RFC 1918.  You
	can connect multiple sites using the address in RFC 1918, you
	just need to ensure that each site chooses a different prefix.

	There really is nothing new with ULAs.  We have been playing
	with this sort of stuff for years in one form or another.
	This document is about collecting what we know should be
	done and putting it on one place with specific details as
	they apply to FC00::/7.

	Thats why I said the DNS section was a "cop out".  The DNS
	information hadn't been collected, distilled and put on
	paper.  I attempted to do that.

	* Don't publish ambigious addresses global.
	* It is unwise (but not wrong) to publish unreachable addresses.
	* Don't let reverse queries for private address space leak.
	  That it is common to leak the private net next to you and
	  you should stop that as well as what you are using.
	* That you can the apex of the reverse zone for private space
	  to create your own deleation tree (e.g. 10.in-addr.arpa,
	  168.192.in-addr.arpa) and not have to slave all the reverse
	  zones everywhere.
 
	Mark

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 8 Dec 2004 23:34:08 -0500

Hi Mark,

>	  168.192.in-addr.arpa) and not have to slave all the reverse

I agree that it would be good to document this information, but there 
are three reasons why I personally don't think that the ULA document 
is the right place to do this:

(1) This is operational information, not part of the specification of 
these addresses, so it would be better published in a BCP.

(2) The IPv6 WG is not the best group to make broad statements about 
what should/should not be included in the global DNS.  The dnsop WG 
would be a better place for this work.

(3) The ULA document has already passed IETF LC and is in the IESG. 
It should be re-opened for by the WG for critical technical flaws at 
this point, so I don't think it makes sense to use this document as a 
vehicle for publishing general information about how to handle local 
addresses in the DNS.

We need to come to some closure on how/if the DNS portions of this 
document need to change before publication, and we need to do it 
quickly because this document is already in IESG evaluation.

Brian Haberman, I think you are serving as WG chair for this 
document, right?  Could you possibly figure out if this conversation 
has raised any new issues that need to be considered after IETF LC? 
If so, can you figure out if there is any IPv6 consensus regarding 
what to do about them?

I need to understand if it is necessary to delay this document for 
resolution of this issue.

Thanks,
Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 08 Dec 2004 20:47:56 -0800

> draft points out, this can happen with a mix of IPv4 and IPv6 addresses.

We have RFC 3484 which rationalizes the choice between IPv4 and IPv6 and 
as long as those are all global addresses the intent is that they all be 
reachable. ULAs are designed to be unreachable from the most part of the 
Internet. Thus the probability of trouble is very different.

> It happens today with a mix of global IPv4 addresses and net 10 addresses

Did you really mean IPv4 and not IPv6?

I've never seen a box that has had a net 10 *and* a global IPv4 address 
assigned to the same interface, but boxes with a ULA and a global IPv6 
address on the same interface might become very common.

    Erik

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Dec 2004 16:15:08 +1100

> these addresses, so it would be better published in a BCP.

	Then remove all the other operational content.  Saying
	prefixes should be advertised / filtered is as much operational
	content as saying what should and should not be advertised
	in the DNS.

	What I said was specific to ULAs with different constraints on
	both types of ULA. 

> would be a better place for this work.

	Well run it past DNSOPS/DNSEXT.  As far as I can see this
	was never refered to either group.  You have my options
	from such a referral.
 
> vehicle for publishing general information about how to handle local 

	It is a critical flaw not to say how to prevent excessive load
	on critical parts of the global DNS infrastucture.

---

From: Alain Durand <[email-masked]>
Date: Wed, 08 Dec 2004 21:41:57 -0800

On Dec 8, 2004, at 6:27 AM, Brian Haberman wrote:

>> This is unfortunately not the only concern. Actually, i would even 
>> say this is

Brian,

I'm of the opinion that those are important issues but it is unlikely 
they will be resolved in this wg.
The problem I have with the current text is that it somehow goes too 
far. It provides
a rationale why ULA SHOULD not be published  that is not correct and 
would inevitably lead to
confusion.

I'd suggest to not publish any rationale and simply say something like:

    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 and are discussed in the dnsop working group.

Note: I do not think you need another last call, this can be simply 
fixed
in the RFC 48h.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Dec 2004 10:10:30 +0000

> Note: I do not think you need another last call, this can be simply 

This sounds good to me.  

Tim

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 9 Dec 2004 07:46:02 -0500

>never reached consensus or thus publication.

Right.  And, while I personally agree with the 
don't-publish-unreachables concept, it has been a controversial one 
one in the DNS community.  It is not fair to use the ULA document as 
a path to standardization of that concept, when we don't know if  the 
people who objected to its publication in other fora are involved 
here.

The whole question of how/if to handle local addressing in the DNS is 
a hairy one, and one that it isn't the IPv6 WG's job to solve.

This document has already been reviewed by the IESG, and there is one 
discuss outstanding (from Ted Hardie).  So, we need to be 
conservative at this point regarding what (if any) changes we make to 
the document.  If we make substantial technical changes, the document 
will at least have to return to IETF LC and be re-reviewed by the 
IESG.  We cannot, in good conscience slip in controversial DNS 
wording into the document at this point in the process.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Thu, 09 Dec 2004 20:47:19 -0500

<WG chair hat on>

Please note that I am the shepherding chair for this document.

I have gone through the mailing list discussions on this document
several times.  Everyone should note that this document has been
through WG Last Call, IESG Review, and IETF Last Call.  Given the
level of reviews and comments, there is WG consensus to leave
the DNS text as is in the -08 version.

Given some of the operational issues raised, I am recommending
that the more global issue of reachable-vs-unreachable addresses
in the DNS be referred to the dnsops and/or v6ops WGs.  The
IPv6 WG does not have the expertise (nor the mission) to address
this DNS operational issue.

<WG chair hat off>

Regards,
Brian