[There is background meta discussion going on on where this discussion should be located at. However, since one specific point here is site local, maybe we can keep this here for a while. On the other hand, if this moves (again) completely to the multi-homing/mobility side, multi6 might be more appropriate, and chairs there have indicated that it would be ok.]
> * Stable (or reliable) end-point identifiers > * Resiliency of application (protocol) in the face of sudden > IP address changes > * Self-organised networks
These are the goals that we need to focus on.
From this point of view, the only (semi-)stable end-point identifiers we have today are IP addresses.
The trouble isn't that IP addresses don't make for good end-point identifiers or that they don't make for good topology/interface identifiers, but that they can't do both at the same time.
Well, almost but not quite. We also have the limitations of the current routing technology, which make IP addresses really suitable only as topology/network/interface identifiers.
Furthermore, it will take quite a long time to get something to replace the IP addresses as end-point identifiers. As has been discussed several times, domain names do not work well enough, and therefore we need a new name space, I think.
What exactly do you mean here? A 128 bit value that we can put in all the right places inside the applications and transport protocols (but not on the wire), or something that isn't such a 128 bit value?
Well, my current personal opinion is that actual end-point identifiers should most probably be cryptographic in nature, due to a number of security reasons. On the other hand, I also think that we need some way of representing those end-point identifiers as 128- or even 32-bit value, to be used in legacy APIs and withing the stack (but probably not on the wire). It is the a third issue whether we want to use the cryptographic nature of the actual identifiers in all transactions. Probably not: sometimes using them just as bit strings is likely to be appropriate.
Now, when I say that "end-point identifiers replace IP addresses", I am mostly speaking about the semantic change. In a way, already using Mobile IPv6 route optimization presents such a semantic change, though in very primitive form. Using stable PI addresses locally to name hosts for administrative purposes might be another primitive example of such a semantic change. On the other hand, the real change only occurs when the end-point identifiers cease to be IP addresses; MIPv6 RO and PI addresses both fail on this test.
I think Robert Honore put much of the need for end-point identifiers
very nicely in his recent posting to the general IETF discussion list. End-point identifiers are needed for many administrative purposes,
to permanently name hosts, services, and other end-point-like entities.
What comes to domain names, my primary concern is their lack of security, and DNSsec does not seem to be the answer. There are also other problems with DNS names, including the difficulties of integrating DynDNS and DNSsec, long update times (due to caching), dependency of centralized (hierarchical) administration, etc.
One very important property of [end-point] identifiers is that they have enough structure to be used as a key in a lookup process. I haven't seen a write-up of HH addresses, but from what I understand they lack this property.
Well, my (perhaps poor) understanding from the FARA work (by Bob Braden, Aaron Falk and others) seems to indicate that it may be perfectly OK to use identifiers even if they cannot be used as keys in a lookup process. However, my thinking process is still going on, and I can't give any real argument here.
On the other hand, my (again poor) understanding from the recent Distributed Hash Table papers seems to indicate that it is fairly easy to use random strings as lookup keys in a distributed, Byzantineously robust lookup system. It even looks possible that such a system could be built in a piece wise manner, letting it scale up in a "natural" way.
Thirdly, nothing prevents one from arranging the identifier space in such a manner that they can be used as hierarchical lookup keys whenever such a lookup process is needed. I think that should be possible even for Hinden/Haberman addresses, since such a lookup system would have limited scope.
And note that the use of non-routable, stable addresses isn't free: you need to go through a lookup process to find the locators.
Using any address-independent identifiers or names costs something. On the other hand, if you use the domain name system anyway, you can make a single query to get both the end-point identifier and a set of locators.
If you use reachable PA as identifiers you have the option of connecting first and adding multihomedness later.
Yes, provided that your PA address works, right now. Which is one dependency that we are trying to avoid. Let me take a counterexample. If you use PI addresses locally for administrative purposes (think SSH), you can use them even if your network is disconnected, going through renumbering, or otherwise failing to get any PA prefixes.
And you probably need PA for a while anyway to support legacy
IPv6 implementations or even as a fallback for when the new mapping system is unavailable.
I don't see PAs going away any soon if ever, even at the application level. There are good reasons for still sending UDP packets and even sometimes opening TCP connections to PA addresses even if we had stable, reliable, address and location independent end-point identifiers.
Actually I think MAST is very close to mobility, and could, if developed further, easily replace what's on the table now for mobility, while at the same time attack the multihoming problem, for which current MIPv6 doesn't provide many useful hooks.
Sure it could. In perhaps 4-5 years. MIPv6 is here, now. Again, what I am basically saying is that we seem to need a roadmap, with short term solutions and longer term solutions.
However, since I do think that we most probably do need stable and secure end-point identifiers, I think that something like HIP will be more appropriate.
Doing crypto all the time isn't the answer.
Doing crypto all the time isn't the answer, I agree. But you do need crypto for some things, unfortunately. Separating the locators and end-point identifiers creates a number of very concrete and nasty security problems, at the IP layer. That is, those problems are NOT application level security problems, but threats to the well functioning of the very infrastructure.
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt tries to explain the most important ones of these problems.
Given the above, I think we could have a roadmap that might look something like the following:
Stable identifiers: Hinden/Haberman -------------> New name space for end-point Resiliency on Huitema MIPv6 --> (MAST) ---> identifiers address changes: multi-homing (maybe HIP)
The way I see it:
1. Define a generic address mangling system between IP and transports based on stable host identifiers OR simple session identifiers
This, as such, is already a long term goal, in my opinion. Since this is likely to require code changes, just deployment alone is likely take a long time, not counting the time needed to reach consensus at the IETF.
2. Make no assumptions about the identifiers except that the transports must understand them, so: PA, PI/non 2000::/3 or even IPv4
Sorry, but I don't understand what you are trying to say. Are you trying to say that we need to have 128 and 32 bit handles so that they can be used by legacy applications and APIs? If so, I do agree.
3. Define mechanisms to populate the hostid/sesid+mangling table. Can be: a. out of band using distributed lookup database b. using in-band negotiation (= like MAST) c. crypto: modified IPsec or HIP
Hmm. It may be a good idea to have multiple mechanisms to get the identifier->addresses mappings. However, it would be good if we had just a single control protocol and security mechanism for verifying that the mappings are "authorized" and do not endanger the infrastructure.
--Pekka Nikander
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
