IPv6: Motivation and Datagram Format

An IP address is the numeric identifier a host uses to be reachable on an internetwork; IPv4 encodes it in 32 bits, giving a theoretical maximum of 2³² ≈ 4,294,967,296 addresses. In practice usable space is far smaller once you subtract reserved ranges (private blocks like 10.0.0.0/8, loopback, multicast, and other special-use allocations). Combined with historically wasteful allocation — entire /8 blocks (16.7 million addresses each) handed to single organizations in the 1980s — the effective supply ran out much faster than the raw bit-count suggests. Address exhaustion is the structural depletion of unallocated IPv4 space by regional Internet registries, formally completed for the last major registries between 2011 and 2019.

IPv6 is the successor Internet Protocol standardized to eliminate this ceiling by widening the address field to 128 bits, a change specified in RFC 8200 (obsoleting the earlier RFC 2460). Because address length appears in the very first bits of the packet header, this single decision cascades into a full header redesign: fields that existed in IPv4 largely to manage fragmentation, options, and variable header length were reconsidered from scratch. The result is the IPv6 datagram format, a fixed 40-byte base header followed by an optional chain of extension headers, each identified by a "Next Header" field that plays the role IPv4's Protocol field played but generalizes it into a linked list of header types. A second, distinct idea completes the picture: because IPv6 cannot be deployed everywhere overnight, the Internet needs transition mechanisms — protocols and translation devices that let IPv4-only, IPv6-only, and dual-stack hosts communicate during the multi-decade migration. The three canonical strategies are dual stack (a host or router runs both protocols simultaneously), tunneling (IPv6 packets are encapsulated inside IPv4 packets to cross IPv4-only segments), and translation (a gateway rewrites IPv4 packets into IPv6 packets and vice versa, extending the logic of NAT to cross protocol versions rather than just address spaces).

Why IPv4 ran out: the arithmetic of exhaustion

IPv4 addresses are 32 bits, structured historically into classes (A, B, C) and later allocated via CIDR (Classless Inter-Domain Routing) in variable-size blocks written as `address/prefix-length`. The core problem is not merely that 4.3 billion is "too small" for billions of devices — it is that address blocks were allocated in large, inflexible chunks decades before efficient allocation practices (and NAT) existed, so huge swaths of address space sat unused inside organizations while the free pool at IANA shrank to zero. Once free pools hit zero, new networks could only obtain addresses via transfer markets or through techniques like NAT and Carrier-Grade NAT (CGN), which let ISPs share one public address among thousands of subscribers by rewriting port numbers.

The 128-bit address

An IPv6 address is written as eight groups of four hexadecimal digits separated by colons, for example: ``` 2001:0db8:85a3:0000:0000:8a2e:0370:7334 ``` Two shorthand rules keep this readable: 1. Leading zeros in each 16-bit group may be dropped: `0db8` → `db8`. 2. One run of consecutive all-zero groups may be replaced with `::` (used at most once per address, to avoid ambiguity). Applying both rules to the address above gives `2001:db8:85a3::8a2e:370:7334`. The address space, 2¹²⁸ ≈ 3.4 × 10³⁸ addresses, is often described informally as enough to assign roughly 6 × 10²³ addresses per square meter of the Earth's surface — the point is not precision but the fact that exhaustion under any realistic growth model is not a near-term concern. IPv6 addresses are typically structured as a 64-bit network prefix (assigned by providers, used for routing) plus a 64-bit interface identifier (often derived from the device's hardware MAC address via EUI-64, or randomized for privacy). This 64/64 split is a deliberate simplification: unlike IPv4's variable-length subnetting battles, IPv6 subnets are conventionally always /64, which drastically simplifies address planning and eliminates most subnetting arithmetic that trips up IPv4 network engineers.

The header redesign

IPv4's header is 20 bytes minimum but variable up to 60 bytes with options, and includes several fields that impose per-packet router work:

Three removals deserve emphasis because they explain most of the performance gain routers see with IPv6:

• No header checksum. IPv4 routers recompute the header checksum at every hop because the TTL field changes each hop, forcing a checksum update. IPv6 drops this entirely, relying on link-layer checksums (Ethernet CRC) and end-to-end transport checksums (TCP/UDP) to catch corruption. This is a deliberate layering argument: if the ends already verify correctness, redundant per-hop verification is wasted work on every router in the path.
• No in-network fragmentation. In IPv4, any router along a path may fragment a datagram that exceeds the next link's MTU — see IP Fragmentation and the TTL Field. IPv6 forbids this: only the source host may fragment, and it must first discover the path MTU (via ICMPv6 "Packet Too Big" messages) and fragment before sending. Routers that cannot forward an oversized packet simply drop it and send an error back to the sender. This removes a costly, stateful operation from the router's fast path entirely.
• Fixed-length header. IPv4's variable IHL field means a router must read the header length before it knows where the payload starts. IPv6's header is always exactly 40 bytes, so a router can jump straight to a known offset, simplifying hardware pipelining.

The IPv6 base header, field by field

``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address (128 bits) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address (128 bits) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ```

• Version (4 bits): always `0110` (6).
• Traffic Class (8 bits): analogous to IPv4's Type of Service; used for QoS/differentiated services marking.
• Flow Label (20 bits): a new field. Routers can use it, together with source/destination address, as a hash key to keep all packets of one flow on the same path without inspecting transport-layer ports — useful for load balancing and for keeping encrypted traffic's flow identifiable without decryption.
• Payload Length (16 bits): length of everything after the base header (extension headers + upper-layer data), in bytes. Unlike IPv4's Total Length, it excludes the header itself, since the header is always 40 bytes.
• Next Header (8 bits): identifies the type of the header immediately following — either an extension header (e.g., Hop-by-Hop Options, Fragment, Routing) or an upper-layer protocol (TCP = 6, UDP = 17), generalizing IPv4's Protocol field into a chain.
• Hop Limit (8 bits): decremented by each forwarding router; datagram is discarded when it reaches zero. Functionally identical to IPv4's TTL, renamed to reflect what it actually measures.
• Source / Destination Address (128 bits each): the enlarged addresses.

Extension headers as a linked list

Where IPv4 crammed optional features into a variable-length Options field inside the main header (forcing every router to at least check for options), IPv6 chains extension headers after the fixed base header, each carrying its own Next Header field pointing to the next one: ``` [ IPv6 base header ] -> Next Header = Routing [ Routing header ] -> Next Header = Fragment [ Fragment header ] -> Next Header = TCP [ TCP segment ] ``` A router that does not need to process a particular extension header (most routers only care about the base header and the final upper-layer protocol) can, in principle, skip past known extension header types using their fixed or self-declared lengths, without parsing their contents — keeping the router's fast path lean while still allowing sources to attach arbitrary optional metadata.

Pseudocode: forwarding logic contrast

The following pseudocode makes the router-side simplification concrete by contrasting the core forwarding decision loop for IPv4 versus IPv6. ``` // IPv4 router forwarding (simplified core loop) function forward_ipv4(packet): if packet.TTL == 0: send_icmp_time_exceeded(packet) drop(packet) return if not checksum_valid(packet.header): // must verify on every hop drop(packet) return packet.TTL = packet.TTL - 1 packet.header_checksum = recompute_checksum(packet.header) // must redo every hop next_hop, out_link = lookup_route(packet.dest_addr) if packet.length > mtu(out_link): if packet.flags.DF == false: fragments = fragment(packet, mtu(out_link)) // router does the work for f in fragments: send(f, out_link) else: send_icmp_frag_needed(packet) drop(packet) return send(packet, out_link)

// IPv6 router forwarding (simplified core loop) function forward_ipv6(packet): if packet.hop_limit == 0: send_icmpv6_time_exceeded(packet) drop(packet) return packet.hop_limit = packet.hop_limit - 1 // no checksum to verify or recompute — none exists in the header next_hop, out_link = lookup_route(packet.dest_addr) if packet.length > mtu(out_link): send_icmpv6_packet_too_big(packet, mtu(out_link)) // router never fragments drop(packet) return skip_extension_headers_if_unneeded(packet) // O(1) jump for the common case send(packet, out_link) ``` Two lines disappear entirely in the IPv6 version — checksum verification and checksum recomputation — and the fragmentation branch collapses from "fragment-or-signal" to "always signal, never fragment." Both changes remove per-packet, per-hop CPU work that scales with the size of the Internet's core routing infrastructure, which is exactly where such savings matter most.

Transition mechanisms

Because the base of Internet-connected devices cannot flip to IPv6 simultaneously, three interoperability strategies coexist: 1. Dual stack. A host or router runs both IPv4 and IPv6 stacks side by side. When communicating, it picks whichever protocol both endpoints support, typically preferring IPv6 (Happy Eyeballs algorithms in modern OSes race both and use whichever connects faster). This is conceptually simplest but requires every device and every hop to eventually support both stacks — expensive at global scale, and it does not by itself reduce IPv4 address consumption. 2. Tunneling. When an IPv6-capable segment needs to cross an IPv4-only network (or vice versa), the sending router encapsulates the IPv6 datagram whole, header and all, inside the payload of an IPv4 datagram, then the receiving tunnel endpoint strips the IPv4 wrapper and forwards the original IPv6 packet onward. This is exactly the encapsulation idea used for VPNs, generalized across protocol versions rather than across administrative domains. 3. Translation (e.g., NAT64/DNS64). A gateway rewrites packets between address families entirely, translating an IPv6 packet's header into an IPv4 header (and its 128-bit address into a 32-bit one via a mapping table) so an IPv6-only client can reach an IPv4-only server, and back again for the response. This extends the rewriting idea behind Network Address Translation (NAT) from "share one IPv4 address among many hosts" to "bridge two entirely different address families," at the cost of the same end-to-end transparency problems NAT already introduces (breaking protocols that embed IP addresses in payloads, complicating peer-to-peer connectivity, requiring per-flow state at the gateway). ``` function tunnel_encapsulate(ipv6_packet, tunnel_endpoint_ipv4_addr): ipv4_wrapper = new_ipv4_header() ipv4_wrapper.protocol = 41 // "IPv6 encapsulated in IPv4" ipv4_wrapper.dest_addr = tunnel_endpoint_ipv4_addr ipv4_wrapper.payload = ipv6_packet // entire IPv6 datagram, header included return ipv4_wrapper function tunnel_decapsulate(ipv4_packet): if ipv4_packet.protocol != 41: error("not a v6-in-v4 tunnel packet") return ipv4_packet.payload // recovers original IPv6 datagram unchanged ```

Address space sufficiency. IPv4 supplies at most 2³² ≈ 4.29 × 10⁹ addresses; even under the generous assumption that every allocated address is fully utilized, this cannot uniquely address a world with tens of billions of networked devices plus redundant addressing needs (multiple interfaces per host, subnetting overhead, reserved ranges). IPv6 supplies 2¹²⁸ ≈ 3.4 × 10³⁸ addresses — a factor of roughly 2⁹⁶ (about 7.9 × 10²⁸) more than IPv4. Even reserving huge fractions of this space for hierarchical routing aggregation (which IPv6 does deliberately, unlike IPv4's historically ad hoc allocation), the remaining usable space vastly exceeds any addressing demand extrapolated from current device growth trends. This is not a probabilistic argument, it is a counting argument: the exhaustion problem is solved by brute enlargement of the identifier space, not by cleverer reuse.

Per-hop processing cost. Consider a router forwarding $n$ packets per second, sustained. In IPv4, each packet requires:

• one checksum verification, $O(L)$ in header length $L$ (typically 20–60 bytes), and
• one checksum recomputation after decrementing TTL, also $O(L)$.

In IPv6, both operations are $O(0)$ — they simply do not exist in the base header path. Removing a constant per-packet cost does not change asymptotic big-$O$ complexity of "forward $n$ packets" (both are $O(n)$ in the number of packets), but it materially reduces the constant factor per packet, which is exactly what matters for line-rate router hardware operating in the nanoseconds-per-packet regime. At core-router scale (hundreds of millions of packets per second), even a small constant-factor reduction per packet is the difference between a design that fits in a hardware fast path and one that needs software fallback.

Fragmentation cost shift. In IPv4, a router performing fragmentation must: split the payload into MTU-sized pieces, replicate and adjust the header for each fragment (recomputing Total Length, Fragment Offset, Flags, and the checksum for each piece), and potentially cause reassembly failures or performance cliffs at the destination if fragments are lost or reordered — this is exactly the fragmentation machinery discussed in IP Fragmentation and the TTL Field. IPv6 moves this entire cost to the sender: the source must perform Path MTU Discovery (send progressively, react to ICMPv6 "Packet Too Big" messages, cache the discovered MTU per destination) before transmitting oversized data. The total work done to deliver oversized data does not vanish — someone must still fragment it — but it is relocated from every router along the path (an $O(\text{path length})$ multiplier on fragmentation cost in the worst case, since a packet could theoretically be refragmented at each hop under old IPv4 semantics) to a single point, the sender, performing it once. This is a genuine efficiency win for the shared network core, traded for extra state (an MTU cache) and one additional round trip's worth of latency at the sender when MTU is first discovered.

Correctness of the extension header chain. The key invariant maintained by the Next Header linked-list design is: at every point in the header chain, the current header unambiguously determines the type and, where necessary, the length of the header that follows. This lets a router (or host) walk the chain safely: ``` function parse_headers(packet): offset = 40 // base header is always exactly 40 bytes next_type = packet.base_header.next_header while next_type is an extension header type: ext = read_header_at(packet, offset) next_type = ext.next_header offset = offset + ext.length_in_bytes() // self-describing length // next_type now names the upper-layer protocol (TCP=6, UDP=17, ...) return offset, next_type ``` Termination is guaranteed because each extension header type has a well-defined, computable length (either fixed by specification or self-declared via a length field inside the header), so `offset` strictly increases each iteration and the loop cannot run past the packet's actual size without hitting a terminal upper-layer Next Header value or the end of the payload — the same "walk a chain until you hit a known terminator" invariant that underlies any linked-list traversal.

Honest tradeoffs. IPv6 is not strictly superior in every dimension. The 128-bit addresses roughly double the per-packet header overhead compared to IPv4's 32-bit addresses even before counting other field changes (40 bytes minimum versus 20 bytes minimum), which matters for very small packets (VoIP, IoT telemetry) where header-to-payload ratio affects effective throughput. Extension header chains, while elegant, complicate middlebox processing (a firewall wanting to see the transport-layer port must walk the whole chain, which is more work than reading a fixed offset in IPv4) — this has led some real-world middleboxes to drop packets with unfamiliar extension headers as a security-conservative default, a practical deployment headache the original design did not fully anticipate.

Trace a single web request — a client at address `2001:db8:1::10` fetching from a server at `2001:db8:2::80` over TCP, with the packet passing through two intermediate routers, R1 and R2, where R2's outbound link has a smaller MTU than the packet.

What the trace demonstrates. The IPv4 path appears to succeed faster on the first send (no round trip needed) but pushes fragmentation-and-reassembly work onto R2 and the server, work repeated on every oversized flow through that router for every affected packet. The IPv6 path costs one extra round trip on the very first oversized packet (the ICMPv6 error) but after that the client's Path MTU cache means every subsequent packet is correctly sized before it ever reaches R2 — R2 does zero fragmentation work for the remainder of the connection. For a long-lived flow (e.g., a large file transfer or a persistent connection), the amortized cost strongly favors IPv6's design: one discovery round trip versus per-packet, per-router fragmentation overhead for the flow's entire duration. A second short trace shows address compression in practice. A router's routing table stores the server's network as the prefix `2001:0db8:0002:0000::/64`. Written in compressed form (drop leading zeros in each group, collapse the longest run of all-zero groups to `::`): ``` 2001:0db8:0002:0000:0000:0000:0000:0000/64 → drop leading zeros per group: 2001:db8:2:0:0:0:0:0/64 → collapse the run of all-zero groups: 2001:db8:2::/64 ``` The client address `2001:db8:1::10` matches a different /64 prefix (`2001:db8:1::/64`), so R1 and R2 must consult a longest-prefix-match routing table exactly as in IPv4 — the address width changed, but the fundamental forwarding lookup mechanism (longest prefix match), a topic developed further under Routing Algorithms: The Graph Abstraction, is unchanged in spirit.

The transition from IPv4 to IPv6 was less the work of a single inventor than a sustained standards effort by the Internet Engineering Task Force (IETF) once address exhaustion became foreseeable in the early 1990s. Steve Deering is generally credited as the primary architect of what became IPv6 (originally called "SIPP," Simple Internet Protocol Plus, one of several competing proposals evaluated by the IETF's IPng — "IP: The Next Generation" — process).

Every major operating system (Windows, macOS, Linux, Android, iOS) ships dual-stack networking by default, silently preferring IPv6 when both the local network and the remote server support it — this is why "IPv6 test" websites report large fractions of mobile traffic already using IPv6 even though most users are unaware of the protocol underneath. Mobile carriers, facing the largest device-growth pressure of any access network, were among the earliest large-scale adopters, commonly deploying IPv6-only radio access networks paired with NAT64/DNS64 translation gateways so phones can still reach the IPv4-only remainder of the web. Content delivery networks and hyperscale cloud providers (serving a large fraction of global web traffic) have supported IPv6 for years, meaning a client with a working IPv6 path often reaches popular destinations without ever touching IPv4 or a NAT device at all. Home routers increasingly run dual stack out of the box, tunneling IPv6 over an ISP's IPv4-only last-mile infrastructure via mechanisms like 6rd or DS-Lite where native IPv6 delivery isn't yet available. Understanding the header format and transition mechanisms described here is prerequisite background for network engineers configuring routing policy, for security teams writing firewall rules that must correctly parse extension header chains, and for anyone studying how Routing Algorithms: The Graph Abstraction computes paths across a network that, in practice, is really two overlapping networks in the middle of a decades-long handover.

Ask the tutor: How does Path MTU Discovery actually work step by step when an IPv6 sender's first packet is too large for the path?