Subject: site locals are bankrupt

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 23:56:55 -0500

Tony,

You are wasting our time.  There is clear consensus to deprecate SLs.  They
were a bad idea, and people realize that now.  Your attempt to justify the
burdens they place on the network, on apps (including DNS), on routing hasn't
made them look any more attractive.  The best justification you've been able
to produce for keeping them is that they're supposedly already deployed.  Of
course that deployment is insignificant compared to the future use of IPv6. 
At any rate, nothing is likely to stop legacy products from using SLs if they
want to -- the point is to make certain that future products (especially apps)
don't have to deal with them. 

What you have totally failed to do is explain why site locals and the burdens
and complexity and unreliability that come with it are in the best interests
of the Internet as a whole, as opposed to the interests of some company that
wants to sell crippled products to its customers.

Site locals had their chance, and failed to justify themselves.  Taking them
away results in a vast improvement to IPv6.  It's time to move forward.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Apr 2003 01:12:34 -0500

--On Monday, 31 March, 2003 16:44 -0800 Dave Crocker 
<[email-masked]> wrote:

> Tony,
>
>>> Let's assume that there is a FooBar server in SiteA.  If
>>> another node in SiteA (NodeA) is communicating via a
>>> multi-party application to a node in SiteB (NodeB), and
>>> wants  to refer NodeB to the FooBar server in SiteA, what
>>> does it do?
>
> TH> Send a name.
>...
> In any event, please note that the suggestion that
> applications are required to use names, rather than IP
> addresses, is new.
>
> Completely new.
>
> As in, it has not been part of the Internet architecture for
> the past 25 years.
>
> So we all should be a tad careful about claiming that failure
> to use that enhancement represents a failure.  A new idea that
> is good is good, but failure to use that idea previously is
> not "broken".

Hmm.  Maybe some clarification is in order, since at least three 
different, and contradictory, claims have been made about this 
principle.

The "use names and not addresses to facilitate the transition to 
IPv6" principle was articulated some years ago, I'm pretty sure 
back when I was still Apps AD.   It was discussed at the time, 
and should not now come as a surprise to anyone.   However, my 
understanding --then and now-- was that what we agreed to was to 
try to move away from the presentation form of IP addresses on 
the user interface side of applications.  For example, we wanted 
to strongly discourage the use of addresses in URLs, we wanted 
to see an address in a telnet command or in setting up an FTP 
command channel only for debugging (if that) and so on.

Today's implied claim that the principle extends to use of names 
within and between applications is new to me.  There are all 
sorts of reasons why I think it is impractical. Certainly it is 
not something I would have consciously agreed to at any time in 
the last decade or so.  In addition to the reasons that have 
been given, there is the small matter that DNS resolvers use 
timeout logic that is measured in seconds -- tolerable for 
one-time use when an application starts up, and maybe every 
half-hour or so thereafter, but almost inconceivable each time 
an application needs to look at an address or pass an address 
reference to a machine with which it is already conducting a 
dialogue.  Worse, some applications are likely to get very 
confused if they go back to the DNS a second time and get very 
different address information (or even a different ordering of a 
set of addresses) to be used in conjunction with connections 
that are already open.

Now, this may suggest that we need new facilities.  Or perhaps 
we just need a way to say "use this address, but the same prefix 
you already have for me" or "look the name up again, and pick 
the address you get back that matches the prefix you see for 
me".  I don't know.  I am pretty sure that no one has discussed 
those issues with the applications area at any time since IPv6 
started to gell.

I'm equally concerned about statements like:

TH> Any app that sends topology locator information without 
understanding
TH> the topology is broken.

and

> That is not clear, but in any case the deployed Internet is
> not the same as it was 25 years ago. From RFC 791;

> 	A distinction is made between names, addresses, and
> 	routes [4].   A name indicates what we seek.  An address
> 	indicates where it is.  A route indicates how to get
> 	there.  The internet protocol deals primarily with
> 	addresses.  It is the task of higher level (i.e.,
> 	host-to-host or application) protocols to make the
> 	mapping from names to addresses.   The internet module
> 	maps internet addresses to local net addresses.  It is
> 	the task of lower level (i.e., local net or gateways)
> 	procedures to make the mapping from local net addresses
> 	to routes.

> Mapping names to addresses is a simple task. One could argue
> that it was so simple that apps took the shortcut of using the
> 'where' to also define the 'what'. That does not mean the
> requirement for apps to keep a clear context for 'what' is a
> new requirement.

Tony, I agree with the first statement.  I'd almost suggest that 
it is self-evidently true, which may be the point you are trying 
to make. But we get different meanings from the RFC 791 quote, 
and that may be a lot of the difference in perspective here.  At 
the time 791 was written, addresses were not routes, or bound to 
routes.  Consequently, it would have been inappropriate to refer 
to them as "topology locators".  They were just addresses. 
Routes, and hence topology and topology locators, were 
invisible, not only to the applications, but even to TCP.  An 
application that uses addresses in the 791 sense isn't involved 
with topology at all and has no clue about network topology. 
Even the "here" and "not here" implied by testing whether an 
address was on the same network was, and remains, invisible to 
most applications.

When we introduced subnetting and then CIDR and, more 
specifically, route aggregation, we changed the character of 
that name/ address/ route separation.  For the first time, an 
address manifestly implied more about topology than "same 
network or not".  In the process, we effectively introduced the 
notions of PI and PD space, and made multihoming nearly 
impossible for anyone but very large enterprises plus those with 
the financial resources to bully their way in.  But, even then, 
I suggest that calling an address a "topology locator" is 
something of a stretch, so, while your statement is true about 
"topology locators", it is not clear to me that it applies to IP 
addresses, at least in IPv4.

The IPng effort started off with a number of problems to be 
solved.   More address space was one.  My recollection is that 
getting multihoming back was another and that we knew that we 
had a route-scaling problem as well as an address-scaling one. 
This multiple-prefix-per-host stuff is dandy in theory, but 
we've yet to see it work to permit widespread multihoming 
without exploding the routing tables.  My own sense is that it 
will not work unless we end up dividing the world up into a 
handful of super-ISPs with local ISPs organized in strict 
hierarchy.  To overdramatize things a bit (I hope), if the IPv6 
architecture requires that business model in order to keep 
routing working, IPv6 will fail and, probably, so will the 
Internet.

My hope continues to be that we will eventually devise, and 
evolve to, a routing architecture with much better scaling 
properties than full-knowledge link state models and Dijkstra, 
or Dijkstra-equivalent, calculations performed on each state 
change.  While there hasn't been much visible motion, I don't 
believe the IETF community has given up on that class of change. 
To decide that IPv6 addresses are locators that are bound to the 
topology of the network, and doing applications design on that 
basis, runs the risk of precluding such routing options.    I 
haven't seen where or when the community has agreed that "IPv6 
Address == topological locator" as a matter of architecture and 
I'm fairly relieved by that.

And, as Dave Crocker pointed out (if I interpret his remarks 
correctly), if IPv6 addresses are topology locators, then we are 
going to need identifiers that have the appropriate binding 
properties to those addresses.  The DNS won't do it: it is too 
slow, updates take too long, inconsistent responses from 
different servers while updates propagate are the norm, and it 
isn't tightly enough bound to the addressing mechanism to be 
able to yield "best address for purpose" information.

My own guess is that the principle behind the statement you 
quote from 791 is correct, but the terminology may need to be 
adjusted.  Today, I would say that there is an important 
separation between name, address-identifier, and 
topology-locator.  If IPv6 addresses are the topology-locators 
of the IPv6 universe, then there isn't going to be much real 
progress on application upgrading and deployment until we invent 
address-identifiers.  On the other hand, if IPv6 addresses are 
to serve as address-identifiers (as IPv4 addresses have done 
since the 70s), then we shouldn't expect applications to either 
understand any hidden topology semantics they might have or to 
refrain from using the addresses because those topology 
semantics exist.

  regards,
    john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 01 Apr 2003 15:08:06 +0200

--On mandag, mars 31, 2003 16:44:35 -0800 Dave Crocker <[email-masked]> 
wrote:

> In any event, please note that the suggestion that applications are
> required to use names, rather than IP addresses, is new.
>
> Completely new.
>
> As in, it has not been part of the Internet architecture for the past 25
> years.

RFC 1958, June 1996:

4. Name and address issues

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

yes, "required" is new, and IMHO unspportable.

                    Harald

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 1 Apr 2003 07:16:38 -0800

John,

I am not going to comment on each point, but your general perspective
highlights the problem at hand. The discussions on the multi6 mail list
have basically been about how the routing community believes the address
is the topology locator, while your & Dave's comments show the app
community believes it is an identifier. Where the two communities agree
is that the DNS as currently deployed and operated is not up to the task
of handling the identifier role. My point is that this is due more to
implementation & operation than architecture. Also I believe the multi6
discussion about creating a new identifier, to get the app community to
stop camping on the topology locator, will end up creating a distributed
database infrastructure almost identical to DNS. We don't need two of
those, so we should fix DNS.

I disagree with the perspective that subnetting or CIDR changed the
character of the address. It continues to indicate on the local network
or not, and anything not is handed to a node tasked to figure out the
next hop. I think what has changed since RFC 791 is the geographic scope
of the local network, not the architectural concepts.

Tony

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Monday, March 31, 2003 10:13 PM
> To: Dave Crocker; Tony Hain
> Cc: 'Margaret Wasserman'; [email-masked]
> Subject: Re: Thinking differently about names and addresses
> 
> 
> >>> Let's assume that there is a FooBar server in SiteA.  If another 
> >>> node in SiteA (NodeA) is communicating via a multi-party 
> application 
> >>> to a node in SiteB (NodeB), and wants  to refer NodeB to 
> the FooBar 
> >>> server in SiteA, what does it do?
> >
> > TH> Send a name.
> >...
> applications are 
> > As in, it has not been part of the Internet architecture 
> for the past 
> > 25 years.
> >
> > So we all should be a tad careful about claiming that 
> failure to use 
> > that enhancement represents a failure.  A new idea that is good is 
> > good, but failure to use that idea previously is not "broken".
> 
> > That is not clear, but in any case the deployed Internet is not the 
> > same as it was 25 years ago. From RFC 791;
> 
> > Mapping names to addresses is a simple task. One could 
> argue that it 
> > was so simple that apps took the shortcut of using the 
> 'where' to also 
> > define the 'what'. That does not mean the requirement for 
> apps to keep 
> > a clear context for 'what' is a new requirement.
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Apr 2003 11:11:17 -0500

> highlights the problem at hand. The discussions on the multi6 mail
> list have basically been about how the routing community believes the
> address is the topology locator, while your & Dave's comments show the
> app community believes it is an identifier.

it's clear that it is both of these, and furthermore that this was a
deliberate design compromise for the sake of reduced complexity.

> Where the two communities
> agree is that the DNS as currently deployed and operated is not up to
> the task of handling the identifier role. My point is that this is due
> more to implementation & operation than architecture.

disagree.  it's largely a consequence of the design decision to make the
DNS namespace federated and the lookup widely distributed across the
network.  if DNS didn't work this way, it wouldn't be nearly as usable
for the things we use DNS for.  the fact that DNS doesn't solve all
naming problems shouldn't bother us any more than the fact that IP
doesn't solve all naming problems.

> Also I believe
> the multi6 discussion about creating a new identifier, to get the app
> community to stop camping on the topology locator, will end up
> creating a distributed database infrastructure almost identical to
> DNS. 

if what you claim is true (I haven't followed multi6) it's clearly
unworkable.

to ease transition, any new identifier needs to use the same structure
as an IP address; and indirection is far better handled as a side-effect
of sending a packet than by requiring an explicit lookup.  also,
proactive propagation of updates (replication) is far better at
producing reliable results than retroactive propagation (cacheing). IOW,
mobile IP is a lot closer to a reasonable solution to this problem than
DNS.

> We don't need two of those, so we should fix DNS.

DNS could certainly be improved in various ways, but you can't fix DNS
to serve the purpose you want it to serve.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Apr 2003 08:22:35 -0800

Tony,

TH>  The discussions on the multi6 mail list
TH> have basically been about how the routing community believes the address
TH> is the topology locator, while your & Dave's comments show the app
TH> community believes it is an identifier.

By definition, an address is a topology indicator.  Always.

The point that I was trying to make is that the uniqueness of an
address's bits permits its use as an uninterrupted label, ie, a name.
(Up a few layers, this is the basis for including URL's in the set of
URI's.)

So this is not about competing definitions of the bits, but different
USES of them.  IP needs to interpret those bits.  Hence, it MUST handle
them as topological indicators.  Apps that use IP addresses use them as
simple labels.

TH>  Where the two communities agree
TH> is that the DNS as currently deployed and operated is not up to the task
TH> of handling the identifier role. My point is that this is due more to
TH> implementation & operation than architecture.

Responding to this point takes us into the world of solutions. I suspect
we will all find this topic more productive (and probably more pleasant)
when we move into that mode.

TH> Also I believe the multi6
TH> discussion about creating a new identifier, to get the app community to
TH> stop camping on the topology locator, will end up creating a distributed
TH> database infrastructure almost identical to DNS. We don't need two of
TH> those, so we should fix DNS.

That was my own view roughly 10 years ago, when Noel Chiappa was pushing
for use of an end-point identifier, as part of what is now IPv6.

At this stage, I would want to hear the requirements (or probably
better, the desired usage scenarios) before being certain that a
modified DNS is the answer.

TH> I disagree with the perspective that subnetting or CIDR changed the
TH> character of the address.

Before:  IP addresses contained no topological information.

After:   IP addresses contained quite a bit of topological information
AND that information was (is) used quite heavily.

A change that permits a routing table to be reduced massively
necessarily involves changing the character of something.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Apr 2003 08:08:59 -0800

Harald,

...
>> As in, it has not been part of the Internet architecture for the past 25

HTA> RFC 1958, June 1996:

HTA> 4. Name and address issues

HTA> yes, "required" is new, and IMHO unspportable.

whimsical:  ok, so only *20* years...

serious: the "required" was intended as the only significant point.
(this is worth emphasizing, since it is key to the question of whether
apps are "broken" or whether we have a new problem to solve.)

Obviously, names have been a part of the Internet architecture dating
back before there was an Internet architecture. (My decrepit memory
thinks Hosts.txt was present in 1972. If not, it was certainly very
quickly thereafter.)

d/

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 1 Apr 2003 10:28:14 -0800

Dave Crocker wrote:
> TH> have basically been about how the routing community believes the 
> TH> address is the topology locator, while your & Dave's 
> comments show 
> TH> the app community believes it is an identifier.
> 
> The point that I was trying to make is that the uniqueness of 
> an address's bits permits its use as an uninterrupted label, 
> ie, a name. (Up a few layers, this is the basis for including 
> URL's in the set of
> URI's.)

And my point is that when you take that uninterpreted label out of its
context of uniqueness, it can't be used as a meaningful name. The real
problem that the app community has with 1918 & SL is that they validly
want a single namespace, but they also want to insist on using addresses
as names. The disjoint nature of the deployed address space precludes
both of those actions at the same time. 

> 
> So this is not about competing definitions of the bits, but 
> different USES of them.  IP needs to interpret those bits.  
> Hence, it MUST handle them as topological indicators.  Apps 
> that use IP addresses use them as simple labels.

Which I would call competing definitions, but that is not the point.
What the app community is indirectly saying is that we use topology
locators as names, we have to have a single rooted name space, therefore
the locators have to point at a unified topology. The reality of
deployed networks is that there will be routing filters, therefore we
have a disjoint views of the address space. In addition, the app
community expects their use of the topology locator as a name to be
stable over a long period, while the routing community wants the
flexibility to change the locator as needed for significant* topology
changes. These 'USES' are clearly at odds.

* I define significant in this context as disruption of an ISP/customer
interconnect, that would cause a prefix to become unusable. These are
relatively infrequent in relation to overall topology changes, but more
frequent than current procedures for DNS changes.

> TH> is that the DNS as currently deployed and operated is not 
> up to the 
> TH> task of handling the identifier role. My point is that 
> this is due 
> TH> more to implementation & operation than architecture.
> 
> Responding to this point takes us into the world of 
> solutions. I suspect we will all find this topic more 
> productive (and probably more pleasant) when we move into that mode.
> 
> 
> TH> discussion about creating a new identifier, to get the 
> app community 
> TH> to stop camping on the topology locator, will end up creating a 
> TH> distributed database infrastructure almost identical to DNS. We 
> TH> don't need two of those, so we should fix DNS.
> 
> That was my own view roughly 10 years ago, when Noel Chiappa 
> was pushing for use of an end-point identifier, as part of 
> what is now IPv6.
> 
> At this stage, I would want to hear the requirements (or 
> probably better, the desired usage scenarios) before being 
> certain that a modified DNS is the answer.

We agree that we need to understand the requirements before starting on
a design.

> necessarily involves changing the character of something.

You cut off the significant part. Since at least RFC 791, IP addresses
have always indicated the topology significance of local or remote
networks. What subnetting did was add structure as the definition of
'local' was reduced in geographic scope. What CIDR did was add structure
to the network identifier part to reduce the effort of finding the
proper next hop as the number of remote networks grew. Neither of those
acts changed the architectural nature of the address, just the bit
positions.  

Clearly the app community has taken advantage of using the 'where'
identifier as a 'what' identifier. This worked fine until ~1987 when
people started putting in routing filters which fragmented views of the
'where' space. The fragmented views became more widespread as sites that
had squatted on unallocated space interconnected without injecting
global routes. With 1597/1918, the fragmentation was formalized and the
market demand for squatting disappeared. What the anti-SL camp is
arguing is that if we only take one step back, we will rid ourselves of
the problem of fragmented views. What they miss is that reintroduces the
market demand for squatting, because we offer no alternative, as well as
the point that it doesn't really remove the original issue of filtering
causing differing views. 

We really need a big-picture perspective here before any knee-jerk
reactions. I have one alternative for how to preallocate space to deal
with the squatting issue, but even that doesn't solve the disconnect
between the app community view of a unified 'where' space to be used as
'whats', when the network managers will continue to install route
filters and fragment the 'where' space. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Apr 2003 14:20:06 -0500

> context of uniqueness, it can't be used as a meaningful name.

which is why addresses need to be unique.

> The real problem that the app community has with 1918 & SL is that
> they validly want a single namespace, but they also want to insist on
> using addresses as names. 

not exactly.  there are valid cases for apps using addresses even when
names exist.  sometimes you really do want to talk to a host that is at
a particular network location.  

as for 'apps insist on using addresses as names' - this is because the
architecture doesn't provide names that are good enough to use as
endpoint identifiers for all or even most cases.  you might think this
is unfortunate, and I might agree, but it doesn't follow that we should
force all apps to use DNS.  and fixing the architecture to have a
reliable endpoint identifier is a pipe dream.  nobody has demonstrated
how to make it workable.

also re: 'using addresses as names' -  this is a bogus distinction,
addresses *are* names to a large degree.  the prefix of an address is an
arbitrary bit pattern (i.e. a name), the suffix is an arbitrary bit
pattern. only the bits in the middle have anything to do with topology. 
maybe they're closer to names of locations than to names of hosts, but
they're still names.

> locators as names, we have to have a single rooted name space,
> therefore the locators have to point at a unified topology. 

at least in the current IP architecture, and we're nowhere close to
having a workable new architecture that separates locators from names.

> The reality of deployed networks is that there will be routing
> filters, therefore we have a disjoint views of the address space. In
> addition, the app community expects their use of the topology locator
> as a name to be stable over a long period,

not just the app community.  TCP expects this; it cannot recover from
address changes. or does the routing community think that it's okay to
interrupt TCP connections at a whim?

> while the routing community
> wants the flexibility to change the locator as needed for significant*
> topology changes. These 'USES' are clearly at odds.

yes, there are competing concerns.  this calls for a compromise about
how stable addresses need to be, not for having infinitely stable
addresses nor for having addresses change at a whim. 

> We agree that we need to understand the requirements before starting
> on a design.

the new namespace:

a) must to work underneath transport and other protocols, so that
those protocols' associations can survive address changes.
b) must provide quick, secure, reliable indirection
c) must provide for timely update and/or the ability to recover from
stale mapping information quickly and transparently to the application
d) must have appropriate granularity/precision - generally that of
a host/port, so that connections from multiple sources to the same
endpoint identifier reach the same process 
e) requirement c notwithstanding, there's some need for ability to do
redirects at connection setup time and possibly later, to support
process mobility and/or fanout within server farms
f) must have global scope so that referrals work

> people started putting in routing filters which fragmented views of
> the'where' space. 

no, it still works fine in a global address space.  you are confusing 
address scope with address reachability.  apps aren't expected to be
able to reach hosts when there are explicit filters in place, so the
fact that those filters break apps is considered a feature.  however
apps are expected to accomodate private addresses, and the fact that
many apps cannot reasonably do this is considered a bug in the app.

> What the
> anti-SL camp is arguing is that if we only take one step back, we will
> rid ourselves of the problem of fragmented views.

what the consensus is arguing is that private addresses were a mistake.

> What they miss is
> that reintroduces the market demand for squatting, because we offer no
> alternative,

there is no demand for squatting until addresses are scarce.  v6
addresses are not scarce.

> between the app community view of a unified 'where' space to be used
> as'whats', when the network managers will continue to install route

the route filters do not fragment the where space, so this is not a
problem.

Keith