Subject: Re: what the "scope" disagreement is about

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 22:58:12 -0400

> Given a list of addresses for a target, how would an application pick
> one that is assured to work at the receiver? Answer: it can't without
> knowing the topology. The only way to keep the app from knowing
> topology, and make the app work in the presence of a list is to pass the
> label that was used to get the initial list, so the receiver can get its
> own that is topologically appropriate. 

Tony, 

What you are essentially claiming is that an application that doesn't know
about network topology should defer choices that must be based on topology to
some other application.  Of course, it's not any easier for that other 
application to know about topology, and it's also less reliable and less
efficient.  It might seem reasonable to isolate the topology-selection stuff
into a single application, but it's not - different applications have 
different needs in this regard.  Again this is from experience with an app
that needed to choose the closest of several alternate URLs for a resource -
doing all of the DNS lookups on all of the URLs and then trying to find the
closest one of those was just too slow.  Finally, if you want any app -
even this "special" app, to be aware of topology, then the first thing you
need is globally scoped labels for points in the topology - which is exactly
what exposing site locals to applications denies you.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 1 May 2003 10:48:07 -0700

Keith Moore wrote:
> ... Finally, if you want 
> any app - even this "special" app, to be aware of topology, 
> then the first thing you need is globally scoped labels for 
> points in the topology - which is exactly what exposing site 
> locals to applications denies you.

What ???  Yes we need a way to differentiate them, but eliminating the
local one doesn't accomplish that. The labels FEC0::/10 vs. 2::/3
provide exactly the scoping differentiator this statement claims to
need. Your comment appears to be so focused on the 'local' aspect of one
of the labels, that it missed the point that the other label is global. 

Making all labels global only works if the routing is in fact globally
flat. We know it isn't, so we should provide a simple way to figure it
out for processes that care. We should not be eliminating the only means
we have to figure it out. Yes, we need to complete the work on making
the 38 bits globally unique, but that can't happen if we start by
eliminating the first 10.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 1 May 2003 10:48:03 -0700

Theodore Ts'o wrote:
>> The real network is not a single flat routing space.
> 
> And this is where we disagree.  For better or for worse, the 
> market is demanding that IP addresses that can be treated as 
> belong to a single flat routing space.  

The market demand is for stable addresses that can be routed globally.
That does not mean that the network manager wants to globally route
every prefix.

> How else do you 
> explain the demand for provider independent addresses, and 
> people punching holes in CIDR blocks so they can have have 
> multihoming support for reliable network service?

The market demand is for address space that is STABLE. This stability
must isolate the network manager from the whims of any ISP, as well as
prevent the network manager from being locked into a provider to avoid
the cost of renumbering. That does not equate to a demand that every
prefix be globally routed, or that every node be globally accessible.
The network manager demands the control to decide that. 

The IETF app community is demanding that to keep their view of the world
pristine and simple, they get to define the world as a flat routing
space, and claim they are passing around opaque data structures, at the
same time they fully intend for the receiver to use the opaque object as
a topology locator. 

> 
> One solution for that would be to not do multihoming, and 
> simply have servers live on multiple IP addresses belonging 
> to multiple ISP's, and use multiple DNS 'A' records in order 
> to provide reachability.  I suspect that would be Tony's 
> solution about what we should be doing today. 

That scenario is inconsistent. You start with 'not do multihoming', but
then describe multihomed servers. 

> This is 
> perhaps workable for short-term http connections, but it's 
> absolutely no good for long-term TCP connections, which won't 
> survive a service outage since TCP commits the "sin" of using 
> IP addresses to identify its endpoints, instead of using DNS 
> addresses....  

I did not say that using an IP address was a sin, just that doing so
without understanding the topology that you are describing is a broken
model.

> But whether this is the reason, or the whether 
> there are other reasons why the "solution" of killing off 
> provider independent addresses and letting the DNS sort it 
> out has been perceived as unacceptable, it's pretty clear 
> that the market is spoken.  Even as people have been wagging 
> their fingers and saying "horrible, horrible", customers are 
> demanding it, and ISP's are providing it.  This is the 
> situation in IPv4, and I very much doubt the situation is 
> going to change much in IPv6.

I agree that PI is in market demand, and have a couple of personal
drafts on the topic. I saw this as a failing in the current PA or
Private, allocation model and figured we needed to get it dealt with.

> 
> It's certainly true that having a reliable end-point 
> identifier is critical.  But I don't think the DNS is it. 

One of my points awhile back was that the current DNS is not up to the
task, and neither are the other name resolution services. Those need to
be addressed at the same time as the applications that insist in doing
the work for themselves.
 
> The DNS has been abused in many different ways, and very 
> often, thanks to split DNS games, and CNAMES, and all the 
> rest, the name which the user supplies to the application is 
> also not guaranteed to be a name which can be utilizable by C 
> when B wants to tell C to connect to A:
> 
> >      ---- A ----
> >        |      I
> >        |      n
> >        |      t
> >        I      e ---- C
> >        2      r
> >        |      n
> >        |      e
> >        |      t
> >      ---- B ----
> 
> Tony is basically saying, "IP addresses don't work for this, 
> so let's bash application writers by saying they are broken, 
> and tell them to use DNS addresses instead".  

I am saying that the app either needs to learn the topology, or pass the
task off to a service that has the means to learn it. Passing around
addresses that are useless is not an approach to solving the problem.

> Well, I'm here 
> to point out that DNS addresses don't work either.  
> Applications get names such as "eddie.eecs", and even when 
> they get a fully qualified domain name, thanks to a very 
> large amount of variability in how system administrators have 
> set up split-DNS, there is no gauarantee that a particular 
> DNS name is globally available, or even globally points at 
> the same end point.  So if IP addresses are not a flat 
> routing space, DNS names are not a flat naming space, either.  

Which simply points out we have work to do, that won't get done by
avoiding the issue.

> 
> I struggled for a while to come up with ways of coming up 
> with a "canonical DNS name" which could be passed around to 
> multiple hosts many years ago when I was trying to come up 
> with a convenient way to construct canonicalized, globally 
> usable Kerberos principal names from host specifiers that 
> were supplied by the user on the command line. We ran up 
> against the same problem.  Fundamentally, the DNS wasn't and 
> isn't designed to do this.

So the IESG needs to task the DNS community with fixing it. The reality
of the deployed network is that the topology is inconsistent from
different perspectives. If all the 'identifier to topology' resolving
processes expect the world to be flat, they are simply broken.

> 
> Now, I suppose you could say that the people who "broke" DNS 
> are fault, but there are also people who would say that the 
> people who broken the flat routing space assumption (which 
> while not universally true was true enough for engineering 
> purposes) are a fault instead. Perhaps a more constructive 
> thing to say is that the original Internet architecture --- 
> and here I mean everything in the entire protocol stack, from 
> link layer protocols to application level protocols --- were 
> not well engineered to meet the requirements that we see 
> being demanded of us today.

Or even 20 years ago. The issue was ignored in the past because the
demand was low enough to allow that. 

> 
> This is why I believe that ultimately 8+8 is the most 
> interesting approach.  As the old saw goes, "there is no 
> problem in computer science that cannot be solved by adding 
> an additional level of indirection".  

8+8 and similar schemes suffer one of the same problems you are
complaining about. To make them work, the network needs a very fast
converging, global, identifier to locator mapping service. Mangling the
address field in the packet only allows the app to use part of the
address for the identifier. There is no reason that the identifier has
to be part of the address.

> 
> What we need is something that sits between DNS names and 
> provider-specific IP addresses.  That is a hole in the 
> architecture which today is being fixed by using 
> provider-independent addresses, much to the discomfort of 
> router engineers.  Another solution, which has been 
> articulated by Tony, is that we should sweep all of this dirt 
> under the DNS carpet instead, and force the application 
> writers to retool all their implementations and protocols to 
> pass DNS names around instead.  But the DNS really isn't 
> suited to handle this.  What we need is something in-between.

The problem will not be solved by PI addressing. I don't care if apps
pass around addresses, as long as they are doing the work to make sure
the address is consistent with the topology the app is intentionally
describing. If the app is not going to learn about topology (and I agree
the app shouldn't) it needs to rely on a service that has the means to
do the job. We agree, the current DNS is not up to the task. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 May 2003 14:36:43 -0400

> need. 

being able to distinguish an ambiguous address from a global address
doesn't solve the problem of requiring hosts or apps to be aware of
topology in order to make address selection.  the problem here is that
an SL address is ambiguous in almost any context outside of an RA or IP
header; so there's simply no way to be confident that a particular SL
belongs to a particular section of the network. 

ambiguous addresses are both the factor that would force hosts and apps
to be more aware of topology AND the factor that make it intractable for
hosts and apps to be aware of topology.  Not only do they cause this
problem, they preclude any solution to the problem.

> flat. 

It's worked in IPv4 for 20+ years.  What has been repeatedly shown to
not work well is to try to route on non-global labels.  (anyone remember
uucp mail or easynet?)

> Yes, we need to complete the work on
> making the 38 bits globally unique, but that can't happen if we start
> by eliminating the first 10.

If we can agree on how to make the first 48 bits globally unique, does
it really matter what values are assigned to the first 10 bits? That
choice could be made strictly on the basis of compatibility issues with
existing hosts, apps, and routers, once the other technical aspects of
GUPIs had been worked out.

(yes, GUPIs, NOT SLs.  they WILL be routed between sites, for good
reasons, and we shouldn't try to stop this)

Keith

---

From: [email-masked]
Date: Thu, 01 May 2003 12:16:51 -0400

On Wed, 30 Apr 2003 15:09:22 EDT, Ofer Inbar said:

> From what I have seen, those who think "local scope" is harmful, are
> concerned about the ambuity of addresses, as Keith says here again.

Exactly.

> They are NOT concerned about the fact that a given address may not be
> reachable from some places, or may be reachable via different routes
> from different places.  Or, rather, whether they're concerned about
> that or not, it has nothing to do with their objections to locally
> scoped addresses.

Yes, I'm concerned about reachability, and it *does* have something to
do with locally scoped addresses, but in an inverse fashion..

>                    All of their objections to locally scoped addresses
> seem to be about the fact that the addresses are ambiguous, not unique.
> They have no objections to globally unique addresses that remain
> "local" as far as routing and reachability.

The "inverse fashion" mentioned above - it's a LOT harder to diagnose a
problem when the remote end is handing you bogon debugging information.
Anybody else ever had to deal with the case where a 'traceroute' to a
dead host shows one path, but sending a TCP SYN packet gets back an
ICMP Host Unreachable from one RFC1918 space address complaining about
another 1918-space address, neither of which are in the traceroute? ;)

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 1 May 2003 08:05:16 -0400

On Wed, Apr 30, 2003 at 01:31:50PM -0700, Tony Hain wrote:
> The reason I say this is about reachability is that even with unique
> addresses, applications will fail when they choose to pass 'an opaque
> identifier' around, while they simultaneously assume that the content is
> a valid topology locator at the receiver. The arguments claim the need
> for opaqueness as an application simplifier on one hand, at the same
> they insist that the topology match their perspective of a flat routing
> space. The real network is not a single flat routing space.

And this is where we disagree.  For better or for worse, the market is
demanding that IP addresses that can be treated as belong to a single
flat routing space.  How else do you explain the demand for provider
independent addresses, and people punching holes in CIDR blocks so
they can have have multihoming support for reliable network service?

One solution for that would be to not do multihoming, and simply have
servers live on multiple IP addresses belonging to multiple ISP's, and
use multiple DNS 'A' records in order to provide reachability.  I
suspect that would be Tony's solution about what we should be doing
today.  This is perhaps workable for short-term http connections, but
it's absolutely no good for long-term TCP connections, which won't
survive a service outage since TCP commits the "sin" of using IP
addresses to identify its endpoints, instead of using DNS
addresses....  But whether this is the reason, or the whether there
are other reasons why the "solution" of killing off provider
independent addresses and letting the DNS sort it out has been
perceived as unacceptable, it's pretty clear that the market is
spoken.  Even as people have been wagging their fingers and saying
"horrible, horrible", customers are demanding it, and ISP's are
providing it.  This is the situation in IPv4, and I very much doubt
the situation is going to change much in IPv6.

It's certainly true that having a reliable end-point identifier is
critical.  But I don't think the DNS is it.  The DNS has been abused
in many different ways, and very often, thanks to split DNS games, and
CNAMES, and all the rest, the name which the user supplies to the
application is also not guaranteed to be a name which can be

>      ---- B ----

Tony is basically saying, "IP addresses don't work for this, so let's
bash application writers by saying they are broken, and tell them to
use DNS addresses instead".  Well, I'm here to point out that DNS
addresses don't work either.  Applications get names such as
"eddie.eecs", and even when they get a fully qualified domain name,
thanks to a very large amount of variability in how system
administrators have set up split-DNS, there is no gauarantee that a
particular DNS name is globally available, or even globally points at
the same end point.  So if IP addresses are not a flat routing space,
DNS names are not a flat naming space, either.  

I struggled for a while to come up with ways of coming up with a
"canonical DNS name" which could be passed around to multiple hosts
many years ago when I was trying to come up with a convenient way to
construct canonicalized, globally usable Kerberos principal names from
host specifiers that were supplied by the user on the command line.
We ran up against the same problem.  Fundamentally, the DNS wasn't and
isn't designed to do this.

Now, I suppose you could say that the people who "broke" DNS are
fault, but there are also people who would say that the people who
broken the flat routing space assumption (which while not universally
true was true enough for engineering purposes) are a fault instead.
Perhaps a more constructive thing to say is that the original Internet
architecture --- and here I mean everything in the entire protocol
stack, from link layer protocols to application level protocols ---
were not well engineered to meet the requirements that we see being
demanded of us today.

This is why I believe that ultimately 8+8 is the most interesting
approach.  As the old saw goes, "there is no problem in computer
science that cannot be solved by adding an additional level of
indirection".  

What we need is something that sits between DNS names and
provider-specific IP addresses.  That is a hole in the architecture
which today is being fixed by using provider-independent addresses,
much to the discomfort of router engineers.  Another solution, which
has been articulated by Tony, is that we should sweep all of this dirt
under the DNS carpet instead, and force the application writers to
retool all their implementations and protocols to pass DNS names
around instead.  But the DNS really isn't suited to handle this.  What
we need is something in-between.

						- Ted

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 May 2003 16:22:40 -0400

> > being able to distinguish an ambiguous address from a global 
> > address doesn't solve the problem of requiring hosts or apps 
> > to be aware of topology in order to make address selection.  
> 
> Ambiguity has nothing to do with the address selection problem here.

False.  It makes the address selection problem intractable.

> > > Making all labels global only works if the routing is in 
> > > fact globally flat.
> > 
> > It's worked in IPv4 for 20+ years.  What has been repeatedly 
> > shown to not work well is to try to route on non-global 
> > labels.  (anyone remember uucp mail or easynet?)
> 
> It has never worked for multi-homed systems when some of the
> participants in an app have a different view of the topology.

False, or at least an exaggeration.  Basically multi interface hosts
have worked just fine as long as the host had a distinguished address
which was reachable from each of its interfaces (whether via ARP or
routing or whatever), and that it consistently used as a source address
-- or more generally, as long as all of the addresses it used as
source addresses were routable from any of the nets to which it
connected (modulo access control), regardless of whether different
routing paths were available to different hosts.

What hasn't ever worked is requiring apps to know about routing
topology in order to successfully route packets to the destination,
where "successfully" might mean a variety of things ranging from "being
able to get the packets there at all" to "having those packets utilize
the high speed (and/or secure) link".

Note again that ambiguous addresses make this problem even harder to
solve, by changing the problem from "need more information to know
how to get there" to "can't even tell where 'there' is".

> > If we can agree on how to make the first 48 bits globally 
> > unique, does it really matter what values are assigned to the 
> > first 10 bits? That choice could be made strictly on the 
> > basis of compatibility issues with existing hosts, apps, and 
> > routers, once the other technical aspects of GUPIs had been 
> > worked out.
> 
> Which is one of my points. There have been several proposals offered
> to create probabilistically unique 38 bit values,

probabilistically unique doesn't cut it, because it's making
unreasonable assumptions about the size of the collision domain. 
remember, hosts don't have to communicate directly in order to cause a
collision between their identifiers within an application.

> that are compatible
> with shipping code that use that specific /10. In other words we have
> the technical means to take the ambiguity issue off the table. Getting
> rid of the shipping /10 doesn't accomplish the goal of removing
> ambiguity, it only delays getting there. 

the thing we should be doing is figuring out how to provide GUPIs,
not figuring out an excuse to keep using the SL prefix. 

> Your other issue about address selection doesn't go away. IPv6 nodes
> will have multiple addresses, therefore a list to select from.  

agreed, but we can minimize the degree to which the selection is
critical.

> With a distinguishing flag (upper 10 bits), it becomes possible for
> the processes that resolve names to topology locators in order to sort
> it out. 

wrong, because processes that resolve names have no idea about whether
such locators are valid in the scopes in which they will be used, much
less whether they are suitable for use by the applications.

> Without that flag there is no consistent way for that process
> to know. 

wrong.  the mere existence of this "flag" is what makes it impossible
for the app to know whether the address is valid.

> If that process is the end app (because it doesn't trust any
> other process to be fast or reliable enough), then the app needs to
> know the topology it explicitly intends to describe.

Now you're essentially arguing (without any supporting evidence) that
the network shouldn't have to know how to route packets beyond the local
link.

Keith

---

From: [email-masked]
Date: Thu, 01 May 2003 15:24:25 -0400

> not work well is to try to route on non-global labels.  (anyone remember

Compare-and-contrast "pathalias" and BGP's AS-path.  Include discussion
of out-of-band information needed in both cases. ;)

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 1 May 2003 15:58:25 -0500

Thus spake "Keith Moore" <[email-masked]>
> topology in order to make address selection.

A host/app needs to be similarly aware of topology (and security policy) to
make any reasonable selection between multiple global addresses.  Adding
non-globals to the mix doesn't make things significantly worse.

> > Yes, we need to complete the work on making the 38 bits globally
> > unique, but that can't happen if we start by eliminating the first 10.
>
> it really matter what values are assigned to the first 10 bits?

Yes, it does.  Having a common prefix for non-global addresses makes the job
of network managers much simpler, and thus reduces the likelihood of leaks.
Does it need to be a 10-bit prefix?  Not really, but FEC0::/10 is already
there.

> reasons, and we shouldn't try to stop this)

Since this is the first time I've seen "GUPI" used, should I assume that
means a globally unique provider-independent prefix which isn't globally
routed?  If so, I think you're using that term in the same sense Tony uses
SL.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 1 May 2003 14:09:53 -0700

Keith Moore wrote:
> ...
> remember, hosts don't have to communicate directly in order 
> to cause a collision between their identifiers within an application.

In other words, I was incomplete earlier. We are required to have a
single flat global routing domain, with the additional policy constraint
that only a single organization is allowed to inject a given value.
Otherwise every address is probabilistically unique. How do you know
that someone is not injecting 8/8 into routing today, and confusing some
poor soul (or just hijacking the space) in a remote corner of the net?
Given the current technology, we probably need the additional policy
constraint that any given value is only allowed to appear at a single
location, else we can't be sure it is really the authorized originator.

> the thing we should be doing is figuring out how to provide 
> GUPIs, not figuring out an excuse to keep using the SL prefix. 

No excuses, the existence and use in shipping code of a particular /10
is not preventing progress on uniqueness. 

> agreed, but we can minimize the degree to which the selection 
> is critical.
> 
> wrong, because processes that resolve names have no idea 
> about whether such locators are valid in the scopes in which 
> they will be used, much less whether they are suitable for 
> use by the applications.
> 
> > Without that flag there is no consistent way for that 
> process to know.
> 
> wrong.  the mere existence of this "flag" is what makes it 
> impossible for the app to know whether the address is valid.
> 
> > If that process is the end app (because it doesn't trust any other 
> > process to be fast or reliable enough), then the app needs 
> to know the 
> > topology it explicitly intends to describe.
> 
> Now you're essentially arguing (without any supporting 
> evidence) that the network shouldn't have to know how to 
> route packets beyond the local link.

You have argued yourself in a full circle. You agree that the address
selection issues don't go away, then turn around and say that the
existence of a tool for distinguishing which on the list are least
likely to work for global purposes makes it impossible for apps to
choose, and end up back at the point of an app can't pass around data
that it intends for the receiver to use as topology data unless it
understands the topology. In fact the local router may not know how to
get some packets off the local link if a network manager has limited the
routing information available to that router. This is not broken, it is
the reality that global routing is not a single flat space. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 May 2003 17:33:15 -0400

On Thu, 1 May 2003 15:58:25 -0500
"Stephen Sprunk" <[email-masked]> wrote:

> A host/app needs to be similarly aware of topology (and security
> policy) to make any reasonable selection between multiple global
> addresses. 

agree.

> Adding non-globals to the mix doesn't make things significantly worse.

Disagree.  First, it immediately reduces the available choices, and
thus, the potential for poor choices (since SLs are more often poor
choices than not). Second, it pushes the burden of routing back into the
network where it belongs.  Third, while it's possible (though
unattractive) for the network to supply some topology information
to hosts in a world where identifiers for points in the topology are all
are taken from the same name space, having ambiguous addresses makes
this completely infeasible.

> > If we can agree on how to make the first 48 bits globally unique,
> > does it really matter what values are assigned to the first 10 bits?
> 
> Yes, it does.  Having a common prefix for non-global addresses makes
> the job of network managers much simpler

Not clear; since it doesn't necessarily give them the flexibility they
need.  The idea that a network has only one boundary of interest is
of fairly limited applicability; it's certainly not something that is
general enough to be wired into the addressing architecture.

however, I was referring specifically to the prefix FEC0://10.  Yes,
it's already allocated, but it's also defined in such a way as to be
dysfunctional, and too many broken assumptions are wired into existing
code.  So for the sake of compatibility it seems better to allocate
another prefix for GUPIs.

> Since this is the first time I've seen "GUPI" used, should I assume
> that means a globally unique provider-independent prefix which isn't
> globally routed? 

yes.

> If so, I think you're using that term in the same sense Tony uses SL.

IMHO, they shouldn't have any "site" or filtering assumptions wired into
them, they're just a set of prefixes that are not dependent on a
provider and can't be assumed to be globally routable.  But to make
them work we'll need a way to transparently map/forward them to routable
prefixes.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 1 May 2003 12:52:33 -0700

More below.

> the problem here is that an SL address is ambiguous in almost 
> any context outside of an RA or IP header; so there's simply 
> no way to be confident that a particular SL belongs to a 
> particular section of the network. 
> 
> ambiguous addresses are both the factor that would force 
> hosts and apps to be more aware of topology AND the factor 
> that make it intractable for hosts and apps to be aware of 
> topology.  Not only do they cause this problem, they preclude 
> any solution to the problem.
> 
> fact globally 

> routers, once the other technical aspects of GUPIs had been 

Which is one of my points. There have been several proposals offered to
create probabilistically unique 38 bit values, that are compatible with
shipping code that use that specific /10. In other words we have the
technical means to take the ambiguity issue off the table. Getting rid
of the shipping /10 doesn't accomplish the goal of removing ambiguity,
it only delays getting there. 

Your other issue about address selection doesn't go away. IPv6 nodes
will have multiple addresses, therefore a list to select from. With a
distinguishing flag (upper 10 bits), it becomes possible for the
processes that resolve names to topology locators in order to sort it
out. Without that flag there is no consistent way for that process to
know. If that process is the end app (because it doesn't trust any other
process to be fast or reliable enough), then the app needs to know the
topology it explicitly intends to describe. If the app doesn't want to
learn topology, it must choose to hand the task off to a process with
the means to figure it out. The current DNS is not up to the task, so it
either needs to be fixed, or a replacement defined that actually
addresses the issue here.

Tony

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 1 May 2003 22:45:07 -0400

> That does not mean that the network manager wants to globally route

No, but stable address that can be routed globally satifies the goal
having an address which can be passed from B to C and still be used to
reach A.   That was my point.

> then describe multihomed servers. 

I'm saying that's what people want in the real world.   

It seems to me that you have this alternate solution which requires
using the DNS instead.  But given the choice between forcing
applications to be rewritten, or leaning on the ISP's to provide
globally routable, provider-independent addresses that *can* be passed
from B to C and used to reach A, we know what network managers have
done, successfully --- they lean on their ISP's.

> be addressed at the same time as the applications that insist in doing

... and your solution is that IPv6 shouldn't do any of this work?
Make the the application writers modify all of their protocols and
implementations, as well as forcing the DNS to retool?  No wonder your
proposed solution is so popular.  :-)

> converging, global, identifier to locator mapping service. 

Yes, but at the same time it is no *more* work than that which is
required by your scheme.  Regardless of whether we put this work all
on the shoulders of the DNS and application folks, we still need to
have to provide the same solution.  So your scheme of forcing the DNS
to do all of this work isn't any easier.

> Mangling the address field in the packet only allows the app to use
> part of the address for the identifier. There is no reason that the
> identifier has to be part of the address.

Yes, applications would have to be changed to recognize that only part
of the "IPv6 address" is useful as the identifier.  But I suspect when
you compare the utility of a fixed-length identifier which is
guaranteed to be unique, as opposed to a variable-length,
often-inconsistent user-provided string,the fixed-length identifier
will be considered much superior.

The bottom line is that in order to solve the problem right, I think
everyone will have to make some changes.  Perhaps part of the problem
here is that **everyone** has been saying, "my part of the stack is
perfect --- everything else in the stack needs to change in order to
accomodate *me*".  For example, saying that nothing needs to change in
IPv6, but rather the IESG must force the DNS direct to do all sorts of
things, and that application writers must be forced to make all sorts
of changes to conform to a particular architecture, might not
necessarily been the course of success.  In fact, it probably would
just cause a general consensus to deprecate site-local addresses.  :-)

> do the job. We agree, the current DNS is not up to the task. 

What if applications pass around a fixed-length identifier which they
consider to be a globally unique "address", and the IP layer contacted
some locator server (to be defined) a routable entity which it
considers an "address"?  It's the same pieces which you outlined; it's
just simply a matter of factoring the pieces slightly different, and
recognizing that there is only one IP layer, and many applications.
So modifying the IP layer to make use of the locator service is much
less work than forcing all of the applications to be changed to
contact this posited locator service.  

						- Ted

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 10:25:33 -0700

Theodore Ts'o wrote:
> No, but stable address that can be routed globally satifies 
> the goal having an address which can be passed from B to C 
> and still be used to

Only if there is a route from C to A for the address that was passed. If
there is a list that B can reach A by, it needs a way to tell C to get
its own list, or a way to sort out which will actually be useful to C. 

> 
> It seems to me that you have this alternate solution which 
> requires using the DNS instead.  But given the choice between 
> forcing applications to be rewritten, or leaning on the ISP's 
> to provide globally routable, provider-independent addresses 
> that *can* be passed from B to C and used to reach A, we know 
> what network managers have done, successfully --- they lean 
> on their ISP's.

I agree, but just because an address is unique does not mean it is
globally routable. If B passes an address for A that it can reach, but C
has no route to, this is not accomplishing the network manager's goal.
For some reason the network manager doesn't want C to contact A by a
particular address, so B shouldn't be passing it. 

> ... and your solution is that IPv6 shouldn't do any of this 
> work? Make the the application writers modify all of their 
> protocols and implementations, as well as forcing the DNS to 
> retool?  No wonder your proposed solution is so popular.  :-)

IPv6 didn't cause this problem, it only makes it harder to ignore. 

> 
> Yes, but at the same time it is no *more* work than that 
> which is required by your scheme.  Regardless of whether we 
> put this work all on the shoulders of the DNS and application 
> folks, we still need to have to provide the same solution.  
> So your scheme of forcing the DNS to do all of this work 
> isn't any easier.

I didn't say DNS has to do all of the work. All name resolutions
services need to as well as any other process that passes around
addresses that it intends the receiver to use as a topology locator.
This is a simple engineering function of making the data useful in the
context it is intended to be used. 

> Yes, applications would have to be changed to recognize that 
> only part of the "IPv6 address" is useful as the identifier.  
> But I suspect when you compare the utility of a fixed-length 
> identifier which is guaranteed to be unique, as opposed to a 
> variable-length, often-inconsistent user-provided string,the 
> fixed-length identifier will be considered much superior.

Uniqueness does not guarantee utility, and having something that can
consistently be turned into a useful value is always superior to quickly
getting the wrong answer. 

> 
> The bottom line is that in order to solve the problem right, 
> I think everyone will have to make some changes.  Perhaps 
> part of the problem here is that **everyone** has been 
> saying, "my part of the stack is perfect --- everything else 
> in the stack needs to change in order to accomodate *me*".  
> For example, saying that nothing needs to change in IPv6, but 
> rather the IESG must force the DNS direct to do all sorts of 
> things, and that application writers must be forced to make 
> all sorts of changes to conform to a particular architecture, 
> might not necessarily been the course of success.  In fact, 
> it probably would just cause a general consensus to deprecate 
> site-local addresses.  :-)

IE: Shoot the messenger rather than deal with the issues that have been
ignored for 15+ years ... :(

> > describing. If the app is not going to learn about topology (and I 
> > agree the app shouldn't) it needs to rely on a service that has the 
> > means to do the job. We agree, the current DNS is not up to 
> the task.
> 
> What if applications pass around a fixed-length identifier 
> which they consider to be a globally unique "address", and 
> the IP layer contacted some locator server (to be defined) a 
> routable entity which it considers an "address"?  It's the 
> same pieces which you outlined; it's just simply a matter of 
> factoring the pieces slightly different, and recognizing that 
> there is only one IP layer, and many applications. So 
> modifying the IP layer to make use of the locator service is 
> much less work than forcing all of the applications to be 
> changed to contact this posited locator service.  

I don't have a conceptual problem with the approach, but such a service
would have many of the same issues that DNS should be dealing with
anyway. In particular it would need to converge quickly on a global
basis, at the same time the resolution function is widely distributed to
scale appropriately. Someone would have to show me how the
fixed/variable length issue makes any difference to the hard part of
this problem.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 May 2003 13:17:46 -0400

This discussion is looping, and Tony seems to be the only person who is
hung up about this, so I'm going to reply to this message in private
rather than on the list.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 May 2003 14:38:35 -0400

> Only if there is a route from C to A for the address that was passed.
> If there is a list that B can reach A by, it needs a way to tell C to
> get its own list, or a way to sort out which will actually be useful
> to C. 

NO, Tony.  We need for the network to do routing, not the hosts.

Why is this so hard for you to understand?

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 12:44:11 -0700

> Why is this so hard for you to understand?

It is not hard to understand, because I agree there is no need for the
host or app to do routing. At the same time, the host or app doesn't
need to be passing around topology information. If any process chooses
to pass around values that are explicitly expected to be directly used
as topology locators, that process needs to understand the topology it
is describing. This isn't rocket science ...

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 May 2003 15:56:06 -0400

> need to be passing around topology information.

you're simply wrong about that, at least in the current architecture.

> If any process chooses

that "process" is called IP routing, and expecting routers to understand
IP addresses and their relationship to topology is not a new idea.

Keith

---

From: [email-masked]
Date: Fri, 02 May 2003 16:00:51 -0400

> Why is this so hard for you to understand?

Or as the spoofed ad from a number of years ago said:

"The network is the network.  The computer is the computer.  We
apologize for any confusion." -- Sun Microsystems

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 02 May 2003 14:08:17 -0500

Tony simply has the most patience.  Others of us unsubscribed.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 13:32:35 -0700

> Tony simply has the most patience.  Others of us unsubscribed.

To be honest, my patience ran out long ago. This is such an important
architectural and operational point that it requires attention even when
I would much rather be doing other things.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 14:40:50 -0700

Keith Moore wrote:
> > ... the host or app doesn't need to be 
> > passing around topology information.
> 
> > If any process chooses to pass around values 
> > that are explicitly expected to be directly used
> > as topology locators, that process needs to 
> > understand the topology it is describing. 
> 
> that "process" is called IP routing, and expecting routers to 
> understand IP addresses and their relationship to topology is 
> not a new idea.

There is nothing more to say ... 

Tony

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 May 2003 18:14:31 -0400

Tony,

Having picked on Keith in public a few days ago, it is your 
turn, and I'll make the same apology in advance.  Even on the 
parts of this with which I agree, the content and style of the 
discussion is no longer helpful. So, with the understanding that 
I'm just a random member of the community who has no authority 
to tell anyone to do, or not do, anything, I want to make two 
observations and a few suggestions to you and everyone else who 
is posting to this list.  Fwiw, if I hadn't had enough 
experience working with both you and Keith to value the 
experience and perspective of both of you when you are calm and 
thinking and explaining yourselves clearly, I wouldn't bother.

First of all, you have managed to convince me and, I think most 
others who have been listening, that "get rid of SL" is an 
answer to the wrong question.  Whether it is the right answer or 
the wrong one is less important than identifying the right 
question and then sorting things out in that context.  I think 
you have been trying to identify the right question, but your 
doing so has gotten repeatedly lost in the noise.

Second, it is clear to me that you and Keith have a profound 
disagreement about the character, state, and evolution of the IP 
architecture. The precise nature of that disagreement has been 
sufficiently obscured by differences in vocabulary and arguments 
about side-issues that I imagine that most readers of the list 
can't crisply identify the disagreement.  I'm not even sure you 
and Keith can do that at this stage; I suspect, from the level 
of mis- and non-communication, that you cannot.  I can try to 
explain it, but not this week (see below).

For whatever it is worth, I'd like to encourage everyone to take 
about a week off from this.  The arguments that are being made 
today don't differ very much from those that were being made in 
late March.  Anyone who hasn't been convinced yet --one way or 
the other-- is, IMO, much more likely to be convinced by quietly 
thinking about the arguments and statements, and generally 
letting things sink in, for a week or two than by more traffic 
that repeats the arguments yet another time.

And, for several other participants... There really are some 
subtle and very important architectural issues here (a subject 
on which I think Tony and Keith agree).  _Please_ invest the 
time to try to read and understand the postings and the issues 
they are trying to address. They are not simple, or at least the 
right solutions aren't: if they were, I really hope we wouldn't 
be having discussions this lengthy or heated.   When you read a 
few sentences of a posting and then fire off a response based on 
what you think that poster, or previous ones, are suggesting -- 
and more than a few postings have clearly resulted from that 
behavior-- you mostly just add to the noise.  And the noise is 
getting seriously in the way of looking carefully at those real 
problems.

        thanks,
           john

--On Friday, 02 May, 2003 12:44 -0700 Tony Hain 
<[email-masked]> wrote:

> It is not hard to understand, because I agree there is no need
> for the host or app to do routing. At the same time, the host
> or app doesn't need to be passing around topology information.
> If any process chooses to pass around values that are
> explicitly expected to be directly used as topology locators,
> that process needs to understand the topology it is
> describing. This isn't rocket science ...
>
> Tony