if_gif: Use the MTU on the gif interface for the outgoing packets
Needs ReviewPublic
Actions

Authored by hrs on Aug 11 2025, 11:14 PM.

Details

Reviewers

ivy
ae
zlei
meta

Group Reviewers

network

Summary

The gif(4) interface always used MTU of the outgoing interface based on
the routing entries when the outer protocol is IPv4, and IPV6_MINMTU
for IPv6. The latter was required so that packets would not be dropped
in the middle of the IPv6 tunnel endpoints, where path MTU discovery
does not work well.

However, this was confusing and IPV6_MINMTU caused performance penalty
even when the path MTU was obviuosly longer than the minimal value.
The pain point is that there is no way to configure the outer protocol
MTU when it is IPv6, while the MTU looks configurable via the gif interface.

This patch makes gif(4) to use the interface MTU as the outer protocol MTU,
instead of the outgoing interface. The default MTU is 1280, which is
the same as before and the safest value for IPv6. The system administrator
now change the MTU by just using the ifconfig(8) utility.

This reverts change in D51297. I do not think the word 'clamping' is
appropriate for this because the behavior in question just involves
forced fragmentation, not clamping the transfer unit, and is applied to
IPv6 only. A name that looks like a generic knob to adjust the segment
length is not intuitive to sysadmins, IMO.

When I wrote D45854, I received feedback indicating that simply
configuring IPV6_MINMTU as the default MTU on the gif(4) interface
and letting the transmit code path follow it was simpler. I agree
that sysadmins expect that the MTU on the gif(4) interface works
for both the input and output paths.

The reason why this was not implemented in the first place was that
if_bridge(4) does not allow uneven MTUs across the members,
and ip6_output() does not see the MTU value configured on
the gif(4) interface. Fixing this limitation is more consistent
than adding a new knob. I had planned to update the patch,
but I didn't have time to revisit it.

I also plan to add test for whether the fragmentation occurs as expected.
Before that, I would like feedback about this change.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 66178
Build 63061: arc lint + arc unit

Event Timeline

hrs created this revision.Aug 11 2025, 11:14 PM

Herald added subscribers: ivy, ziaee, glebius and 3 others. · View Herald TranscriptAug 11 2025, 11:14 PM

hrs requested review of this revision.Aug 11 2025, 11:14 PM

Harbormaster completed remote builds in B66178: Diff 160200.Aug 11 2025, 11:15 PM

hrs added reviewers: ivy, ae, zlei, meta, network.Aug 11 2025, 11:16 PM

hrs mentioned this in D45854: if_gif(4): Support the IFF_LINK0 flag to change the MTU handling for IPv6.Aug 12 2025, 12:55 AM

Quickly reviewed for typos in manpages. I will test the code changes later.

sbin/ifconfig/ifconfig.8
2956	This was changed to "the", as pointed out by pauamma. It might be a good idea to share the reason if you revert it to "a".
share/man/man4/gif.4
100	s/machanism/mechanism/
162	s/an/a/
165	the reason for?

The interface MTU is a hint to upper layers that, the max transfer unit it can handle directly to the nexthop.

For IPv4, the intermediate routers are capable to fragment when using tunnel interface's MTU. Meanwhile PMTU can also be taken into account so it will not bother too much.

For IPv6, it is a little complicated, as the intermediate routers are forbidden to fragment hence either IPV6_MINMTU is chosen or PMTU is a must to get best performance, which will result in discoverd path MTU between IPV6_MINMTU and interface's MTU.

Given IPv6 is now widely deployed, I think IPv6 PMTU now shall work great. So is it now the time to unconditionally turn IPv6 PMTU on for gif(4) ?

Please correct me if wrong.

So is it now the time to unconditionally turn IPv6 PMTU on for gif(4) ?

Another choice can be, use IPV6_MINMTU initially, and switch to the better path discovered MTU when available, so the tunnel will not be blocked on PMTU process. I have not test if that is possible, just a thought.

In D51866#1185261, @zlei wrote:

So is it now the time to unconditionally turn IPv6 PMTU on for gif(4) ?

Another choice can be, use IPV6_MINMTU initially, and switch to the better path discovered MTU when available, so the tunnel will not be blocked on PMTU process. I have not test if that is possible, just a thought.

The problem is that the inner protocol cannot detect PTB messages for the outer protocol in the current implementation. MTU for the outer protocol can be updated, but no handling is provided for the inner protocol. This is the reason why MTU for the inner protocol is set to the theoretically minimal value. It is possible to implement a PTB message handler for automatic adjustment, as you mentioned. Some routers have this feature.

Tested, it works fine for me both for IPIP and EtherIP. It is a much simpler and good approach. BTW, it conflicts with after D51835.

LGTM except for manpage points.

meta added a subscriber: kazubu_jtime.net.Aug 20 2025, 8:49 AM

@hrs I think the change to if_bridge(4) about gif(4) MTU part can be landed separated. That looks good to me.

Probably right now there's no sufficient time to ease the PMTU headache, I think use interface MTU should be a good tradeoff. Well I think it is better to have a commit tag Relnotes: YES , so users are warned this change and tweak before / after the upgrade.

Would it be possible to include this in 15.0-RELEASE? I worked on D51297 to ensure that the fix for bug 280736 would be included in the release, as there has been no progress on D45854 for over a year. Since this is a better approach for bug 280736, it should be included as well.

I don’t think it’s a good idea to add the noclamp flag in 15.0 and remove it and replace it with this approach in 15.1. I’d like to avoid having to wait another year.

In D51866#1196328, @meta wrote:

Would it be possible to include this in 15.0-RELEASE? I worked on D51297 to ensure that the fix for bug 280736 would be included in the release, as there has been no progress on D45854 for over a year. Since this is a better approach for bug 280736, it should be included as well.

I don’t think it’s a good idea to add the noclamp flag in 15.0 and remove it and replace it with this approach in 15.1. I’d like to avoid having to wait another year.

Agreed. I'm hacking the testcase for EtherIP with large MTU. Hopefully I can finish it in days.

Will it happen soon? I don't believe hrs can spend much time on this. We need to work on this instead. I'll try to resolve conflicts and submit another review.

As I mentioned above, I don't want to wait another year to get this landed.

meta mentioned this in D52594: if_gif: Use the MTU on the gif interface for the outgoing packets.Wed, Sep 17, 3:46 PM

meta added a comment.Mon, Sep 29, 8:58 AM

This comment was removed by meta.