Geoff,
My understanding is that these are not routable addresses.
you are right: not only they are not routable but they should be
easy to be recognized as not routable.
To clarify: if we decide to define this prefix, it will mean that the
particular prefix will be generally unavailable for routing, as there
will be hosts that will use the prefix at the API level.
Consequently, if you want to talk to those hosts, you cannot use the
prefix in the network.
Hence, even though the prefix is not assumed to appear in the wire,
defining this does effect on what bits can(not) be used in the wire.
But _nothing_ in what you have posted so far justifies and _address
allocation_
From HIP's perspective _they are just numbers_ as they are
identities, not locators.
We have tried to address this in the draft. Succinctly:
If we want legacy IPv6 applications to work without changes with
protocols that use non-routable identifiers as upper layer
identifiers, it would be desirable to have identifiers that
a) are syntactically similar to current IPv6 addresses, but
b) are understood to be semantically different.
The draft attempts to address that by allocating a separate prefix
for such identifiers, and at the same time also provide a secure
means for associating any identifier in the given identifier space
with other properties, in a fashion similar to HBA/CGA.
Looking at these identifiers from a HBA/CGA point of view, what we
propose are similar to HBAs/CGAs with two differences:
- the hash length is much longer and therefore more secure (about 120
bits vs. about 56 bits)
- they are non-routable
If you feel that argumentation like the above should be in the
document, I can expand the above and we can add it as an appendix to
the draft.
(The IAB had a draft for a while about identities, and then the IAB
decided to drop it on the floor. Seems like it could sure come in
useful here in terms of outlining to some IAB folk the difference
between locators and identifiers!)
I agree a document explaining the various types of identifiers would
be useful. OTOH, my own IETF-related work queue is currently more-or-
less full till March or so.
--Pekka
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
