At 01:24 AM 17/03/2006, Julien Laganier wrote:
[ Cross-posted to HIP WG and IPv6 WG. ]
[ Please reply _only_ to the INT area. ]
Folks,
draft-laganier-ipv6-khi-01.txt has been updated based on feedback
received from IETFers.
The HIP base specification currently has a hard dependency on this
draft and therefore it would be desirable to have it published as an
RFC as soon as possible, since the HIP base specification is now
quite mature. This draft intent is to make it possible for existing
applications running on a HIP node to use both HIP and IPv6 at the
same time, in the hope that it will foster the HIP experiment.
Your opinions on moving forward with this draft are more than
welcomed.
I provided the following comments to Jari as AD, and he suggested that I
forward the comments to the Internet Area mail list.
I have read this draft, and have the following comments:
1. I find the following text to be very unclear:
"...they are expected to be
routable at an overlay level. Consequently, while they are
considered as non-routable addresses from the IPv6 layer point of
view, all existing IPv6 applications are expected to be able to use
them in a manner compatible with current IPv6 addresses."
I _think_ what the authors are saying here is that in order to preserve the
syntax and some subset of the semantics at the application layer of
'conventional' IP address use, they want to preserve the some of the
characteristics of a 128 bit identifier. But perhaps this could be better
expressed in the document. "routeable at an overlay level" doesn't make a
huge amount of sense to me.
2. "globally unique in a statistical sense"
I _wish_ authors would not use such imprecise terms. It is essentially
meaningless in that "uniqueness" is an absolute term, rather than a
statement of statistical probability. Either they are unique or they are
not. In this case it would appear that they are not unique.
3. I find hard to follow:
"As these identifiers are expected to be used alongside with IPv6
addresses at both applications and APIs, co-ordination is desired to
make sure that an ORCHID is not inappropriately taken for a vanilla
IPv6 address and vice versa. In practice, allocation of a separate
prefix for ORCHIDs seems to suffice, making them compatible with IPv6
addresses at the upper layers while simultaneously making it trivial
to prevent their usage at the IP layer."
This seems unnecessary and inappropriate. It seems to add an element of
fuzziness and confusion to the entire case being made. You _can't_ have it
both ways and it seems to me that stealing unicast addresses at the
forwarding plane to use as an application layer identity realm without any
unicast semantics is not terribly sensible.
4. I'm not sure that I can agree with:
" A specific danger would be realised if the IETF community later decided
to use the ORCHID prefix for some different purpose. In that case,
hosts using the ORCHID prefix would be, for practical purposes,
unable to use the prefix for the other, new purpose. That would lead
to partial balkanisation of the Internet, similar to what has
happened as a result of historical hijackings of non-RFC1918 IPv4
addresses for private use."
This appears to be factually incorrect - if indeed these are truly
application level identifiers then the similarity to RFC1918 address use is
not a sustainable proposition.
5. General Comments
Identifier realms are generally expensive and hard to construct in useful
and meaningful ways. The temptation to steal from existing identifier
realms and reuse the tokens in another context is always present, and,
invariably dangerous and often ill-advised (one only needs to refer to RR
type proliferation in the DNS as an example of such overloading of identity
in ways that are often unhelpful). In reading this draft I remain
unconvinced that stealing bits from the forwarding plane identity realm (ip
unicast addresses) is a Good Idea.
The essential problem here remains the same problem in any form of compound
layered identity realm that disambiguates the "who" from the "where" and
"how": How to obtain from the "who" identity a useful mapping to a current
valid "where" and to do so in a robust and valid manner. The draft appears
to be curiously silent on this essential problem, and as such the draft
appears not to head anywhere productive in its present form in furthering
our understanding of the implications of this form of disambiguation of
identity. I suspect that the essential attributes of any decent solution in
this form of identity realm lie in structured rather than unstructured
opportunistic identity spaces - the structure aids in the mechanism of
unique solutions of a mapping question (what unicast forwarding address
should I map to when all I have at the moment this identifier value of the
remote party with whom I wish to communicate with?) i.e. "uniqueness" is a
tough, expensive and useful concept. You can dilute uniquess by heading
into unstructured opportunistic token realms but you lose determinism and
efficiency when attempting to manipulate such identities as a precursor to
communication. I don't think this draft proposes any novel way around this
aspect of identity realms.
I suspect that the architecture behind shim6 is about as cheap as you can
get in this area of attempting to pull arapt identity from location - don't
invent a new identity realm but use any initial "where" locator as a
surrogate host-to-host identity token and allow local context dynamic
mappings to hang off this initial association. If you want more robust and
persistent identity realms then you end up in another question - in the
long run any other identity realm starts to look so much like the DNS that
the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should
have published draft-iab-identities rather than letting it die (see section
4.5 in particular) as I suspect that much of what else could be said here
is already said there.)
Geoff
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
