RE: [Int-area] Progress on draft-laganier-ipv6-khi-01.txt

> 
> In any case, we should not confuse (a) the allocation within the
> IPv6 address space for a place to pass handles across interfaces
> that today take (only) routable IPv6 addresses with (b) the
> structure of HITs (which may in fact be 256-bits long at some point)
> or other hash-based identities.  A completely local table could be
> kept within any one system to map from the first to the second.
> 

It is not only local handles where this matters; in fact, as you point
out, it may not matter much there at all.  However, think about using
HITs instead of IPv6 addresses in ACLs; here, referrals may not matter
so much but it would be nice if the HIT were 128 bits and relatively
immune to attacks on its one-wayness.  

I also agree with the points made by Dave (it would be nice to allow
room for experimenting with centrally managed HITs, previously known as
type 2 HITs) and Marcelo (we need to encode the hash algorithm
somewhere), so it seems to me that a compromise that might satisfy
everyone is to define an experimental /28 for ORCHIDs, use a bit to
denote type 1 (flat) or type 2 (structured), and three bits for encoding
the hash algorithm used.  This leaves 96 bits for the hash in the flat
HIT, while the type 2 could use more bits beyond the upper 32 for the
structured id.

Tom

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