On 08 May 2011, at 19:47 , Brian E Carpenter wrote: > But it's really playing with words to assert that a firewall which > chooses to overwrite the field is "supporting" it in the sense > intended by the phrase "Hosts or routers that do not support the > functions of the Flow Label field...".
It is not playing with words. Those security gateways normally are also routers, using the formal IPv6 definition of a router, often participate in routing protocols (e.g. eBGP in the case of multi-homed uplinks from an end-site; OSPF or RIP within an end -site) as routers, and often use the Flow Label value as input to their forwarding decisions. > The technical issue is that load balancing based on flow label values > won't work properly if middleboxes (or attackers) change the values > arbitrarily. As near as I can tell, everyone here agrees on the objective of enabling the Flow Label to be useful for load-balancing. As my note of a few moments ago suggested, there is a way to address both the operational security concerns and the load-balancing objectives. Rather than repeat myself, I'll just refer back to that note. > Thomas has argued that if the label MUST NOT be changed, we should > remove any suggestion of cases in which it's OK to change it. Followed > to its logical conclusion, that means it's not OK for a firewall to > change it. The crux of his concern seems to be that the current text tries to have things both ways, which ambiguity is long-standing, as I noted in my weekend email. I hope, perhaps overly optimistically, that the formula I proposed in my note of a few moments ago will find middle ground that most folks find acceptable. Cheers, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
