Re: Thinking differently about names and addresses

[John C Klensin <[e-mail]>]

--On Monday, 31 March, 2003 16:44 -0800 Dave Crocker 
<[e-mail]> 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