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