The IP Protocol and Datagram Format

The Internet Protocol (IP) is the network-layer protocol that moves discrete units of data, called datagrams, from a source host to a destination host across an internetwork of possibly heterogeneous networks. IP's service model has two defining properties. It is connectionless: every datagram is routed independently, carrying full source and destination addresses, with no setup phase and no per-flow state kept by routers. It is best-effort: the network makes no promise that a datagram will arrive, arrive only once, arrive undamaged, or arrive in the order it was sent. Datagrams can be dropped (queue overflow), duplicated, corrupted (rare, checksums help), reordered (different paths), or delayed arbitrarily. This minimalism is intentional and traces to the end-to-end argument: a function like reliable delivery can only be correctly and completely implemented by the endpoints that understand the application's needs, so building a "mostly reliable" network layer only adds cost and complexity without eliminating the need for end-to-end checks. IP therefore focuses on one job — getting a datagram, hop by hop, as far as it can toward its destination, using the destination address and each router's forwarding table — and leaves reliability, ordering, and flow control to protocols like TCP. The concrete artifact that makes this work is the IP datagram format: a header of well-defined fields prepended to whatever payload the transport layer hands down. Every router that touches a datagram inspects only this header (never trusting or even usually understanding the payload) to decide where to send it next, whether it has expired, and whether it needs to be broken apart. Studying the header field by field is really studying the entire contract IP offers the rest of the Internet.

An IP datagram is built once at the source and reconstructed conceptually — though never truly "processed" beyond the header — at every router along the path. The following pseudocode captures what a router does to every datagram at every hop; this is the actual mechanism, executed billions of times a second across the Internet. ``` function IP_FORWARD(datagram, incoming_interface): header = parse_header(datagram) // 1. Sanity check if header.version != 4: drop(datagram); return if not verify_checksum(header): drop(datagram); return // corrupted header, discard silently // 2. Decrement time-to-live header.TTL = header.TTL - 1 if header.TTL <= 0: send_ICMP_time_exceeded(header.source) drop(datagram); return // 3. Recompute checksum (TTL changed, so checksum must change too) header.checksum = compute_checksum(header) // 4. Is this router the final destination? if header.dest_addr == this_router_address: deliver_to_local_process(datagram, header.protocol) return // 5. Look up next hop using longest-prefix match next_hop, out_interface = forwarding_table.lookup(header.dest_addr) if next_hop is null: send_ICMP_destination_unreachable(header.source) drop(datagram); return // 6. Fragment if the outgoing link's MTU is too small if datagram.length > MTU(out_interface): if header.flags.DONT_FRAGMENT: send_ICMP_fragmentation_needed(header.source) drop(datagram); return fragments = fragment(datagram, MTU(out_interface)) for each fragment in fragments: transmit(fragment, out_interface, next_hop) else: transmit(datagram, out_interface, next_hop) ``` Notice what is absent: there is no acknowledgment sent back to the source confirming forwarding, no retry if `transmit` silently fails at the link layer, no buffer held in case the datagram needs to be resent, and no coordination with any other datagram from the same flow. Each datagram is a self-contained decision problem for each router — this is exactly what "connectionless" and "best-effort" mean operationally.

The IPv4 header, field by field

The header is a minimum of 20 bytes (5 32-bit words), extendable to 60 bytes via the Options field.

Two design choices deserve emphasis. First, TTL exists purely as a self-defense mechanism: routing loops are possible in any distributed system without global coordination, and TTL guarantees a datagram is eventually destroyed rather than circulating forever, consuming bandwidth. Second, the checksum covers only the header, not the payload — checking the payload is left to the transport layer (TCP/UDP have their own checksums), another direct application of the end-to-end argument: since transport-layer checksums are needed anyway (the network cannot verify application-level correctness), duplicating full-payload checking at every router hop would be wasted work.

Per-router processing time. The core operations at each hop are: checksum verification, TTL decrement, checksum recomputation, and a routing-table lookup. Checksum verification and recomputation over a 20-byte header (or up to 60 with options) take $O(1)$ time relative to header size — it is a fixed-size one's-complement sum, independent of payload length. The routing lookup is a longest-prefix match over the destination address; using a trie-based structure (as real routers do), this is $O(W)$ where $W = 32$ is the address width in bits — effectively constant, and in practice implemented in specialized hardware (TCAMs) for true $O(1)$ lookup. So per-datagram forwarding work at each router is $O(1)$ in the size of the network — it does not grow with the number of hosts, flows, or the datagram's payload size. This is a deliberate efficiency property: a core router forwarding millions of datagrams per second cannot afford per-flow bookkeeping, and IP's connectionless design guarantees it never has to maintain any.

Space. IP routers keep no per-datagram or per-flow state between forwarding decisions (ignoring optional features like NAT, which is not part of IP proper). The only persistent memory is the forwarding table, whose size is bounded by the number of network prefixes known to the router (hundreds of thousands in core Internet routers), not by traffic volume. This is the crucial space efficiency argument: a router handling a million simultaneous flows uses the same memory as one handling ten, because IP never allocates per-flow resources.

Correctness of the "no infinite loop" guarantee. Consider the invariant: every datagram's TTL strictly decreases by at least 1 at every hop it visits, and a datagram with TTL = 0 is always discarded. Since TTL starts at a finite value (commonly 64) and is a non-negative integer that strictly decreases each hop, the datagram can visit at most `initial_TTL` routers before being discarded — even if the forwarding tables contain a routing loop (a temporary inconsistency that can occur during route changes). This proves termination: no datagram circulates the network forever, bounding wasted bandwidth to $O(\text{TTL}_{\max})$ hops per errant datagram, regardless of how badly routing tables are misconfigured.

Correctness of best-effort delivery (what is and isn't guaranteed). IP's specification makes exactly one promise: if a datagram is delivered, its header was not corrupted undetected (subject to the checksum's limitations — a 16-bit one's-complement sum only detects, it does not correct, and can miss some multi-bit error patterns). It makes no promise of delivery at all. This is not a bug to be proven away — it is the specification. The honest tradeoff: by refusing to guarantee delivery, IP avoids buffering, retransmission timers, and acknowledgment traffic at every router, which is what makes it scale to arbitrary network sizes and heterogeneous, sometimes lossy, link technologies (early IP ran over noisy packet-radio links). Reliability, when an application needs it, is reconstructed end-to-end by TCP using sequence numbers and retransmission — a strictly more expensive mechanism that IP correctly avoids imposing on traffic that does not need it (e.g., real-time voice, which prefers a dropped datagram over a late one).

Trace a real datagram carrying a DNS query (over UDP) from a laptop (`203.0.113.7`) to a DNS resolver (`198.51.100.53`), crossing two routers, R1 and R2, with R2's outgoing link having a smaller MTU (1200 bytes) than R1's.

Original datagram built at the source:

Step 1 — At R1 (link MTU 1500, no fragmentation needed):

Step 2 — At R2 (outgoing link MTU 1200):

R2 splits the 1480-byte payload into two fragments (each payload chunk must be a multiple of 8 bytes, per the Fragment Offset unit):

Both fragments keep Identification = 0x1A2B (same as the original), so the destination host knows they belong together; TTL = 62 in both. Each fragment gets its own header checksum computed over its own (smaller) header. Both are forwarded independently — potentially arriving out of order, since IP gives no ordering guarantee even for fragments of the same datagram.

Step 3 — At the destination host: the IP layer collects fragments sharing (Source, Destination, Protocol, Identification), reassembles the original 1480-byte payload using each fragment's offset, and — only once all fragments have arrived — passes the reassembled datagram up to UDP using the Protocol field (17) to route it to the UDP module, which then delivers it to the process bound to the destination port inside the DNS query. If any single fragment is lost, the destination eventually times out reassembly and discards all fragments received so far — IP does not request retransmission of the missing piece; that is left entirely to whatever (if anything) sits above UDP. This example shows the header fields working together as a system: Identification and Fragment Offset exist specifically to make fragmentation and reassembly possible, TTL keeps decrementing independently of fragmentation, and the checksum must be recomputed at every point the header changes, including after fragmentation splits it into new headers.

Every router on the Internet — from a home Wi-Fi gateway to a core backbone router pushing hundreds of gigabits per second — implements exactly the forwarding logic sketched above: check the header, decrement TTL, look up the next hop, forward or fragment. Content delivery networks, cloud data centers, and mobile carrier networks all rely on IP's connectionless design to let traffic be rerouted instantly around failures without any per-flow renegotiation, since no router held connection state to begin with. Network diagnostic tools like `traceroute` and `ping` directly exploit the TTL field (sending datagrams with increasing TTL values to provoke "time exceeded" replies) and the header checksum mechanism to map paths and test reachability. Firewalls and routers inspect the Protocol field to distinguish TCP from UDP from ICMP traffic, and Quality-of-Service systems use the Type of Service byte to prioritize latency-sensitive traffic such as voice-over-IP. The entire architecture of the modern Internet — its ability to run over Ethernet, Wi-Fi, satellite links, and cellular data with no changes to the applications above — rests on the deliberately minimal service contract this header encodes.

Ask the tutor: How does Path MTU Discovery use the Don't Fragment flag to avoid IP fragmentation entirely?