Thomas, All, On Jan 10, 2011, at 15:31 MST, Thomas Narten wrote: > Brian E Carpenter <brian.e.carpen...@gmail.com> writes: >> 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.
Let's take a step back here for a moment and recognize a few things: 1) Routers, (specifically, 1st-hop routers that would be replacing a zero flow-label with something non-zero), already implement a pseudorandom hash algorithm today (sometimes in HW), in order that they can determine an outgoing component-link for packets sent out/across LAG's and ECMP paths. So, this draft is simply proposing to re-use an existing pseudorandom function already built-in to routers and simply encode that result into a flow-label. 2) For your proposal, above, of incrementing the flow-label by one to be successful, the device encoding the flow-label would have to track state of all flows in order to ensure that all packets belonging to the same flow got the same flow-label. While this might be true, and easy, for hosts or stateful firewalls, this would absolutely not work for 1st-hop routers that are allowed to set a flow-label if they observe an incoming packet whose flow-label wasn't set by the host, (IOW, flow-label == 0). So, I'm seeing a technical problem with your proposal (#2) and huge advantages for re-use of pseudorandom algorithms already implemented within devices in the network that are potentially responsible for writing a flow-label with as little state as possible, (#1). -shane > 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------