Tony and Erik,
As I wrote, I can't see how we could convince the world from going
from where we are now to a world that requires people to change
their network stack, add a new piece of infrastructure, and to
change applications at the same time. That won't happen, any
more. Even a "killer application" that requires a stack change
and a piece of new infrastructure would be highly unlikely to
succeed. Hence, try to minimise the amount of change required at
each step.
If we follow that logic, how do we ever deploy any change? Any
kind of locator/identifier semantics is necessarily a change, just
because it is not the status quo. It will have impact somewhere in
the stack and run into the brick wall of actual deployability.
I submit, rather, that we have the ability to deploy change, but
that we only have one shot and we'd best do it right. IPv6, while
distributed, is not actually deployed in the sense of it being
enabled and pervasive yet. If we, as a body, reached consensus on
a change, it would be tractable to deploy new stacks. Obviously,
it needs to be a worthwhile change.
I would find it very nice if we could change the IP layer, install
infrastructure, and change the applications in one shot. I just
don't believe that we any more can do it -- we almost failed with
IPv6, and IMHO would have failed without the _severe_ address
scarcity outside of NA and EU.
People are replacing their computer and operating systems all the
time. Hence, a change to the stack *can* be fairly generally
implemented in 5-7 years, which is the time of most hosts get
replaced or at least undergo a software update.
Given a new stack is there, people *may* start to use a piece of new
infrastructure. Getting a new piece of DNS-like infra out there is
relatively easy. What is hard is to get people to generally use it
and to provide to running the infrastructure by sharing part of the
operational load. I wasn't there when DNS was initially deployed,
but as far as I have understood, it wasn't exactly painless.
If there is new functionality in the stack and new piece of
infrastructure, it *may* be possible to provide sufficient incentives
for upgrading the applications. I would imagine that security might
be such a feature in the long run.
One thing I didn't understand from the KHI draft is how we can
remove the use of these identifiers if they are successful. If
folks use them (meaning that they appear in the appropriate places
in the DNS, and that stacks know what is an identifier vs. a
locator based on the prefix), how would they disappear from use?
Is the assumption that the applications would switch to some other
API which explicitly passes HIs or HITs?
Yes, that is what I hope to eventually happen.
I don't see much benefits to move the applications to use the
existing APIs (e.g., connect()) with a KHI, to some other API which
passes a 128-bit HIT without a KHI prefix.
So I must be missing something.
I don't see much incentive for for doing a KHI -> pure HIT
transition, but I could imagine some incentive for KHI -> HI
transition, where HI can assumedly be much longer and even variable
size than a KHI or HIT.
But I do agree with you that we are missing some thinking here, i.e.,
we are missing a convincing set of incentives. Maybe we should go
and try to create them artificially, by reducing the KHI hash size so
that they will become insecure sooner that with the current design,
and by not allowing the experiment to be continued, say, beyond 2015
even with IETF consensus. _Sort_ of similar to what we did with
6bone, making it very clear from the beginning that people have to
eventually move forward.
If the currently secure hash size is about 96 bits, 120 bits can be
expected to become insecure in about 24 years.... Maybe that is too
much; OTOH, given the recent advances in breaking SHA-1, we should
have *some* marginal....
--Pekka
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
