Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: "Michel Py" <[email-masked]>
Date: Wed, 26 Jun 2002 17:16:03 -0700

>> Michel Py wrote:
>> It is a terrible responsibility to embed everyone-gets-one
>> PI-address in the addressing architecture. 

> Keith Moore wrote:
> why do you think it's not an equally terrible responsible
> to say "nobody gets a global address prefix unless it's
> tied to a provider"?

I don't. What part of my postings makes you think so? Tony and I are
proposing schemes that are aggregatable and that are not tied to a
provider.

> what makes you think that the policy groups are better
> qualified than we are to make such a decision? we have enough
> trouble understanding the various technical implications (at
> all protocol layers and above) of such a decision - the policy
> groups are even less knowledgable.

The policy groups have to deal with user pressure. Instead of
questioning their competence, I prefer the path of providing them with a
solution that gives them other options than desperate measures.

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: Robert Elz <[email-masked]>
Date: Thu, 27 Jun 2002 12:59:06 +0700

Date:        Wed, 26 Jun 2002 17:16:03 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Tony and I are
  | proposing schemes that are aggregatable and that are not tied to a
  | provider.

Unfortunately, they have just as many drawbacks - just different ones
(in some cases).

Both those schemes are geographic based addresses - these aggregate if and
only if one assumes that areas that are geographically close are also
topologically close.   I have seen no evidence that there's any truth in
this at all.

They're provider independent only of there are multiple providers that
have agreed to cooperate with each other and share the prefix (essentially
routing packets to each other when they arrive at the "wrong" place).
While that is entirely possible to assume might happen in some high
density usage parts of the world, where multiple providers can all exist
and make a profit, in much of the world, the simply aren't enough active
users to support the infrastructure for multiple providers.

Anyone would always be free to connect to a different provider, by simply
connecting to a more distant location of course - but then their address
would not (could not if any aggregation at all is to be achieved) be based
upon their geography, but the provider's instead.  That is, to change
providers an address change is likely to be required for many (perhaps
most) and for those it isn't, the provider choice will be limited to
those who have managed to join the local provider club.

On the other issue ... anyone can (attempt to) pay any ISP, or set of
ISPs to carry any address.   The rish is certainly no greater of that
happening with a SL address with a site-id embedded, than it is for a
global address allocated by a different provider, or a geographic
address from some other region.

If anything, the risk is less with SL addresses, as they can be clearly
labelled "for local use only", lowering the chances that people will ever
decide they would like to interpret them as global addresses (all of these
things are just numbers, so perceptions, and what the ISPs will agree to
do are all that matters anyway).   Global addresses are expected to be
globally visible, and there's no reason at all to assume that people won't
go to a competitor ISP and say "I will connect to you, and pay you all
these $'s if you will agree to advertise the prefix I have already been
allocated this other way" (and even say to ISPs, "I will connect to you,
and you allocate me an address, but you agree thatonce allocated you can
never reclaim the address, no matter whether I stop paying you or not").

kre

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2002 08:00:28 -0700

Robert Elz wrote:
>  ...

The problem is that the local ISP has every motivation to take the money
with no substantial costs, because those appear at the aggregating
transit providers upstream. While it sounds nice to say we will
legislate against that, reality is that it will happen, so the only
reasonable defense is to provide an alternative that scales.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 11:40:08 -0400

> reasonable defense is to provide an alternative that scales.

Your conclusion doesn't follow.  If upstream providers don't already
have a mechanism to filter out bogus route advertisements, surely it
can be developed - particularly when the bogus prefixes are easily 
identified.

I'd be happy to see a scalable alternative to provider-based addressing,
but that's not a good argument against SLs with site-ids.
--------------------------------------------------------------------
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, 27 Jun 2002 11:12:37 -0700

> but that's not a good argument against SLs with site-ids.

I was not arguing against SLs with site-ids, just that we should not try
in any way to lead people down the path where those site-ids are
perceived to be globally unique. As long as the site-id is a locally
administered value, a network administrator can use them privately in
any way he sees fit, including private connections to other networks
(assuming they can coordinate amongst themselves to avoid collisions).
My primary concern is that we avoid building what amounts to an address
registry of global scope, which ends up maximizes entropy in the routing
system.

Yes we need PI public space, see: draft-hain-ipv6-pi-addr-use-02.txt for
some of the reasons why. The actual mechanism is still to be resolved,
but the fundemental need remains. We also need space that is set aside
for private use, and the SL space does that with the exception that it
tried to legislate that /16-/48 must be 0. If I were building a network,
since FEC0: is defined for local use, I see no reason that I would leave
those bits as 0.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 14:17:45 -0400

> perceived to be globally unique. 

I disagree in the strongest possible terms.  

It's absolutely insane to expect applications (that may spam more
than one site) to have to deal with ambiguous addresses.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2002 12:09:01 -0700

> than one site) to have to deal with ambiguous addresses.

Well any app that is generating 'spam' should be restrained....

You missed the point of what I was saying. Within the context of a
private network of one or more sites, there should be no ambiguity
because the local manager is in control of the proposed site-id bits. If
two or more private networks want to join togther and form a larger
private network, as long as they coordinate the site-id bits, there will
still be no ambiguity. If an application wants to depart from the
confines of a private network, it should not be using private addresses.
We already have PA space for public use, and some activity around PI
space.

Since the scope of a private network is managed by the local
administrator, there is no need make SL space globally unique. I agree
it needs to by unique within a private network.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 15:18:36 -0400

> because the local manager is in control of the proposed site-id bits. 

no, because there is more than one site, and there is more than one
local manager, and given enough private interconnections the chances
of a conflict start to become significant.   

(in other words, it's not reasonable to assume that a private network 
is well-bounded or that it doesn't interconnect with other networks 
that do connect to the public network.  and even if those networks 
don't provide transit to the between the public network and private 
network there may be apps that have to deal with addresses from both
types of networks)

if you have enough bits for the site-id you can make the probability 
of a conflict approach zero *provided* the site bits are randomly 
chosen.   but the easiest way to avoid conflicts is to make the 
site-id globally unique, and there's no good reason to not do so.

now if we really get PI space set up in such a way that any site
can get a unique chunk of PI space whether or not it is connected
to any public network, that would remove the need for unique SL
prefixes, and that would be fine with me.  but while I'm glad 
people are working on proposals to do that, I'm not holding my 
breath waiting for it to happen.  if we end up with both unique 
SL addresses and PI addresses, that's not a horrible thing.

but SL addresses without a site-id just cause more harm than good,
and they really need to be eliminated in favor of unique SL 
addresses, unique PI addresses, or both.  

Keith

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Jun 2002 15:33:26 -0400

Keith,

> site-id globally unique, and there's no good reason to not do so.

Who delegates the globally-unique site-ids?  If the site-ids are
globally unique, how are they any different from global addresses?

Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 15:51:35 -0400

> Who delegates the globally-unique site-ids?  

presumably ICANN or their designees.

> If the site-ids are

they have a different prefix so they can easily be distingiushed
from public addreses.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2002 12:52:25 -0700

Keith Moore wrote:
> is well-bounded

Like it or not, routing protocols actually do require that the
boundaries of a network be well defined.

> or that it doesn't interconnect with other networks
> that do connect to the public network.

As I said, all they have to do is coordinate the space. While it might
be nice if they didn't have to worry about any possibility of
collisions, their private use of space does not justify a public
registry. Even if we created a public registry, who would pay for its
maintenance, and what would be the rules for acquiring a site-id? We
already have public registries struggling with these issues just to keep
a relatively small number of SPs happy. How would that scale up to
handle every possible side-id request, and garbage collection as the
original requestor goes away?

> and even if those networks

Yes there is, and it has everything to do with managing a large global
database, and nothing to do with bit patterns as seen by an app.

> SL addresses and PI addresses, that's not a horrible thing.

The focus of my PI draft has been on multi-homing, but it could be
expanded to cover the case of the globally unique range for a
disconnected set of sites. This is not because I prefer it over making
SL unique from a bit-pattern perspective, but from the operational
perspective a global database for SL can't scale.

> addresses, unique PI addresses, or both.

SL addresses without a globally unique site-id are only a problem if
people expect them to work outside the context of a private network. I
will agree that there is a need for a private address space that spans
multiple sites within a private network, so we do need to remove the
'must be zero' restriction on those bits.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 16:11:27 -0400

> boundaries of a network be well defined.

but not all routers share the same view. 
and in general applications aren't aware of such views at all.

> As I said, all they have to do is coordinate the space. 

this is more difficult than you make it sound.  private networks 
have found it difficult to coordinate IPv4 private address space, 
or even to coordinate the NAT mappings between their addresses 
spaces.  and there's no good reason to require them to do so.

> While it might
> registry. 

the fact that the same apps can interact with peers on both private 
and public IP networks does justify it.  

(though I'd be happy if we can find a way to prefixes unique 
without such a registry.  the best way I can find to do that is 
to allow a prefix to be derived from something like a MAC address 
of a network device - which is fine as long as you always keep 
that network device...  problem is that makes the prefixes 
something like /64.  

but unique prefixes are the essential feature, 
the registry is just an implementaiton mechanism.)

> Even if we created a public registry, who would pay for its

make sure there are plenty of site-ids available.

delegate blocks of site-ids to parties in a good position to make
them available to customers - say router vendors.  let them 
ship one attached to each router, with a bar code label.
allow people to obtain them from other parties (DNS registrars, 
RIRs, etc) as a backup mechanism.

try not to GC the addresses at all.
or if necessary, 'lease' them for long periods of time.

> database, and nothing to do with bit patterns as seen by an app.

where is the large global database of Ethernet MAC addresses?
that system of assigning unique IDs seems to have worked 
reasonably well without an expensive infrastructure.

so I think your concerns about management are unfounded.  

> perspective a global database for SL can't scale.

again I don't have a problem with PI addresses if you can solve the
problems associated with them, but it seems premature to exclude 
globally unique SLs until you'e convinced people you can solve the 
ambiguous address problem in a better way.

and your argument that the global site-id space "can't scale" is so
far unconvincing.

> people expect them to work outside the context of a private network. 

private networks aren't always bounded like you seem to think they are,
and even when the network is bounded as far as routers are concerned, 
an app may have to communicate with peers in several networks.  

Keith

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Jun 2002 16:17:32 -0400

> presumably ICANN or their designees.

This introduces a management headache.  The address registries already
are struggling with managing the global address space.  Adding another
registry will not be beneficial.

> they have a different prefix so they can easily be distingiushed

But with a globally unique site-id, they are globally routable.  What's
the point?  If the site local addresses are used within a private
network, there is no need for a global registry since they won't be
seen in the global Internet.

Brian

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jun 2002 16:27:57 -0400

>globally unique, how are they any different from global addresses?

Exactly.  Perhaps I'm over-abstracting...but it seems to me
like a globally-unique site-id is just another form of a global
address.

I think there are lots of reasons not to make these site-ids globally
unique, if we choose to adopt them.  For instance, how does an
ad hoc, disconnected network get a site-id?  Maybe it doesn't need one.

What about my home?  Do I have to go to my ISP or ICANN to get a
site-local ID for my home?

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 16:43:14 -0400

> registry will not be beneficial.

okay, give the job to someone else who can do it well then.
vendors don't seem to have any trouble assigning a unique serial 
number to each products.  this isn't rocket science.

> But with a globally unique site-id, they are globally routable.  

no, they're *potentially* globally routable, but only if every
network agrees to route them.  which they won't because there
will be too many of them.  so no, they won't be globally routable
in general.  a few may be routable on limited portions of the
public network because they've made special arrangements 
with particular ISPs, but that's between them and their ISPs.

>  If the site local addresses are used within a private

not so, because the private networks and the public internet are
not disjoint. they overlap, and apps on hosts that appear in
multiple networks have to deal with addresses from each of
those networks. 

it's a bit like the problem of a host with multiple interfaces
trying to send traffic to a link-local address.  to which
interface does it send the traffic (in the absence of explicit
information)?   can it use a LL address in a referral to 
peer on a different host?  etc.  you get the same problem with
non-unique SLs that you do with LLs just at a different scale.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 16:48:37 -0400

> like a globally-unique site-id is just another form of a global

of course it's a global address.  but that doesn't mean it's globally
routable.
 
> unique, if we choose to adopt them.  

name one.

> For instance, how does an
> ad hoc, disconnected network get a site-id?  

that's not a reason, that's a problem to be solved.  there is every
reason to believe it can be solved as long as we can get enough 
bits for the site-id.

similarly the routing table concern is a valid concern that has
to be addressed, but in a way the mechanism is its own solution,
since there's no way that ISPs are going to even attempt to route 
every site-specific prefix in existence.    those that try will
quickly lose, thus solving the problem.

> Maybe it doesn't need one.

there's no way to know.  most sites currently using v4 private addresses 
probably didn't realize the mess they were getting themselves into either.

> site-local ID for my home?

why not just get it for free with your cable modem/router/whatever?

Keith

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Jun 2002 16:59:43 -0400

> > unique, if we choose to adopt them.

The cost of administration of the global database.

Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2002 14:02:59 -0700

> spaces.  and there's no good reason to require them to do so.

That is a poor analogy because they really haven't had enough space to
work with. Also, they are the ones motivated to make the interconnect
work, so there is in fact every reason to make them responsible for it
rather than burdening a public resource for private gain.

> the registry is just an implementaiton mechanism.)

and that implementation mechanism is not free.

> make sure there are plenty of site-ids available.

There are only 37 bits to work with, and what is to keep everyone on the
planet from asking for 1000?

> RIRs, etc) as a backup mechanism.

As soon as you introduce the inefficiency of aggregates, the potential
number of sites goes down.

> or if necessary, 'lease' them for long periods of time.

how do you know it is unique if there is no GC, even if it is broken
into multiple database segments?

> reasonably well without an expensive infrastructure.

You pay for it with every device you purchase. Another poor analogy
because if we were running a global ethernet bridged network, there
would in fact need to be a very large database of address to contact
mapping for any hope of operational debugging support. With IPv4 we
reduce that database by aggregating collections of addresses under a
single contact, and that system still struggles to maintain accurate
data.

> and your argument that the global site-id space "can't scale" is so

and your argument that a group of sites can't coordinate is
unconvincing. If we had set aside 32 /8's and it wasn't working, then I
might buy it.

> private networks aren't always bounded like you seem to think

By definition a private network is bounded, just ask the administrator
where the boundaries are. If they don't know where the boundaries of
their network are they are open to much bigger problems than a few apps
not working.

> an app may have to communicate with peers in several networks.

If an app needs to leave the bounds of a private network, it should be
using global addresses. If you are arguing that a multiparty app with
multiple participants on both sides of the site boundary should be able
to pass around both SL & Global as explicit addresses, explain why. The
only reason I see where it might need to is if one of the participants
has only a SL prefix. If that is the case, that node has clearly been
put in a region where access to, and interactions with, nodes in the
global space are administratively intended to not work.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 17:08:50 -0400

> The cost of administration of the global database.

there doesn't need to be a global database.  try again.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Jun 2002 17:15:42 -0400

> there doesn't need to be a global database.  try again.

If there isn't a global administration db:

     1. How do we know a site-id is unique?
     2. How do we know who owns the site-id?

And if you want to use AS numbers, just remember that a 64 bit AS number
will not fit inside 37 bits.
--------------------------------------------------------------------
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, 27 Jun 2002 14:18:49 -0700

> of course it's a global address.  but that doesn't mean it's globally

You have just argued yourself into a corner. If the address the app
chooses is not globally routable, how does it connect? Why would it have
chosen SL over the PA prefix to begin with? Wouldn't it make more sense
to avoid the possibility of being black-holed? You are looking for
addresses that are both locally administered (for the site that is not
attached), and globally routable (for the app to actually connect in any
arbitrary case with nodes outside the private network), but recognizing
those are mutually exclusive. The reason I have gleaned from this thread
is that you don't want the app to have to worry about scope. How can it
avoid worrying about scope if your preferred address mechanism doesn't
go everywhere?

Functionally the scope mechanism provides a much cleaner decision point
for an app than a nebulous expansion of SL to include globally unique
site-ids. Again I have no problem with locally administered site-ids,
because those are routed within the context of the private network so an
app can rely on them. If the app wants to connect outside the scope of
the private network, it really needs to be using a global address, or
have lots more knowledge about current routing policy than anyone will
ever share with an app.

Tony

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Jun 2002 17:19:59 -0400

Tony,

> have lots more knowledge about current routing policy than anyone will

Thank you.  I completely agree.

Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 17:39:29 -0400

> You have just argued yourself into a corner. 

no I haven't.  the addresses are for private interconnection agreements,
not for global routing.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 17:35:21 -0400

> work with. 

I agree the analogy is imperfect for coordination of address spaces.
however they have plenty of latitude regarding the nat mapping tables,
and it's still a major pain to coordinate more than a small number of
sites. 

> Also, they are the ones motivated to make the interconnect

strongly disagree.  even though the use of NATs only directly
affects those who use NATs, their effect is actually much broader -
effectively preventing widespread deployment of any app that
cannot deal with NATs.  

we have evidence that coordination of site-ids doesn't scale well,
and at present the only alternative to having global addresses
for private sites is v6 NAT.

> and that implementation mechanism is not free.

nothing is free, strictly speaking.
if you print a site-id on a label then the label costs a few cents.
 
> planet from asking for 1000?

37 bits might not be enough in which case we'd need a separate 
allocation for globally unique site locals.  but if the normal way
you get a site local is to buy a router, why would anybody need
more site local prefixes than routers? 

> number of sites goes down.

agreed, which is part of why 37 bits might not be quite enough.  

still, allocating 11 bits for vendors would give each vendor 
67 million numbers to assign, and that's assuming that every
vendor got the same size allocation.  or you could have more vendor
IDs and give each one fewer addresses per allocation chunk,
which would use the space more efficiently.  I see no reason
why we shouldn't be able to get at least 2**32 distinct site 
IDs from 37 bits of address space.

> into multiple database segments?

the same way you know that an ethernet address is unique.

> You pay for it with every device you purchase. 

yep, and it's both cheap and transparent.  works beautifully.

> Another poor analogy
> because if we were running a global ethernet bridged network, 

who said anything about running a global ethernet bridged network,
or anything on that scale?  surely you don't expect every private
network in the world to establish a bilateral interconnection
with every other one?  that's what the public network is for.

> unconvincing. If we had set aside 32 /8's and it wasn't working, then I

as I understand it, sheer lack of address space isn't usually the problem
because they're typically not using one-to-one mapping anyway.  

> where the boundaries are. 

tell that to the apps that have to live in multiple networks at once.

> using global addresses. 

then figure out how to give every network in the world a global address.

which it seems is what we're both trying to do, though we have different
ideas of how to go about it.  I don't have any fundamental objection to
PI addresses, but I acknowledge there are problems to be solved, and
I wish you the best in your efforts to solve them.

OTOH you seem to have fundamental objections to globally unique site
prefixes even though you reject the proffered solutions out of hand
without really considering them.  Frankly I think that's counterproductive.

> If you are arguing that a multiparty app with
> to pass around both SL & Global as explicit addresses, explain why. 

no I'm arguing that every network, private or public, should have
globally unique addresses available to it, and every host on such
a network should be capable of using those addresses, so that apps 
don't have to deal with limited-scope or ambiguous addresses at all.

> The

not true, at least not so long as addresses have to be obtained from
an ISP. 

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2002 15:12:21 -0700

Keith Moore wrote:
> but if the normal way

Because routers have interfaces in multiple sites.

> no I haven't.  the addresses are for private interconnection

These arguments are contradictory. If an address isn't globally routed,
the app needs to deal with some addresses having a limited scope. Right
now we have told the app unambiguously that a specific set of addresses
has a limited scope. What you are asking for is that we remove the
explicit scope, and leave it up to dynamic routing policy as to where
the scope boundary is. How does the app learn where the scope boundary
is? At least with the concept of a two-faced DNS, the app has a chance
of knowing that if a SL comes back in the query that the node is
somewhere in the same private net.

I agree no address should ever be ambiguous, but that doesn't require
global uniqueness. The thing that is required is that the address be
unique within the scope of routability. If you expect an app to figure
out that scope, it needs to be through the one piece of information that
the app has about topology, and that is the name-to-address-mapping
process. The resolution of a restricted-scope address requires an exact
match between the administrative boundary of the resolution tool and the
routing boundary. If those don't match there is no hope the app will
work reliably.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Jun 2002 18:44:48 -0400

> Because routers have interfaces in multiple sites.

seems like a stretch for those 'sites' to not have routers themselves
and thus, their own site prefixes.   sure you can make each site
a bridged ethernet, but then you are unlikely to have so many
hosts on any of those ethernets that you can't subnet a single SL
prefix for the whole thing.  

still, the idea isn't to force people to get prefixes or site-ids
from a router vendor, it's to set up some cheap ways of distributing
prefixes so that everyone who needs one probably gets one 
automatically.  there can be other mechanisms for the few that 
don't get enough via this mechanism.

> the app needs to deal with some addresses having a limited scope. 

true enough, but there's still a useful difference between a globally 
unique address with a limited scope, and an ambiguous address.

if the app tries to send to a globally unique SL address with a limited
scope, the message will either get there or it will fail.  if the
message fails it's almost certainly because there is no route to the
destination - in other words, it's completely beyond the ability of 
either the app or the network to fix, everything has fulfilled its
function as well as possible.   also it's likely that the network 
can issue a network unreachable ICMP giving quick feedback to the app.

if the app tries to send to an ambiguous address, like a LL or a
SL without a site-id, and the transmission fails, it could be for 
any reason - the host is on the local net/site but is down, the host 
is on another network/site but there's no way to tell, the app
didn't send the message through the right interface, etc.

part of what I'm discovering is that if you want to make any kind
of address selection algorithm work well, you need to ensure that
IF there is an allowed signal path from source to destination, the 
hosts will (or are very likely to) (a) have addresses assigned to them 
that allow that signal path to be used, and (b) the address selection 
algorithm will choose a addresses that meet those criteria over those
that do not.  in order to meet condition (a) then we need to make
sure that every site has a globally-unique prefix.  in order to meet
condition (b) then we need to make sure that globally routable prefixes 
are chosen in preference to site-specific prefixes.

> unique within the scope of routability.

the app has no good way of knowing about scope - and multi-faced DNS 
just doesn't cut it - DNS really doesn't know more about topology
than any other app, and the DNS server has no control over who caches
its messages.  

but it's not necessary that the app know about scope.  it's only 
necessary that

a) if the app can send a message to a destination, it can easily
   find out which address will work
b) if the app can't send a message to that destination, it can
   find out quickly

at least, I think this is the optimal result given the assumption
that we don't have a completely connected network - i.e. that
there will be some host pairs (A,B) for which A cannot reach B
due to either the lack of a signal path or an administrative prohibition.

none of this really requires that we get rid of limited scope
addresses, just that we always use global address in preference
to LS addresses.  though if we can provide privately-routable provider-
independent addresses then it's hard to see how to justify 
keeping ambiguous SL addresses in the architecture.

Keith

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Jun 2002 15:04:14 +0700

Date:        Thu, 27 Jun 2002 15:12:21 -0700
    From:        "Tony Hain" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I agree no address should ever be ambiguous, but that doesn't require
  | global uniqueness.

This all depends upon the frame of reference for "ambiouous".  You're
agreeing that addresses should be unambiguous from a particular point
of reference.  Keith wants addresses to be unambiguous from any point
of reference - in particular, so an app can send an address from one
node to another, without having to worry about whether it will mean the
same thing when it arrives as it dopes when it was sent.

My take on that is that limited scope addresses simply shouldn't be used
that way - it may be true that using DNS names as a reference to ship
around isn't good enough (personally, I'm not convinced that if it
ever became important they wouldn't be good enough - most of the reported
problems are due to laziness or poor knowledge, which affect anything
when there's no incentive to do better).

But I see no reason not to ship around only known global addresses
(ones expected to be globally reachable), and then allow apps that desire
to use more limited scope addresses to discover the limited scope address
from the global.

Incidentally - this also relates to your comment's on the icmp-name-lookups
draft ...

	It
	also doesn't make any sense to use a mechansim that is clearly getting
	packets to the dst node to ask it for other addresses that might be used
	to get packets to it. THe only possible use I can see would be to allow
	shifting to a different pair for route selection reasons,

Another possible use is to shift to a different pair, of a different scope
(not caring about the routing used in the slightest).   That is, you ask
the global addr to return you the site local addresses.

As long as it is obvious on the face of it what is a global address,
and what is limited scope (which matching fe80::/9 tells us now), having
apps only tell others about global addresses, and never passing off a SL
addr to another app looks real easy to me.

The only requirement is that a global address actually exists to use.

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:10:20 -0400

> that way - 

I could agree with this *if* there were a mechanism to ensure that
sites always had a globally-scoped address available to them -
then we could say that limited-scope addresses should not be used
in referrals.

> it may be true that using DNS names as a reference to ship

it's important *now*, it's just that you don't see the apps for which
it is important.  and the problems are inherent in DNS itself - 
the degree to which it is federated and distributed, that and the names 
don't mean what you think they mean - and in a network that has differences 
in link bandwidths (and delays) ranging several orders of magnitude - 
to say nothing of varying load and packet loss rates. 

> to use more limited scope addresses to discover the limited scope address

the reason to ship around limited-scope adresses in the current environment
is that in some cases they're the only ones available, and in some cases
the limited-scope address might work better than the global-scoped address.
however one could argue that the latter situation is a failure of the network,
or more likely a failure to configure the routing protocols properly.
 
> The only requirement is that a global address actually exists to use.

and that if provided there is a signal path available, then that address 
serves to route the packet to the destination from that source.

Keith

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Jun 2002 21:19:04 +0700

Date:        Fri, 28 Jun 2002 09:10:20 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | I could agree with this *if* there were a mechanism to ensure that
  | sites always had a globally-scoped address available to them -
  | then we could say that limited-scope addresses should not be used
  | in referrals.

Yes, I think we need to think a little more about what we do with
disconnected federations (rather than disconnected sites) and
partially connected federations.

These might be areas where one of the geographic addressing schemes
might prove useful (Tony's perhaps more than the one from the multi-homing
group, as it defines the address that will be allocated to a particular
spot on the planet's surface).

  | it's important *now*, it's just that you don't see the apps for which
  | it is important.

That could be - but if it is important, the DNS can/should be fixed, as:

  | and the problems are inherent in DNS itself -

I don't agree with that at all.   Nothing requires a DNS lookup to take
a long time, the vast majority of them don't.   If one takes a long time,
that indicates a configuration problem of some kind, which can and should
be corrected.  To the degree that isn't happening, the only explanation I
can think of is that people simply don't care enough.

The problem that does exist is that app designers (and app protocol designers)
aren't the ones who get to fix the problems - and rather than simply
insisting that things be fixed for the app to work properly, they're
working around the problem by just not using DNS names.

  | the degree to which it is federated and distributed,

none of that need cause excessive delays.

  | that and the names don't mean what you think they mean

That indicates configuration problems too.

  | - and in a network that has differences 
  | in link bandwidths (and delays) ranging several orders of magnitude - 
  | to say nothing of varying load and packet loss rates.

All that will affect all parts of an app's performance, not just the
DNS part.   If anything, the DNS can overcome those kinds of problems
(I've been doing it for years) by simply making a local replicated copy
any part of the DNS database where normal access causes problems.

But even without that, the DNS isn't (or shouldn't) be causing more
suffering (for its one occasional lookup every now and then before
local caching works) than all of the normal packets that are being
delayed, lost, ...

  | > The only requirement is that a global address actually exists to use.
  | 
  | and that if provided there is a signal path available, then that address 
  | serves to route the packet to the destination from that source.

Oh, yes, of course, that's what I intended to mean.

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 11:38:34 -0400

> be corrected.  

I don't think that's true - at least, I don't know of any way to configure 
DNS so that a client knows to avoid querying zone servers that are 
unreachable due to network congestion or failed links.

Granted, there are many DNS failures for which I've never found an explanation.
But the lack of tracability in DNS means it's hard to track down such things -
e.g. when an app gets a bogus "no such host" indication, who is responsible?

That, and the lack of fate-sharing almost inherently means that an app that 
relies on DNS is less reliable than one that doesn't need DNS.

> To the degree that isn't happening, the only explanation I

or peharps you're not thinking enough? :)

> working around the problem by just not using DNS names.

That's a bit like app designers insisting that NATs go away.  App designers
have to deal with whatever environment their customers have.  It's our job
as architects and engineers to encourage customers to set up reasonable
environments and to give them mechanisms that allow them to do so.

But it's NOT reasonable to insist that everything go through DNS.
DNS is simply too slow and too inherently unreliable to be used for 
all purposes.  The reliability can probably be improved somewhat,
and we should certainly try to do that.  But DNS names will never 
replace IP addresses for use in application referrals.  And if
anything is going to replace IP addresses for such purposes, it needs
to be structured very differently from DNS, both in how translation
is done and in how the mapping information is propagated.

> That indicates configuration problems too.

No, it just means that not everybody shares the same idea as to
how (or when) DNS should be used.

> any part of the DNS database where normal access causes problems.

Expecting ordinary users to do this seems like a stretch

> local caching works) than all of the normal packets that are being

The reason this analysis fails is that the DNS lookups don't necessarily 
share the same links or servers as the ones that are critical to the app.
DNS burdens the app with additional points of failure.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Jun 2002 09:13:27 -0700

> same thing when it arrives as it dopes when it was sent.

and my point was that even if he sends an address that has a globally
consistent meaning, if there is no route why bother? Lets use the
following example:
         |       |
      A -|-- B --|- C
         |       |
      SL | SL&G  | Global

What Keith is asking for is that B should be able to tell C about the SL
for A because A doesn't have a global address. If there is no global
address for A, how will C get packets to it, even if the address it gets
is unique? If the argument is that the network for B could leak the
routes for A into the SP for C;
1) is the site policy for A being violated by advertising it?
2) more likely, is the SP policy for C being violated because A is not
directly attached?
3) how does the app on B know that the route leak has occured and C has
a route to A, particularly since it knows it doesn't have a SL address
for C?
4) how does the app on B know that A has a route to C, particularly
since it knows it doesn't have a global address for A?

This is simply a broken model for an app. Yes it would be nicer for the
app if the boundaries didn't exist, but A is not connected to the public
net for a specific policy reason, and wishing that B could work around
that is simply a waste of time. Global uniqueness in the SL space
doesn't solve any of the above problems. It is more likely to cause
people who don't understand routing to try it & fail, than actually help
make apps work. As long as A & B have an unambiguous SL space between
them, apps that stay in the SL context will work, and it will be clear
to B that A can't possibly participate at the same time as C. If we
confuse the world by making it so that it will *sometimes* be possible
for A to talk to C, we will spend more time explaining why it almost
never works than it was worth for the few cases where it does.

> to use more limited scope addresses to discover the limited

That will fail if one of the sites only has SL's. The result you are
looking for is that an app will not ship around mixed scope addresses.
If B ends up in the above example where it only has a SL for A and only
a global for C, IT SHOULD NOT SEND ADDRESSES, period. If it has a SL for
all the participants, it should use those because the app is more likely
to stay intact if one of the participant sites is changing its public
prefix. Outside of that I agree that if any of the participants doesn't
have a SL, the app should only use globals.

> the global addr to return you the site local addresses.

I agree this could happen, but passing smaller scope addresses in a
larger scope ICMP seems like a bad idea. I don't like the idea of equal
or larger scope addresses being passed, but at least they should be able
to deliver packets. The real problem is that smaller scope addresses
will fail to work more often than not. Again, provide a name and let the
resolution of that name in local context provide meaningful addresses.

> The only requirement is that a global address actually exists to use.

Since this is the problem for the disconnected site, the requirement
needs to be that an app never passes around mixed scope addresses.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 14:14:08 -0400

> consistent meaning, if there is no route why bother? 

if there's no route then it really doesn't matter, because the app
couldn't function anyway.  

> Lets use the
> for A because A doesn't have a global address. 

B has no way of knowing whether or not there is a route from A to C.

But if there *is* a route from A to C, then there needs to be a an
address for A that B can give to C, even if A is not connected to the
public Internet.

> If there is no global
> is unique? 

If A and C have a private interconnection, then the packets can get there.
Not all interconnection is through the public Internet.

> If the argument is that the network for B could leak the

there's no way for the app to know the site policy, so it's a moot question.

> 2) more likely, is the SP policy for C being violated because A is not

also moot, for the same reason.

> a route to A, particularly since it knows it doesn't have a SL address

why do you assume a route leak?  It's entirely possible for A and C 
to have a legitimate signal path between them even if one or neither is
connected to the public internet.

> since it knows it doesn't have a global address for A?

A's SL might or might not be valid for C.  
B doesn't know whether or not A and C are part of the same 'site'. 

> This is simply a broken model for an app. 

well, duh.

> Yes it would be nicer for the
> that is simply a waste of time. 

There's no presumption that B is routing traffic from A to C.  Rather
B is an app that is forced to live in a world where it is trying to
communicate with multiple peers, or maybe even coordinate activities
among multiple peers, where some of its peers are connected to the 
public Internet and some are not.  B cannot be expected to have any 
idea which peers can talk to which other peers, or for that matter,
which peers' addresses are valid in which other peers' addressing realms,
because we've forced apps to deal with ambiguous addresses.

At least if we make it possible for everyone to have unambiguous addresses
then we can plausibly impose the contraint on apps that they should only
use unambiguous addresses in referrals.  B still won't be able to tell
whether A and C can communicate directly, but at least it can give C an
address for A which is unambiguous, and which allows C to *quickly* determine
whether it can talk to A.

> Global uniqueness in the SL space
> doesn't solve any of the above problems. 

forget about SL space for the moment because it's confusing the issue.
if you give A a globally unique address, then C can make some sense of it.
if you force A to have an ambiguous address, then C can't tell whether 
A is unreachable, or whether A's address is simply not valid.

> As long as A & B have an unambiguous SL space between
> to B that A can't possibly participate at the same time as C. 

the notion of "SL context" is a network-centric view.  apps don't have
any idea about such contexts.  apps and hosts have to cope with 
overlapping network contexts and interfaces on multiple networks that 
are in different contexts.   app cannot be expected to stay within some
invisible network context; actually quite often apps are expected to 
work across such boundaries.

> If we

we're already in a world where it is *sometimes* possible for A to talk
to C, and we have been ever since firewalls were invented.  since firewalls
aren't going to go away anytime soon, apps have to deal with the possibility
that traffic is administratively prohibited.  the only questions are whether
we want to impose additional barriers by preventing private networks 
from having unambiguous addresses when they talk to other networks, and 
by making it difficult for apps to determine whether they actually talk
to one another due to the fact that their addresses are ambiguous.

> a global for C, IT SHOULD NOT SEND ADDRESSES, period. 

wrong.  B has no idea whether A's SL address is valid for C.
it might be obvious from looking at the drawing that C cannot use 
the SL address for A, but it's not obvious to B from the information
available to it.

now you could argue that A should never send out an SL address in
a referral.  and if we made it so that it were always possible for 
A to get an unambiguous address (or for A's network to provide A
with an unambiguous address), I'd agree with you.  however in 
the current architecture, such an argument is untenable.

> If it has a SL for
> prefix. 

no.  B doesn't know whether A's SL is valid for C, even if 
both A and C have SL addresses.  They could be from different
realms.

> needs to be that an app never passes around mixed scope addresses.

I don't know what a "mixed scope" address is.  But as long as we expect
hosts to be able to use ambiguous addresses for anything other than
very specific and limited purposes, apps *will* pass them around,
and people *will* expect those apps to work.

The requirement should be that every network can get globally-unique
addresses for each of its hosts, and that it's free to interconnect
using those addresses with any other network that will agree to connect
to it.  That way, every host and app that needs one can get a globally
unique address, and apps can then be discouraged from using ambiguous
addresses.  It doesn't mean that every app can route traffic to
any other potential peer that it knows about, but that's a given.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Jun 2002 12:48:51 -0700

> B has no way of knowing whether or not there is a route from A to C.

In this example B knows the scopes don't match.

> address for A that B can give to C, even if A is not connected to the

This is where we fundamentally disagree. If A is not connected to the
public Internet, there is no 'NEED' for B to be able to tell C about it.
The number of places where by intent a node is disconnected from the
public Internet, yet might be able to interact with nodes on the public
Internet and not in its local routing domain, is so small that it is
both not worth solving, and creates more confusion than solutions.

> there's no way for the app to know the site policy, so it's a

Then why is it passing around addresses?

> A's SL might or might not be valid for C.

This only happens when NAT is involved.

> because we've forced apps to deal with ambiguous addresses.

Globally unique addresses don't solve any of these issues. I agree that
unambiguous addresses in the context of routability is required. In the
example, B knows the scopes don't match, so without route leaking it
knows the two sides can't see each other.

> whether it can talk to A.

The time it takes to determine reachability is the same, and global
uniqueness will not change that.

> A is unreachable, or whether A's address is simply not valid.

and the practical difference is?

> any idea about such contexts.

and rather than figure out how to give them such knowledge you are
arguing to remove the mechanism. There is no requirement that any app
use SL, just as there is no requirement for a network manager to
announce them. If an app wanted to stay within the bounds of the local
routing administration, restricting itself to SL would be the first step
to accomplishing that.

> apps and hosts have to cope with

All of the administratively created boundaries are there explicitly to
prevent apps from working across them. If we remove NAT from the set by
moving to IPv6, we are left with the case where some administrator has
decided that apps should not arbitrarily work, but you are insisting on
making that possible despite the administrator.

> to one another due to the fact that their addresses are ambiguous.

If an address is ambiguous outside its realm of routability, who cares?
Either the routing system has a unique entry for the node, so all the
participants can get there, or the address is outside this realm of
routability, and they wouldn't get there even if the address is unique.

> the SL address for A, but it's not obvious to B from the information

B knows that it only has a global for C and a SL for A, so it can't
refer one to the other with any hope that the connection will actually
work.

> both A and C have SL addresses.  They could be from different

As long as there is no NAT in the path, there is no way that routing
would work if the SL for A, B, & C are from different realms. Assuming
we add the ability for local management of site-ids, if A & C have a
private connection the prefix A tells B would have to be the same as the
one it tells C, or routing within A would fail to deliver the packets.
At the same time, there is no reason that the disconnected sites of Q,
R, & S couldn't use the same set of site-ids.

> I don't know what a "mixed scope" address is.

Not clearly stated... an app should not pass around an address set
unless all the scopes match.

> But as long as we expect
> to it.

That is a nice idea, and if we had a mechanism for PI addresses this
would be possible. Help promote the need for PI, and stop trying to turn
SL into PI. There is a need for both.

> That way, every host and app that needs one can get a globally

There are apps that don't want arbitrary global accessability, and this
requirement would force them to have it anyway.

Tony

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Jun 2002 19:28:30 -0400

> In this example B knows the scopes don't match.

so what?  the fact that A used a limited-scope address to talk to B 
doesn't doesn't tell B anything about whether A and C can communicate
directly.  B knows nothing, absolutely nothing, about the network
connectivity between A and C and there's absolutely no way B can 
make *any* inferences about connectivity by looking at any set
of A's and C's addresses.  furthermore, there's nothing that any 
address selection rule can do to change this situation.

> public Internet, there is no 'NEED' for B to be able to tell C about it.

that's insane.   what you're saying is that we don't need to care about 
whether applications can interoperate if their hosts aren't all connected 
to the public internet.  the bottom line is that people need apps that 
work even when all of their hosts aren't connected to the public internet, 
and  the burden is going to be on apps to make this work whether you
think it's reasonable or not.  our only choice is to decide whether 
we're going to force those apps to be less reliable by burdening them 
with ambiguous addresses.  

> both not worth solving, and creates more confusion than solutions.

try again.  there are lots of private enterprise networks today
that are interconnected by NATs whether or not there is any connection
(via a NAT) to the public Internet, and there are lots of apps that
have to run on spaces where public and private networks overlap -
essentially every enterprise network today has apps that run in an
environment like this.  are you saying you're going to make it as
difficult (or worse) for those apps to use v6 as v4+NAT?  I don't think
that's a viable option.

> Then why is it passing around addresses?

you may as well ask why DNS passes around addresses.  DNS isn't
aware of the policy either, and even though 2-faced DNS attempts
to limit exposure of addresses that aren't usable there's no way
the DNS server can know who gets those addresses and whether
they're authorized to talk to ports on those hosts.  bottom line is 
just because you get an address from DNS or anywhere else doesn't 
mean for certain that you can actually send traffic to it.

> This only happens when NAT is involved.

NO, Tony.  It's possible for A and C to be in different sites, 
even though B can talk to both of them.  It's also possible for
them to be in the same site, even though B has a SL address for
one and a global addres for the other.

> Globally unique addresses don't solve any of these issues. 

globally unique addresses are not a complete solution - there is no
complete solution.  but they minimize the potential for some errors 
and make it easier to quickly detect other conditions that prevent
an address pair from being used, and thus make it easier for 
applications to recover quickly from those conditions.  e.g. it's much
better to get an ICMP unreachable when trying to send to an address
than to have to wait for a timeout.

> I agree that

no it doesn't because B has no way of knowing whether it has *all*
of the addresses for both A and C, and nothing can be inferred from 
the fact that A chose a SL address for B and C chose a global address
for B.  especially when different connections (sometimes even within
the same app) have different needs that quite reasonably affect 
address selection, and when network connectivity can vary from one
time to the next and at different places in the network at the same time.

> uniqueness will not change that.

I don't think so.   with an unambiguous/global address the router knows 
whether or not it has a route to the destination, and can issue an
unreachable ICMP immediately if this is not the case.  with an ambiguous
address there may be a need to do routing (in the case of SL) and ND
for a host that might not even be at that site, and the only indication
that you can't reach that host is an ND timeout, which might or might
not result in an ICMP message being sent back across routers after the 
timeout has expired.  (often we don't get them in IPv4, so I don't 
expect we'll get them in IPv6 either...) 

of course if the destination is down you'll get the timeout in any case,
but we assume that's a rare situation.  the difference is that when trying
to use SLs from a remote network you'll have to wait for a timeout 
anytime you're using a nonlocal SL - and the timeout tells the sender 
*no* information about whether the host is up or down.  how often this 
happens is highly dependent on how your network is interconnected with 
others' and where your apps live relative to that topology.

> and the practical difference is?

response time, overall reliability, and the effort/complexity that apps 
need to expend in trying to deal with multiple addresses, detecting errors, 
and recovering from errors.
 
> arguing to remove the mechanism. 

even asuming you can resonably teach apps about network topology
(going against 20+ years of internet architecture), please explain 
how you are going to teach apps about network topology without giving
them any way to determine which addresses are in which part of the
network.  it simply can't be done.  you can beat your head against
the wall as long as you want, but you won't get anywhere except
a bruised head.  this is what the NAT/RSIP/MIDCOM people have been
trying to do and it's basically accomplished zilch except to serve as 
a demonstration on how utterly fruitless and futile that line of 
investigation is.  

> There is no requirement that any app

an app could restrict itself to SL, or it could restrict itself to 
not using SL.  but users that try to use SL are going to wonder 
why they have to force their apps to live in one world or another.

what this basically means is that SL has very limited utility,
and that we need a mechanism that allows sites to have globally
unique addresses whether or not they're connected to the public
Internet.   And once we have the better mechanism then SL should 
probably be discouraged so that apps don't have the burden of 
dealing with them.  that doesn't mean that we have to try to eradicate
SL from the face of the Earth, but it's certainly not clear why
we should bother to support SL and the complexity that comes with
it if we can solve the same problem via simpler and more reliable means.

> prevent apps from working across them. 

perhaps, but the boundaries aren't as clean as you want to pretend.  the 
fact that B can talk to both A and C does not mean that direct 
communication between A and C is permitted.  nor would the inability
of either A or C to talk to B mean that communicaiton between A and C
were forbidden.   the only way to know if there's a boundary between
A and C is for one of them to try to talk to the other.

> If we remove NAT from the set by

No.  if the administrator doesn't want A and C to talk to each
other then the administrator sets up a filter that blocks traffic
between A and C (it could be either at A or at C or in between).  the 
administrator doesn't necessarily tell B about it, B might not even been
in that administrator's control, and there's no way for B to know that 
such a filter exists from looking at information it has about A and C.

> If an address is ambiguous outside its realm of routability, who cares?

not being on the public internet is not the same thing as "outside the
realm of routability".

> routability, and they wouldn't get there even if the address is unique.

No.  The routing system is not monolithic, routing policy domains
and addressing domains can overlap, and hosts may exist in multiple 
domains or at the intersection of multiple domains.  It's not as if all
of the interconnections between a set of communicating hosts are either 
permitted or forbidden at the same time.

> refer one to the other with any hope that the connection will actually

basically true, but B has no way of knowing whether this will work even
if both A and C have SLs, or if both A and C have globals.  the best
B can do under any circumstances is to say "A, here is the set of 
addresses I have for C" (or "C, here is the set of addresses I
have for A") and let A (or C) sort it out as best it can.  B cannot 
make a reliable decision on A or C's behalf as to whether they can 
connect or, if there are multiple addresses, which address is the one
to use.

> would work if the SL for A, B, & C are from different realms. 

that's simply incorrect.  any of A, B and C can exist in multiple realms,
and B doesn't know which realms A and C (or for that matter B) are in.

> Assuming
> one it tells C, 

so given that multiple prefixes are available to A and C, how are A and C 
going to arrange to choose the same prefix when talking to B?  
don't say that they should use the same address selection algorithm,
after all they may have different needs, or their current network 
connectivity at the time they each started talking to B might have 
been different.

> or routing within A would fail to deliver the packets.

presuming that {Q R S } and {A B C} always stayed disjoint, which is
a difficult condition to enforce.  here's the question - given that
there could well be a good reason for such private networks to merge
(e.g. say that company Q merged with company A) do you really want to 
force NATv6s on them?  or massive renumbering of all of the sites 
involved, even those not involved in the merger?

ambiguous addresses are just a nightmare.

> unless all the scopes match.

that's a truly bizarre idea.   nobody would adhere to such a rule
unless (maybe) we made it easy for all hosts to have global addresses.  
and the rule wouldn't solve the problem anyway.  you're trying to
get apps to enforce arbitrary restrictions on interconnection which
are not dictated by site policies, and which would actually prevent
many kinds of distributed apps from serving their purposes.

what is a proxy, after all, if not an app component that lives in 
the intersection of policy domains that mediates communication
between peers in those various domains?  are you going to say that
proxies can't exist because you're refusing to allow them to 
mediate between apps that choose different addressing scopes?

> SL into PI. There is a need for both.

As I've said before, I'm all for having PI addresses.  I don't personally
care whether SL is the mechanism or there is some other mechanism,
as long as we get PI addresses that sites can use to interconnect
between themselves.  I don't even care if they're aggregatable
(though others might).  

On the other hand, if we have PI addresses, I'm unconvinced of the need
for SLs in that case.  Perhaps someone can cite a use case for SLs
that would not be met by PIs.  Until I see that use case then my
presumption is that we'd be better off with PIs and without SLs.

> requirement would force them to have it anyway.

No.  Nothing stops an app from refusing any connection (or ignoring
any input) it wants to refuse (ignore), and nothing stops a site from 
blocking traffic on any source/dest pair it wants.

Keith