John C Klensin wrote:
[edited]
> ... > I strongly suspect that we are using words in ways that results > in miscommunication, because I think there is a third > alternative. That alternative may fall into the category you > describe as "passing around name objects", or maybe it doesn't. > >From my perspective --which is definitely the applications end > of the stack looking down-- the problem is all about data > abstraction. I'm going to try to switch terminology here in the > hope that it will help clarify things. Suppose the application > gets a well-constructed handle, and passes that handle "around" > --either to other applications or to different interfaces to the > stack/network. I don't see the application as dealing in > topology information by doing that, even if the handle > ultimately identifies information that is deeply > topology-sensitive and/or if the process that produces the > handle uses topological information, or probes the network to > develop such information. The important thing from that > perspective is that the application is dealing with the handle > as an opaque object, without trying to open it up and evaluate > its meaning or semantics (with regard to the network or > otherwise).
In general I agree, but the difference of perspective is that ignoring the fact that the well constructed handle is actually derived from topology information does not make the issue go away. The only way you can get the handle you are looking for is to have something below you sort out the topological reality. I agree the current name service is not up to the task, and I believe that we need to get that fixed. Unfortunately it looks like it will take some very crisp architectural guidance to get the IESG to refocus the DNS related WGs to even discuss the issues. The sad part is that many of the participants there already ship or run variants that help address this problem, but they have agreed not to work on standardizing it.
Having a mechanism within each host which can sort out the topological issues seems like something we will have to explore. It is not clear to me that DNS is the solution, though it may be a part of the solution. More below.
> > >From that point of view, having an application go to the stack > and say "given these criteria, give me a handle on the interface > or address I should use" or "given this DNS name, and these > criteria, give me a handle on the address I should use" does not > involve the application being topology-aware, nor does it imply > the application doing something evil because it picks an address > (or virtual interface, or...) without understanding the > topology. The handle is opaque and and an abstraction -- as far > as the application is concerned, it doesn't have any semantics, > regardless of whether lower layers of the stack can derive > semantics from it or from whatever they (but not the > application) can figure out it is bound to.
This points out that I have been imprecise by claiming that passing names are sufficient, all the criteria you would use for local communication with the stack are the 'name' in the context of my previous mail.
As long as the handle stays contained within the machine you are fine. The problem arises when the app passes that handle to another node, believing that the topology specific information is already there. If the blob passed were the same as what the app used to acquire the local handle, the other nodes would acquire appropriate local handles.
Agree that these handles can't move off the host on which they are valid.
Recognizing applications DO want to be able to send identifying information in the course of transactions with other hosts, and that it is important to make such applications function, perhaps it's time to actually address this problem with some degree of standardization. Do we really want to continue having applications try (and often fail) to do this work? Perhaps we're discussing something that some become an integral component of the Internet Protocol suite.
It would make more sense for an application to make a call to an API that says "I want to hand off identifying information about host X to host Y. Please package me up information to sent to X so that it will be able to understand what I mean." The result of that API would be a blob which the application would send. The receiving application would pass that blob to an API on its end, effectively saying "I got this blob from host A, and it wants me to use it to set up communication. Please figure out what it meant, and give me a handle for talking to the proper destination."
The application would not see (or care) how this is actually implemented. Application writers should not need to know or care. Under the covers, those APIs could result in some sort of work done solely on the hosts in question, or could result in some sort of exchange amongst the hosts to figure out the best way to make that communication happen. Getting this decision out of the application space is the key point. This would simplify the implemenentation of applications which want to do these types of third party communications, and provide a standardized mechanism for implementation. With that standardized, a uniform firewall and NAT traversal mechanism could be considered. Note that there is a great deal of room for exploration of mechanisms and techniques to make this work. I'm not proposing a singular solution, but merely a framework for facilitating that solution.
A mention of proper layering was made earlier in this discussion thread. It's time we took a serious look at how to improve on the mechanisms used. Solving this layering issue could benefit both IPv4 and IPv6 implementations. As noted, the problem is not new at all, though perhaps now is the time to shed light on the matter.