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

[copybara-service]

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

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.

FUTURE_COPYBARA_INTEGRATE_REVIEW=#12634 from pawannn:master 2067f61