You listed out some of the trade-offs. The one you only inferred and I'll be more explict about is that doing it once correctly has a benefit of not all UDP-based applications having to reinvent the wheel (and probably inconsistently).
Gee. I think I said this before somewhere.
Eliot
Erik Nordmark wrote:
But I have not seen a clear summary of what will be made better nor a clear argument against using domain names, as the stable, public, address-independent end-point identifier.
Dave,
I haven't seen such a list either.
It might be useful to split your question apart into two questions: 1. Using current domain names and their mapping to AAAA records 2. Using variable length identifiers
For #1 folks have pointed out that a currently domain names are often used as service names and not host names, and one can't tell whether multiple AAAA records for the same name imply multiple hosts implementing the same service or multiple locators assigned to a single host, or something in between.
I've also seen statements in the past that current domain name usage isn't one that guarantees uniqness. One example of this are cases when www.example.com brings you to different http content from the inside of the company than from the outside of the company. Another example are hosts that don't know their fqdn but only the first component of their fqdn.
I think all these can be addressed and still use FQDNs as identifiers. (For instance by having some different RRtype which allows telling "service" apart from "host".)
The issues around #2 has to do with how the protocols above IP operate. If the identifier is only used to establish some state which is only used when the locators change, then it is possible to have the upper layer protocols operate on the locators when sending and receiving packets. Thus you'd have multi-locator ULPs. I think this implies that the ULPs need to be involved in locator changes. In the case of UDP I think this implies that the applications will be multi-locator aware and involved in locator changes.
An alternate approach, which requires fixed length identifiers which can fit into existing 128 bit fields, is to have a shim layer above IP which handles id<->locator mappings and have the ULPs operate on the identifiers. In this case the locator changes can be handled in that shim layer. And under some constraints it appears possible to transition to such a scheme without touching applications which use the IPv6 APIs.
Whether the future evolution of the protocols is better served by having fixed length identifiers at the IP level or FQDNs as identifiers is hard to tell.
So there are definitely tradeoffs to take into account here.
Erik
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
