Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

[Tom Herbert <[e-mail]>]

On Mon, Jul 13, 2020 at 11:34 AM Fernando Gont <[e-mail]> wrote:
>
> On 13/7/20 15:11, Tom Herbert wrote:
> > On Mon, Jul 13, 2020 at 11:01 AM Fernando Gont <[e-mail]> wrote:
> >>
> >> On 10/7/20 15:32, Toerless Eckert wrote:
> >>> IMHO: See my email earlier in the thread about punting stuff to slow-path, especially when/before
> >>> you figure out that you should have just ignored something at linerarte.
> >>>
> >>> Aka: not sufficiently prescriptive RFCs + bad implementations == extension header based features killed in deployments.
> >>
> >> Indeed. And add to that that the EH structure itself seems to be rather
> >> unfriendly with some popular hardware architectures. (unless with "not
> >> sufficiently prescriptive RFCs" you are meaning to set the maximum
> >> EH-header chain length to some sane value that folks might agree to
> >> comply with).
> >>
> >
> > RFC8504 implicitly does that for number of Hop-by-Hop or Destination
> > options in a packet:
> >
> > "A host MAY impose a limit on the maximum number of non-padding
> > options allowed in the destination options and hop-by-hop extension
> > headers.  If this feature is supported, the maximum number SHOULD be
> > configurable, and the default value SHOULD be set to 8."
> >
> > The default value of eight was derived from the number of already
> > defined options, extrapolation of new options that might be defined
> > and deployed, and discussions with some HW vendors that they can
> > efficiently process a small number of TLVs (as opposed to hundreds in
> > a packet that are possible without a limit).
>
> Kudos to RFC8504 and authors for that- That said, given that options may
> have a rather unlimited length, is that enough? It would seem to me that
> the most important thing is that E-H header length, as opposed to the
> length of individual options, or ther number of options...
>

Fernando,

draft-ietf-6man-icmp-limits-08 defines the ICMP errors for limits of
number of options, length of extension headers, length of extension
header chain, etc. However, I don't believe any default limits are
suggested other than the RFC8504 limits.

Wrt byte length, the most interesting limit with regards to routers is
when the aggregate length of the header chain exceeds the size of the
parsing buffer in the device. As I understand it common lengths of
parsing buffers are 128, 256, or 512 bytes. That might suggest the
default minimum should be 128 bytes or maybe 256 bytes. That is, we
would expect that routers should be able to process IP header,
extension headers, and first four bytes of transport header (e.g. to
get ports for ECMP) fit in the parsing buffer in the first N bytes of
the packet. We can narrow this down if the standard is followed such
that routers only process the IPv6 and HBH headers, intermediate
destinations in a routing header only process headers through the
routing header, and end hosts process all options.

Tom


> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>