Networking / Advanced: policy, evidence, capacity, and resilient design / Lesson 15

Reason about MTU, ICMP, and path discovery

Calculate declared size budgets while distinguishing path limits, TCP MSS, IPv4 fragmentation, and IPv6 discovery behavior.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Separate interface MTU, path MTU, transport payload, and encapsulation overhead.
Explain fragmentation and discovery failures through bounded offline models.

Name the packet boundary before subtracting bytes

An interface MTU describes a packet-size boundary at that interface, while a path MTU is constrained by the links on a particular direction of travel. Application payload, TCP segment data, IP packet length, and link-frame occupancy are different measurements. Tunnels add outer headers and can reduce the available inner-packet budget. A large local interface value does not prove that every downstream hop accepts the same size. Paths and encapsulation can change, so a previously successful size is evidence for its observed context rather than a permanent global limit.

Use declared headers instead of a universal MSS formula

TCP MSS describes a maximum segment data size advertised by a receiver; the effective sending size must also respect path and protocol constraints. The following arithmetic assumes a synthetic tunnel consumes exactly eighty bytes and that IP and TCP have only their base headers. Options, IPv6 extension headers, additional tunnels, and application framing would change the useful payload calculation. MSS is TCP-specific and does not directly govern UDP application messages. A smaller advertised MSS can help a particular design but is not a general substitute for correct path discovery.

python Calculate a synthetic tunnel payload budget

underlay_mtu = 1500
tunnel_overhead = 80
inner_mtu = underlay_mtu - tunnel_overhead
print(f'inner_mtu={inner_mtu}')
for family, ip_header in (('IPv4', 20), ('IPv6', 40)):
    print(f'{family}_tcp_payload={inner_mtu - ip_header - 20}')

Expected output

inner_mtu=1420
IPv4_tcp_payload=1380
IPv6_tcp_payload=1360

The declared inner MTU is 1420 bytes, leaving 1380 or 1360 bytes with the stated IPv4 or IPv6 base headers. These are arithmetic results for fixed assumptions, not interface settings, measured path limits, or recommended universal MSS values.

IPv4 and IPv6 routers have different fragmentation roles

IPv4 can fragment a packet where permitted, with fragment offsets expressed in eight-byte units; nonfinal payload pieces must respect that alignment. When DF prevents fragmentation, an oversized packet needs appropriate error handling instead. IPv6 routers do not fragment forwarded packets; the source handles sizing and any source fragmentation under IPv6 rules. The model below applies only to IPv4 with DF clear and a fixed twenty-byte header. It is not a packet generator, checksum validator, reassembly engine, or IPv6 fragmentation algorithm.

python Partition a declared IPv4 payload offline

mtu, header, remaining = 1500, 20, 3000
capacity = ((mtu - header) // 8) * 8
offset_bytes = 0
while remaining:
    data_bytes = min(capacity, remaining)
    remaining -= data_bytes
    print(f'offset={offset_bytes // 8} data={data_bytes} mf={int(remaining > 0)}')
    offset_bytes += data_bytes

Expected output

offset=0 data=1480 mf=1
offset=185 data=1480 mf=1
offset=370 data=40 mf=0

The 3000-byte payload becomes pieces of 1480, 1480, and 40 bytes with offsets 0, 185, and 370. Each resulting IP packet also needs its header. No fragments are transmitted, and real options or reassembly constraints require additional reasoning.

ICMP errors carry useful path information

Classical PMTUD uses relevant ICMP feedback about packets that exceed a path constraint, including IPv6 Packet Too Big. Blocking every ICMP message can remove that feedback and contribute to a black hole where small exchanges work but larger transfers stall. Echo replies are a different ICMP function: failure of an echo request alone does not establish that required error feedback is blocked. Packetization-layer discovery can use transport-aware probing and confirmation, but needs its protocol’s documented bounds and recovery behavior rather than arbitrary repeated large sends.

A size-sensitive symptom is a hypothesis to test

A stalled large response can suggest an MTU or discovery problem, but application limits, congestion, middleboxes, and loss can produce similar symptoms. Compare the actual packetization assumptions, tunnel boundary, direction, error feedback, and observation point in declared evidence. Host offload can make captured sizes differ from wire packets, so an oversized host-side record is not automatically an on-wire violation. Any operational capture, probe, or configuration change requires separate authorization. Here, only synthetic arithmetic is performed; no interface, route, firewall, or network endpoint is inspected.

Common errors and fixes

Every interface MTU is converted to MSS by subtracting forty

Why it happens: One IPv4/TCP base-header assumption was generalized to every encapsulation and family.
How to fix it: List the actual inner and outer headers before calculating a payload budget.
Prevent it next time: Label every size with its protocol boundary and assumptions.

All ICMP is blocked because echo is unnecessary

Why it happens: Diagnostic echo and necessary network error feedback were treated as identical.
How to fix it: Define a reviewed policy for required error messages and validation behavior.
Prevent it next time: Review discovery and failure signaling before changing filtering.

An IPv4 fragmentation model is applied to forwarded IPv6

Why it happens: The source and router fragmentation responsibilities were not separated.
How to fix it: Use the correct address-family rules and path feedback model.
Prevent it next time: Keep IPv4 and IPv6 acceptance cases explicit.

Check your understanding

1. What base-header TCP payload fits a declared IPv6 path MTU of 1280?

Show worked solution

With a forty-byte IPv6 header and twenty-byte TCP header, the arithmetic budget is 1220 bytes. Additional extension or TCP option bytes need separate accounting. This calculation neither discovers a path nor prescribes the receiver’s advertised MSS or a host configuration change.

2. Why is a successful small request insufficient to rule out PMTUD trouble?