Geoff,
I fully agree with you that a new identifier name space should not be
mixed with any existing locator space. In other words, from an ideal
architectural point of view, the goals of having non-routable
identifiers that have different semantics from IPv6 addresses
definitely do not warrant allocation from the IPv6 address space.
There we fully agree, and and that is exactly how I would like to see
the architecture to be in the longer run: an identifier space fully
separate from the locator space, the locator space consisting mainly
of IPv6 addresses. (The IPv4 story is also there, but it is more
messy; I'll skip it here for the sake of clarity.)
But we need a transition strategy!
Requiring a change that mandates that you
1) change your stack,
2) introduce a new piece of infrastructure, and
3) change your applications
is a no-starter. Such changes won't happen, or if they do, it takes
at least 10 years. Haven't we learned anything from the pain we are
feeling with IPv6?
Hence, we need a transition strategy that allows us to move from the
current situation into full blown identifier / locator split along a
path where each step is easy enough and brings benefits by itself.
My current view is that we will be progressing along two (or perhaps
three) parallel paths, the steps being roughly as follows:
1a. Implement SHIM6
- changes stack
- does not change applications
- implements identifier / locator split, but
- keeps identifier and locator semantics and syntax identical
- does not require any additional infrastructure
- works only with IPv6
1b. Implement "invisible" HIP that uses IP addresses as identifiers
- changes stack
- does not change applications
- implements identifier / locator split, but
- keeps identifier and locator semantics and syntax identical
- does not require any additional infrastructure
- works with both IPv4 and IPv6
- is more heavyweight than SHIM6
2a. Implement KHIs on the top of SHIM6
- changes stack but minimally from 1a, perhaps not at all
- does not change applications
- 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
3. Implement full HIP, with a new HIP-aware API
- does not change stack from 2b
- does change applications
- continues identifier / locator split by
- making identifiers and locators fully separate
- does not work any additional infrastructure compared to 2
- works with both IPv4 and IPv6
- is more heavyweight than SHIM6
Note that "HIP" above does not necessarily mean HIP as currently
defined, but something that combines host-layer mobility, multi-
homing, and security in a HIP-like way. It may grow from the current
HIP, it may grow from SHIM6, it may grow from IPsec+IKEv2+MOBIKE
+BTNS, or it may grow from MIP+MONAMI6, or from some combination of
those. Or we may end up having three or four different ways of
implementing it. What is important here is the semantics; if we end
up with multiple protocols to implement the semantics, well then we do.
To summarise my idea of the transition path, we progress step-by-step:
1. Change the stack
2. Introduce KHIs and supporting infrastructure
3. Change the API and applications
Trying to do any combination of the steps at once would decrease the
chances of success proportionally. Trying to do all three at once is
bound to fail.
So, the one and only reason why KHIs need to be *temporarily*
allocated from the IPv6 address space is to allow smooth transition
without requiring any changes to existing applications. In theory we
could live without such allocation, creating syntactically similar
overlapping spaces, but that would not be prudent engineering.
During the transition some identifiers are bound to leak to the
locator space, as Alan pointed out. It is just prudent engineering
to minimise the effects of such leaks, both in the implementation
(within the stack) and in the operational environment (in live
networks). Even if there was no implementation errors, some upper
layer protocols would still send these identifiers to non-consenting
hosts, causing indirect leaks.
Finally, note that we have very carefully proposed to use KHIs as an
*experiment* until 2009. By that time we will know much better if
the transition strategy is working, and if it is, how long longer we
will need the allocation. If the transition is not taking place at
all, which is of course possible, the allocation will be defaulted
back to IANA.
--Pekka
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
