101
0/240
Loading content...
Global Unicast Addresses (GUAs) are the IPv6 equivalent of public IPv4 addresses—they are globally unique, routable across the entire Internet, and serve as the primary identifiers for hosts participating in worldwide communication. When you access a website, stream video, or send email over IPv6, you're using global unicast addresses.
The 2000::/3 address space—where all current global unicast addresses reside—contains more addresses than IPv4's entire public space by a factor of over 2^96. This astronomical abundance enables a fundamentally different approach to addressing: every device can have unique, permanent, aggregatable addresses without the contortions that IPv4's scarcity imposed.
This page explores global unicast addresses comprehensively—from the hierarchical allocation model through practical address planning to configuration and management considerations.
By completing this page, you will understand global unicast address structure and hierarchy, how addresses flow from IANA through RIRs to ISPs to organizations, proper address planning techniques for organizations, and how global addresses interact with other address types in operational networks.
Global Unicast Addresses occupy the 2000::/3 address range—any address beginning with binary 001 (hex 2 or 3 in the first nibble). This represents 1/8th of the total IPv6 address space, yet contains approximately 42 undecillion addresses.
Fundamental Characteristics:
Global Uniqueness: Each GUA is unique across the entire Internet. No two interfaces anywhere should have the same global unicast address.
Full Routability: GUAs can be routed across any IPv6 network. Unlike link-local or ULA addresses, there are no topological restrictions.
Hierarchical Structure: GUAs follow a hierarchical allocation model enabling route aggregation—essential for manageable routing tables.
Provider-Assigned Nature: Most organizations receive GUAs from their ISP, creating a natural aggregation hierarchy.
SLAAC Compatibility: Global prefixes advertised by routers allow hosts to automatically configure globally-routable addresses.
| Property | Value | Implication |
|---|---|---|
| Prefix | 2000::/3 | All addresses 2000:: through 3fff:: |
| Size | ~42 undecillion addresses | Effectively unlimited for humanity's needs |
| Scope | Global | Routable everywhere |
| Allocation | IANA → RIR → LIR/ISP → End-user | Hierarchical, aggregatable |
| Interface ID | Fixed 64 bits | Standard across all allocations |
| Current Usage | ~0.0003% allocated | Vast majority still available |
Only 2000::/3 is currently allocated for global unicast. The remaining 7/8 of IPv6 space (4000::/3 through dfff::/3, excluding multicast ff00::/8) is reserved for future use. This conservatism ensures that any mistakes in current allocation schemes can be corrected without exhausting IPv6's potential.
IPv6 global addressing follows a hierarchical allocation model designed for aggregation and scalability. Understanding this hierarchy is essential for network design and address planning.
Allocation Hierarchy:
IANA (Internet Assigned Numbers Authority)
|
Allocates large blocks (/12)
|
┌─────────────────┼─────────────────┐
▼ ▼ ▼
ARIN RIPE NCC APNIC ...
(N. America) (Europe) (Asia-Pacific)
│ │ │
Allocates /32 - /29 to ISPs/LIRs │
│ │ │
▼ ▼ ▼
ISP / Enterprise ISP / LIR Organizations
│ │ │
Assigns /48 - /56 to customers │
│ │
▼ ▼
End Sites Individual Sites
│
/64 to each subnet
│
▼
Hosts (/128)
Regional Internet Registries (RIRs):
| RIR | Region | Founded | Current Allocation Block |
|---|---|---|---|
| ARIN | North America, Caribbean | 1997 | 2600::/12, 2610::/23, etc. |
| RIPE NCC | Europe, Middle East, Central Asia | 1992 | 2a00::/12, 2001::/16, etc. |
| APNIC | Asia-Pacific | 1993 | 2400::/12, 2001::/16, etc. |
| LACNIC | Latin America, Caribbean | 2002 | 2800::/12 |
| AFRINIC | Africa | 2004 | 2c00::/12 |
Standard Allocation Sizes:
ISP/LIR Allocations:
End-Site Assignments:
Subnet Level:
Why /48 for Sites?
The /48 standard emerged from analysis:
While /48 is standard, organizations can request more from their RIR with justification. Large enterprises, cloud providers, and data centers often hold /32 or larger. The key is demonstrating utilization—planned subnetting showing how the space will be used. Don't be constrained by defaults if your architecture requires more.
Let's dissect a global unicast address to understand each component's role.
Example Address: 2001:0db8:85a3:0042:0000:8a2e:0370:7334
┌─────────────────────────────────────────────────────────────────────────┐
│ 128 bits │
├────────────┬─────────────┬─────────────┬────────────────────────────────┤
│ n bits │ m bits │ p bits │ 64 bits │
│ Provider │ Site │ Subnet │ Interface ID │
│ Prefix │ Prefix │ ID │ │
├────────────┴─────────────┴─────────────┼────────────────────────────────┤
│ 64 bits │ 64 bits │
│ Network Prefix (Routing) │ Host Identifier │
└────────────────────────────────────────┴────────────────────────────────┘
2001:0db8:85a3:0042 : 0000:8a2e:0370:7334
└────────┬─────────┘ └───────┬────────┘
Routing Prefix Interface ID
(from RIR/ISP/Router) (host-generated)
Breaking Down the Components:
| Component | Bits | Our Example | Controlled By |
|---|---|---|---|
| Global Routing Prefix | Variable (typically 48) | 2001:db8:85a3::/48 | RIR → ISP → Organization |
| Subnet ID | Variable (typically 16) | ::42 | Organization |
| Interface ID | Fixed 64 | ::8a2e:370:7334 | Host (auto or manual) |
The 64-Bit Interface Identifier:
The fixed 64-bit interface ID enables:
The Subnet ID Field:
With a /48 global routing prefix, you have 16 bits for subnet IDs—65,536 possible subnets. Common schemes:
2001:db8:85a3:0001::/64 → Building 1
2001:db8:85a3:0002::/64 → Building 2
2001:db8:85a3:0100::/64 → Servers (256 = 0x100)
2001:db8:85a3:0200::/64 → User VLANs start
2001:db8:85a3:8000::/64 → Guest network (high bit set)
2001:db8:85a3:ffff::/64 → Management network (last subnet)
Numeric organization within the subnet ID field aids troubleshooting and documentation.
Do not create subnets longer than /64 (e.g., /126 for point-to-point links). While technically possible, this breaks SLAAC, privacy extensions, and many IPv6 features. The address space is effectively infinite—there's no benefit to 'saving' addresses by using longer prefixes, and significant cost in operational complexity.
Proper IPv6 address planning requires thinking differently from IPv4. With abundant space, the goal shifts from conservation to organization, aggregation, and future-proofing.
Planning Principles:
Plan for Growth: Allocate more space than currently needed. A subset that's too small requires renumbering.
Maintain Aggregation: Keep subnets contiguous where possible to enable summarization in routing.
Reflect Organizational Structure: Use address structure to mirror physical or logical topology.
Reserve Space: Leave gaps between allocations for future insertion.
Document Everything: IPv6 addressing requires clear documentation for troubleshooting.
Example: Mid-Size Enterprise Planning
Scenario: Company receives 2001:db8:abcd::/48 from ISP
Master Allocation: 2001:db8:abcd::/48 (65,536 /64s available)
Hierarchical Plan:
2001:db8:abcd:0000::/52 (4,096 /64s) → Headquarters
├── 2001:db8:abcd:0000::/56 (256 /64s) → HQ Floor 1
│ ├── 2001:db8:abcd:0000::/64 → HQ F1 User VLAN 1
│ ├── 2001:db8:abcd:0001::/64 → HQ F1 User VLAN 2
│ ├── 2001:db8:abcd:0010::/64 → HQ F1 VoIP
│ └── 2001:db8:abcd:00ff::/64 → HQ F1 Management
├── 2001:db8:abcd:0100::/56 (256 /64s) → HQ Floor 2
└── 2001:db8:abcd:0200::/56 (256 /64s) → HQ Floor 3
2001:db8:abcd:1000::/52 (4,096 /64s) → Branch Office 1
2001:db8:abcd:2000::/52 (4,096 /64s) → Branch Office 2
2001:db8:abcd:3000::/52 (4,096 /64s) → Branch Office 3
2001:db8:abcd:8000::/52 (4,096 /64s) → Data Center 1
├── 2001:db8:abcd:8000::/56 → DC1 Production
├── 2001:db8:abcd:8100::/56 → DC1 Staging
├── 2001:db8:abcd:8200::/56 → DC1 Development
└── 2001:db8:abcd:8f00::/56 → DC1 Infrastructure
2001:db8:abcd:c000::/50 (16,384 /64s) → Reserved for Future
This plan uses only ~25% of available space while providing clear structure and room for growth.
Align allocations to nibble (4-bit) boundaries when possible. A /52 ends at a nibble boundary (:x000), making addresses easier to read and remember than odd boundaries like /51. Subnet IDs like 0000, 1000, 2000 are cleaner than 0000, 0800, 1000. This isn't technically required but significantly aids human readability.
Hosts can obtain global unicast addresses through several mechanisms, each with different tradeoffs.
1. SLAAC (Stateless Address Autoconfiguration)
Router sends: Host receives:
RA with: Prefix: 2001:db8:1::/64
Prefix: 2001:db8:1::/64 +
Flags: A=1 (autonomous) IID: ::21c:42ff:feab:cdef (generated)
=
2001:db8:1::21c:42ff:feab:cdef
Advantages: Zero infrastructure required beyond router; works immediately Disadvantages: No control over host addresses; harder to log/track
2. DHCPv6 Stateful
Client ←→ DHCPv6 Server
Solicit → ff02::1:2
Advertise ← Server
Request → Server
Reply ← Server (contains assigned address)
Result: Host receives specific address from DHCP pool
Advantages: Centralized address management; logging; control Disadvantages: Requires DHCP infrastructure; potential single point of failure
3. Manual Configuration
# Linux
ip -6 addr add 2001:db8:1::100/64 dev eth0
# Windows
netsh interface ipv6 add address "Ethernet" 2001:db8:1::100
# Cisco Router
interface GigabitEthernet0/0
ipv6 address 2001:db8:1::1/64
Advantages: Precise control; essential for infrastructure Disadvantages: Doesn't scale; error-prone; requires change management
| Use Case | Recommended Method | Rationale |
|---|---|---|
| End-user workstations | SLAAC + Privacy Extensions | Simple, scalable, privacy-preserving |
| Servers | Manual or DHCPv6 Stateful | Stable, predictable addresses for DNS/services |
| Routers/Infrastructure | Manual | Addresses are infrastructure; must be explicit |
| IoT/Embedded | SLAAC (RFC 7217) | Stable per-network; no server needed |
| Virtual machines | DHCPv6 Stateful | Integration with orchestration platforms |
| Guest networks | SLAAC | No tracking needed; simple operation |
Hosts can use both methods simultaneously: SLAAC for address configuration, DHCPv6 for additional options (DNS servers, NTP, etc.). Router Advertisements control this via the M (Managed) and O (Other) flags. O=1, M=0 means 'use SLAAC for address, DHCPv6 for other options'—a common enterprise configuration.
Organizations must choose between Provider-Assigned (PA) and Provider-Independent (PI) address space. This choice has significant implications for portability, routing, and cost.
Provider-Assigned (PA) Space:
Addresses allocated from your ISP's block:
ISP owns: 2001:db8::/32
You receive: 2001:db8:abcd::/48 (from ISP's space)
Characteristics:
Provider-Independent (PI) Space:
Addresses allocated directly from your RIR:
You receive: 2001:db9::/32 (direct from ARIN/RIPE/etc.)
Not part of any ISP's aggregation
Characteristics:
Each PI allocation adds an entry to the global BGP routing table. With hundreds of thousands of entries already, unnecessary fragmentation harms Internet routing. RIRs require justification for PI space. If you don't need provider independence, use PA space—it's better for the Internet ecosystem and cheaper for you.
During the IPv4-to-IPv6 transition, most networks operate in dual-stack mode—running both protocols simultaneously. Global unicast addresses play a crucial role in this environment.
Dual-Stack Address Architecture:
Interface eth0:
├── IPv4: 192.168.1.100/24 (likely NAT'd)
├── IPv6 Link-Local: fe80::21c:42ff:feab:cdef/64 (always present)
├── IPv6 Global: 2001:db8:1::21c:42ff:feab:cdef/64 (routable)
└── IPv6 Temporary: 2001:db8:1::a5c2:3f7b:c892:4521/64 (privacy)
Happy Eyeballs Algorithm:
Modern clients use "Happy Eyeballs" (RFC 6555/8305) when connecting:
This ensures users get the fastest connection while preferring IPv6 when it works well.
Address Selection in Dual-Stack:
RFC 6724 governs source address selection. Default behavior:
| Destination | Source Selection | Reason |
|---|---|---|
| IPv6 Global | IPv6 Global (or temporary) | Scope match |
| IPv6 Link-Local | IPv6 Link-Local | Scope match |
| IPv4 | IPv4 | Protocol match |
| Either available | Prefer IPv6 | Default policy |
Operational Considerations:
DNS Must Serve Both: Publish both A and AAAA records for dual-stack services
Firewall Parity: Security policies must cover both protocols
Monitoring Both Stacks: Failure in either protocol affects users
Performance Comparison: Measure both to ensure IPv6 path is competitive
Fallback Works: Test that Happy Eyeballs successfully falls back when IPv6 fails
If your IPv6 deployment is healthy, you can encourage clients to use it by setting AAAA record TTLs shorter than A records (clients cache the AAAA response, making IPv6 appear faster) or by advertising IPv6 prefixes with higher priority in RA. Tools like ipv6-test.com help verify IPv6 reachability from various global locations.
We've comprehensively explored IPv6 global unicast addresses—the primary addresses for Internet communication. From hierarchical allocation to enterprise planning, you now understand the addressing that powers the modern Internet. Let's consolidate this knowledge:
Congratulations! You have completed the IPv6 Address Types module, mastering the complete taxonomy of IPv6 addressing: unicast (link-local, ULA, global), multicast (well-known groups, solicited-node, scopes), and anycast. You now understand how these address types work together to enable the sophisticated, efficient, and scalable communication that defines IPv6.