On 8 sep 2010, at 3:18, Brian E Carpenter wrote: > The flow label field is always unprotected (no IP header > checksum, not included in transport checksums, not included in > IPsec checksum). It cannot be verified and can be used as a > covert channel, so it will never pass a security analysis. Thus > some firewalls *will* decide to clear it, whatever the IETF > wants. This is inevitable, for exactly the same reason that the > diffserv code point is rewriteable at domain boundaries.
Two related remarks: There is currently no writeup of how to use the flow label for ECMP. And as far as I can tell there are no implementations of this either. Which is a real shame. There is work going on on creating "multipath TCP" where a TCP flow is split into subflows which take different paths. (See the MPTCP wg.) Currently, it is assumed that the paths are defined by the source/destination address pairs, but there are many paths that can't be selected this way. A different way to do this would be to have a path selector value in packets which the MPTCP (or other multipath transport) can use to tell routers to use different paths for different subflows. The flow label would be a very good choice for this, it would then bascially be a "subflow label". Considering the above, in my opinion: - we shouldn't lock down the flow label such that only one flow label per flow is allowed because this would impede future innovation - zero flow labels are still created by many systems, but these would hamper a flow label based ECMP. Rewriting zero flow labels into a real flow label somewhere in the network would therefore be a useful function - arbitrarily changing flow labels could break stuff like flow label based multipath and flow label based ECMP In other words: the flow label wouldn't be immutable, but non-zero values SHOULD NOT be rewritten. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------