Re: npf: nbuf_ensure_contig and large options

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

mlelstv%serpens.de@localhost (Michael van Elst) wrote:
> >> There probably aren't many reasons for an IPv6 packet to have an option
> >> located this far, but that's theoretically possible, and more
> >> importantly, correct specwise.
> 
> 
> >I do not see that as an NPF problem.  It expects the network stack to
> >support certain operations and, in this case, it is a limitation of the
> >mbuf interface and m_ensure_contig().
> 
> Please also see RFC 7112.
> 
> "As a result of the above-mentioned requirement, a packet's header
>  chain length cannot exceed the Path MTU associated with its
>  destination.  Hosts discover the Path MTU using procedures such as
>  those defined in [RFC1981] and [RFC4821].  Hosts that do not discover
>  the Path MTU MUST limit the IPv6 Header Chain length to 1280 bytes.
>  Limiting the IPv6 Header Chain length to 1280 bytes ensures that the
>  header chain length does not exceed the IPv6 minimum MTU [RFC2460]."
> 
> While that's not directly related to mbufs, I would guess that general
> support for jumbo packets in the stack would require us to provide
> larger mbufs that would again ensure that one mbuf can carry one
> packet and thus one complete header chain. Current ethernet and
> internet MTUs are not a real problem.

In theory -- yes.

We already support large mbufs and m_ensure_contig() could be changed
to re-allocate into an arbitrary sized.  However, why would you stuff a
kilobyte of IPv6 headers, let alone an entire 9K jumbo frame?  If you
know legitimate scenarios of such long header chains -- let us know.
At least right now I am not aware of any.  This might evolve and change
in the future and at that point we would have to be revisit.  However,
having bloated headers is not the direction anybody would like to see.
We are trying to make Internet faster, right? :)

-- 
Mindaugas