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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:53:49 -0400

with all due respect. rfc 1918 was a hack and never would pass the IESG today IMO they are doing a far better job these days causing us to detail our network views and development of protocols.  1918 has wrecked the Internet.
/jim

> -----Original Message-----
> From: Steven M. Bellovin [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 10:17 AM
> To: Pekka Savola
> Cc: Ralph Droms; [email-masked]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols 
> 
> 
> In message 
> <[email-masked]>, Pekka Savola 
> writes:
> >On Sun, 9 Jun 2002, Ralph Droms wrote:
> >> problem.  A router can't know when it's forwarding a 
> packet outside of a 
> >> site unless it's been configured with information about 
> site borders.  So 
> >> network architects and admins have to define what makes up 
> sites and 
> >> configure the routers at the borders to know about those site 
> >> borders.  And, I don't think there's a good way to define 
> default behavior 
> >> or auto-discovery for site-local addressing...
> >
> >Precisely.
> 
> Yup -- and now we're elevating it to an architectural principle.
> > 
> >> I don't see much difference between RFC 1918 addresses and 
> site-local 
> >> addresses in the areas of network design and deployment...
> >
> >Me neither.  More probable outcome is that someone starts to 
> request that
> >people implement NATv6, because 1) they're already used to 
> it (and like
> >its "security") in v4 world, and 2) they think it's easier 
> for them to do
> >NAT than to renumber.
> >
> >Site-locals were born in the era that not all sites had internet
> >connectivity.  Now that assumption is not all that valid 
> anymore.  It's
> >just easier for people to use a global address block (even 
> if we define
> >that address block to be 3ffe:eff3::/32 or whatever) even with these
> >"internal needs" (note: I believe there should be 
> _something_ that does
> >not require you to fill any kind of paperwork).
> >
> 
> Yah.  Let's pick a prefix, and tell folks to pick a random 
> number (more 
> precisely, use an RFC 1750-compatible RNG) to fill out the 
> rest of the 
> high-order bits to a /48 or a /64.  We encourage ISPs to provide real
> prefixes to companies that are using application-layer gateways, and 
> hence don't "need" a routable prefix.  We promise two months of 
> connectivity to folks using non-conflicting random prefixes when they 
> connect, while they renumber.  We think of other, creative solutions 
> that exploit the fact that we have a really large address space that 
> we're not going to exhaust.  
> 
> In short, that we do *something* that isn't going to cause long-term 
> architectural and operational pain.
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb (me)
> 		http://www.wilyhacker.com ("Firewalls" book)
> 
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Steve Blake <[email-masked]>
Date: Thu, 13 Jun 2002 17:26:21 -0400

Jim Bound wrote:

> with all due respect. rfc 1918 was a hack and never would pass the IESG
> today IMO they are doing a far better job these days causing us to detail
> our network views and development of protocols.  1918 has wrecked the
> Internet.

Ripping site-locals out of the specs will not prevent folks who perceive
the need for stable addresses (e.g., for internal use) from allocating them, 
especially given that ~7/8 of the IPv6 address space is held in reserve.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                   919-472-9913

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 18:31:14 -0400

> especially given that ~7/8 of the IPv6 address space is held in reserve.

the problem of course is that such addresses are not for internal use forever.
even if the net never connects to the public internet, the chance that the
net will connect to some other network that does connect to the public
internet are fairly good, and this invites potential address collisions.
(though less likely in v6 than in v4, where most nets use RFC 1918 space...)

seems like you really want some address space that 
- is unique
- isn't provider-based
- can be routed between private nets

Keith

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Jun 2002 14:32:01 -0700

> the need for stable addresses (e.g., for internal use) from allocating
> them, especially given that ~7/8 of the IPv6 address space is held in
> reserve.

that is what folk said about chunks of v4 space and then got into deep
doo doo when it was allocated, another site with which they merged had
also grabbed it, ...  occasionally, the goddesses are just.

we have all been here before -- crosby, stills, and nash

randy

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 14:33:12 +0700

Date:        Thu, 13 Jun 2002 17:26:21 -0400
    From:        Steve Blake <[email-masked]>
    Message-ID:  <[email-masked]>

  | Ripping site-locals out of the specs will not prevent folks who perceive
  | the need for stable addresses (e.g., for internal use) from allocating them, 
  | especially given that ~7/8 of the IPv6 address space is held in reserve.

Yes, exactly.

If site locals were made to go away, they'd simply be re-invented by
sites all over the place, in totally un-coordinated ways, and the same
pressures that led to reserving the 1918 address space will just reappear.

That was really: "people are doing this ('borrowing' address space) anyway,
we might as well tell them some numbers to use that will cause less problems
than simply using arbitrary ones".

Unless / until we come up with some way of avoiding even the possibility that
sites will ever need to renumber (which I think is almost the same as asking
for a guarantee that the routing people can route a 2^48 flat address space)
then stable addresses for internal communications are a *requirement* for
many sites, and whether that's achieved by simply "borrowing" some random
prefix and using it forever, or whether it is done using "fec0::/10" is
largely irrelevant - it will be done anyway.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 14:37:13 +0700

Date:        Thu, 13 Jun 2002 18:31:14 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | seems like you really want some address space that 
  | - is unique
  | - isn't provider-based
  | - can be routed between private nets

"provider based" is wrong, "isn't topologically based" is what would
be needed, so I get to retain the same addresses regardless of how my
connectivity to the net happened to change.

And the third needs to be "can be routed" without qualification.

All that you need to do is come up with the address space and routing
solution that meets those criteria (kind of like IPv4 addresses were in
the 80's and before) and then I'll certainly agree that we don't need
site local addresses, or some other replacement for them.

Until then however, we do.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 14:41:51 +0700

Date:        Thu, 13 Jun 2002 14:32:01 -0700
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | that is what folk said about chunks of v4 space and then got into deep
  | doo doo when it was allocated, another site with which they merged had
  | also grabbed it, ...  occasionally, the goddesses are just.

And that is exactly why 1918 was written, and as the need hasn't changed
in the slightest, exactly why site locals (or something equivalent) are
needed now.

kre

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Jun 2002 09:50:35 -0400

> pressures that led to reserving the 1918 address space will just

Just because people do something that we feel is unwise, doesn't mean
we should encourge such behavior (either explicitly, or by
silence). Saying "don't do that" is one of the things that the IETF
can do.

If the real feeling here is that site locals are bad if they end up
reproducing some of the same problems as private addresses, then we
should produce documents that explain when site-locals can safely be
used (i.e., an applicability statement that describes when the IETF
recommends their use). For other uses that people imagine (or that we
expect they will imagine), but for which we think is a bad idea, we
should say *why* its a bad idea *and* we should suggest a better way
of doing it, so that folks who have a particular problem can choose an
appropriate solution.

For example, we could arrange to allow sites to obtain globally unique
address space (though non-routable globally) if they want it for
internal numbering. That would address some of the issues that private
addresses of led to. Note that this is something we can't do in IPv4
because there just aren't enough address for this; IPv6 doesn't have
that constraint.

Thomas

---

From: Steve Blake <[email-masked]>
Date: Fri, 14 Jun 2002 10:01:06 -0400

> in the slightest, exactly why site locals (or something equivalent) are

A simple proposal:

  FEC0::/48                  good enough for (most) home nets, SOHO, etc.

  FEE<36-bit random#>/48     NUSLA

  FEFF<4-byte AS#>/48        for sites that absolutely, positively care about
                             global uniqueness

Any special casing for site-locals in the stack and the API should be removed.
Use at your own risk, just like rfc1918 addresses.

The latter (FEFF<AS#>/48) are portable global addresses.  If you can pay
someone enough to announce them for you in the DFZ, hooray for you.

Regards,

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 21:59:22 +0700

Date:        Fri, 14 Jun 2002 09:50:35 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | Just because people do something that we feel is unwise, doesn't mean
  | we should encourge such behavior (either explicitly, or by
  | silence). Saying "don't do that" is one of the things that the IETF
  | can do.

Of course.   But what here is something that we feel to be unwise.
Use of NAT to make 1918 addresses "work" in v4 is one, but no-one is
suggesting that for v6.  Use of 2 faced DNS is another, but while
some are suggesting that (why???) that's also something we should do
without.

But stable addresses ???

  | For example, we could arrange to allow sites to obtain globally unique
  | address space (though non-routable globally) if they want it for
  | internal numbering. That would address some of the issues that private
  | addresses of led to. Note that this is something we can't do in IPv4
  | because there just aren't enough address for this; IPv6 doesn't have
  | that constraint.

Yes, that would be fine, and that's just what Steve Blake suggested in
a message sent a few minute after yours.   Stable addressing is what's
needed - the bit pattern that identifies it isn't important.

But note the bit patterns suggested in Steve's message - his suggestion
becomes pretty much the same as the suggestion that I made a long time
ago, to stick identifiers in the upper bits of the SL address (he also
has NUSLA's in there, just to keep everyone happy - and retains current
SL addresses, though I'm not sure why on that) - this suggestion was
thrown out when suggested, the NUSLA suggestion was essentially abandoned,
and every time anyone suggests putting IDs of any kind in those bits, the
suggestion gets laughed at (with no actual technical rationale at all).

So my suspicion is that this kind of approach isn't going to work.

Your suggestion, which is essentially the same as  the one I made a long
time ago for all practical purposes, raises the question (or this is what
was put to me) of just who is going to administer this extra address space,
and wouldn't that be a bunch of extra work that no-one wants to do.

At the time (and still) I personally think this is a pathetic excuse for
an argument, but it seemed to be the one that convinced people more than
anything else - fear of creating another ICANN look-like bureaucracy (or
giving that one even more things to make a mess of).

kre

ps: one final comment on Steve's suggestions - I'm not sure that AS
numbers are the ideal thing to use here - for two reasons.   One they're
already carried around in the routing system, which might lead some people
to try and use them to make these addresses globally routable, which would
be a big mistake, and second, because they are a routing identifier, I
think it would be best not to confuse things by also making them an
addressing identifier - allocating numbers is such a trivial task that
I think we can just create a new set, or could, if there was any chance of
a proposal like this being adopted, which I doubt.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Jun 2002 08:05:08 -0700 (PDT)

> of doing it, so that folks who have a particular problem can choose an

To my mind, one of the key failure modes of
overlay addressing is collisions when the original
assumptions of the overlay cease to be true --
like when you get two companies who merge, say,
and their net 10 address spaces collide. This
drives integration attempts to a great deal of
distraction and a Quick Fix NAT(tm) is almost
certainly the result.

What you'd really like in that situation is to
renumber, but color me skeptical that renumbering
will ever be "easy" or "automatic", especially
when you consider the widespread conflation of
addresses as routing tags and as identity. Thus,
I think site locals will still beg the Quick
Fix NAT(tm). Badness.

If we instead say that you should just blackhole
otherwise globally routed prefixes at the site
boundary, we don't run into this problem. If you
have a change of policy, you just change some or
all of the prefix that gets blackholed instead of
renumbering. Just as easy, if not easier than
setting up NAT's, IMHO. 

	 Mike

---

From: Steve Blake <[email-masked]>
Date: Fri, 14 Jun 2002 11:39:28 -0400

> ago, to stick identifiers in the upper bits of the SL address (he also

No claims of originality on my part.

> SL addresses, though I'm not sure why on that) - this suggestion was

They are out-of-the-box, for those (the majority of users, probably) who
can't be bothered to configure a NUSLA.

> a proposal like this being adopted, which I doubt.

AS numbers have an existing infrastructure for allocation, and they are
unique.  The set of nets that would ever care about true uniqueness probably
intersects heavily with the set that would own an AS# anyway (although the
first set might be the null-set for all I know).

As to whether they are ever globally routable: that is a business issue
between a customer and his provider.  Any IETF prohibitions on this would
be so much hot air.

Note that draft-hain-ipv6-pi-addr-02.txt addresses are a perfectly suitable
alternative to my proposal (at least in some cases), but they aren't 
zero-cost to acquire either.

Regards,

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 23:13:32 +0700

Date:        Fri, 14 Jun 2002 11:39:28 -0400
    From:        Steve Blake <[email-masked]>
    Message-ID:  <[email-masked]>

  | They are out-of-the-box, for those (the majority of users, probably) who
  | can't be bothered to configure a NUSLA.

OK, but then all the "problems" that people keep complaining about
remain.

  | AS numbers have an existing infrastructure for allocation, and they are
  | unique.

Yes, but they're not allocated to all sites normally - I have never
been at a site that had its own AS# I think, even back in the old
days when I was assisting the first version of AARnet, there was no
AS# (for the net which linked all of Aus...) - that's changed of
course, but most end user sites currently don't need an AS#, so
allocating them for this would vastly change the dynamics (and 32 bits
might not be enough).

  | The set of nets that would ever care about true uniqueness probably
  | intersects heavily with the set that would own an AS# anyway (although the
  | first set might be the null-set for all I know).

Possibly, but that assumes that the NUSLA part remains, and that stuff
seems to have been written off previously (for whatever reason).

  | Note that draft-hain-ipv6-pi-addr-02.txt addresses are a perfectly suitable
  | alternative to my proposal (at least in some cases), but they aren't 
  | zero-cost to acquire either.

Ah yes, Tony's draft has some very interesting ideas, and is almost
certainly worthy of much more discussion that it seems to have elicited
(for which I apologise to him as one of those who never found the time
to comment, though I have read it as new versions appeared).

Unfortunately, while it might make a nice alternative to provider based
addressing as a global address method (for some) if it can be made to
work (which largely depends upon the routing people managing to support
the address space at a fine enough resolution to make it feasible to use),
it isn't an alternative to site locals at all.

Addresses there are still constrained - I don't get allocated one which
I get to keep forever, no matter what, which is what SL addresses give me
(with or without some higher layer identifier embedded in them).
So, as an alternative to SL, they don't work, regardless of how good
they may be as global addresses.  Of course, they also weren't designed
(I believe) as an alternative to SL, so this is probably no surprise.

kre

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Jun 2002 09:31:53 -0700 (PDT)

> (I believe) as an alternative to SL, so this is probably no surprise.

   In the good old days, wasn't it rather common
   for clueless newbies to slavishly number their
   networks 192.6 or somesuch which was what they
   found in the network administrator manual examples?
   They worked just great up until the time they
   wanted to connect to the real net, right?
   Assuming that you _never_ want to globally
   advertise that prefix -- which is what site
   locals are intended for -- does it actually
   make any difference which prefix you choose? Why
   does IETF have to sanction one? Why not just
   let people make their own decisions? It's not
   like there's any more or less work if they 
   change their minds, right?

   BTW: isn't there already an implicit "site local"
   address space for v6 with net 10 v4 mapped
   address?

		Mike

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Jun 2002 00:00:55 +0700

Date:        Fri, 14 Jun 2002 09:31:53 -0700 (PDT)
    From:        Michael Thomas <[email-masked]>
    Message-ID:  <[email-masked]>

  |    In the good old days, wasn't it rather common
  |    for clueless newbies to slavishly number their
  |    networks 192.6 or somesuch which was what they
  |    found in the network administrator manual examples?

Yes (that wasn't the number, it used to be imprinted on my
brain, but fortunately these days it is seen so rarely that
I have forgotten the value - I think it had a 200 in it though,
not that it matters - 192.9.200 ??).

It was this kind of thing that led to 1918 addresses - the IETF
invented (allocated) them precisely because of the problems that
this (and other number "borrowing") caused.

  |    They worked just great up until the time they
  |    wanted to connect to the real net, right?

yes.

  |    Assuming that you _never_ want to globally
  |    advertise that prefix -- which is what site
  |    locals are intended for -- does it actually
  |    make any difference which prefix you choose?

Yes.   Because if you happen to choose a prefix that is someone
else's globally allocated prefix, you can never talk to them.
Or more likely, you find you have to renumber because you want
to talk to them (if you're lucky, and never do, there's no issue).

If you're ever going to be in the position of having to renumber
then the address you have isn't stable.

Of course, if "you" happen to be a large ISP, instead of an end-site,
then not only can "you" not communicate with the true assignee of the
address, but nor can anyone else who uses you for connectivity.

  |    Why does IETF have to sanction one?

One, as distinct from two or three or ... it doesn't.  One as
distinct from zero, so you know the address that you're going to
be using will never be one that someone else uses (and you might
need to use to communicate with them - their using it as a private
address is harmless of course).

  |    Why not just let people make their own decisions?

They don't have enough information to make a good decision.
Allocate several prefixes (like was done in 1918) and allow
people to choose which they want to use if you like, that's
fine - but they need to be prefixes reserved for the purpose.

  |    BTW: isn't there already an implicit "site local"
  |    address space for v6 with net 10 v4 mapped
  |    address?

If you mean the ::/80 address space (::/96 and ::FFFF:/96) then
if there's any addresses that it would be nice to see vanish,
it would be those (and one hopes that they will do so once v4
has finally departed - sometime in the far future).  In any case
these ones don't work, because you don't get a /48 prefix out
of them,

If you mean 2002:0A00::/24 (which aren't usually called v4 mapped
addresses I thought) then that's certainly a possibility,
but it is also just a bit pattern variation on fec0::/10, and
I thought we'd all agreed that bit patterns cannot possibly be
what's important here.   I don't care what the bit pattern is,
just as long as it exists (but since fec0::/10 already exists,
I'd want to see a good justification to alter it).  I would also
expect 2002::/16 to vanish, sometime in the far future, as well
of course, that one may even happen before the other as 2002
remains viable only while the IPv4 global routing system works,
::/80 (the two sub-groups of that of relevance) is still usable
while there's any IPv4 left anywhere.

kre

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Jun 2002 10:26:44 -0700 (PDT)

> this (and other number "borrowing") caused.

   But the real problem was renumbering. That
   still hasn't gone away.

 > to talk to them (if you're lucky, and never do, there's no issue).

   Uh, except you can't talk to them anyway because
   all you have is a non-globally-routable
   address, right?

 > then the address you have isn't stable.

   See above.

 > address is harmless of course).

   Except you can't communicate with them unless
   you renumber or NAT anyway.

 > fine - but they need to be prefixes reserved for the purpose.

   Except neither does IETF, it seems. There's
   no such thing as an long term stable
   globally routable prefix. If you want a
   globally routable address, you have to deal 
   with renumbering, regardless of whether you
   got your "private" prefix from RFC 1918, or the
   back of an old Ultrix manual.

 > If you mean the ::/80 address space (::/96 and ::FFFF:/96) then
   []

 > If you mean 2002:0A00::/24 (which aren't usually called v4 mapped
   []

   I'm not sure which one I mean, honestly, and am 
   too lazy to look it up. However, it seems that
   if you have any v6 prefix which maps the
   v4 space, you automatically get net 10's for
   the bargain, and all of the hassles they
   entail, including dealing with the v4 overlay
   network routing. Keeping "private" addresses
   as a v4 artifact -- which are still accessible
   to v6 if you are so inclined -- may be a way 
   out of this...

	  Mike

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Jun 2002 00:57:26 +0700

Date:        Fri, 14 Jun 2002 10:26:44 -0700 (PDT)
    From:        Michael Thomas <[email-masked]>
    Message-ID:  <[email-masked]>

  |    But the real problem was renumbering. That
  |    still hasn't gone away.

No, and that's why we need these things - so when renumbering happens,
our internal addresses (the ones I use to mount my filesystems from
the fileserver, etc, which stay in use for months or years between
reboots) don't alter.

  |    Uh, except you can't talk to them anyway because
  |    all you have is a non-globally-routable
  |    address, right?

No, not at all.   That was what happened for v4, but here we're
talking about an address you have in addition to your globally
reachable address, not instead of it.

  |    Except neither does IETF, it seems. There's
  |    no such thing as an long term stable
  |    globally routable prefix.

No, but we're talking about SL here, nothing globally
routable about it at all.  And while a globally routable
permanent static address would be nice to have, at the
minute that doesn't look to be feasible.  Again, that's
exactly why we (I anyway) want SL addresses.

  |    If you want a
  |    globally routable address, you have to deal 
  |    with renumbering, regardless of whether you
  |    got your "private" prefix from RFC 1918, or the
  |    back of an old Ultrix manual.

Sure, but that other address remains working just fine, for all
the internal connections - no need to change it, ever.  That is,
provided it is an address that no-one else will ever be using for
their global communications, which is another way of saying,
providing it is a reserved address.

  |    I'm not sure which one I mean, honestly, and am 
  |    too lazy to look it up. However, it seems that
  |    if you have any v6 prefix which maps the
  |    v4 space, you automatically get net 10's for
  |    the bargain, and all of the hassles they
  |    entail,

Yes, you do.   That's 2002:0A00::/24

But 2002::/16 will remain allocated only as long as the v4 global
routing system remains to make it feasible, then it will vanish back
to unallocated space, as it would no longer serve any function
(it will probably take a long time before it gets reused, but
eventually I'd expect it to be).  Then 2002:0axx:... will just
be someone else's global address.

  |    Keeping "private" addresses
  |    as a v4 artifact -- which are still accessible
  |    to v6 if you are so inclined -- may be a way 
  |    out of this...

But aside from being a different bit pattern than fec0::/10
what's the difference supposed to be?   (Ignoring for now that
2002::/16 will not always be available for the purpose).

kre

---

From: Alain Durand <[email-masked]>
Date: Fri, 14 Jun 2002 11:45:16 -0700

> the fileserver, etc, which stay in use for months or years between

Site local addresses save your from renumbering if you change ISP.
They don't help if you merge two networks. Subnet ID may collide.

    - Alain.

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 11:51:40 -0700

> Site local addresses save your from renumbering if you change ISP.

help with renumbering is good.  help which non-trivially complicates
addressing, forwarding, and routing is very bad.  the long-run cost in
complexity, bugs, unreliability, ... of the latter will overweigh the
savings of the former.

randy

---

From: Michael Thomas <[email-masked]>
Date: Fri, 14 Jun 2002 17:52:28 -0700 (PDT)

> the fileserver, etc, which stay in use for months or years between

   I guess I get off the merry-go-round here because
   I'm having a hard time imagining a deployment where
   it's OK to hose general internet connectivity, so
   long as other local services are kept up. Somehow
   I don't expect that the user population counting on
   their pr0n will be mollifed to find out that they
   can still download their PHB's powerpoints.

   YMMV.

	     Mike

---

From: [email-masked]
Date: Sat, 15 Jun 2002 11:49:30 +1000

>    can still download their PHB's powerpoints.

	Well you have a very poor imagination and understanding of
	typical connection patterns.  99.99% of external connections
	are short lived.  Those that arn't short lived take a hit
	when the address renumbers.  This is why certian providers
	can get away with *forcing* a address change every 24 hours
	today.

	However if you put a NFS server on a machine that has its
	address change every 24 hours then have a 10000 mounts off
	that server spread over 1000 machines and see what happens.

	NFS isn't the only protocol where long running connections
	are the norm *inside* a site.  Things like SSH/X11/TELNET
	all tend to have much longer running sessions intra site.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Sun, 16 Jun 2002 08:16:43 +0700

Date:        Fri, 14 Jun 2002 11:45:16 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | Site local addresses save your from renumbering if you change ISP.

They don't avoid renumbering, but they save my internal network
connections from the side-effects of he renumbering.

  | They don't help if you merge two networks. Subnet ID may collide.

That's certainly true - but a merge like this can be, and needs to
be planned, and can take as long as required to be executed.  What's
more I get to decide which internal bits of the two (or more) nets
get renumbered, and which bits get to retain their old numbers.

And of course, this only ever happens when the site owner chooses to
have it happen (two organisations that merge can run their net as
two separate IPv6 "sites" if they choose), unlike an external
renumbering, which could be caused by your ISP altering its point
of connection to the topology and having to renumber itself, and all
its clients (and going to a different ISP doesn't save you in many
cases, as you'd have to renumber to do that as well).

kre

---

From: Bill Fenner <[email-masked]>
Date: Mon, 17 Jun 2002 16:21:44 -0700

>And of course, [merging two sites with possibly-overlapping subnet
>numbers] only ever happens when the site owner chooses to
>two separate IPv6 "sites" if they choose)

Running the net as two separate sites has its own costs, though,
by limiting the permitted topology.  (See my discussion with Dave
Thaler hundreds of messages ago in this thread).

  Bill

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Jun 2002 18:24:23 +0700

Date:        Mon, 17 Jun 2002 16:21:44 -0700
    From:        Bill Fenner <[email-masked]>
    Message-ID:  <[email-masked]>

  | Running the net as two separate sites has its own costs, though,
  | by limiting the permitted topology.  (See my discussion with Dave
  | Thaler hundreds of messages ago in this thread).

Yes, absolutely.   Nothing is going to avoid *all* renumbering in
every possible situation, what site locals avoid is renumbering from
the outside affecting operations internally (if they're used properly).

To me, that's a big win.

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Jun 2002 09:50:22 -0400

> the outside affecting operations internally (if they're used properly).

perhaps, but the "if they're used properly" comes with a cost - 
applications have to know how to deal with them.  

the other thing is that 'proper' handling of of SLs and LLs is different 
enough from proper handling of normal addresses that sane apps will only 
use them as a last resort, and the limitations of those kinds of addresses
for normal opreations will not be discovered until the global addresses
fail to work.  the bottom line is that renumbering from the outside
will still affect operations internally - just in ways that are more 
subtle and harder to diagnose.  (as if the loss of external connectivity
isn't enough of an effect) 

so I think SLs are a fairly limited win, and they come at a fairly
high cost.

I also think that external renumbering events are going to have to be
carefully managed by humans, with plenty of advance notice, for the 
forseeable future.  

Keith

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Jun 2002 21:22:37 +0700

Date:        Tue, 18 Jun 2002 09:50:22 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | perhaps, but the "if they're used properly" comes with a cost - 
  | applications have to know how to deal with them.  

Some applications.   But those are also the applications that need to
know more about addresses than they currently usually do anyway.

If you remember from some earlier message, I'd only use SL addresses in
those apps that expressly say they want to use them, for others, the
vast majority of apps probably, globals work fine.

  | the other thing is that 'proper' handling of of SLs and LLs is different 
  | enough from proper handling of normal addresses that sane apps will only 
  | use them as a last resort,

But that makes no sense.   If you're able to use them at all, the logic
has to be there in the code, and in that case, it makes sense to use them
whenever they work (SL's anyway, LL's usually only when their use is
specifically requested).

So ...

  | and the limitations of those kinds of addresses
  | for normal opreations will not be discovered until the global addresses
  | fail to work.

I don't think that's true.   I'd also never regard a SL address as a fall
back from a global that doesn't work - my model at least requires the
global address to work (in the sense of reach the recipient and get a
reply back) before I'd consider using the SL instead.   Rather, SL's are
for those apps that know they will (or are likely to) be using the
address for a long time, and which consequently want an address that
will more probably be stable for longer.

  | the bottom line is that renumbering from the outside
  | will still affect operations internally - just in ways that are more 
  | subtle and harder to diagnose.

I disagree - but this seems to largely come down to the theory of when
and how SL's will get used.   Certainly external renumbering has the
potential to disrupt internal stuff - anything that is using a global
address will be affected.   But if I know that I want to guard against
that possibility (as an app writer of the kind of apps that suffer
most - filesystem, mounts, tunnels, ... probably remote logins) then
if I get to use SLs I can avoid the problems for me - one less issue for
the net people to have to deal with.

  | (as if the loss of external connectivity isn't enough of an effect) 

External connectivity isn't likely to be lost (or shouldn't be), just
external connections that have lasted longer than the overlap period
of old & new addresses will break when the old finally stop working.

Often, that will be no noticeable effect at all, as there simply tend
not to be that many long term wide area connections (tunnels are probably
the most noticeable kind of application that may be affected).

  | so I think SLs are a fairly limited win, and they come at a fairly
  | high cost.

I'm still looking for the high cost, I can't really see it.   Certainly
not zero cost, but I don't really think that the cost is all that great.

  | I also think that external renumbering events are going to have to be
  | carefully managed by humans, with plenty of advance notice, for the 
  | forseeable future.  

Depends who is foreseeing ... I certainly agree that it is going to be a
while before things can be less disruptive.   But that's no excuse for
deliberately creating the environment where more disruption is required.

Note that for many sites these days (IPv4) renumbering is essentially
an invisible operation - almost nothing is affected at all.   That is,
one adjusts the NAT box, and fixes the external DNS, and aside from
any connections that were open and get broken (which a good NAT box,
if such a thing exists, could probably avoid by keeping the old state
even after recreating it becomes invalid) no-one inside the net can
even tell that the renumbering happened.

One of the aims of IPv6 was to be at least as good as IPv4 at everything
(and better wherever it is possible).   If SL's get sacrificed, just
how does IPv6 ever return to even par (or better) ?   If the answer if
NATv6, then I think we should all just quit and leave all of this to
someone with better judgment.

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Jun 2002 10:46:53 -0400

okay, I now understand your use case for SLs, though I still think it
would probably be better to solve that problem by assigning a unique,
non-publically-routable prefix to each site that asks for one.

Keith

---

From: Robert Elz <[email-masked]>
Date: Tue, 18 Jun 2002 22:13:12 +0700

Date:        Tue, 18 Jun 2002 10:46:53 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | okay, I now understand your use case for SLs, though I still think it
  | would probably be better to solve that problem by assigning a unique,
  | non-publically-routable prefix to each site that asks for one.

Yes, that would be an alternative - and is much the same as
SL's with site ID's embedded.

Aside from the much touted (but really silly) objection of "who would
assign them" this method has other problems.

Either way (SL's with ID's, or non-routable globals) gets rid of the
scoping problem.   No need to pass scopes around any more - but they're
still needed for LL's.

They also make routing easier.

The global addr model though makes apps lifes more difficult, in that
it is then no longer immediately obvious which addresses are stable,
and which are not.   Given two addresses, which should I use if I want
a stable connection (assuming I somehow know that both work) ?

Globals also lack the "you can't possibly route that, everyone and his
dog owns the same address" argument that immediately shoots down
anyone trying to make the thing routable, and stable.

None of this is easy - there is no easy answer (or not that has been
proposed so far).

kre

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Jun 2002 08:27:29 -0700 (PDT)

> a stable connection (assuming I somehow know that both work) ?

   This is just the tip of the iceberg of what hosts
   don't know about addresses. The problem is that 
   it is definitionally *unknowable* to the host
   since only thing that has that knowledge of those
   sort of topology goodies are routers, perhaps 
   transported by routing protocols.

   This, to my mind, is the very basic reason why
   SL addresses are a generally Bad Idea. Requiring
   hosts to have knowledge of network topology is
   a bug, not a feature.

	  Mike

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Jun 2002 11:40:38 -0400

> SL's with site ID's embedded.

right.  but you don't have to deal with that extra frob.
 
> scoping problem.   No need to pass scopes around any more - but they're

perhaps, but LLs really shouldn't be used except for some very odd
cases - I see LL as mostly a way to avoid having to reinvent the
same functionality differently for each L2 network.

> a stable connection (assuming I somehow know that both work) ?

I don't think stability is the issue.  global addrs need to be reasonably
stable (which is to say, on the order of MTBFs for reliable machines) 
whether or not the prefix is provider-based, topology-based, or 
assigned to the site.   the idea that a prefix can be changed at a whim
is just a fantasy.  at the same time, apps that need stable connections 
that last for months really do need to work out mechanisms to recover
from address changes, but they'd need to do this even if the addresses
were permanent, because within that kind of timeframe, machines get moved, 
replaced, reassigned, etc anyway.

the real issue is that a pre-site prefix is still a limited scope prefix.
it might or might not work to reach a different site with a different
per-site prefix, depending on whether you have a private connection to
that site.  so there's still trial-and-failure involved in knowing which
address to use, and an app component cannot expect to advertise a single
single global address to be reachable from all of its peers if any
of those peers are at a site that relies on pre-site prefixes for 
connectivity (via private agreements).  so it still complicates the 
model that apps have to be written to, though not quite as badly as SLs. 

but as long as we insist on provider- or topology-based addressing for
the public network, I don't see a better way to solve the problem that
isolated sites want to interconnect with other sites, than non-routable
site-specific address prefixes.

and since we cannot insist that everyone connect every host to the
internet, distributed apps have to make a decision anyway - either 
they're only going to work on hosts that are connected to the public
internet and have global addresses, or they're going to have to cope
with multiple addresses and the possibility that the same address
won't work everywhere.  but at least we can avoid having addresses
whose meaning varies from one place to another, and we can avoid
having apps try to guess what addressing realm/scope they're in.

> None of this is easy - there is no easy answer (or not that has been

indeed.

Keith

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jun 2002 12:48:44 +0700

Date:        Tue, 18 Jun 2002 08:27:29 -0700 (PDT)
    From:        Michael Thomas <[email-masked]>
    Message-ID:  <[email-masked]>

  |    This, to my mind, is the very basic reason why
  |    SL addresses are a generally Bad Idea. Requiring
  |    hosts to have knowledge of network topology is
  |    a bug, not a feature.

I agree with the last sentence, but knowing about SL addresses
tells you nothing at all about network topology.  The two just
aren't related.   Assigning SL addresses requires knowledge of
the topology (as does assigning global addreses), but to use
one doesn't.   All the hosts do is use them.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Jun 2002 02:13:23 -0400

> one doesn't.   All the hosts do is use them.

actually a distributed app does in some sense need to know 
about network topology in order to use SL addresses, because
a component might send a referral using an SL address to another
component that isn't at the same site.  without some notion
of topology the app has no idea which address to use in the 
referral.  it's very much like the problem that occurs with NATs.

the app could simply refuse to use SL addresses, but then it 
wouldn't be able to use components at sites that don't have 
global addresses.

though I expect it's more likely that the app would pass
multiple addresses in the referral and let the components
receiving those referrals do trial-and-failure until they
find an address which works to reach the desired component,
than actually trying to make the app aware of topology.

still, it stinks no matter how you do it.

Keith

---

From: Brett Pentland <[email-masked]>
Date: Wed, 19 Jun 2002 16:46:06 +1000

> referral.  it's very much like the problem that occurs with NATs.

Is it good practice for such an app to use addresses directly, rather 
than hostnames (that are then resolved through DNS into global addresses 
anyway)?  Perhaps this is an example of a bad use of SL but does it mean 
that SL is inherently bad?

Regards,
Brett.

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Jun 2002 16:30:05 +0700

Date:        Tue, 18 Jun 2002 11:40:38 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

[Aside: I have been interrupted many times while creating this message.
(Its life span in my editor runs to many hours now...)
I see that while I have been waiting, you have replied to an earlier
message I sent.   I think that the points you made there have been
covered in this reply already, before I saw your later message, so I
won't reply to that one as well - much of this is all based around the
usage model for SL addresses - for sure, it is possible to imagine some
in which SL addressing would be absolutely horrible.   They should
obviously be avoided.  I don't think that such a model is required
however, I believe that SL addressing can be mare relatively painless
to use]

  | perhaps, but LLs really shouldn't be used except for some very odd
  | cases - I see LL as mostly a way to avoid having to reinvent the
  | same functionality differently for each L2 network.

But what is of concern here largely is not how often they should be
used, but whether the mechanisms to allow them to be used at all have
to be provided.   Once an option exists, all the support is required,
even if in practice the option is never used.

So, the simple existence of LL addresses, and the possibility that a
node may be connected to two links, each with its own set of LL addresses,
and to nothing else at all (no global addressing, and in your model, no
SL addressing) means that apps need to have all the baggage in them to
deal with sending to either one of those links - even if in practice
it gets used almost never.

It is because all this is *required* anyway, that I can't see where the
big extra costs for using SL addresses come from - it is all just the
same extra baggage.

  | I don't think stability is the issue.

Stability is absolutely the issue.

  | global addrs need to be reasonably
  | stable (which is to say, on the order of MTBFs for reliable machines) 
  | whether or not the prefix is provider-based, topology-based, or 
  | assigned to the site.   the idea that a prefix can be changed at a whim
  | is just a fantasy.

That would sure be nice.   But no-one has yet suggested any mechanism
by which we confine this to the realms of fantasy, and stop it becoming
reality.   If you can do that, by all means, I'd love to know how it is
to be achieved.

The argument so far seems to be "it hasn't happened yet, and I wouldn't
like it if it did happen, so I will just declare it impossible".

Even worse, to a fair degree there's a large amount of assuming this, and
then "simplifying" things based upon this assumption being a fact, to
the degree that when (if) the assumption turns out to be wrong, we'll
all be much worse off.

Another assumption is that when renumbering does happen, the old and new
overlap will be so long, that nothing that really matters will care if
it stops working (there will be so little, and it will be so infrequent
that it just won't really matter).   The problem with this is that the
overlap period is a period if instability, and in general, people want
such periods to be as short as possible, not as long.   Make it too long
and you may end up with a new renumbering being required before the first
one is fixed.

Now I certainly don't know that renumbering will happen often, or at
any particular frequency, I'd certainly mush prefer stable addressing that
never changes.   But I am not prepared to assume that is how things will
end up, so I want to plan for the worst, and give everything the greatest
possibility to work properly - so I assume that one day (maybe 10-15
years away, who knows) some significant renumbering will start to be
needed.   I want the protocols we are installing now (along with
enhancements over this period) to be able to cope with that.

If later events show that some other solution is found, and site local
addresses have no role left to play, then they can simply fade away,
we can declare them historic, and we will have wasted some effort, on
what is really insurance.   I'd love it if that happened, but I actually
think this insurance is more like car insurance, than plane crash
insurance - it isn't the kind you take out but expect never to have to
use, it is the kind we take out, because it is very likely it will
actually be needed, sometime or other (just my opinion of course).

  | at the same time, apps that need stable connections 
  | that last for months really do need to work out mechanisms to recover
  | from address changes, but they'd need to do this even if the addresses
  | were permanent, because within that kind of timeframe, machines get moved, 
  | replaced, reassigned, etc anyway.

Yes.   Back when IPng was being started, I really wanted us to do TCPng
at the same time (which may have turned out to be SCTP or something like
it) - so that we could expect that coping with address changes would be
much easier.   But almost no-one else wanted to do that...

So I don't really have great hopes that we're going to get things like
NFS, changed so that they can cope with address changes transparently.
Again, great if it happens, I'm just not willing to gamble everything
on success in that area.

  | the real issue is that a pre-site prefix is still a limited scope prefix.

Yes.

  | it might or might not work to reach a different site with a different
  | per-site prefix, depending on whether you have a private connection to
  | that site.

Yes.

  | so there's still trial-and-failure involved in knowing which
  | address to use,

Yes.

  | and an app component cannot expect to advertise a single
  | single global address to be reachable from all of its peers if any
  | of those peers are at a site that relies on pre-site prefixes for 
  | connectivity (via private agreements).

Well, again, I'd simply require everyone to have global addresses that
work.  That is, I would make site local addressing actually depend upon
global addressing working.   To some extent this (not by design) mitigates
Jim Bound's concern about SL addressing defeating end to end, as I would
have SL addressing simply not work if end to end didn't work first.

So, creating a private fiefdom with only SL addressing (any not routed
address space really) and expecting it to function to communicate with
others just won't work at all - except in the case of sites running a
private DNS, which really should be only disconnected sites - when the
DNS can simply be set up to return all addresses that actually work - if
you put an address there, it better work for everyone who can possibly
get that answer, directly or indirectly).

  | so it still complicates the 
  | model that apps have to be written to, though not quite as badly as SLs. 

I don't see the difference.

Note that the only apps that really need to be much complicated by SL's
(aside from the scope part, which is really largely hidden - the lower
layers include it in the addr structure, and the app just uses the whole
thing) when they're trying to be fancy with addresses.

That is, for example, to send an address from one node to another.

My model for that would be for the app to send only global addresses,
(more accurately, only addresses that were received from the DNS)
never site locals (which only requires that they be easy to recognise).

Note: I require everything to have a global address, so there's never
a problem doing that (no guarantee that the global will work from the
place it is being sent - but that's the same whether SL's exist or not).
Then where the address is received, the app can decide if it would be
better to use a SL addr if it can, and discover the SL addr for itself
(most apps won't bother, as they're not going to be affected).

  | but as long as we insist on provider- or topology-based addressing for
  | the public network, I don't see a better way to solve the problem that
  | isolated sites want to interconnect with other sites, than non-routable
  | site-specific address prefixes.

No, nor do I.   I have no problems with these things.  If they're
used only by completely non-connected sites, they'll work just fine.
And continue regardless of whether SL addresses also exist.

But if they get seen by a globally connected site, then they start to cause
other problems (including how we find the things in the first place,
given the "disconnected" site isn't going to be in the the DNS).

  | and since we cannot insist that everyone connect every host to the
  | internet,

We can't insist that everyone make every host reachable from the
internet - we can insist that everything be given a global address.
We don't do it quite in that way of course, instead we just design
things so that if everything doesn't have a global address, it doesn't
work, even locally.   We make lots of that kind of decision (as does
everyone else who builds things).

  | but at least we can avoid having addresses
  | whose meaning varies from one place to another, and we can avoid
  | having apps try to guess what addressing realm/scope they're in.

I would never let an app see an address whose meaning varied (beyond
what it gets told in the address itself).   That is, for a site local
with a scope attached, just consider the scope to be the most significant
bits of the address.   With this interpretation, all addresses the
app should ever see are ones with (instantaneous anyway) fixed meanings.
Embedding the scope in the SL addr, and calling it a site identifier,
doesn't change that, it just means that more addresses are available.
The same should be somehow made true if global prefixes were to be
assigned - apps would need some way to know which would work, and which
would not - this looks to be the biggest drawback to that approach to me.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Jun 2002 09:32:10 -0400

Hi Robert,

At 05:30 AM 6/19/02 , Robert Elz wrote:
>what is really insurance.   

If site-local addressing is "really insurance", and may "fade away" later,
would this be an argument for:

         - Moving site-local out of the base IPv6 specs into separate documents
                 (with the exception of reserving their address space in the
                 addressing architecture)?
         - Determining the status (PS, DS, experimental, historic) of those
                 documents separately?
         - Making site-local implementation optional? Maybe hosts that don't
                 implement SL should treat them as global, routers should, by
                 default, never forward them? -- This opens the possibility
                 of enabling site-local later with changes only in routers.

What do you think?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Jun 2002 10:24:30 -0400

> anyway)?  

yes.  DNS is often slow, unreliable, or even unavailable.  many hosts 
don't know their own DNS names, or if they do know a name, it's not fully-
qualified.  it's not reasonable to expect all apps to use DNS every
time they start a new communication with a host.

> Perhaps this is an example of a bad use of SL but does it mean

none of this is inherently, absolutely bad, but some things are worse
than others.  I think SL is far more trouble than it's worth.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Jun 2002 11:07:10 -0400

> it gets used almost never.

I guess I disagree, because I don't think existence of an API for
sending/receiving raw IP packets compels apps to support that either.

but it depends to some degree on how LL is pitched to the public.  
the zeroconf WG is pitching v4 LL as a mechanism to allow appliances 
to auto-configure themselves, and therefore encouraging use of LL by 
applications, with all of problems that exist for v6 LL and more.
I don't think use of LL by apps is a good idea for either v4 or v6.  

> big extra costs for using SL addresses come from - it is all just the

the danger is that SL addrs are clearly meant for use by apps, while
it can be argued that LLs aren't meant for GP use.

> Stability is absolutely the issue.

I guess it depends on how often the network's global prefixes are 
renumbered and whether this is done as a planned event or on the whim
of the ISP with little or not notice.  To me the later is simply
unacceptable, but I don't pretend I/we can stop ISPs from doing that.
ISPs that pull that kind of stunt deserve to go out of business quickly.

> reality.   If you can do that, by all means, I'd love to know how it is

to some degree this is govered by public perception about what is 
reasonable, and such perception can be influenced by standards.    
so we do have some influence here.    we should try to use it.

> the degree that when (if) the assumption turns out to be wrong, we'll

either you have to assume some kind of predictable behavior by the network,
or you have to build your own network to your own specs all the way to 
every machine you wish to connect to.  that predictable behavior is more-
or-less determined by the specifications.  there's no way to absolutely
prevent brain-damage like unannounced renumbering, but it can be discouraged.  
and if such renumbering breaks valuable functions,  and is unnecessary, 
that creates a market opportunity for a competitor to that ISP.
 
> and you may end up with a new renumbering being required before the first

Well, the assumption (correct or not) is that a site can tolerate multiple
prefixes anyway, so that the degree of "instability" due to overlap will 
be acceptable.  Whether this is true is yet TBD.

> enhancements over this period) to be able to cope with that.

well, there is more than one idea about how to give everything the greatest 
possibility to work properly.  one way is to design a simple and easily 
understood way of having things work properly, with clear separation of 
function between various layers (e.g. the network/ISP is responsible for 
making sure that address prefixes don't change without X amount of notice and 
Y amount of overlap, and apps that need to keep connections open longer than 
Y are responsible for having their own mechanisms for doing so).  another
way is to introduce extra complexity and overlap between functionality
(belt-and-suspenders approach) which might assume that the app will 
compensate for any degree of instabliity in the network.  To me the
latter way is more expensive, introduces more potential for failure, and 
is harder to fix problems when they occur because the ISP can blame the app 
implementor and vice versa.  Once you have complexity, it's difficult to
get rid of it.  So I prefer the simple approach.
 
> NFS, changed so that they can cope with address changes transparently.

easiest way to fix this is to have NFS (and those other apps) use mobile IP.

> work.  

I don't think it flies as long as we're requiring sites to connect
to the public net to get global addresses, and some sites don't want to 
connect  to the public net at all.  But they do want to connect to other 
sites, and they want to run the same apps that people on the public net run.

> I don't see the difference.

with global non-routable addresses, the site-id is carried along with the
address, it's exposed as part of the address (assuming a reserved prefix
for such addresses), it's returned in the same kind of DNS RR that carries 
a normal address.    the address is globally scoped so there is no chance 
of mistaking an address from a remote site as being one from a local site 
or a different remote site.

> never site locals (which only requires that they be easy to recognise).

again, I don't think that flies.  too many enterprise nets are not 
connected to the public internet have no way to get globals.
in the current IPv6 view, they have no way to get global IPv6 addresses .
even if they borrow a prefix from somewhere, those addresses won't 
really be global in the sense that they're reachable from elsewhere.  

> And continue regardless of whether SL addresses also exist.

But it seems to me that if we do have these, we don't need SL anymore.

> given the "disconnected" site isn't going to be in the the DNS).

DNS is not the only mechanism by which apps find addresses, nor should
it be.  I expect to see even more such mechanisms in the future.

> internet - we can insist that everything be given a global address.

perhaps (and I probably agree), but right now we're insisting on just
the opposite.

> what it gets told in the address itself).   

I *wish* I could dictate the environments that my apps run in to that
degree, but I don't have any way to prevent an app that I write from seeing
such addresses.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Jun 2002 08:36:24 -0700 (PDT)

> that SL is inherently bad?

   I'll point out that SDP -- the main component for
   media rendezvous signaling -- doesn't use DNS names.
   They are sent as raw numeric addresses. So this is
   not entirely academic.

	    Mike

---

From: Alain Durand <[email-masked]>
Date: Wed, 19 Jun 2002 09:54:35 -0700

>                  of enabling site-local later with changes only in 

What is the impact of your proposal to the address selection rules?

	- Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Jun 2002 14:00:30 -0400

Hi Alain,

>What is the impact of your proposal to the address selection rules?

There are two cases:

         (1) The routers don't support site-local.  No site-local
                 prefixes will be advertised, and no site-local traffic
                 will be routed.

         (2) The routers do support site-local.  Site-local prefixes may
                 be advertised, and site-local traffic will be routed
                 within the site.

In both cases, the hosts will behave exactly the same, with different
results.

In the first case, the host will not receive any router advertisements
containing site-local prefixes, so it won't build site-local source
addresses.  Since site-local isn't supported in the site, the host 
should only receive global destination addresses, and will use global
source addresses to send to them.  In the event of a configuration error,
the host might receive a site-local destination address.  In that case, it
would treat the site-local destination as global and use a global 
source address.  The destination address would not appear on-link to the 
host, so the packet would be sent to the default router where it would 
be discarded (probably with a scope exceeded ICMP error, unless we invent
a new one).

In the second case, the host may receive router advertisements from the
router containing site-local prefixes and configure addresses of the form 
"<SL-prefix><IID>".  However, the host will think that these are global
addresses (just like it would treat any currently undefined portion of the
IPv6 address space).  When a host with both site-local and global
addresses configured (all treated as global) receives a global destination
address, the longest-match portion of the address selection rules will
result in choosing a true global address (not a site-local address).  When
a site-local destination is chosen, a site-local address will be preferred,
for the same reason.  If both site-local and global destinations are
available, either might be chosen as a destination -- the host would not
have any reason to prefer one over the other.  

I think this works fine...

The current source address selection document could be simplified to 
remove any special handling for site-local, but a separate document could
be written explaining how a more sophisticated set of selection rules
could be implemented on hosts that are aware of site-local addressing.

Margaret

---

From: Alain Durand <[email-masked]>
Date: Wed, 19 Jun 2002 11:31:25 -0700

On Wednesday, June 19, 2002, at 11:00 AM, Margaret Wasserman wrote:
[...]
> If both site-local and global destinations are

So you are actually suggesting a paradigm change from the model where
hosts implement a mechanism (address selection) to enforce Site Local use
whenever possible to a model where application knowledgeable
about site local scope may decide to take advantage of it when available.
Am I right?

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Jun 2002 15:19:33 -0400

> have any reason to prefer one over the other.  

not so, because the address chosen may get used in other
contexts besides that of the immediate source and destination.

the idea that a host can reasonably choose from among addresses based
on looking at only the sources and destinations of a single host pair
does not hold.

Keith

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Jun 2002 14:54:32 +0700

Date:        Wed, 19 Jun 2002 09:32:10 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | If site-local addressing is "really insurance", and may "fade away" later,
  | would this be an argument for:
  | 
  |          - Moving site-local out of the base IPv6 specs

No, insurance is only useful if you have it from the start.  Planning
to leave it in the background, and then pay for it after things break
simply doesn't work...

  |          - Making site-local implementation optional?

That one I have no problem with.   If implementations don't want to
bother with it, or with all the possible ways they can be used (mult-site
nodes, etc) that's just fine.

For some uses I would have no problems using nodes that don't support
SL addressing, for others, such an implementation would rule itself out
of contention immediately.

On the other actually requiring multi-site nodes is something that I
might never need (and very few sites might) so that one might become
more of a speciality item.

kre

ps: I also agree with (I think) everthing that is in Tim Hartrick's message.

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Jun 2002 15:22:44 +0700

Date:        Wed, 19 Jun 2002 11:07:10 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | but it depends to some degree on how LL is pitched to the public.

Yes, exactly - and one of its planned uses (right from day 1) was to
support "dentist office" networks - perhaps more likely these days
as "IETF attendees on a bus" (not a plane as using 802.11 there is
probably frowned upon, I haven't risked trying it to see if anyone
would notice...) who just happen to create an ad-hoc network, with
no external support at all.
 
  | I don't think use of LL by apps is a good idea for either v4 or v6.

To eliminate this completely, you need to find a way to assign a global
address with no delay (no more than a minute anyway) and no network
connectivity required to obtain it.   I think that means a well known
prefix - which is exactly what the SL prefix is.   So if you really
want to prevent this usage of LL's, I think you not only have to support
SL addresses - but actually make implementation of them mandatory.

I'd just keep SL support optional (require as little as possible) and
have the apps deal with LL addresses when the situation arises.

  | the danger is that SL addrs are clearly meant for use by apps, while
  | it can be argued that LLs aren't meant for GP use.

You could try arguing that, but you'd be arguing against the design.

  | ISPs that pull that kind of stunt deserve to go out of business quickly.

Unfortunately, that requires the customers to desert, quickly, which requires
yet another renumbering.

And remember, that while an ISP could do this as a stunt, the more likely
cause is going to be the network (via a nanog or similar meeting) deciding
that the routing table is simply getting too big, too fast, and that some
realigning of addresses is required to allow topological aggregation to
work again with the network configured in the state that it has developed
into at the time.

That is, it isn't a "stunt".   And while you can argue that such a
change should be properly planned, my counter is that no amount of
proper planning is sufficient - I want connections to be able to
exist where the address will *never* change (other than at my specific
demand - no-one else can ever instigate it).

  | to some degree this is govered by public perception about what is 
  | reasonable, and such perception can be influenced by standards.    
  | so we do have some influence here.    we should try to use it.

Yes.  To do that in an honest way, we first need to decide how to
avoid requiring addresses with either topological or geographical
significance (both of which require renumbering sometimes).
The original (70's-80's) IP allocation scheme would be OK (allocate
1 2 3 4 ... to however asks in the order they ask).   Just make routing
work with that.   Or, propose something else.

  | there's no way to absolutely
  | prevent brain-damage like unannounced renumbering,

I am not worried about unannounced renumbering, but *any* renumbering.
Announced 5 years in advance or not...

  | easiest way to fix this is to have NFS (and those other apps) use mobile IP.

Doesn't work.   That requires a stable address to use as the home agent.
And if the net has been renumbered, the stable address doesn't work.

If we had designed good EIDs instead of just having addresses, then mobile
IP would have been almost a no-brainer.   (And so would renumbering,
mobile-IP then just treated as one reason for renumbering).

But we didn't, and now mobile-IP depends upon stable addresses just like
everything else (it trades off one stable address for another).

  | I don't think it flies as long as we're requiring sites to connect
  | to the public net to get global addresses, and some sites don't want to 
  | connect  to the public net at all.

Hmm - maybe I'm not being clear, or you just missed my point.   No
requirement for a site to connect to the public net, certainly.
A site that isn't connected just uses SL addresses as if they were
global addresses (they go in its disconnected DNS - or however it does
address lookups) and are used exactly like anyone else would use a
global address.   The site boundaries are the ends of the net as we
know it, so there's no magic at all here.

To allow two disconnected sites to communicate, they need either
global addresses (in which case they're just becoming another internet
and as many sites as like, and are permitted, can connect to that, instead
of the public net) or we need some kind of site ID in SL addresses
(and in the latter case, they just go on acting as if they were global,
in the former, SL's are the same as SL's on the public net, and there
is a global address to use to make the SL's work).

Groups of sites, talking to each other, but disconnected from the "one
true internet" is something that the current addressing plans really
haven't allowed for, and should.

  | with global non-routable addresses, the site-id is carried along with the
  | address, it's exposed as part of the address (assuming a reserved prefix
  | for such addresses), it's returned in the same kind of DNS RR that carries 
  | a normal address.    the address is globally scoped so there is no chance 
  | of mistaking an address from a remote site as being one from a local site 
  | or a different remote site.

But there's no way to tell from the address that it is one that you
cannot reach from outside, which makes it annoying (at best) to pass
around.

Of course, we could have such addresses marked by a magic prefix, that
people could recognise.   Then there'd be no problem.  And of course, that
is exactly what a SL address with a site-id in it is.   (Note: I think
I'm one of comparatively few people who actually support site-id's in
SL addresses).

  | again, I don't think that flies.  too many enterprise nets are not 
  | connected to the public internet have no way to get globals.
  | in the current IPv6 view, they have no way to get global IPv6 addresses .

See above.

  | even if they borrow a prefix from somewhere, those addresses won't 
  | really be global in the sense that they're reachable from elsewhere.

If the site is not connected, then "reachable from elsewhere" is a
pretty meaningless concept.   If a "borrowed" prefix is what it takes
to make things work in some rare cases, then that's exactly what
people will do.   If renumbering out of it into a "proper" address is
not too hard or disruptive, then they will do that too when they connect.

But borrowed or a true advertised topological global address, wouldn't
matter (in the very rare case that such a thing would be needed).

  | But it seems to me that if we do have these, we don't need SL anymore.

We don't need SL with the bit pattern that we have, but non-routable
global addresses would just be the same thing for most purposes (just
avoid the scope issue in the API etc).   So would SL's with site-id's.

  | perhaps (and I probably agree), but right now we're insisting on just
  | the opposite.

You mean in IPv4?   Yes, that need to be corrected.   If you meant
IPv6, then I don't understand what you're trying to say.

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 11:22:27 -0400

> no external support at all.

okay. but there's a fairly fundamental conflict here between this 
use of LL (in a network that will never be connected to the internet)
and the use of LL on a network that is only temporarily disconnected
from the internet.  apps need to know which kind of address to use.
if they start assuming an LL-only network they won't be able to 
send referrals to nodes outside that network; if they start assuming
a network with globals they won't be able to send referrals to 
LL-only nodes.   and to try to use both kinds of addrs requires that 
the  app know about network topology.

bascially LLs and SLs create a big mess (if apps use them at all)
and don't provide any good way to solve those problems.  of course,
many apps don't do referrals and don't have any problem with LLs
or SLs (other than the problem of using LLs on a multiple-interface
box) but some apps do, so when you use LLs and SLs for apps you get
the confusing situation where some apps work (so the network is "up")
while others fail in odd ways.

I don't know how to solve this problem entirely, but I think it
can be minimized by discouraging use of LLs when they're not needed,
and by replacing SLs with a better mechanism.

I do see a use case for LLs but I think we could provide SL-like 
functionality in a better way which was less confusing to apps,
and at the same time solve the problem of allowing isolated networks
(not having provider-based addresses) to privately interconnect to 
other networks without NAT.

> Unfortunately, that requires the customers to desert, quickly, which requires

well, if the customer is being forced to renumber, then the customer might 
as well switch ISPs at the same time...

> work again with the network configured in the state that it has developed

well, one hopes that nanog or whoever provides adequate advance notice,
and that they don't try to force everybody to renumber at once.
management of this kind of change will be tricky and I don't think anyone's
demonstrated how to do it yet.
 
> proper planning is sufficient - 

surely being able to plan for this for weeks or months causes
fewer problems than having 24 hours notice... though I don't pretend
that we're anywhere close to having entirely painless renumbering 
no matter how much notice is given.  (like 'painless dentistry'
there is no such thing...)

> I want connections to be able to

yes, I understand that use case.  I just think that there are better
ways of providing for it than SLs.  

and I'm not saying we should forbid hosts or sites or apps from using
SLs, nor that we should reallocate those addresses for other purposes -
but I think we would do well to provide a better way to solve this
problem and to recommend that non-routable global prefixes be used
in preference to SLs.  that way, apps wouldn't need to try to deal
with SLs specially.

> work with that.   Or, propose something else.

don't even try to solve the problem of routing these things and accept
that (at least for the time being) that addresses used in the public
internet still have to be based on topology.  have icann set up a 
web page to request a non-routable prefix which explains the limitations
of such prefixes, accepts a credit-card # (for a one-time fee to 
cover the cost of maintaining the registry and web page only) and 
then assigns a prefix.

another idea is to allow sites to pick their own in a 6to4-like
fashion, say by taking some well-known prefix, appending an
ethernet (or other) MAC address from a device in their possession,
and then the rest of the bits are theirs to play with...
two problems with that approach: 1) you probably end up with a
/64 prefix which might be a pain for some sites, 2) the site can't
sell the device with that MAC address to some other site :)

> know it, so there's no magic at all here.

such sites often want to connect privately with other networks,
though not to the public net.  SLs aren't good for that.

> global addresses 

right, but to get those they (currently) need to connect with the
public network, which they don't want to do.

> haven't allowed for, and should.

agreed.  and note also that some of those sites may be connected to the
public network (not providing transit for the others), while others
aren't connected.

> cannot reach from outside, which makes it annoying (at best) to pass

assuming a reserved prefix, an app could tell a non-publically-routable
(NPR) address from a 'normal' address.  but it still would have a difficult
time knowing whether the address was usable to a random peer.  
as I said, it's better than SL, but it still doesn't solve all the problems.

Keith

---

From: Robert Elz <[email-masked]>
Date: Mon, 24 Jun 2002 00:19:03 +0700

Date:        Fri, 21 Jun 2002 11:22:27 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

I think this discussion is mostly over (for now), so I will respond
to just one point in your message, and leave the rest for
perhaps some other time...

  | okay. but there's a fairly fundamental conflict here between this 
  | use of LL (in a network that will never be connected to the internet)
  | and the use of LL on a network that is only temporarily disconnected
  | from the internet.  apps need to know which kind of address to use.

Hmm - I think apps (&/or the system, or something) need to be able to
do something here (if they're the kind that survive long enough for
changes to occur).   Things like MTAs, DNS servers, ... all do already
(or do if they're worth using).

That is, it is entirely likely that a node will power up with no net
connected (hence no global addresses - v4 or v6), and apps will
start running.   Later it connects to a net, and globals appear.
Later still, the net goes away again, and the globals expire.
When the net comes back again, the global addresses that reappear
may be the same as before, or they might be different.

All this happens all the time - as things are now (regardless of whether
scoped addresses exist or not).

Apart from simply refusing to work if a global addr isn't available
(as distinct from being able to contact some remote site, which is
kind of inevitable) apps really need to be able to deal with things
like this.

Like it or not, the world has changed in the past 20 years - your
typical internet node is no longer a half ton (or more) beast that
runs forever, and never turns off or gets disconnected.   Apps, and
app designers just have to adapt - regardless if this means doing
more work.

kre

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Jun 2002 13:45:05 -0400

indeed.
 
> kind of inevitable) apps really need to be able to deal with things

agreed.  apps really do need a way to deal with things like this.
unfortunately, they don't have a good way of dealing with things
like this, and it's not at all clear that placing the responsibility
with the apps to deal with things like this is architecturally
sane.
 
> Like it or not, the world has changed in the past 20 years 

indeed it has (and along with it the net), and this is the entire 
point.  the net has changed in such a way that it doesn't support
some kinds of applications very well.  at the same time, we have
an even greater desire to support those kinds of applications.

> - your

it's not at all clear that the problem can be solved effectively
by placing the burden on the apps - in fact it's clear that the 
problem *cannot* be solved effectively merely by expecting apps 
to do "more work".  

like you say, the net has changed in the past 20 years, and the days
in which somebody could make a change to one aspect of the net and 
claim that whatever difficulties those changes caused are somebody 
else's problem, are long gone.  

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 14:16:22 -0700

Keith Moore wrote:
> ...
> is just a fantasy.

Clearly you still live in the fantasy land where pleanty of addresses
were handed out 20 years ago, the birds sing, the air is always clean,
and the sun always shines... Changing prefixes is the new reality. I
know first hand as my ISP recently changed their subnet prefix &
allocations overnight without bothering to inform anyone.

Tony

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2002 14:21:57 -0700

> and the sun always shines.

is your point sufficiently weak that you need to spout this <bleep>?

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jun 2002 17:43:22 -0400

> allocations overnight without bothering to inform anyone.

Tony,

This kind of statement is a personal attack and it has no place in IETF.

Also, you apparently need to reread what I wrote, because you missed
it the first time.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 15:03:09 -0700

> Also, you apparently need to reread what I wrote, because you missed

It was not intended as a personal attack, but I agree it can be read
that way so I apologize for any misunderstanding.

The statement I was responding to was "the idea that a prefix can be
changed at a whim is just a fantasy.". The point is that arbitrary &
random prefix changes are reality and believing it doesn't happen is the
fantasy. While it is nice to believe that providers that do this are
subject to customer retaliation, where are the customers going to go? If
the SP otherwise provides the best service available (or increasingly
the only service), the renumbering even is a fact of life.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jun 2002 18:31:49 -0400

> fantasy. 

Okay, let me rephrase that:

The idea that a prefix can be changed at a whim without having a serious
impact on the reliability and performance of applications is just a fantasy.

People who think that DNS is a sufficient replacement for stable IP
addresses haven't actually bothered to look at how poorly DNS works, 
how ambiguous and unstable DNS names can be in practice, how quickly 
apps could expect to recover from address changes (especially when the 
zone servers themselves have moved).  Nor have they investigated the 
burden of expecting apps to implement explicit app-level acks for 
everything that gets sent over a TCP stream (so that the app can recover 
from a connection broken by renumbering), because without such acks
the app doesn't know how much data has actually been read by its peer.

> While it is nice to believe that providers that do this are

I don't disagree with that - in fact I currently have to live with an
BRI ISDN connection to my house because no provider that can provide
higher bandwidth is willing to give me a stable IP address.

But just as we cannot force providers to be reasonable, neither can
we force applications to work under unreasonable conditions.  The best
we can do is to try to define what is reasonable and what is unreasonable.

Keith

---

From: "Vijay Amrit Agrawal" <[email-masked]>
Date: Fri, 28 Jun 2002 10:17:18 +0530

Hi,
.
Aren't we suppose to have sufficient IP address so that each can have
globally unique address? If that is the case, can't each user get his/her
own IP address without bothering about renumbering in the service provider?
Why are we trying to constrain the end user, to solve the routing problem?
IPV4 doesn't work well with NAT. We are trying to address many limitation of
IPV4 in IPv6. Why not try to make IPv6 such that, it can work well even when
technology like NAT is deployed i.e. the end address is different from the
transport address. Any way we are modifying application, won't it be better
if they are modified in more flexible way.For example: We use one address to
address the end systems, this
address has certain bits that are unique globally, but certain bits that are
used only for routing and can take any value depending on the routing path
that exist at that moment? When somebody uses a new service provider, the
upper bits are changed by the gateway routers (or by the routing component
in the host itself by doing a dns queery), and since the end systems
don't use those upper bits at all, they could care less who is the service
provider? In telephone system we have the countrycode-areaCode-number, may
be for Ip we need
serviceProviderCode-countryCode-areaCode-number. When we want to ping or do
any such thing, we keep the service provider code as zero or something
else. Address aggregation can be done at service provider code or using
country code or any other combination.(May be in IP world we would use
domaincode like.com, .edu instead of country code so the address also
reflect the DNS hierarchy).
There can be many other use of separating the transport address from the end
address as there are advantages of decoupling them (one can argue that the
dns name are the end address but a string doesn't usually form a good thing
for end address).
 One can also have certain bit in the transport address (or can be in
ipHeader) to indicate that this packet is from a customer and service
provider may treat this packet differently.
Regards,
Vijay

---

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

> Why not try to make IPv6 such that, it can work well even when
> transport address. 

the problem with NAT isn't just that the address changes in transit;
it's also that NATs split up the network into multiple addressing 
realms and make addresses ambiguous.  there's really no way to solve
that problem.

Keith