IPv6 · Computer Networking Interactive

A new version of the Internet Protocol with four times the address and a simpler header — and the hardest part turned out to be persuading anyone to use it.

Words you will meet

IPv6 (Internet Protocol version 6) — 128-bit addresses, a fixed 40-byte header .
Hop limit — IPv4 (Internet Protocol version 4) ‘s time-to-live, renamed to say what it counts.
Next header — what the payload is. Options are now one of the possibilities.
Anycast address — deliver this to any one of a group of hosts.
Flow label — 20 bits saying this datagram belongs to a particular flow.
Tunnelling — carrying one protocol inside another to cross unfriendly ground.
Flag day — a date on which everything is switched over at once. Not possible here.

Why this matters

In the early 1990s it became clear that the 32-bit address space was running out. New subnets and nodes were being attached at a breathtaking rate, and the IETF (Internet Engineering Task Force) began work on a successor.

The estimates of when addresses would be exhausted, made by the two leaders of the IETF’s Address Lifetime Expectations working group, were 2008 and 2018. In the event, IANA (Internet Assigned Numbers Authority) allocated the last remaining pool of unassigned IPv4 addresses to a regional registry in February 2011.

But this section’s real lesson is not about addresses. It is the sentence the book ends on: it is enormously difficult to change network-layer protocols. Section 3.8 already showed the other side of that coin, when QUIC (Quick UDP Internet Connections) put a transport protocol in the application layer precisely so it could be changed. This is why.

The datagram

Figure 4.26 — the IPv6 datagram

Click any box to read what that part of the message is for.

Every field, as text

Version — 4 bits — which IP this is (example: 6)
Traffic class — 8 bits — priority (example: 0x00)
Flow label — 20 bits — this datagram belongs to a flow (example: 0x00000)
Payload length — 16 bits — bytes after the header (example: 1440)
Next header — 8 bits — what the payload is (example: 6)
Hop limit — 8 bits — how many more routers (example: 64)
Source address — 128 bits — who sent it (example: 2001:db8::1)
Destination address — 128 bits — where it is going (example: 2001:db8::7)

Forty bytes, fixed, always. Compare it with Figure 4.17 in section 4.3.1: the address fields are four times larger and the header is only twice the size, because so much else was removed.

The three changes the book puts first

Expanded addressing. From 32 bits to 128. That is not four times as many addresses — it is 2⁹⁶ times as many. The book’s line: every grain of sand on the planet can be IP-addressable.

It also adds a third kind of address. Alongside unicast and multicast there is now anycast, which delivers a datagram to any one of a group of hosts. The book’s example is sending an HTTP (HyperText Transfer Protocol) GET to the nearest of several mirror sites.

A streamlined 40-byte header. Fixed length, always. A number of IPv4 fields were dropped or made optional, and the result allows faster processing at a router.

Flow labelling. Twenty bits identifying a flow. The book admits the definition is elusive. RFC (Request For Comments) 2460 says it permits “labeling of packets belonging to particular flows for which the sender requests special handling, such as a non-default quality of service or real-time service”. Audio and video might be a flow; file transfer and e-mail might not. What is clear is that the designers foresaw needing to distinguish flows even though nobody had yet settled what a flow was.

What was removed, and why it is always the same reason

IPv4 against IPv6

	IPv4RFC 791, 1981	IPv6RFC 2460 / RFC 4291
Address size
Header size
Fragmentation at routers
Header checksum
Options
Flow label
Address kinds

Cells marked ⓘ have a reason behind them — click to read it.

Four rows are removals, and every one of them was removed for the same reason. Click any cell.

In plain words

Read the removals together and one motive runs through all of them: make a router’s per-packet work smaller.

Fragmentation is a time-consuming operation. Removing it from routers and placing it squarely in the end systems considerably speeds up forwarding.
The header checksum had to be recomputed at every hop, because the time-to-live changed. Removing it removes that work — and the transport and link layers already checksum, so it was judged redundant.
Options made the header variable-length, so processing time varied and nothing knew in advance where the data began.

Section 4.2.1 measured the budget: 5.12 nanoseconds for a 64-byte datagram on a 100 Gbps link. Every one of these removals is that number being taken seriously.

Options did not disappear — they moved

This is the neat part. An options field is no longer part of the standard header, but the capability survives: options became one of the things the next-header field can point to.

Just as the next header can be TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) , it can be an options header, which in turn names its own next header. A router that does not care about the options skips straight past, and the base header stays a fixed 40 bytes.

Compare what IPv4 forced: because any datagram might carry options, every router had to be prepared to parse a variable-length header on every datagram. IPv6 moves the cost onto the datagrams that actually use the feature.

What happens now when a datagram is too big

IPv4: the router fragments it. Section 4.3.1 works the example.

IPv6: the router drops it and sends a “Packet Too Big” ICMP (Internet Control Message Protocol) error back to the sender, which resends the data in a smaller datagram. Section 5.6 covers ICMP.

That is path MTU (maximum transmission unit) discovery made mandatory rather than optional — the mechanism section 4.3.1 described as the modern answer. IPv6 does not offer the old answer at all.

Getting there from here

The technical part is finished. The practical question is harder: how does an Internet built on IPv4 become one built on IPv6?

The difficulty is asymmetric. New IPv6-capable systems can be made backward-compatible — they can send, route and receive IPv4 datagrams. But already-deployed IPv4 systems cannot handle IPv6 datagrams, and there are billions of them.

Why there was no flag day

One option would be a flag day: a given time and date when every machine on the Internet is turned off and upgraded.

It has been done. The transition from NCP (Network-Control Protocol) to TCP (Transmission Control Protocol) happened on 1 January 1983, and chapter 1.7 covers it.

But even then, when the Internet was tiny and administered by a small number of “wizards”, [RFC 801] recognised that a flag day was barely possible. A flag day involving billions of devices is unthinkable.

Note what this means. The 1983 flag day was not a precedent — it was the last moment such a thing could ever have happened.

Tunnelling

The approach most widely adopted in practice.

Figure 4.27 — tunnelling IPv6 through IPv4

1 — The problemstep 1 of 4

B and E want to interoperate using IPv6 datagrams. Between them sit routers that understand only IPv4. An IPv6 datagram sent into C would be unintelligible — and C cannot be upgraded, because there are billions of such routers and no flag day is possible.

B and E speak IPv6. Everything between them speaks only IPv4. Step through and watch what the middle routers think they are carrying.

Read all steps as text

1 — The problem — B and E want to interoperate using IPv6 datagrams. Between them sit routers that understand only IPv4. An IPv6 datagram sent into C would be unintelligible — and C cannot be upgraded, because there are billions of such routers and no flag day is possible.
2 — B puts the whole IPv6 datagram inside an IPv4 one — The entire IPv6 datagram — header and all — becomes the payload field of an IPv4 datagram. Nothing is translated and nothing is lost.
3 — The IPv4 datagram is addressed to E, the far end of the tunnel — Not to F, the ultimate destination — to E. From C and D’s point of view this is an ordinary IPv4 datagram going to an ordinary IPv4 address, and they forward it by the ordinary rules.
4 — E unwraps it — E is the destination of the IPv4 datagram, so it receives it. The protocol field says 41, which means the payload is an IPv6 datagram. E extracts it and routes it onward exactly as if it had arrived from a directly connected IPv6 neighbour.

In plain words

The intervening set of IPv4 routers between two IPv6 routers is called a tunnel. The sending end puts the entire IPv6 datagram into the payload field of an IPv4 datagram, addressed to the router at the far end of the tunnel.

The routers in between forward it as they would any other IPv4 datagram, blissfully unaware that it contains a complete IPv6 datagram. The far end receives it, notices that the protocol field is 41 — meaning the payload is an IPv6 datagram — extracts it, and carries on.

The idea generalises well beyond this problem, and the book says so: tunnelling is used widely in the all-IP cellular networks of chapter 7.

The lesson the book draws, and it is the big one

One important lesson that we can learn from the IPv6 experience is that it is enormously difficult to change network-layer protocols.

Since the early 1990s, numerous new network-layer protocols have been announced as the next major revolution. Most have had limited penetration: IPv6, multicast protocols, resource reservation protocols.

The book’s image is exact:

Introducing new protocols into the network layer is like replacing the foundation of a house — it is difficult to do without tearing the whole house down, or at least temporarily relocating the residents. On the other hand, the Internet has witnessed rapid deployment of new protocols at the application layer. Introducing new application-layer protocols is like adding a new layer of paint — relatively easy to do, and if you choose an attractive colour, others in the neighbourhood will copy you.

The classic application-layer examples are the Web, instant messaging, streaming media, distributed games and social media. All arrived, spread and in some cases disappeared while IPv6 was still being deployed.

This is the argument section 3.8 was making from the other end. QUIC put a transport protocol into the application layer because of this. Its authors could change it at the speed of a browser update rather than the speed of an operating-system upgrade — and IPv6 is what happens when you cannot.

Check yourself

0 of 7 answered

1.predictIPv6 addresses are four times as long as IPv4's. How many times as many addresses is that?
2.IPv6 drops the header checksum. Why was that judged safe?
3.predictAn IPv6 datagram reaches a router and is too big for the outgoing link. What happens?
4.IPv6 has no options field. Have options gone away?
5.predictIn Figure 4.27, what address is on the IPv4 datagram that crosses the tunnel?
Not the ultimate destination.
6.How does the far end of a tunnel know the IPv4 payload is an IPv6 datagram?
7.The book compares changing the network layer to replacing a house's foundation, and changing the application layer to painting it. What follows from that?

What to remember

128-bit addresses and a fixed 40-byte header. That is twice IPv4’s size while carrying four times the address. So much else was removed: no fragmentation at routers, no header checksum, options moved to a “next header”.
Every one of those removals is about a router’s per-packet time budget.
Changing the network layer is like replacing a foundation; changing the application layer is like painting. That single comparison explains both IPv6’s pace and QUIC’s existence.