Subject: RE: Architectural Considerations section in specs

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 08:01:51 -0700

Dave Crocker wrote:
> Folks,
> 
> DS> I am saddened by the fact that Tony's simple question 
> could not be 
> DS> addressed. Site local addressing in IPv6 is a concept 
> which has been 
> DS> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed 
> DS> Standards. This is a string of documents dating back to 1995. For 
> DS> eight years this concept was apparently considered a good thing.
> 
> The problem appears to have been that no one bothered to draw 
> the necessary implications and circulate them for explicit 
> consideration. So folks scanned a spec, didn't see anything 
> that looked egregious, and only now are realizing how 
> extensive the impact is.

What they are missing is that a defined prefix doesn't create the
problem that they are complaining about. Limiting the usable scope of
addresses is an operations decision. The mismatch between the
operational reality of limited scope addresses and the app developer
fantasy that there is a single flat routing space is the core problem
here.

Defining a prefix for those only made it *possible* for apps to
recognize which ones might be restricted. It does not *make* apps deal
with the problem of leaking addresses outside their scope of relevance
(unless you take the viewpoint that end users actually expect
applications to work right, and will require it once it is possible).
Applications are not required to understand topology, unless and until
they insist on passing around topology specific information. If any
process is going to pass around topology specific information, it MUST
understand the topology it is describing. 

There is no magic here, and defining a prefix didn't change the
architecture. Operational decisions established the architecture, and it
is our job to define the technologies that work within that
architectural reality. We can choose to continue to declare a
'flat-earth' and insist that applications and name resolution
infrastructure are free to arbitrarily pass around topology specific
objects, or we can choose to recognize the reality of the deployed
network and build the technologies that allow applications to operate
correctly within it. 

Tony

--------------------------------------------------------------------
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: Wed, 23 Apr 2003 17:59:37 -0400

> addresses is an operations decision. 

Tony, this discussion is about ambiguous addresses.  Your persistent
attempt to conflate it with packet filtering and/or routing policy isn't
shedding any light on the argument.  And you're smart enough to know
the difference.

> recognize which ones might be restricted.

But it doesn't help apps know *how* those addresses are restricted.

>  It does not *make* apps deal

Experience indicates that this is exactly what happens.  You cannot
expect apps to not leak addresses outside of their scope because apps do
need to pass addresses around and they have no way of being aware of
their scope boundaries.  The way to solve this problem is to make
addresses unique.

> they insist on passing around topology specific information. 

Another attempt at disinformation on your part.  The fact that the
current internet architecture doesn't provide us with reliable endpoint
identifiers that are independent of topology information is not a
justification for asserting that applications should not pass around the
best endpoint identifiers that are available to them.  And very few
applications use these as anything other than opaque tokens.

> architecture. 

defining a prefix didn't change the architecture - asserting that the
same prefix could be reused in multiple locations did change the
architecture.

> Operational decisions established the architecture, and
> it is our job to define the technologies that work within that
> architectural reality.

indeed.  this is precisely why we are deprecating site locals - because
they do not work within the architectural reality.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 15:47:37 -0700

Keith Moore wrote:
> Tony, this discussion is about ambiguous addresses.  Your 
> persistent attempt to conflate it with packet filtering 
> and/or routing policy isn't shedding any light on the 
> argument.  And you're smart enough to know the difference.

Yes, but you keep changing the argument. On 4/18 it was:
>> introduction of scoped addresses causes far more problems than it
solves.

Today it is ambiguity. I was trying to separate the discussion by
focusing explicitly on the scoped address issue. 

> But it doesn't help apps know *how* those addresses are restricted.

No, but a limited hint is useful in many situations. Should we have
better tools? By all means. That does not mean we get rid of something
that has some utility before we show that it has none because there are
alternatives.

> Experience indicates that this is exactly what happens.  You 
> cannot expect apps to not leak addresses outside of their 
> scope because apps do need to pass addresses around and they 
> have no way of being aware of their scope boundaries.  The 
> way to solve this problem is to make addresses unique.

I do not buy the assertion that 'apps need to pass addresses around'. It
is possible for apps to choose passing around names and let the topology
get sorted out by the name resolution infrastructure. As I said to JCK,
you can't have it both ways. You can either choose to keep it all below
the app layer by passing around names, or if the app chooses to reach
down and get topology information it has bought into the responsibility
to understand what it is doing.

> Another attempt at disinformation on your part.  The fact 
> that the current internet architecture doesn't provide us 
> with reliable endpoint identifiers that are independent of 
> topology information is not a justification for asserting 
> that applications should not pass around the best endpoint 
> identifiers that are available to them.  And very few 

You insist on the right to reach down and get lower layer information,
but refuse to accept the responsibility that goes along with having it.
??? If the app chose to use a name as the endpoint identifier, it would
have the conflict.

> defining a prefix didn't change the architecture - asserting 
> that the same prefix could be reused in multiple locations 
> did change the architecture.

This is more an argument to define ways to disambiguate the current
space than it is to remove a well-known prefix for use in local scopes.
Get your arguments straight, and you will realize all this deprecate SL
nonsense is a waste of time. We need to solve the fact that apps refuse
to acknowledge they are ignoring topological reality, and the ambiguity
argument become simply a matter of subnet routing collisions during
mergers.

> indeed.  this is precisely why we are deprecating site locals 
> - because they do not work within the architectural reality.

No, the apps that insist on reaching down and getting lower layer
information that they don't understand is what doesn't work. Deprecating
SL makes absolutely no difference to this, because the same issues will
crop up for globally unique local scope addresses. Before you say it,
the 'connect to the wrong node' argument is an IPv4 artifact. With IPv6
auto-conf, or even manual conf using a discarded MAC, the probability of
a SL address actually pointing to two nodes is close to zero, and even
lower than that for those both being reachable from participants in the
same multi-party app. 

Go back through all your arguments about the evil's of SL, and see how
many go away if the prefix is disambiguated. Then look at the fact that
A can't tell C the difference between Bl & Bg unless there is some
indicator. 

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 18:08:27 -0500

Thus spake "Keith Moore" <[email-masked]>
> shedding any light on the argument.  And you're smart enough to know

And you're conflating ambiguous addressing with scoping.

> You cannot expect apps to not leak addresses outside of their scope
> because apps do need to pass addresses around and they have no
> way of being aware of their scope boundaries.  The way to solve this
> problem is to make addresses unique.

Give everyone global addresses and the scoping problem remains unchanged.
Even "global" addresses are scoped by administrative or security policies.

Having a prefix set aside for private addresses, whether SL or RFC1918, is
convenient for humans, that's all.  It may make scoping easier or more
common, but it's not the cause.

> same prefix could be reused in multiple locations did change the

Perhaps.  There is no functional difference unless multiple instances of the
same address are actually _reachable_ by a third party; the mere existence
of duplicates does not change the architecture.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 19:34:13 -0400

> > attempt to conflate it with packet filtering and/or routing policy
> > isn't shedding any light on the argument.  And you're smart enough
> > to know the difference.
> 

nope.  the property that I'm concerned about is not that an address
may only be usable within a particular portion of the network, it's
that the address is ambiguous.  so given an address there's no way to
know whether or not it is valid, or why it doesn't seem to work to let
you connect with the host/peer/server you think it's associated with.

> > defining a prefix didn't change the architecture - asserting that
> > the same prefix could be reused in multiple locations did change the
> > architecture.
> 
> Perhaps.  There is no functional difference unless multiple instances
> of the same address are actually _reachable_ by a third party; the
> mere existence of duplicates does not change the architecture.

wrong.  it's useful to have unique names for hosts (or points on the
network) even if they're not directly reachable by everyone who might
possess those names.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 19:59:00 -0400

> that has some utility before we show that it has none because there
> are alternatives.

it's not as if all of the utility for scoped addresses is positive.  it
does make sense to get rid of things with significant negative utility,
particularly when the supposed positive utility is not compelling.

site-local is not useful as a limited hint that the addresses are
restricted, because the scope of such restrictions is still invisible to
apps, and because there is no policy for use of site-local by apps which
will work reliably across different network setups. and any measures
that apps might undertake to work in the presence of site-locals will
work even better (more efficiently and more reliably) if globals are
used.

> I do not buy the assertion that 'apps need to pass addresses around'.

you're simply mistaken about that.  until we have reliable, universal, 
distinguished names for (possibly virtual) hosts that can be used as
endpoints in TCP and UDP, etc., and as long as there is ever a need
to unambiguously refer to a network location, we're going to need to
pass addresses around.

> It is possible for apps to choose passing around names and let the
> topology get sorted out by the name resolution infrastructure.

not in any naming system that we have today, or are likely to have
deployed within ten years.

> As I said to JCK, you can't have it both ways. You can either choose
> to keep it all below the app layer by passing around names, or if the
> app chooses to reach down and get topology information it has bought
> into the responsibility to understand what it is doing.

not if the app treats the addresses as opaque tokens. 

> but refuse to accept the responsibility that goes along with having
> it.???

overloading of IP addresses to be multiple things (among them endpoint
identifiers, interface identifiers, network locations, host
identifiers, even authentication principals) is deeply embedded in the
IP architecture.  you may think it's a poor compromise, and lots of
people would agree with you.  but nobody has demonstrated a
complete solution that appears to be a better way for things to work. 
and given this deliberate overloading, it's disingenous for you to claim
that addresses are inherently lower layer information (more correctly,
they're shared between layers), and that apps that use addresses as
opaque tokens somehow have some new responsibility for dealing with
ambiguity that you've decided to burden them with.

> space than it is to remove a well-known prefix for use in local

I don't believe there is a good way to disambigate the current SL space;
there simply aren't enough bits available.  Nor do I believe (for
reasons cited elsewhere) that it is desirable to burden hosts and apps
with having to deal with more addresses than are necessary to name the
network locations to which they are attached, nor to embed information
about reachability within addresses, nor to expect hosts and/or apps to
select the "right" set of addresses to get from point A to point B.  

so there are indeed other problems with site local even if you make them
globally unique; it's just that lack of uniqueness is the worst problem.

> information that they don't understand is what doesn't work.

wrong.  if they tried to treat those identifiers as anything other than
opaque tokens, I might agree with you.  but very few apps do that, and
I'm not worried about those that do.  indeed, it's the expectation that
apps need to start treating addresses as other than opaque tokens, for
instance by having to use different addresses in different situations
in order to reach the same point on the network, that I'm arguing
against.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 20:41:42 -0500

> that the address is ambiguous.

As Mr. Hain pointed out, last week your argument was about scoping and apps
picking addresses, not about private addresses.

> so given an address there's no way to know whether or not it is valid,
> or why it doesn't seem to work to let you connect with the
> host/peer/server you think it's associated with.

You have no way of knowing if any address is reachable from any particular
location.  That is not a property specific to private addresses.

> network) even if they're not directly reachable by everyone who might

Useful, yes; a fundamental part of the architecture, no.

Removing private addresses from the IPv6 architecture is a fundamental
change from IPv4: site-locals are not a new addition, just a different name.

If site-locals are deprecated, the NAT/stable address/whatever crowd will
just pick a different prefix to use.  Worst case, they'll all pick different
ones.  RFC1597 didn't cause the scoped-address mess; it just provided a
reasonably safe sandbox and standard semantics.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 22:12:35 -0400

> As Mr. Hain pointed out, last week your argument was about scoping and
> apps picking addresses, not about private addresses.

indeed, there are several arguments.  ambiguity is the biggest problem,
but there are others.  nor are they independent of one another - the
problems interrlate.  having ambiguous addresses makes the address
selection problem more difficult, but the need to employ address
selection is a problem even if all addresses are global. also, when I've
been using the word "scoping" I've been talking about the scope in
which an address is defined (has a well-defined meaning) rather than the
scope in which an address could be used- I argue that we need globally
scoped addresses even if they can only be used within a limited portion
of the network.

> > so given an address there's no way to know whether or not it is
> > valid, or why it doesn't seem to work to let you connect with the
> You have no way of knowing if any address is reachable from any
> particular location.  That is not a property specific to private
> addresses.

they're different.  if you have a globally scoped address you can
try to send to it, and the network will make a best effort to get it
there, modulo policy.  if it doesn't know how to get the packet there,
and the network "should" send an ICMP that explains the reason it can't
get there.  and that address will reach the same location/host from any
point in the network. 

if you have an ambiguous address you can try to send to it, but the
network can't tell where it's intended to go.  to the extent that the
network tries to route it somewhere, it may not end up at the
location/host the sender intended, and there's no way for anyone to know
that the packet is being misrouted.  if an error is returned it is
pretty much useless - either the host is down or the network interpreted
the address in a different scope that was intended or the sending host
picked the wrong interface.

note that if you had a globally unique address that only works within a
limited scope, it acts like any other globally scoped address.

> > > Perhaps.  There is no functional difference unless multiple
> > > instances of the same address are actually _reachable_ by a third
> > > party; the mere existence of duplicates does not change the
> > > architecture.
> >
> > network) even if they're not directly reachable by everyone who
> > might possess those names.
> 

disagree.  the internet protocol fundamentally depends on addresses
being global - routing between arbitrarily connected IP networks cannot
work without this property.  furthermore there are several deep
assumptions that IP addresses are uniquely assigned to hosts - for
instance, IP addresses are used as TCP endpoint identifiers, and
round-trip estimates are made on a per-host basis.

> change from IPv4: site-locals are not a new addition, just a different

False.  IPv4 only had private addresses for use in isolated networks,
and this was a late addition, and we've learned from experience that
this was a mistake.

> If site-locals are deprecated, the NAT/stable address/whatever crowd
> will just pick a different prefix to use. 

and the boogey man will come, and we'll all be attacked by terrorists
flying cessna 172s.  sorry, but I'm sort of fed up with living in a
country that does its best to control its citizens through irrational
and ungrounded fear, all the while pretending that it's good for you and
ignoring the real problems that exist.  I've got a pretty low tolerance
for such tactics these days.

yes, we have to give people good ways to solve real problems that they
have.  no, we don't have to legitimize every bad idea that people have
put into practice merely because somebody is doing it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 14:07:34 -0400

> However,  because   of  communications  policy   restrictions, 
> neither  the application  layer nor  the network  layer can  know
> whether  B  is actually allowed to  talk to C.   So it seems  that
> these applications can  only work when  deployed  within  a  policy 
> domain.  

one question here is whether there is some burden on applications to
try to find a path between hosts B and C, say by address and/or
interface selection, or whether the burden is entirely on the network. 

one of the problems with our current notion of 'policy domains' is that
they are so inflexible as a security mechanism that people demand, out
of necessity, that some applications be able to work across them.  

so no, it's not reasonable to assume that apps that do referrals are
only expected to work within a single policy domain.

>  The fact that  A gives B an address of C  rather than
> a name of  C  doesn't seem  relevant  at  all; after  all,  names 
> just resolve  to addresses;  I think the  name vs.  address issue  is
> a  red herring  in this context. 

that's because you haven't had to deal with DNS unreliability,
imprecision, inconsistency, and performance issues.

> 2. A system  with a site-local address is likely to  have other
> addresses as
>    well, and it is  a bad thing for a system to  have more than one
>    address, because the apps have no way of knowing which address is
>    the right one to distribute. 
> 
>    I think the reply to this is  that this horse escaped from the barn
>    about 20 years  ago

not in a general sense.  even today, the vast majority of IPv4 hosts
have a distinguished IP address that is usable from everywhere that's
supposed to be able to talk to the host.

> , and  anyway, choice of  address is a 
>    management function. That  is, the app  needs to  be told  through
>    some  sort of  config which addresses to use when.

which is a management nightmare.

> It's been claimed that if non-ambiguous addresses are used, at least
> the app can tell when  communication is being prevented due  to policy
> restrictions, as it  will receive ICMP  messages with appropriate 
> diagnostic information. Unfortunately, this  presumes more from  the
> network layer than  the network layer actually  provides.  ICMP
> messages  may be generated due  to transient problems, they may  fail
> to be generated at all  (for "security reasons", or due to limitations
> on the rate  of ICMP generation), they may be dropped in the network, 
> etc.  When communication fails,  there is no  reliable way for the
> endsystems to determine why it has failed. 

no, but when the connection times out right after the host has
received 3 or 4 "prohibited" ICMP messages in response to traffic sent
on that connection, it's a pretty good clue.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 12:55:25 -0700

Eric Rosen wrote:
> ... The fact that  A gives B an address of C  
> rather than a name of  C  doesn't seem  relevant  at  all; 
> after  all,  names  just resolve  to addresses;  I think the  
> name vs.  address issue  is a  red herring  in this context. 

If A gave the entire list of choices to B, you would be right. The
problem is that A will generally give B the one it chose, since it
believes that one works. 

> 
> The existence of policy domains seems to restrict the 
> applicability of these multi-party referring applications, 
> especially as  the app itself has no way of knowing whether 
> it is crossing policy domain boundaries.  

This is right in the general case. We have toyed with the idea of
preventing mixed  scope connections which would allow the app to clearly
know. 

> 
> So  what does  this  have to  do  with site-local  addresses? 
>   I think  two
> arguments have been made.
> 
> 1. Because site-local  addresses are  ambiguous, if  A passes 
>  a site-local
>    address to B, B may not be able to use it to talk to C. 
> 
>    I  think the reply  that has  been made  to this  is that  
> the site-local
>    addresses have to  be unambiguous within a particular  
> policy domain, and
>    it is a  management function to ensure that this is  the 
> case.  Since the
>    apps in  questions are applicable only  within a policy  
> domain, the fact
>    that the  addresses are ambiguous  outside that domain 
> doesn't  makes the
>    apps any less useful than they already are. 

This is right on. 

> 
> 2. A system  with a site-local address is likely to  have 
> other addresses as
>    well, and it is  a bad thing for a system to  have more 
> than one address,
>    because the apps have no way of knowing which address is 
> the right one to
>    distribute. 
> 
>    I think the reply to this is  that this horse escaped from 
> the barn about
>    20 years  ago, and  anyway, choice of  address is a  
> management function.
>    That  is, the app  needs to  be told  through some  sort 
> of  config which
>    addresses to use when.

The intent of the sending rules is to provide the default version of
that config. There are arguments that those don't work for the mobile
node case, but I would argue that the mobile node has to know when it is
away from home to inform its HA, so we could add a rule that MNs don't
use local scope addresses when away from home. 

> 
> It's been claimed that if non-ambiguous addresses are used, 
> at least the app can tell when  communication is being 
> prevented due  to policy restrictions, as it  will receive 
> ICMP  messages with appropriate  diagnostic information. 
> Unfortunately, this  presumes more from  the network layer 
> than  the network layer actually  provides.  ICMP messages  
> may be generated due  to transient problems, they may  fail 
> to be generated at all  (for "security reasons", or due to 
> limitations on the rate  of ICMP generation), they may be 
> dropped in the network,  etc.  When communication fails,  
> there is no  reliable way for the endsystems to determine why 
> it has failed. 

In addition, it doesn't solve the issue that A will pass B the address
that it is using, rather than the possible set. B needs to derive its
own view of how to reach C even when globally unique addresses are used.

> 
> So I  don't really  think the  case against site-locals  has 
> been  made here (which is  not to say that  there isn't a  
> case against them based  on other considerations). 
> 
> I think the  underlying problem is that our  comms 
> architecture doesn't take the policy restrictions  into 
> account at all, and folks  tend to assume that this needs  to 
> be accounted for  at some other  layer than the one  they are 
> most interested in.  This generates  frustration, and creates 
> a high heat to
> light ratio.   Usually everyone blames  it on NAT,  so it's 
> nice to  see the
> same issue come up in an IPv6 non-NAT context. 
> 

I am not trying to place blame, but I would word it differently. While
the architecture has all along allowed for differentiating policy
restrictions, the app community chose to simplify their effort by
ignoring that there were policy differences in the lower layers. This
worked as long as the world was dominated by client/server oriented 2
party apps. In a world of multi-party apps, the policy differences of
the lower layers are exposed and we need to rethink how apps deal with
that reality. 

Tony

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Apr 2003 14:04:54 -0700

Tony Hain wrote:
> I am not trying to place blame, but I would word it differently. 

Not to contradict you, but...

> While the architecture has all along allowed for differentiating policy
> ignoring that there were policy differences in the lower layers. 

Nobody ignored anything.  To start with, the application community has 
had to work around these sorts of problems.  This is why there are SIP 
proxy gateways, STUN services, and MX gateways.  All of these exist due 
to connectivity limitations (either intentional or architectural).  All 
of these cases fall under the "Got Lemons?  make lemonade" approach.  So 
I believe you've mischaracterised the community.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 17:10:12 -0400

> problem is that A will generally give B the one it chose, since it

there are multiple problems.

one problem is when the network expects different hosts to choose
different addresses in order to reach the same destination.

another problem is that even if A passes a list of choices to B,
neither A nor B typically has any idea about which choices will
work for B, or for any third intermediary that B passes the list to.

(no, it's not the case that A will "generally" give be the address it chose,
because there's too much variation in behavior between distributed apps. 
often A has no need to choose from that set of addresses at all; it's just
trying to provide some referral service.)

another problem is that being able to pass a list of addresses is not the same
thing as being able to fail over from one address to another, and yet people
want to treat the existence of multiple addresses on a host as a substitute
for multihoming.

> > I think the  underlying problem is that our  comms architecture doesn't
> > take the policy restrictions  into account at all, and folks tend to
> > assume that this needs  to be accounted for  at some other layer than the
> > one  they are most interested in.  This generates  frustration, and
> > creates a high heat to light ratio.   Usually everyone blames it on NAT, 
> > so it's nice to see the same issue come up in an IPv6 non-NAT context. 
> 
> 

another false statement.  apps have been expected to deal with crude and
inflexible policy implementation in lower layers for many years, so apps
people are painfully aware that such differences exist.  what some of us are
saying is that the lack of flexibility in these mechanisms has increased
complexity in both apps and the network without providing much in the way of
useful policy control or security, and we need to reconsider some of the
cruder mechanisms like private addressing.  or in other words - don't create a
mess at layer 2 or 3 and expect layer 7 to sort it out.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:01:02 -0700

> I believe you've mischaracterised the community.

Those are all examples of building complexity into the infrastructure so
that the app can maintain the fantasy that the world is flat. Personally
I would rather see the Lemons turned into a nice desert than squeezed
and watered down.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 18:11:27 -0400

> that the app can maintain the fantasy that the world is flat. 

maybe instead it's your fantasy that it's reasonable to expect apps to cope
with routing.

---

From: Robert Elz <[email-masked]>
Date: Sun, 27 Apr 2003 19:40:13 +0700

Date:        Wed, 23 Apr 2003 19:34:13 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

[ietf list deleted, there's been way too much of this discussion there
already].

  | the property that I'm concerned about is not that an address
  | may only be usable within a particular portion of the network, it's
  | that the address is ambiguous.

We have had ambiguous addresses since forever.   Site locals don't
cause that, they merely make it more obvious - that is, your application
can trivially avoid using it if it wants to.

Think back, way before IPv4 addresses became scarce, and remember all the
sites that numbered their network using the 192.9.200 block.   Aside from
ignorance (which we have no good reason to believe has gone away anyway)
people did that because they wanted an address immediately: "I'm just
setting up this network, and I see I have to tell it an address to use,
and no, I am not waiting until tomorrow, or even an hour, until someone
tells me what to use."

Assuming that I don't care about global routing (right now anyway), an
address (prefix) is just a number, any number will work, so I will simply
pick the first number that comes to hand - and something that is printed
as an example in some documentation is an easy choice, and I'll just
use that.   So will many others.

Later I'll connect, but unless there's some very good reason to do so,
I'll just add the global prefix my ISP tells me to use, and keep the
one I invented for myself.

Ambiguous addresses - and no way at all for the app to tell, so no way
to possibly make things work.   Of course, "that's the network's problem,
not the applications", right?   Nonsense.   Finger pointing doesn't
help, we know this is going to happen.   When you can foresee something,
and deliberately ignore it, and harm results, you get the blame, and
rightly.

One use of site local addresses is to be that well known ambiguous address.
One that anyone can simply take and use.

Personally, I'd prefer unique addresses - and sticking a unique number in
the upper 32 of the "spare" 38 bits (or something like that) in SL
addresses would be just fine.   Unique SL addresses, or the NUSLA proposal
from a couple of years ago, are just fine - they're still SL addressesm
unique or not.

But for that to have a hope of working, that unique number has to be
available, instantly, at no cost, anytime, from anywhere (even the cost
of a phone call is too much, not the $0.25 so much, but the time it takes
to discover the number, get to someone at the other end who can help, ...)

If the allocation method doesn't meet those criteria, people will ignore it.
The only method I know of which works is "well known prefix" (onto which
a random number can be appended if you like).  Know another?

  | so given an address there's no way to
  | know whether or not it is valid,

If you're concerned, and it might not be valid, and you have a choice,
then just don't use it.   What's so hard about that, aside from the "might
not be valid" test sometimes.   If the doubtful address is site-local, even
that is easy.

Of course, if there is no other address (no other address type), then you
have no choice - and it either works or doesn't.

  | wrong.  it's useful to have unique names for hosts (or points on the
  | network) even if they're not directly reachable by everyone who might
  | possess those names.

Well, if you believe other stuff that this WG won't let go of, then if
even a SL address has the 'u' bit set, it is of global scope, and so
perfectly useful as a unique name, if that's all you require of it.
Even a LL address (even more likely to have 'u' set) would do for this.

But wanting a unique name (which isn't a name, but an address anyway)
is no argument for doing away with SLs, even assuming that they're not
unique, one way or another.   It is an argument for all hosts having
global addresses, which is just fine - that's how I'd like it to be as
much as possible.   But having a global addr is no reason for not also
having a SL addr.

kre