IPv6 Address Types: A Comprehensive Classification

In the vast expanse of the IPv6 address space—340 undecillion addresses strong—unicast addresses represent the workhorse of everyday network communication. A unicast address identifies exactly one network interface on exactly one node, enabling the fundamental point-to-point communication that underpins virtually all network interactions.

While this concept seems straightforward (after all, IPv4 also has unicast addresses), IPv6 reimagines unicast addressing with a sophisticated scope hierarchy, multiple simultaneous addresses per interface, and built-in address types that eliminate the need for complex supplementary protocols. Understanding IPv6 unicast addressing isn't merely about learning a new format—it's about grasping a fundamentally different addressing philosophy.

A unicast address in IPv6 identifies a single network interface. When a packet is sent to a unicast destination, it is delivered to exactly that one interface—no copies, no duplication, no ambiguity. This one-to-one delivery model is the foundation upon which reliable network communication is built.

Fundamental Properties of Unicast Addresses:

1. Unique Interface Identification: Each unicast address uniquely identifies one interface within its scope. No two active interfaces can share the same unicast address in the same scope.

2. Single Delivery Guarantee: The network makes a single delivery attempt to exactly one destination. Unlike multicast (one-to-many) or broadcast (one-to-all), unicast traffic follows a single path to a single recipient.

3. Bidirectional Communication Enablement: Unicast addresses serve as both source and destination addresses, enabling two-way communication—the source address in a request becomes the destination address in the response.

4. Routing Table Foundation: Network routing tables are fundamentally organized around unicast prefixes. Even when handling multicast or anycast traffic, routers use unicast addresses for next-hop identification.

Understanding Address Scope:

The revolutionary aspect of IPv6 unicast addressing is the scope concept. Unlike IPv4, where an address is simply 'valid' or 'invalid', IPv6 unicast addresses have validity limited to specific topological regions:

• Interface-Local: Valid only on the sending interface itself (loopback)
• Link-Local: Valid only on the directly attached network segment
• Site-Local (deprecated): Was valid within an organizational site
• Global: Valid across the entire IPv6 Internet

This scope hierarchy isn't mere categorization—it fundamentally affects routing behavior. A link-local address cannot appear as source or destination in a packet crossing a router. This architectural constraint eliminates entire classes of configuration errors and security vulnerabilities.

Link-local addresses (prefix fe80::/10) represent one of IPv6's most elegant design decisions. Every IPv6-enabled interface automatically generates a link-local address upon activation—no manual configuration, no DHCP, no infrastructure dependency. This self-configuration capability ensures that IPv6 devices can always communicate with their immediate neighbors, regardless of whether global addressing infrastructure exists.

Link-Local Address Structure:

fe80:0000:0000:0000:XXXX:XXXX:XXXX:XXXX
├────────────────────┤├──────────────────┤
     64-bit Prefix         64-bit Interface ID
     (always fe80::/64)    (derived from interface)

The prefix is always fe80::/64 (despite the technical /10 allocation, only fe80::/64 is used in practice). The interface identifier is typically derived from the interface's MAC address using the EUI-64 algorithm or generated randomly for privacy.

Why Link-Local Addresses Matter:

1. Bootstrap Dependency: Link-local addresses enable all other IPv6 configuration. Neighbor Discovery Protocol (NDP), which replaces ARP and enables router discovery, operates entirely over link-local addresses. DHCPv6 client-server communication uses link-local addresses. Without link-local addresses, an interface cannot configure itself.

2. Router Communication: All routing protocols (OSPFv3, IS-IS, EIGRP for IPv6, BGP peering) use link-local addresses for next-hop identification. This provides stability—even if global prefixes change, routing adjacencies remain intact because link-local addresses are permanent.

3. Infrastructure Independence: In a network outage affecting global address allocation, devices retain local connectivity. Network management, troubleshooting, and recovery operations can proceed using link-local communication.

4. Attack Surface Reduction: Link-local addresses are unreachable from outside the local network segment. An attacker cannot directly target link-local addresses from the Internet, providing inherent security for local control plane traffic.

Global Unicast Addresses (GUAs) are the IPv6 equivalent of IPv4 public addresses—they are globally unique, routable across the entire Internet, and serve as the primary addresses for Internet communication. Allocated from the 2000::/3 range, GUAs currently represent the vast majority of assigned IPv6 address space.

Global Unicast Address Structure:

┌───────────────────────────────────────────────────────┐
│                  128 bits total                       │
├──────────────────────────┬────────────────────────────┤
│    48-64 bits            │     64 bits                │
│    Global Routing Prefix │     Interface Identifier   │
├─────────────┬────────────┼────────────────────────────┤
│ n bits      │ 64-n bits  │                            │
│ Provider    │ Site       │     Host Portion           │
│ Prefix      │ Prefix     │                            │
└─────────────┴────────────┴────────────────────────────┘

The standard allocation follows a hierarchical model:

• Regional Internet Registry (RIR) receives large blocks from IANA (e.g., /12)
• Internet Service Providers (ISPs) receive allocations from RIRs (e.g., /32)
• Organizations/Sites receive allocations from ISPs (e.g., /48)
• Subnets are carved from site allocations (e.g., /64 per segment)
• Hosts receive /128 addresses from subnet space

The /64 Subnet Boundary:

A critical architectural decision in IPv6 is the fixed 64-bit interface identifier. The first 64 bits define the network (routing prefix); the last 64 bits identify the interface. This division is not arbitrary—it enables:

1. Stateless Address Autoconfiguration (SLAAC): Hosts can automatically generate complete addresses by combining a router-advertised /64 prefix with their self-generated interface ID. No address server required.

2. Privacy Extensions (RFC 4941): Hosts can generate random, temporary interface IDs for outgoing connections, preventing long-term tracking while maintaining the same network prefix.

3. Stable Identifiers (RFC 7217): Hosts can generate stable-but-unpredictable interface IDs that remain consistent per-network while resisting tracking across networks.

4. Standardized Autoconfiguration: With a fixed /64 boundary, all autoconfiguration mechanisms—SLAAC, DHCPv6, privacy extensions—work identically regardless of the prefix hierarchy above the /64 boundary.

Example Global Unicast Address Breakdown:

Consider the address 2001:0db8:85a3:0042:0000:8a2e:0370:7334:

• Full Address: 2001:0db8:85a3:0042:0000:8a2e:0370:7334
• Compressed: 2001:db8:85a3:42::8a2e:370:7334
• Routing Prefix: 2001:db8:85a3:42::/64
• Interface ID: ::8a2e:370:7334

In this example:

• 2001:db8::/32 might be the ISP's allocation
• 2001:db8:85a3::/48 might be the customer's site allocation
• 2001:db8:85a3:42::/64 is the specific subnet
• The interface ID uniquely identifies this host on subnet 42

Unique Local Addresses (ULAs), defined in RFC 4193, provide IPv6's equivalent of IPv4 private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). However, ULAs incorporate lessons learned from IPv4's private addressing experience, addressing the collision and uniqueness problems that plague private IPv4 networks.

ULA Address Structure:

┌─────────────────────────────────────────────────────────────┐
│                      128 bits                               │
├────────┬───┬───────────────────┬────────────────────────────┤
│ 7 bits │1  │    40 bits        │    64 bits                 │
│   FC   │L  │   Global ID       │    64 bits                 │
│ Prefix │bit│   (random)        │   Subnet ID + Interface ID │
├────────┴───┴───────────────────┼──────────┬─────────────────┤
│      48 bits                   │ 16 bits  │    64 bits      │
│      /48 Prefix                │ Subnet   │  Interface ID   │
└────────────────────────────────┴──────────┴─────────────────┘

• fc00::/7: The reserved ULA range
• fc00::/8: Reserved for future definition (not currently used)
• fd00::/8: Available for local assignment (what everyone uses)
• 40-bit Global ID: Randomly generated to ensure uniqueness
• 16-bit Subnet ID: Allows 65,536 subnets within a ULA prefix
• 64-bit Interface ID: Standard interface identifier

Why ULAs Solve IPv4 Private Address Problems:

1. Collision Prevention: With 40 random bits, the probability of two independently-generated ULA prefixes colliding is approximately 1 in 1 trillion. Compare this to IPv4, where nearly every organization uses 10.0.0.0/8 or 192.168.0.0/16, causing guaranteed conflicts in mergers and VPNs.

2. Global Uniqueness (Probabilistic): While not registered centrally, properly-generated ULAs are globally unique with overwhelming probability. This enables network mergers without renumbering—a significant operational advantage.

3. Proper Scoping: ULAs are explicitly not globally routable. Unlike IPv4 private addresses, which rely on ISP filtering to prevent leakage, ULAs have a distinct prefix (fd::/8) that makes filtering decisions unambiguous.

4. Persistence Across Provider Changes: Organizations can use their ULA prefix indefinitely, regardless of ISP changes. Internal services addressed via ULA don't require renumbering when global prefixes change.

Beyond the primary unicast categories, IPv6 defines several special-purpose unicast addresses with unique behaviors and strict usage constraints. Understanding these addresses prevents configuration errors and clarifies diagnostic output.

The Loopback Address (::1):

The IPv6 loopback address is ::1 (or fully expanded, 0000:0000:0000:0000:0000:0000:0000:0001). This is the equivalent of IPv4's 127.0.0.1. Packets addressed to ::1 never leave the local machine—they are processed entirely within the network stack.

Key characteristics:

• Scope is interface-local (the most restricted scope)
• Used exclusively for intra-host communication
• Any packet with ::1 as source or destination appearing on a network is erroneous
• Typically assigned to a virtual loopback interface (lo on Linux, Loopback Pseudo-Interface on Windows)

The Unspecified Address (::):

The all-zeros address :: (or 0:0:0:0:0:0:0:0) is the unspecified address. It indicates the absence of an address rather than a real destination.

Uses:

• As source address during initialization (before address configuration completes)
• In ICMPv6 Neighbor Solicitation during Duplicate Address Detection (DAD)
• As destination in routing tables to represent the default route (::/0)

The unspecified address is never valid as a destination address in a transmitted packet or as a source address after initialization completes.

IPv4-Mapped IPv6 Addresses:

The prefix ::ffff:0:0/96 contains IPv4-mapped IPv6 addresses, used internally by dual-stack implementations to represent IPv4 addresses in IPv6 format. For example, the IPv4 address 192.0.2.1 maps to ::ffff:192.0.2.1 (or ::ffff:c000:0201 in pure hex).

These addresses:

• Are used by applications running on dual-stack hosts
• Allow IPv6-only application code to handle IPv4 connections
• Are never seen on the wire as actual packet addresses
• Represent an internal software implementation detail, not a network address type

The Documentation Prefix (2001:db8::/32):

This prefix is reserved exclusively for documentation, examples, and instructional materials. Using it in production networks is incorrect—these addresses should never appear in real routing tables or network configurations. When you see 2001:db8:: in examples, it's intentionally non-routable to prevent confusion with real addresses.

The 64-bit interface identifier in unicast addresses can be generated through multiple methods, each with different properties regarding stability, privacy, and security. Understanding these methods is essential for network architecture and troubleshooting.

Method 1: EUI-64 (Modified MAC Address)

The traditional approach derives the interface identifier from the Ethernet MAC address:

1. Take the 48-bit MAC: 00:1a:2b:3c:4d:5e
2. Insert ff:fe in the middle: 00:1a:2b:ff:fe:3c:4d:5e
3. Flip the Universal/Local bit (7th bit): 02:1a:2b:ff:fe:3c:4d:5e
4. Result interface ID: 021a:2bff:fe3c:4d5e

Advantages: Stable, predictable, easy to correlate with MAC addresses for troubleshooting.

Disadvantages: Enables tracking across networks (privacy concern), reveals device vendor (OUI prefix), fails when no MAC exists (tunnels, virtual interfaces).

Method 2: Privacy Extensions (RFC 4941)

To prevent tracking, hosts can generate temporary, random interface identifiers that change periodically:

1. Generate cryptographically random 64-bit value
2. Ensure proper bit settings (set U/L bit to local)
3. Use this temporary address for outgoing connections
4. Deprecate after configured lifetime (typically hours to days)
5. Generate new temporary address before old one expires

Advantages: Prevents long-term tracking, hides MAC address, changes identity over time.

Disadvantages: Breaks connection stability for long-lived sessions, complicates logging/auditing, may interact poorly with poorly-designed firewalls.

Method 3: Stable Semantically Opaque IIDs (RFC 7217)

A balanced approach generating identifiers that are:

• Stable within a network (same ID when reconnecting to the same network)
• Different across networks (different ID on each network visited)
• Unpredictable to observers (no correlation to MAC or other identifiers)

The algorithm: IID = Hash(Prefix, Interface_Name, Network_ID, DAD_Counter, Secret_Key)

This provides stability for local administration while preventing cross-network tracking.

With multiple addresses per interface, IPv6 hosts must select which source address to use for outgoing packets. This process, defined in RFC 6724, follows a sophisticated algorithm ensuring optimal address pairing.

The Fundamental Rule: Prefer source addresses that match the destination's scope and characteristics.

RFC 6724 Selection Rules (Simplified):

1. Prefer same address: If the destination is one of our addresses, use it as source
2. Prefer appropriate scope: Match source scope to destination scope (link-local to link-local, global to global)
3. Avoid deprecated addresses: Don't use addresses marked as deprecated
4. Prefer matching label: Policy table labels group compatible addresses
5. Prefer public addresses: Unless temporary addresses are preferred
6. Use longest matching prefix: Prefer addresses sharing more prefix bits with destination
7. Prefer native addresses: Prefer addresses on native interfaces over tunneled

Policy Table Customization:

The default RFC 6724 policy table can be customized to implement organizational preferences. Common customizations include:

• Preferring ULA source addresses for ULA destinations
• Preferring IPv4 over IPv6 (or vice versa) for dual-stack hosts
• Preferring specific prefixes for multi-homed environments
• Directing privacy-sensitive traffic through temporary addresses

On Linux, the policy table is configured in /etc/gai.conf. On Windows, netsh interface ipv6 show prefixpolicies displays the current table.

Understanding source address selection is essential for troubleshooting connectivity problems, security configurations, and multi-homed network designs.

We have traversed the complete landscape of IPv6 unicast addressing—from the automatically-generated link-local addresses that bootstrap all IPv6 communication, through the globally-routable addresses that enable Internet connectivity, to the privacy-preserving mechanisms that protect user identity. Let's consolidate this knowledge: