skip to content

What does an IPv6 router send when a packet exceeds its next-hop MTU, and how must the source react?

level: middleimportance: should knowfreq 34%

answer

  1. no fragmenting in the middle
  2. drop, then report the size
  3. type 2 carries a number
  4. never below 1,280
  5. shrink fast, grow slowly

basics

~20 s

The router drops the packet and sends ICMPv6 Packet Too Big (type 2) to the source, carrying the next-hop link's MTU. The source lowers its path-MTU estimate, never below 1,280 bytes, and sends smaller packets.

solid answer

~50 s

IPv6 routers never fragment (RFC 8200), so a router that cannot forward a packet because it exceeds the outgoing link's MTU **must** drop it and send **Packet Too Big** (type `2`, code `0`) to the packet's source. The message carries a 32-bit **MTU** field holding the next-hop link's MTU and quotes as much of the dropped packet as fits in a 1,280-byte error. Under RFC 8201 the source reduces its **path-MTU estimate** for that path to the reported value and sends smaller packets; a transport such as TCP sends smaller segments. It must ignore a reported MTU below the IPv6 minimum of 1,280 bytes, should check that the quoted packet is one it actually sent, and must never raise its estimate because of a Packet Too Big; it may probe for a larger MTU later, no sooner than 5 minutes after one arrived.

go deeper

for a junior

Recall that IPv6 routers drop oversized packets instead of fragmenting them, and send Packet Too Big, ICMPv6 type 2, carrying the link MTU back to the source.

for a middle

Walk through the exchange: router drops and reports the next-hop MTU, source lowers its path-MTU estimate, rounds repeat per constricting link, and nothing goes below 1,280 bytes.

for a senior

Show you can reason about the edges in production: forged or missing Packet Too Big, multicast senders, slow probing upward, and when to rely on probing-based discovery.

for a principal

Discuss the design trade: moving fragmentation to the source made routers simpler and faster, at the price of making one ICMPv6 message essential to every large transfer.

## Why IPv6 needs this message In IPv4 a router may fragment a packet that is too big for the next link, unless the sender set the Don't Fragment bit. IPv6 removes that option. RFC 8200 states that **fragmentation in IPv6 is performed only by source nodes**, using the Fragment header, never by routers on the path. It also sets a floor: every IPv6 link must carry packets of at least **1,280 bytes**, the IPv6 minimum link MTU. So when a packet is larger than the next link allows, the router has one move: drop it and tell the source. The message that does the telling is **ICMPv6 Packet Too Big**, and it is the input to **Path MTU Discovery** for IPv6 (RFC 8201, which obsoletes RFC 1981). The path MTU is the smallest link MTU along a path. ## What the router does 1. It determines that the packet is larger than the MTU of the outgoing link. 2. It discards the packet. RFC 4443 says a Packet Too Big **MUST** be sent in this case. 3. It builds an ICMPv6 error with **Type `2`**, **Code `0`** (set to zero by the sender, ignored by the receiver) and a 32-bit **MTU** field holding the next-hop link's MTU. 4. It copies in as much of the dropped packet as fits without the error packet exceeding 1,280 bytes, so the source can match it to a connection. 5. It addresses the message to the **source address of the dropped packet**. Two details set Packet Too Big apart from other ICMPv6 errors: - It is **sent even about multicast packets** (and link-layer multicast or broadcast), which other errors are not. RFC 4443 makes that exception so path-MTU discovery works for multicast. A multicast sender may receive several, one per constricting path, and uses the smallest. - Like every ICMPv6 error, it is subject to the router's **rate limit**, so a burst of oversized packets may draw fewer messages than packets. ## What the source does RFC 8201 sets the rules for a node that implements Path MTU Discovery: - It **reduces its path-MTU estimate** for that path based on the MTU field, and its transport sends smaller packets; TCP, for example, sends smaller segments. - It **discards** a Packet Too Big that reports an MTU **below 1,280 bytes**, and never lowers its estimate below that minimum. - It **should validate** the quoted packet, checking that it matches traffic it actually sent. A forged message is a known way to make a sender use needlessly small packets (RFC 5927 describes this class of attack against TCP). - It **never increases** its estimate because of a Packet Too Big. To find out whether the path MTU has grown, it probes with a larger packet, but not sooner than **5 minutes** after a Packet Too Big for that path; RFC 8201 recommends **10 minutes**. - A node may instead skip discovery entirely and never send packets larger than 1,280 bytes, which RFC 8200 allows for minimal implementations. ## A worked example A server on a link with a 1,500-byte MTU sends to a client reached through a tunnel whose link MTU is 1,420 bytes. | Step | Event | Result | |---|---|---| | 1 | Server sends a 1,500-byte packet | fits the first link | | 2 | The tunnel's entry router cannot forward it | packet dropped | | 3 | Router sends Packet Too Big with MTU 1,420 to the server | message quotes the start of the dropped packet | | 4 | Server sets its estimate for this path to 1,420 | the transport resends the data in packets of at most 1,420 bytes | | 5 | A later link with a smaller MTU would drop again | another Packet Too Big, another reduction | Discovery can take several rounds, one per constricting link, before the estimate settles. ## History worth knowing - RFC 1981 defined IPv6 Path MTU Discovery; **RFC 8201** replaced it in 2017. - Under the obsoleted RFC 2460, a Packet Too Big reporting less than 1,280 bytes told the source to add a Fragment header to every packet, producing so-called atomic fragments. RFC 8021 described why that was harmful, and RFC 8200 removed the rule; today the message is simply discarded. - When Packet Too Big cannot be relied on to arrive, Packetization Layer Path MTU Discovery (RFC 4821, RFC 8899) finds the path MTU by probing without ICMP. ## Slips to avoid - Saying the router fragments the packet, which is IPv4 behaviour. - Calling it Destination Unreachable with a fragmentation code, which is IPv4's encoding. - Saying the source raises its estimate when a Packet Too Big reports a larger MTU.

  • Why may an IPv6 router send Packet Too Big about a multicast packet when other ICMPv6 errors about multicast are forbidden?
    Without it, IPv6 multicast senders could never learn path MTUs, since routers will not fragment for them either. RFC 4443 therefore exempts Packet Too Big from the rule against errors about multicast destinations. A multicast packet may draw several, one per constricting path, and RFC 8201 has the sender use the smallest reported MTU across the paths in use.
  • How does an IPv6 source discover that a path's MTU has grown, for example after a route change?
    Not from Packet Too Big: RFC 8201 forbids raising the estimate in response to one, since such a message may be stale or forged. The source periodically sends a packet larger than its current estimate and keeps the larger size if it gets through. Because most such probes fail, it must wait at least 5 minutes after a Packet Too Big before trying, and 10 minutes is recommended.
  • Why should a host check what a Packet Too Big message quotes before acting on it?
    Anyone who can send packets to the host can forge a Packet Too Big, and acting on a fake one makes the host send needlessly small packets for that destination. RFC 8201 says nodes should validate that the quoted packet matches traffic they actually sent, and RFC 5927 describes forged path-MTU messages as a blind performance-degrading attack on TCP. The 1,280-byte floor also limits how much damage a forged message can do.

A narrow bridge on a delivery route: the guard does not saw an oversized load into pieces. He turns the truck back and radios the depot the bridge's width limit, and from then on the depot loads trucks to fit that limit on that route.

saying these in an interview costs you the question

  • An IPv6 router fragments a packet that is too big for the next link.
  • IPv6 reports an oversized packet with Destination Unreachable, fragmentation needed.
  • The source lowers its path MTU to whatever value Packet Too Big reports, even below 1,280.
  • A Packet Too Big reporting a larger MTU lets the source raise its estimate at once.
  • Packet Too Big goes to the packet's destination so the receiver can reassemble.