On Tuesday 15 November 2005 23:42, Erik Nordmark wrote: > Pekka Nikander wrote: (...)
> > 2a. Implement KHIs on the top of SHIM6 > > - changes stack but minimally from 1a, perhaps not at all > > - does not change applications > > I don't understand the last point. A KHI couldn't be used in > referrals unless we have a ubiquitous and scalable KHI->locator > lookup system, and I don't think we know how to build such a thing > (yet). Yes and no. We do not know yet how to build a scalable KHI->locator lookup system. But OTOH, a KHI can be used in FTP referrals, we had it working. Then, for the rest of applications using referrals that break with KHIs, one can argue that they probably break in presence of NATs too. But nobody's perfect ;) Perhaps it's acceptable for a _transition_ and _experimental_ tool. I used to run HIP on the laptop with which I am writing this message. It had vanilla IP and IPsec stacks plus a HIP userland daemon, and still I was able to use both HIP and IP at the same time. That was possible because we could make the distinction between an IPv6 address (starting with binary 00 or 11) and a HIT (starting with binary 10 or 01.) When this distinction was lost I was not any longer able to use the _vanilla_ IPsec SPD to specify that packets send from any HIT to any HIT should be encrypted and integrity protected by ESP (hence causing HIP exchange). Yes that was hacky and overloaded, but again it was just working (as a transition and experimental tool.) > > - continues identifier / locator split by > > - requires additional infrastructure to KHI->locator mapping > > - works only with IPv6 > > > > 2b. Implement HIP with KHIs in the legacy API > > - does not change stack from 1b > > - does not change applications > > - continues identifier / locator split by > > - making a minimal difference in identifier and locator > > syntax and semantics > > - requires additional infrastructure to KHI->locator mapping > > - works with both IPv4 and IPv6 > > - is more heavyweight than SHIM6 > > I think there is also a 2c to explore, which hasn't been talked > about much. Instead of doing KHI, define Hierarchically allocated > 128-bit identifiers (hereby named HAI). If we have those we can use > existing scalable infrastructure for lookups (defining some new DNS > RR, or perhaps just use PTR and AAAA). > This would still be more heavyweight than SHIM6, since the lookup > of the locators is needed before communication can start. > But it would run on top shim6 for the locator agility part. The 2c you are referring to used to exist as 'Type 2' HITs (64 bits hierarchical prefix for lookup + 64 bits of public key hash). They were removed lately by the working group because the HIT diversity was problematic and there was no consensus to keep them alive. --julien -- julien _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
