IPv6 Address Types: A Comprehensive Classification

In the IPv4 world, a device without DHCP or manual configuration cannot communicate—it has no address, and therefore no identity on the network. IPv6 fundamentally changes this paradigm through link-local addresses: automatically-generated, mandatory addresses that require no configuration, no DHCP server, no manual intervention.

The moment an IPv6 interface becomes active, it automatically generates a link-local address and can immediately communicate with neighbors on the same network segment. This single capability enables everything else in IPv6—router discovery, address configuration, neighbor resolution, and routing protocol operation all rely on link-local addresses.

This page explores link-local addresses in complete depth—their structure, generation methods, operational role, and the profound architectural implications of guaranteed local connectivity.

Link-local addresses are IPv6 addresses that are valid only within a single network segment—they are never routed beyond the local link. Every IPv6 interface must have a link-local address; it's not optional, not configurable, but a mandatory requirement for IPv6 operation.

Fundamental Characteristics:

1. Automatic Generation: The instant an interface is enabled for IPv6, it generates a link-local address without any configuration. This happens before any router advertisements, before DHCP, before anything else.

2. Mandatory Presence: An IPv6 interface without a link-local address cannot participate in IPv6 networking. The address is essential for Neighbor Discovery Protocol (NDP), which in turn is essential for everything else.

3. Non-Routable: Link-local addresses are explicitly forbidden from being routed. Routers must drop any packet with a link-local source or destination that would cross a router boundary.

4. Ambiguity Across Interfaces: The same link-local address can exist on multiple network segments (e.g., fe80::1 can appear on every link in the world). They are unique only within their link—hence the term "link-local."

5. Permanent Stability: Unlike global addresses that may change due to prefix updates, privacy rotations, or renumbering, link-local addresses remain constant for the interface's lifetime.

Address Structure:

┌───────────────────────────────────────────────────────────────────┐
│                          128 bits                                 │
├────────────────────────────────────┬──────────────────────────────┤
│           64 bits                  │          64 bits             │
│       Fixed Prefix                 │     Interface Identifier     │
└────────────────────────────────────┴──────────────────────────────┘
        fe80:0000:0000:0000                Generated from interface
        (always this value)                (various methods)

The first 64 bits are always fe80:0000:0000:0000 (or fe80::). The second 64 bits contain the interface identifier, generated through one of several methods.

Generation Methods:

1. Modified EUI-64 (Traditional)

Derived from the Ethernet MAC address:

MAC Address:     00:1c:42:ab:cd:ef
                 │    │    │    │
                 ▼    ▼    ▼    ▼
Split:           00:1c:42   ab:cd:ef
                      │
Insert fffe:     00:1c:42:ff:fe:ab:cd:ef
                 │
Flip bit 7:      02:1c:42:ff:fe:ab:cd:ef

Link-Local:      fe80::21c:42ff:feab:cdef

The 7th bit (Universal/Local bit) is inverted: 0→1 means locally-administered becomes globally unique in EUI-64 terminology.

2. Privacy-Oriented Stable IID (RFC 7217)

Modern systems generate interface identifiers that are:

• Stable per-network (same IID when reconnecting to known network)
• Different across networks (different IID on each network)
• Unpredictable (cannot be guessed from external information)

The algorithm uses: IID = First_64_bits(SHA-256(Prefix + Interface_Name + Network_ID + DAD_Counter + Secret_Key))

This prevents MAC address tracking while maintaining stability.

3. Random Generation

Some implementations generate fully random IIDs for link-local addresses, regenerating on each boot. This maximizes privacy but reduces stability for local services.

4. Manual Configuration (Discouraged)

Administrators can manually configure link-local addresses, but this is generally discouraged—automatic generation is reliable, and manual configuration risks conflicts or inconsistencies.

Because link-local addresses are unique only within their link, a device with multiple interfaces faces ambiguity: if it has fe80::1 on eth0 and wants to communicate with fe80::2, which link is intended? The answer: Zone IDs (also called Scope IDs).

Zone ID Concept:

A zone ID appends to a link-local address, specifying which interface/link the address refers to:

fe80::1%eth0      →  fe80::1 on the eth0 link
fe80::1%wlan0     →  fe80::1 on the wlan0 link
fe80::1%12        →  fe80::1 on interface index 12

The zone ID is purely local—it has no meaning beyond the local machine and is never transmitted in packets. It's a host-local disambiguation mechanism.

Zone ID Syntax by Platform:

When Zone IDs Are Required:

1. Ping/Connectivity Tests: ping fe80::1 fails ambiguously; ping fe80::1%eth0 succeeds

2. SSH/Application Connections: ssh fe80::1%eth0 specifies the network path

3. Routing Protocol Configuration: May require zone specification for neighbor addresses

4. Multi-homed Hosts: Any machine with multiple IPv6 interfaces needs zone IDs for link-local communication

When Zone IDs Are Implicit/Unnecessary:

1. Single-Interface Hosts: Only one link exists; zone is unambiguous

2. Incoming Connections: The receiving interface is determined by packet arrival, not address

3. Global Addresses: No zone needed; global addresses are globally unique

4. Packet Transmission: The kernel selects outgoing interface based on routing; zone ID is resolved before transmission

Neighbor Discovery Protocol (NDP) is IPv6's mechanism for address resolution, router discovery, prefix discovery, and more. Crucially, NDP operates entirely over link-local addresses. This design decision has profound implications.

NDP Functions Using Link-Local:

1. Router Solicitation/Advertisement: Hosts discover routers and prefixes
2. Neighbor Solicitation/Advertisement: Address resolution (replacing ARP)
3. Redirect Messages: Routers inform hosts of better paths
4. Duplicate Address Detection (DAD): Ensures address uniqueness

Why Link-Local for NDP?

Using link-local addresses for NDP provides:

1. Zero-Configuration Operation: Hosts can perform NDP immediately upon generating their link-local address—no global address needed.

2. Infrastructure Independence: If global prefix allocation fails (DHCP down, RA not received), local network operations continue via link-local.

3. Security Boundary: NDP messages never leave the local link; they cannot be injected from remote networks.

4. Stability: Link-local addresses don't change during renumbering operations; NDP continues uninterrupted while global prefixes transition.

Router Advertisement Structure:

Router Advertisement (RA)
├── ICMPv6 Type: 134
├── Source Address: fe80::1 (router's link-local)
├── Destination: ff02::1 (all-nodes multicast)
├── Hop Limit: 255 (mandatory for NDP)
├── Router Lifetime: 1800 seconds
├── Options:
│   ├── Source Link-Layer Address: 00:1c:42:ab:cd:ef
│   ├── MTU Option: 1500
│   └── Prefix Information:
│       ├── Prefix: 2001:db8:1::/64
│       ├── Valid Lifetime: 2592000
│       ├── Preferred Lifetime: 604800
│       └── Flags: L (on-link), A (autonomous)

Note: The source address is the router's link-local address (fe80::1), even though the advertised prefix is global (2001:db8:1::/64). Hosts use this link-local address as their default gateway.

IPv6 routing protocols—OSPFv3, EIGRP for IPv6, IS-IS, and BGP (for neighbor peering)—use link-local addresses for neighbor relationships. This architectural choice provides significant operational advantages.

How Routing Protocols Use Link-Local:

1. Neighbor Discovery: Hello packets are sourced from and addressed to link-local addresses

2. Next-Hop Identification: Routing tables point to link-local addresses as next-hops

3. Adjacency Formation: Router adjacencies are formed between link-local addresses

4. LSA/Update Exchange: Routing updates (LSAs in OSPF, updates in EIGRP) flow between link-local addresses

Routing Table Example:

router# show ipv6 route

IPv6 Routing Table - 10 entries

O   2001:db8:1::/64 [110/1]
     via fe80::1, Ethernet0/0            ← Link-local next-hop

O   2001:db8:2::/64 [110/2]
     via fe80::2, Ethernet0/1            ← Link-local next-hop

S   ::/0 [1/0]
     via fe80::1, Ethernet0/0            ← Default route to link-local

Every next-hop is a link-local address, even for global destination prefixes.

Why This Design Is Superior:

1. Renumbering Immunity: When an organization changes its global prefix (changing ISPs, for example), routing adjacencies remain intact. Link-local addresses never change, so OSPF neighbors, EIGRP neighbors, and BGP sessions continue uninterrupted. Only the route destinations change—not the forwarding paths.

2. Configuration Simplicity: Neighbor statements can use predictable link-local addresses. neighbor fe80::1 works regardless of what global prefixes are assigned.

3. Troubleshooting Clarity: Link-local addresses identify the physical network segment. When you see next-hop fe80::1%eth0, you know exactly which interface and link the traffic traverses.

4. Stability: Global addresses may be deprecated, temporary, or multiple. Link-local addresses are singular and permanent—ideal for infrastructure relationships.

OSPFv3 Neighbor Configuration:

interface Ethernet0/0
  ipv6 ospf 1 area 0
  ! Neighbor adjacency forms automatically using link-local addresses
  ! No explicit neighbor statement needed on broadcast/point-to-point

OSPFv3 discovers neighbors via link-local multicast (ff02::5, ff02::6) and forms adjacencies using discovered link-local addresses.

Link-local addresses have unique security properties—some beneficial, some requiring careful consideration.

Inherent Security Benefits:

1. Natural Isolation: Link-local traffic cannot leave the local segment. An attacker on a remote network cannot directly target your link-local addresses.

2. Control Plane Protection: Since NDP, routing protocols, and management functions use link-local, they're naturally protected from remote attacks.

3. Attack Surface Reduction: Services bound to link-local addresses are inaccessible from the Internet by architecture, not just firewall rules.

4. Spoofing Difficulty: To spoof link-local communication, an attacker must be physically present on the same L2 segment.

Security Concerns:

1. Local Segment Attacks: An adversary with L2 access can attack link-local services directly. Rogue Router Advertisements, NDP spoofing, and other attacks target link-local infrastructure.

2. Router Advertisement Attacks: Malicious RAs can redirect default gateways, announce false prefixes, or deny service. RA Guard (IEEE 802.1AR) mitigates this at the switch level.

3. NDP Spoofing: Without Secure Neighbor Discovery (SEND), NDP is vulnerable to spoofing attacks analogous to ARP spoofing in IPv4.

4. Management Exposure: If management interfaces use link-local addresses, any local attacker gains management access.

Mitigation Strategies:

Understanding how link-local addresses participate in everyday network operations solidifies theoretical knowledge.

Scenario: Host Boot and Configuration

1. Interface eth0 comes up
   └── Automatic action: Generate link-local fe80::21c:42ff:feab:cdef

2. Join multicast groups
   ├── ff02::1 (all-nodes)
   └── ff02::1:ffab:cdef (solicited-node for link-local)

3. Perform DAD for link-local address
   ├── Send NS to ff02::1:ffab:cdef (source ::)
   ├── Wait for NA (if received, address conflict)
   └── No conflict → Address usable

4. Send Router Solicitation
   ├── Source: fe80::21c:42ff:feab:cdef  ← Link-local!
   ├── Destination: ff02::2 (all-routers)
   └── Purpose: Request immediate RA

5. Receive Router Advertisement
   ├── From: fe80::1 (router's link-local)  ← Link-local!
   ├── Contains: Prefix 2001:db8:1::/64, Lifetime info
   └── Host installs fe80::1 as default gateway

6. Configure global address via SLAAC
   ├── Combine prefix 2001:db8:1::/64 + interface ID
   ├── Result: 2001:db8:1::21c:42ff:feab:cdef
   └── Perform DAD for new global address

Notice: Steps 1-5 (link-local generation through RA reception) happen before any global address exists. Link-local enables everything that follows.

We've thoroughly explored link-local addresses—the mandatory, automatically-generated addresses that form the foundation of all IPv6 operation. Let's consolidate this essential knowledge: