RFC 5214: A Potential Router List Is Not a Reachability Receipt

Summary

An ISATAP Potential Router List tells a host which IPv4 addresses are eligible targets for Router Solicitation. It does not certify that the address is fresh, reachable, correctly filtered or still attached to an advertising router.
A valid Router Advertisement and a configured IPv6 address are later pieces of evidence, not substitutes for bidirectional forwarding and observed service.
The useful governance lesson is narrow: keep the common discovery layer thin, then make each operator prove the running states it actually controls.

The green inventory cell

At 09:00 in a constructed change window, isatap.example.net returns two IPv4 addresses. The configuration system compares the answer with its intended Potential Router List and paints both entries green. One address belongs to the router still serving the site. The other belongs to a router drained the previous evening; its replacement sits in another partition, behind a protocol-41 rule that has not yet been opened.

At 09:05 a host sends directed Router Solicitations. One target answers. The other is silent. At 09:08 the host has an IPv6 address and a default route learned from the responding router, yet return traffic for part of the site still follows stale IPv6 routing toward the drained box. Discovery has partly worked. Service has not.

This is not a report of an outage at a named organisation. It is a constructed synthesis of mechanisms specified in RFC 5214, RFC 6964 and the underlying IPv6 Neighbor Discovery rules. Its purpose is to expose four states that a dashboard can compress into one: publication, reachability, control-plane acceptance and data-plane delivery.

The first green cell was not false. The list really did contain two addresses. It answered a precise question: where should a host try to find an advertising ISATAP router? The error began when the answer was promoted into a claim the list was never designed to make.

Why ISATAP needs a list

ISATAP treats an IPv4 network as a non-broadcast multiple-access link for IPv6. A dual-stack node encapsulates IPv6 in IPv4 protocol 41. An IPv6 interface identifier carries an IPv4 address, allowing a node to compute the underlay locator used for a tunnel peer. This is elegant because it reuses an existing IPv4 site without requiring general IPv4 multicast.

The absence of assumed multicast changes router discovery. On an ordinary broadcast link, a solicitation can reach all routers. On an ISATAP link, the host needs candidate IPv4 addresses to which it can direct the exchange. RFC 5214 therefore defines the Potential Router List, or PRL. Each entry contains an IPv4 address representing an advertising ISATAP interface.

The adjective “potential” is doing technical work. The PRL is a discovery set, not a live routing table. A host may acquire it through manual configuration, a DHCPv4 vendor-specific option, an FQDN resolved through DNS or another site-specific method. The protocol does not turn any of those publication channels into an availability monitor.

An FQDN is convenient because an administrator can change the set without touching every host. It also introduces a clock. RFC 5214 gives the interface a PrlRefreshInterval, with 3,600 seconds as the default, and says that when DNS provides TTLs, refresh should use the smaller of the configured interval and the minimum returned TTL. A record can be authoritative for the name-service transaction and still be stale for the physical router state that changed a minute later.

The address proves a mapping, not a machine

ISATAP's static mapping takes the last four octets of the relevant IPv6 address and treats them as an IPv4 address. During decapsulation, the receiver checks a specific consistency relation: the outer IPv4 source must match the IPv4 value embedded in an ISATAP source address, or the source must be a member of the PRL when it is acting as a router.

That is a valuable deterministic check. It prevents arbitrary outer sources from being accepted as though they were the endpoint named by the inner address. It is also bounded. Matching bits do not prove that the machine is the intended asset, that its configuration is current, that it belongs to the correct administrative site or that its forwarding table leads anywhere useful.

The locator set itself must not span multiple sites. That rule protects the abstraction: an ISATAP interface cannot silently turn unrelated IPv4 realms into one link. But “single site” is not a magic property stored in the address. It is an operational claim enforced by routing, access controls, name service, inventory and change management.

RFC 5214's security discussion makes this boundary explicit. Site borders should restrict IPv4 ingress and protocol 41 so outside packets cannot be injected into the ISATAP link. An inside node can also pretend to be a router. Hosts use the PRL in their filtering decisions, and administrators are told to keep the list current and protect its resolution mechanism from subversion. A published address therefore depends on the integrity of the process that put it there.

Asking and answering are distinct events

After the PRL is initialised, a host directs Router Solicitations to its entries. An advertising interface sends a solicited Router Advertisement back to that host. The advertisement must use a link-local ISATAP source whose embedded IPv4 address matches a PRL entry.

This creates an evidence chain with useful, separate receipts:

a source published a candidate address;
the host refreshed that publication at a known time;
IPv4 routing and filtering allowed a solicitation to reach the address;
a router returned an advertisement with the expected source relation;
the host accepted router, prefix and route lifetimes;
address configuration completed;
the selected neighbor remained reachable;
packets crossed the tunnel in both directions; and
an application observed the service it required.

Each later event depends on earlier conditions, but none can be backfilled by the existence of the earlier record. A DNS response cannot stand in for an RA. An RA cannot stand in for a Neighbor Advertisement. A configured address cannot stand in for the return path. A successful ping to one destination cannot prove every route, packet size or application dependency.

Neighbor Unreachability Detection exists because reachability is a changing property. RFC 5214 says hosts should perform NUD and should make an initial confirmation with Neighbor Solicitation and Neighbor Advertisement after address resolution. Routers may do the same, although the specification recognises that this might not scale in every environment. ARP failures and persistent ICMPv4 errors are also treated as link-specific indications that the path to a neighbour may have failed.

These are not inconsistencies in the design. They are the design refusing to claim more certainty than the available evidence supports.

A receipt that stops at the right boundary

An operator who still runs or retires ISATAP can build a better service receipt without inventing a new protocol message. Record the site identifier and approved locator-set scope; the PRL source, returned addresses, TTL and refresh time; the accountable owner of each address; IPv4 route and ARP reachability from each site partition; protocol-41 border policy; RS transmission and matching RA; prefix, route and router lifetimes; initial NS/NA confirmation; router-side IPv6 routes and anycast membership; bidirectional packet observations; an external IPv6 check; representative application success; and removal of stale entries during retirement.

That receipt is BTW editorial analysis, not a requirement attributed to RFC 5214. Its value is institutional. When a change fails, it shows which team owned the last verified fact and which fact was assumed. It also prevents the retirement project from declaring victory merely because the FQDN was removed while manually configured hosts or hidden protocol-41 paths remain.

Heng Lu's Running-Code Primacy offers the appropriate constraint. A common specification should define the minimum deterministic rules required for interoperability and shared safety. It should not become a standing source of truth for conditions that operators can verify locally. The PRL is a good thin coordination mechanism because it says where to ask. The mistake is not that it is thin; the mistake is asking it to certify the answer, the path and the result.

The List Knew Where to Ask. It Did Not Know Whether the Router Would Answer.

Why it matters

Summary

The green inventory cell

Why ISATAP needs a list

The address proves a mapping, not a machine

Asking and answering are distinct events

More routers make the ownership problem visible

A receipt that stops at the right boundary

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing