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

From: Dan Lanciani <[email-masked]>
Date: Fri, 3 Dec 2004 15:14:31 -0500 (EST)

Mark Andrews <[email-masked]> wrote:

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

I strongly object to making this a "MUST NOT," especially with the growing
uncertainty that there will ever be a _permanent_ centrally assigned flavor
of ULA available without recurring fees.

An important feature of even locally assigned ULAs is that they are globally
unique "enough" for many/most purposes that have been discussed.  After months
of analysis to that end, their lack of absolute uniqueness is insufficient to
justify adding new prohibition on a particular range of uses at this late date.

				Dan Lanciani
				ddl@danlan.*com

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

---

From: "Brian McGehee" <[email-masked]>
Date: Fri, 3 Dec 2004 12:48:38 -0800

I have to agree with this MUST NOT.

|+    Advertising locally assigned ULA AAAA records in the global DNS
|+    MUST NOT occur as they are not globally unique and will lead
|+    to unexpected connections.

Although there is a good chance that someone else in the world has my same
name, they don't receive their mail at my home address.  OK, Bad example
(reversed).  But if there is a chance of overlap; allowing this insures
there is a chance of misdirection.

$.02
-Brian
http://consult.tavian.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
Lanciani
Sent: Friday, December 03, 2004 12:15 PM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt

An important feature of even locally assigned ULAs is that they are globally
unique "enough" for many/most purposes that have been discussed.  After
months
of analysis to that end, their lack of absolute uniqueness is insufficient
to
justify adding new prohibition on a particular range of uses at this late
date.

				Dan Lanciani
				ddl@danlan.*com

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Dec 2004 10:36:47 +1100

> of ULA available without recurring fees.

	Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG.
	If you need to publish them in the DNS you need to use a 
	split DNS configuration.  This is no different to how we handle
	RFS 1918 address.   They don't get published in the GLOBAL DNS
	because they are AMBIGIOUS.
 
> justify adding new prohibition on a particular range of uses at this late dat

	They are unique enough to link serveral hundred / thousand sites
	*with minimal renumbering required*.

	They are not unique enough to link millions of sites where the
	is no way of knowing that renumbering is required.
	
	You just cant filter them out of global respones especially once
	DNSSEC is in use.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 3 Dec 2004 17:39:59 -0600

Thus spake "Brian McGehee" <[email-masked]>
> there is a chance of misdirection.

My original thought in allowing ULA AAAA records in the global DNS was that 
it is not operationally feasible to expose those records to all of the hosts 
that have connectivity to those addresses and no others, particularly when 
you're using them to communicate privately to another organization.

There is certainly a failure mode where two parties may inadvertently select 
the same prefix and one may get traffic intended for the other due to 
entries in the global DNS, but that is no different from someone publishing 
a ULA IP address on a web page instead of a DNS name that points to that 
address.  The failure is the collision, not the DNS entry.

I did think about this and considered the odds of the above happening to be 
significantly lower than the risk of a host not being able to resolve names 
for machines it can reach via a ULA because it (or its nameserver) is 
inadvertently using the global DNS instead of a local zone file.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Dec 2004 10:31:43 +0100

Dan Lanciani wrote:
> I strongly object to making this a "MUST NOT," ...

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

          Brian

---

From: Daniel Senie <[email-masked]>
Date: Mon, 06 Dec 2004 13:27:13 -0500

>(And I would put an equivalent SHOULD NOT on centrally assigned ULAs.)

I disagree. SHOULD NOT is sufficient, as it was (is) for RFC 1918. I also 
would remove the "highly" in "highly undesirable". The leak of such an 
address is not serious. Though such leakage has occurred occasionally with 
IPv4, the world has not ended. While I understand a strong desire to "get 
it right this time with IPv6," I don't see this particular issue as one 
where the result will be anything more than annoying prospective adopters 
of IPv6 with no good reason.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Dec 2004 10:16:41 +0100

Daniel Senie wrote:
> I disagree. SHOULD NOT is sufficient, as it was (is) for RFC 1918. I 
> also would remove the "highly" in "highly undesirable". The leak of such 
> an address is not serious. Though such leakage has occurred occasionally 
> with IPv4, the world has not ended. While I understand a strong desire 
> to "get it right this time with IPv6," I don't see this particular issue 
> as one where the result will be anything more than annoying prospective 
> adopters of IPv6 with no good reason.

Personally, I could accept either MUST NOT or SHOULD NOT, and don't feel
strongly about "highly." I hope the chairs can declare a consensus...

    Brian

---

From: Bill Manning <[email-masked]>
Date: Tue, 7 Dec 2004 11:25:35 +0100

> 	because they are AMBIGIOUS.

	they do get published in the "global" DNS (whatever happened to the
IABs single coherent namespace?)   since I have seen things like:

	foo.bar.	a   192.168.31.2

that said, regardless of IETF blustering, ULA or equivalents are 
routable
address blocks - please provide an unambigious, statement of how any 
prefix
is globally restricted to a limited scope for routing)  - AND- keep 
your mits out
of my zone files thank you very much.

> 	You just cant filter them out of global respones especially once
	true...

--bill

---

From: Bill Manning <[email-masked]>
Date: Tue, 7 Dec 2004 11:30:09 +0100

On Dec 6, 2004, at 10:31, Brian E Carpenter wrote:

>> is

	keep your mitts off my zone files.
	and if the prefixes are routable -AT ALL- then i may chose to
	define my "local region" to be the Internet.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Dec 2004 13:44:35 +0100

>     define my "local region" to be the Internet.

Bill, you could do that if the prefixes are *routed* but that is
not going to be the case if the ULA spec is followed, except for
private routing arrangements. Since the spec says they MUST NOT
be globally routed, it seems entirely rational to apply the same
rule to your zone files. But as I said before, I can live with
SHOULD NOT.

    Brian

---

From: Bill Manning <[email-masked]>
Date: Tue, 7 Dec 2004 17:51:08 -0500

> rule to your zone files. But as I said before, I can live with
		please define "globally routable" in technical terms.
		and since routing is not the same as lookup, your assertion
		about the "rational" nature of registration in a lookup system
		does not hold much credence.

---

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

>         please define "globally routable" in technical terms.

Why? I didn't use that phrase. The draft doesn't say that, it says
that ULA prefixes must not be globally routed. Different.

>         does not hold much credence.

Not at all. As others have pointed out, if DNS returns AAA records
for prefixes that are not in fact routed, TCP timeouts will result.
That's sufficient reason to not put such records in your zone files.

    Brian

---

From: [email-masked]
Date: Wed, 8 Dec 2004 10:20:48 +0000

> that ULA prefixes must not be globally routed. Different.

	i guess that i am confused here.  what does it mean to be "globally routed"?
	and how is that different than "globally routable"?

> That's sufficient reason to not put such records in your zone files.

	so your DNS server in Zurich is expected to have knowledge 
	about the state of the routing system between ISPs in Argentina?
	This problem is functionally identical to the original route server
	concept that was used in the NSF NAPs.  ISP A could talk to the 
	RS and ISP B could talk to the RS, but they could not talk to each
	other ...  From the RS point of view, it had no knowledge of the
	policy filters that prevented these two ISPs from exchanging traffic.

	DNS is a lookup system.  It has zero idea about the currnet state
	of reachability/routedness ... telling me i should not place records
	in my DNS that are useful to me, just because they are not useful to 
	you is presumptious at best.

	when/if the DNS carries explicit routing information, then i'll be
	willing to buy into your argument... not until then though.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Dec 2004 11:33:28 +0100

> 	i guess that i am confused here.  what does it mean to be "globally routed"?

Advertised in BGP4+ between all or most ISPs.

> 	and how is that different than "globally routable"?

I didn't attempt to define that since it is indeed a woolly phrase.
Any prefix *could* be globally routed; the interesting question is
whether it *is* globally routed.

> 	willing to buy into your argument... not until then though.

Perhaps you don't like the reality that most enterprises operate
2-faced DNS, but they do.

     Brian

---

From: [email-masked]
Date: Wed, 8 Dec 2004 12:32:17 +0000

> Advertised in BGP4+ between all or most ISPs.

	to borrow your term, thats pretty woolly as well.
	ISP is very nebulous. It has never been adaquately
	defined.  
	given that the predominant EGP (BGPv4) has extensive
	knobs for policy control, there is not and can not be a 
	common view of "globally routed". One can take snap shots 
	from various "peepholes" but that does not global routed make.
	What really matters is can i get my packets to the folks who 
	want/need then and can they get their packets to me?  There is no such
	thing as a "globally routed" prefix.  They do not exist.
	I would like to be proven wrong of course, but I don't think
	it can be done.  Please prove me wrong.

> whether it *is* globally routed.

	bingo!  and since globally routed is nebulous, it does nto
	matter... what matters is, do my packets get to where they are going
	and will the desired replies get back.

> 2-faced DNS, but they do.

	what does that have to do with this question?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Dec 2004 11:52:03 +0100

Bill, this is my last go on this. Not that I specially want
to leave you the last word, but if you don't get what I'm
saying after all this, it's pointless to continue. Below...

> 	it can be done.  Please prove me wrong.

It is certainly true (and I check potaroo.net regularly) that the
default-free zone is different according to where you sit in the
network. But it's equally true (and the recent pseudoPI proposal
confirms it) that having any particular view of the DFZ polluted by
a few thousand non-aggregated long prefixes (for any definition of
"long" that you prefer) doesn't actually matter. That's the beauty
of BGP4, in fact. So, while you are correct that there is no
unique definition of "globally routed", because there is no globally
unique DFZ, I don't think this affects the logic here at all. If a
prefix is advertised in one or more of the world's DFZ's, it's in practice
globally routed.
> 	and will the desired replies get back.

Well indeed. I wasn't trying to say anything else.

> 	what does that have to do with this question?

Let's assume that server.example.com has an AAAA record
that returns a ULA inside company example.com, but the AAAA record is
not exported from example.com. (That's common practice today with A records
that return RFC 1918 or even global IPv4 addresses that don't happen to be
routed by example.com's ISP. In fact, that's what will happen when I press
Send on this email.) I think all the ULA draft can say is that this should
be normal practice - don't put an AAAA record outside your firewall if
the underlying address isn't routed outside your firewall. And it isn't in
fact anything specific to ULAs.

     Brian

---

From: Bill Manning <[email-masked]>
Date: Thu, 9 Dec 2004 06:41:09 -0500

> saying after all this, it's pointless to continue. Below...

we agree to disagree.  only history will tell if the IESG is making the 
right choice
here.  as a final - this looks so much like RFC 1918 that it is 
frightening.  esp
when we look at the public query load of these supposedly private 
addresses.
use of views, as common as it is, remains perverse and in contravention 
of the
IAB statement on a common namespace.  So i guess your right, this is 
not the
end2end, common namespace Internet that I thought it was.  This is the 
Internet
of NAT, Walled Gardens, and incoherency....  The market is a powerful 
master.

--bill