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

["Henderson, Thomas R" <[e-mail]>]

I have a few comments in response to Geoff's and this draft in general.

> -----Original Message-----
> From: Geoff Huston [mailto:[e-mail]] 
> Sent: Tuesday, April 18, 2006 9:13 PM
> To: Julien Laganier; Internet Area
> Cc: HIP
> Subject: Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt
> 
> 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.


"  To make
   them more like vanilla IPv6 addresses, they are expected to be
   routable at an overlay level."

I think that this sentence has some problems and leads to confusion.  

Suggest "Systems using ORCHIDs must map them to routable addresses;
the details of such mapping are outside of the scope of this document."


> 
> 
> 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.

I think that "statistically unique" is commonly used in cryptography and
is well understood.  Whether it is precise enough or not-- if one cares
to determine the precision, one can calculate the probabilities
involved.  I don't know of a better term for what is described.

> 
> 
> 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.

I think we can have it both ways, and we need to consider ways like this
if we ever want to experiment with different architectures.  It is
sensible in that it allows applications to run on legacy APIs but use
the modified stack.  

> 
> 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.

I don't think the sky-is-falling tone of the quoted text is accurate,
and would be fine if it were removed entirely.

> 
> 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.

I think that the draft somewhat concedes this point (see paragraph 5 of
1.1).  However, the drawbacks are possibly more than offset by the
benefit of supporting legacy applications during a transition period.

> 
> 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.

IMO, the above issue (whether identities should be unstructured) is
outside the scope of the ORCHID draft.   HIP is using largely
unstructured identities and needs a specification of how to construct
the few bits of structure that the identities have.

> 
> 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.)

I am not disagreeing with your perspective; shim6 may be as far as one
wants to take this id/locator split architecture, and the jury is still
out.  But I think it is worthwhile considering whether there is benefit
to going further, and I'm happy that the IETF and IRTF are experimenting
with HIP for that.

> 
> 
>     Geoff


There are a few things contained in this draft:
i) specification of how ORCHIDs are constructed
ii) discussion about how ORCHIDs might be used
iii) request for IANA allocation for Context ID
iv) request for IANA allocation of an IPv6 prefix for ORCHIDs

I would like to recommend that regardless of the outcome of this
discussion that we end up on the path to an RFC that handles "i)",
because this is the piece needed for the HIP RFCs.  I don't so much care
about "ii)" since it can be handled (perhaps better) elsewhere.  "iii)"
seems non-controversial.

Regarding iv), to me, this hinges on whether IANA wants to coordinate
the 128-bit quantities used in the AF_INET6 sin6_addr field at the API
by recognizing that some experimental systems expand the semantics of
that field and use higher-order bits to distinguish between currently
used IPv6 addresses and other quantities.  The allocation seems to me to
be a good idea to more formally recognize this, but not a requirement
for these experiments to continue.

Tom

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area