MTU/MSS Calculator

Three modes keep the layers apart. Path MTU mode takes an L3 path MTU that is already effective and removes only the fixed inner IP header (20 for IPv4, 40 for IPv6) and the fixed 20-byte TCP header, which is exactly how RFC 9293 section 3.7.1 defines the value sent in the MSS Option (MMS_R - 20): 1500 gives 1460 for IPv4 and 1440 for IPv6. TCP options such as Timestamps and SACK, and IPv4 options or IPv6 extension headers, are never subtracted from that advertised value; they shrink the payload of each segment the sender emits, reported separately as the maximum TCP payload per segment. That payload figure is the ceiling this MTU allows and is deliberately not labelled Eff.snd.MSS: RFC 9293 defines Eff.snd.MSS as min(SendMSS + 20, MMS_S) - TCPhdrsize - IPoptionsize, so it also depends on the MSS the peer advertised, which this tool does not ask for. A peer advertising a smaller MSS lowers the real per-segment payload further. An IPv6 path MTU below 1280 is rejected rather than calculated, because RFC 8200 section 5 requires every IPv6 link to carry 1280 octets and RFC 8201 forbids a node from holding a Path MTU estimate below it. Planning mode starts from the underlay link MTU instead: PPPoE is link adaptation that lowers the L3 MTU to 1492 (RFC 2516; RFC 4638 is needed above that), the tunnel overhead is sized from the outer/underlay IP family, and the inner IP family is chosen independently for the TCP packet. 802.1Q and 802.1ad tags are L2 header bytes: they enlarge the Ethernet frame to 1522 or 1526 but do not reduce the L3 MTU, so they are reported as framing rather than subtracted. IPsec ESP is sized per cipher profile, because RFC 4303 section 2.4 has two padding rules and they differ by transform: AES-CBC pads to its 16-byte block, AES-GCM only to the 4-byte boundary that keeps the ICV aligned. WireGuard rounds the inner MTU down to a multiple of 16 because the inner packet is padded before encryption. Rounding down leaves part of the underlay MTU unusable, and that is reported as unused headroom rather than padding: a maximum-size inner packet needs no padding, so the MTU reduction from underlay to inner is larger than the bytes the encapsulation actually puts on the wire. Planning mode reports both, plus the resulting outer packet size. A plan whose IPv6 underlay or IPv6 inner MTU would fall below 1280 is rejected: such a link needs link-specific fragmentation below IPv6, which is a property of the tunnel rather than a smaller MSS. Reverse mode adds only the fixed headers back, shows that arithmetic, then holds the requirement at the minimum link MTU the IP version demands before rebuilding the underlay and link requirement: a target MSS of 536 on IPv6 still needs a 1280-byte link. That larger MTU raises the ceiling the MSS Option may use to 1220, but it does not change what you advertise - RFC 9293 only requires the MSS Option to be at most MMS_R - 20, so 536 remains a valid value to send. The target and that ceiling are reported as separate rows. Limitations: ESP transport mode, GRE optional key/sequence fields and per-layer outer families in stacked tunnels are not modelled; use the extra overhead field for those.