Subject: C000

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Apr 2003 15:31:13 +0200

Let's be constructive and ignore distractions like appeals.
Let's also assume that item (4) ["requirements for a local 
addressing mechanism"] in the chairs' work list is relatively
straightfoward and obvious.

Assume that we consider stable, probably unique,
unrouteable prefixes important enough to get their own 3-bit
prefix, and for the sake of argument let's pick C000::/3.

Further assume that we want to generate /48s.

Then the problem to solve is generating probably unique 45 bit
numbers easily and essentially free of charge. That's clearly possible 
in several ways, so let's not debate details.

Therefore, assume we have a way of generating such prefixes under C000::/3.

What are they going to do to the scoped architecture? Will applications
need to treat them any differently from 2000::/3?

   Brian
--------------------------------------------------------------------
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: Brian Haberman <[email-masked]>
Date: Thu, 10 Apr 2003 09:59:05 -0400

> Therefore, assume we have a way of generating such prefixes under C000::/3.

Assumption made. :)

> 
> What are they going to do to the scoped architecture?

I believe the scoped addr arch will have to contain rules
that specify how the prefixes are delineated.  That is, if
the prefixes don't match, they are in different sites.  The
process doing this comparison will then have to determine what
action is needed for the mis-match (e.g. routing protocols will
not advertise the both prefixes out the same interface).

> Will applications need to treat them any differently from 2000::/3?

I think so.  In the 3rd-party referral case, an app will have to do
the check mentioned above before sending a referral.

Regards,
Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Apr 2003 10:13:11 -0400

>not advertise the both prefixes out the same interface).

Why?  If local addresses are not ambiguous, there is no reason
why "sites" can't overlap (i.e. one interface could be in two
different "sites").  BTW, I think we may want to reconsider the
use of the term "site" -- I'm not sure what term to use
instead, though.

>the check mentioned above before sending a referral.

Or, we need to make sure that apps don't get local addresses
unless they explicitly ask for them.  This could be achieved by
a combination of Mark Andrew's proposal for putting local
addresses in the DNS, and some API changes to only return the
largest scoped address(es) available, unless an app explicitly
asks for addresses with lesser scope.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Thu, 10 Apr 2003 10:27:32 -0400

Margaret Wasserman wrote:
> different "sites").  

I didn't consider overlapping sites in my response.  Of course,
if they are not ambiguous they could be globally routed...

> BTW, I think we may want to reconsider the

Don't know what term would be appropriate.

> asks for addresses with lesser scope.

If we allow overlapping sites and the addresses are near-unique,
the apps may not even care.

I seem to be guessing since there isn't any context around these
addresses to describe their properties.

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Apr 2003 17:12:14 +0200

below...

> addresses to describe their properties.

Indeed, we need to define their properties to meet the requirements,
when we've agreed on them. My point was really to check whether we
still have scoping issues and the answer seems to be yes. However,
I think during the recent debates it was pointed out that many
sites will choose to treat some of their normal (PA) address space
as private, simply by not routing it externally. So the referral
issue will arise there too.

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Apr 2003 11:16:56 -0400

>addresses to describe their properties.

Me, too.

That's why I think we should start by trying to figure out what
our requirements are for local addressing -- or at least what
the problems statement is...

Then, we can try to figure out what type of addressing and/or
other mechanisms can be used to meet those needs with the fewest
limitations, the least complexity and the lowest impact on other
parts of the protocols stack.

I'm not sure where to start, though...

 From my perspective, the primary need is for addresses to use
on disconnected networks.  However, other people have stated
other requirements for local addressing -- addressing for
intermittently connected networks, allowing local connections
to survive global prefix renumbering, local access control,
handling site merges, etc.  People have also offered
constraints -- shouldn't require changes to existing applications,
etc.

I think that these things may need more details added
before we can understand if any (combination of) mechanism(s)
can meet the requirements and stay within the constraints.
In some cases, we may find that there are conflicting
requirements and constraints, and we will need to make
trade-offs.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Apr 2003 11:33:06 -0400

Hi Brian,

>issue will arise there too.

Yes, applications do have to deal with addresses that are
unreachable.  Even if we group the "local" addresses into
a single prefix, applications will still need to handle it
when global address/port combinations are filtered/firewalled.

I'm not sure that it is possible, but I hope that we can come
up with a local addressing scheme that does not require
hosts to include any special handling for local addresses
(at any layer of the protocol stack).

I think that this may be possible using globally unique
local addresses, specifying some DNS enhancements (like
Mark Andrew's proposal, perhaps) that make it possible
for applications/stacks to control when they might receive
local addresses, and relying on the longest match rule
in the address selection rules to generally match local
addresses with local address and globals with globals.
But, I really need to understand the goals better before
I can be sure.

I'm fairly certain that something more complex will be
needed in the intermittently-connected case, but I'm
hoping that we can come up with optional mechanisms for
those type of networks that won't be required for all
implementations.  I also understand that there is some
interesting work going on in this area in the nemo WG,
but I haven't check that out yet.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 11:04:20 -0700

Margaret Wasserman wrote:
> ...
> That's why I think we should start by trying to figure out 
> what our requirements are for local addressing -- or at least 
> what the problems statement is...
> 
> other mechanisms can be used to meet those needs with the 
> fewest limitations, the least complexity and the lowest 
> impact on other parts of the protocols stack.
> 

I offer draft-hain-ipv6-sitelocal-00.txt as a starting point.

> ...
> can meet the requirements and stay within the constraints. In 
> some cases, we may find that there are conflicting 
> requirements and constraints, and we will need to make trade-offs.

The cynical might consider this a 3-year effort that will simply
redesign the current SL, since the current SL was the result of a
trade-off between the demand for site controlled address space, and the
routing communities conflicting demand that any address space not
provider aligned have an enforceable means of keeping it out of the
global routing tables. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 10:48:54 -0700

Margaret Wasserman wrote:
> unreachable.  Even if we group the "local" addresses into a 
> single prefix, applications will still need to handle it when 
> global address/port combinations are filtered/firewalled.
> 
> up with a local addressing scheme that does not require hosts 
> to include any special handling for local addresses (at any 
> layer of the protocol stack).

This pair of paragraphs sums up the fundamental problem. For many there
is an analytical recognition that applications do have to have special
handling for limited scope addresses, but at the same time there is
wishful thinking that we can flatten the network back into a single
routing scope. 

> local addresses, and relying on the longest match rule in the 
> address selection rules to generally match local addresses 
> with local address and globals with globals. But, I really 
> need to understand the goals better before I can be sure.

The inconsistency of accepting DNS enhancements for one type of limited
scope address  but not another is really sad. What is even worse is the
recognition that we don't have a wide understanding of the goals &
requirements, while claiming we have consensus that the only tool in
hand does not solve the problems.

Tony

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Apr 2003 11:27:20 -0700

Hello Tony,

Tony Hain wrote:

> handling for limited scope addresses,

I thought this was under dispute.  I myself do not find the
arguments for special handling very persuasive, for exactly
the reason that Margaret stated:
 
>> ... applications do have to deal with addresses that are 

To me this means that if an application encounters an address
that is unreachable for _any_ reason (not just incompatible
scoping) it has to cope, and maybe in just about the same ways.

For the second part,

>                                      but at the same time there is

What do you think about the proposal to define a block of
addresses for use as globally-unique but not globally routable
addresses?  That's _not_ a single routing "scope".

It would be nice if we could get some quick action on something
along those lines that would (a) allow site-locals to be deprecated
according to the wishes of many people and yet (b) allow the use
of provider-independent addresses according to the wishes of many
people.  Maybe if a lot of people found this to be a solution of
their most important wishes we could move forward more quickly.

Regards,
Charlie P.

---

From: Tim Chown <[email-masked]>
Date: Thu, 10 Apr 2003 19:50:45 +0100

> Further assume that we want to generate /48s.

Well, in some cases a block of /48's is desirable - the nice property of
fec0::/10 is that you can have a local-scope hiearchy of sites with 
aggregatable site prefixes (rather than routers in such a topology needing
to maintain routes to all non-aggregated /48's).

Tim

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 11:58:32 -0700

Charles E. Perkins wrote:
> > This pair of paragraphs sums up the fundamental problem. For many 
> > there is an analytical recognition that applications do 
> have to have 
> > special handling for limited scope addresses,
> 

Some applications might cope in the same way, but others MUST NOT. It is
inappropriate for a file mount of proprietary content to suddenly
traverse the Internet when the internal network partitions. If the file
mount were allowed to arbitrarily connect using the global scope
addresses, this is exactly what would happen.

> addresses for use as globally-unique but not globally 
> routable addresses?  That's _not_ a single routing "scope".

This describes the reality of networks that partition their PA space.
The only arguments against uniqueness are coming from those who want to
ensure that the space is not routable. 

> 
> It would be nice if we could get some quick action on 
> something along those lines that would (a) allow site-locals 
> to be deprecated according to the wishes of many people and 
> yet (b) allow the use of provider-independent addresses 
> according to the wishes of many people.  Maybe if a lot of 
> people found this to be a solution of their most important 
> wishes we could move forward more quickly.

If there were only those two opinions, we might move quickly.
Unfortunately, the consensus call mixed the opinions of those that want
a resolution disallowing local scopes (route filtering) with those that
want to remove the ambiguity aspect of the current SL. Then we need to
account for the opinion of the routing community that wants a way to
ensure that PI addresses do not crush the routing table (actually many
simply do not want PI to exist). To that end, I have been working on a
PI allocation that scales to some degree, but may require minor
adjustments to current business models. This raises yet another
community of opinion, where business models are sacred. There are
undoubtedly other opinions that need to be factored in.

We are not going to find a single approach that meets all competing
requirements quickly. We may find a set of approaches, but in any case
that will take time. If we want to make progress, we need to task those
motivated to get rid of the current SL with finding alternatives first.
Doing otherwise is irresponsible and will only stall IPv6 deployments. I
have no doubt that simply having this debate will cause many to
reconsider their rollout plans.

Tony

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Apr 2003 12:28:42 -0700

Hello Tony,

Tony Hain wrote:

> Some applications might cope in the same way, but others MUST NOT.

I'm still not convinced by your example ...

>                                                            It is
> traverse the Internet when the internal network partitions.

Agreed!

>                                                      If the file

The addresses are supposed to NOT be globally routable.
Thus, the Internet traversal would only happen if the
local network administration made other arrangements
for the packets to be routed to some other domain.
Tunneling comes to mind, but we don't have to be that
specific for this discussion.

So it seems to me that the danger would only exist IF the
network administration took specific steps to enable it.
Administrations that left the provider-independent addresses
routable only within their domain should still see that
the traffic is dropped instead of exiting their domain.

> ensure that the space is not routable.

If I read this correctly, it means we're in good agreement here.
And, others claim (correctly in my opinion) that it is possible
to ensure that the space is not externally routable even if it
contains unambiguous addresses.

> If there were only those two opinions, we might move quickly.

I am suggesting that there may be a large population that hold
these opinions, and if the members of that large population are
willing to forego their other needs for a little while, we might
move forward more quickly now.  The other needs would then
become priority items to be met as soon as the proponents
figure out how.

>                  .............                  Then we need to
> simply do not want PI to exist).

Anyone who does not want to route PI addresses should have
the authority of RFC 36fb (fb == foobar) to back them up!

>                       To that end, I have been working on a

So why can't this be done within the context of an allocated
space of provider-independent but NOT-globally-routable
addresses, by the same specification that deprecates site-local?

> that will take time.

Not all.  Check!   Doing all competing requirements may actually
be impossible, unless the requirements are softened somehow.

>                  If we want to make progress, we need to task those

Unless you can say why the proposed routing doesn't solve the
address scoping problem, I still think there is a viable
strategy lurking nearby.  Agreed it only does two of the
more important things that need to be done.

Regards,
Charlie P.

---

From: Richard Carlson <[email-masked]>
Date: Thu, 10 Apr 2003 14:39:14 -0500

Hi Charrlie;

>scoping) it has to cope, and maybe in just about the same ways.

I agree with this statement.  Why would applications that have unreachable 
peer handling care what the reason is?

Regards;
Rich

>their most important wishes we could move forward more quickly.

------------------------------------

Richard A. Carlson                              e-mail: [email-masked]
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 02:44:45 +0700

Date:        Thu, 10 Apr 2003 15:31:13 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let's also assume that item (4) ["requirements for a local 
  | addressing mechanism"] in the chairs' work list is relatively
  | straightfoward and obvious.

I wouldn't.

  | Assume that we consider stable, probably unique,
  | unrouteable prefixes important enough to get their own 3-bit
  | prefix, and for the sake of argument let's pick C000::/3.

Actually, we don't need a 3 bit prefix for these - the number allocation
in the rest of the prefix can be quite dense, there are no H ratios to
consider here, so a very large number of sites will fit.   So, say,
a 10 bit prefix (just to pick a number) would most likely work just fine.
For the sake of argument, let's pick FEC0::/10

  | Further assume that we want to generate /48s.

Of course, nothing else is rational (though, just like globals, there
needs to be a provision for pairs, or even bigger blocks, for those very
few truly huge sites for which a /48 is not enough - but while we need
to remember not to break that, we can probably ignore it for most purposes).

  | Then the problem to solve is generating probably unique 45 bit
  | numbers easily and essentially free of charge. That's clearly possible 
  | in several ways, so let's not debate details.

Well, actually, it was the details of this that led to site locals as we
have them now.   You may remember that I was one of those who thought that
this should be achievable fairly easily - but the WG back in the early
days did not agree, no-one wanted to create another ICANN type organisation,
which is more or less what would be required (just with people selling
numbers instead of names - just like domain names, there has to be some
kind of renewal payment, or dead allocations never get cleaned up, and
even with 45 bits of address space, if nothing is ever reclaimed, they
won't last very long).

So, let's do exactly that and, if not quite debating details, at least
produce some concrete proposals, and see how well they're supported,

  | What are they going to do to the scoped architecture? Will applications
  | need to treat them any differently from 2000::/3?

For the few applications that care any more than "if I send a packet, does
it arrive" (which work just fine with SL as it exists now), then yes.
Apps would need to make sure that they only send addresses to other nodes
which are likely to work there, so they'd need to filter out the useless
ones (somehow working out which those are - if it is a defined prefix, that's
fairly easy) and only sending ones that can be expected to work.

This is pretty much exactly what needs to be done using current SL's.

The one difference is that (one hopes) that a C000::/3 would be certainly
useless if sent outside its zone of reachability (a packet sent to it will
go as far as default routes take it, then die).   On the other hand, a
packet sent to a (current) FEC0::/10 just might go to some node in the
other site because of the ambiguity (which is a problem that really is
bringing the internet to its knees with 1918 addresses, isn't it!)

Of course, if sites don't just use FEC0::/48 but instead really use
FEC0::/10 and 38 random bits, the chances of the same random bits just
happening to be in use at some other location where a referral happens to
have been sent are vanishingly small.   But even if it does happen, and
FEC0::/48 will probably be fairly common, the chances of a packet being
delivered to some other node are pretty low, given that most addresses
have an EUI-64 (or a random number) in the low 64 bits, so the chances of
duplication in different sites is pretty tiny.

Once again, I wouldn't mind some kind of number allocation authority to
fill in the 38 bits with something more likely to be unique than a random
number (or the 45 bits if a /3 replaced the /10) - but before we think
about discarding what we have now, let's get the details of that authority
(or mechanism) worked out and defined, and agreed to.   If attempts to 
do that fail, then we still have SL's as we have now, which is certainly
a big advantage over nothingness.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 03:10:44 +0700

Date:        Thu, 10 Apr 2003 11:27:20 -0700
    From:        "Charles E. Perkins" <[email-masked]>
    Message-ID:  <[email-masked]>

  | 
  | Hello Tony,

  | To me this means that if an application encounters an address
  | that is unreachable for _any_ reason (not just incompatible
  | scoping) it has to cope, and maybe in just about the same ways.

Yes, I agree with that much.  The difference is where an application needs
to send an address to its peer, and has two available - which does it pick.
If they're both global, then both are equally likely to work, so random
selection (or selection using any other available criteria) is as good as
it gets.   On the other hand, when they're of different scopes, then the
app wants to take care not to send an address that is not appropriate for
the destination, so random selection most certainly isn't the solution.

  | What do you think about the proposal to define a block of
  | addresses for use as globally-unique but not globally routable
  | addresses?  That's _not_ a single routing "scope".

No, but it is essentially identical to what we currently have.   There
are almost no real practical differences.   Why change?

  | It would be nice if we could get some quick action on something
  | along those lines that would (a) allow site-locals to be deprecated
  | according to the wishes of many people and yet (b) allow the use
  | of provider-independent addresses according to the wishes of many
  | people.  Maybe if a lot of people found this to be a solution of
  | their most important wishes we could move forward more quickly.

Yes, if that could be done, it would be fine.   The problem is, that the
last time this was attempted, (a) was the result of the search for (b).
What makes you sure that the result would be different this time?
Or different in a way other than "no consensus was achieved for any
particular non routable addressing scheme so we won't have one" which
at the minute is the most likely outcome of ant attempt to find something
new (given that many people have been, wrongly I believe, scared away
from site locals as we have them, and so might not support them even
as a compromise solution).

kre

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 13:28:46 -0700

Charles E. Perkins wrote:
> ...
> >                                                      If the 
> file mount 
> > were allowed to arbitrarily connect using the global scope 
> addresses, 
> routable only within their domain should still see that the 
> traffic is dropped instead of exiting their domain.

You missed the point. For this to work as you describe, the application
had to do something to recognize the different scopes of the addresses
available to it. If it does nothing and expects all addresses to have a
single scope, it will recover into a state that the network manager
wants to preclude.

> 
> If I read this correctly, it means we're in good agreement 
> here. And, others claim (correctly in my opinion) that it is 
> possible to ensure that the space is not externally routable 
> even if it contains unambiguous addresses.

If a single entity is in control of routing announcements, the
confidence level of it being correct is higher, though most would
recognize that errors happen. When sites interconnect, or service
providers have explicit instructions for custom handling of prefixes,
there is an opportunity for error outside the origin sites control.
Ambiguity raises the confidence level that filtering will happen even in
the case of errors, because the well-known prefix will be filtered at
multiple levels. 

> > > according to the wishes of many people and yet (b) allow 
> the use of 
> > > provider-independent addresses according to the wishes of many 
> I am suggesting that there may be a large population that 
> hold these opinions, and if the members of that large 
> population are willing to forego their other needs for a 
> little while, we might move forward more quickly now.  The 
> other needs would then become priority items to be met as 
> soon as the proponents figure out how.

Wrong order, and from what I can tell many hold the opinion that we
should remove ambiguity simply on the promise that we might find an
alternative. We are much more likely to find alternatives if those who
want ambiguity to go away are motivated. If ambiguity goes away, it will
be much harder to get the group to agree that the other needs are in
fact priorities.

> the authority of RFC 36fb (fb == foobar) to back them up!

Cash speaks much louder than an RFC, particularly if the competitor is
willing to ignore the RFC to get it.

> 
> >                       To that end, I have been working on a PI 
> > allocation that scales to some degree, but may require minor 

If it meets all the needs, I have no problem. That is not what the
chair's plan of action is though. Item 1) specifically calls for
deprecation, then item 4) identifies requirements for a replacement,
followed by possible future work items on solutions if the group comes
to consensus on requirements and the charter is appropriately updated.
The point is there are many opinions on what is right here, and until
they result in a viable alternative that all agree to, the current plan
must remain in place.

> > requirements quickly.  We may find a set of approaches, but in any 
> > case that will take time.
> 

The current activity shows that even when requirements are softened
(like uniqueness was last time around), people will try to firm them
back up later. 

> > motivated to get rid of the current SL with finding alternatives 
> > first. Doing otherwise is irresponsible and will only stall IPv6 
> > deployments. I have no doubt that simply having this debate 
> will cause 
> > many to reconsider their rollout plans.
> 
> strategy lurking nearby.  Agreed it only does two of the more 
> important things that need to be done.

What is important depends on which community you are standing in, and
what issues have been recent irritants. Also, what looks like an obvious
solution from some perspectives, is an absolute non-starter from others.
We must not fall in the trap of proclaiming 'there must be a simple
solution' and deprecating the only tool we have. We must find a solution
that all can accept first.

Tony

---

From: David Conrad <[email-masked]>
Date: Thu, 10 Apr 2003 14:35:46 -0700

Perhaps I'm misunderstanding...

On Thursday, April 10, 2003, at 12:44  PM, Robert Elz wrote:
> just like domain names, there has to be some

2^45 / ( 60 * 60 * 24 * 365.25) = 1,114,925

If you are allocating (on average) a /45 per second, 24x7x365, it will 
take over 1 million years to consume 45 bits of address space without 
reclamation.

> FEC0::/10 and 38 random bits

2^38 / ( 60 * 60 * 24 * 365.25 ) = 8,710

If you are allocating (on average) a /38 per second, 24x7x365, it will 
take over 8 thousand years to consume 38 bits of address space without 
reclamation.

A simple auto-responder operated by some global authority (or split 
among (say) 4 or 5 regional authorities) that automatically responds to 
a request every second would probably take a competent perl (or other 
language) programmer a day or two to throw together.

What am I missing?

Rgds,
-drc

---

From: Tim Chown <[email-masked]>
Date: Thu, 10 Apr 2003 23:13:20 +0100

> What am I missing?

So my disconnected network gets a prefix from your autoresponder how? :)

Tim

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 05:33:50 +0700

Date:        Thu, 10 Apr 2003 14:35:46 -0700
    From:        David Conrad <[email-masked]>
    Message-ID:  <[email-masked]>

  | What am I missing?

Aside from Tim's response, there's also the issue of why I'm only
going to be asking for one a second.   I think I'd try more like
a thousand a second.   If a thousand other people do the same, then
the 2^45 space is gone in a year.

Why would we do that?    Well, after the year, the address space is
going to be exhausted, but I'm going to have a nice supply that I
can agree to part with some of, for just a small consideration...

Now if you make the application refuse to service more than one
request a second, to prevent this, then it is going to be pretty
difficult for anyone else to ever get a number, because these
million requests a second are still arriving, in addition to the
few hundred (or so) from "legitimate" users.

To prevent this, you need to start doing lots of analysis of the
requests, using some non-trivial technology to make sure that you're
only allocating addresses to those who deserve them.

At this point, the whole thing gets non-trivial.

Of course, if there's a non-trivial charge for the numbers, then
many of those problems go away - but who gets to keep all that money?
How do I get to be someone who gets to allocate an integer in response
to a request, and charge $1 for the privilege (and how big a chunk
of that 2^45 (or 2^38) can I have just for me, for free... - if not
for free, then how do I get to be the organisation that allocates the
chunks, for much larger sums, and much less work).

All of this really was considered 8 years or so ago (no, I really
don't remember when it was) - schemes to allocate numbers look easy,
but to make them effective, and reasonable, and able to avoid abuses
they're not nearly as simple as they look like they should be.

kre

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 16:11:11 -0700

Robert Elz wrote:
> ...
> All of this really was considered 8 years or so ago (no, I 
> really don't remember when it was) - schemes to allocate 
> numbers look easy, but to make them effective, and 
> reasonable, and able to avoid abuses they're not nearly as 
> simple as they look like they should be.

Preallocation of a range in an evenly distributed manner would get past
the abuse issues, or at least localize them to the granularity of the
distribution grid. 

Tony

---

From: David Conrad <[email-masked]>
Date: Thu, 10 Apr 2003 16:39:18 -0700

On Thursday, April 10, 2003, at 03:33  PM, Robert Elz wrote:
> Aside from Tim's response,

Which, given the smiley, I assume was in jest.  If it wasn't, I've got 
a few billions of hours worth of AOL "1035 hours free" CDs I'd be happy 
to send his way.

> there's also the issue of why I'm only
> going to be asking for one a second.

I didn't assume that.  I said the auto-responder would respond to one 
per second (or 10 or 100 or 1000, 2^45 is a _lot_).

>  I think I'd try more like

*Yawn*  So, the automated system keeps track of the requesting address 
and drops multiple requests from the same source.

This is just silly.  Yes, we can all come up with DoS attacks that can 
disable a service like this.  We can also come up with remedies against 
many of those attacks.  Arms races are fun.

What is the point?  We're talking about allocating a globally unique 
prefix for each non-connected sites to remove what some consider a 
wart/unnecessary and/or ill-defined complexity that will result in 
duplicate addresses.  You want to connect, you're going to have to get 
a prefix from your ISP and renumber anyway.

The advantages to allocating a globally unique prefix are well known.  
The disadvantage is that someone/something has to insure global 
uniqueness.  Given 2^45, it would be mind-numbingly easy to determine 
whether or not an automated system was being abused _LONG_ before any 
even close to significant portion of the prefixes were consumed.  The 
allocating organization(s) then come up with solutions to the abuse and 
wait for the next abuse mechanism to appear.  I do not see why this 
requires a perfect theoretical solution when a pragmatic engineering 
solution will be good enough and is so bloody easy.

This entire discussion has been really depressing.  People seem to be 
arguing theoretical positions instead of trying to come up with 
engineering solutions to what is, fundamentally, a non-problem.  
Non-connected sites are going to have to renumber if they want to 
connect (at least according to the current routing paradigm).  Given 
that, we might as well make it easier for non-connected sites that want 
to talk to each other.  Who knows, maybe somebody will come up with a 
way to flat route 2^48 in the million years between now and when the 
first /3 is consumed.

Sheesh.

Rgds,
-drc

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 17:00:12 -0700

David Conrad wrote:
> You want to connect, you're going to 
> have to get 

This statement keeps being made as if there is magic in connected
status. The reality is that in IPv6, renumbering is simply adding a
prefix. There is no requirement that any other prefixes go away. In
particular, a stable site controlled prefix will not go away no matter
where it came from.

> connect (at least according to the current routing paradigm). 

Or simply pay *enough* to get their prefix of choice routed.

Tony

---

From: David Conrad <[email-masked]>
Date: Thu, 10 Apr 2003 17:56:51 -0700

Tony,

On Thursday, April 10, 2003, at 05:00  PM, Tony Hain wrote:
> The reality is that in IPv6, renumbering is simply adding a
> prefix. There is no requirement that any other prefixes go away.

Pragmatically speaking, I believe this requirement will be made by ISPs 
when you move from one provider to another.  Even if it isn't, you will 
(perhaps eventually) have to garbage collect all the non-useful 
prefixes from router configs, firewall rules, network management 
packages, etc.

>  In

Yes, and barring NAT, you still need to number the site with the 
provider's prefix you obtained to gain connectivity.  Given this, I 
don't see any particular value in using a prefix guaranteed to be 
ambiguous over a globally unique prefix (assuming the globally unique 
prefix can be obtained trivially).

> Or simply pay *enough* to get their prefix of choice routed.

Only if they have globally unique prefixes (which I thought you were 
arguing against).  And besides, pay whom?  Potentially each and every 
ISP in front of each and every site they want to reach?  If this were 
easy, why aren't we doing it with IPv4 now?

Rgds,
-drc

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 10 Apr 2003 18:09:17 -0700

Hello Tony,

>single scope, it will recover into a state that the network manager
I _did_ mean that the application should not distinguish the scope
by considering the address.  I guess you mean to suggest that the
application should distinguish its inferred level of security for the
data transfer based on whether the destination is site-local or not.

This suggestion, though, can only work one time.  If an application
needs to make _two_ distinctions (for, say, two different reasons,
or two different levels of security), site-local cannot help.

Doesn't this mean that the addressing is effectively imbued with
some other characteristic(s) (like security level in this case)?
I thought that associating the address structure with application-
defined semantics was "bad".  I'm remembering the "porn bit".

>there is an opportunity for error outside the origin sites control.
Do you mean, that some other site would advertise a PI prefix that
actually belonged to the origin site?  It seems to me that this wouldn't
wreak too much damage as long as the core routers didn't have to
accept the prefix.

>the case of errors, because the well-known prefix will be filtered at
It seems to be a tricky business to predict which of several possible
protocol or administrative errors would be more likely, but in this
case it seems to me that there isn't much difference.  If I had an
"ambiguous" prefix, and a friend to route it for me, I might ought
to warn my friend that it was ambiguous.  But even if I was lax, I'd
still expect my friend to honor an agreement that we might make.
Thus, the "ambiguous" case has "more" error potential, it seems to
me.  Suggesting that ambiguity is a stronger deterrent than mandating
exclusion from the core routers is pretty speculative, isn't it?

>be much harder to get the group to agree that the other needs are in
I'd rather suggest that we build on smaller successes instead of
keeping around bugs for people to fix.  The danger might be that
the buggy stuff would get more and more ingrained to the point of
permanence.  Ambiguous addresses seem "buggy" even by your
description of their value.

>willing to ignore the RFC to get it.
But that's fine with me too.  I only suggest that the non-aggregable prefix
should not get into the core routing tables.  If someone wants to route it
by other means, why not?  Even if one of the core routers advertises such
a prefix, all the others "should' ignore it or flag it as an error.  I 
don't see
this as a terrible problem...

>chair's plan of action is though.
>
Good plans can take improvements into account, and if
there were some acceptable consensus I bet it would carry weight.

> Item 1) specifically calls for
A plan that gets (a lot?) more than the existing amount of consensus
could be called "better", in a way.  I think the non-globally-routable GUPI
plan has some chance at that.

>that all can accept first.
Well, that's not what I'm suggesting.  I'm only suggesting that there might
be a better plan (non-globally-routable GUPI) that is acceptable to
_more_ people (not everybody).  It's simple, because it's incomplete.

Regards,
Charlie P.

---

From: Greg Daley <[email-masked]>
Date: Fri, 11 Apr 2003 11:06:31 +1000

Hi Tim,

> So my disconnected network gets a prefix from your autoresponder how? :)

I'm sure they could put a fax number on the website ;)

Greg Daley.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 11 Apr 2003 11:08:59 +1000

> prefix, and for the sake of argument let's pick C000::/3.

I dunno, I'm not sure that that's called for.  I'd agree
that we'd probably like to generate /48s, but I think that
2^38 of them is probably enough.  Remember, the uniqueness
constraint is really just there to ease site mergers.

> [...] Therefore, assume we have a way of generating such
> prefixes under C000::/3.

I'd rather see:

    1) something useful using FEC0:/10 very soon,
	eg: non-aggregable non-globally-routed.
	provider-independent addresses (GUPIs)

    2) some further work on route-aggregable PI addressing,
        which could more usefully be assigned a block like
	C000:/3.  

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 11 Apr 2003 11:22:52 +1000

> defined semantics was "bad".  I'm remembering the "porn bit".

I'd agree, in so far as deciding what a scope 'means' from the
scope is a flawed approach ... maybe _this_ GUPI is my sooper-
secure VPN, but _that_ GUPI is my experimental broadcast radio
interface ...

I think it would be good for nodes to be able to recognize 
the difference between scopes though, and avoid sending packets
which cross scopes.  That would clear up a lot of the issues
re: convexity, etc.

> by other means, why not?

Eg: tunnels, presumably.  Yeah, I don't see a problem with that,
if the Illuminati want a globally-routable PI network running
over VPN tunnels, they can have one ... and organize their own
route aggregation.

> _more_ people (not everybody).  It's simple, because it's incomplete.

Hmmm ... maybe we should complete it, and see if it's still simple!

-----Nick

---

From: Mike Saywell <[email-masked]>
Date: Fri, 11 Apr 2003 02:37:04 +0100

I might have missed something here, but...

Wy dont we go with something like C000::/3 and then allocate prefixes
within that to the various different uniqueness mechanims such as geo,
MAC, time, requested, manual, random etc?

I think it's quite clear that people had very different requirements from
SLs, perhaps their main strength was simply as a big chunk of free to
use address space.  It would be nice if this quality could be preserved
whilst removing the ambiguity and consequent scope issues.

C000::/3 addresses could be treated as global (imho) so existing
implementations wouldn't need changing.  With ISP support it's possible
that some schemes really could become globally routable and thus offer
some degree of provider independance.

I think something like this would be simple to implement today and hopefully
would address a lot of the concerns people had with SLs.

Cheers,

Mike

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Apr 2003 18:43:13 -0700

> I offer draft-hain-ipv6-sitelocal-00.txt as a starting point.

Ok, let's take a look at this document.

>    Most of the arguments against the use of site-local addresses amount 
>    to wanting applications to work even in the presence of intentional 
>    filtering imposed by the network manager. The argument to remove 
>    site-local addresses from the architecture is equivalent to; we 
>    should prevent you from doing harm to yourself by insisting that 
>    scissors were never invented, that way we don't have to keep telling 
>    you not to run with them. Filtering will exist in networks, so there 
>    will be domains of applicability, or scopes. Applications that 
>    insist on passing topology information outside its domain of 
>    applicability will fail to operate correctly. 

I believe that you have misunderstood other peoples' arguments.  Nobody 
denies that filtering will occur.  However, people have raised concerns 
about how an API should interpret a site-local as opposed to a globally 
scoped address.  There is also a response time issue, as well as the 
security of ICMP to consider at the same time.  How long do you get to 
complete a phone call?

>    The site-local address format uniquely identifies interfaces within 
>    a single administrative domain of applicability. Site-local 
>    addresses are designed to provide stable addresses for use inside a 
>    site. 

Let us delve deeper than this.  Why is it that stable addresses are so 
necessary?  Could it be because renumbering is painful?  Could that be 
one source of our ills?

Jumping around a bit...

>    Private space is used to avoid exposing to competitors what internal 
>    networks they are deploying and which office is coordinating that   
>    effort.

One needn't have private address space to avoid this problem.  You don't 
need private address space to conceal topology.

>    Network managers also don't have to expose business plans to 
>    a registrar for evaluation for networks that are not attached to the 
>    global Internet. 

I think this is a real problem, because registrars still do not 
understand the amount of address space they have.  Simply charge a 
linearly increasing fee and be done with it.

>    Some have stated that if they are required to 
>    register for public space for every internal use network, they are 
>    more likely to pick random numbers than tip off the competition.

Because of the other problems.  And indeed they may be better off doing 
so, even so.  Which brings us to:

>    Another significant use of private address space is test networks. 
>    Frequently these are large, elaborate networks with a mix of public 
>    and private address space. Use of random unallocated space runs the 
>    risk of collision with legitimate addresses on remote networks. 

Yes, but it's a very low risk.  Far lower than IPv4.  But you also miss 
a point.  The reason people use private address space today is simply 
because of the hassle of getting it allocated.  Fix the registries and 
this largely goes away.

Finally, from your security considerations section:

>    Access control is one aspect of what SL provides. It is a clear 
>    address space that service providers can put in bogon filters, and 
>    enterprise managers can filter without having to go into detail 
>    about which specific devices on a subnet are allowed in or not. It 
>    does not comprise a full service security solution, and should not 
>    be sold as such. It is simply a way to clearly articulate the 
>    difference between public and private endpoints. 

While I understand why you would think this, it was a huge mistake for 
the providers to believe this with RFC 1918 addresses.  Every time 
someone advertises a bogus route to a real network I kick myself because 
people thought RFC 1918 would solve that problem.  It won't.  Filtering 
of site-locals is nothing more or less than filtering any other address 
range.  We now know through fast and hard experience that such 
permissive mechanisms are BAD for the Internet.  Let's not make this 
same mistake again.

> provider aligned have an enforceable means of keeping it out of the

The cynical would say that 8+8 was given short shrift.

Eliot

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 10 Apr 2003 21:32:42 -0700

Hello Robert,

>are almost no real practical differences.   Why change?
I would think that a solution that doesn't have scope built into the
addressing architecture, and that has few practical operational
differences from site-local, would be a good choice.

The reason for change would be to eliminate ambiguous addresses.

>What makes you sure that the result would be different this time?
I'm not sure!  But I would like to see a way to have the kind of
provider independence that site-local provides, and this is a way
to do it that is "compatible" with the vote to eliminate site-locals.
Making more people happy and giviing more people what they
need/want is a better outcome than just eliminating site-locals.

>particular non routable addressing scheme so we won't have one"
>
Well, at least they're routable away from the core, unique, and useful
right away.  Why do you say that "globally unique, provider independent,
non-globally-routable" is not a particular choide for an addressing scheme?
Do you mean that it's not specific enough?  Additional specification
would come later as needed.   My proposal is to specify some useful
address range at the same time that site-locals are deprecated.  I don't
even care if it's FEC0/10 but there are surely arguments pro and con
and maybe somewhere else is less controversial.

Regards,
Charlie P.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Apr 2003 10:40:50 +0200

> the 2^45 space is gone in a year.

Of course the allocator would throttle the rate, but indeed
there are various DoS attacks to be considered.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Apr 2003 10:39:22 +0200

> So my disconnected network gets a prefix from your autoresponder how? :)

That's why there are other algorithms to consider (GPS readout or a
date-and-time based hash or an IEEE address hash, for example).

The point is, it's soluble one way or another.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 17:06:47 +0700

Date:        Thu, 10 Apr 2003 16:11:11 -0700
    From:        "Tony Hain" <[email-masked]>
    Message-ID:  <0fcb01c2ffb6$7c95fb90$ee1a4104@eagleswings>

  | Preallocation of a range in an evenly distributed manner would get past
  | the abuse issues, or at least localize them to the granularity of the
  | distribution grid. 

Only if you have some way to verify that the source of a request is
with the designated grid unit.   To make any verification like that
non trivial to subvert, it is going to cost something to perform,
so the idea of free numbers goes away - then the billing also needs
to be paid for, and the organisation doing all this work is going to
want to be compensated for it (profit...)

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 17:18:24 +0700

Date:        Thu, 10 Apr 2003 16:39:18 -0700
    From:        David Conrad <[email-masked]>
    Message-ID:  <[email-masked]>

  | *Yawn*  So, the automated system keeps track of the requesting address 
  | and drops multiple requests from the same source.

And now no-one is able to offer a broker service, with a nice web,
or e-mail (or telephone, for Tim's people who aren't connected)
interface, because you will only allow the source address to request
one address.

Of course, if all this is being done using IPv6, which we assume it
one day will, then I have 2^64 available source addresses in one
subnet available to me, which is enough to get all 2^45 site numbers
if you just check the address for uniqueness.   So, you're going to have
to try and find some larger aggregation to use, and get that right.

  | This is just silly.  Yes, we can all come up with DoS attacks that can 
  | disable a service like this.  We can also come up with remedies against 
  | many of those attacks.  Arms races are fun.

And costly.

  | What is the point?  We're talking about allocating a globally unique 
  | prefix for each non-connected sites to remove what some consider a 
  | wart/unnecessary and/or ill-defined complexity that will result in 
  | duplicate addresses.

Yes, and as I said before, and proposed in different ways several times,
that's what I would have liked too.   I still would.

The point here is that previous attempts to do this all failed.

So, I'd like some very strong evidence that this time it will succeed,
before being willing to throw out all of what we now have, because I
have no confidence at all that it is going to succeed this time.

  | You want to connect, you're going to have to get 
  | a prefix from your ISP and renumber anyway.

Of course you'll need a new prefix, but as Tony said, not "renumber"
But that's irrelevant here.

  | This entire discussion has been really depressing.  People seem to be 
  | arguing theoretical positions instead of trying to come up with 
  | engineering solutions to what is, fundamentally, a non-problem.

I agree with this.   I have practical experience, and site local addresses
as we have them work.   We don't need any of this discussion.

If we want to find a way to allocate stable PI addresses, and we can make
that work, then let's just do that.   Once we have it, it is quite possible
that there will be no remaining need for site-local addresses, and then
no-one is going to object to deleting them.   Until then, they should
stay just as they are now.

kre

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 17:50:18 +0700

Date:        Thu, 10 Apr 2003 18:43:13 -0700
    From:        Eliot Lear <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let us delve deeper than this.  Why is it that stable addresses are so 
  | necessary?  Could it be because renumbering is painful?  Could that be 
  | one source of our ills?

No.   The more painful renumbering is (and hence the less often we're
likely to actually do it - even if that means being locked into an ISP)
the less we need some other kind of stable addresses, because in practice
the ISP provided addresses are stable.

The easier we make renumbering, which I agree is something that we should
be working on (and something I am actually getting some work done on),
the more we want/need some other stable addressing scheme.

The root cause is that addresses are also identifiers, and things break
when the identifiers alter.

So, we one of two problems solved before we can give up on some easily
obtainable stable address space - either we need PI (routable) addressing,
or we need separation of identity from location.   So far, after all of
these years, we have failed to find anything that works for either of
those.

When you have a solution to one of them, that will be a big advance by
itself - then we can look again and see if we still have a need for any
other kind of addressing.

kre

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Apr 2003 14:45:27 +0300 (EEST)

> when the identifiers alter.
[...]

Indeed, but that depends a *lot* on what you expect of "renumbering".

IMO, we should focus on making renumbering as easy as possible *primarily* 
with no regard to connection survivability.  Even if connections broke, 
that alone coul dbe a huge win.  Of course, a full solution would be 
bonus, but not realistic to aim for.

To begin with, writing an informational document on operational procedures 
how to make renumbering easier could be a start to scoping the problems.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 20:40:53 +0700

Date:        Fri, 11 Apr 2003 14:45:27 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | IMO, we should focus on making renumbering as easy as possible *primarily* 
  | with no regard to connection survivability.

I agree, for connections which are using the addresses that are altered.
Finding a way to keep them running is some long term project for someone
else...

But, I want to keep connections that don't have to be affected by the
renumbering - and that means having those use some addresses that aren't
going to be affected.

kre

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 11 Apr 2003 07:56:22 -0700

Hello Robert,

Robert Elz wrote:

>  | I would think that a solution that doesn't have scope built into the
>  | addressing architecture, and that has few practical operational
>  | differences from site-local, would be a good choice.
>
>Unless we delete link-local, that isn't going to happen, is it?
>
Got me there.  But it's the exception that proves the rule, because
applications using link-local are in fact special-built to do so.

>  | I'm not sure!  But I would like to see a way to have the kind of
>  | provider independence that site-local provides, and this is a way
>  | to do it that is "compatible" with the vote to eliminate site-locals.
>  | Making more people happy and giviing more people what they
>  | need/want is a better outcome than just eliminating site-locals.
>
>That's fine - but let's find the new solution first, please.
>
>  
>
O.K.  How about a staged solution?  The first autoresponder gives out a
new address to _any_ requester, but only one per minute total no matter
how many requesters.

Then we work from there to solve more and more of the problems
that you have raised in other messages.  As I remember, almost no
IETF solution is perfect on first deployment (even site-locals, as it
turns out).

The broker service is easily arranged even by autoresponder.
And if it's simple enough I reckon an autorresponder ought to
be hosted on IANA's website.  IANA "could" delegate out
subranges to other sites for robustness.

Regards,
Charlie P.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Apr 2003 08:30:44 -0700

Rob,

Have you looked at HIP?

Eliot

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 22:37:37 +0700

Date:        Fri, 11 Apr 2003 07:56:22 -0700
    From:        Charlie Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | But it's the exception that proves the rule, because
  | applications using link-local are in fact special-built to do so.

No, they're not.   The applications that use them most commonly in normal
use are, but part of the objective for LL addresses was to be able to
deal with an isolated LAN - no routers - and on that LAN you want all of
the applications to function.   What's more, a host connected to that
LAN isn't necessarily not also connected to other LANS.   That means that
all applications need to be able to handle scoped addresses, just so they
can function in this kind of environment.   That includes where you want
to use your multi-interface host (802.3 and 802.11 perhaps - they're
pretty common these days) to figure out what is going wrong on the LAN
and why the router is not advertising any prefixes.   That might mean
using telnet, snmp, http, ssh, tftp, ... (almost anything).

  | O.K.  How about a staged solution?  The first autoresponder gives out a
  | new address to _any_ requester, but only one per minute total no matter
  | how many requesters.

Fine.   Make it work, and we'll see how well it functions.

And you're doing that, also consider how you convince people to actually
use it, rather than just inventing their own number and using that.
What's the benefit that the average site is going to get, or what
down-side is there to just inventing a number for a site which only
intends to use it internally (disconnected, filtered, whatever).

Remember, even back in the early days, when all it took was an e-mail
to get a class B number (I don't go back far enough to when this worked
for A's!) lots of people still just picked a number out of the air and
used it.

kre

---

From: Shannon -jj Behrens <[email-masked]>
Date: Fri, 11 Apr 2003 08:45:41 -0700

> I might have missed something here, but...

<http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt>

Just a few days ago, I was volunteering to create the service for free (in the
name of fame), and Michael Py reminded me of the above draft which talks about
your next paragraph.  

By the way, my service was going to be based on a simple turing test instead
of rate limiting (these are just small details), such as the simple tests 
required before you can create a new slashdot account.

> would address a lot of the concerns people had with SLs.

I agree.

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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: "Charles E. Perkins" <[email-masked]>
Date: Fri, 11 Apr 2003 09:12:49 -0700

Hello Robert,

I'll respond mainly just to clarify what I said, but maybe
the discussion is not generating much that is new.  If so,
I hope you don't mind if I let you have the last word.

Robert Elz wrote:

> the applications to function. 

I completely agree with this, and I meant to say
something different, but I think you already said it better.

> Fine.   Make it work, and we'll see how well it functions.

You're on.  But I can't do much on it before next week.

> use it, rather than just inventing their own number and using that.

Obviously, this is impossible to do in any absolute sense.
But, it could be that "most" people will "do the right thing".
And you are right that everything needs clear documentation.

> intends to use it internally (disconnected, filtered, whatever).

Only future-proofing and the possibility for tunneled access
to the outside world.

> for A's!) lots of people still just picked a number out of the air and

In fact, people still do this for disconnected sites.

Regards,
Charlie P.

---

From: Ole Troan <[email-masked]>
Date: Fri, 11 Apr 2003 17:25:00 +0100

Charlie,

> applications using link-local are in fact special-built to do so.

are they? so the solving the "dentist's office" problem is no longer
on the agenda. that's news to me.

every application must work with link-local addresses.

/ot

---

From: Thomas Narten <[email-masked]>
Date: Fri, 11 Apr 2003 12:45:35 -0400

> linearly increasing fee and be done with it.

This issue does not exist for IPv6. The RIR policies for allocating
IPv6 address space say one can give each end site a /48 (or
/64). There is no need to count hosts or in any other way justify how
many hosts one has.

This a *big* change from IPv4.

See, for example, http://www.arin.net/policy/ipv6.html

Thomas

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 17:53:05 +0700

Date:        Thu, 10 Apr 2003 21:32:42 -0700
    From:        Charlie Perkins <[email-masked]>
    Message-ID:  <[email-masked]>

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Apr 2003 17:53:05 -0400

> Some applications might cope in the same way, but others MUST NOT. It
> is inappropriate for a file mount of proprietary content to suddenly

No, it's inappropriate for an application to make assumptions about the
security properties of the links over which its traffic will be routed.
If the content is potentially sensitive, the traffic should be encrypted
by the application.

> If we want to make progress, we need to task
> those motivated to get rid of the current SL with finding alternatives
> deployments. 

After several years of trying, the people who want to keep SL have
failed to meet the burden of demonstrating how it can work reasonably.
Keeping SL under these circumstances is irresponsible, a violation of
our processes, and serves only to ensure that IPv6 will be nearly
useless.

> I have no doubt that simply having this debate will cause

it's entirely because of this debate that IPv6 might actually become
viable.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Apr 2003 17:57:44 -0400

> I agree with this statement.  Why would applications that have
> unreachable peer handling care what the reason is?

apps often want to handle a temporary condition (e.g. link down)
differently than a presumably permanent one (e.g. administrative
prohibition).  

for instance in the case of email, if the connection to the
destination server times out or gets an ICMP unreachable or the client
gets a 4xx response in SMTP then, it retries later - only bouncing if
the destination is repeatedly unreachable.  OTOH if the client gets a
5xx response it bounces the message immediately. detection of an ICMP
administrative prohibition response could work the same way.

Keith

---

From: David Conrad <[email-masked]>
Date: Fri, 11 Apr 2003 15:18:23 -0700

Robert,

> interface, because you will only allow the source address to request

The goal of the allocation service is to allocate to non-connected 
sites -- something that would be done by individuals from the sites in 
question.  A brokerage service for non-connected sites, if such ever 
existed (why?), would presumably arrange for a special service from the 
global or regional allocator or could obtain a provider prefix.

Rate limiting based on source address is but one trivial example of how 
to combat abuse.  As has been described elsewhere, another example 
would be to use some form of simple Turing test.  There are a myriad of 
other mechanisms that could be used to make abuse less likely.  Yes, 
with enough effort, abuse can still occur ("with enough thrust, pigs 
can fly"), but the abuse can be detected trivially ("hmmm.  why were 
400 times as many prefixes allocated this week compared to last week?") 
and specific instances of abuse can be addressed.

> The point here is that previous attempts to do this all failed.

I personally think the roadblocks created by those wanting a perfect 
solution are indicative of one of the areas where the IETF has gone 
wrong, but that's a rant for another venue.  In general, it is 
difficult to come up with a perfect solution.  Typically, a "good 
enough" solution is sufficient to meet pragmatic engineering 
requirements.

> stay just as they are now.

My impression (correct me if I am wrong) is that site-local imposes 
additional complexity on each and every v6 implementation and that the 
complexity (or even the full definition of what a "site" is) has not 
yet been fully understood.  "Administratively scoped" addresses can 
provide the same functionality without special case code being imbedded 
in every implementation, using filtering that is functionality provided 
by every router I'm aware of.   Working code, and all that.

Keep It Simple.

Rgds,
-drc

---

From: Robert Elz <[email-masked]>
Date: Sat, 12 Apr 2003 20:03:12 +0700

Date:        Fri, 11 Apr 2003 15:18:23 -0700
    From:        David Conrad <[email-masked]>
    Message-ID:  <[email-masked]>

  | My impression (correct me if I am wrong) is that site-local imposes 
  | additional complexity on each and every v6 implementation

No, I think the extra required of site local is trivial.   The only real
extra work is to support routing protocols in multi-site nodes, and no-one
is required to support that.

  | (or even the full definition of what a "site" is) has not 
  | yet been fully understood.

This is utter nonsense.   There is no need for anyone to define what
a site is, or not in the way that people keep asking for it to be defined.
What's the full definition of an Autonomous System ?   Yet we've been
using that (ignoring the nonsense about "common control" in its earlier
definitions) forever.   Each of those is whatever its users want it to
be, just a collection of nodes that have been grouped together, and upon
which some routing constraints are imposed.

  | "Administratively scoped" addresses can 
  | provide the same functionality without special case code being imbedded 
  | in every implementation, using filtering that is functionality provided 
  | by every router I'm aware of.   Working code, and all that.

And are no different in any respect from site locals, except that there's
no way the application can tell that they're "special".

Refer back to Charlie Perkins latest message (Friday morning, his time)
and you'll see that we agree that getting rid of site locals doesn't
get rid of scoped addresses, nor does it get rid of ambiguous addresses.
What exactly is being gained?

Don't get me wrong, I'm all in favour of unique PI addresses, if we can
make them work - certainly they'd provide all that SL's as we have them
now provide, and a bit more (they make none of the problems that people
keep claiming SLs have go away, except for the extremely esoteric
"merging sites") - but is there any reason that we can't add that, while
leaving SLs intact as we now have them - and then if they cause SLs to
fall into disuse, they can be deleted.

kre

---

From: Eliot Lear <[email-masked]>
Date: Sat, 12 Apr 2003 13:50:38 -0700

My mistake.  I stand corrected.

Eliot

---

From: Mika Liljeberg <[email-masked]>
Date: 13 Apr 2003 21:36:10 +0300

On Sat, 2003-04-12 at 01:18, David Conrad wrote:
> existed (why?)

Perhaps to offer telephone service for the non-connected administrators
of those non-connected sites. :-)

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Apr 2003 14:46:54 +0200 (CEST)

> but I haven't check that out yet.

Margaret,

Just to be clear: I think the reference to Nemo makes sense in a specific case
of intermittently-connected networks - the case of an organization
having some pieces of their network intermittently connected.
In that case the general approach of tunneling back to the organization's
main network, and the specific instantiation of this called Nemo,
makes sure the addresses in the intermittently connected
part remain as stable as the organization's addressing as a whole.

But this doesn't necessarily address the case of e.g. a lonely household
which is intermittently connected and where the ISP chooses to return
a different prefix each time the household connects.
Note that I don't think there is any technical issues that need to be solved
by the IETF to enable the ISP to hand out the same prefix each time the
household connects. See the "tussel in cyperspace" paper for the issues
around trying to mandate business level issus using protocols.

  Erik

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Apr 2003 09:10:31 -0400

> is required to support that.

This strikes me as a comment from someone who has not been following
this topic in detail. There are _many_ in the community who disagree
with the above statement. Including folk that do applications for a
living and are concerned about the implications on individual
applications.  Consider, for example, how it only takes "trivial"
changes to ensure that an implementation/application that is running
in a multi-sited environment (e.g, a home user with SLs configured
locally who also has an IPsec tunnel back to their work enviornment,
which also uses SLs).

Robert Elz <[email-masked]> writes:

>     Date:        Thu, 10 Apr 2003 09:49:16 +0200
>     From:        <[email-masked]>
>     Message-ID:  <[email-masked]>

> I haven't been following the ipv6 wg list (the ipng list) for about 6
> months now (just lack of time), so I'm not really aware what started
> this silly discussion.

Please spend some time going through the extensive archive on this
topic. You might find that the topic is more complex than your above
comment indicates.

Thomas

---

From: Eliot Lear <[email-masked]>
Date: Sun, 13 Apr 2003 08:47:52 -0700

> is required to support that.

So long as you go with the rule that you select a source address based 
on the destination's scope, that all works.  If you don't do that we 
have other problems, such as unacceptably long application time-outs. 
Christian's rules actually seem pretty sensible in this regard.

> There is no need for anyone to define what

And in fact, if the ultimate decision is to keep SLs, this is an 
important point.  Sites end at administratively defined boundaries. 
It's almost like asking where one should put a firewall.  The answer is, 
of course, where one is needed.

> fall into disuse, they can be deleted.

What benefit, then, does IP version 6 provide you?

Eliot

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Apr 2003 16:20:23 +0700

Date:        Sun, 13 Apr 2003 08:47:52 -0700
    From:        Eliot Lear <[email-masked]>
    Message-ID:  <[email-masked]>

  | So long as you go with the rule that you select a source address based 
  | on the destination's scope, that all works.

Yes, as much as possible, that's what I do.

  | And in fact, if the ultimate decision is to keep SLs, this is an 
  | important point.  Sites end at administratively defined boundaries. 
  | It's almost like asking where one should put a firewall.  The answer is, 
  | of course, where one is needed.

Exactly.

  | What benefit, then, does IP version 6 provide you?

Me personally, almost nothing.   Or rather, only the intangible benefit
of having the internet continue to exist into the future, and be able
to sanely support future applications - all of which depends upon available
addresses for everyone.

But I have no idea what this question has to do with anything.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Apr 2003 16:29:44 +0700

Date:        Mon, 14 Apr 2003 09:10:31 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | This strikes me as a comment from someone who has not been following
  | this topic in detail.

Which I have already said is true.

  | There are _many_ in the community who disagree with the above statement.

I'm sure there are.   But many people disagreeing does not make a
consensus for a change.

  | Including folk that do applications for a
  | living and are concerned about the implications on individual
  | applications.  Consider, for example, how it only takes "trivial"
  | changes to ensure that an implementation/application that is running
  | in a multi-sited environment (e.g, a home user with SLs configured
  | locally who also has an IPsec tunnel back to their work enviornment,
  | which also uses SLs).

If you have read my (relatively few) messages over the past week or so,
you'll see that I agree that multi-site nodes are an extra complication.
We could abolish those if people are willing to give up the few cases
where they're actually useful.  Doing that would be far less intrusive
than abolishing site local completely.

But I still don't see what getting rid of SL really accomplishes there.

Those same apps need to deal with using LL addresses when nothing else
is available, and they need to be able to operate on nodes that have
attachments to multiple links where only LL addresses exist.

It seems to me that the problems there are just the same as the problems
with SLs that you imply.

So, are you proposing to do away with LLs, leaving only global addresses,
to make the application code writers job easier?   If not, then they're
going to have to cope anyway, aren't they?

Lastly however, my model of SL usage (which I admit hasn't been widely
distributed yet, though if you read all my messages, going back a long
time, on this topic, you'd probably guess easily enough) has only those
apps that actually want to use SL addresses ever actually seeing the
things.   An app (or its author) that doesn't want to have to deal with
SL addresses, will never see them (isolated sites that have only SL
addresses excepted, but in that environment, SL's are effectively global
and nothing really matters).

  | Please spend some time going through the extensive archive on this
  | topic.

I am going to do that.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Apr 2003 06:44:21 -0400

At 04:29 PM 4/15/2003 +0700, Robert Elz wrote:

Hi Robert,

>than abolishing site local completely.

The IPv6 WG has considered a few different models for accomplishing
this (the only documented ones are the "moderate" and "limited" models
that Bob Hinden and I document, respectively).  We haven't found any
model that realizes most of the benefits of site-local addresses that
doesn't cause serious complications for DNS, applications and/or
routing.

>attachments to multiple links where only LL addresses exist.

There is little/no belief that LLs will be included in the DNS, and
they aren't routed (so we skip any complications for DNS or routing
protocols).  Some apps just may not work properly in on a multi-link
node in a link-local-only environment...  but there are many apps
that it would not really make sense to run in this sort of environment.

>going to have to cope anyway, aren't they?

Applications should be able to treat all addresses that they ever see
as global addresses.  As you state, this works if you constrain the
use of site-locals to a single disconnected site and/or the use of
link-locals to a single disconnected link.  This was my "limited"
proposal.

>and nothing really matters).

If you want the IPv6 WG to consider your model, please document it.

Margaret

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Apr 2003 20:01:44 +0700

Date:        Tue, 15 Apr 2003 06:44:21 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | There is little/no belief that LLs will be included in the DNS,

I would hope that will be true of SL's as well (in both cases, with
the exception of the case where there is only one link/site, where
putting LL's/SL's in the (locally-rooted, as there is nothing else)
DNS might make sense (depending upon what other name resolution
mechanisms are available).   But any kind of local use only addresses
in the global DNS (whether they be 1918's, LL's, SL's, or some new
non-routed PI addressing) makes no sense.

  | and they aren't routed (so we skip any complications for DNS or routing
  | protocols).

Yes, once again, routing in mult-site nodes is the one extra complexity
for SLs.

  | Some apps just may not work properly in on a multi-link
  | node in a link-local-only environment...  but there are many apps
  | that it would not really make sense to run in this sort of environment.

Why is it reasonable, or even acceptable, to say this about LLs,
when the same statement could be made, just as well, about SLs,
but there it is, for some reason, unacceptable?

  | Applications should be able to treat all addresses that they ever see
  | as global addresses.

That's fine, if they don't care what works.   For many apps, the
difference is immaterial, and that's exactly what they would do.

For others though, more care is needed - if an app has two addresses
available, and needs to send one as a referral, it had better pick the
one that is going to work.   I appreciate that app writers would prefer
if they were both global addresses, so they can say "I have no way to
tell which will work, so all I can do is pick at random, and it is someone
else's fault if it doesn't work", whereas with SL addresses (or even
a /3 or something prefix for PI global addresses) that is no longer true,
and one address will be more likely to work (just from its appearance)
than another - so the app writer no longer has an excuse for not doing
the extra work.   And yes, it is extra work, no question about it.
But getting rid of SLs doesn't make that go away, as LLs still exist.

  | As you state, this works if you constrain the
  | use of site-locals to a single disconnected site and/or the use of
  | link-locals to a single disconnected link.

I have no intention whatever of adopting any such constraint.   That's
just the environment when allowing SLs (or LLs) to be treated identically
to globals works (including sticking them in the DNS, or anywhere else).

  | If you want the IPv6 WG to consider your model, please document it.

That will happen.   But I don't see any reason why there needs to be
one approved or blessed model necessarily.   Just leave SLs in 
the architecture (with the properties they currently have), and
they will get used.   If different people come up with different
strategies, that's just fine.

kre

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 15 Apr 2003 09:09:10 -0700

>> attachments to multiple links where only LL addresses exist.

I think Robert has a point here; no one is talking about doing away with
LL's, so apps will still need to deal with them. Perhaps the non-routable
aspect of LL's makes things less complicated than for SL's, however?

> that it would not really make sense to run in this sort of environment.

As to Margaret's point on multi-link nodes in a link-local-only environment,
if the multi-link nodes are populated with host routes that associate LL
destinations with links (or, if LL destinations can be associated with links
through on-demand route discovery) then apps should work fine. Ongoing work
in the MANET wg has considered this case; perhaps this is also falls within
the realm of the multi-link subnet specification?

Fred
[email-masked]

---

From: Mika Liljeberg <[email-masked]>
Date: 15 Apr 2003 19:35:46 +0300

> than abolishing site local completely.

Those "few cases" of multi-site nodes will include a few hundred million
3GPP terminals in a not so distant future. Wireless multi-access
terminals will be quite common, because people will want to combine wide
coverage with fast short range access (not to mention VPN).  Non-global
reachability is practically a given. Whether those terminals will use
local-scope addressing is another matter, but quite likely some of them
will.

	MikaL

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Apr 2003 19:14:41 +0300 (EEST)

> strategies, that's just fine.

"Just leaving SLs in the architecture" requires a *significant* effort in 
about all the aspects of routing protocols, apps, etc.

Who's going to do that work?  Is it worth the while of all the people 
involved?

I'd say NO.

That's why IMO the decision was to "deprecate" site locals.  Not eliminate
them.  Indeed, I personally use quite a few features that are in
"deprecated" status.  But if I happen to shoot myself in the foot by
accident, I can't blame anyone else: it has been made crystal clear what
the status of SL's should be.

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Apr 2003 01:36:53 +0700

Date:        Tue, 15 Apr 2003 09:09:10 -0700
    From:        "Fred L. Templin" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Perhaps the non-routable
  | aspect of LL's makes things less complicated than for SL's, however?

Routing is only complicated for SL's at multi-site nodes.   Anywhere else,
SL routing is identical to global routing - it is just another prefix
passed around (and filtered from being passed around at the site boundaries).
There's nothing special in that.

Multi-site nodes certainly make routing harder.   I don't write routing
implementations, so I'm not going to attempt to say if it is so much harder
that we'd really be better off without them in the architecture.   But that's
really the only aspect of SL's that routing should be influencing.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Apr 2003 01:50:37 +0700

Date:        Tue, 15 Apr 2003 19:14:41 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | "Just leaving SLs in the architecture" requires a *significant* effort in 
  | about all the aspects of routing protocols, apps, etc.
  | 
  | Who's going to do that work?  Is it worth the while of all the people 
  | involved?
  | 
  | I'd say NO.

Then just don't implement it.   We don't need to deprecate it for you to
not implement it.

If no-one really cares about SLs, then your users won't mind, and everyone
will be happy.   When we get to advance IPv6 to Internet Standard status,
if no-one is using (including obviously if many implementations haven't
bothered implementing) SL addresses, then the "significant implementation
and successful operational experience"  won't have been achieved, and the
SL part will have to be removed from the spec in order for it to advance.
(I suspect that SL has enough implementations to get to DS without problems).

This is all as it should be.

On the other hand, if the users really do want the functionality offered
by site locals, then if the IETF deprecates them, when the users come to you
complaining that your implementation is lacking them, you're just going to
say "there's nothing like that in the current IETF standards, so there's
nothing I can do about it" and the users will have no real options.

On the other hand if the users want the thing, and it is still in the spec,
and you just haven't bothered to implement it, because you regard it as
unnecessary, too difficult, broken, ... then when the users come to you and
ask why, you get to try and convince them you're right.   If you do, fine.
If not, your implementation gets a reputation as deficient, and fewer users
use it.

Again, that's all as it should be.

So, just have the courage of your convictions.   If you think it is useless,
unnecessary, or broken, just don't implement it.   There's no need to
need the rest of the IETF to agree to you (or seem to agree with you) before
taking that action.

  | That's why IMO the decision was to "deprecate" site locals.  Not eliminate
  | them.  Indeed, I personally use quite a few features that are in
  | "deprecated" status.

For some things that's entirely reasonable.   For example, RIP (v1 anyway)
is deprecated, but lots of people still use it.   There are two cases where
that works - first where the deprecated thing has been in wide use, but has
been replaced by something better - (RIP, SNMPv1 ...) - there the 
implementations all exist, for users who know what they're doing (or don't)
there's no real difficulty using the thing.   The other case is where only
peer nodes under some degree of common control need to do anything at all
to use something that's been deprecated.

But for something which has not yet been out there long enough, or been
implemented all that much, and which requires fairly general implementation
to be useful at all, deprecation is equivalent to outlawing.   It just gets
forgotten - often without any real experience to show that it wouldn't
have worked, just fear of too much work on the part of some implementors.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Apr 2003 01:55:47 +0700

Date:        15 Apr 2003 19:35:46 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1050424546.22241.73.camel@devil>

  | Those "few cases" of multi-site nodes will include a few hundred million
  | 3GPP terminals in a not so distant future.

You're considering objects I don't know much about, so could you explain
why they need to be multi-site?

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Apr 2003 22:17:55 +0300 (EEST)

> nothing I can do about it" and the users will have no real options.

I'm not sure if I agree with your point here btw.  The documents which 
contained SL's still exists: the knowledge to implement them has not been 
lost.  Indeed, deprecating them is the real test for the users and 
implementers: if they are really needed, the support stays.  Otherwise 
it's removed.  And if someone really needs the implementation to have the 
support, they must convince the vendor they're useful.
 
> need the rest of the IETF to agree to you (or seem to agree with you) before

You miss my point completely.

I'm worried about the specification complexity.  Implementation complexity 
is important of course, but was not the point here.

Why waste the cycles of the vast majority of the IETF folks by specifying
the details of SL's everywhere?  Of course, you could just handwave them
away everywhere ("use with site-local addresses is out of scope"), but
that would not seem to be responsible behaviour at all.

We need to ensure no significant amount of *IETF* work is wasted on making 
site-locals "work".  The easiest way to do that seems to be "deprecating" 
them.

---

From: Mike Saywell <[email-masked]>
Date: Tue, 15 Apr 2003 20:55:54 +0100

> site-locals "work".  The easiest way to do that seems to be "deprecating" 

It seems to me that most of the people who want to keep site-locals
only require the address space and not any special handling of scope.
Whilst the people that want to get rid of them are mainly concerned
about the problems scoping implies.

So can we not simply deprecate the scoping side of things but leave the
allocation intact?  Perhaps renaming it as being reserved for experimental
and disconnected networks only...

Yes there are issues when sites merge etc, but they *can* use global
addresses, if they've chosen not too then they're making life much
harder for themselves and they deserve the pain ;)

Ad-hoc networks and other minority cases such as community networks may
not have the luxury of obtaining the necessary global address space,
so they need some prefix to communicate, but nothing more.

Cheers,

Mike

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Apr 2003 16:48:59 -0400

>and disconnected networks only...

I would be concerned about doing this because some implementation
already have special handling for the "scoped" nature of site-locals.

For disconnected networks, you ideally want to use prefixes that will
be treated exactly like globals (they are global to the attached
network), so you wouldn't want to use a prefix for which there may
already be special handling due to its scoped nature, would you?

I agree.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Apr 2003 16:51:52 -0400

>so they need some prefix to communicate, but nothing more.

It would be hard for me to disagree with you, because this is exactly
what I proposed in my "limited" model...

However, people have convinced me that there are already implementations
that include special handling for the FECO::/10 prefix, based on the
assumption that it is "scoped" (as defined in the scoped addressing
architecture).  What you really want for disconnected sites is a local
prefix that will be treated exactly like a global prefix (since it is
global to the attached network), so there may be a conflict between
implementations that treat site-local specially and the needs of
a disconnected network.

Margaret

---

From: Mika Liljeberg <[email-masked]>
Date: 16 Apr 2003 01:30:44 +0300

> why they need to be multi-site?

Well, the why of it is a good question, and I'm probably not the best
person to answer it, but I'll give it a go anyway. The roots of this
thinking are deep in the telecoms world. Basically, 3GPP views packet
data as a bearer service that carries packets between two access points.

For simplicity, you could think of the bearer service as a tunnel
between the mobile terminal and some remote gateway, which provides
access to a service or to a network. Naturally, operators and service
providers want to charge differently for different services, so a clear
separation is required. The terminal gets an IP address from the gateway
as part of the tunnel setup procedure (called PDP context activation).
This means that, as soon as the terminal activates more than one packet
data service, it automatically becomes multi-site (assuming the gateways
for the services belong to different sites).

The mobile might also have access to circuit switched data services. Add
to that VPN or a short range radio like Bluetooth or 802.11 and you have
yet more opportunities to become multi-site. Mobile devices are simply
primed for this, so I wouldn't assume multi-site nodes will be rare.

	MikaL

---

From: Hans Kruse <[email-masked]>
Date: Tue, 15 Apr 2003 17:18:14 -0400

Yup, that would seem to make sense.

Hijacked prefixes create problems for the _rest of the network_ when the 
admin of the disconnected site does the wrong thing (connect without 
proper/complete renumbering, filtering, etc).  So, we need a recognizable 
prefix for non-provider based addresses so the rest of the net can protect 
itself.

If the address space is identified, then scoped link locals could go to 
experimental (forgive me if that is procedurally not possible) or be 
deprecated, and the WG can start work on solving some of the issues raised 
(globally unique PI space, intermittent connections, etc).

> so they need some prefix to communicate, but nothing more.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: Derek Fawcus <[email-masked]>
Date: Wed, 16 Apr 2003 11:14:53 +0100

> so they need some prefix to communicate, but nothing more.

I didn't bother patticipating in the consensus call (forgot),  but if I
had it would have been to vote no.

I've previously given my thoughts on this (during the previous round of
"let's fill SL"),  which were that as a user I wanted them,  but as an
implementor I could do without them.

As a user my only need for them is to have a bunch of address space tha
I could allocate from without having to coordinate with any RIR,  and
I'de like that to be a significant chunk of address space.

As an implementor,  the only real pain caused by SL (in forwarding) is
that it effectivly requires multiple FIBs (or a scoped FIB),  which can
cause wonderful issues depending upon the router architecture.  There
are also issues at the routing level.  The scope check when forwarding
is a non issue,  as it has to be done for LL anyway.

So if we had a bunch of address space (say FE40::/10) reserved in the
architecture that was for private allocation (without the scope / multi
site features) I be happy to deprecate (for almost any definition of
deprecate) SL addresses.

I'd say that this new address block be treated like global unicast by
all systems/apps,  but that if one wanted to use it,  then it was at one's
own risk - you have to handle any issues that arise.  This would still
mean that the addresses are ambiguous,  but then that's the user's
problem for chosing to use them.  If this ambiguity doesn't cause any
issues for their application,  then fair enougth.

I would not limit the use of these addresses to any particular scenario.
I would allow them to be used when one also (potentially) had
proper assigned global unicasts.  This would (for example) allow one
to use these addresses for say transit and internal connectivity within
a community wireless network,  with end nodes potentially having bits
of global unicast space handed on to them if/when they wanted to reach
the wider internet.

I'd not require any filtering requirements on the addresses,  but in
operational terms anyone using them would probably want to do some
filtering.  Likewise ISPs would probably want to drop packets using
such addresses.

We could also then simply the default address selection rules to be
longest match (assuming SL deprecated).

(How about reserving FE00::/8 for various 'ambigous' addresses?)

DF

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Apr 2003 13:44:47 +0300 (EEST)

I've put these two threads back separately because they deal with separate 
issues -- and it's easier for the rest to keep up.

On Wed, 16 Apr 2003, Robert Elz wrote:
> In another message [email-masked] said:
>   | You miss my point completely.
>   | I'm worried about the specification complexity.  Implementation complexity
>   | is important of course, but was not the point here. 
> 
> Specification complexity of SL is almost zero.

At the *moment*, yes.

>   It has been that way for
> ages.  

Because it has never been properly specified.

> And implementations were using it regardless.   What's more the
> degree of specification was just about perfect for this.   The aim and
> basic rules were there, and that was it.   Enough to work out what needed
> to be accomplished.

For basic stuff like the scope and address selection -- I'd maybe agree.  
But routing protocols, for example?  Definitely not.
 
> With that, implementors can go and try different ways of actually using
> the things, documenting the results along the way for the benefit of others.

I haven't seen much documentation yet -- the only thing has been Brian 
Haberman's experiences of prototype implementation with routing protocols.
 
>   | We need to ensure no significant amount of *IETF* work is wasted on making
>   | site-locals "work".  The easiest way to do that seems to be "deprecating"
>   | them.
> 
> There's been far more IETF work spent (it seems to me) in the past few
> months on the attempt to deprecate site locals than was ever spent on their
> specification, or on making them work.   This hardly seems to have been *easy*.

"ever spent" -- maybe yes.

And that's the whole problem: a nice concept which doesn't seem to fly
except in some certain scenarios.  Currently, it's out there.  When specs 
are written, at the moment, SL's must be taken into consideration in their 
fullest form.  Any other action would seem irresponsible.

"To be spent to be specify them properly" -- definitely not, as seen 
above.

> All that was needed was to do nothing, and see what happens.
> 
> That's still all that is needed.

I totally disagree here.

Let's see.  From here, we might have an analogue:

 * we know Internet can be an nasty place from the security point of view
-- however, there are likely some intranets which are actually pretty
nice.

Is it OK to just say "Security considerations are outside of the scope of
this memo." and leave it at that in all specs, whether related to
Internet, intranets or whatever else?

---

From: Thomas Narten <[email-masked]>
Date: Wed, 16 Apr 2003 07:13:24 -0400

> is required to support that.

I think it is naive to believe that implementing SLs can truly be
optional and only impacts those that chose to implement/use them. If
they get widely used, implementations will be forced to deal with the
consequences, including those that specifically didn't want to do
anything special with SLs.

From a previous posting:

Thomas Narten <[email-masked]> writes:

> Having said that, one of the great difficulties I have with SLs is
> that I don't see a viable "compromise" or "middle ground". Every
> proposal I have looked at either uses SLs in very restricted settings
> (e.g, disconnected sites), or ends up having to implement the full
> blown "multi-sited node" (even though try to claim otherwise). I find
> scenarios that argue for a middle ground to be an unworkable illusion.

> Consider a bottom line. If we say SL addresses are a reasonable thing
> for (say) home networks doing autoconfig, and so on, the reality will
> be that SOHO routers will find ways of creating zeroconf environments
> that enable SL by default. They will then be used in practice in huge
> numbers of home networks. Corporations will likewise be tempted to use
> them, since they seem to provide "permanent" addresses, and
> "stability" across renumbering. So, we have situation not unlike being
> half-pregnant.  In practice, SLs will become widely used in many
> organizations.

> But, once you have wide usage in terms of independent networks
> numbered using SLs, you have the inevitable problem of what happens if
> a node is in two sites at the same time. I don't buy the argument that
> this won't happen much and that the market can fill the gap if there
> is a need (and the IETF thus won't need to do this). If widespread
> useage of SL in networks becomes the reality, devices will be forced
> to work in those enviornments. One simple example: at home, I have my
> home network with a DSL link to the internet and also a VPN connection
> to my corporate intranet. This is a *very* common operating
> configuration. (Does anyone believe this won't be a common
> environment?) If both the home and corporate network use SL addressing
> (as they will in practice), things just won't work right unless nodes
> implement the multi-sited node architecture.

> Thus, I continue to come to the conclusion that we can't have it both
> ways. We either deprecate SLs, or we do the full blown multi-sited
> node. Doing anything in between will not work well enough in practice
> (i.e., is equivalent to us putting our heads in the sand) and will
> lead to interoperability problems, failed communications, and a less
> robust Internet. Exactly the opposite of what I believe IPv6 is all
> about.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 16 Apr 2003 07:22:08 -0400

> It seems to me that the problems there are just the same as the problems

In theory, the problems are similar, in practice, I think not. I.e.,
the difficulties can be contained for LLs much more easily than with
SLs.

Differences include:

- LLs are useful for boostrapping; that is what people seem to say
  they will be used for. Folk aren't arguing that LLs be used to keep
  connections stable across renumbering, or for numbering their
  internal links in a PI manner.

- LLs will almost certainly not be in the DNS, whereas SLs will (how
  else can applications find them and use them?)

- Using LLs as a last resort is generally fine; implementations can
  almost pretend they don't exists unless there are no other addresses
  (e.g., via address selection rules). But one of the goals people
  have for SLs is that their usage is preferred over globals (when
  possible).

- Single link environments aren't going to be the norm, thus global
  addresses will be needed to reach off-link destinations. In those
  environments, LLs only need to be used in limited settings. I don't
  see the desirably or need for a node being in multiple "sites", if
  it only has LL addresses. But this is certainly what will happen if
  SLs are used.

It is the need to implement full multi-sitedness that brings the full
complexity into the picture. So far, the notion that one can get the
benefts of SL without also implying a need to implement the full
multi-sited node mode has been unconvincing.
  
> going to have to cope anyway, aren't they?

Nodes/applications can treat LLs as if they were global addresses in
most cases without it causing a lot of problems. They don't need to
special case for them (except for applications that use LLs as part of
the protocol -- but that is a minimal set). Treating SLs as if they
were global will lead to things not working correctly in practice
(e.g, the multi-sited node example).

> things.

Your model is different than the model others have and are pushing
when they say "keep SLs". There are some who argue that an important
benefit of SLs is that they can keep connections stable across
renumbering events. That is largely at odds with the  idea that only
apps that care about SLs will use them and or have to know about
them.

Or, what if you connect to a site that has SLs in the DNS (because
that is what the site has chosen to do)? Maybe the application  never
wanted to deal with this case, bit it has no been forced to.

Thomas

---

From: Andrew White <[email-masked]>
Date: Thu, 17 Apr 2003 13:53:54 +1000

> apps that care about SLs will use them and or have to know about

I don't see it this way.

IMO, desirable default behaviour is to use site locals iff they exist (see
RFC3484, section 6, rules 2, 8, 9).  In fact, use the smallest relevant
scope (based on whatever destination ID (eg hostname) you are using).  Given
this, work your way up the destination list until something works.

This works for "most" applications regardless of scopes, filters, or site
locals.

So, name -> address resolvers or similar systems will need to know about
address scopes so they can implement source address selection.  Most
applications can remain blissfully ignorant and simply try addresses in the
order given until one works or they all fail, without considering scope.

The applications that will have problems are those that intend to forward
addresses (not just names) in a manner that might cross scope boundaries. 
Such applications need much more complex address selection rules, since they
need to choose addresses that will work across the entire mesh, not just
point-to-point.

For such applications, the difference between a site local address and a
"global" address is that the site local promises that it is scoped.  The
global may have global scope, or may be filtered.  Recovery code is needed
in either case - SLs have the advantage that they can be discarded a-priori,
since using an SL to a machine with only a global can be reasonably expected
to break.

-- 
Andrew White                [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Apr 2003 16:18:18 +0700

Date:        16 Apr 2003 01:30:44 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1050445842.22244.576.camel@devil>

  | The terminal gets an IP address from the gateway
  | as part of the tunnel setup procedure (called PDP context activation).
  | This means that, as soon as the terminal activates more than one packet
  | data service, it automatically becomes multi-site (assuming the gateways
  | for the services belong to different sites).

Huh?   I'm still mis-understanding something.   Why would I want my terminal
(phone) to be a member of either (any) of the sites that are relevant to the
gateways?

  | The mobile might also have access to circuit switched data services. Add
  | to that VPN or a short range radio like Bluetooth or 802.11 and you have

Sure, if I have a bunch of local attached devices, I'm likely to want all
of them, and the handset, to be in the same site.   But I'm still not sure
why I'd want them to be in a site connected to any service provider.

I suspect that you're assuming that all links have to be in some site or
other - they don't - siteless links are entirely possible (and in the IPv6
world as it exists right now, are probably the most common around).

Sites (as in the usage of the term in site local addressing) are an 
administrative concept - multi-site nodes only really make sense when
a node is controlled by multiple administrations (and some similar cases
where a link wants to be in a site, where the attached nodes are controlled
by multiple administrations, because links can't be in multiple sites).

kre

---

From: Mike Saywell <[email-masked]>
Date: Thu, 17 Apr 2003 10:22:43 +0100

On Tue, Apr 15, 2003 at 04:51:52PM -0400, Margaret Wasserman wrote:
> architecture).

Hmm, hence the C000::/3 proposal I suppose.

Well I'd vote "YES" for either, I think it's the best middle-ground
we're likely to find...

Cheers,

Mike

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Apr 2003 16:41:38 +0700

Date:        Wed, 16 Apr 2003 13:44:47 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let's see.  From here, we might have an analogue:
  | 
  |  * we know Internet can be an nasty place from the security point of view
  | -- however, there are likely some intranets which are actually pretty
  | nice.

Hmm - interesting example.   I'd veen considering writing a draft
deprecating the AH and ESP headers.

All the arguments I've seen (with trivial rearrangements) for deprecating
site local addresses apply.

They're not much used, there are problems with key distribution that aren't
yet specified, issues of authenticity, ...   And in practice TLS (SSL)
accomplishes all that's really needed, and it is widely deployed.

So, should we go ahead with that?

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Apr 2003 17:03:44 +0700

Date:        Wed, 16 Apr 2003 07:13:24 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think it is naive to believe that implementing SLs can truly be
  | optional and only impacts those that chose to implement/use them. If
  | they get widely used, implementations will be forced to deal with the
  | consequences, including those that specifically didn't want to do
  | anything special with SLs.

Of course.   There's no surprise there.   But that's if they get widely
used.   If they're not used much at all, then implementations will largely
be able to ignore them, right?

So, your argument seems to be that you want to deprecate site locals because
you're afraid they'll get used.    That's novel.

  | > So, we have situation not unlike being
  | > half-pregnant.  In practice, SLs will become widely used in many
  | > organizations.

I would hope that's what will happen, yes.

  | > But, once you have wide usage in terms of independent networks
  | > numbered using SLs, you have the inevitable problem of what happens if
  | > a node is in two sites at the same time.

Why?   If that was simply made impossible, then the node would have to
choose which site it wanted to be in.   Some might curse the restriction,
but people would adapt (and/or implementations would adapt - just as
some RIPv1 implementations managed to handle multiple subnet masks on
a network they were routing, something which is apparently impossible to
achieve using RIPv1).

  | One simple example: at home, I have my
  | > home network with a DSL link to the internet and also a VPN connection
  | > to my corporate intranet. This is a *very* common operating
  | > configuration. (Does anyone believe this won't be a common
  | > environment?) If both the home and corporate network use SL addressing
  | > (as they will in practice), things just won't work right unless nodes
  | > implement the multi-sited node architecture.

Huh?   The multi-site architecture that's currently proposed can't
deal with that - only a node can be in multiple sites, not a link.
To do what you're describing, your home lan would want to be in two
sites, and site locals just can't deal with that.

For me, I'd just be a part of my corporate lan's site (I'm not in
the slightest bit interested in being part of some random ISP's site,
even if they'd allow me).   Being "part of the site" just means
integrating addressing.   That will already be being done for the
corporation's global addressing (I'll have a piece of that for my
home use) - I'd expect to just get the equivalent piece of their
site local addressing.

This works just fine for me (and I guess you) - at home I'm never going
to want an entire /48 (as in, consume the whole thing), so however
I get my addressing I'm only going to be using a small part.   The actual
numbers I use for my subnet numbers are irrelevant.

But even if that isn't possible, and the corporation won't give me any
addresses at all (global or site-local) I can still be part of the same
site just by picking a different value for the upper 38 "used to be 0"
bits in the site-local address, and not configuring boundaries.
As long as the values are different, as many nets as want can be
connected together that way.

You don't have to configure boundaries - so you don't have to have
different sites.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Apr 2003 17:40:51 +0700

Date:        Wed, 16 Apr 2003 07:22:08 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | In theory, the problems are similar, in practice, I think not. I.e.,
  | the difficulties can be contained for LLs much more easily than with
  | SLs.
  | 
  | Differences include:
  | 
  | - LLs are useful for boostrapping; that is what people seem to say
  |   they will be used for.

That is one of their important uses.

  | Folk aren't arguing that LLs be used to keep connections stable
  | across renumbering,

Aren't they?   I thought that was exactly why BGP+ uses LL addresses
over a tunnel for its peer-peer connectivity?

I also see no reason that connections that are on a link shouldn't use
LL addresses, even in preference to SL.   Certainly if SL addresses
go away that's what I'll be doing, there will be no other option, it
will just offer much reduced functionality.   Or course, the other option
(I suppose) will be NATv6 and stable internal addressing (the same as
is done now for v4).

  | or for numbering their internal links in a PI manner.

Of course they are - but this is easy, as we get a prefix, and how
we sub-divide it is irrelevant to the provider.  That is, we already
get PI stable internal numbering, so we don't have to deal with any
of this.

If you can make stable PI global addressing work, that will be fine,
and better than SL addresses.   Go for it.   Just leave SL alone as it
is until you're finished.

It won't actually solve almost any of the hard problems that SL's (and LL's)
create - unless your PI global addressing is also globally routable of
course - that is, there will still be addresses that don't work, and
will never work.   Routing would get easier, but just abandoning multi-site
nodes would achieve that (routing wins because LLs aren't routed,
forwarding still needs to handle scoped addresses).

  | - LLs will almost certainly not be in the DNS, whereas SLs will (how
  |   else can applications find them and use them?)

SLs should certainly not be in the DNS (non-connected sites excepted).
And there are ways.

There's certainly no particular reason for putting a SL in the DNS
that doesn't apply equally to LL addresses.  It may be that LL will
be less common (as long as SL remain) as there won't be as much need
to ever know an LL address, but if SL goes away (before being replaced
by something better of course), then LL will be the only stable addresses
that remain, and I'd both expect, and actually use, the things in just
the way I'm advocating that SL's be used (which in my case isn't in the
DNS, but for others, might be).

  | - Using LLs as a last resort is generally fine; implementations can
  |   almost pretend they don't exists unless there are no other addresses
  |   (e.g., via address selection rules). But one of the goals people
  |   have for SLs is that their usage is preferred over globals (when
  |   possible).

Yes.   There are advantages to using LL's (in preference even to SL's)
when they're applicable as well.   I see no reason that shouldn't be done.

  | - Single link environments aren't going to be the norm, thus global
  |   addresses will be needed to reach off-link destinations. In those
  |   environments, LLs only need to be used in limited settings. I don't
  |   see the desirably or need for a node being in multiple "sites", if
  |   it only has LL addresses.

What you've just said, once you translate it into the correct terminology
is that you don't see a need for nodes to be connected to multiple links.

Nonsense.

And LL addresses still will be used, on nodes connected to multiple links
(which is the LL equivalent of a node connected to multiple sites in the
SL case).   And applications need to deal with that.

  | It is the need to implement full multi-sitedness that brings the full
  | complexity into the picture.

yes, it does.   But that's already needed for multiple links, and LLs,
and I don't think you can just wish those away.

Nor do I take any notice of proclamations that "they're not meant to
be used that way" - if they can be, they will be.

  | So far, the notion that one can get the
  | benefts of SL without also implying a need to implement the full
  | multi-sited node mode has been unconvincing.

Your concept of what is a multi-site node seems to be deficient, based upon
your analysis in the other message I just replied to.

The true need for multi-site nodes is really very rare.   While I have
played with such things, just for fun, I have not yet seen a true operating
environment where they're needed (but I also don't hang about exchange points,
which was the motivation for including them).

  | Nodes/applications can treat LLs as if they were global addresses in
  | most cases without it causing a lot of problems. They don't need to
  | special case for them (except for applications that use LLs as part of
  | the protocol -- but that is a minimal set). Treating SLs as if they
  | were global will lead to things not working correctly in practice
  | (e.g, the multi-sited node example).

This is utter nonsense.   LL's are scoped addresses, with even more
restricted scopes, than SL's.

If you're willing to "just treat an LL as if it was a global" then you
can most certainly do exactly the same to a SL address.   That will
cause far fewer problems.

  | Your model is different than the model others have and are pushing
  | when they say "keep SLs".

Yes.

  | There are some who argue that an important
  | benefit of SLs is that they can keep connections stable across
  | renumbering events.

That includes me.

  | That is largely at odds with the  idea that only
  | apps that care about SLs will use them and or have to know about
  | them.

Nonsense.   Only apps that both use long time connections (ones that
would expect to last at least as long as address overlap during a
renumbering - which some people have said should be months, but even
an hour is enough) and which can't easily recover from broken connections,
care about address stability.

That is, my web browser doesn't (other than perhaps if it keeps its
proxy config using address to avoid DNS lookups for it every query,
a topic on which I know nothing) - as web connections don't last for
hours (more likel seconds, perhaps minutes).   SMTP connections just
the same - and if the connection does break, the SMTP client/server
will simply retry (using the new addresses next time).

On the other hand, I want my ssh sessions, my NFS mounts, etc, to
remain viable for years.   Those I don't want touched by address
alterations (or not ones over which I have no direct control).

Or, to put this another way, only ssh and NFS (and a few more like
them) really need to deal with SL addresses, everything else can
just use globals.

  | Or, what if you connect to a site that has SLs in the DNS (because
  | that is what the site has chosen to do)? Maybe the application  never
  | wanted to deal with this case, bit it has no been forced to.

And what if you want to connect to a site that has LLs in the DNS
(because that is what the site has chosen to do)?   Or in the IPv4
world, what if you connect to a site that has 1918 addresses in the
DNS (because that is what the site has chosen to do)?  Maybe the application
never wanted to deal with this case, but it has no been forced to.

So what?

Things don't work if people put bad addresses in the DNS.   Have you
really never come across something that has 127.0.0.1 in the DNS and
wondered why you couldn't connect to it?   Try a connection to
localhost.cs.mu.oz.au see what happens?   I'd guess that localhost.xxx
for lots of other xxx's would do just the same.

It isn't SLs that cause this problem.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Apr 2003 21:41:11 +0300

> (phone) to be a member of either (any) of the sites that are relevant to the

Well, as a subscriber you only get to choose whether you want to use
particular services, such as "WAP", "Multimedia Messaging" or
"Internet". Each of these "PDP contexts" is effectively a tunnel leading
to a (potentially) different network. The terminal gets an IP address
from each network. Some of these networks may use private addressing.
I.e., a single host is either connected to multiple networks or
connected to the same network in multiple points of the topology (or
even both).

I'm merely trying to explain how packet data services are organized in
the 3GPP architecture. I'm not trying to defend the architecture itself
(as I said, I'm probably not the right person for that).

If you'd like to know more about the architecture, I refer you to
www.3gpp.org.

> why I'd want them to be in a site connected to any service provider.

I wasn't talking about local attached devices.

I'll give you an example. You can have constant wide-area wireless
Internet connectivity via GPRS. Your operator charges by amount of
transferred data, so you would also like to use 802.11 WLAN to connect
to Internet whenever you're in a WLAN hotspot (to save money and to get
better bandwidth).

So, you have one (or more) addresses via your GPRS (3GPP) access, and an
intermittent one via WLAN (changing depending on your point of
attachment).

> world as it exists right now, are probably the most common around).

You could argue that all siteless links of the same scope form a site
amongst themselves. That's how it works out in the implementation,
anyway. There's no special site zone id reserved for "siteless".

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 09:05:57 -0700

Margaret Wasserman wrote:
> ...
> Applications should be able to treat all addresses that they 
> ever see as global addresses.  ...

Continuing to ignore the reality that filtering creates addresses with a
local scope of applicability only insures that applications can't make a
valid choice when confronted with a real network. 

The presumption that the scoped addressing document can proceed without
discusssing local scope addresses is invalid because that would only
present a wishful view of a flat network. Any document that ignores the
most common case network is absolutely useless outside the IETF, and not
worth publishing. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 09:05:57 -0700

> It isn't SLs that cause this problem.

You are right, it is the mismatch of the fantisy of a single scope
address space, confronted with the reality of the deployed network which
creates limited scope addresses through filtering. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 09:05:57 -0700

Keith Moore wrote:
> No, it's inappropriate for an application to make assumptions 
> about the security properties of the links over which its 
> traffic will be routed. If the content is potentially 
> sensitive, the traffic should be encrypted by the application.

So you have a magic solution to the key distribution problem? If not
stop the FUD.

> After several years of trying, the people who want to keep SL 
> have failed to meet the burden of demonstrating how it can 
> work reasonably. 

The shipping code would appear to show how it works. The fact that
'ignorant' apps have a problem when they blindly pass information
outside its scope of relevance is not a problem caused by SL, nor are
they resolved by attempts to remove SL.

> Keeping SL under these circumstances is 
> irresponsible, a violation of our processes, and serves only 
> to ensure that IPv6 will be nearly useless.

The violation of the process is an ill-considered attempt to declare an
architecture that differs from the reality of the deployed network. 

> 
> > I have no doubt that simply having this debate will cause many to 
> it's entirely because of this debate that IPv6 might actually 
> become viable.

Shipping code wouhd say otherwise.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 18 Apr 2003 12:34:37 -0400

>valid choice when confronted with a real network.

No...  I am accepting the fact that any address (whether
it appears to be global or local) may be unreachable, so
applications already need to deal appropriately with unreachable
global addresses.

You seem to be ignoring the fact that firewalls will be used
to filter address/port combinations for all addresses, so
we can't guarantee that an address is global reachable, just
because we know it is a global address.

And, just because you know that you can reach a particular
address at one port, doesn't indicate that you can reach it at
another.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Fri, 18 Apr 2003 14:10:08 -0400

> So you have a magic solution to the key distribution problem? If not

even unsecured Diffie-Hellman would be more secure than trusting
a network of any significant size to be physically secure and expecting
apps to be aware of that aspect of the topology.  

and if you look for a single solution to key distribution, of course
you'll never find one. different applications and different sites have
widely different needs. but for the vast majority of cases off the shelf
solutions are available that are both more flexible and more reliable
than what you are proposing.

> The shipping code would appear to show how it works.

where in the world did you get the idea that the fact that something is
shipping means that it works well?  or for that matter, the idea
that "if our apps work, then the network must be okay"  from Microsoft?

> The fact that

SL creates a myriad of problems.  Trying to claim that they're someone
else's problems is disingeneous.  The people who have to deal with the
problems you're trying to foist on them are now telling you where to
stick those problems.  Hint: it's not in the IPv6 architecture.

> The violation of the process is an ill-considered attempt to declare
> an architecture that differs from the reality of the deployed network.

the only process violation that has occured was allowing IPv6 to go to
Proposed with site-locals in the first place, when we knew or should
have known that there were serious technical omissions with respect to
scoped addresses.  but finally we're getting around to fixing that.

> Shipping code wouhd say otherwise.

the amount of code that is shipping now is a drop in the bucket.  

Keith

---

From: Robert Elz <[email-masked]>
Date: Sat, 19 Apr 2003 03:08:39 +0700

Date:        17 Apr 2003 21:41:11 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1050604871.2893.199.camel@devil>

  | Well, as a subscriber you only get to choose whether you want to use
  | particular services, such as "WAP", "Multimedia Messaging" or
  | "Internet". Each of these "PDP contexts" is effectively a tunnel leading
  | to a (potentially) different network. The terminal gets an IP address
  | from each network. Some of these networks may use private addressing.

All this is fine.   But why would my node want to be in the same site as
any of those?   Once again, sites are administrative things, you're only
in one when you want to be.   (In this case, as an embedded device, I assume
the handset manufacturer would be making that decision for me, and while
they could decide to implement a multi-site node, and make the handset be
a member of all of those sites, I can't think of any reason they'd bother,
and I as a consumer certainly wouldn't feel short changed if they don't.)

  | I wasn't talking about local attached devices.

OK, I misunderstood (this really isn't my area...)

  | So, you have one (or more) addresses via your GPRS (3GPP) access, and an
  | intermittent one via WLAN (changing depending on your point of
  | attachment).

Sure, but they're just service providers, they have their sites for
their nodes, and I have mine for my nodes, why would we want to mingle?

  | You could argue that all siteless links of the same scope form a site
  | amongst themselves. That's how it works out in the implementation,
  | anyway. There's no special site zone id reserved for "siteless".

Hmm...

I wouldn't have replied at all to your message (nothing I have said above
is really very important or new) - but it seems to me that this is a very
important point.

I had a similar (brief) exchange off line with Erik Nordmark on this
general issue (off-line because of stupid mailer issues which contrived to
delete the list address from one of my messages, not intentionally).

But this seems in some way to be important when considering site local, and
it is something that I had never considered, and perhaps which does need to
be considered.

It seems that there's some expectation out there that (assuming site
local addressing remains) every link is a member of some site or other.

I have no idea where that comes from, nothing I have ever read suggests that
to me.

Site local addresses are a prefix like any other, if you don't have a site
local address (on an interface) then you're not a member of any site (on
that interface) is the way I interpret things.

This is just like global prefixes - if you don't have a global prefix (on
some interface) then you're not a member of that network (the network of all
nodes with the same prefix - of whatever prefix length is being considered).

Regardless of site local staying in the architecture or not, no-one is
or could be compelled to use site local addressing, or to form a site.

Links that aren't members of any sites I expect to be very common (whether
they're the majority of links, or just common between sites doesn't matter,
but common they're likely to be).

It may be that this should be clarified in the architecture.

Note that there doesn't need to be a special scope id for "no site", if
there's no site local address (on an interface) that interface is not in
any site.

Normal practice, of course, will be for routers to advertise site local
prefixes in RA's just as they do global prefixes, and for nodes to 
auto-configure site local addresses, just as they do globals, so the usual
thing would be for all the nodes attached to a lan to be in a site, but
with no expectation that would be enforced anyhow (I ought to be able to
take my portable system to some random net, connect, get a global prefix,
but ignore site local, because of not intending to ever be a part of that
site).

I'm not sure how much this alters anyone's perceptions of site local
usage, but I am surprised to see people believing that a "site" is something
that everything is required to be in - I'd certainly like to know from
where that perception arises.

kre
necess

---

From: Mika Liljeberg <[email-masked]>
Date: 19 Apr 2003 00:53:48 +0300

> that interface) is the way I interpret things.

I think that you just have a fairly narrow definition of what the term
"site" means.

I was using "site" loosely to refer to an administrative domain that
might naturally (although not necessarily) map to a single zone of
site-local scope, if the network administrator chose to use site-local
addressing. I think most people can envision a "site" without involving
site-local addressing. My apologies if my inexact use of the language
confuses people.

> nodes with the same prefix - of whatever prefix length is being considered).

This is true for host interfaces but not necessarily router interfaces.

> there's no site local address (on an interface) that interface is not in

Let's be careful here. A link belongs to a site if it carries packets
with site local addresses. That doesn't mean the link has to have a
site-local prefix for address auto-configuration.

> but ignore site local, because of not intending to ever be a part of that

Yes, fine. In the 3GPP example, you become part of a site by the
concious decision to use a particular service. This implies activating
the relavant PDP context and configuring the addresses that are
advertised. As a user of a phone, you generally don't get to pick and
choose which prefixes you accept.

> where that perception arises.

I never envisioned everyone using site-local addressing, but I've been
using the term "site" long before there ever was site-local addressing
and I certainly don't limit the word to that context. As I said in my
first message, whether any of those 3GPP services will actually use
site-local addressing is another matter, but probably some of them will.

	MikaL