Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? )

From: [email-masked] (Henderson, Thomas R)
Date: Mon Apr 4 09:42:01 2005

=20

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Monday, April 04, 2005 5:36 AM
> To: Henderson, Thomas R
> Cc: Tim Shepard; [email-masked]
> Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20
> SHA1 broken? )=20
>=20
> Tom,
>=20
> >>> That describes the essential bit of what I was trying to=20
> get at by=20
> >>> proposing we just have a byte with one or two assigned=20
> code points.
> >>> So if we say this:
> >>>
> >>>    If the prefix is 01000,
> >>>    then the next 3 bits are the HA.
> >>>
> >>>    If the prefix is something other than 01000, then the=20
> syntax and
> >>>    semantics of the following bits (however many there may be)
> >>>    are to be defined by future documents.
> >>>
> >>> that makes me happy.
> >>
> >> I'm happy with that, too.
> >
> > Can we make it 010, with five bits HA?
>=20
> Why that way?  Why not five bit prefix and three HA?  IMHO=20
> three bits for the hash algorithm should be enough at this=20
> point of time.  What is your rational for this different=20
> allocation of the bits? =20

The rationale is simply to be able to more simply enumerate those
prefixes that would collide with IPv6 address space.  With five bits, it
makes it longer to enumerate all of the possible collisions with that
space-- unless one allows wildcards.  For example, if I want to specify
a different HIT space that covers all of the global unicast IPv6
addresses, with five bit prefix, I must enumerate a lot of possible
prefixes.

Maybe this is a non-issue, if wild card bits are supported in future
prefix definitions.  I was not thinking of 3 vs. 5 from an IANA
allocation issue, nor do I think that 5 bits is needed for the hash
algorithm.=20

Tom