In looking over various archives and documents, on the matter of separating node address from node identifier, I have not been able to find or develop a clear summary of the reasons the identifier cannot be a domain name.
I don't see any reason why it can't. A while ago I argued that it should be, as the fact that an API change was needed to support IPv6 makes that I still can't use the protocol for most applications even though my OS and network support it. If we let the application talk to the network using the FQDN, there are no addresses inside the application so no problem supporting different protocols. The same for supporting new namespaces: just add the right resolver code to the stack and you're in business. The application only sees an opaque bit string.
However, there are a few things that make this somewhat difficult. First of all, we really need something between the FQDN (which is often used as a service identifier) and the locator address, because today many services are provided by more than one host. While every host is capable of providing the service, this doesn't mean each host has access to the other's transport state so we can't move transport sessions from host to host. So we need to group the locators per host. The simplest way to do this is FQDN -> host identifier -> locator. But this is solvable in other ways as well, of course. The same for the inherent dependence on the DNS.
But I think the most compelling reason to not do this is that changing the transport layer or introducing a new layer on top of the transport layer is a very painful process, as we can see by how long it's taking application writers to adopt the new IPv6 API. Now obviously if there are huge benefits we should still do it, but there aren't. Or rather, those benefits can be gained much easier, by not changing existing layers or introducing new layers, but only introducing a new API. This makes it possible for applications to talk to the network in a protocol- and hopefully even namespace-independent way, without any need for the other side to change as well. The idea behind a layer is that it talks to the same layer on the other end. That's not called for here, so a local API change is all that's needed.
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
