Lets understand why we are having this discussion at all. While the draft
indicates that these 'tokens' will never be used in ip-level unicast
forwarding, there is a desire to use a token space drawn from the IP global
unicast address space. If we ignore this for a second then yes, its quite
reasonable to move on with a 128 bit orchid, and be done.
The point of compromise lies in the desire to use of the IPv6 global
unicast address space. At this point a whole set of other considerations of
address use come into play, best summarized by looking at the material at
http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf
A related commentary can be found at
http://www.potaroo.net/ispcol/2005-07/ipv6size.html
So the question arises - what ipv6 global unicast prefix makes sense in
terms of a compromise between maximising prefix length and not making
'undue' demands on the pool of IPv6 global unicast addresses.
Geoff
At 01:36 AM 5/06/2006, marcelo bagnulo braun wrote:
El 04/06/2006, a las 18:02, Pekka Nikander escribió:
In my personal opinion, having ORCHIDs that are considered secure now
and could be estimated to be secure for the next 20 years or so might
be about the right size.
but in that case, you need to make ORCHIDs to support multiple hash
functions, since i guess it is not that clear that we will stick to
sha-1 for the next 20 years right?
ORCHIDs do support multiple hash functions, through different
prefixes. What comes to SHA-1, it is not clear whether it would last for
20 years for the ORCHID purpose or not, but the same applies pretty much
to any other hash function.
agree
but this point imho affects the length of the prefix.
I mean one thing is to assign a single /8 prefix to all orchids and a
different thing is to assign a separate /8 per hash function and that if
we need to move from a given hash function we need to forget the used
prefix and get a new one.
I mean, after all, it is a matter of bits. We need to encode different
hash functions in ORCHIDs. The question is whether we encode them in the
prefix or in the suffix part. My point is that this needs also to be taken
into account when deciding what would be the prefix length. If we use a
very short prefix for this version of ORCHIDs and in the future we need to
change the hash function, then we will need another very short prefix to
support the ORCHIDs for the new hash function.
I think that the amount of address space required for the orchids would be
clearer if the hash function was encoded in the suffix rather than in the
prefix.
one /8 versus one /8 per hash fucntion used may be an important difference
(depending on how well the attaks on hash functions evolve)
Regards, marcelo
--Pekka
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
