The IPv6 base header has no header checksum and no fragmentation fields, so what took over each of those jobs?
answer
- two IPv4 jobs, two new homes
- pseudo-header in upper-layer checksums
- only the source splits
- Next Header 44
- ICMPv6 Packet Too Big, 1,280 floor
basics
~20 sError detection moved to link-layer frame checks and to TCP, UDP and ICMPv6 checksums over a pseudo-header with both addresses. Fragmentation moved into a Fragment extension header that only the source adds; routers send Packet Too Big instead of splitting.
solid answer
~40 sThe IPv4 header checksum is gone, so no router verifies or recomputes anything when it decrements Hop Limit. Corruption is caught by the link layer's own frame check on each hop and, end to end, by upper-layer checksums: TCP, UDP and ICMPv6 all cover a pseudo-header holding the source and final destination addresses, so a packet delivered to the wrong host fails its checksum. The UDP checksum, optional over IPv4, is mandatory by default over IPv6. Identification, flags and fragment offset moved into a Fragment extension header (`Next Header` 44) that only the source inserts. A router facing a packet too big for the next link discards it and sends ICMPv6 Packet Too Big; the source then sends smaller packets or fragments them itself, and every link must carry at least 1,280 bytes.
go deeper
Recall that the IPv6 base header has no checksum and that routers never fragment IPv6 packets; the source does it, when it must.
Explain both moves: upper-layer checksums cover a pseudo-header with both addresses, and fragmentation lives in an 8-byte Fragment header with a 13-bit offset, M flag and 32-bit Identification.
Connect the design to failures: with no router fragmentation, a dropped ICMPv6 Packet Too Big message means large packets vanish, and fragmented traffic meets the same filters as other extension headers.
Weigh what the move costs: end-to-end integrity of the addresses now rests on the endpoint's upper-layer checksum, and fragmentation is an end-host decision the network cannot repair.
## Two IPv4 jobs, two new homes An IPv4 router does two things to the header of every packet that IPv6 removes from the base header: it verifies and updates a **header checksum**, and it may **split** a packet that does not fit the next link. RFC 8200 keeps both jobs but moves them: | IPv4 field(s) | Job | Where it lives in IPv6 | |---|---|---| | `Header Checksum` | Detect a corrupted header | Link-layer frame checks per hop; TCP, UDP and ICMPv6 checksums end to end | | `Identification`, flags (DF, MF), `Fragment Offset` | Split a packet anywhere on the path | A **Fragment extension header**, inserted only by the source | The motive was to take per-packet work out of every router; this answer is about where the work went. ## The checksum: who protects the header now - In IPv4 a router **must** verify the header checksum of every packet it receives (RFC 1812), and because it changes TTL it rewrites the checksum before forwarding; RFC 1812 allows that to be an incremental update. - In IPv6 there is nothing to verify or recompute when `Hop Limit` drops by one. - Protection per hop comes from the **link layer**: a frame such as Ethernet's carries its own frame check sequence, which catches bit errors on that link only. - Protection end to end comes from the **upper layer**. RFC 8200 section 8.1 defines a **pseudo-header** that TCP, UDP and ICMPv6 include in their checksums: the 128-bit source address, the final destination address (the last Routing header entry, if there is one), the upper-layer packet length and the upper-layer `Next Header` value. - Because the addresses are inside that checksum, a packet whose destination address was corrupted in transit and delivered to the wrong host fails verification there. - The UDP checksum, optional over IPv4, is not optional over IPv6 by default; a narrow zero-checksum exception exists for tunnel encapsulations. ICMPv6 also covers the pseudo-header, which ICMP for IPv4 never did; RFC 8200 gives exactly this reason, that the IPv6 fields ICMPv6 depends on are no longer covered by an internet-layer checksum. - Fields no checksum covers include `Traffic Class`, `Flow Label` and `Hop Limit`; the first and last legitimately change in transit anyway. ## Fragmentation: only the source, only in an extension header When a packet meets a link it does not fit, the sequence is: 1. The router discards it and sends an **ICMPv6 Packet Too Big** message (type 2, RFC 4443) carrying the next-hop link's MTU to the source. 2. The source lowers its path MTU estimate, through Path MTU Discovery for IPv6 (RFC 8201) or a packetization-layer method such as RFC 8899 for datagram transports, and sends smaller packets. 3. If the application cannot make its packets smaller, the source fragments them itself, inserting a **Fragment header** (`Next Header` 44) into each fragment. 4. Only the destination reassembles. It must accept a packet that reassembles to 1,500 bytes; if reassembly times out it reports ICMPv6 Time Exceeded with code 1. The Fragment header is always 8 bytes: - `Next Header`, 8 bits, naming the first header of the fragmented part; - `Reserved`, 8 bits; - `Fragment Offset`, 13 bits, in **8-octet units**; - two reserved bits and the **M** (more fragments) flag; - `Identification`, **32 bits**, twice the width of IPv4's 16-bit field. That is 8 + 8 + 13 + 2 + 1 + 32 = 64 bits. The source must choose an Identification that differs from any other packet it fragmented recently with the same source and destination addresses. ## Why there is no Don't Fragment bit Since no router may fragment, every IPv6 packet already behaves as an IPv4 packet with DF set. What makes that workable is a floor: RFC 8200 requires every link to carry **1,280-byte** packets, and a link that cannot must fragment and reassemble below IPv6. A minimal implementation may skip Path MTU Discovery and send nothing larger than 1,280 bytes. RFC 8200 also discourages source fragmentation for any application that can adjust its packet size to the measured path MTU. ## Consequences you meet in production - Filtering ICMPv6 Packet Too Big leaves large packets silently lost: the router has dropped them and the source never learns why. - Fragments carry an extension header, so they inherit the drops measured against extension headers on the public internet. - An endpoint is the only place header corruption can be detected end to end, so an upper layer that disables its checksum loses that protection.
- How wide is the IPv6 Fragment header's Identification field, and why does that width matter?It is 32 bits, against 16 bits in IPv4. The source must not reuse a value for another fragmented packet with the same source and destination while fragments may still be in flight or awaiting reassembly; a 16-bit space can wrap within that window at high packet rates, which risks splicing fragments of different packets together.
- What lets an IPv6 source that does no Path MTU Discovery still get its packets through?The 1,280-byte minimum link MTU in RFC 8200. Every link must carry a 1,280-byte packet, by fragmenting below IPv6 if its own MTU is smaller, so a minimal implementation may simply never send anything larger than 1,280 bytes.
- If IPv6 routers never fragment, why does the Fragment header exist at all?Because a source sometimes has to send a packet larger than the path MTU, for example a datagram an application cannot resize. The source splits it, inserts a Fragment header in each piece, and only the destination reassembles; routers stay out of it.
saying these in an interview costs you the question
- IPv6 routers fragment oversized packets just as IPv4 routers do.
- IPv6 dropped fragmentation entirely, so a large packet can never be split.
- Without a header checksum, nothing in IPv6 catches a corrupted destination address.
- The fragmentation fields are still in the base header, just usually set to zero.
- An IPv6 source sets a Don't Fragment bit to stop routers splitting its packets.