Subject: RE: Proposal for site-local clean-up

From: Dan Lanciani <[email-masked]>
Date: Mon, 18 Nov 2002 22:49:42 -0500 (EST)

Erik Nordmark <[email-masked]> wrote:

|Being the probable guilty party for introducing this thought back in
|draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.
|
|I don't think stable addresses per se is the key thing - it is
|the robustness of the communication that is important.

Given that nobody seems to know how to make communication (as many applications
currently understand/use it) robust in the face of _unstable_ addresses it isn't
obvious that this distinction is of much utility.

|This robustness has at least two factors that are relevant in this
|discussion: the stability of the addresses, and the leakage of
|non-global scope addresses.  I think the question is how to weigh those
|together.

Ok, but it isn't clear that these two factors are of even remotely similar 
weight.  Leakage is a problem that can be addressed, but there are a lot of
things that simply will not work without stable addresses (at least not without
a complete overhaul of many higher-level protocols).

|In terms of the stability of the addresses one has to take into account
|both stability as it relates to local communication and stability for
|global communication.

We have always been told that stable global v6 addresses will not be available
to end users, or at least will not be available to end users at a low cost.
Unless you are proposing to revise the whole address allocation architecture
*and* have a way to force ISPs to change their business models I think we must
accept this as a given.

|If you assume that the value/importance of local
|communication is much higher than the value/importance of global communication
|then site-locals make sense to explore.

I think you have made an unreasonable leap by dropping the "stable" qualifier.
The value/importance of _stable_ local communication is almost certainly much
higher than the value/importance of _stable_ global communication.  We already
accept that sometimes when we click a link in a browser things go wrong and we
have to try again.  Protocols like SMTP that drive global email assume that
almost anything can go wrong and have the capability to queue messages for days
if necessary.  But my NFS client is simply not prepared to have its server's
address renumbered out from under it.  My multi-hour build will fail unless
I notice the problem and fire up adb on the kernel in a hurry.  Similarly my
print job will fail if the printer and/or client is/are renumbered in the middle
of a tcp session.  My distributed home automation system, while quite tolerant
of temporary lost connections and machine reboots, can not deal with addresses
changing out from under it.  This is hardly unreasonable because the tools to
deal gracefully with such situations have not yet been invented.  To make such
things work now each application would have to implement its own procedures to
deal with unstable addresses.  This is obviously not acceptable to application
writers.

|(FWIW that was my assumption
|way back).
|Such an assumption might make sense we say that a site is an
|administrative concept (such as a company), but it makes less sense
|if a site is a geographic concept and as I understand the original
|thoughts a site was intended to be a geographic concept like a building
|or a campus.

We understand that sites are administrative.

|In any case, for a home user I suspect that the value/importance of
|local communication would typically be less than the value/importance
|of global communication.

Again assuming we are talking about _stable_ communication, I believe that 
you are incorrect.  Granted those of us who depend on our home networks for
automation and such are currently on the bleeding edge, but what about the
future when every stereo and tv is on the net?  It's one thing to have to
re-click that remote link in the browser, but quite another to have your
stereo refuse to change channels.  Consumers are not going to pay their ISP
a premium to keep their stereos working.  I know it sounds nice in theory,
but look what happened to Divx.  If you take away scoped addressing we _will_
use NAT.

|Thus the ISP offering a service with unstable
|global addresses I don't think it would be that satisfactory
|for the peer-to-peer communication that we wish to enable with IPv6,
|even if there are stable site-local addresses so that the user can
|communicate inside their home without a glitch.

I'm having trouble parsing the above.  ISPs currently offer unstable v4
addresses (unless you pay extra) and they aren't satisfactory for the
peer-to-peer communication we used to have back when address space was
portable.  People have worked around this with various application-level
kludges.  You obviously recognize that stable addresses have value, so
I don't understand why you expect that ISPs will suddenly stop charging for
that value.  Depriving users of the tools necessary to make productive use
of their networks without paying for stable globals for all internal nodes
will just encourage yet another round of kludges.

|So let's not loose sight of the fact that the goal is a robust network.

I think that the goal is a useful network--useful not only for ISPs and
application vendors but for consumers.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: Tim Chown <[email-masked]>
Date: Tue, 19 Nov 2002 13:15:24 +0000

> to end users, or at least will not be available to end users at a low cost.

Told by who?  I can see ISPs wanting to charge for extra services where they
can, and thus for a static /48 as they do now for a static single IPv4
address.  But I would hope that enough ISPs would offer free static /48's
to take custom from those who charge.   The only "snag" is that such ISPs
with 10M customers would need a lot more than a /32, esp. taking into
account the HD-ratio.

Tim

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Nov 2002 11:20:56 -0500

> things that simply will not work without stable addresses (at least not 
> without a complete overhaul of many higher-level protocols).

Agreed that stable addresses are necessary, but experience suggests that 
it is very difficult to 'address' leakage of addresses.  Every application 
is another path by which addresses can be leaked.  For that matter, so 
is every mobile host.

> to end users, or at least will not be available to end users at a low cost.

I think this depends on what you mean by "stable".  For some reason the
community has been reluctant to specify a number here, and the result
is that people have widely varying ideas about what we can expect in practice.
I don't think we want to let the reliable operation of applications be
an accident, nor do I think we want to trust market forces to sort this
out. 

> *and* have a way to force ISPs to change their business models I think we must

I don't think it's necessary to "force" anything, and casting things in these
terms makes them seem more difficult than they really are.

> higher than the value/importance of _stable_ global communication.  

No.  You erroneously assume that different applications are used for local
and global communications, and you are over-generalizing the case for 
stable global communications from two very specific cases.  Too many people
think that the Internet only needs to support web and email.  If that were
the case we wouldn't need IPv6 at all.  

The 'local' versus 'global' distinction is a false one. I run NFS over TCP 
over IPv6 over long distances, and it works.  And yes, I'm screwed if 
my ISP changes my IP address (fortunately they have agreed to not do that).  
I also regularly send print jobs over the same connection.

> but look what happened to Divx.  If you take away scoped addressing we _will_

Threatening to destroy the utility of IPv6 if you don't get your way 
won't get you much support here.  Perhaps you should take another tack.

> that value.  

I don't understand why you expect that ISPs will treat v6 exactly the
same as v4, when if they do it this way there is no reason for their 
customers to pay for this additional service.  perhaps ISPs will charge 
more for v6 than for v4, and they'l claim that they're doing so because 
v6 addresses are stable.   

> Depriving users of the tools necessary to make productive use

Bottom line is that we need addresses to be (reasonably) stable at both
the local and the global level.  It's not sufficient to just have stable
local addresses - especially given the problems that SLs cause. 
 
> application vendors but for consumers.

I don't think anyone would disagree with that - but that doesn't mean that
a network with SLs is more reliable/useful than one without.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Nov 2002 21:05:58 +0100 (CET)

Sorry for the delayed response - didn't see me in the to: or cc: fields.

> We have always been told that stable global v6 addresses will not be
> available to end users, or at least will not be available to end users at a
> low cost. Unless you are proposing to revise the whole address allocation
> architecture *and* have a way to force ISPs to change their business models
> I think we must accept this as a given.

The temporal stability of addresses have a temporary component - it isn't
black and white.

Crystal ball:
I wouldn't be surprised if small sites renumber the IPv6 addresses once
a year with an overlap (both new and old working for a week perhaps). 
I see no reason why one would ever want to change them once a day.

Taking together globally things means that there will be lots of renumbering
in progress at any given time (given millions of sites and a reasonably long
overlap).

Thus I'm not too worried about e.g. my home site changing IPv6 prefixes
all the time. Of course, there is a concern for applications which keep
a connection open for a long time (weeks), but I suspect that such applications
are, or need to be, capable of reconnecting since they need to be able to deal
with peer failure.

> I think you have made an unreasonable leap by dropping the "stable"
> qualifier. The value/importance of _stable_ local communication is almost
> certainly much higher than the value/importance of _stable_ global
> communication.  

Even with the "stable" qualifier my opinion is the same. 
You are welcome to disagree.

> But my NFS client is simply not prepared to have its server's
> print job will fail if the printer and/or client is/are renumbered in the
> middle of a tcp session. 

You seem to be assuming flash renumbering without overlap.
With a one week overlap when a site gets renumbered by its ISP
your two week long build might require a umount -f for NFS, and
your petabyte print job (that takes > 1 week to send to the printer)
might fail.

> My distributed home automation system, while quite tolerant
> of temporary lost connections and machine reboots, can not deal with
> addresses changing out from under it.  This is hardly unreasonable because
> the tools to deal gracefully with such situations have not yet been
> invented.  To make such things work now each application would have to
> implement its own procedures to deal with unstable addresses.  This is
> obviously not acceptable to application writers.

And the tools to deal in a robust manner with multiple-scopes of addresses
have not been applied to your home automation system either.
To be it makes more sense to get applications to 
 - not cache DNS answers forever
 - be prepared to restart connections after redoing a DNS lookup 
   if the connections are open for a long time (days or more).
I think this is less work, since many applications can get away with
doing nothing, than having all applications handle different scope addresses.

> We understand that sites are administrative.

Section 4 in draft-ietf-ipngwg-scoping-arch seems to say something differnet.
A site doesn't span multiple administrations, but it is limited
to a single geographic location, such  as an office, an office complex, or 
a campus. 

> application vendors but for consumers.

Agreed. I don't think I was saying anything different.

  Erik