Understanding IPv6 Addressing

An IPv6 address is a 128-bit identifier of an interface, written in hexadecimal with one canonical spelling, split into a prefix and an interface identifier, and typed by its first bits. After reading, you can write any address canonically, tell its type and scope, give a link-local address its zone, recover the hardware address inside an identifier derived from it, and name the reverse DNS record that maps an address to a host.

View as Markdown

An IP version 6 (IPv6) address is a 128-bit identifier, and (RFC) 4291 says what it names: "IPv6 addresses of all types are assigned to interfaces, not nodes" (RFC 4291, section 2.1). An ip address listing shows them, often several per interface. By the end you can write any address canonically, split prefix from interface identifier, read type and scope from the first bits, give a link-local address its zone, turn a modified 64-bit Extended Unique Identifier () back into its Media Access Control (MAC) address, and build its ip6.arpa name.

Why IPv6 exists

IPv4 addresses are 32 bits (RFC 791, section 2.3), 4,294,967,296 values. The Internet Engineering Task Force () began choosing a successor in late 1990, when projections showed the address space becoming a limiting resource, and its January 1995 recommendation records the name the Internet Assigned Numbers Authority () gave IP Next Generation (IPng): "The IANA has assigned version number 6 to IPng. The protocol itself will be called IPv6" (RFC 1752, sections 1 and 11.2). IPv6 addresses have 128 bits (RFC 8200, section 1), about 3.4 × 10^38 of them.

On 3 February 2011 the Number Resource Organization (NRO) announced that IANA's free pool of IPv4 addresses was fully depleted (NRO, 3 February 2011). On 16 October 2026, 48.65% of Google's users reached it over IPv6, and 57.13% in Brazil (Google, IPv6 Statistics).

The address and its text forms

Addresses are unicast, anycast or multicast, and "There are no broadcast addresses in IPv6, their function being superseded by multicast addresses" (RFC 4291, section 2). In text, "The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address" (section 2.2). A piece may drop its leading zeros, and one run of all-zero pieces may be replaced by ::, once per address: 2001:DB8:0:0:8:800:200C:417A is also 2001:DB8::8:800:200C:417A, loopback is ::1 and the unspecified address ::. A mixed form, x:x:x:x:x:x:d.d.d.d, ends in an IPv4 address (section 2.2).

The canonical form, rule by rule

RFC 5952 fixes one spelling for output: "The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format" (RFC 5952, section 4). The rules (sections 4.1 to 5):

Rule	Section	Not canonical	Canonical
No leading zeros	4.1	`2001:0db8::0001`	`2001:db8::1`
Shorten every zero piece possible	4.2.1	`2001:db8:0:0:0:0:2:1`	`2001:db8::2:1`
No `::` for one zero piece	4.2.2	`2001:db8::1:1:1:1:1`	`2001:db8:0:1:1:1:1:1`
Longest run; on a tie, the first	4.2.3	`2001:db8:0:0:1::1`	`2001:db8::1:0:0:1`
Lowercase	4.3	`2001:DB8::8:800:200C:417A`	`2001:db8::8:800:200c:417a`
Dotted decimal after a well-known prefix	5	`0:0:0:0:0:ffff:192.0.2.1`	`::ffff:192.0.2.1`

With a port, write [2001:db8::1]:80, not the ambiguous 2001:db8::1:80 (RFC 5952, section 6).

Prefix and interface identifier

A prefix is written address/length, the length counting the leftmost bits that form the prefix (RFC 4291, section 2.3), as in IPv4's Classless Inter-Domain Routing (), read in CIDR notation explained. A written prefix "may drop leading zeros, but not trailing zeros, within any 16-bit chunk of the address" (section 2.3): 2001:0DB8:0:CD30::/60 is legal, 2001:0DB8:0:CD3/60 is not. The rest is the interface identifier (IID), 64 bits in every global unicast address outside binary 000 (section 2.5.4); RFC 7136 keeps that length, with /127 router links as a particular case (RFC 7136, sections 2 and 5). So 2001:db8:abcd:12::1/64 spans 2001:db8:abcd:12:: to 2001:db8:abcd:12:ffff:ffff:ffff:ffff, 18,446,744,073,709,551,616 addresses; IPv6 subnetting cuts larger blocks into such subnets.

Address types: what the first bits say

RFC 4291 types an address by its first bits, ::/128 unspecified, ::1/128 loopback, ff00::/8 multicast, fe80::/10 link-local, and "implementations must treat all addresses that do not start with any of the above-listed prefixes as Global Unicast addresses" (RFC 4291, section 2.4). IANA currently assigns global unicast space only from 2000::/3, keeping the rest, about 85% of all addresses, reserved (IANA, IPv6 Address Space); its special-purpose registry marks reachability (IANA, IPv6 Special-Purpose Address Space):

Block	Use	Globally reachable
`::/128`, `::1/128`	unspecified, loopback	False
`::ffff:0:0/96`	IPv4-mapped	False
`64:ff9b::/96`	IPv4/IPv6 translation	True
`2001:db8::/32`, `3fff::/20`	documentation	False
`fc00::/7`	unique local	False
`fe80::/10`	link-local	False

IPv4-mapped addresses stand for IPv4 nodes, while the IPv4-compatible form and the site-local prefix fec0::/10 are deprecated (RFC 4291, sections 2.5.5 and 2.5.7); the translation prefix belongs to dual-stack and translation.

Link-local addresses use fe80::/10, as currently defined only fe80::/64 (RFC 4291 errata, erratum 4406), and "Routers must not forward any packets with Link-Local source or destination addresses to other links" (RFC 4291, section 2.5.6). Unique local addresses (ULAs) use fc00::/7, in practice fd00::/8, the only defined half, with a 40-bit Global ID that must not be sequential or well known (RFC 4193, sections 3.1 and 3.2); unlike RFC 1918 space, "If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses" (section 1). Documentation has 2001:db8::/32 (RFC 3849, section 2) and, since August 2024, 3fff::/20: "The original 2001:db8::/32 reservation is inadequate to describe many realistic, current deployment scenarios" (RFC 9637, section 1). Anycast addresses are syntactically indistinguishable from unicast (RFC 4291, section 2.6).

Multicast and its scopes

A multicast address starts with ff, then four flag bits (0RPT, T set for a transient group), a 4-bit scope and a 112-bit group identifier, and is never a source address (RFC 4291, section 2.7). Scopes, as RFC 7346 and IANA now define them (RFC 7346, section 2; IANA, IPv6 Multicast Address Space), with groups from RFC 4291 (section 2.7.1):

Value	Scope	Well-known groups
1	Interface-Local	`ff01::1` all nodes
2	Link-Local	`ff02::1` all nodes, `ff02::2` all routers
3	Realm-Local	reserved until RFC 7346
4, 5, 8	Admin-Local, Site-Local, Organization-Local	`ff05::2`, all routers in scope 5
e	Global	`ff0e::101` all Network Time Protocol servers

Interface-local, link-local and realm-local boundaries follow from physical connectivity, and global scope has none (RFC 7346, section 2). Each unicast or anycast address also maps to a solicited-node group, its last 24 bits after FF02:0:0:0:0:1:FF00::/104: 2001:db8::8:800:200c:417a gives ff02::1:ff0c:417a (RFC 4291, section 2.7.1), the group behind Neighbor Discovery, the IPv6 counterpart of the Address Resolution Protocol ().

Zones: why fe80::1 needs %eth0

Link-local addresses can repeat from link to link, and "The zone to which a particular non-global address pertains is not encoded in the address itself but determined by context, such as the interface from which it is sent or received" (RFC 4007, section 5). The zone follows a percent sign, <address>%<zone_id>, as in fe80::1234%1 (sections 11 and 11.3), and "Hence, the format MUST be used only within a node and MUST NOT be sent on the wire unless every node that interprets the format agrees on the semantics" (section 11.2).

RFC 9844 (August 2025) adds that zones are usually interface names, fe80::1234%eth0 on Linux and fe80::4321%7 on Windows, and that "a link-local address without a zone index cannot be used in the Linux socket API" (RFC 9844, sections 1 and 3). It requires user interfaces to let users enter a zone (section 5) and obsoletes RFC 6874, with its syntax for zones in Uniform Resource Identifiers (URIs) (section 3).

How interface identifiers are made

Modified EUI-64 builds the IID from a 48-bit : insert ff fe in the middle and invert the universal/local bit (RFC 4291, Appendix A), the next-to-lowest bit of the first octet (RFC 2464, section 4). For the documentation MAC address 00-00-5E-00-53-01 (RFC 9542, section 2.1.4), computed:

MAC address                       00-00-5E-00-53-01
ff-fe inserted in the middle      00-00-5E-FF-FE-00-53-01
universal/local bit inverted      02-00-5E-FF-FE-00-53-01
interface identifier              0200:5eff:fe00:5301
link-local address                fe80::200:5eff:fe00:5301
in 2001:db8::/64                  2001:db8::200:5eff:fe00:5301

The method also runs backwards: drop ff fe from ping(8)'s fe80::5054:ff:fe70:67bc and flip the bit back: 52:54:00:70:67:bc (ping(8)). The pattern is a hint, not proof: RFC 7136 treats the whole IID as opaque (RFC 7136, abstract and section 3).

RFC 8064 (2017) says "By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID" (RFC 8064, section 3), and recommends RFC 7217's identifiers, stable within a subnet and different when the host moves (RFC 7217, abstract), as the default for Stateless Address Autoconfiguration (). RFC 8981 (2021) adds temporary addresses with randomised identifiers, by default valid for 2 days and preferred for 1, and drops the advice to disable them by default (RFC 8981, abstract and sections 3.8 and 5). documents addr_gen_mode 0, "generate address based on EUI64 (default)", and use_tempaddr 0 for most devices (Linux kernel documentation, IP Sysctl): the kernel's documented defaults, not a statement about any distribution. How hosts obtain addresses, by SLAAC or (Dynamic Host Configuration Protocol for IPv6), is the next part.

Reverse DNS under ip6.arpa

An holds one IPv6 address (RFC 3596, section 2.1); the reverse name writes the address as 32 nibbles, low-order nibble first, under ip6.arpa (section 2.5). Computed for 2001:db8::200:5eff:fe00:5301:

1.0.3.5.0.0.e.f.f.f.e.5.0.0.2.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

That name is the owner name of the pointer () record; the host name, say host.example.com, is the record's value. Python's documentation is explicit: "This is the name that could be used for performing a PTR lookup, not the resolved hostname itself" (Python 3.15 documentation, ipaddress). Reading the Records in a dig Answer shows PTR answers.

How addressing fails or is attacked

Text is the first trap: a spreadsheet holding 2001:db8::1:0:0:1 finds no match for 2001:db8:0:0:1::1 (RFC 5952, section 3.1.2), and comparing strings for access control can be a security risk (section 8), so compare parsed values. RFC 7721 names four attacks, correlation over time, location tracking, address scanning and device-specific exploitation (RFC 7721, section 3); a constant IID tracks a host across links (section 3.2), and the 's 24-bit Organizationally Unique Identifier (OUI) and the fixed ff fe shrink the search space: "This erases much of the protection against address scanning that the larger IPv6 address space could provide as compared to IPv4" (section 3.3). Temporary addresses help, though not against an on-link observer such as the default router (RFC 8981, section 1.2).

Scope is the other trap: site-local fec0::1 could exist in many sites at once (RFC 3879, section 2); ULAs should stop at the site border and stay out of the global DNS, and give no inherent security (RFC 4193, sections 4.3, 4.4 and 7); a link-local address without its zone fails on a node with several links (RFC 4007, section 11.4). Documentation prefixes stay out of production: "they MUST NOT be used for actual traffic, MUST NOT be globally advertised, and SHOULD NOT be used internally for routed production traffic or other connectivity" (RFC 9637, section 4).

Seeing addresses on a host

On Linux, -6 limits ip to IPv6 (ip(8)); ip-address(8) selects by device, scope or flag (ip-address(8)):

ip -6 address show
ip -6 address show dev eth0
ip -6 address show scope link
ip -6 address show scope global
ip -6 address show temporary

Each address shows its scope (link, valid only on that device, or global), a valid_lft after which the kernel removes it, a preferred_lft after which new connections stop using it, and flags such as tentative (duplicate address detection not yet passed), temporary and dynamic (ip-address(8)). To reach a link-local target, ping(8) using Internet Control Message Protocol () datagram sockets needs the outgoing interface: ping fe80::5054:ff:fe70:67bc%eth0 (ping(8)).

This illustrative session, run with Python 3.13.16 (Python 3.15 documentation, ipaddress), can be replayed in the Python playground:

>>> import ipaddress
>>> a = ipaddress.ip_address('2001:db8:0:0:8:800:200c:417a')
>>> a.compressed
'2001:db8::8:800:200c:417a'
>>> a.exploded
'2001:0db8:0000:0000:0008:0800:200c:417a'
>>> a.reverse_pointer
'a.7.1.4.c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa'
>>> b = ipaddress.ip_address('fe80::5054:ff:fe70:67bc%eth0')
>>> b.scope_id
'eth0'
>>> b.is_link_local
True
>>> ipaddress.ip_address('::ffff:192.0.2.128').ipv4_mapped
IPv4Address('192.0.2.128')

The IPv6 Toolkit computes locally the canonical and expanded forms, type, scope, prefix arithmetic, an EUI-64 MAC address and the ip6.arpa name, dropping any %zone suffix. Its special-block table has eleven entries and lacks 3fff::/20, so 3fff::1 reads as global unicast, and the MAC 10:34:56:78:9a:bc it recovers from 2001:db8::1234:56ff:fe78:9abc may never have existed: confirm with the IANA registry and the OUI / MAC vendor lookup.

What to remember

An IPv6 address identifies an interface, not a node, in 128 bits; every interface must have a link-local address.
Accept any RFC 4291 spelling; print RFC 5952's: lowercase, no leading zeros, :: for the longest zero run of two or more pieces, the first on a tie.
Prefixes keep each piece's trailing zeros; global unicast addresses outside binary 000 end in a 64-bit interface identifier.
ff00::/8 is multicast with a 4-bit scope (3 is realm-local), fe80::/10 link-local and never forwarded, fc00::/7 unique local, 2001:db8::/32 and 3fff::/20 documentation.
A link-local address needs its zone, fe80::1%eth0, which never leaves the node.
Modified EUI-64 exposes the MAC address, aiding tracking and scanning; RFC 8064 prefers RFC 7217 identifiers, though the Linux kernel documents EUI-64 as its default.
The nibble-reversed ip6.arpa name is the PTR record's owner name; the host name is its value.

This series, in order

This article opens the series IPv6. It covers the address itself; the parts follow a host onto a network in the order it meets each piece: the subnet it lands in, the way it gets an address, the neighbour discovery that replaces ARP, and the transition machinery that lets it reach the IPv4 world, down to the port sets that let many customers share one IPv4 address.

IPv6 subnetting and the /64 boundary. Structure rather than scarcity: why a subnet is almost always a /64, and how prefix delegation hands out space.
How IPv6 hosts get addresses: SLAAC and DHCPv6. From link-local up: router advertisements, SLAAC, privacy addresses and DHCPv6.
Neighbor Discovery: how IPv6 replaces ARP. and multicast instead of broadcast ARP: the five Neighbor Discovery messages.
Running IPv6 and IPv4 together: dual-stack and translation. Dual-stack, Happy Eyeballs, and the IPv4-embedded addresses that bridge the two families.
Port blocks and port sets: the arithmetic of sharing one IPv4 address. MAP-E and MAP-T give each customer a share of one IPv4 address as a set of ports: the PSID arithmetic of RFC 7597, worked by hand.