Subject: comment digest

From: Keith Moore <[email-masked]>
Date: Tue, 26 Aug 2003 22:31:33 -0400

contents:

On list bandwidth and message volume
On the "need" for "local addressing"
On use of link-local addresses by IPv6 applications
On address selection policy
On "solving the right problems" and the layer of indirection
On "The IETF doesn't tell people how to run their networks"

----------------------------------------------------------------------
I. On list bandwidth and message volume:

This message is an experiment.

Some people have expressed concerns about the number of messages being sent to
this list.  Personally I think we have a tremendous amount of work to do here,
and I don't see how we can accomplish that much work without a high-bandwidth
discussion.  However I am sure that there are better ways to make use of the
bandwidth we have than to have very long threads where we argue about minute
details of each other's musings.  (On the other hand, if we make independent
statements rather than following up to each other's statements, this imposes
its own barriers to closure.)

For now I've decided to try to respond to several points in a single message
to be sent out approximately once per day (for the days I  read mail, which
isn't every day).  I might also send out some individual messages or replies,
but presumably fewer than before.  I'll probably also put a few of these
summaries on web pages so that in the future I can refer to them by URL and
not have to repeat them.

I'm interested in hearing (via private mail) how well this works for people. 
I will probably vary the format a bit depending on the feedback I get.  

One request: if you do choose to respond to the list about something in this
message, please pick a meaningful subject rather than the global subject of
this message.

----------------------------------------------------------------------
II. On the "need" for "local addressing"

Several people maintain that network admins will insist on local addressing. 
A few have countered that network admins are quite aware of the problems
associated with local addressing and NATs in IPv4.

I'm wondering if this is essentially a tools and/or a marketing problem.  That
is, maybe we need to

a. standardize the addressing solution that makes the most sense for support
   of applications and actual operations,

b. provide tools that make it easy and foolproof to restrict access and/or
   hide networks that aren't supposed to be externally visible, and

c. market these addresses and tools in such a way that they'll sound like "the
   right thing" to network admins, and especially, their bosses.

Of course, IETF is not a marketing organization, but that doesn't mean
we have to ignore human nature. 

So if we need to slap the words "local addresses" in some document title, and
then explain how GUPIs or PUPIs or whatever serve that need, for the sake of
appearances, let's do so.  And if we can find a way to make it easy to get the
configuration right at the borders of a network beyond which PUPIs aren't
supposed to be visible, fine - as long as we're not placing a huge burden on
hosts or apps.  

But when we're talking among ourselves, it seems (on a technical level) better
to avoid the complexity that comes with firmly associating a single specific
and fairly arbitrary network boundary with an address format.  And it seems
clearer if we use a less-loaded term than "local addresses" when talking among
ourselves - even while we acknowledge that blocks of these addresses will
sometimes (perhaps often) be confined to enclaves.

(Personally I suspect the idea of the "site" with definite boundaries is
something of an anachronism - since I'm increasingly hearing of cases where
people are pulling their hair out trying to glue together separate "sites"
with NATs and make the result look seamless.  But I don't want to overlook
the hazards of poor marketing.)

----------------------------------------------------------------------
III. On use of link-local addresses by IPv6 applications

I think I've said most of this before, but a summary might help.

I see several general problems with the use of link-local addresses by apps:

1. By design, they won't route outside a single link, but even for small ad
hoc networks or home networks we're seeing a mixture of link technologies in
use.  Yes, you can sometimes bridge them, but not always, and bridging
introduces its own set of problems. 

2. Not all apps can use them, and many of those that can use LLs cannot use
them in all conditions, depending on (to users) obscure details of the way the
network is organized.  It would be better if small networks behaved in ways
that ordinary users could understand and predict.

3. Of the apps that can use them, sometimes you have to configure the app to
behave differently depending on the network configuration.  For instance,
under normal circumstances you might want the app to ignore LL addresses, but
if it's running on an isolated single-link network then you might have to
configure the app to use them.  And in general you can't expect the app to
detect this.

4. A network that is initially single-link might acquire some external
connections and routing capability, and transitioning apps from LL to another
kind of address (so that other nodes can participate in existing apps) is
disruptive.

That, and we need a solution for self-organizing networks anyway, and there
seem to be good reasons to treat a single-link network as just a component of
(or a trivial case of) a self-organizing network.

Granted, we don't have the technology for self-organizing networks yet.  In
the meantime, people will have to cope with whatever is already there.  But
think our efforts are better directed toward making self-organizing networks
function well than to try to make LLs be the solution for such networks.

----------------------------------------------------------------------
IV.  On address selection policy

I don't think making the policy settable on a per-stack basis is a good idea
because different apps have different needs, and a policy that is appropriate
for one app will prevent the operation of another app on the same host.  Also,
it's another knob that users have to understand and that tech support has to
deal with.  

I don't think letting each link specify policy is a good idea, partially
because a reliance on address solution (at least, as it's currently
envisioned) makes referrals more difficult for apps, but also because a host
might quite reasonably be connected to more than one network through more than
one interface, and the policies of the various networks can conflict.  And
again, different apps need different policies - some need to favor stability
over response time, some vice versa.  It gets very complex to sort all of this
out.

Besides, I think we can develop better mechanisms than either of these.

"Chirayu Patel" <[email-masked]> wrote:

> If you are using an automated mechanism, as I had suggested, getting
> conflicting policy from different interfaces implies that something
> wrong with the network engineering.

I don't think so, because of the liklihood for a host to connect to different
networks.

Chirayu also asked for a clarification on this bit that I wrote:

> per-link policy is the wrong way to think about this.  what you want 
> is for each network to be able to say "here's the best way to get
> here from there given a variety of conditions"... and then minimize
> the number of conditions.

I admit this is a bit vague, and it's not fully developed.  I have been
looking at various scenarios for connecting networks - some of them
core-connected with PA addresses, some of them not core-connected but with
interconnections to other networks; some of them self-organizing, others with
managed routing and assignments; some of them fixed, some of them mobile; etc.
 The possible interconnections in between them are almost arbitrary (and these
interconnections might or might not allow transit through the network). The
interconnections will change over time and the networks will sometimes have to
transition from one kind of address to another, and sometimes they'll have to
deal with multiple kinds of addresses, but you want this to work as smoothly
as possible.  Then you have to consider what the world looks like to apps
running on these networks that are using a variety of kinds of address space. 
And finally you have to decide at what point the app's responsibility ends and
the network's responsibility begins (or the other way around if you're used to
looking at things from layer 3). 

Anyway, by "minimizing the number of conditions" I really meant minimizing the
number of prefixes, and types of prefixes, that a host or app or network has
to deal with, to the minimum required to do the job.  The more prefixes we
have to choose from, the harder it is to make the right choice, and the more
ways we have for things to fail.  By "here's the best way to get there from
here" what I meant was that the problem of host A figuring out how to send to
attachment point B looks a lot more like a routing problem than an address
selection problem.  And once again, routing is a lot less confusing if you
have a (more-or-less) uniform way of naming points in the network. (years of
struggling with trying to weave uucp and DECnet and BITNET and Internet mail
together into a coherent whole convinced me of that)

Sorry, that's still vague.  I'm working on a better explanation.

----------------------------------------------------------------------
V.  On "solving the right problems" and the layer of indirection

This is another attempt to summarize, that may end up on a web page.

One reason that I maintain that the layer of indirection to support mobility
has to go between layer 3 and 4 is that if a TCP connection breaks due to a
prefix change, the app has no way of knowing how much data got to the other
end.  It doesn't see the TCP-level acks, and even if it did, those acks only
mean the data got to the destination host - it doesn't mean the data got to
the app.  So you really need the indirection layer to go below TCP so that
TCP's error recovery can handle the case where you lose data due to a prefix
change.

However I don't see lump prefix changes that happen due to your network
changing connectivity in the category of "mobility", and I don't think of
address selection or prefix substitution as examples of mobility either.  If
you had a layer that tried to hide the details of which address to use from
apps, IMHO it would be just below layer 7. (Though as far as I can tell, it's
more confusing and disruptive to try to hide those details from apps than to
give them good APIs to deal with them explicitly.)

So to me it seems to make sense to treat "mobility" (where your network
disconnects from one point of the network and reconnects to another, probably
because it's moved through physical space) very differently than changes in
network connectivity or policy that might require migrating to a new kind of
prefix but don't necessarily break existing signal paths.

At any rate, it might be that this is the crux of this particular disagreement
between me and Tony.

----------------------------------------------------------------------
VI.  On "The IETF doesn't tell people how to run their networks"

Tony says that "The IETF is not in the business of telling people how to run
their networks" but of course that's wrong - the very purpose of IETF is to
specify how networks are to be operated, at various levels of detail.  There's
little point to TCP or IP if higher-level protocols can't make any
expectations about what services the network will provide; and none of our
widely-deployed apps would be nearly so successful if apps couldn't make such
expectations.  Both email and the web, for instance, depend heavily on the
expectation that there's a large "core" Internet that looks flat to the
periphery; this is the fundamental assumption that allows for the exchange of
email and the ability to access web pages between domains with no prior
arrangement.

Of course IETF doesn't demand, for instance, that you permit a certain kind of
traffic on your network, or that you provide transit for third party traffic
across your network.  But neither can you expect your apps to work if you
organize it in an arbitrary way or impose arbitrary constraints on what your
network does.

One way to describe IETF's job (relative to IPv6) is to define the behavior of
the network such that apps will work well.  Of course, we have to be realistic
about what we expect of the network, and this necessarily involves a
compromise.

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

--------------------------------------------------------------------
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: Leif Johansson <[email-masked]>
Date: Wed, 27 Aug 2003 08:15:37 +0200

If people like the idea of keeping (carefully worded) arguments and 
discussions on
web-pages this might be an apropriate job for a wiki. Just a thought.

~       Cheers Leif