Pekka Nikander wrote:
Geoff, to quote my longer message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html,
"I fully agree with you that a new identifier name space should not be
mixed with any existing locator space." Hence, from what I called "an
ideal architectural point of view", I agree with what you write above,
with the difference that I don't see need for any registries.
Statistical uniqueness seems to be enough.
I think it would be wise to reserve from space for identifiers in the
128-bit IPv6 space, whether they are statistically unique or whether
they have internal hierarchy.
The KHI draft seems to assume that we would only ever need 128
identifiers that have no internal hierarchy, which seems short-sighted
as best, given how little we know about the feasibility of doing lookups
in flat very large spaces.
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?
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.
Erik
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
