Dear Geoff and Brian,
Its a simple draft, but it still makes absolutely no sense to me to
me in terms of relating to to an address allocation. If these token
values are in fact "non routable identifiers" , which is what I
read above, then you have no semantic intersection with the
conventional address space and you can set up a "non-routeable
identifier" register and allocate unique identifier tokens
according to any distribution criteria that makes sense according
to the intended use.
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.
The difference is that I try to be practical here, and pave way to
such fully fledged, non-routable identifiers, which in fact are much
larger than 128 bits, like Brian pointed out:
Another benefit of a separate registry for IDs is the removal of
the size
concern (mentioned as a reason for the request of a /3). As
completely
separate from addresses, these identifiers could be even larger than
128 bits. And this would increase their strength as cryptographic
entities.
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.
Doesn't that transition strategy make any sense to you? What is
wrong with it?
If you are worried that once established such hook for an identifier
space within the address space is likely to last for a long time,
please say so.
--Pekka
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
