Subject: Re: what the "scope" disagreement is about

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 1 May 2003 15:58:25 -0500

Thus spake "Keith Moore" <[email-masked]>
> being able to distinguish an ambiguous address from a global address
> doesn't solve the problem of requiring hosts or apps to be aware of
> topology in order to make address selection.

A host/app needs to be similarly aware of topology (and security policy) to
make any reasonable selection between multiple global addresses.  Adding
non-globals to the mix doesn't make things significantly worse.

> > Yes, we need to complete the work on making the 38 bits globally
> > unique, but that can't happen if we start by eliminating the first 10.
>
> If we can agree on how to make the first 48 bits globally unique, does
> it really matter what values are assigned to the first 10 bits?

Yes, it does.  Having a common prefix for non-global addresses makes the job
of network managers much simpler, and thus reduces the likelihood of leaks.
Does it need to be a 10-bit prefix?  Not really, but FEC0::/10 is already
there.

> (yes, GUPIs, NOT SLs.  they WILL be routed between sites, for good
> reasons, and we shouldn't try to stop this)

Since this is the first time I've seen "GUPI" used, should I assume that
means a globally unique provider-independent prefix which isn't globally
routed?  If so, I think you're using that term in the same sense Tony uses
SL.

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

--------------------------------------------------------------------
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: Thu, 1 May 2003 17:33:15 -0400

On Thu, 1 May 2003 15:58:25 -0500
"Stephen Sprunk" <[email-masked]> wrote:

> A host/app needs to be similarly aware of topology (and security
> policy) to make any reasonable selection between multiple global
> addresses. 

agree.

> Adding non-globals to the mix doesn't make things significantly worse.

Disagree.  First, it immediately reduces the available choices, and
thus, the potential for poor choices (since SLs are more often poor
choices than not). Second, it pushes the burden of routing back into the
network where it belongs.  Third, while it's possible (though
unattractive) for the network to supply some topology information
to hosts in a world where identifiers for points in the topology are all
are taken from the same name space, having ambiguous addresses makes
this completely infeasible.

> > If we can agree on how to make the first 48 bits globally unique,
> > does it really matter what values are assigned to the first 10 bits?
> 
> Yes, it does.  Having a common prefix for non-global addresses makes
> the job of network managers much simpler

Not clear; since it doesn't necessarily give them the flexibility they
need.  The idea that a network has only one boundary of interest is
of fairly limited applicability; it's certainly not something that is
general enough to be wired into the addressing architecture.

however, I was referring specifically to the prefix FEC0://10.  Yes,
it's already allocated, but it's also defined in such a way as to be
dysfunctional, and too many broken assumptions are wired into existing
code.  So for the sake of compatibility it seems better to allocate
another prefix for GUPIs.

> Since this is the first time I've seen "GUPI" used, should I assume
> that means a globally unique provider-independent prefix which isn't
> globally routed? 

yes.

> If so, I think you're using that term in the same sense Tony uses SL.

IMHO, they shouldn't have any "site" or filtering assumptions wired into
them, they're just a set of prefixes that are not dependent on a
provider and can't be assumed to be globally routable.  But to make
them work we'll need a way to transparently map/forward them to routable
prefixes.

Keith