Networking / Intermediate: lifecycle, trust, and application protocols / Lesson 7

Explain IPv6 addressing and local discovery

Connect IPv6 scopes, prefixes, Neighbor Discovery, router advertisements, and address lifetimes without importing IPv4 assumptions.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Read IPv6 notation and distinguish address scopes.
Explain Neighbor Discovery and router information.
Separate SLAAC, DHCPv6, and address lifecycle evidence.

Compact notation still represents 128 bits

IPv6 addresses contain 128 bits written in hexadecimal groups. Leading zeros can be omitted, and one consecutive zero run can be compressed with :: under the notation rules. Textual equality is therefore not a reliable address comparison. Normalize using an address-aware parser when evaluating a plan. A prefix length defines fixed bits just as in IPv4, but the much larger space changes allocation strategy. Do not enumerate every address in a large prefix merely to count capacity. Documentation examples use 2001:db8::/32 and are not assignments for a deployed network.

Scope and interface context matter

A node can hold link-local, global, and other relevant address types simultaneously. Link-local addresses are meaningful on a particular link and often need an interface zone in an API or textual endpoint. They are not routed across arbitrary networks. Multiple addresses also have selection and lifetime behavior, so the address visible in one screenshot may not be the one an application chooses. Unique local addresses are not a substitute for a complete routing and security design. Treat address scope, allowed reachability, and authentication as distinct properties rather than calling every non-global address automatically safe.

python Normalize and classify declared IPv6 values offline

from ipaddress import ip_address
address = ip_address('2001:0db8:0000:0000:0000:0000:0000:0020')
print(address.compressed)
print('version=' + str(address.version))
print('link_local=' + str(ip_address('fe80::20').is_link_local))

Expected output

2001:db8::20
version=6
link_local=True

The parser works on strings only. The link-local classification does not identify an interface, install an address, or prove that the value is reachable.

Neighbor Discovery is more than an ARP replacement

IPv6 Neighbor Discovery uses ICMPv6 messages for functions including neighbor address resolution, router discovery, and reachability maintenance. Router advertisements can describe default-router and prefix information. Blocking all ICMPv6 can therefore break essential operation rather than merely disable a diagnostic utility. Neighbor Solicitation and Advertisement are distinct from Router Solicitation and Advertisement, and their roles should not be collapsed into one generic discovery packet. Like ordinary ARP, basic neighbor discovery is not universal proof of trusted identity. Network policy and authenticated upper layers remain necessary according to the design.

Configuration mechanisms contribute different information

SLAAC can form addresses from advertised prefixes and local rules when its conditions are satisfied. DHCPv6 can provide stateful addresses, prefixes, or other configuration depending on the deployment. It is not simply DHCPv4 with longer addresses; router discovery remains a separate IPv6 mechanism. Common multi-access SLAAC designs use /64 prefixes, but special link and routing cases exist and should not be overwritten by a blanket rule. Duplicate Address Detection and preferred/valid lifetimes affect whether an address may be used. An address can become deprecated before it becomes invalid.

python Model preferred and valid lifetimes separately

now = 120
preferred_until = 100
valid_until = 300
state = 'invalid' if now >= valid_until else ('deprecated' if now >= preferred_until else 'preferred')
print('synthetic_state=' + state)
print('valid_remaining=' + str(max(0, valid_until - now)))

Expected output

synthetic_state=deprecated
valid_remaining=180

The synthetic address is still valid but deprecated at this observation time. This arithmetic models one lifecycle distinction, not a complete address-selection or SLAAC implementation.

Diagnose the address family actually used

A dual-stack application may receive both A and AAAA records and choose or race connection attempts according to its implementation. A working IPv4 request does not establish that IPv6 routing, neighbor discovery, MTU, or policy is correct. Conversely, a failed IPv6 attempt may be hidden by successful fallback, changing latency rather than producing a visible error. Record selected address, family, interface context, and timing. Use a matched comparison before altering configuration. This lesson never sends solicitations, assigns addresses, or modifies router advertisements; all examples are offline reasoning fixtures.

Common errors and fixes

IPv6 is treated as IPv4 with longer notation

Why it happens: Discovery, scope, and configuration differences were ignored.
How to fix it: Model IPv6 mechanisms separately.
Prevent it next time: Use family-specific evidence checklists.

All ICMPv6 is assumed optional

Why it happens: Essential discovery and error functions were called diagnostics only.
How to fix it: Review required message types in the design.
Prevent it next time: Base policy on protocol roles rather than names.

Deprecated means immediately unusable

Why it happens: Preferred and valid lifetimes were conflated.
How to fix it: Track both lifetimes and selection rules.
Prevent it next time: Test address lifecycle transitions explicitly.

Check your understanding

1. Why does fe80::1 need a link context on a multihomed node?

Show worked solution

The same link-local text can be meaningful on several separate links. An interface zone identifies which local context is intended. The address alone does not select a unique routed destination across all interfaces.

2. IPv4 succeeds and IPv6 falls back slowly. What should be recorded before diagnosis?