Hi Fernando, I have a question on: http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing that a flow-label be constructed using the IPv6 Source & Destination values as input-keys to a hash function as follows: Flow Label = counter + F(Source Address, Destination Address, Secret Key) If you do the above, then intermediate routers that are performing LAG and/or ECMP load-balancing will not be able to use the flow-label as an input-key for calculating a load-balancing hash. Instead, intermediate routers will have to fetch a 5-tuple of {Source IP, Destination IP, Protocol, Source Port, Destination Port} from the IPv6 header to calculate a load-balancing hash (and, at the same time, completely ignore the flow-label as an input-key for its flow-based load-balancing hash, since it's redundant). Why couldn't (or, shouldn't) the hash function instead use the following: Flow Label = counter + F(Source Port, Destination Port, [Protocol], Secret Key) If you did this, then intermediate routers & switches that were performing LAG and/or ECMP load-balancing could easily use the following /fixed-offset/ header fields as input-keys to the load-balancing hash: Load Balancing Hash = F(Source IPv6 Address, Destination IPv6 Address, "draft-gont" Flow Label) IMHO, this would allow draft-gont-6man-flowlabel-security to nicely/peacefully co-exist with widely deployed/used flow-based load-balancing schemes for LAG and ECMP. Thanks, -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------