How IPv6 Addressing Actually Works

People often describe IPv6 as "IPv4 but with more addresses". That is like describing a container ship as "a lorry that floats". It points at one visible difference and misses the design choices that make the system behave differently.

IPv6 addressing is not only bigger. It changes the normal shape of a host's identity on the network. One interface can have several addresses at once. Scope becomes explicit. Broadcast disappears. The default gateway is often known only by a link-local address. A residential line in Athens may receive a delegated /56, then slice it into 256 separate /64 LANs without touching NAT at all. A laptop may use one stable address for inbound reachability, one temporary address for outbound privacy, and a link-local address that never leaves the local segment.

That is why teams that "understand the notation" still get tripped up by real IPv6 networks. The hard part is not compressing zeros in hexadecimal. The hard part is understanding what the bits are for, how hosts build addresses, why /64 keeps showing up, why fe80::1 needs an interface zone, how neighbour discovery replaces ARP, and why routers hand out prefixes rather than single host addresses.

This article follows the addressing model from the inside out: address structure, scopes, address assignment, interface identifiers, prefix delegation, multicast-based neighbour discovery, source-address selection, and the operational mistakes that keep breaking otherwise good IPv6 deployments.

1. An IPv6 Host Usually Has Several Addresses, Not One

IPv4 trained people to expect one main address per interface. There may be aliases, but the mental model is still singular: this machine is 192.168.1.42.

IPv6 breaks that expectation immediately.

A normal client interface often holds at least:

• one link-local address in fe80::/10
• one global unicast address from the site's routed prefix
• one or more temporary global addresses for outbound privacy
• sometimes a stable secondary address for services or long-lived reachability

Run this on a Linux host with IPv6 enabled and the output often looks more crowded than people expect:

$ ip -6 addr show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    inet6 fe80::1c2b:44ff:fe8a:9d11/64 scope link
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1200:34:8d6a:72c1:48f0:19a2/64 scope global dynamic mngtmpaddr
       valid_lft 86384sec preferred_lft 14384sec
    inet6 2001:db8:1200:34:4c6d:54f7:ce20:6ad3/64 scope global temporary dynamic
       valid_lft 86384sec preferred_lft 7184sec

That one interface already tells most of the IPv6 story.

• fe80::... works only on the local link.
• 2001:db8:... is globally scoped and can be routed beyond the LAN.
• the host may prefer the temporary address for new outbound connections, so remote sites do not see a long-lived stable interface identifier in every session.

This multi-address model is normal, not exceptional. It lets IPv6 separate roles that IPv4 often forced into one identifier.

A link-local address answers "how do I talk to neighbours and routers on this Ethernet or Wi-Fi segment right now?" A global address answers "how can the wider routed network reach me?" A temporary address answers "how do I avoid reusing the same stable host identifier for every outbound connection?"

That is already a more expressive design than IPv4 private addressing plus NAT. NAT in IPv4 often hid the shortage of public addresses by collapsing many internal hosts behind one translated identity. IPv6 prefers to keep end hosts individually addressable and solve privacy separately.

The first operational consequence is simple: when you see more than one IPv6 address on an interface, that is usually healthy. The second is less obvious: when troubleshooting, you have to ask which address the host will actually choose for this destination and why.

2. The Bit Layout Matters More Than the Hex Notation

Yes, IPv6 addresses are 128 bits long. Yes, they are written as eight groups of four hexadecimal digits. That part is easy.

Example:

2001:0db8:1200:0034:4c6d:54f7:ce20:6ad3

Leading zeros inside each 16-bit block can be omitted:

2001:db8:1200:34:4c6d:54f7:ce20:6ad3

One contiguous run of zero blocks can be compressed with :: once per address:

2001:db8:1200:34::1

That syntax is worth knowing, but the addressing model is in the bit split.

On most LANs, the division looks like this:

|  network prefix (64 bits)  |  interface identifier (64 bits)  |

So for:

2001:db8:1200:34:4c6d:54f7:ce20:6ad3/64

• network prefix: 2001:db8:1200:34::/64
• interface identifier: 4c6d:54f7:ce20:6ad3

That /64 is not a random habit. It is the standard subnet size that Stateless Address Autoconfiguration, neighbour discovery assumptions, and much host software expect on ordinary multi-access links.

People coming from IPv4 often ask why a home LAN "wastes" so many addresses. That question imports the wrong scarcity model. IPv6 is designed so that subnets are plentiful and hosts can derive local identifiers comfortably inside them. The design goal is operational simplicity, not squeezing every bit as if the internet still had only 4.3 billion addresses.

Nibble Boundaries Matter Operationally

IPv6 addresses are written in hexadecimal, and each hex digit represents four bits. This means prefix lengths that align on nibble boundaries are easier to read and delegate.

Examples:

• /32 aligns after eight hex digits
• /48 aligns after twelve hex digits
• /56 aligns after fourteen hex digits
• /64 aligns after sixteen hex digits

Suppose an ISP assigns:

2001:db8:1200:3400::/56

The customer can then carve out 256 clean /64 LANs:

2001:db8:1200:3400::/64
2001:db8:1200:3401::/64
2001:db8:1200:3402::/64
...
2001:db8:1200:34ff::/64

That is one reason /56 is a common residential delegation size. It is operationally neat.

Text Form Does Not Change Identity

These two addresses are identical:

2001:0db8:0000:0000:0000:0000:0000:0001
2001:db8::1

Log search tools, ACLs, and inventory systems that treat them differently are broken. Normalisation matters. When operators say "we could not match the address in the logs", a surprisingly common root cause is that one system stored the full form and another compressed form.

The human-readable notation matters because humans debug networks. The network, however, sees only 128 bits.

3. Scope Is Built Into the Addressing Model

IPv4 has private ranges and public ranges, but scope is comparatively crude. IPv6 makes scope much more explicit.

The important categories are:

• link-local: fe80::/10
• global unicast: usually within 2000::/3
• unique local: fc00::/7, commonly fdxx: in practice
• multicast: ff00::/8
• loopback: ::1
• unspecified: ::

Link-Local Addresses

Every IPv6-enabled interface can form a link-local address. This address only works on the local Layer 2 segment. Routers do not forward it.

That sounds modest. It is actually foundational. Neighbour discovery, router discovery, and many first-hop operations depend on link-local addressing. A host can talk to its local router before it has any global address at all.

This is also why a default route often looks like this on Linux:

$ ip -6 route show
default via fe80::1 dev wlan0 proto ra metric 600
2001:db8:1200:34::/64 dev wlan0 proto ra metric 600
fe80::/64 dev wlan0 proto kernel metric 256

The next hop is fe80::1, not some global address. The router only needs to be reachable on the local link to serve as a next hop.

Global Unicast

Global unicast addresses are the normal public IPv6 space. In practice they live under 2000::/3.

These addresses are meant to be routed across the public internet. If your ISP delegates a prefix and your firewall policy allows inbound traffic, devices can be addressed directly without NAT.

That is one of the big conceptual shifts for teams used to IPv4 home routers. Reachability and filtering are separate concerns. NAT is not the main safety boundary. Stateful firewalls still matter, sometimes more than ever.

Unique Local Addresses

Unique local addresses, often written with an fd prefix, are the IPv6 equivalent of a site-local private realm for internal use.

Example:

fd7a:2c4e:9b10:12::/64

ULAs are not meant to be routed globally. They are useful for internal services, lab environments, and networks that want stable internal addressing independent of upstream provider space.

Unlike old IPv4 habits, ULAs are not required just because a network wants internal communication. Many IPv6 sites use only global space internally and rely on firewall policy to control exposure. ULAs are a tool, not a mandate.

Multicast Replaces Broadcast

IPv4 leans heavily on broadcast. IPv6 removes broadcast entirely. The protocol uses multicast where one-to-many local signalling is needed.

That one change reshapes local discovery behaviour. Instead of flooding every node on the link with a generic broadcast, IPv6 can target multicast groups with narrower relevance. Neighbour discovery takes advantage of this heavily, which we will get to later.

4. Address Assignment Starts with Link-Local, Then Builds Upward

The first IPv6 address a host normally forms is not global. It is link-local.

A simplified boot sequence on a normal LAN looks like this:

1. interface comes up
2. host forms a tentative link-local address
3. host runs Duplicate Address Detection
4. host uses router solicitation and listens for router advertisements
5. host learns on-link prefixes, default route, and possibly DHCPv6 hints
6. host forms additional addresses from the learned prefix

You can see the router-advertisement path with tools such as rdisc6 or a packet capture:

$ sudo tcpdump -n -i wlan0 icmp6

Typical early ICMPv6 traffic includes:

• Router Solicitation, type 133
• Router Advertisement, type 134
• Neighbour Solicitation, type 135
• Neighbour Advertisement, type 136

Stateless Address Autoconfiguration

Stateless Address Autoconfiguration, defined mainly in RFC 4862, is what most people mean when they say "IPv6 configures itself".

A router advertisement can carry a Prefix Information Option like this:

Prefix: 2001:db8:1200:34::/64
A flag: 1   (autonomous address configuration allowed)
L flag: 1   (prefix is on-link)
Valid lifetime: 86400 seconds
Preferred lifetime: 14400 seconds

If the autonomous flag is set, the host can form its own address inside that prefix by combining the /64 network portion with an interface identifier.

The router does not assign host number 42 the way a DHCPv4 server often does. It announces a prefix and policy. The host completes the address locally.

DHCPv6 Exists, but It Is Not the Whole Story

DHCPv6 can still be part of the system. Routers may use flags in the RA to tell hosts whether to use DHCPv6 for address assignment, for extra configuration, or both.

Common combinations:

• SLAAC only: host forms address from prefix, learns route from RA
• SLAAC + stateless DHCPv6: address via SLAAC, extras such as DNS via DHCPv6
• stateful DHCPv6: address leased by DHCPv6, route still usually learned from RA on many networks

That last detail surprises people. Even with DHCPv6, router advertisements often remain part of the design because first-hop routing and neighbour discovery are still ICMPv6 functions.

Duplicate Address Detection

Before an address becomes usable, the host checks whether someone else already uses it.

For a tentative address like:

2001:db8:1200:34:4c6d:54f7:ce20:6ad3

the host sends a Neighbour Solicitation asking whether any node already owns that address. If nobody replies, the address becomes active.

This process is called Duplicate Address Detection, or DAD. It protects against collisions caused by manual configuration mistakes, cloned virtual machines, or broken identifier generation. In a healthy SLAAC environment collisions are rare. The protocol still checks.

The detail worth noticing is where DAD sends that first query. For an address that is still tentative, the host does not source the solicitation from the final global address yet. It usually uses the unspecified source :: and sends the query to the target's solicited-node multicast group. That lets any conflicting owner answer before the candidate becomes live.

A simplified trace looks like this:

Source: ::
Destination: ff02::1:ff20:6ad3
ICMPv6 Type 135: Neighbour Solicitation
Target Address: 2001:db8:1200:34:4c6d:54f7:ce20:6ad3

If another host already owns that target address, it answers with a Neighbour Advertisement and the new host marks the address as duplicate. If nobody answers, the host promotes the tentative address to preferred or valid use according to the learned lifetimes. That small exchange is one reason cloned virtual appliances with copied secrets or copied stable-IID seeds can create surprisingly stubborn local faults.

The same first-hop logic also explains why some virtualisation bugs look intermittent. If two machines boot on different VLANs, the duplicate never becomes visible. If they later land on the same segment, DAD suddenly exposes the collision. The address plan did not become invalid at that moment. The hosts only became close enough to detect it.

5. Interface Identifiers Changed Because Privacy Changed

The lower 64 bits of a normal /64 address are the interface identifier, often shortened to IID. How that IID is formed has changed significantly over time.

The Old EUI-64 Habit

In early IPv6 deployments, hosts commonly derived the IID from the NIC's MAC address using a modified EUI-64 process.

If the MAC was:

00:25:96:12:34:56

then the IID might be formed roughly as:

0225:96ff:fe12:3456

That had one obvious convenience: uniqueness was easy, because MAC addresses were meant to be globally unique.

It also had one obvious privacy problem: every network the laptop joined saw the same stable hardware-derived identifier in the address.

Stable Opaque Identifiers

Modern hosts usually avoid raw MAC-derived IIDs for ordinary global addresses. RFC 7217 describes a better approach: generate a stable but opaque IID using a secret value, the prefix, and interface-specific context.

The practical result is good enough for operators:

• the address stays stable within a given prefix, which helps local management
• the IID does not reveal the hardware MAC
• the same laptop gets different stable IIDs on different networks

Temporary Addresses for Outbound Connections

RFC 8981 describes temporary addresses, sometimes called privacy extensions. These are extra global addresses with rotating IIDs that hosts often prefer for new outbound connections.

That is why ip -6 addr commonly shows both a stable global address and a temporary one.

The logic is sensible:

• stable address is useful for local policy and sometimes inbound reachability
• temporary address reduces long-term correlation of outbound client traffic

Servers often disable temporary-address preference because they want durable, predictable source addresses. Clients often enable it because they care more about privacy than inbound stability.

Why This Matters in Logs

If you operate services, do not assume one user equals one IPv6 address forever. A browser on a consumer line may rotate temporary addresses while staying inside the same delegated prefix. Identity, abuse controls, and rate limiting should often consider prefix information and authentication context, not just one full 128-bit value.

That does not mean you should aggregate everything by /64 blindly. It means the addressing model includes stability and instability by design.

6. Prefix Delegation and Subnetting Are Where IPv6 Feels Different from IPv4

IPv6 addressing starts to make sense when you stop asking "how many hosts fit on this subnet?" and start asking "how much structured space does this site have to delegate internally?"

The Typical Allocation Ladder

A common public-allocation shape looks like this:

• Regional Internet Registry allocation to an ISP, often /32 or similar
• customer site allocation such as /48 for larger sites or /56 for residential service
• individual LANs as /64

This is not a hard law for every provider, but it is common enough to anchor your intuition.

Why /64 Keeps Coming Back

On ordinary LANs, /64 is the standard because SLAAC and related mechanisms assume 64-bit interface identifiers. When people try to run /80 or /112 on a general client LAN, they usually discover that the savings are imaginary and the compatibility pain is real.

There are exceptions on special links. Point-to-point router links may use /127 to avoid certain edge cases and because there are no SLAAC clients on the segment. Infrastructure links and loopbacks can use other prefix lengths deliberately. The important point is that host LANs and infrastructure links have different design rules.

A Residential /56 Example

Suppose an ISP in Greece delegates:

2001:db8:1200:3400::/56

The customer can create:

2001:db8:1200:3400::/64   main home LAN
2001:db8:1200:3401::/64   work devices
2001:db8:1200:3402::/64   IoT devices
2001:db8:1200:3403::/64   guest Wi-Fi

and still have 252 more /64 networks available.

In IPv4 a home router often chops one private /24 into VLANs only with careful NAT and firewall planning. In IPv6, abundant prefix space makes segmentation much more natural.

Prefix Delegation to Downstream Routers

A larger site may also pass chunks of delegated prefix space onward. One edge router receives a site prefix, then hands /64 or /60 blocks to internal routers through DHCPv6 Prefix Delegation or manual routing design.

That means IPv6 addressing is about hierarchy as much as host count. Prefixes travel down the topology. Routers advertise them on local links. Hosts self-complete addresses inside them.

Renumbering Is Expected

Because prefixes are delegated structurally, IPv6 was built with renumbering in mind. If a provider changes the upstream prefix, router advertisements can introduce the new one and deprecate the old one with lifetimes.

This does not make renumbering painless. Firewalls, ACLs, logs, DNS, and static config still need discipline. But the protocol machinery at least assumes that prefixes may change and gives hosts a graceful path to hold old and new addresses simultaneously during transition.

It also helps to quantify what the common delegation sizes mean in practice:

That table is why experienced IPv6 operators get uneasy when providers hand out a single /64 to a whole site. Technically one LAN can function. Operationally the customer loses the clean ability to segment guest Wi-Fi, servers, cameras, lab equipment, and workstations into separate prefixes without introducing awkward workarounds.

IPv4 habits make 256 LANs sound excessive. In IPv6 terms it is modest and useful. A hotel, school, or office building can spend that space surprisingly quickly once every floor, SSID, tenant segment, and infrastructure zone gets its own subnet. The address architecture is trying to make that kind of planning ordinary rather than exceptional.

7. Neighbour Discovery Replaces ARP and Uses Multicast Carefully

IPv4 relies on ARP to map Layer 3 addresses to Layer 2 addresses on the local link. IPv6 removes ARP and replaces it with Neighbour Discovery Protocol, which runs on ICMPv6.

That change is bigger than a protocol rename. NDP handles:

• address resolution
• neighbour reachability detection
• router discovery
• prefix discovery
• duplicate address detection
• redirects in some cases

No Broadcast, So How Does Local Discovery Work?

Instead of broadcasting "who has this address?" to everyone, IPv6 often uses a solicited-node multicast address derived from the target IPv6 address.

Take this host address:

2001:db8:1200:34:4c6d:54f7:ce20:6ad3

The lower 24 bits are 20:6ad3. Its solicited-node multicast address becomes:

ff02::1:ff20:6ad3

Nodes join multicast groups corresponding to their own solicited-node addresses. When another host wants the target's MAC address, it sends a Neighbour Solicitation to that multicast group instead of waking every node on the link.

This is not perfect precision, because 24 bits can still collide. It is much narrower than broadcast.

A Simplified Neighbour Solicitation Flow

Host A wants to reach Host B on the same /64.

1. Host A sees the destination is on-link.
2. Host A checks its neighbour cache.
3. If no entry exists, Host A sends:

ICMPv6 Type 135: Neighbour Solicitation
Target Address: 2001:db8:1200:34:4c6d:54f7:ce20:6ad3
Destination: ff02::1:ff20:6ad3

4. Host B replies with:

ICMPv6 Type 136: Neighbour Advertisement
Source: 2001:db8:1200:34:4c6d:54f7:ce20:6ad3

5. Host A updates its neighbour cache with Host B's MAC.

On Linux you can inspect that cache with:

$ ip -6 neigh show
fe80::1 dev wlan0 lladdr 00:11:22:33:44:55 router REACHABLE
2001:db8:1200:34:4c6d:54f7:ce20:6ad3 dev wlan0 lladdr 3c:52:82:9a:2b:11 STALE

The neighbour table has states such as REACHABLE, STALE, DELAY, and FAILED, just as with modern IPv4 neighbour management.

Router Discovery Uses the Same Framework

Because NDP includes router discovery, the host learns both local neighbours and first-hop routers through ICMPv6. This is why blocking ICMPv6 casually is much more destructive than some IPv4 operators assume. It does not merely hide diagnostics. It breaks core control traffic.

If you drop the wrong ICMPv6 types, hosts may fail to discover routers, fail to resolve neighbours, or fail path MTU discovery.

8. Source and Destination Address Selection Explain Many Oddities

Once a host has several IPv6 addresses, it needs rules for choosing the right one.

Suppose a laptop has:

• fe80::1c2b:44ff:fe8a:9d11 on wlan0
• 2001:db8:1200:34:8d6a:72c1:48f0:19a2 stable global
• 2001:db8:1200:34:4c6d:54f7:ce20:6ad3 temporary global

Now consider three destinations:

• fe80::1
• fd7a:2c4e:9b10:12::25
• 2001:4860:4860::8888

The host should not use the same source every time.

Scope Matching

A link-local destination needs a link-local source on the same interface. A global destination generally needs a global source. This is one reason the command below requires a zone index:

$ ping -6 fe80::1%wlan0

Without %wlan0, the address is ambiguous because the same link-local value could exist on many interfaces.

RFC 6724 Selection Rules

IPv6 source and destination address selection rules are described in RFC 6724. Implementations may add local policy, but the protocol intent is to prefer addresses with appropriate scope, matching label policy, and sensible lifetime characteristics.

In practice this means:

• link-local traffic stays link-local
• outbound internet traffic from a client often prefers a temporary global source
• a server may prefer a stable global source
• deprecated addresses should not be preferred for new sessions

The Default Route Still Points to a Local Router

Even when the final destination is global, the host's next hop is usually a link-local router address on the LAN. That feels strange at first:

$ ip -6 route get 2001:4860:4860::8888
2001:4860:4860::8888 from 2001:db8:1200:34:4c6d:54f7:ce20:6ad3 via fe80::1 dev wlan0 proto ra

The final destination is global. The router is reached through its local-link identity. Both are true at once.

This is also why tracing a failing IPv6 path requires care. A host can have a perfectly fine global address and still fail because it cannot reach fe80::1 as its first hop.

9. The Common Operational Mistakes Are Usually Design Mistakes

IPv6 addressing problems often look mysterious because the visible symptom appears several layers away from the actual mistake.

Using Non-/64 Prefixes on Ordinary Client LANs

This keeps happening. Someone thinks a /80 is more "efficient". Then SLAAC breaks, some client stacks behave oddly, neighbour discovery assumptions stop matching, and everyone wastes a day rediscovering why the design centre of IPv6 host LANs is /64.

If the segment is a normal multi-host LAN, use /64 unless you have a specific reason and have validated every stack involved.

Blocking ICMPv6 Too Aggressively

Security teams that grew up on bad IPv4 firewall folklore sometimes block ICMPv6 broadly. Then router discovery fails, path MTU discovery fails, neighbour reachability becomes erratic, and large TCP sessions mysteriously stall.

ICMPv6 is not optional plumbing. It is part of the control plane.

Forgetting Privacy-Address Churn in Monitoring

If your abuse tooling, asset inventory, or user analytics assume one stable client IP, temporary addresses can look like chaos. The fix is not to disable privacy everywhere by reflex. The fix is to model the system correctly.

Logging Only Full Addresses Without Prefix Context

A consumer device may rotate interface identifiers while staying inside the same delegated customer prefix. If incident response systems throw away prefix relationships, they lose useful topology context.

Again, do not overcorrect by treating every /64 as one identity automatically. Just recognise that the prefix hierarchy carries meaning.

Ignoring Router Advertisements in Troubleshooting

On IPv4, a lot of local addressing comes from DHCP alone. On IPv6, many failures are visible in router advertisements, prefix lifetimes, or neighbour discovery. If the packet capture does not include ICMPv6 control traffic, the investigation is missing the most interesting part.

Treating NAT as the Missing Safety Mechanism

Some teams are uneasy when every host has a real routable address. They try to re-create IPv4 scarcity thinking instead of enforcing proper stateful firewall policy.

IPv6 addressing does not remove access control. It removes the need to overload access control onto address translation.

Ignoring Path MTU Discovery and ICMPv6 Packet Too Big

IPv4 networks often limp along because routers can fragment packets or middleboxes quietly hide the consequences of bad MTU assumptions. IPv6 moved in the opposite direction. Routers do not fragment in transit. If a packet is too large for some hop, the network has to send back an ICMPv6 Packet Too Big message so the sender can reduce packet size.

When operators block that message class out of habit, large flows can fail in ways that look unrelated to addressing. Small pings work. DNS works. A TLS connection may even start. Then a larger response stalls because the sender never learns the real path MTU. People blame the application while the actual fault sits in overzealous ICMPv6 filtering.

This belongs in an addressing article because first-hop IPv6 design assumes that control information travels through ICMPv6. Address discovery, router discovery, and path size feedback all ride the same family of messages. If your operational model treats ICMPv6 as optional noise, the addressing model will look unreliable when the real problem is that the network is dropping its own signalling.

Forgetting RA Guard and First-Hop Trust Boundaries

IPv6 makes routers visible through router advertisements. That is elegant when the right device is advertising. It is dangerous when any random host can pretend to be the router on an unprotected access port.

An accidental or malicious rogue RA can cause clients to install the wrong default route, deprecate the legitimate prefix, or prefer a hostile first hop for traffic capture. Managed switches therefore often deploy RA Guard or equivalent first-hop protections on access ports. The exact feature quality varies by platform, and operators still need to understand extension-header evasions and platform-specific caveats, but the principle is stable: do not let every edge port behave like a trusted router attachment.

This is the IPv6 version of a first-hop trust problem. The addressing system itself is not broken. It is doing what the local control plane tells it. The job of the access network is to make sure only the real control plane gets to speak with authority.

10. Read the Host's Address Table Like a Story

When IPv6 finally clicks, ip -6 addr and ip -6 route stop looking like random hex and start reading like a live description of how the host is attached to the network.

Take this example:

$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    inet6 fe80::a8f2:5bff:fe10:4421/64 scope link
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1200:3401:8f8c:1b32:ae44:11d0/64 scope global dynamic mngtmpaddr
       valid_lft 86352sec preferred_lft 14352sec
    inet6 2001:db8:1200:3401:5c1b:9a7c:4e20:7012/64 scope global temporary dynamic
       valid_lft 86352sec preferred_lft 7152sec
 
$ ip -6 route show
2001:db8:1200:3401::/64 dev eth0 proto ra metric 100
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::1 dev eth0 proto ra metric 100

That small table already tells you:

• the link is up
• the host formed a link-local address
• the LAN prefix is 2001:db8:1200:3401::/64
• the router advertised the prefix and default route
• the host has both a managed stable-style global address and a temporary outbound address
• the next hop is the router's link-local fe80::1

A packet capture can extend the story:

Router Advertisement from fe80::1
  Prefix Information: 2001:db8:1200:3401::/64
  Autonomous flag: set
  Valid lifetime: 86400
  Preferred lifetime: 14400

You can push the story one step further with two more commands:

$ ip -6 route get 2001:4860:4860::8888
2001:4860:4860::8888 from 2001:db8:1200:3401:5c1b:9a7c:4e20:7012 via fe80::1 dev eth0 proto ra
 
$ ip -6 neigh show dev eth0
fe80::1 lladdr 00:11:22:33:44:55 router REACHABLE

The route lookup shows which source address the kernel currently prefers for that destination and which next hop it will use. In this example the source is the temporary global address, which is typical client behaviour. The next hop is still the router's link-local identity. That one line confirms both source-selection policy and first-hop reachability.

The neighbour table completes the picture. It tells you whether the host can actually resolve the router or peer to a Layer 2 destination. When that entry is REACHABLE, the host has recently confirmed the mapping. When it becomes STALE, the host may still use it but will probe again if traffic continues. When it falls into FAILED, the problem is not upstream BGP, DNS, or a missing global prefix. The host cannot even complete the local-link delivery step.

That is why IPv6 debugging is often more legible than people expect once they know where to look. ip -6 addr explains which identities exist. ip -6 route explains which prefix and next hop the kernel believes in. ip -6 neigh explains whether the local segment can actually deliver frames to the next hop. Together they describe the full first-hop addressing state without guesswork.

One last detail in that toolbox is the zone index on link-local traffic. If you test ping -6 fe80::1 without %eth0 or %wlan0, the command may fail even though the router is healthy. The address is only unique within one link, so the kernel needs the interface context to know which neighbour table and which local segment you mean. That looks fussy until you remember that the same host can have fe80::1 reachable on Ethernet, Wi-Fi, a VPN tunnel, and a virtual bridge at the same time. Link-local scope is precise by design, and the tools expose that precision.

At that point the whole mechanism is visible. Prefix comes from the router. Host self-completes the address. Link-local is used for first-hop control traffic. Temporary addresses rotate for privacy. The /64 is not decoration. It is the design centre.

That is the point where IPv6 addressing stops feeling alien. It is no longer "a very long IP". It is a layered model with explicit scope, abundant delegation space, host-generated identities, and multicast-based local control.

11. IPv6 Addressing Is a Hierarchy, Not a Shortage Economy

The easiest way to misunderstand IPv6 is to keep forcing IPv4 scarcity habits onto it.

IPv4 made people count usable host numbers, conserve subnets, hide everything behind NAT, and think of one address as one machine's single identity. IPv6 keeps addresses globally meaningful, makes subnet abundance normal, expects /64 host networks, separates scope cleanly, and lets one interface carry several addresses for different purposes.

Once you accept that shift, the design becomes much more coherent.

• link-local addresses exist so local control traffic can always function
• router advertisements distribute prefixes and route policy
• hosts form their own addresses rather than waiting for one central allocator in every case
• privacy extensions solve correlation concerns without throwing away end-to-end addressing
• prefix delegation makes internal segmentation natural
• multicast replaces broad local shouting

The notation is the least interesting part. The interesting part is that IPv6 addressing encodes how the network is structured and how the host participates in it.

That is why experienced operators who treat IPv6 as "just more bits" keep getting surprised by it. The extra bits matter. The model built around them matters more.