Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)]

From: "Michel Py" <[email-masked]>
Date: Tue, 26 Nov 2002 14:33:42 -0800

> Charles E. Perkins
> Rate-limiting has to be part of the solution.
> Thankfully, it's not very hard.

Especially if you cache the requesting ipv4 address or IPv6 prefix for
24 hours or more. One GUSL allocation per IP per day is more than
enough.

I think that the complete uniqueness is a matter of psychology more than
anything else. Even if the odds of collisions with a hash or random are
no better than winning the lottery, there are some people that actually
win (not me, sigh). Given that Charlie could provide true uniqueness for
free, why consider a system that does not provide true uniqueness?

Michel.

--------------------------------------------------------------------
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: Wed, 27 Nov 2002 00:54:54 +0200 (EET)

> free, why consider a system that does not provide true uniqueness?

I'm not sure whether you haven't been listening or don't agree with my 
(and some others') reasoning.

Nearly unique is IMO much better than completely unique.  (Actually, 2^38 
may even be too unique by the same reasoning.)

That's because those addresses are meant to be unique _only_ within a
scope.  Addresses leak, yes, but that doesn't hurt when the probably of
collision then is suitably low (e.g. below 0.1%).

If the addresses are _unnecessarily_ unique, they will be used for wrong
purposes, no matter what.

It's better that people don't associate _any_ addresses that are not of 
global scope to be globally unique.

IMO we will not want to have site-locals be too attractive: we don't want
to have (too big) competition to global-scope addresses.  IMO we want
_IPv6_ users to use _globals_, and (some) site-locals only when they more
or less have to.  

Globally unique PI addresses are a step in entirely wrong direction.

As you see, these are not really all that "technical" reasons, but I don't
want to see the world where people are using IPv6 with similar
walled-gardens as NAT's create today.

(and besides, with "nearly unique" there's no need for any infrastructure
to support them.)

Note: I'm not disputing the (possible) usefulness of globally unique PI
for e.g.  multihoming etc. purposes, but those are _global scope_
addresses, and that's not the point here.

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 23:49:11 -0500

> Globally unique PI addresses are a step in entirely wrong direction.

I entirely disagree.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 08:55:02 +0200 (EET)

> > Globally unique PI addresses are a step in entirely wrong direction.

I should have said "globally unique PI site-local addresses" but that does 
not probably change your statement.

> I entirely disagree.

Care to elaborate a bit?

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 08:33:46 -0500

> not probably change your statement.

we've been talking about this for weeks.  the worst problems with
site-locals are their ambiguity; we need global uniqueness to get
rid of that ambiguity and also to allow them to be reliably routed
between sites.

however we may just be using the words in slightly different ways - 
globally unique vs. probably unique,
site-local (FEC0::/10) vs. some site-specific address space TBD,
etc.

I currently think 

- we need a new address space for globally-unique PI addresses (GUPIs)
  
- some mechanism for ensuring global uniqueness is probably better
  than having those addresses be probably unique

- we need an understanding that GUPIs are not globally routable
  unless/until we know how to make that routing scale - but NOT
  an architectural limitation against it

- use of site-locals (FEC0:://10) should be discouraged in general
  with a possible exception for isolated/test networks

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 15:53:43 +0200 (EET)

> site-local (FEC0::/10) vs. some site-specific address space TBD,

I think your "may" may have hit the nail on the head.

I'm _only_ _specifically_ thinking of "how do we fix site-locals to make 
them usable".  I do _not_ want this w.g. to try to bang its head against 
the wood, trying to get workable globally scoped unique PI, possibly 
routable, addresses to work (in all layers from L1 to L10).  Seems like a 
total waste of energy to me, as most efforts are _not_ in the layers we 
can really control.

You seem to be thinking "how do we provide alternative globally unique,
possibly routable, PI addresses so that site-locals would not be needed".

Looking at this from your perspective:
 - I think GUPI, possibly routable, global-scope addresses might be ok, I 
have lots and lots of reservations about them, but they're not for this 
working group to try to cope with.
 - If we just stick to modifying site-locals somehow (and leave the PI 
global scopes out of the problem statement), I would definitely push for 
"nearly unique" site-locals

Does this seem like a fair characterization?

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 09:16:22 -0500

> "nearly unique" site-locals

I think this WG needs to define GUPIs - because that seems like the best
way to take the pressure off of SLs to be misused.  however I don't think
we should try to make them globally routable, at least not now.

once we do that, I don't know that nearly unique SLs is such a big deal,
but I wouldn't object to them.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 16:44:00 +0200 (EET)

> we should try to make them globally routable, at least not now.

I don't really agree that this is what we should be doing.

I think:
 - if we specify global-scope GUPI's they will also be used when regular
global-scope addresses would be better (and we should encourage PA
addresses, because they actually _work_); ie. they will cause trouble and
may eventually result in prefix/address translation (NAT-like) problems.
 - if we instead specify site-local, near-unique addresses, folks still 
treat them as site-locals; they are used less than GUPI's would be, in 
site-local contexts only.  Near-uniqueness removes the problems with 
ambiguity of site-locals.
 - I think it's better to deal with reality (provider assigned addresses) 
than try to escape it (provider independent addresses), even though how 
enticing it could be...

Following my thinking, site-locals could of course be used as an aid for 
e.g. renumbering or intermittently connected sites, but that should be 
better than having delusions that using global-scope addresses there would 
somehow make such addresses "global" or "globally usable".

I hope this clarifies my reasoning?

> but I wouldn't object to them.

.. But I agree if we _do_ specify these global-scope GUPI's, adding
uniqueness to site-locals seems like a useless effort.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 11:13:57 -0500

> may eventually result in prefix/address translation (NAT-like) problems.

mumble.  all we can do is give people good tools, explain how they were
intended to be used, and hope they use them in an optimal fashion.   
right now we are in a situation where SLs will be used for situations
where they are not good tools.  the only way to solve this problem is
to give people better tools, and GUPIs seem to be a good fit.

yes, some people will probably try to use GUPIs where PA globals would
be a better choice.  eventually, they'll learn.  they'll have to renumber
to fix that problem, but it won't be more difficult than any other kind
of IPv6 renumbering, and we have to solve that problem anyway.

> ambiguity of site-locals.

yes, but that's not the only problem with site-locals.  another problem
is that it's widely believed that they are some kind of security mechanism.  
another problem is that it's widely believed that hosts and applications
should treat them differently than other addresses, either by filtering them
or by preferring them over other addresses.  in other words, there are 
lots of dubious assumptions about site-locals that are more easily and
more effectively fixed by discouraging many uses of site-locals, and 
providing an alternative for the valid use cases, than by trying to 
change people's mindsets about what site-locals means.

> than try to escape it (provider independent addresses), even though how

"reality" is subjective.

I think it's fair to say that we know how to make PA addresses routable
on a large scale, and we don't know how to make PI addresses routable
on a large scale.  On the other hand, I think it's also fair to say that
PA addresses don't do everything that people need - they don't support
multi-provider multihoming, and they don't support networks that aren't 
connected directly to the global internet.  So PA addresses are desirable
but not sufficient.

> somehow make such addresses "global" or "globally usable".

I guess we are concerned about different anticipated delusions.  I'm much
more concerned about the delusions that already seem to exist about the 
applicability of site-locals than about the delusions that might exist
about the applicability of PI globals.

I do think that an addressing architecture that simplifies 
decision-making would minimize the potential for delusions.  From 
that perspective, a simple table is quite attractive:

case				| recommendation
--------------------------------+-----------------------
network connected to the        | PA global addresses
public internet                 |
				|
network not connected to the    | PI global addresses
public internet, but            |
connected to other IP networks  |
via private arrangements        |
                                |
isolated stable network		| PI global addresses or 
                                | site-local addresses
                                |
isolated ad hoc network         | site-local addresses

Keith