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

> 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
			 shep@alum.mit.edu

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