Thread (6 messages) 6 messages, 3 authors, 2026-02-12

Re: (2) [net-next,v3] ipv6: shorten reassembly timeout under fragment memory pressure

From: Eric Dumazet <edumazet@google.com>
Date: 2026-02-12 07:17:09
Also in: netfilter-devel

On Thu, Feb 12, 2026 at 1:22 AM 배석진 [off-list ref] wrote:
quoted
On Wed, Feb 11, 2026 at 4:11 PM Fernando Fernandez Mancera
[off-list ref] wrote:
quoted
On 2/11/26 11:32 AM, 배석진 wrote:
quoted
  Changes in v3:
- Fix build bot error and warnings
- baseline update



 From c7940e3dd728fdc58c8199bc031bf3f8f1e8a20f Mon Sep 17 00:00:00 2001
From: Soukjin Bae <redacted>
Date: Wed, 11 Feb 2026 11:20:23 +0900
Subject: [PATCH] ipv6: shorten reassembly timeout under fragment memory
  pressure

Under heavy IPv6 fragmentation, incomplete fragment queues may persist
for the full reassembly timeout even when fragment memory is under
pressure.

This can lead to prolonged retention of fragment queues that are unlikely
to complete, causing newly arriving fragmented packets to be dropped due
to memory exhaustion.

Introduce an optional mechanism to shorten the IPv6 reassembly timeout
when fragment memory usage exceeds the low threshold. Different timeout
values are applied depending on the upper-layer protocol to balance
eviction speed and completion probability.

Signed-off-by: Soukjin Bae <redacted>
Hello,

isn't this what net.ipv6.ip6frag_time does? In addition, the situation
you described could be overcome by increasing the memory thresholds at
net.ipv6.ip6frag_low_thresh and net.ipv6.ip6frag_high_thresh.

Please, let me know if I am missing something.
Also :

1) net-next is closed.
Please read Documentation/process/maintainer-netdev.rst

2) We do not send 3 versions of a patch in the same day.
Please read Documentation/process/maintainer-netdev.rst

3) What about IPv4 ?

4) Only the first fragment contains the 'protocol of the whole
datagram', and fragments can be received in any order.

5) We do not add a MAINTAINER entry for such a patch, sorry.

Hello,


Regarding about net.ipv6.ip6frag_time and low/high_thresh:

The issue we are addressing currently occurs due to a large volume of mDNS
traffic from WiFi APs. As a temporary measure, we increased the high_thresh
value to accommodate the traffic.

However, UDP traffic such as mDNS cannot recover once a fragment stream is
lost, leading to wasted memory. Therefore, this patch is intended to make
more efficient use of the currently allocated fragment memory by shortening
the reassembly timeout under memory pressure.

Also, we tend to avoid changing the global value of ip6frag_time to
preserve existing behavior. This is why I added new config too.


Regarding others:

1, 2) net-next is closed and multiple patch
I apologize for the oversight regarding the net-next status and the frequent
submissions. I was tried to fix CI build failures. I will follow the
documented guidance going forward.

3) What about IPv4?
The issue was primarily observed in IPv6-dominant IMS environments, which
was the initial focus. However, I agree that the same memory management logic
is beneficial for IPv4. I will include IPv4 support in the next version to
provide a unified solution.

4) Only the first fragment contains the 'protocol of the whole datagram'.
You are correct. I will update the logic to store the L4 protocol information
once the first fragment is received, and only then apply the adjusted timeout.
If the first fragment is lost, the adjusted timer will not be triggered, but
this is acceptable as a partial case.
I do not think we will accept a patch trying to 'fix' reassembly. This
is fundamentally not fixable.

I can tell you that in crowded wifi environments, I have seen delays
of 30 seconds (and more) to complete
a datagram of only 2 fragments. Your default settings are not viable.

If you depend on receiving fragments, change the existing tunables.
Instead of :

/proc/sys/net/ipv6/ip6frag_high_thresh:4194304  (4 MB)
/proc/sys/net/ipv6/ip6frag_low_thresh:3145728 (3 MB)
/proc/sys/net/ipv6/ip6frag_time:60

Use:

/proc/sys/net/ipv6/ip6frag_high_thresh:104857600  (100 MB)
/proc/sys/net/ipv6/ip6frag_low_thresh:78643200 (75 MB)
/proc/sys/net/ipv6/ip6frag_time:60

Of course, avoiding fragments is the right solution.

https://datatracker.ietf.org/doc/html/rfc6762#section-17

TCP should avoid using frags by default.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help