Budget headers and data

Subtract the headers that are actually present, and distinguish smaller messages from source fragmentation.

• §5.1 defines the maximum send transport-message size by subtracting IPv6 headers, including extension headers, from the effective sending size. When avoiding source fragmentation, that effective size is the PMTU. UDP’s eight-byte header is additional overhead (RFC 768).
• The chosen no-options UDP example at PMTU 1400 has 40 IPv6 +8 UDP +1352 data octets. Adding a chosen 8-byte Destination Options header leaves 1344 data octets. Extension headers do not all have this size; real headers must be counted.
• At PMTU 1280, a no-extension UDP packet has at most 1232 data octets. UDP does not split an existing datagram into several application messages automatically. The application protocol must support any repacketization, or source fragmentation may be needed (§§5.1,5.5).
• A source can fragment a larger IPv6 packet into fragments that each fit the PMTU; routers cannot (RFC 8200§4.5). The final state uses a 1500-byte original packet:40 IPv6 +8 UDP +1452 data. Its 1460 octets after the base header (8 UDP +1452 data) becomes 1232 and 228-byte pieces, each with40 IPv6 +8 Fragment-header overhead:1280 and 276-byte fragments.
• The first fragment has offset 0/M=1; the second has offset154/M=0, since 1232/8=154 (RFC 8200§4.5). The first contains the entire UDP header. Widths for those fragment pieces share one byte scale. Reassembly happens at the destination; this is an alternative source-fragmentation example, not the router repairing an earlier dropped packet.
• Packetization layers are encouraged to avoid source fragmentation (§5.1). A PMTU probe must not be fragmented down to the old PMTU (§5.4), which would defeat its test. Reliable retransmissions still need congestion control; a PTB-indicated PMTU probe loss is not itself a congestion notification (§5.4). TCP also remains bound by its peer MSS, independently of PMTU.