Skip to content

Comments

Fix: Next-Hop MTU in ICMPv4 "Fragmentation Needed" Packets#12634

Open
pawannn wants to merge 1 commit intogoogle:masterfrom
pawannn:master
Open

Fix: Next-Hop MTU in ICMPv4 "Fragmentation Needed" Packets#12634
pawannn wants to merge 1 commit intogoogle:masterfrom
pawannn:master

Conversation

@pawannn
Copy link

@pawannn pawannn commented Feb 22, 2026

Fixes #12568

Problem

  • When gVisor sends an ICMPv4 “Fragmentation Needed” message (Type 3, Code 4), it was leaving the Next-Hop MTU field as 0.
  • According to RFC 1191, this field must contain the MTU of the next-hop link. Sending 0 is incorrect.

Impact

  • When a Linux host receives a Fragmentation Needed message with MTU set to 0, it falls back to an old default value from the RFC plateau table. In practice, this results in the system caching an MTU of 552 bytes.
  • That causes connections to containers behind gVisor to degrade significantly, especially for larger packets. It can also create long-lived MTU locks in the routing cache, which impacts performance to external services like GitHub.

Root cause

In the IPv4 forwarding path:

If a packet:

  • Has the Don’t Fragment bit set
  • Exceeds the outgoing link MTU
    gVisor correctly generates an ICMP Destination Unreachable with Code 4.

However, while constructing the ICMP header, it never sets the Next-Hop MTU field using icmpHdr.SetMTU(). As a result, the MTU remains 0.
The method to set it already exists. It just wasn’t being used.

What this change does

  1. Introduces a new ICMP reason type that carries the next-hop MTU value.
  2. Updates sendICMPv4 to:
    • Set the correct ICMP code for Fragmentation Needed.
    • Populate the MTU field with the actual link MTU.
    • Safely cap it to uint16 maximum.
  3. Updates the forwarding path to pass the correct MTU when generating the ICMP error.

Result

Now, when a packet is too large and cannot be forwarded:

  • gVisor correctly includes the actual next-hop MTU in the ICMP response.
  • Hosts update their Path MTU properly.
  • No fallback to 552 bytes.
  • No unnecessary performance degradation.

@google-cla
Copy link

google-cla bot commented Feb 22, 2026

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Next-hop MTU in ICMP "Fragmentation Needed" packets is set to 0

1 participant