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

>   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