[Please direct replies either to the IPv6 or the IETF mailing lists, but not both. The default should be IPv6, imho.]
As IETF seen a lot of this stuff recently already, why not move the show to IPv6... Note also that multi6 is doing work in this area.
> * 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.
Don't forget about FQDNs.
We both agree, and I think quite a few others agree, that IP addresses are not very good end-point identifiers. However, they are used as such today.
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.
Today, a host has an IP address that is both present in the DNS in order to be usable as an identifier, and present on an interface to be usable as a locator. We can either keep the address we have in the DNS and create new locators, or create a new identifier that goes into the DNS and keep the current address(es) as locators.
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?
Consequently, we have to provide (semi-)stable IP addresses for IPv6 networks. Based on the recent discussion at the IPv6 WG, apparently people think that PA addresses are not stable enough. Hence, at least to me, the Hinden/Haberman addresses look like a good temporary solution. It seems to provide stable IP addresses, which can temporarily be used as end-point identifiers, with the expectation that they will be eventually replaced with "proper" end-point identifiers.
One very important property of 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.
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. If you use reachable PA as identifiers you have the option of connecting first and adding multihomedness later. 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.
What comes to application resiliency, Christian Huitema's approach of (mis)using Mobile IP may work well enough for a while. However, it has a number of architectural problems that make me to think about it only as a temporary solution. Going further, if we did not have any other reasons for "proper" end-point identifiers, I think that Dave Croker's MAST might be good next step.
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.
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.
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
2. Make no assumptions about the identifiers except that the transports must understand them, so: PA, PI/non 2000::/3 or even IPv4
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
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
