lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 11 Jan 2019 19:10:39 +0100
From:   Michal Kubecek <>
To:     netdev <>
Cc:     Peter Oskolkov <>,
        Timothy Winters <>,
        Eric Dumazet <>,
        Eric Dumazet <>,
        Florian Westphal <>,
        Tom Herbert <>,
        David Miller <>
Subject: Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu

On Friday, 11 January 2019 18:09 Peter Oskolkov wrote:
> On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <> wrote:
> > Thanks for the clarification.   I'm thinking about creating a draft
> > to say no fragments less then 640 unless it's the last fragment.  
> > Does that work for your code going forward?
> I will prepare a patchset to convert IPv6 defrag queue to rbtree+list,
> similarly to how IPv4 defrag queue currently works. Just in case it
> is decided to go this route. I don't think having an
> arbitrary/non-standard size cap (640) is a good approach.

It's not completely arbitrary. The idea is that two most obvious
fragment sizing strategies are

  (a) use maximum possible size for all except last, then the rest
  (b) calculate minimum required fragment count and use (almost) the
      same size for all of them

Both strategies create non-last fragments of size at least 1280 / 2.
But I agree that using the same data structure and algorithm as for
IPv4 is more future proof.

Michal Kubecek

Powered by blists - more mailing lists