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

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Apr 2006 14:12:36 +1000

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 19 Apr 2006 08:53:44 -0700

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

> -----Original Message-----
> From: Geoff Huston [mailto:[email-masked]] 
> 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
> 

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

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

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

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

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

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

> 4.5 in particular) as I suspect that much of what else could 

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

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Apr 2006 04:47:16 +1000

>   But I think it is worthwhile considering whether there is benefit

I too believe that this is a valuable experiment - the bit I find difficult 
to understand
is why this draft proposes to use a considerable chunk of unicast address 
space for a
use that will never include header fields in packets on the wire.

>for these experiments to continue.

This is an excellent  summation - thanks!

Indeed we agree that whether or not the IETF comes to some consensus that (iv)
is a Good Idea, these HIP experiments can continue. I just don't understand
why these upper level ORCHIDs must be drawn from the same unicast token
space as forwarding identifiers that are used in packets on the wire.

regards,

    Geoff

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Apr 2006 20:05:31 +0200

Hi Geoff,

Thanks for your thorough review of our document, this is helpful. 

Replying to your comment in which you said you "just don't understand 
why these upper level ORCHIDs must be drawn from the same unicast 
token space as forwarding identifiers that are used in packets on the 
wire."

As Tom noted, doing so would allow to "coordinate 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."

I agree with Tom that such an allocation is not a requirement per se. 
However, doing so would allow to use on a single system most of the 
*unmodified* IPv6 applications, both with HIP and without HIP. 

I think it is especially valuable for the HIP experiment because it 
would lower the barrier to participate in the experiment. Possibly 
anyone could participate in the experiment on a day-to-day basis 
while using a single IPv6 system (There's HIP implementations for 
BSD, Linux, MacOS X and Windows). People would not be required to 
set-up and use a specialized system which can only talk to 
HIP-enabled nodes. IMHO doing so would foster the HIP experiment by 
widening the potential participant base.

Regards,

--julien

On Wednesday 19 April 2006 20:47, Geoff Huston wrote:
> >   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.
>
> I too believe that this is a valuable experiment - the bit I find
> difficult to understand
> is why this draft proposes to use a considerable chunk of unicast
> address space for a
> >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.
>
> Indeed we agree that whether or not the IETF comes to some
> consensus that (iv) is a Good Idea, these HIP experiments can
> continue. I just don't understand why these upper level ORCHIDs
> must be drawn from the same unicast token space as forwarding
> identifiers that are used in packets on the wire.
>
> regards,
>
>     Geoff