On Fri, Aug 12, 2016 at 10:59 AM, Joe Touch <[email protected]> wrote: > > > On 8/12/2016 10:54 AM, Tom Herbert wrote: >> On Fri, Aug 12, 2016 at 10:21 AM, Joe Touch <[email protected]> wrote: >>> >>> On 8/11/2016 4:59 PM, Jesse Gross wrote: >>> >>> The most common example given in this area is the use of IP options. At the >>> time that routing was moving to hardware implementations, options were not >>> widely used and so were not implemented. However, imagine that options were >>> in common use – do you think that router vendors would have decided that IP >>> was too difficult to implement and abandoned that market? Or would we now be >>> accepting that this is a common element of protocols? >>> >>> >>> A good example from history here are TCP options. In the beginning, they >>> were considered only a complexity overhead. >>> >>> Another example is IPsec. >>> >>> Both, are examples of TLV options (TCP within the TCP header; IPsec as a >>> 'next layer' protocol). >>> >>> Both are widely supported in hardware. >>> >>> That's not to suggest that we should focus on TLV solutions, but it goes to >>> prove that even TLV-format options do not prevent widespread hardware >>> support. >>> >> Joe, >> >> I don't know sure that parsing of TCP options is really all that >> widespread, > In hardware at the endsystems, it is. > >> but I do know that the inability of middleboxes to >> properly implement support for both IP options and IPv6 extension >> headers have pretty much made those non-starters for widespread >> deployment. > > IPsec is a counterexample. > > For many years, the network device community pushed back on options > because it undercuts their profit model (build for the 80% case and toss > the rest to software slow-path). > > The tide there is turning; even the OPS groups are starting to admit > that we can't simply deprecate IP options, but we can do things to > encourage their more widespread support (e.g., limit the chain, etc.). > I hope you're right and extension headers do become deployable someday...
> Middleboxes ignore or misimplement options by design; they''re never > useful as a constraint for protocol design. Wouldn't placing a limit on the header length chain as you alluded to above be an example of such a constraint on protocol design? Tom > > Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
