IPv6 Address Types: A Comprehensive Classification

Anycast introduces a communication paradigm that fundamentally differs from unicast and multicast: a single address is assigned to multiple nodes, and the network delivers packets to the topologically nearest instance. From the sender's perspective, they're addressing one destination—but which physical node receives the packet depends on the sender's location in the network.

This "one-to-nearest" model enables remarkable architectural patterns: automatic failover without client awareness, geographic load distribution, reduced latency through proximity-based routing, and resilient service deployment. Understanding anycast unlocks sophisticated approaches to building highly-available, globally-distributed systems.

While anycast existed in IPv4 (DNS root servers being the classic example), IPv6 embraces it as a first-class address type with explicit architectural support and standardized behaviors.

Anycast delivers packets addressed to an anycast destination to exactly one of the multiple nodes sharing that address—specifically, the one that is "nearest" according to routing metrics. This creates a fascinating hybrid behavior:

• Like unicast: One packet → one recipient
• Unlike unicast: Multiple nodes can hold the same address
• Unlike multicast: Only one node receives each packet (not all group members)

Fundamental Properties:

1. Address Indistinguishability: An anycast address looks syntactically identical to a unicast address. There is no special prefix or format that marks an address as anycast—the designation is contextual.

2. Routing-Based Selection: The routing infrastructure determines which instance receives traffic. The packet follows normal routing to the "nearest" destination as computed by routing protocols.

3. Transparent to Senders: The sending host has no knowledge (and needs none) that the destination address is anycast. It simply sends to the address; the network handles destination selection.

4. Instance Equivalence: All nodes sharing an anycast address must provide equivalent service. The sender expects the same service regardless of which instance responds.

5. No Return Path Guarantee: The response may come from a different source address (the unicast address of the responding node), potentially confusing stateful protocols.

How Anycast Works at the Routing Level:

Consider three DNS servers in New York, London, and Tokyo, all advertising the anycast address 2001:db8:53::1:

1. Each server announces 2001:db8:53::/48 (or the specific /128) to its upstream routers
2. These announcements propagate through the global routing system
3. Each router in the world builds a route to 2001:db8:53::/48 pointing to the "nearest" instance
4. A client in Paris queries 2001:db8:53::1—their ISP routes to London (nearest)
5. A client in Sydney queries the same address—their ISP routes to Tokyo
6. A client in Brazil routes to New York

From each client's perspective, they're talking to the same address. The routing infrastructure transparently directs them to different physical servers.

Key Insight: Anycast leverages standard routing protocols—no special anycast-aware routing is needed. If an address is announced from multiple locations, routing naturally directs traffic to the nearest announcement point.

Unlike unicast (one address per interface) or multicast (explicit group membership), anycast configuration involves assigning the same unicast-format address to multiple interfaces across the network. The address format is identical to unicast—context and configuration determine anycast behavior.

Configuration Requirements:

1. Address Assignment: Each participating node configures the anycast address on a local interface (often a loopback interface for stability).

2. Route Advertisement: Each node must advertise the anycast prefix to the routing domain. Without advertisement, nodes won't attract traffic.

3. Service Equivalence: All nodes must provide functionally identical services for that address.

4. Consistent Policy: Response handling, security policies, and service behavior must be uniform across instances.

Linux Configuration Example:

Assigning an anycast address on a Linux server:

# Assign anycast address to loopback (stable, always up)
ip -6 addr add 2001:db8:53::1/128 dev lo

# Verify assignment
ip -6 addr show dev lo

# In BGP configuration (e.g., FRRouting)
router bgp 65001
  neighbor 2001:db8::ffff remote-as 65000
  address-family ipv6 unicast
    network 2001:db8:53::/48
  exit-address-family

Why Loopback Interface?

Using loopback interfaces for anycast addresses provides:

• Stability: Loopback never goes down due to cable disconnection
• Independence: Not tied to any physical interface state
• Flexibility: Address persists regardless of physical connectivity changes
• Convention: Industry standard practice for anycast and router-ID addresses

If the anycast address were on eth0 and the cable was disconnected, the address would disappear from the system, potentially causing routing inconsistencies.

The magic of anycast lies entirely in standard routing protocol behavior—no anycast-specific mechanisms are needed. Understanding how routing produces nearest-node selection clarifies both anycast's power and its limitations.

BGP-Based Global Anycast:

For Internet-scale anycast (like DNS root servers), BGP is the enabling technology:

1. Multi-Origin Announcement: Each anycast instance's AS announces the anycast prefix to its BGP peers

2. AS Path Construction: Each announcement carries the originating AS. All announcements for the same prefix appear as alternative routes.

3. Best Path Selection: Each receiving router applies BGP best-path selection:

   • Prefer highest local preference
   • Prefer shortest AS path
   • Prefer lowest origin type (IGP < EGP < incomplete)
   • Prefer lowest MED
   • Prefer external (eBGP) over internal (iBGP)
   • Prefer nearest IGP neighbor
   • Prefer lowest router-ID

4. Convergent Selection: After convergence, each router has exactly one best path to the anycast prefix, pointing toward the nearest instance from that router's perspective.

IGP-Based Internal Anycast:

Within an organization, OSPF or IS-IS can provide anycast routing:

1. Each anycast instance redistributes or originates the anycast route into the IGP
2. SPF calculation finds shortest paths to all instances
3. Each router installs the nearest instance as next-hop
4. Load balancing may be enabled (ECMP) if multiple instances are equidistant

Equal-Cost Multi-Path (ECMP) Considerations:

When two anycast instances are equidistant (same metric), routers may install both as valid next-hops and load-balance between them. This can be beneficial (spreading load) or problematic (splitting TCP flows across different servers).

For stateless protocols like DNS, ECMP is generally acceptable. For stateful protocols, ECMP can break sessions when different packets reach different instances. Solutions include:

• Consistent hashing (same source always reaches same instance)
• Disabling ECMP for anycast prefixes
• Using anycast only for initial discovery, then switching to unicast

Anycast excels for specific use cases where its properties—automatic nearest selection, transparent failover, geographic distribution—align with service requirements. Let's examine the primary applications:

DNS (The Canonical Anycast Application):

DNS is perfectly suited for anycast:

• Stateless: Each query is independent; no session state to maintain
• UDP-dominant: Most queries are single UDP request/response pairs
• Latency-sensitive: Users experience DNS latency as page load delay
• Fault-tolerant requirement: DNS failures break all Internet connectivity

The 13 DNS root server identities (A through M) use anycast extensively. For example, the 'F' root server (F.root-servers.net) operates from 250+ global locations, all sharing address 2001:500:2f::f. Users worldwide query their nearest instance automatically.

Content Delivery Networks (CDNs):

CDNs deploy anycast for automatic geographic optimization:

1. CDN edge servers worldwide share an anycast address
2. Users connect to their nearest edge automatically
3. Content is delivered from nearby cache, minimizing latency
4. If an edge fails, users seamlessly fail over to the next-nearest

Many CDNs combine anycast with DNS-based load balancing:

• Initial DNS query uses anycast for resolver selection
• DNS response contains the nearest edge server's unicast address
• Content transfer uses unicast (avoiding anycast's stateful limitations)

DDoS Mitigation:

Anycast provides inherent DDoS protection:

• Attack Distribution: Attack traffic is automatically spread across all anycast instances based on attackers' locations
• No Single Bottleneck: No single server receives 100% of attack traffic
• Absorptive Capacity: Combined capacity of all instances handles aggregate attack volume
• Geographic Containment: Attack impact is localized to instances nearest the attack sources

IPv6 mandates a specific anycast address for every subnet: the Subnet-Router Anycast Address. This address has the all-zeros interface identifier combined with the subnet prefix.

Structure:

Subnet Prefix:           2001:db8:1234:5678::/64
Subnet-Router Anycast:   2001:db8:1234:5678::/128   (or ::0 interface ID)

                         2001:db8:1234:5678:0000:0000:0000:0000
                         └──────────────────┘└────────────────┘
                              64-bit prefix   64 bits all zeros

Purpose and Behavior:

1. Automatic Assignment: Every router on a subnet automatically holds this anycast address for that subnet. No explicit configuration needed.

2. Router Discovery Alternative: Hosts can use this address to reach any router on the subnet—useful for mobile nodes needing quick router contact.

3. Redundancy Foundation: In multi-router subnets, packets to this address reach the nearest router, providing rudimentary redundancy.

4. Implementation Requirement: All routers MUST recognize packets to this address as locally-destined; they must not forward them.

Reserved Anycast Addresses:

Beyond the Subnet-Router Anycast, IPv6 reserves other anycast addresses for specific purposes:

Practical Usage Scenario:

Mobile IPv6 uses Subnet-Router Anycast when a mobile node needs to quickly contact a router on a foreign network:

1. Mobile node arrives on new subnet
2. Node sends to Subnet-Router Anycast address of new subnet
3. Nearest router receives and responds
4. Mobile node uses response to configure on new subnet

This is faster than waiting for periodic Router Advertisements (which can take up to MaxRtrAdvInterval seconds).

While anycast offers powerful capabilities, it comes with significant constraints that must be understood to avoid architectural failures.

The Statefulness Problem:

Anycast's most fundamental limitation is its incompatibility with stateful protocols:

1. Session State: TCP requires that all packets of a connection reach the same endpoint. Anycast cannot guarantee this during routing changes.

2. Routing Dynamics: When link costs change, traffic may shift to a different instance mid-connection. The new instance has no TCP state; the connection fails.

3. ECMP Hazards: If ECMP splits packets across instances, TCP never establishes (sequence numbers appear random to each instance).

4. Asymmetric Paths: Return traffic follows potentially different paths—fine for UDP, problematic for protocols expecting symmetric flows.

Operational Challenges:

1. Debugging Difficulty: When anycast misbehaves, determining which instance served a request is non-trivial. Logs must correlate across distributed instances.

2. Monitoring Complexity: Traditional ping/traceroute to anycast addresses only reaches the nearest instance—verifying all instances requires explicit testing from multiple locations.

3. Health Check Integration: If an instance fails, its routes must be withdrawn from the routing domain. This requires integration between service health checks and routing protocol configuration.

4. Capacity Planning: Traffic distribution depends on topology, not explicit weights. An instance may receive disproportionate load simply because it's "nearest" to many users.

5. Geographic Unpredictability: BGP routing doesn't guarantee geographic proximity. A "nearest" instance in routing terms may be physically distant due to peering arrangements.

Successful anycast deployments follow established patterns that maximize benefits while mitigating limitations.

Pattern 1: Anycast + Unicast Hybrid

Use anycast for discovery, unicast for communication:

1. Client queries anycast DNS resolver
2. Resolver responds with nearby server's unicast address
3. Client communicates with unicast address directly
4. TCP connections are unaffected by routing changes

This pattern is used by most CDNs—anycast selects the edge, unicast serves content.

Pattern 2: Stateless Service Anycast

Deploy purely stateless services on anycast:

• DNS authoritative servers
• NTP time servers
• Certificate validation (OCSP)
• Health check endpoints

No session state means any instance can handle any request.

Pattern 3: Edge Termination

Terminate TCP at anycast edges, proxy to backends:

1. Anycast edge receives TCP connection
2. Edge maintains local TCP state
3. Edge forwards requests to backend (unicast or internal anycast)
4. Response returns through same edge

Cloudflare, Google, and other global services use this extensively.

We've explored IPv6 anycast addressing from concept through implementation—understanding how one-to-nearest delivery emerges from standard routing, where it excels, and where it fails. Let's consolidate the essential knowledge: