Deep down, the three previous lessons tell one and the same story: IPv4 became too small and the industry kept it alive through ingenuity (CIDR, private addresses, NAT). This lesson introduces the real solution: IPv6, the version of the IP protocol designed so that addresses never run short again — and, along the way, to remove the NAT patch and give every device back its status as a full endpoint of the network. IPv6 is not futurology: more than half the traffic toward the big Internet services already rides on it, your phone probably uses it daily, and Meridiano's machines already have IPv6 addresses even though nobody configured them. Here you will learn to read and abbreviate its addresses, to recognize its address types, and to understand how they autoconfigure and how IPv6 coexists with IPv4.

1. Why IPv6 exists: the real exhaustion and the limits of the patch
2. Anatomy of an IPv6 address: 128 bits in 8 hexadecimal groups
3. Abbreviation rules: leading zeros and the :: operator
4. Address types (and the death of broadcast)
5. The /64 prefix and the end of painful subnetting
6. Autoconfiguration: SLAAC versus DHCPv6
7. Coexistence with IPv4: dual stack (and what tunnels and NAT64 are)
8. IPv6 at Meridiano: what is already there and what turning it on would involve

Module recap: IPv4 offers 2³² ≈ 4.3 billion addresses; IANA handed out the last free block in 2011 (lesson 05-01) and today public IPv4 addresses are bought, leased and rationed. NAT (lesson 05-03) made survival possible by sharing addresses, but at a price: broken inbound connections, layers of workarounds for P2P and video calls, CGNAT stacking translations, and the loss of module 4's end-to-end principle.

The IETF saw the problem coming in the 1990s and designed IPv6 with one radical decision: 128-bit addresses. The resulting math:

The goal is not just "enough for everyone" but surplus for everyone: with extreme abundance, every device gets its own public address, the need for NAT disappears, and network design gets simpler (as you will see with the /64). IPv6 keeps the IP philosophy you know — best effort, packets, TTL (renamed Hop Limit), the same layer 3 of the model — but changes the address format, simplifies the header and replaces auxiliary mechanisms (ARP and broadcast among them).

With 128 bits, dotted decimal notation would be unmanageable (16 numbers from 0 to 255). IPv6 uses hexadecimal: the 128 bits are split into 8 groups of 16 bits, each group written as 4 hex digits (0–9, a–f), separated by colons:

Quick hexadecimal refresher: each hex digit maps to exactly 4 bits (0=0000, 9=1001, a=1010, f=1111). That is why it fits so well: a group of 4 hex digits is a clean 16 bits, none of IPv4's conversions with remainders. The prefix is expressed just like in CIDR: 2001:db8:acad:10::/64 means "the first 64 bits identify the network".

Conventions you will always see:

• Lowercase (db8, not DB8) — it is the recommended canonical form.
• The 2001:db8::/32 range is reserved for documentation (like the 203.0.113.x we used with NAT): every example in this course uses it.
• In URLs, the address goes in square brackets because of the clash with the port's :: https://[2001:db8::10]:443/api/proyectos.

IPv6 addresses are full of zeros, and there are two rules for not writing them. They are the only two rules, and mastering them is the basic IPv6 reading skill.

Rule 1 — Drop leading zeros within each group (but each group keeps at least one digit):

Rule 2 — Compress, ONCE only, the longest run of consecutive all-zero groups with :::

The "once only" restriction is no whim: with two ::s it would be impossible to know how many zeros each one hides, and the address would be ambiguous.

Worked compression example (two runs of zeros — the longer one gets compressed):

Worked expansion example (the reverse path, essential for comparing addresses):

That last warning is the classic trap: db8:20 means 0db8:0020. The zeros you restore when expanding always go in front of the digits, never behind.

In IPv6 an interface does not have one address: it has several at once, each with a scope. The types you must recognize:

Two important ideas:

• Every IPv6 interface has an auto-generated fe80::… link-local address, with no server and no configuration whatsoever. It is not an error symptom like APIPA: it is mandatory by design, and the neighbor protocols and routes run on top of it (a machine's IPv6 gateway is usually the router's link-local).
• Broadcast is dead. IPv6 has no shout-to-everyone address: it uses multicast aimed at specific groups. Where IPv4 shouted at the whole network (module 2's ARP at layer 2, the DHCP DISCOVER to 255.255.255.255), IPv6 asks only the interested parties: the NDP protocol (Neighbor Discovery Protocol, over ICMPv6) replaces ARP using targeted multicast — each node listens on a small group derived from its own address, and the rest never even wake up. Less noise on the network, same result.

IPv6's universal convention: every subnet is a /64. The 128 bits split into two fixed halves:

Life-changing consequences compared with lesson 05-02:

• Each subnet has 2⁶⁴ addresses (18 quintillion). You will never calculate "how many hosts fit": they all fit. There is no 2^h − 2, no usable range to size, no broadcast address to reserve (it no longer exists).
• Subnetting does not disappear, but it stops hurting. The ISP hands an organization a large prefix — typically a /48 or /56 — and subnetting is simply enumerating /64s inside it, with no host counts and no jumps:

Note the style detail: the subnet group can be made to match the VLAN or site number, and since hex aligns with the bits 4 at a time, "pretty" boundaries (per digit) are the natural ones. Compared with calculating jumps of 32 and usable ranges on Valencia's /24, the IPv6 plan can be written on a napkin. The 05-02 skill is not lost: the prefix/host logic is the same; only the scarcity and the fine arithmetic disappear.

In IPv4, an unconfigured machine depends on DHCP and its DORA exchange (module 2 — we won't repeat it here). IPv6 adds an alternative that does not exist in IPv4: the machine configuring itself by listening to the router.

SLAAC (StateLess Address AutoConfiguration):

1. The router periodically (and on demand) advertises the subnet's prefix through RA messages (Router Advertisement, part of NDP): "this network is 2001:db8:acad:10::/64 and I am the way out".
2. The machine takes the prefix and generates its own 64-bit interface identifier (historically derived from the MAC in the EUI-64 format; today, for privacy, stable random identifiers plus rotating temporary addresses are preferred).
3. The machine verifies with NDP that nobody is already using that address (DAD, Duplicate Address Detection) and starts working. Gateway included: the link-local of the router that sent the RA.

Nobody maintains a lease table: hence "stateless". Comparison with what you know:

In practice they coexist: the router's RA carries flags telling clients "autoconfigure with SLAAC", "ask a DHCPv6 server for the details (e.g. DNS)" or both. For a network like Meridiano's, SLAAC + DNS in the RA would cover the workstations; DHCPv6 would be the option if IT wanted a central address registry like the one DHCP gives it today.

IPv6 is not backward compatible with IPv4: an IPv6-only node cannot talk to an IPv4-only one. Since the transition spans decades, there are coexistence strategies:

• Dual stack — the recommended strategy and the one you will encounter: each machine has IPv4 and IPv6 addresses at the same time, and each connection uses one or the other. Who decides? DNS resolution: if the name has an AAAA record (IPv6 address) and an A record (IPv4), the system tries IPv6 preferentially and falls back to IPv4 if it doesn't respond (the happy eyeballs mechanism, which races both so the user never pays the penalty). Cost: you administer two addressing planes in parallel — double configuration, double firewall, double diagnosis.
• Tunnels (a mention): encapsulating IPv6 packets inside IPv4 to cross stretches that don't speak IPv6 yet. Historically useful (6in4, 6rd); residual today.
• NAT64/DNS64 (a mention): lets IPv6-only networks reach servers still on IPv4 only, translating protocols at the border. This is how many mobile networks operate: your phone is IPv6-only and you never notice. Ironic but transitional: IPv6 gets deployed and another NAT appears — until the last IPv4 server migrates.

What is already there, without anyone lifting a finger. If Marta runs ip addr (or ipconfig) on her PC today, next to her IPv4 she will see something like this:

That inet6 fe80::…/64 scope link line is the mandatory link-local: the operating system generated it on its own (in this case from the MAC 5c:26:0a:4b:91:d3 with the old EUI-64 method — hence the resemblance; Windows and modern Linux systems usually use random identifiers). Jon would see the equivalent in Bilbao. With it, machines on the same link could already talk IPv6 to each other (ping fe80::…%eth0 — the %eth0 says through which interface, since link-locals repeat on every link). What they do not have is a global address or IPv6 access to the Internet: no router is advertising prefixes.

What turning it on for real would involve (the day Meridiano tackles it):

1. ISP prefix: request/confirm the delegation of a prefix (a /48 or /56) on the Valencia and Bilbao connections.
2. Addressing plan: assign one /64 per VLAN/subnet, like the 2001:db8:acad:0010::/64 scheme we sketched — half an hour of work, no arithmetic.
3. Routers: enable RAs per subnet (SLAAC, with DNS in the RA or DHCPv6 depending on the registry policy), and route IPv6 between VLANs and sites (the VPN must carry IPv6 too).
4. A serious firewall: this is THE critical point. Under dual stack, the file server would have a global address theoretically reachable from the whole Internet — NAT's "pseudo-firewall" (lesson 05-03) no longer exists. Security comes to depend exclusively on explicit firewall rules on the router: deny inbound by default, allow just what's needed. Enabling IPv6 without reviewing the firewall is the classic deployment mistake.
5. Double diagnosis: monitoring, DNS (AAAA records for the intranet) and troubleshooting in duplicate; a failure that "only happens sometimes" may be an IPv6-only failure with a silent fallback to IPv4.

The reward: Marta and Jon with real end-to-end connectivity (the VPN still makes sense — it encrypts and authenticates — but without NAT contortions), services publishable without port forwarding, and a network aligned with the direction the Internet has been moving in for two decades.

• Expanding zeros wrong: db8:20 is 0db8:0020, not db80:2000. Restored zeros go on the left of each group.
• Using :: twice: illegal due to ambiguity. Only the longest run of zeros (and on a tie, the first) gets compressed.
• Treating the fe80:: link-local as an error: it is not APIPA. It is mandatory, legitimate and necessary; its presence indicates no fault whatsoever. (Its absence would indeed be most unusual.)
• Looking for the broadcast address: it does not exist in IPv6. Think multicast (ff02::1 for "everyone on the link").
• Sizing IPv6 subnets "to save addresses": don't do /112s or /120s to "avoid waste". The convention is /64 per subnet; breaking it breaks SLAAC and saves nothing that is scarce.
• Enabling IPv6 (or leaving it enabled) without a firewall designed for IPv6: with global addresses there is no NAT to cover the internal services. Default inbound rule: deny. And beware: even if you "don't use IPv6", your machines have link-locals and many systems prefer it if an RA shows up — a rogue RA on the network is a known attack.
• Tip: to compare two IPv6 addresses written differently, expand them to the full 8 columns and compare. With practice you will do it in your head; at first, on paper.
• Tip: under dual stack, when something fails "halfway", always ask: was this over IPv4 or IPv6? (ping vs ping -6, A record vs AAAA).

a) Compress as much as possible (canonical form): 2001:0db8:00a0:0000:0000:0000:0000:0d10 b) Compress as much as possible: 2001:0db8:0000:0000:0130:0000:0000:0007 (careful: two runs of zeros) c) Expand to the full 8 groups: 2001:db8:acad:120::20:7

Marta runs ip addr on a machine that already has IPv6 enabled and sees these addresses. Classify each one (type and scope) and explain its role:

• ::1
• fe80::5e26:aff:fe4b:91d3
• 2001:db8:acad:10:1c3a:9bf2:44d0:8a11
• fd00:10::10

The ISP delegates the prefix 2001:db8:7a00::/48 to Meridiano. Propose a /64 for each subnet of the module's plan (Valencia corporate, Valencia guests, Valencia servers, Bilbao), matching the subnet group to the VLAN/site numbers (10, 20, 30, 120), and answer: how many /64 subnets fit in the /48 in total? Does it make sense to ask how many hosts fit in each one?

Solution 1

a)

b)

c)

Solution 2

• ::1 — loopback, scoped to the machine itself. Equivalent to IPv4's 127.0.0.1: testing the local stack.
• fe80::5e26:aff:fe4b:91d3 — link-local (fe80::/10), scoped to the link: it does not cross routers. Auto-generated (here with EUI-64 from the MAC 5c:26:0a:4b:91:d3: the 7th bit of the first byte is flipped, 5c→5e, and ff:fe is inserted in the middle). It supports NDP and is usually the gateway that routers advertise.
• 2001:db8:acad:10:1c3a:9bf2:44d0:8a11 — global unicast (starts with 2), routable on the Internet. Subnet prefix 2001:db8:acad:10::/64 (Valencia corporate in our plan); the random interface identifier suggests SLAAC with privacy extensions.
• fd00:10::10 — unique local (ULA), inside fd00::/8 ⊂ fc00::/7: the IPv6 equivalent of RFC 1918, for internal use, not routable on the Internet. Here, plausibly, a stable internal address for the file/intranet server.

Solution 3

Plan (subnet groups chosen in hex, visually matching VLAN/site):

/64 subnets in a /48: the subnet bits are 64 − 48 = 16, hence 2¹⁶ = 65,536 subnets. With 4 in use, 65,532 remain free: scarcity has stopped being a design variable.

Hosts per subnet? Each /64 contains 2⁶⁴ ≈ 1.8 × 10¹⁹ addresses. The question loses the meaning it had in IPv4: there is nothing to size, no 2^h − 2, no broadcast to subtract. In IPv6 you count subnets, not hosts.

This lesson closes the addressing circle: you know why IPv6 exists (the exhaustion NAT merely postponed), you read and abbreviate its 128-bit addresses with the two rules (leading zeros and a single ::), you distinguish global unicast, link-local, ULA and multicast — and you know that broadcast is dead —, you understand why the universal /64 turns subnetting into arithmetic-free enumeration, you can compare SLAAC with the DHCP you already knew, and you are clear that the real transition is called dual stack. At Meridiano, moreover, you have seen that IPv6 is already on every machine in the form of a link-local, and what steps (and what firewall) turning it on for real would demand.

And with that, module 5 is complete: IPv4 anatomy and its binary, masks and subnetting with a method, NAT and the world of private addresses, and IPv6 as the destination. You now know how the addressing of a network like Meridiano's is designed end to end. What we have not yet systematized is what to do when, with everything well designed, something fails: Marta can't reach the intranet, the ping gets lost halfway, DNS resolves strangely. Turning your knowledge into a diagnostic method — with the everyday tools well sharpened, traffic capture included — is the goal of module 6: Diagnostic Tools.