Visual RFC.
ALL RFCs / RFC 8201
Read the RFC ↗
RFC 8201 / IPv6 Path MTU

Find the smallest link

01

A link MTU is the largest IPv6 packet one link can carry in one piece. The path MTU is the smallest of those limits along the route. A sender learns about a smaller limit through ICMPv6 Packet Too Big feedback.

RFC 8201 · § 3EXAMPLE
4 / 4
Find the smallest linkA new 1280-byte packet fits all three shown links and travels to the peer. This shows size feasibility, not guaranteed network delivery or a permanent path limit.One path can hide several bottlenecksSourceR1R2Peer150014001280Link MTUs · whole IPv6 packet octetsnew 1280-byte packet1280 ≤ 1500, 1400, 1280Fits every shown linkSize feasibility ≠ guaranteed deliveryIPv6 has no DF bit · sender adapts
04
Send a packet that fits

A new 1280-byte packet is no larger than any shown link MTU and reaches the destination. These examples show size feasibility, not a delivery guarantee or cryptographic proof.

Source for this drawing: RFC 8201 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
RFC 1981RFC 8201 § 4

RFC 8201 obsoletes RFC 1981. Its clarified requirement discards PTB messages reporting less than the IPv6 minimum link MTU; it does not teach the removed below-minimum handling from the old text. Appendix B records the changes.

Read the updated RFC section ↗
KEY POINT

Routers drop oversized IPv6 packets; the source adapts its packet size.

  • RFC 8201 defines Path MTU Discovery (PMTUD) for IPv6. It obsoletes RFC 1981, derives from IPv4 RFC 1191, and is STD 87. It is not a new IPv6 wire version. IPv6 has no IPv4 Don’t Fragment bit (Appendix A).
  • The initial PMTU estimate is the known first-hop link MTU (§3). That is a starting estimate, not knowledge of every later link. A route through links 1500,1400,1280 has PMTU 1280 octets, including the IPv6 header, not 1280 bytes of application data.
  • An oversized packet is discarded at the constricting hop; an ICMPv6 Packet Too Big message reports the next-hop MTU (§3; RFC 4443§3.2). IPv6 routers do not fragment that packet. More than one send/PTB cycle can be needed when a smaller bottleneck lies farther along the path.
  • The source reduces its estimate and sends smaller packets, or changes its effective sending limit so the upper layer adapts (§§3–4). A valid decrease should be detected as fast as possible; retransmission remains the upper layer’s responsibility.
  • IPv6 nodes should implement PMTUD. A minimal implementation may omit it, but then must limit packets to the IPv6 minimum link MTU 1280 (§1; RFC 8200§5). This is not a rule that every IPv6 path has exactly1280 MTU.
  • This RFC deliberately uses lower-case must/should/may and does not invoke RFC 2119 definitions (§1). This guide preserves those distinctions; numerical link values above are chosen examples, not prescribed network settings.
DETAILS

Fictional unicast path, all lengths in octets. Three link limits 1500/1400/1280; each state is a labeled attempt or response, not successful forwarding through a failed hop.

Read the RFC section ↗

All chapters in RFC 8201

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗