Hi Thomas, On 2011-01-11 11:31, Thomas Narten wrote: > Brian E Carpenter <[email protected]> writes: > >> I'm not sure there's a problem here. The draft has the >> pseudo-random label as a SHOULD and Fernando's crypto >> algorithm as OPTIONAL. The problem with the RFC 3697 >> text is that it apparently encouraged lots of people >> to design complex schemes for encoding semantics in the >> flow label. > > I don't follow that last sentence. Can you expand?
See draft-hu-flow-label-cases, section 3, for several examples. > >> Given that we expect people to put flow labels into a >> hash function of some kind, a 20-bit pseudo random number >> seems like a better default than 1,2,3,... (depending on >> the hash function, obviously). > > I want to challenge that up front. > > For the example in your draft, MODULO(n), incrementing by one has > wonderful properties. Given that incrementing by 1 is about as simple > as it gets, that seems like a fine thing to do. Yes, certainly, if the modulo is applied directly to the value. But in practice it seems more likely that the value will be hashed up with the traditional 5 tuple, and in that case having 20 variable bits will do more to produce an even distribution of values than if the sources only vary the low-order bits. (Assuming that most sources are only generating a modest number of flows. If a source is generating a few million flows an hour, this argument doesn't apply.) > There may be security downsides by having such a predicable generator > at the source, but that is a different issue than making it hash well. Yes. Should we be using that argument more strongly in the draft? > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
