Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt

[Geoff Huston <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area