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