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