Hi, Shane, Please find my comments inline....
> 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. Why? > Why couldn't (or, shouldn't) the hash function instead use the > following: Flow Label = counter + F(Source Port, Destination Port, > [Protocol], Secret Key) Because the specs require the Flow Label to be unique on a per (src addr, dst addr) basis. -- hence the flow-selection function needs to take into account the v6 addresses rather than the src/dst ports. > 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. This is actually the intent of the proposed flow-label selection algorithm in draft-gont-6man-flowlabel-security-00 Please let me know if the above has clarified your concern... Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
