MSS vs MTU

The Difference in One Table

MSS Derivation Math for IPv4

On a standard Ethernet path the link MTU is 1500 bytes. An IPv4 header without options is 20 bytes. A TCP header without options is 20 bytes. Subtract both from the MTU and you get the maximum TCP payload that fits in one packet without fragmentation:

1500 − 20 (IPv4 header) − 20 (TCP header) = 1460 bytes MSS

This is why 1460 is the most common MSS value seen on IPv4 Ethernet networks. It is not a fixed constant — it is the result of these specific conditions. Change any of the inputs and MSS changes too.

IPv6 Headers Are 40 Bytes

IPv6 has a fixed base header of 40 bytes — twice the size of the minimal IPv4 header. With a TCP header of 20 bytes, the MSS on a standard 1500 MTU IPv6 path is:

1500 − 40 (IPv6 header) − 20 (TCP header) = 1440 bytes MSS

This means IPv6 TCP sessions carry 20 fewer bytes of application data per packet than equivalent IPv4 sessions on the same link MTU. On high-throughput paths this is negligible, but it is a real difference that shows up in protocol analysis.

TCP Options Reduce MSS Further

The TCP header can grow beyond 20 bytes when options are present. The most common is the timestamps option (RFC 7323), which adds 10 bytes of option data plus 2 bytes of padding — 12 bytes total. With timestamps enabled, the effective TCP header becomes 32 bytes, and MSS on an IPv4 Ethernet path drops to:

1500 − 20 (IPv4) − 32 (TCP with timestamps) = 1448 bytes MSS

Other options such as SACK (Selective Acknowledgment) also consume TCP header space when present in a segment. The MSS option itself is only carried in SYN packets and does not consume space in data segments.

MSS in the TCP Handshake

MSS is negotiated during the TCP three-way handshake. The SYN packet from the initiating host carries an MSS option advertising the largest segment it can receive. The SYN-ACK from the responding host carries its own MSS advertisement. Once the handshake completes, each side uses the other's advertised MSS as the limit for segments it sends. Neither side should send a data segment larger than the other side's advertised MSS. This is an advisory mechanism — each side is responsible for honoring the peer's advertisement.

MSS Clamping by Routers

MSS clamping is a technique where a router or firewall rewrites the MSS option in SYN packets as they pass through, reducing it to a value that will fit through a lower-MTU segment of the path. This is commonly deployed on PPPoE links, VPN gateways, and tunnel endpoints where the effective MTU is lower than 1500.

For example, PPPoE adds an 8-byte header, reducing the effective IP MTU to 1492. Without MSS clamping, endpoints would negotiate MSS 1460, resulting in 1500-byte IP packets that exceed the 1492 PPPoE MTU. Path MTU Discovery (PMTUD) is supposed to detect this and instruct senders to use smaller packets, but it relies on ICMP "fragmentation needed" messages that are often blocked by firewalls. MSS clamping is a practical workaround that fixes the problem at the TCP handshake before PMTUD is even needed.

PMTUD vs MSS Clamping: Trade-offs

Path MTU Discovery (PMTUD, RFC 1191 for IPv4, RFC 1981 for IPv6) is the standards-based solution: the sender sets the DF (Don't Fragment) bit on packets and relies on routers to send ICMP "packet too big" messages when a packet exceeds an intermediate link's MTU. The sender then reduces its segment size for that destination. The problem is that many firewalls block ICMP, preventing these messages from reaching the sender and creating an MTU black hole where large packets are silently dropped. MSS clamping sidesteps this entirely by setting a safe MSS at the TCP layer before oversized packets are even sent. For network operators, deploying MSS clamping on VPN and PPPoE gateways is generally more reliable than depending on correct ICMP behavior across the entire path.

MSS for UDP: No Negotiation

MSS is a TCP-only concept. UDP has no connection setup, no options field, and no mechanism to advertise a maximum payload size. UDP applications are responsible for keeping their own datagrams small enough to avoid IP fragmentation, or for handling the consequences of fragmentation themselves. DNS over UDP defaults to 512 bytes historically, and EDNS0 allows up to 4096 bytes, but many resolvers cap at 1232 bytes or smaller to avoid fragmentation issues. VoIP, video, and game applications similarly need to be aware of link MTU and either fragment at the application layer or keep datagrams conservatively sized. This is why MSS clamping fixes TCP issues but leaves UDP-based protocols potentially still broken on low-MTU paths.

Practical Troubleshooting Clues

• Websites partly load (small resources succeed, large page bodies stall) — classic MTU black hole.
• VPN connects successfully but some applications time out or behave inconsistently through it.
• SSH connects but the shell hangs after the banner — large SSH packets are being dropped.
• Lowering the tunnel MTU or enabling MSS clamping on the VPN gateway resolves the problem.
• Packet captures show large segments being retransmitted repeatedly without progress.
• Ping with ping -M do -s 1452 <destination> fails but smaller sizes succeed — confirming an MTU black hole.

Frequently Asked Questions

What does MSS stand for?

MSS stands for Maximum Segment Size. It is the largest TCP payload a host says it can receive in one TCP segment.

Why is MSS usually 1460 with 1500 MTU?

With IPv4 and TCP without options, the IP header is 20 bytes and the TCP header is 20 bytes. 1500 − 40 leaves 1460 bytes of TCP payload.

What is MSS clamping?

MSS clamping is when a router or firewall lowers the advertised TCP MSS in SYN packets so endpoints send smaller segments that fit through a lower-MTU path such as PPPoE or a VPN tunnel.