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? > 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. 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. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
