Kurose and Ross, Computer Networking: A Top-Down Approach, section 4.3, cross-checked against RFC 791 (Internet Protocol), RFC 1071 (Computing the Internet Checksum), RFC 2474 (the Differentiated Services field), RFC 3168 (Explicit Congestion Notification), RFC 1191 (Path MTU Discovery) and RFC 8200 (IPv6). Every offset, length and checksum was recomputed in code.
Learn the header as five rows of 32 bits, and say aloud what each field is for. Then do the fragmentation example by hand, twice, until the three rules (multiples of 8, offsets in 8-byte units, the more-fragments flag) feel automatic.
Textbook slides use friendly field names. The standard (RFC 791) calls datagram length “Total Length”, the 16-bit identifier “Identification”, and upper-layer protocol “Protocol”. The old type of service byte is now split into DSCP and ECN (RFC 2474 and RFC 3168). Same bits, newer names.
The picture: a shipping label, and a sofa through a door#
A parcel carries a label. It says who sent it, who gets it, how heavy it is, and what kind of thing is inside. The couriers in between read only the label. They never open the box.
An IPv4 header is that label. Routers read it, and nothing else, to move the datagram (the network-layer packet) toward its destination.
Now imagine moving a big sofa through a narrow door. You take it apart, number the pieces, and note which piece is the last one. You only put it back together inside the new home. That is fragmentation: a datagram too big for the next link is cut into numbered pieces, and only the receiving host rebuilds it.
Vocabulary, before anything uses it#
| Term | What it means |
|---|---|
| Header | The control information at the front of a datagram. Routers read it to forward the datagram. |
| Payload | What the datagram carries after its header, usually a TCP or UDP segment. |
| 32-bit word | A group of 4 bytes. The header is drawn as rows of one word each. |
| MTU | Maximum transmission unit: the largest datagram, header included, that one link-layer frame can carry. Ethernet’s is 1,500 bytes. |
| Fragment | One piece of a datagram that was too big for a link. Each fragment is a full datagram with its own header. |
| Reassembly | Putting the fragments back into the original datagram. Only the destination host does it. |
| Flag | A single bit that is either on (1) or off (0). |
| Checksum | A number computed from data, sent along with it, so the receiver can spot bits that changed in transit. |
The header, field by field#
A header with no options is exactly 20 bytes: five rows of 32 bits. Learn it in that shape.
| Row | Fields in the row (size in bits) |
|---|---|
| 1 | Version (4) · Header length (4) · Type of service (8) · Datagram length (16) |
| 2 | Identifier (16) · Flags (3) · Fragment offset (13) |
| 3 | Time to live (8) · Upper-layer protocol (8) · Header checksum (16) |
| 4 | Source IP address (32) |
| 5 | Destination IP address (32) |
| 6+ | Options (0 to 40 bytes, rarely used), then the payload |
What each field is for:
| Field | What it says |
|---|---|
| Version | Which IP version: 4. A router reads this first to know how to read the rest. |
| Header length | Header size in 32-bit words. 5 means 5 × 4 = 20 bytes. The largest value, 15, means 60 bytes, so options can take at most 40 bytes. |
| Type of service | Now split in two. The first 6 bits are the DSCP (Differentiated Services Code Point), which marks a traffic class such as voice. The last 2 bits are ECN (Explicit Congestion Notification), which a router can set instead of dropping the packet, if the sender marked it as ECN-capable. |
| Datagram length | Whole datagram, header plus payload, in bytes. 16 bits, so at most 65,535 bytes. |
| Identifier | A 16-bit number the sender gives each datagram. All fragments of one datagram share it. |
| Flags | Three bits: one reserved (always 0), DF (do not fragment), and MF (more fragments follow). |
| Fragment offset | Where this fragment’s data belongs in the original, in units of 8 bytes. |
| Time to live (TTL) | A hop counter. Each router subtracts 1. If it reaches 0, the router drops the datagram and sends an error back to the source. This stops packets looping forever. Maximum 255. |
| Upper-layer protocol | Which protocol the payload is for: 6 is TCP, 17 is UDP, 1 is ICMP. The destination uses it to hand the payload to the right part of the system. |
| Header checksum | Checks the header only, not the payload. Every router checks it and must recompute it, because the TTL changed. |
| Source and destination addresses | The 32-bit IP addresses of the sending and receiving hosts. |
| Options | Rare extras, such as recording the route. They make the header longer and slower to process. |
Overhead. A TCP segment inside an IPv4 datagram carries at least 20 bytes of TCP header plus 20 bytes of IP header: 40 bytes before any application data. In a 1,500-byte datagram, that leaves 1,460 bytes of data, about 97.3% useful. Send a single typed key, and the datagram is 41 bytes for 1 useful byte, about 2.4%. With UDP, whose header is 8 bytes, the minimum overhead is 28 bytes.
The header checksum, worked once#
The checksum uses one’s complement arithmetic (RFC 1071). Treat the header as ten 16-bit numbers, with the checksum field set to 0. Add them up. If the sum spills past 16 bits, add the spill back onto the bottom (“wrap the carry”). Then flip every bit. That is the checksum.
A header from 192.0.2.10 to 198.51.100.20, carrying TCP, with TTL 64. In hexadecimal (base 16), its ten words are 4500 003C 1C46 4000 4006 0000 C000 020A C633 6414. Reading them: version 4, header length 5 (20 bytes), and datagram length 0x3C = 60 bytes. Then identifier 0x1C46 and the DF flag set. Then TTL 0x40 = 64, protocol 6 (TCP), and the checksum set to 0 for now.
The sum is 0x2CDD9. That spills one hex digit, 2, past 16 bits. Wrap it: 0xCDD9 + 0x2 = 0xCDDB. Flip every bit: checksum = 0x3224.
To check, the receiver adds all ten words including 0x3224 and wraps. A correct header gives 0xFFFF, all ones.
When the next router lowers the TTL from 64 to 63, the word 4006 becomes 3F06. The sum drops by 0x0100, so the checksum rises by 0x0100 to 0x3324. That is why every router recomputes it.
Fragmentation and reassembly#
Every link has an MTU. Ethernet’s is 1,500 bytes, and some links are smaller. When a datagram is bigger than the next link’s MTU, an IPv4 router cuts it into fragments. Each fragment gets a copy of the header. Its datagram length and checksum are recomputed, and three fields let the receiver rebuild the original:
- Identifier: the same in every fragment, so the receiver knows they belong together.
- Fragment offset: where the piece’s data starts in the original data, divided by 8.
- MF flag: 1 on every fragment except the last, which has 0.
Because the offset is counted in 8-byte units, every fragment except the last must carry a multiple of 8 data bytes. So, for a header with no options, the data per fragment is the MTU minus the 20-byte header, rounded down to a multiple of 8.
A 4,000-byte datagram (20-byte header, 3,980 data bytes, identifier 777) meets a link with MTU 1,500.
Data per fragment: 1,500 − 20 = 1,480. That is already a multiple of 8 (1,480 ÷ 8 = 185). So the data splits into 1,480 + 1,480 + 1,020 = 3,980 bytes: three fragments.
| Fragment | Data bytes | Datagram length | Offset | MF |
|---|---|---|---|---|
| 1 | 0 to 1,479 | 1,500 | 0 | 1 |
| 2 | 1,480 to 2,959 | 1,500 | 1,480 ÷ 8 = 185 | 1 |
| 3 | 2,960 to 3,979 | 1,040 | 2,960 ÷ 8 = 370 | 0 |
All three carry identifier 777. Notice the total on the wire is 4,040 bytes, not 4,000: each extra fragment adds another 20-byte header.
Now the case where rounding matters. A 3,000-byte datagram (2,980 data bytes) meets an MTU of 1,000. 1,000 − 20 = 980, but 980 ÷ 8 = 122.5, which is not whole. Round down to 122 × 8 = 976 data bytes per fragment.
Fragments: data 976, 976, 976 and 52 (lengths 996, 996, 996 and 72). Offsets 0, 122, 244 and 366. MF is 1, 1, 1 and 0.
Reassembly
Fragments are rejoined only at the destination host, never by routers along the way. The host groups fragments with the same identifier, source, destination and protocol. It places each one by its offset and knows it has the end when it sees MF = 0. If any fragment is lost, the whole datagram is thrown away, and TCP (if used) must resend all of it.
The DF flag
If DF is set and the datagram is too big, the router does not fragment. It drops the datagram and sends an ICMP (Internet Control Message Protocol) “fragmentation needed” message to the source (type 3, code 4). Path MTU discovery (RFC 1191) uses this on purpose: the sender sets DF, and shrinks its datagrams whenever such a message comes back, until they fit the whole path.
Why IPv6 stopped router fragmentation#
Fragmentation costs routers work, and losing one piece wastes the rest. So IPv6 (RFC 8200) does not let routers fragment at all. A router that gets an IPv6 datagram too big for the next link drops it and sends an ICMPv6 “Packet Too Big” message back. Only the sending host may fragment, and every IPv6 link must carry at least 1,280 bytes. IPv6 also dropped the header checksum. The IPv6 and tunneling guide covers the IPv6 header.
When a datagram exceeds the next link’s MTU, an IPv4 router splits it into fragments that share one identifier, carry data in multiples of 8 bytes, give their offset in 8-byte units and set MF on all but the last, and only the destination reassembles them.
Practice#
Write down the unit of every field before you compute with it: words, bytes or 8-byte units.
- A datagram’s header length field holds 7. How long is the header, and how many bytes of options does it carry?
- A datagram has datagram length 1,200, header length 5, and carries a TCP segment with a 32-byte header. How many bytes of application data does it carry?
- A 5,000-byte datagram with a 20-byte header meets a link with MTU 1,500. How many fragments are made? Give each one’s datagram length, offset and MF flag.
- A host receives a fragment with offset 244, datagram length 996 (20-byte header) and MF = 1. Which bytes of the original data does it carry?
- The last fragment of a datagram has offset 366 and datagram length 72, with a 20-byte header. How long was the original datagram?
- A host sends a datagram with TTL 10. The path to the destination crosses 12 routers. What happens, and where?
- In the checksum example above, the next router lowers the TTL to 63. What is the new checksum, and why must the router compute it?
Solutions#
Find the first line where your working split from the solution, and redo the problem from that line. Do not just read the answer and nod.
- 28 bytes, with 8 bytes of options. The field counts 4-byte words: 7 × 4 = 28. The fixed part is 20 bytes, so 28 − 20 = 8.
- 1,148 bytes. Header length 5 means 20 bytes of IP header. 1,200 − 20 − 32 = 1,148.
- Four fragments: lengths 1,500, 1,500, 1,500 and 560; offsets 0, 185, 370 and 555; MF 1, 1, 1 and 0. Data is 4,980 bytes. Each fragment carries up to 1,480 (a multiple of 8). 1,480 × 3 = 4,440, leaving 540, so the last is 540 + 20 = 560 bytes. Offsets are 0, 1,480, 2,960 and 4,440 bytes, divided by 8.
- Bytes 1,952 to 2,927. The offset in bytes is 244 × 8 = 1,952. The fragment carries 996 − 20 = 976 data bytes, so it ends at 1,952 + 976 − 1 = 2,927.
- 3,000 bytes. This fragment’s data starts at 366 × 8 = 2,928 and is 72 − 20 = 52 bytes long, so the original data was 2,928 + 52 = 2,980 bytes. Add the 20-byte header: 3,000.
- The 10th router drops it. Each router subtracts 1. The 10th router brings the TTL to 0, discards the datagram, and sends an ICMP time-exceeded message back to the source. It never reaches routers 11 and 12.
- 0x3324. The word 0x4006 becomes 0x3F06, so the sum falls by 0x0100 and the complement rises by 0x0100: 0x3224 + 0x0100 = 0x3324. Any change to a header field changes the checksum, and TTL changes at every hop.
Test-readiness checklist#
- ☐ I can draw the IPv4 header as five 32-bit rows and name every field.
- ☐ I can say what each field is for, including DSCP, ECN, TTL and the protocol number.
- ☐ I can convert header length to bytes and find the space used by options.
- ☐ I can compute the 40-byte TCP/IP overhead and what fraction of a datagram is useful data.
- ☐ I can compute an IPv4 header checksum and explain why routers recompute it.
- ☐ I can fragment a datagram for a given MTU: number of fragments, lengths, offsets and MF flags.
- ☐ I can explain reassembly, the DF flag and why IPv6 routers do not fragment.
In every fragmentation question, first write data per fragment = (MTU minus header length) rounded down to a multiple of 8. Everything else follows from that one number.
Frequently asked questions#
How big is an IPv4 header?
Twenty bytes when there are no options, and at most 60 bytes. The header length field gives the size in 4-byte words, so 5 means 20 bytes and 15 means 60 bytes.
Why is the fragment offset counted in units of 8 bytes?
The offset field has only 13 bits, while a datagram can be up to 65,535 bytes long. Counting in 8-byte units lets 13 bits cover the whole datagram, at the cost of requiring every fragment except the last to carry a multiple of 8 data bytes.
Who reassembles fragmented IPv4 datagrams?
Only the destination host. Routers along the path never put fragments back together, and if any fragment is lost, the destination discards the whole datagram.
Why does every router recompute the IPv4 header checksum?
Each router lowers the time-to-live field by one. Because the checksum covers the whole header, any change to a field means the checksum has to be computed again.
Do IPv6 routers fragment packets?
No. An IPv6 router drops a packet that is too big for the next link and sends an ICMPv6 Packet Too Big message back. Only the sending host may fragment, and every IPv6 link must carry at least 1,280 bytes.
Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.
Test yourself on this topic
The free networking practice app has 10 questions on this guide and 500 across the whole course, each with an explanation for every answer. Offline, no ads, no account.
Practise this topic →