NetKit

Protocol Header Overhead & MTU

From vendor documentation

Header sizes for every common encapsulation, plus a stack builder that turns Ethernet, VLAN, PPPoE, MPLS, GRE, IPsec, VXLAN, Geneve and SRv6 into a total, an effective MTU and the TCP MSS for IPv4 and IPv6.

Stack builder

Toggle the layers this path really carries, outermost first.

1500 for standard Ethernet, 9000 for a jumbo-frame path, 1492 for a PPPoE WAN.

ESP padding depends on the payload. Leave it empty to charge only the payload-independent bytes.

L2 framing

4 B each. Two tags is 802.1ad QinQ.

L3 and MPLS
IP version

0–40, padded up to a multiple of 4. Costs exactly as much MSS.

4 B per label.

Tunnelling
Overlay

Result

Underlay MTU 1500 − 50 bytes of encapsulation = 1450 effective MTU; TCP MSS 1410 (IPv4) / 1390 (IPv6)

Encapsulation total
50 B
Effective MTU
1450 B
Layers
4
TCP MSS (IPv4)
1410
TCP MSS (IPv6)
1390
Fragmentation
Fits

Above the protocol floor

How this was computed

  • TCP MSS is the payload that fits after a 20-byte IP header and a 20-byte TCP header with no options: 1450 − 40 = 1410 for IPv4 and 1450 − 60 = 1390 for IPv6. Every 4 bytes of TCP options (timestamps, SACK) reduces it by 4.
  • The Ethernet layer is charged like any other: with it in the stack, read the underlay MTU as the frame budget (1500 for the IP MTU, 1518 with FCS). For a plain Ethernet/IP/TCP path the 1500-byte figure is already the IP MTU, so leave the Ethernet layer out.
  • This is the canonical VXLAN-over-IPv4 figure: 50 bytes = 14 Ethernet + 20 IPv4 + 8 UDP + 8 VXLAN (RFC 7348 §5). A tenant with a 1500-byte MTU therefore needs a 1550-byte underlay, which is why jumbo frames or a lower tenant MTU are the two real options.

Breakdown

One row per layer, with the arithmetic spelled out

50 bytes total
LayerBytesArithmeticConfidenceReference
Ethernet II1414 B header (6 B destination MAC + 6 B source MAC + 2 B EtherType) (FCS not charged) = 14 B. The 8 B preamble/SFD and the 12 B inter-frame gap are physical-layer and are not part of the MTU.verifiedIEEE 802.3
IPv4 header2020 B fixed (version/IHL, DSCP/ECN, total length, id, flags/fragment offset, TTL, protocol, header checksum, source, destination) = 20 B.verifiedRFC 791
UDP88 B: source port, destination port, length, checksum.verifiedRFC 768
VXLAN88 B VXLAN header (flags, 24-bit VNI, reserved). Canonical total over IPv4 with no outer tag: 14 B Ethernet + 20 B IPv4 + 8 B UDP + 8 B VXLAN = 50 B.verifiedRFC 7348

Header size reference

49 of 49 rows

Matches the name, the explanation and the reference.

HeaderBytesNotesConfidenceReference
Ethernet II header146 B destination MAC + 6 B source MAC + 2 B EtherType.verifiedIEEE 802.3
Ethernet FCS432-bit CRC trailer. It is on the wire, but most capture stacks hide it and most switches recompute it.verifiedIEEE 802.3
Ethernet preamble + SFD87 B preamble + 1 B start-frame delimiter. Physical layer, regenerated by every switch, and not part of the 1500-byte MTU.verifiedIEEE 802.3
Ethernet inter-frame gap12Minimum idle time between frames (96 bit times). Counts for wire-rate maths, not for the frame.verifiedIEEE 802.3
Ethernet frame minimum64A frame shorter than 64 bytes without FCS is a runt. Payloads under 46 bytes are padded up to it.verifiedIEEE 802.3
Ethernet frame maximum151814 B header + 1500 B payload + 4 B FCS. One 802.1Q tag makes it 1522; a jumbo frame is anything larger.verifiedIEEE 802.3
802.1Q VLAN tag (each)42 B TPID (0x8100) + 2 B TCI: 3-bit PCP, 1-bit DEI, 12-bit VID. Stack one row per tag when building QinQ.verifiedIEEE 802.1Q
PPPoE session header6Version/type, code, session id, length. Discovery happens over a different EtherType and is not part of the data path.verifiedRFC 2516
PPP protocol field2Identifies the payload protocol: 0x0021 for IPv4, 0x0057 for IPv6, 0xc021 for LCP.verifiedRFC 1661
MPLS label entry (each)420-bit label, 3-bit TC, 1-bit bottom-of-stack, 8-bit TTL. Four bytes per label, however deep the stack.verifiedRFC 3032
MPLS pseudowire control word4Optional 4-byte control word that keeps pseudowire payloads in sequence (RFC 4385).verifiedRFC 4385
IPv4 header2020 B with no options: version/IHL, DSCP/ECN, total length, id, flags/fragment offset, TTL, protocol, header checksum, source, destination.verifiedRFC 791
IPv4 options (maximum)400–40 B, padded to a 4-byte boundary, and every 4 bytes comes straight off the TCP MSS. Record-route options are usually stripped or dropped.verifiedRFC 791
IPv6 header40Fixed 40 B: version/traffic class/flow label, payload length, next header, hop limit, 16-byte source, 16-byte destination. No checksum.verifiedRFC 8200
IPv6 extension header (empty)8Extension headers are a multiple of 8 octets. A hop-by-hop or destination-options header with no options is 8 B; the fragment header is always 8 B.verifiedRFC 8200
TCP header2020 B with no options: source and destination ports, sequence, acknowledgement, data offset, flags, window, checksum, urgent pointer.verifiedRFC 9293
TCP options (maximum)40The data offset allows up to 40 B. Timestamps cost 12 B and SACK blocks 10–34 B, so a SYN can be 32 B of TCP header before any payload.verifiedRFC 9293
TCP MSS option4Kind 2, length 4, and the 16-bit MSS. Announced in the SYN in each direction; it limits the peer, never the sender.verifiedRFC 9293
UDP header8Source port, destination port, length, checksum. No sequencing, no acknowledgement, no congestion control.verifiedRFC 768
UDP-Lite header8Same 8-byte layout as UDP, but the length field becomes checksum coverage so a partially protected payload is possible.verifiedRFC 3828
ICMP header8Type, code, checksum and a 4-byte type-dependent field, followed by the quoted original packet in error messages.verifiedRFC 792
ICMPv6 header8Type, code, checksum and message-specific data. Includes Neighbor Discovery, which replaces ARP.verifiedRFC 4443
IGMPv2 message8Type, maximum response time, checksum, group address. IGMPv3 membership reports grow with the source list.verifiedRFC 2236
ARP for IPv4 over Ethernet28Hardware type, protocol type, hardware/protocol lengths, opcode, sender MAC/IP and target MAC/IP. 28 bytes for Ethernet + IPv4.verifiedRFC 826
GRE base header42 B flags/version + 2 B protocol type (0x0800 IPv4, 0x86DD IPv6, 0x6558 transparent Ethernet bridging).verifiedRFC 2784
GRE checksum4Optional 4 B checksum + reserved1, present when the C bit is set. Almost never used in practice.verifiedRFC 2784
GRE key4Optional 32-bit key when the K bit is set — the usual way to multiplex tenants or VRFs over one tunnel.verifiedRFC 2890
GRE sequence number4Optional 32-bit sequence number when the S bit is set, used for reordering detection.verifiedRFC 2890
AH fixed header12Next header, payload length, reserved, 4 B SPI, 4 B sequence number. The ICV follows and is a multiple of 32 bits.verifiedRFC 4302
AH ICV (HMAC-SHA-1-96)12Truncated 96-bit ICV. The mandatory-to-implement AH algorithm, and the reason AH is rare behind NAT — it signs the IP header.verifiedRFC 4302
ESP SPI + sequence number84 B Security Parameters Index + 4 B sequence number. Always present, in both transport and tunnel mode, and never encrypted.verifiedRFC 4303
ESP IV (AES-CBC)16One explicit cipher block used as the IV (RFC 3602 §2.4). A random IV per packet, so it is pure overhead.verifiedRFC 3602
ESP IV (AES-GCM)88-byte explicit nonce: 4 B salt from the SA plus 4 B carried in the packet (RFC 4106 §3.1).verifiedRFC 4106
ESP trailer21 B Pad Length + 1 B Next Header. The padding before it is 0–255 B and must make payload + pad + 2 a whole number of cipher blocks (16 for AES-CBC).verifiedRFC 4303
ESP ICV (HMAC-SHA-1-96)12Truncated 96-bit integrity check value (RFC 2404).verifiedRFC 2404
ESP ICV (HMAC-SHA-256-128)16Truncated 128-bit integrity check value (RFC 4868).verifiedRFC 4868
ESP ICV (AES-GCM tag)16128-bit authentication tag produced by the AEAD mode itself (RFC 4106 §3.2).verifiedRFC 4106
IPsec NAT-T UDP header8ESP-in-UDP encapsulation on port 4500 so a NAT can keep the flow state (RFC 3948). This is why NAT-T costs exactly one UDP header.verifiedRFC 3948
VXLAN header8Flags byte with the I bit set, 24-bit VNI, reserved. Canonical total over IPv4 with no outer tag: 50 B.verifiedRFC 7348
Geneve header82 B version/option length, 1 B flags, 2 B protocol type, 24-bit VNI, 1 B reserved, plus 4-byte-aligned TLV options.verifiedRFC 8926
SRv6 segment routing header8Next header, hdr ext len, routing type, segments left, last entry, flags, 2 B tag. The segment list follows.verifiedRFC 8754
SRv6 segment (each)16One 128-bit SID per entry. This is why SRv6 policy depth is the dominant cost in an SRv6 encapsulation.verifiedRFC 8754
WireGuard data message overhead321 B type + 3 B reserved + 4 B receiver index + 8 B counter + 16 B Poly1305 tag. With IPv4 + UDP the published total is 60 B.documentedWireGuard protocol
BGP message header1916 B marker + 2 B length + 1 B type. An OPEN message with no optional parameters is 29 B on the wire.verifiedRFC 4271
OSPFv2 packet header24Version, type, packet length, router id, area id, checksum, authentication type and 8 B of authentication data.verifiedRFC 2328
RTP fixed header12V/P/X/CC, M/PT, sequence number, timestamp, SSRC. Each contributing source adds 4 B; a 20 ms G.711 stream is 160 B of payload plus this header.verifiedRFC 3550
DNS message header12Transaction id, flags, then four 16-bit counts (questions, answers, authority, additional).verifiedRFC 1035
DHCP fixed part240236 B BOOTP fixed area (op, htype, hlen, hops, xid, secs, flags, ciaddr…file) plus the 4-byte magic cookie 99.130.83.99. Options follow.verifiedRFC 2131
NTP packet4848-octet packet with four 64-bit timestamps. The optional MAC follows when the packet is authenticated.verifiedRFC 5905

Frequently asked

Why does VXLAN cost 50 bytes?
VXLAN carries a frame inside UDP: 14 bytes of outer Ethernet, 20 of IPv4, 8 of UDP and 8 of VXLAN header. That is the canonical 50 bytes over IPv4 with no outer VLAN tag.
How is the TCP MSS calculated?
Subtract the IP and TCP headers from the MTU: MTU − 40 for IPv4 and MTU − 60 for IPv6, assuming a 20-byte TCP header with no options. Every 4 bytes of TCP options such as timestamps or SACK reduces the MSS by 4.
Why did the MSS become 1452 on a PPPoE line?
PPPoE adds 8 bytes — a 6-byte session header plus the 2-byte PPP protocol field — so a 1500-byte Ethernet link carries a 1492-byte IP MTU, and 1492 − 40 = 1452. That is why PPPoE links need MSS clamping or path MTU discovery.
Why do large transfers stall inside an IPsec tunnel?
ESP adds an 8-byte header, an IV, 0–15 bytes of block padding, a 2-byte trailer and an ICV, and tunnel mode adds a further 20-byte outer IP header. Without MSS clamping or working path MTU discovery, full-size packets are dropped with "fragmentation needed" while small ones pass.
Where does the ESP padding number come from?
It is whatever makes the payload plus padding plus the two-byte trailer a whole number of cipher blocks — 16 bytes for AES-CBC. AES-GCM is a stream cipher and needs no block padding, so its overhead is far more predictable.

Next