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

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
> use that will never include header fields in packets on the wire.
>
> >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.
>
> 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

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area