Subject: RE: A follow up question

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

John C Klensin wrote:
> I want to leave most of that discussion for some ARIN-related 
> list, as David Conrad suggested.  

I was certainly not trying to pick on ARIN, because there is wide
perception that they are fairly liberal in their IPv4 policy. I agree
that allocation policy discussions belong elsewhere.

> But, for the record, I was 
> trying to dodge the question of whether address space 
> exhaustion, by itself, was  "strong enough" or "sufficient" 
> reason to get IPv6 deployed and, especially, to avoid the 
> rathole-populating discussion about alternatives.  Since I am on 
> record as believing that, by some reasonable measures, we have 
> already run out of address space and IPv6 is not yet widely 
> deployed, I would suggest that we have a solid example that it 
> has not [yet?] proven to be sufficient.

Yes it is not widely deployed yet, but that does not mean lack of IPv4
space is not a sufficient reason. In several active deployment cases I
am aware of, going as fast as they can, it takes 3-5 years to get to the
point of delivering a stable commercial grade service. It should not be
surprising that we don't see wide scale deployment yet, since the
realization that we are effectively out of IPv4 space has only hit home
recently. 

> ...
> I strongly suspect that we are using words in ways that results 
> in miscommunication, because I think there is a third 
> alternative.  That alternative may fall into the category you 
> describe as "passing around name objects", or maybe it doesn't. 
> >From my perspective --which is definitely the applications end
> of the stack looking down-- the problem is all about data 
> abstraction.  I'm going to try to switch terminology here in the 
> hope that it will help clarify things.  Suppose the application 
> gets a well-constructed handle, and passes that handle "around" 
> --either to other applications or to different interfaces to the 
> stack/network.  I don't see the application as dealing in 
> topology information by doing that, even if the handle 
> ultimately identifies information that is deeply 
> topology-sensitive and/or if the process that produces the 
> handle uses topological information, or probes the network to 
> develop such information.  The important thing from that 
> perspective is that the application is dealing with the handle 
> as an opaque object, without trying to open it up and evaluate 
> its meaning or semantics (with regard to the network or 
> otherwise).

In general I agree, but the difference of perspective is that ignoring
the fact that the well constructed handle is actually derived from
topology information does not make the issue go away. The only way you
can get the handle you are looking for is to have something below you
sort out the topological reality. I agree the current name service is
not up to the task, and I believe that we need to get that fixed.
Unfortunately it looks like it will take some very crisp architectural
guidance to get the IESG to refocus the DNS related WGs to even discuss
the issues. The sad part is that many of the participants there already
ship or run variants that help address this problem, but they have
agreed not to work on standardizing it.

> 
> >From that point of view, having an application go to the stack
> and say "given these criteria, give me a handle on the interface 
> or address I should use" or "given this DNS name, and these 
> criteria, give me a handle on the address I should use" does not 
> involve the application being topology-aware, nor does it imply 
> the application doing something evil because it picks an address 
> (or virtual interface, or...) without understanding the 
> topology.  The handle is opaque and and an abstraction -- as far 
> as the application is concerned, it doesn't have any semantics, 
> regardless of whether lower layers of the stack can derive 
> semantics from it or from whatever they (but not the 
> application) can figure out it is bound to.

This points out that I have been imprecise by claiming that passing
names are sufficient, all the criteria you would use for local
communication with the stack are the 'name' in the context of my
previous mail. 

As long as the handle stays contained within the machine you are fine.
The problem arises when the app passes that handle to another node,
believing that the topology specific information is already there. If
the blob passed were the same as what the app used to acquire the local
handle, the other nodes would acquire appropriate local handles. 

> 
> If the application is calling on, e.g., TCP, then it might pass 
> some criteria to TCP, or might not, and TCP might either pass 
> enhanced criteria to the handle-generating layer or generate the 
> handle itself.  Again, the application doesn't care -- it just 
> needs to deal with an abstraction of the criteria in application 
> terms.   I think that, from the application standpoint, it makes 
> little difference whether the criteria involve routing, speed, 
> reliability, or any of several potential QoS or security issues.

I agree as long as the app keeps the handle for local use. It can't
assume that handle will have an equivalent meaning somewhere else in the
network. If it wants to pass a handle that it believes has sufficient
topology information for the receiver to directly access the same point,
it needs to understand the topology enough to know that the meaning will
be consistent. Otherwise it needs to pass the original parameters.

> 
> I'll also be the first to admit that we have handled the set of 
> issues this implies rather badly with IPv4 (and they certainly 
> are not new issues).  We have gotten away with it because the 
> number of _hosts_ that need to understand, and choose between, 
> multiple addresses for themselves has been extremely small, at 
> least since routers were introduced into the network 
> architecture.  Because it could mostly be seen as a router 
> problem, applications in IPv4 mostly punted (for better or 
> worse).  Also, since CIDR went in, we basically haven't given a 
> damn when users who can't qualify for PI space can't multihome 
> (at least without resort to complex kludges).   IPv6, with its 
> multiple-address-per-host architecture, turns the problem from 
> "mostly theoretical" to an acute one.  It does so with or 
> without SL addresses being one of those on a host that has 
> public (global or otherwise) addresses as well.

I agree that SL simply exposed the issue. The problems arise from the
mismatched interpretation by the apps, that all 'handles' will be
treated equally by the network, and the reality that the network has
more than a single policy. As you noted earlier, this is not just about
scoping of address reachability, it also applies to QoS and any other
policy related variance in the topology. 

> 
> Finally, from the standpoint of that hypothetical application, 
> the syntax and construction of that opaque handle are 
> irrelevant.  In particular, it makes zero difference if it is a 
> name-string that lower layers look up in a dictionary or a 
> symbol table, or [the name of] some sort of class object, or 
> whether it is, e.g., an IP address.  The only properties the 
> application cares about is that it is a handle that it got from 
> somewhere that satisfies criteria it specified or that were 
> specified for it.

I understand that is what the app wants to see. I am suggesting that in
the absence of a central policy entity that can sort out all possible
topology differences, multi-party apps will need to pass the original
parameter set, and maintain local mappings to the stack handle at each
participant node. Not pretty, but closer to a working solution than
continuing to ignore the reality that the topology is inconsistent.

> ...
> See above.  Applications have gotten away with ignoring that 
> reality because the occurrences have been infrequent -- with one 
> important class of exceptions, we have had few machines with 
> multiple addresses (and multiple interfaces) since routers 
> became common in the network.  The exceptions have been larger 
> web hosts which support pre-1.1 versions of HTTP and hence use 
> one address per DNS name.  But, for them, hosts opening 
> connections to them use the address that matches the DNS name 
> (hence no need to make choices or understand topological 
> information) and the servers either use "address matching the 
> one on which the connection was opened" or an arbitrary address 
> on the interface --since the interface is the same, and its 
> connectivity is the same, it really makes no difference.  If the 
> reason for multiple addresses per host (or interface) in IPv6 is 
> to support different scopes (or connectivity, or multihoming 
> arrangements), then it does make a difference, and will make a 
> difference for a significant number of hosts.  And _that_ 
> implies a new requirement.

We could debate 'new' forever, since as you noted earlier this
requirement existed before routers, but the point is that apps can't
ignore it any longer.

> Tony, there is a difference in perspective here.  I'm going to 
> try to identify and explain it, with the understanding that it 
> has little to do with any of the discussion above, which I think 
> is far more important.  From your point of view, as I understand 
> it, this feature has been in IPv6 for a long time, no one 
> questioned it, or the problem(s) it apparently solved, for 
> equally long, some implementations were designed to take 
> advantage of it, and now people are coming along and proposing 
> to remove it without a clearly-better solution to address those 
> solved problems.  

Yes. 

> From the viewpoint of many or most of the 
> applications-oriented folks on this list, and maybe some others, 
> the applications implications of the SL idea (and maybe the 
> "multiple addresses" idea more generally) are just now becoming 
> clear.  What is becoming clear with them is that the costs in 
> complexity, in data abstraction failures, and in damage to the 
> applications view of the hourglass, are very severe and, indeed 
> that, from the standpoint of how applications are constructed, 
> SL would never have worked..    From that perspective, when you 
> argue that applications are already doing bad things, the 
> applications folks respond by saying "but IPv6 should make it 
> better, or at least not make it worse".

It is inconsistent to claim that SL would never have worked while
admitting that there are implementations that take advantage of it. But
that aside, SL is not the issue, the issue is that apps have come to
believe that the topology is flat so they can pass around handles
constructed of topology specific information. The reality all along has
been that some addresses were not reachable outside an administrative
scope of relevance. Writing those cases off in a client/server world was
mostly possible, but in the peer-to-peer world of IPv6 that is no longer
possible. 

> 
> Those differences lead to discussions about religion and 
> ideology, which get us nowhere (although they generate a lot of 
> list traffic).  It is clear to me (from my particular narrow 
> perspective) that our getting to this point at this time 
> indicates a failure on the part of several generations of IESG 
> members (probably including me).  It also identifies a series of 
> issues in how we review things cross-area (or don't do that 
> successfully) and reinforces my perception that shifting the 
> responsibility for defining standards away from a 
> multiple-perspective IESG and onto WGs with much narrower 
> perspectives would be a really bad idea.

I agree, and even restricting the cross-area review to the IESG is a bad
idea because there aren't enough cycles in that small group. 

> 
> But, unfortunate though it may be, we have gotten here.  We 
> differentiate between Proposed and Draft standards precisely to 
> make it easier to take something out that doesn't work, or 
> --more to the point in this case-- doesn't appear to do the job 
> it was designed to do at a pain level no worse than what was 
> anticipated.  I don't think essentially procedural arguments 
> about how much proof is required to take something out get us 
> anywhere at this stage.  Instead, we should be concentrating on 
> the real character of the problem we are trying to solve and 
> ways in which it can be solved without doing violence to 
> whatever architectural principles we can agree upon.

I agree to a point. My button is pushed by those that claim a technology
'creates more problems than it solves', when they simultaneously admit
they don't have a clue what problems need solving. To that end I started
a draft on what problems need solving, so we can sort out the cases that
the current technology does solve, as well as begin to identify
alternatives. IF we get to a point were there are alternatives for all
the cases people care about, we should drop the unused technology. 

Tony

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Apr 2003 13:58:00 -0700

Tony Hain wrote:
> But that aside, SL is not the issue, the issue is that apps have come to

As there are many entities that provide firewalling functionality, it is 
unreasonable to assume that it would be possible for each of these to be 
the address authority for either end of a connection.  Thus, an 
application must deal with multiple administrative domains today.  In 
some circumstances, administrative firewalls exist specifically to block 
particular applications.  And... network error messages may or may not 
be appropriate to a given circumstance.  It all depends on your threat 
model.

Along these same lines, there is no reason to assume that the end host 
will be trusted by the firewall sufficiently such that a POLICY exchange 
would be allowed.  It is one thing to say, "Permission denied", and 
quite something else to say when one will deny permission.  SLs and IPv6 
provide neither advance nor regression in this regard.

I take exception to this:

> they don't have a clue what problems need solving. 

Most of us -- MOST OF US -- have a clue.  That you refuse to recognize 
it and respect those opinions is unfortunate.

> To that end I started

And many of us have been saying that we have something that works today, 
RIR policies not withstanding.  It's IPv4.

Eliot

---

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

> The only way you
> the issues. 

if the architecutral guidance were crisp it certainly wouldn't be asking the
DNS related WGs to discuss those issues.  DNS cannot solve this problem.

> handle, the other nodes would acquire appropriate local handles. 

this presupposes that the blob that is passed is precisely and reliably bound
to the specific host or process that the app wants to refer to, and also that
the lookup process that maps blobs to locators and/or identifiers is
sufficiently fast and robust.  often neither of these conditions holds.

> The problems arise from the
> treated equally by the network,

heaven forbid that apps would assume the same thing that the IP network
was designed to assume - that there is a uniform address space across the
entire network.  but you want to change this fundamental architectural design
point at layer 3 and then claim that the resulting problems are caused by
inappropriate assumptions at layer 7.  some would say this is layering
violation, but the sharing of identifiers between layer 7 and layer 3 is
another fundamental architectural design point.

> they don't have a clue what problems need solving.

I do have an idea about what problems need solving, but I don't claim to be
able to make a list that satisfies everyone at the drop of a hat. 

But it's not clear that SL was actually intended to solve any of these
problems.  Rather, it seems to me that somebody thought SL was a good idea,
and put it into the v6 architecture.  And then various people started saying
"hey, we can use SL for X", and nobody bothered to examine whether there were
conflicts between those various peoples' assumptions (whether specifically
about SL or not), or even whether SL was worth the cost, until recently.

The problem with trying to make a list of "SL-related problems" is that there
is also a set of problems that don't directly involve SL but also need to be
solved, and SL precludes solving those problems.

Keith

---

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

> It would make more sense for an application to make a call to an API that 
> says "I want to hand off identifying information about host X to host Y. 
> Please package me up information to sent to X so that it will be able to 
> understand what I mean." 

been there, tried to do that, in the context of PVM.  by far the easiest way
to accomplish this is to have a uniform address space at the network level.
any other approach is just too complex.

background: PVM was originally designed to as a uniform API for distributed
memory parallel machines, and later as a way to provide a distributed memory
programming environment across a network of computers (some of which were
potentially distributed memory hosts).  in order to allow applications to send
messages to other "processing elements" or hosts, PVM assigned a task id to
each "processing element" in its virtual machine, and the mapping between task
ids to tasks was uniform across the virtual machine.  this task id consisted
of a host id to which a host-specific offset was added.  we tried making the
mapping non-uniform because it would have relieved us of the need to keep a
mapping table consistent across all hosts in the machine (especially after we
allowed new hosts to be added to the machine), but the most robust, and in
general the most efficient, way to implement the host-id mapping function was
to use consistent numbering for host-ids across the entire machine...that, and
expecting apps to invoke a translation function every time they
passed a task id to another task was just too cumbersome.

uniform addressing models are very compelling, even when you don't have
complete interconnection.

> A mention of proper layering was made earlier in this discussion thread. 
> It's time we took a serious look at how to improve on the mechanisms used. 
> Solving this layering issue could benefit both IPv4 and IPv6 
> implementations. As noted, the problem is not new at all, though perhaps 
> now is the time to shed light on the matter.

proper layering is an art.  it involves understanding when to enforce layering
discipline, and when to escape it. 
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:01:05 -0700

> it and respect those opinions is unfortunate.

Where is the document that shows what requirements need to be solved? 

How would you correlate the stated need from the network manager for:
Stable addresses, both during ISP changes, and for intermittently
connected networks.

with:
Why is it that stable addresses are so necessary?  
Could it be because renumbering is painful?  
Could that be one source of our ills?

&

Fix the underlying problem.  Making renumbering easy.  
If we don't do that, IPv6 is no better than Ipv4.

???

While I agree that we need to get at the underlying problem, handwaving
that easy renumbering will solve it is not helpful. In many cases the
requirement for stable addresses is being handed to the enterprise
network manager by unreasonable Sr. VPs who want to lower their internal
development cost & don't care about anything more than getting their
product out the door. Claiming that easy renumbering will solve that
internal business issue is just an IETF fantasy.

Tony

---

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

Keith Moore wrote:
> if the architecutral guidance were crisp it certainly 
> wouldn't be asking the DNS related WGs to discuss those 
> issues.  DNS cannot solve this problem.

I agree all infrastructure & components that pass around topology
information need work, but DNS is one of those, so it is a good place to
start.

> > the blob passed were the same as what the app used to acquire the 
> > local handle, the other nodes would acquire appropriate 
> local handles.
> 
> this presupposes that the blob that is passed is precisely 
> and reliably bound to the specific host or process that the 
> app wants to refer to, and also that the lookup process that 
> maps blobs to locators and/or identifiers is sufficiently 
> fast and robust.  often neither of these conditions holds.

If the first one doesn't hold, the origin node can't use it so the whole
app is broken. Speed is an implementation issue, not a spec issue. In
any case, it is much faster to pass a blob that can be mapped into
useful topology information, than it is  to pass around useless topology
information.

> heaven forbid that apps would assume the same thing that the 
> IP network was designed to assume - that there is a uniform 
> address space across the entire network.  but you want to 
> change this fundamental architectural design point at layer 3 
> and then claim that the resulting problems are caused by 
> inappropriate assumptions at layer 7.  some would say this is 
> layering violation, but the sharing of identifiers between 
> layer 7 and layer 3 is another fundamental architectural design point.

I am not saying that. From day one, a host that had one interface where
the address prefix was not passed widely in the routing system, and
another where the prefix was passed globally would have exactly the same
issues you are complaining about. This says nothing about firewalling,
qos, ambiguous addresses, etc. This is simply about a host having
multiple addresses, where different points in the network have different
perceptions about the viability of those. The fact that over the years a
simplification was done through the assumption that there was only a
single view is a failure. 

> 
> > I agree to a point. My button is pushed by those that claim a 
> > technology 'creates more problems than it solves', when they 
> > simultaneously admit they don't have a clue what problems need 
> > solving.
> 
> I do have an idea about what problems need solving, but I 
> don't claim to be able to make a list that satisfies everyone 
> at the drop of a hat. 

I don't have a list either, but we need to collectively create that
list. 

> 
> But it's not clear that SL was actually intended to solve any 
> of these problems.  Rather, it seems to me that somebody 
> thought SL was a good idea, and put it into the v6 
> architecture.  And then various people started saying "hey, 
> we can use SL for X", and nobody bothered to examine whether 
> there were conflicts between those various peoples' 
> assumptions (whether specifically about SL or not), or even 
> whether SL was worth the cost, until recently.

Fine, we need to create the list, figure out alternatives and as you
said in SF, push SL into the corner cases, if we still need it. Getting
rid of SL first does not solve the problems. 

> The problem with trying to make a list of "SL-related 
> problems" is that there is also a set of problems that don't 
> directly involve SL but also need to be solved, and SL 
> precludes solving those problems.

I agree there are several problems to be solved, but don't agree that
the existence of SL precludes solving anything. If we try to claim that
we don't need to work on solving problem X because SL solves it, then I
would agree, but so far I haven't heard anyone claim that we shouldn't
work on solving the problems. The only thing I have heard is that we
have found no use for SL (despite the shipping code that uses it),
without the list of basic requirements to judge which problems it does
solve.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Apr 2003 15:26:24 -0700

> Where is the document that shows what requirements need to be solved? 

How about starting with the IPng archives?!  They're actually more 
persistant than, say, an internet draft, anyway.

> Stable addresses, both during ISP changes, and for intermittently

I wouldn't.  I would decompose the network manager's stated need for 
stable addresses.  That's what responsible people do when they see a 
customer requirement with a bad solution.  But see below...

> internal business issue is just an IETF fantasy.

This strikes me like the old adage, "You're safe if you buy IBM" (no 
offense to IBMers).  You were until you weren't because the processes 
you used were outmoded, only you didn't think about it.  Frankly, the 
fantasy here (and I love your charged use of words) is that IPv6 
provides any -- ANY -- added benefit to the customer base.(*)  That same 
Sr. VP ought to be asking why he is spending what will for the forseable 
future be a huge amount of money to cut over to IPv6 when IPv4 will suit 
the vast percentage of enterprises and users just as well as IPv6, given 
their intended use of SLs, as stated by some of those very same network 
managers.

Eliot

(*) Indeed I question whether even the mobility features will be 
properly taken advantage of, given the stated network manager need for 
stable addresses reconciled with their need for Internet connectivity 
(i.e., NAT).  What do you then use for your MN address?  If that mobile 
node wants to have a stable identifier, then it's using site-locals. 
Nonsense?  But if they don't use site-locals then they have all the same 
problems those network managers are complaining about, and you don't 
have a stable address for applications.

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Apr 2003 23:36:35 +0100

> persistant than, say, an internet draft, anyway.

No need to bother, just read any sample of 100 ipng emails in one day and
the same arguments come up again and again.  And again.

Is there a WG chair in the house?

Tim

---

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

> information need work, but DNS is one of those, so it is a good place to

disagree.  "starting" to work on this within DNS would be a distraction at
best.

> app is broken. 

false.  it happens all the time.   a function that converts a service name to
an address doesn't have to produce identical results each time to be useful. 
and yet, if two separate processes need to connect to the exact same process,
the service name alone may not be sufficient to allow them to do that. 

> Speed is an implementation issue, not a spec issue. 

false.  depending on how you architect a service there can be fundamental
and/or practical limits to speed. 

> In any case, it is much faster to pass a blob that can be mapped into

it's even faster if the network provides uniform addressing; then the
addresses are no longer useless.  why do you keep trying to force useless
addresses on us when we can have useful ones at less cost?

> issues you are complaining about. 

it's hardly relevant, since that's not the way things happened.

> This says nothing about firewalling,
> perceptions about the viability of those. 

yup.  and the realization that this is a lousy way to design a network

> The fact that over the years a

and in fact it's a very useful and compelling simplification.

> rid of SL first does not solve the problems. 

we've tried going on the assumption that SL will work, and we've not been able
to resolve the conflicts and problems that result from that assumption.  now
we need to try the assumption that we can do without SL, and see where that
leads.  perhaps we will find that we can do without SL, or perhaps we will
still need SL for a couple of corner cases.  we won't know for sure until we
try to work out the details, and we won't have completely decided for sure
until we actually approve a specification that incorporates those details. 
but that's the direction that the WG has decided to pursue, and I think it's
the right one.

Keith

---

From: Ronald van der Pol <[email-masked]>
Date: Fri, 25 Apr 2003 10:27:17 +0200

> the same arguments come up again and again.  And again.

True, and the problem is that we need to keep reading all those emails
because there might be a new argument in there some day.

> Is there a WG chair in the house?

I think they tried a couple of times. I remember "top 10 posters" lists
and requests to keep the number of replies down. What else can they do?
I think it is up to the frequent emailers now. Maybe they can all setup
web pages "what I think about X" and just point to them :-)

I am truly interested in their opinions, but I don't like wasting time
on reading the same things over and over.

	rvdp

---

From: Tim Chown <[email-masked]>
Date: Fri, 25 Apr 2003 09:36:27 +0100

> web pages "what I think about X" and just point to them :-)

Or write I-Ds.   Some people must have posted 100 I-D's worth of text, yet
there is no "Site locals Considered Harmful" I-D... is there?
 
Tim

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 22:19:14 -0400

Hi Tim,

[I dropped the IETF list, as I think you were talking about
the IPv6 list.]

>Is there a WG chair in the house?

Actually, on the 24th, there was no WG chair in the house.
Bob and I were both on vacations last week that overlapped
on Wednesday through Friday.

That aside, though, do you have suggestions for how we
should temper the discussion on the IPv6 list (which has
lately been lopping over onto the IETF list).

On occasion, we have written to frequent posters privately
and we have asked them to reduce their volume, change
their tone and/or stop repeating their arguments.  This
usually works for a while...

Can you think of anything else that we could that is
consistent with the IETF values of openness and fairness?

Thanks,
Margaret