Folks, Thanks for the responses. I decided to send one, aggregate response, rather than a flood of smaller ones.:
Dredging up some graduate school discussions, I suspect that this topic is differentiated between the classic "network" model of host to host communication, versus the "distributed processing" model of process to process communication. In the early 70's, for example, the Irvine Ring project (and, by the way, Netbios, later) use this process model. For wide-area networking, this has not gained much traction, at the lower packet-handling levels. (It was even interesting to watch MIT take over the Irvine work and eliminate the process addressing function.) My point is that I'm suspecting some folks are trying to lay a very different reference model onto the Internet than we have been using for the last 30 years. BEC> If you are looking for stable identifiers for "stacks" (in the BEC> terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely BEC> that an FQDN is a safe answer. It is probably worth noting that the NSRG report uses domain names to label the different stacks, in its own examples and in discussion. Whatever the reasons for that choice, I obviously find it interesting that they were used for that purpose. BEC> FQDNs are (mis)used in many ways; BEC> a name like www.example.com certainly doesn't identify a given IP stack BEC> on a given interface on a given host 1. When someone starts talking about identifying _interfaces_ I suspect they mean address, rather than 'end point identifier'. On the assumption that that is not what Brian meant, it's worth having this clarified. I'm confused by Bill's comment on this: " if there is an entity at a point in the topology, then the name maps nicely into the DNS". Domain names are not tied to network topology. They are tied to an administrative "topology", which is an entirely different thing. 2. If I understand the concern, here, it is that not _all_ domain names are endpoint identifiers. Erik also raised the point that domain names are used for different (and inconsistent?) purposes. One might be a host, another a service. When there are multiple records returned, they might refer to alternative systems or they might be alternate paths to the same service. My question is: so why does that mean that the ones that _are_ EIDs are not acceptable? What problems are caused by having multiple uses? BEC> I don't see that this has any functional advantage over an IPv6 address BEC> for that stack, and it introduces a DNS dependency for the transport layer. 1. I thought an IPv6 address was an address, not an end-point identifier. No? 2. The concern about introducing a DNS dependency into a lower layer, like transport, strikes me as pretty important, too. However, if we invent a new construct for an EID, we are a) introducing a new global administration requirement, and b) creating a dependency on it in that lower layer. So the concern with this new dependency is on the need for an EID, rather than the fact that it might be a domain name. No? MT> In the case of mobility and multihoming, you might want a stable MT> identifier on a per-packet basis which is independent of the routing MT> layer. A number of folks clearly have in mind using the identifier in every packet. My question is: Why is this needed? What requires putting the identifier in every packet, rather than using it a occasional, special points of an interaction, such as initial rendezvous? Erik's comments are particularly helpful for considering the requirements that folks are trying to satisfy: EN> It might be useful to split your question apart into two questions: EN> 1. Using current domain names and their mapping to AAAA records (or A records or even MX records or SRV records?) At any rate, this is the rendezvous function. EN> 2. Using variable length identifiers Or, to turn this one around, explaining when and why fixed-length IDs might be needed. EN> For #1 folks have pointed out that a currently domain names are often used EN> as service names and not host names, and one can't tell... my question is what problems are caused by multiple uses for domain names? how does it break the usage as endpoint ids? EN> I've also seen statements in the past that current domain name usage isn't EN> one that guarantees uniqness. I guess this underscores the need to be clear about the set of problems being tackled. Let's remember that IP datagrams are pretty basic. There are lots of very clever, useful things they do _not_ do. Are we, perhaps, trying to add other functionality to the IP service, beyond simply providing the current IP service, enhanced to support multihoming and mobility? For example, are we trying to add extra levels of security to the basic service, beyond simply making the use of multiple addresses carry the same, minimal security functions present for current, single-address IP? The "security" associated with a current, bare-bones mono-address host-to-host IP exchange is pretty darn small. I'd summarize it as simply being the assertion that a datagram probably did come from the IP address in the relevant field of the datagram. That's why MAST only tries to ensure an equivalent degree of assurance that latter datagrams with different IP addresses came from the same "system" that sent the first one. If you really need stronger security, use IPSEC, TLS, or whatever. Why do we need more, at the IP level for multihoming or mobility? EN> One example of this are cases when EN> www.example.com brings you to different http content from the inside of the EN> company than from the outside of the company. Clearly this is an important behavior. But should it be discerned at the IP level, or is this better suited to something above, say, transport? EN> I think all these can be addressed and still use FQDNs as identifiers. EN> (For instance by having some different RRtype which allows telling "service" EN> apart from "host".) Not surprisingly, I agree. EN> The issues around #2 has to do with how the protocols above IP operate. EN> If the identifier is only used to establish some state which is only used EN> when the locators change, then it is possible to have the upper layer protocols EN> operate on the locators when sending and receiving packets. Thus you'd have EN> multi-locator ULPs. ... EN> An alternate approach, which requires fixed length identifiers which can fit EN> into existing 128 bit fields, is to have a shim layer above IP which handles EN> id<->locator mappings and have the ULPs operate on the identifiers. Given the MAST proposal, obviously I favor the latter. However it's also clear that I do not believe the EID needs to be in every packet. I think it is a question of where some state information goes. One is to have the ID in every packet, making the IP address irrelevant. (The packet carries its own 'state' about the EID.) The alternative is to have a table of IP addresses that the EID maps to, and maintain the table in the participating hosts. Hence the IP address in the packet indexes to the EID when it is received.) d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253> -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------