IPv6: the internet's present address plan

IPv6 does the same job as IPv4. It carries packets between networks, it is routed hop by hop, and it makes no promise that any individual packet arrives. The change is the size of the address: 32 bits became 128 bits. Every other difference in this module follows from that one decision.

Because 128 bits would be unreadable in the dotted decimal style of an IP address in IPv4, IPv6 is written in hexadecimal: eight groups of four hex digits, separated by colons. Written out in full, an address looks like 2001:0db8:0000:0000:0000:0000:0000:0001. Nobody writes them that way, because two shortenings are allowed. Leading zeros inside a group may be dropped, so 0db8 becomes db8. One run of consecutive all-zero groups may be replaced by a double colon. Apply both and the same address reads 2001:db8::1.

The double colon may appear only once in an address, and the reason is worth understanding rather than memorising. The reader of an address works out how many zero groups the double colon stands for by subtracting the groups that are written from eight. With two double colons in one address there would be no way to tell how many of the missing groups belonged to each, so the address would have more than one valid reading. One is unambiguous; two is a guess.

That is the whole of the notation. The pay-off is what the extra bits do to the behaviour of the people who run networks. Under IPv4, address space was scarce enough to become an asset in its own right: something to be requested, justified, conserved, audited, reclaimed from a team that had stopped using it, and shared between many devices by rewriting packets in flight. Long-lived working practices grew up around that scarcity, and so did a good deal of internal politics.

The design goal of a 128-bit address was to make addresses boring. When a site can have as many addresses as it can think of uses for, nobody competes for them, nobody conserves them, and the interesting questions move back to where they belong: routing, naming, and who is allowed to reach what. An address plan under IPv6 is a piece of documentation design rather than a rationing exercise.

Reading the notation is only half of reading an address. The other half is knowing where the 128 bits split, because the split is what tells you which part identifies the segment and which part identifies the machine sitting on it.

Every ordinary IPv6 segment is a /64. The first 64 bits are the network prefix, the last 64 bits are the interface identifier. In 2001:db8:4a3c:12::5c on a /64, the prefix is 2001:db8:4a3c:12::/64 and the identifier is the part after it. The prefix length is written in the same CIDR notation you already use for IPv4, and it means exactly the same thing: this many leading bits are the network.

The /64 is not an arbitrary convention. It is what the default address configuration mechanism needs in order to work. Under stateless address autoconfiguration, specified in RFC 4862, a host builds its own global address by taking the prefix a router advertises on the link and appending a 64-bit identifier of its own. Advertise anything narrower than a /64 on a segment carrying ordinary hosts and there is no room for the identifier, so the hosts on that segment stop configuring themselves. The rule exists because of the mechanism, and it is the mechanism, not tradition, that you would be arguing with.

This inverts the arithmetic taught in the previous module. In IPv4 you sized a subnet by counting the hosts you expected, choosing the smallest prefix that held them with a little headroom, and then defending the addresses you had left over. Under IPv6 that calculation does not exist. Every segment is the same size, and the size is far larger than any segment will use. What you allocate instead is segments.

A site is typically given a /48 by its provider, and the design work is cutting /64s out of it. Between bit 48 and bit 64 there are sixteen bits of subnet identifier, which is far more segments than a single site will ever number. Because the space is not scarce, the only sensible way to use it is to make it readable: give each site, building, floor or function a block that a person can recognise on sight, leave wide gaps between blocks, and never pack the allocation tightly to save space you are not short of. A prefix you can read in a firewall log without opening a spreadsheet is worth more than a prefix that wastes nothing.

There is one honest exception worth knowing so that real output does not surprise you. Links that carry only two routers and no ordinary hosts have nothing doing stateless autoconfiguration on them, so operators commonly number those with something much narrower than a /64. If you meet one in a routing table, it is not a mistake. Every link where hosts live is a /64.

One thing that does carry over from IPv4 unchanged is the warning at the end of the previous module: a /64 boundary is a delivery boundary, not a security boundary. Two devices on the same /64 reach each other directly, whatever the policy on the router says, and a device that moves between segments changes its prefix without changing what it is allowed to do.

Knowing where the address splits raises the obvious question of who fills in each half. The prefix comes from the router. The identifier is where IPv6 behaves quite unlike the network most people learned on.

An IPv6 host does not wait for a server to give it an address. It configures the first one for itself the moment the interface comes up, and it can reach the rest of the segment before anything on the network has been consulted.

The sequence in RFC 4862 is short. When an interface is enabled, the host forms a link-local address by combining the well-known link-local prefix, fe80::/10, with an interface identifier. Before using it, the host checks that nobody else on the link already holds it, a step called duplicate address detection. It then listens for router advertisements. If a router is present and advertising a prefix, the host combines that prefix with its identifier and now holds a global address as well. No server was asked, and no server holds a record of the result.

The link-local address stays for the life of the interface, and it is not decoration. The signalling that hosts and routers use to find each other on a segment, which IPv6 calls neighbour discovery, runs over link-local addresses rather than global ones, and so do the router advertisements themselves. An interface showing only an fe80:: address is therefore not automatically faulty. It is a host that has configured itself correctly and heard no router advertisement, which is a statement about the segment rather than about the host.

The identifier half is a choice, not a fact about the hardware. A host may derive it from its MAC address, generate it at random, or rotate it periodically for privacy. Rotation is now normal client behaviour, which is why a laptop routinely shows several global IPv6 addresses at once and why an address is a weak identifier for anything you intend to audit. Pin identity to the device or the user, not to the number in the log line.

DHCPv6, specified in RFC 8415, is the mechanism for the cases where self-configuration is not what the organisation wants. A DHCPv6 server can hand out addresses and prefixes and keep a record of which client holds what, which is what a regulated estate usually needs, and it can supply settings such as resolver addresses whether or not it is supplying addresses at all. That last point is the source of a common and confusing fault: a host can hold a perfectly valid global address obtained by autoconfiguration and still resolve no names at all, because addressing and resolver configuration arrived, or failed to arrive, by different routes.

The choice between them is a management question rather than a technical one. Use stateless autoconfiguration where you want segments that work with no dependency to fail, which covers most user networks. Use DHCPv6 where somebody has to be able to answer "which device held this address at 14:20 on Tuesday" from a record rather than an inference. Many estates run both, and the failure mode above is what happens when nobody wrote down which one supplies which piece.

The last address type you need to recognise is the site-internal one. Unique local addresses come from the fc00::/7 range that RFC 4193 sets aside, and the half of that range defined for local assignment is why these addresses start with fd in real output. They are built around a randomly chosen identifier, so two organisations that later merge are very unlikely to find their internal ranges clashing, which is exactly the problem that private IPv4 addressing created at every acquisition. Routers on the public internet are expected to ignore them.

That makes unique local addressing the nearest IPv6 analogue of private IPv4 space, and it is important to be precise about how far the analogy goes. It is a scoping decision. It says where an address is meaningful. It does not say who may connect to it, and it is not a substitute for a firewall.

Autoconfiguration gives every host a global address that is valid anywhere on the internet. To an engineer trained on private addressing behind a translator, that sounds like the removal of a defence, and it is worth settling what was actually being defended.

IPv6 gives every device an address that works end to end, with nothing rewriting it in flight. Default-deny for unsolicited inbound traffic still exists. It comes from a stateful firewall applying a written policy, which is where it should have been coming from all along.

Start with what network address translation actually does, because the security reputation it enjoys is a side effect rather than a purpose. A translating router rewrites addresses and ports so that many internal devices share one public address, and it keeps a state table mapping each outbound conversation to the translated address and port it went out as. A packet arriving from outside is forwarded only if it matches an entry in that table. Unsolicited inbound traffic is dropped because there is no entry to match it against, not because anyone wrote a rule saying it should be.

Once that is clear, the IPv6 design reads differently. Removing translation removes address sharing and the state table that made it work. It does not remove filtering, because filtering was never the same function. An IPv6 edge firewall holding state on outbound flows and dropping unsolicited inbound gives you precisely the behaviour the translator gave you, with two differences that both favour IPv6: the behaviour is written down as policy you can read, review and test, and it can be changed for one service without breaking the addressing of everything else.

The other thing you get back is evidence, and this is the part that matters most for the troubleshooting work later in the course. Behind translation, a log entry at the far end names the shared public address of a whole office, so answering "which machine did this" means correlating timestamps against translation logs that may or may not have been kept. With global addressing the log line names the host. The same is true in reverse: a support engineer can be given an address and reach the actual device, rather than negotiating a port-forwarding rule that has to be maintained by somebody who has left.

None of this means translation disappears from your working life. It is still how most IPv4 access is delivered, and the applied stage takes the full argument apart in the module on NAT and state, including the machinery that lets IPv6-only networks still reach IPv4-only services.

Global addressing, self-configuring hosts and a firewall doing the filtering describe how IPv6 is meant to work. Whether it is actually working at that scale yet is a question of measurement, and measurement is where most confident statements about IPv6 fall apart.

Two independent measurements settle the question of how far along this is, and the gap between them is the lesson. Google's public IPv6 statistics page recorded 50.10 percent of its worldwide users arriving over IPv6 on 28 March 2026. APNIC Labs, measuring a different population in a different way, puts global IPv6 capability at 42 to 43 percent, with India and France both above 70 percent. The APNIC figure is a rolling one rather than a fixed reading, so quote it from the page on the day you use it rather than from memory.

The two sources disagree by several points, and neither of them is wrong. Google is reporting the users who arrive at Google properties, seen from Google's own servers. APNIC Labs is estimating whether end users are capable of IPv6 at all, by running a measurement from a sample of users across the internet and weighting the results by how many users each economy actually has, because the raw sample is not spread evenly. Different populations, different vantage points, different questions, therefore different answers.

That habit has a name worth keeping: measurement literacy. Quote a network statistic with its source, its method and its date, or do not quote it. A figure repeated without those three is untraceable within a week, and adoption figures in particular are quoted years after the measurement that produced them. When somebody tells you IPv6 adoption is at some number, the useful reply is to ask who was counted.

The averages also matter less than they look, because no organisation serves the global average. If your users are in India, the relevant figure is above 70 percent and an IPv4-only service is a visible handicap. If your users are on one corporate network in one country, the relevant figure is whatever that network does, which you can find out directly rather than inferring from a worldwide chart. Both Google and APNIC publish their figures broken down by country, which is the level at which a decision gets made.

What sits behind those percentages, almost everywhere, is dual-stack operation: hosts and networks running IPv4 and IPv6 at the same time, with both usable, and the application choosing per connection. Clients do not choose naively. A modern client resolves a name, gets answers in both families, and starts an attempt on one while holding the other in reserve for a short delay, a behaviour usually called Happy Eyeballs. Whichever family answers first wins the connection.

That politeness is the operational trap of the whole transition. A broken IPv6 path does not produce an error anybody reports. It produces a small extra delay on every connection and then a successful IPv4 connection, so the service looks healthy from the outside and slightly sluggish from the inside, for months. Dual-stack doubles the number of paths that can fail and halves the chance that a failure announces itself, which is why testing has to name the family explicitly instead of trusting that the page loaded.

Running both families indefinitely is not the destination either, because it means paying to operate two internets. The applied stage covers the mechanisms that let a segment start retiring IPv4 while keeping the devices that still need it, which is the approach usually called an IPv6-mostly network. The operational guidance describing it is an Internet-Draft rather than a published RFC, which is a distinction the frontier modules take seriously and you should too.

Notation, the /64 split, the two ways a host is configured, the missing translator and the published figures are each straightforward on their own. They arrive together, and unannounced, as a few lines of interface output that have to be read correctly before anything else about a fault can be worked out.