Brian E Carpenter <[email protected]> writes: > Chris,
> On 2011-11-14 16:06, Christopher Morrow wrote: > > Just a question about this idea in general, if one of the reasons to > > do it is to save middleboxes from doing 'lots of work' ... wouldn't a > > smart attacker just not put this header in? and then choke the > > middleboxes? Actually, I think the argument is not that middleboxes will do less work if this option is present, it's that they won't do the work at all in the case where the option is *not* present. I.e., they won't parse all the extension headers to get to the TCP Port numbers in order to do (say) ECMP. If they could parse them, i.e., they have the code and can do so, then they don't need the option in the first place. I thought the premise for this work was middleboxes that couldn't be bothered with parsing extension headers properly. Thus, if a source includes this option, perhaps it will get slightly better performance because ECMP works better on one of the paths. If the option is missing, ECMP won't work as well. IMO, no source will bother to implement the option based on this cost/benefit. > I could use that argument against *any* optimisation, couldn't I? > DoS is hard to defeat. I think this is backwards. You have previously made the case that middle boxes can't/won't parse extension headers. So they won't be doing the extra work if the option is not present. Right? So this isn't an optimization. This is to get around middleboxes that are unwilling/unable to implement the specs as specified. > > > > what's the incentive for a source to add this header? (it's not in > > their interest to make things 'easier' is it?) > Well, you can argue that it's a small price to get a small improvement > in response time from busy servers, but I agree, this would be a matter > of persuading stack vendors to do it because it's good to do it. Sorry, what has this got to do with "busy servers"? this option is only for middle boxes. Servers will ignore it. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
