-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Monday, March 31, 2003 10:13 PM
To: Dave Crocker; Tony Hain
Cc: 'Margaret Wasserman'; ietf(_at_)ietf(_dot_)org
Subject: Re: Thinking differently about names and addresses
--On Monday, 31 March, 2003 16:44 -0800 Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> 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