Subject: RE: Limiting the Use of Site-Local

From: "Richard Draves" <[email-masked]>
Date: Thu, 31 Oct 2002 10:07:19 -0800

> I am _not_ operating under the assumption that all 
> globally-unique addresses will appear in global routing 
> tables.  If I want to have a private network, I should be 
> able to get a globally unique (routable, but _not_ 
> necessarily globally routed) address, and _not_ have my ISP 
> advertise that prefix into the global routing tables.  If my 
> ISP's policy (or some higher-level policy) requires that I 
> get a second /48 in order to have address space that isn't 
> advertised, I could just get a second /48...

So we have a site with a globally-routable /48 prefix. Are you saying
that instead of using site-local addresses in addition to its global
addresses, the site could use a second /48 global prefix that is not
globally routable and is filtered at the site boundary?

This would be silly. It would be just like site-locals except with a
non-standard prefix. It would work worse than site-locals because
Default Address Selection wouldn't work properly and because of Keith's
issue of distributed apps that do referrals - those apps wouldn't be
able to distinguish the two kinds of addresses to do the right thing.

Rich

--------------------------------------------------------------------
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, 31 Oct 2002 14:00:05 -0500

> globally routable and is filtered at the site boundary?

absolutely.
 
> non-standard prefix. 

no, the prefix should be standardized.

> It would work worse than site-locals because
> Default Address Selection wouldn't work properly 

Default address selection doesn't work properly anyway, partially because
it favors SLs over globals, and partially because the idea that you can 
expect a default address selection rule to work in the absence of information
about the app's requirements, and to do the right things with scoped 
addresses, is naive.

> and because of Keith's

sure they would be able to distinguish them, because the prefix would 
be standardized.    however "the right thing" is simply to favor 
routable globals over non-routable globals but to try all of them -
that way, if two nodes don't manage to connect, it's either because 
the net is broken or the net is prohibiting the connection - either
way it's beyond the the app's control.  the app is able to do everything
that can possibly be done and with almost zero additional complexity.

compare this to the SL case where the app either has to 

a) artifically limit connectivity by filtering SLs when it's not sure
   that nodes could connect using them, OR 

b) include potentially SLs in referrals 
   define an addressing scheme for all nodes used by the app
   whenever connecting to an SL address check to see whether you're
    really connecting to the node you think you're connecting to
   and perhaps implement routing across SL boundaries for the case
    where the customer demands that the app support it
    (which is quite often the case - people do expect apps to work
    across site boundaries) 
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Thu, 31 Oct 2002 11:59:25 -0800

Keith Moore wrote:
> ...
> Default address selection doesn't work properly anyway, 
> partially because it favors SLs over globals, and partially 
> because the idea that you can 
> expect a default address selection rule to work in the 
> absence of information about the app's requirements, and to 
> do the right things with scoped 
> addresses, is naive.

You appear to be skipping past the word 'default'. When an app has
explicit requirements, it should not expect some default behavior
underneath it to do the right thing. The point is that the majority of
simple apps don't need to worry about this, because the stack can do the
right thing for them. For the complex app, it will need to exercise its
own address management rules in any case.

> routable globals over non-routable globals but to try all of 
> them - that way, if two nodes don't manage to connect, it's 
> either because 
> the net is broken or the net is prohibiting the connection - 
> either way it's beyond the the app's control.  the app is 
> able to do everything that can possibly be done and with 
> almost zero additional complexity.

The only difference between the non-routable globals and SL is the need
for sites without routable global prefixes to coordinate the SL space
when they connect. In the end, any prefix that is not in the global
Internet routing table could be used as you describe, but disconnected
sites want a prefix without paying a service provider for one, and
connected sites don't want to pay for a second one and have to worry
about it mistakenly being routed at some point. If we had a PI address
mechansim, we could avoid the payment issue, but that would not remove
the routability issue. The only way to technically reduce that threat is
for the table to contain an ambiguous value. Something a provider might
even be willing to intentionally black-hole as a value-added service. 

There are other fundemental business reasons we need a PI space. To help
us take the fear out of routing table bloat, Michel and I have taken
different approaches to define a PI space. If we get there, that space
would make more sense for the multi-party app than SL, since it would
otherwise would appear to be just another global prefix.

>     (which is quite often the case - people do expect apps to work

As I said, this is the basis of a BCP. I know you don't like the idea
that it is the best we can do today in practice, but that is reality so
let's move on. Rather than waste time trying to prevent a network
manager from doing what he insists on doing, why don't we put the effort
into getting a workable PI address space established so we can show an
alternative with greater value.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 15:19:01 -0500

> Keith Moore wrote:
> > ...
> > Default address selection doesn't work properly anyway,=20
> > partially because it favors SLs over globals, and partially=20
> > because the idea that you can=20
> > expect a default address selection rule to work in the=20
> > absence of information about the app's requirements, and to=20
> > do the right things with scoped=20
> > addresses, is naive.
> 

maybe we need to define what is a 'simple app' then for which the 
'default' behavior suffices - because it seems to me that far too
much faith is being placed in 'default address selection' to address
the burden that is imposed by requiring hosts/apps to do address 
selection in the first place.

in other words, just because a set of default rules might work for
some apps is not a justification for requiring all apps to 
implement address selection code that often cannot work well.

> when they connect. 

first, you make that sound easier than it really is;
second, that's not the only difference.  

its not as easy as you make it out to be because there are industries
that involve hundreds or thousands of suppliers (hundreds or thousands
of separate sites) that want to make extensive use of private interconnects.
it's easier to use non-routable globals than to make coordination of SLs 
scale to that degree.

another difference is that non-routable globals are unambiguous, so that
apps that operate across site boundaries aren't required to deal with 
ambiguous addresses.  another difference is that with non-routable globals
the app can allow the network to do all of the routing and enforce policy 
about who can connect to whom - with SLs the app will often have to do
routing as site boundaries will not always coincide with boundaries of
the application, and therefore any policy about who can talk to whom can
only be implemented in the app.    the ability of the network to provide
security in depth is decreased with SLs.

> In the end, any prefix that is not in the global
> about it mistakenly being routed at some point. 

I don't think paying for an address is a significant issue - the cost
of getting an address (without connectivity) should be similar to that
of getting a domain name - probably less, since trademark protection
shouldn't be an issue for addresses.

> If we had a PI address
> for the table to contain an ambiguous value. 

I've already explained why that 'threat' isn't a problem.

> otherwise would appear to be just another global prefix.

we agree that a PI space is needed.  now if we could just discourage use
of SLs so that such apps would be able to run in most networks...

> > compare this to the SL case where the app either has to=20
> >=20
> >    that nodes could connect using them, OR=20
> >=20
> > b) include potentially SLs in referrals=20
> >     across site boundaries)=20
> 
> let's move on. 

no, it's not even the best we can do in practice assuming we're stuck with SLs.

as it is obvious that SLs present many difficulties on many levels
of the stack, we really should declare consensus that they should
be discouraged except in cases where we know they won't cause problems -
like isolated networks - and move on.

> Rather than waste time trying to prevent a network

nobody is trying to 'prevent' the network manager from doing anything -
but we would do well to provide such managers with the benefit of our
understanding that SLs are not as good an idea as was originaly thought.

and yes, let's get a workable PI space established.  we seem to agree 
that this is a better alternative.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 31 Oct 2002 14:14:58 -0800

Keith Moore wrote:
> 'default' behavior suffices - because it seems to me that far 
> too much faith is being placed in 'default address selection' 
> to address the burden that is imposed by requiring hosts/apps 
> to do address 
> in other words, just because a set of default rules might 
> work for some apps is not a justification for requiring all apps to 

One address per interface doesn't solve all known problems either. 

> 
> > The only difference between the non-routable globals and SL is the 
> > need for sites without routable global prefixes to 
> coordinate the SL 
> > space when they connect.
> 
> its not as easy as you make it out to be because there are 
> industries that involve hundreds or thousands of suppliers 
> (hundreds or thousands of separate sites) that want to make 
> extensive use of private interconnects. it's easier to use 
> non-routable globals than to make coordination of SLs 
> scale to that degree.

Careful, you are arguing that 38 bits is inadequate space for an
industry specific registry...  Also, this argument amounts to a claim
that the industry can't manage an internal registry, but would be glad
to impose its needs on the public registries.

> 
> another difference is that non-routable globals are 
> unambiguous, so that apps that operate across site boundaries 
> aren't required to deal with 
> ambiguous addresses. 

Didn't you notice the phrase: 'coordinate the SL space when they
connect'? If the space is coordinated, it is unambiguous. 

>  another difference is that with 
> non-routable globals the app can allow the network to do all 
> of the routing and enforce policy 
> about who can connect to whom - with SLs the app will often 
> have to do routing as site boundaries will not always 
> coincide with boundaries of the application, and therefore 
> any policy about who can talk to whom can
> only be implemented in the app.  

This is more an argument for PI than it is against SL. First, routing
across a site boundary can't happen if the address space is ambiguous,
because the routing protocols don't know how to deal with that. So you
are either talking about nat, or a coordinated address space with a
boundary router keeping the IGPs separated (a layer 3 area if you will).
We won't waste time with the former, and the later does not exibit the
application ambiguity problems you are worried about.

>  the ability of the network 
> to provide

Let's stick to technical arguments...

> I've already explained why that 'threat' isn't a problem.

Yet most enterprise network managers still believe it is.

> ...
> we agree that a PI space is needed.  now if we could just 
> discourage use of SLs so that such apps would be able to run 
> in most networks...

Shipping code will do more to change behavior than a few lines of text
in an RFC. 

> > that it is the best we can do today in practice, but that 
> is reality 
> > so let's move on.
> 
> as it is obvious that SLs present many difficulties on many 
> levels of the stack, we really should declare consensus that 
> they should be discouraged except in cases where we know they 
> won't cause problems - like isolated networks - and move on.

This refuses to accept the fact that Rich says they are using them on a
connected network without problems. 

> ...
> nobody is trying to 'prevent' the network manager from doing 
> anything - but we would do well to provide such managers with 
> the benefit of our understanding that SLs are not as good an 
> idea as was originaly thought.
> 

For the kinds of apps you are interested in, yes PI is where we need to
be headed. I doubt we will ever convince people that it is better for
some things that SL will get used for.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 17:36:41 -0500

> One address per interface doesn't solve all known problems either. 

I didn't say it did, nor did I advocate that.

(and there are so many things implied by "one address per interface"
that it would take weeks to hammer out all of the details about
which things you were trying to imply by that and which things 
you weren't.  since it's not what either of us are advocating,
let's just not go there)

> to impose its needs on the public registries.

no, I'm arguing that there aren't well-defined bounds on "the industry"
(for any industry), so there are always potential collisions when you
want to hook up some business that hasn't previously coordinated its
use of SLs.  and once you have the burden of getting an address block
from such a registry you might as well use a global address space 
registry that prevents any potential collisions.

> connect'? If the space is coordinated, it is unambiguous. 

you're assuming that IP connection boundaries are the same
as app connection boundaries.  they aren't.  even if there are
networks that coordinate use of SL space, there will still be
apps that are expected to communicate across distinct 'sites'.

(actually I prefer 'addressing realms' - 'sites' sounds too tied
to geography.   maybe we could call it realm-local addressing?)

> because the routing protocols don't know how to deal with that. 

no, it just means that with SLs the apps have to do the routing 
between realms (and define their own addressing, and implement
their own policy for where traffic can be routed) instead of 
having the network do that for them.

> So you

neither of the above.

> Let's stick to technical arguments...

I just gave you one. 

> Yet most enterprise network managers still believe it is.

beliefs and reality are different, it's true.  but it's best to
think of them separately.  'beliefs' can often be changed through
education.
 
> Shipping code will do more to change behavior than a few lines of text

we could certainly ship code in both hosts and routers to discourage 
use of SLs, but somehow I don't think that's what you're suggesting...

however host and router code implementors do read RFCs and sometimes
they even do what they say.   so having text in an RFC about how to
deal with SLs really might have a useful effect.

> connected network without problems. 

a network that only has one site and that primarily runs only one
vendor's software doesn't exactly strike me as a good test case.

> some things that SL will get used for.

well there are probably 'some' things for which SL really is a good idea.
so far I haven't found many.

and it would be really unfortunate if through misunderstanding SLs were
given wider deployment than they deserve.

Keith