Subject: even one reason why provably unique SL is needed?

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Nov 2002 19:42:53 +0200 (EET)

Hello,

People seem to be dodging this, so let's take it into another thread.

There seems to be an assumption that provably unique SL addresses would be 
needed.

Can you tell me at least one reason (note: don't say globally routable)
where this would be required instead of "nearly enough" unique identifiers
(chance of collision about 1/2^38)?

Why I prefer "nearly unique"?  Some reasons from the top of the head:
 - 2^38 is big enough to be in practise collision-free
 - there is no need for _any_ registration infrastructure <=== !!!!
 - automatical generation is easier, also for e.g. disconnected sites
 - people don't get funny ideas they could be totally collision-free and 
thus routable in the internet; or use them as global identifiers
 - gives people some reason to use _globals_ too, when they're really to 
be used

But then again, my take is that we shouldn't be advocating these unique
SL's everywhere anyway, most should just be able to stick to globals.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 14:38:46 -0500

actually I'm fairly convinced that "nearly unique" would be good enough 
as long as we could convince people to actually assign random site
prefixes instead of just choosing one (like all zeros or whatever).  

and they seem to have the "right" property regarding routability -
the chance of collisions is so low that you can hook them up with
a large number of other networks via private arrangement without
fear of collision, but high enough that there's a clear incentive 
for ISPs to filter these things from routing advertisements.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Nov 2002 22:33:43 +0200 (EET)

> prefixes instead of just choosing one (like all zeros or whatever).  

Yes, this is the problem.. but the way it's written down or helper apps 
included in the implementations to do this for you would help, I suggest.
 
> for ISPs to filter these things from routing advertisements.

Exactly.

I don't think we should be providing totally unique PI addresses.  
There's just no need for them.  Or actually there is, _but that's not in
the site-local context_.

So I fear if we provide totally unique PI addresses, people would just 
abuse them, sooner or later.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 15:40:05 -0500

> There's just no need for them.

mumble - being able to track down attackers' prefixes really would be
useful.  but that would require that routers only route registered 
prefixes between sites.  I don't know how to enforce, or even encourage, that.

Keith

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Nov 2002 20:51:57 +0000

Keith,

> for ISPs to filter these things from routing advertisements.

what is your position on probably unique local addresses versus
site-locals? as probably unique addresses have a limited topological
span wouldn't applications still have pretty much the same issues as
with site-locals?

/ot

---

From: [email-masked]
Date: Tue, 26 Nov 2002 08:00:12 +1100

> for ISPs to filter these things from routing advertisements.

	"nearly unique" is not good enough.  You want to be able to
	register these addresses in the ip6.arpa tree.  You don't
	want to force every site to manually configure the top of
	their reverse tree into every nameserver in the organisation.

	This will not work and will just result in reverse queries
	for this address range hitting the ip6.arpa servers similar
	to what happens with the RFC 1918 nets under in-addr.arpa.
	We would then have to set up sacrificial servers as we don't
	have anyone to point too to say "set up your reverse servers
	as you are impacting on the ip6.arpa servers".
	
	What does work is having truly unique addresses and delegating
	the reverse servers.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 16:19:40 -0500

> span wouldn't applications still have pretty much the same issues as

no.  first, probably unique addresses don't have any strict limits
on their topological span - done right they could be routed to 
thousands of networks - just not to *every* network.  second, the
biggest problems with site-locals are not that they might get exposed
to areas of the network from which those addresses are not reachable,
but that they're ambiguous.  'probably unique' addresses (given
a sufficient number of random bits) are effectively unambiguous.

it seems like the goal here is to find the best mechanism to encourage
the sites that use these addresses to pick prefixes that are in practice
unique within the transitive closure of the set of networks to which 
they connect.   this is mostly a human factors question.  

right now I'm thinking that the real trick is getting network operators 
to learn how to get a (probably or not) unique prefix by any means - and 
that the difference between going to a registry, running a random number 
generator, deriving a prefix from some other number, or getting a prefix 
from a tag stuck to a router - is probably noise compared with the
educational effort common to all of these.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 16:29:08 -0500

>         register these addresses in the ip6.arpa tree. 

yeech.  it's a good point.

Keith

p.s. though I can't help but think that something is terribly broken 
about our way of doing address lookups if it imposes this kind of
constraint on how we assign addresses.  
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Nov 2002 23:36:55 +0200 (EET)

> 	their reverse tree into every nameserver in the organisation.

I don't want the administrative pain in the ass of someone managing flat 
ip6.arpa reverses.

No way, no way at all.

Require the DNS server at the edge of the site be authoritative for the 
whole of fec0::/10 or blackhole the queries.

(I don't think too many people would even want to register site-locals in
the _global_ reverse DNS, queriable by anyone -- remember, they're not to
be used globally, and reverses in and itself are already considered a
"security hazard" by some.)

Let's not go down the path of putting site-locals anywhere near the global
ip6.arpa.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 16:45:49 -0500

> be used globally, 

no, it doesn't follow.  

it seems to me that the thing we need to do is to not to try to prevent
leakage, but to make sure that leaked addresses don't cause harm.

if we actually had globally unique site-locals, I don't see why we should
try to stop people listing them in DNS. 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Nov 2002 23:55:02 +0200 (EET)

> leakage, but to make sure that leaked addresses don't cause harm.

I could live with that.

> try to stop people listing them in DNS. 

"There is no free lunch."

The whole concept of trying to put something like that in the reverse DNS
(possibly meaning a flat space) makes my head hurt.

At first sight, the cost seems _way_ too high, and profit borne only by
few.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Nov 2002 14:33:19 -0800 (PST)

[]

So I've been watching this debate about globally
~unique site locals and I don't understand how the
end node knows whether a particular destination
address is in scope (reachable) or not. The old
way, it just matched it to its own scoped prefix
and was done with it. What I've been hearing is
some desire to be able to patch together other
sites (extranets)... how would a node know which
scope address to use in that case?

	      Mike

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 19:59:04 -0500

> scope address to use in that case?

in general the only way for node A to determine whether node B
is reachable is for A to send a packet to B.  if A gets a reply
from B, B is reachable.  if A gets an ICMP message back, B
is not reachable (for temporary or permanent reasons).  if A
gets nothing back, either B is (temporarily) unreachable or
B doesn't want to answer A. 

but you'll never be able to determine this by looking at prefixes.

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Nov 2002 12:12:41 +0900

>>>>> On Mon, 25 Nov 2002 19:42:53 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> There seems to be an assumption that provably unique SL addresses would be 

Perhaps this is a silly comment, but excuse me, I remember a very
similar proposal by Paul Francis at an IETF meeting a few years ago.
At that time the wg should have rejected the idea, but I didn't
remember the details about the discussion and the reason why the idea
was rejected.  Anyway, we may be able to learn something from the
experience (not to waste time, not necessarily to reject the idea
again).  I'm sorry, but I don't have time to dig the minutes or ML
archives on the discussion for now.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Nov 2002 10:21:58 +0100

Which is the moment when you would discover that your prefix wasn't
unique enough, so you'd go and get a new one. Not a big problem, since
it would be very rare.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Nov 2002 11:43:07 +0200 (EET)

On Tue, 26 Nov 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
> was rejected.  

Thanks for the pointer.

> Anyway, we may be able to learn something from the

It's definitely worthwhile to learn from the past.

The draft is available at:
http://www.join.uni-muenster.de/drafts/draft-francis-ipngwg-unique-site-local-00.txt

The meeting was March 2001.

Text from minutes 
http://playground.sun.com/ipv6/minutes/ipng-minutes-mar2001.txt :

====
IPv6 Near-Unique Site-Local Addresses / Paul Francis
   <draft-francis-ipngwg-unique-site-local-00.txt>
----------------------------------------------------

  [See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Proposing to make site local prefixes non-local by adding a random number
to "zeros part" in site local addresses.

Now thinks that this doesn't help with the main problems stated in the
draft.  When merging sites, half will still have to renumber.  Not any
different from using the current site local prefix.  In both cases some
of the subnets will have to be renumbered.

Crawford:  Not quite as bad.  When merging each half could maintain their
original unique prefixes.  

Deering noted that notion of sites is not whole companies.  More like a
notion of a campus.  He also thinks we should think about non-routable
global address space.  Thinks there may need for that.  Something like a
special TLA that ISP's will never route in the global Internet.

Alain Durand, think this is unnecessary as we have lots of global
addresses and we don't need to create way to use local addresses for
non-local communication.

Additional discussion.
=====

But, when merging two sites, you don't need to renumber unless you want 
to.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Nov 2002 11:48:50 -0500

>         register these addresses in the ip6.arpa tree.

Do you?  How does this fit with the concept that unreachable
addresses should not be included in the DNS?

As soon as we have any sort of private addressing (VPNs, firewalls
or any type of site-local addressing, I think we're stuck with some
sort of split DNS that includes local addresses in local name lookups,
but not in global ones, right?

Is the reverse look-up tree an exception to this?  I suppose it would
have to be, if you want people from outside the site to be able to
identify the source of a leaked address...  But, it's not clear how
this would work with mostly-unique addresses.

>         What does work is having truly unique addresses and delegating

Yes.  Truly unique addresses are better for including in the reverse
DNS, even if they aren't routed globally.  They also have the advantage
that if there is an overlap that is causing problems, it is possible
to find out what organization is actually registered to use that prefix.

But, are these (fairly minor) benefits worth the cost of requiring a
registry, etc?

Margaret

---

From: [email-masked]
Date: Sat, 30 Nov 2002 08:28:53 +1100

> addresses should not be included in the DNS?

	Well a entry in the ip6.arpa tree is *not* an *address*.

	As for the forward entries the important thing is not to
	publish ambigious addresses.  It really does not matter if
	you publish unreachable addresses especially if you have
	sorting rules which allow you to have a better than 50/50
	chance (with two address) of making a connection the first
	time.  This requires that the local resolver has some sorting
	rules which are required by RFC 103[45].

	e.g.
		local sites first, then globals, then other sites.

	local sites first defaults the sites the machine is in but
	may be expanded to known locally connected sites.
 
> but not in global ones, right?

	No.  You are stuck with split DNS if you have ambigious addresses.
	You might have connection delays if you don't have good local
	policy to choose the right address but unless the application
	is broken you will get a connection.
 
> this would work with mostly-unique addresses.

	It won't work with mostly-unique addresses and the addresses
	will leak and we will have to set up sacrificial servers to
	save the ip6.arpa servers like we currently hace sacrificial
	servers to save the in-addr.arpa servers.
 
> But, are these (fairly minor) benefits worth the cost of requiring a

	Yes.   Look at the current costs of supporting the sacrificial
	servers for RFC 1918 addresses.  These servers get more queries
	per second than the root servers.  Do we want to have to run
	sacrificial servers forever?

	Also you don't force a organization to do its DNS in-house.  It
	can out-source its DNS maintenance if it wants to if you have
	truly unique addresses.  Given the level of compentance I see
	with the DNS today out-sourcing is a good thing.

	Mark