> Personally, I'd eventually like to see something like a /8 > followed by an org id (like ULAs have). Since ULAs have 32 > bits for such an id, that's how I get /40 (or /48 if eventually > there were a /16 like ULAs use, followed by 32 bit org id). > This would solve some problems HIP doesn't solve today, > which were pointed out in the SHIM6 meeting in Dallas. > (e.g., PTR records for HITs aren't feasible today since > the reverse zone would be flat).
Many people think along those lines when thinking about HIP. But there are some architectural assumptions made before you head down that road. With different architectural assumptions, there would not necessarily be any need to solve the problem of looking up a HIT in some distributed database. For example, ssh host keys are used for identity purposes in the ssh protocol. But we have no way, given a bare ssh host key, of looking it up anywhere (except perhaps in the user's ~/.ssh/known_hosts file). So HITs could be used in similar ways, where referals are never done with HITs alone. So before trying to "solve some problems HIP doesn't solve today", we should think about the architectural possibilities. (E.g. see the FARA paper at http://www.isi.edu/newarch/ for one think-through.) 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. -Tim Shepard [EMAIL PROTECTED] _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
