Summary

  • Early IPv6 Neighbor Discovery gave a host a list of default routers but no vocabulary for saying that one was better for ordinary Internet traffic or that another served only a particular destination range.
  • RFC 4191 added just three preference levels and an expiring Route Information Option. A fully supporting host chose the longest matching prefix, used preference only among equal prefixes, and allowed known reachability to outrank the advertised preference.
  • The extension remained a local hint, not a routing protocol or certificate. Routers were told not to export their full tables; hosts could ignore or override the hints; malicious advertisements could still attract traffic; later work showed that the selected source prefix could also determine the correct egress.

One default list was not enough

The original IPv6 Neighbor Discovery specification, RFC 2461, offered hosts a deliberately simple model. Router Advertisements populated a Prefix List and a Default Router List. The host decided whether a destination was on-link and, if it was not, selected a first hop from that list.

Simplicity concealed a real ambiguity. A laptop might have Ethernet, Wi-Fi and a corporate tunnel. One router might reach the public Internet; another might reach only an isolated laboratory. Two routers on one link might send the same destination through paths of very different quality. A default-router list could say who had volunteered, but not which volunteer was appropriate for which traffic.

Reachability did help. The Neighbor Discovery algorithm preferred routers known or probably reachable. When no router had such evidence, it could rotate among the list. But two reachable routers remained semantically equal even if one would drop the traffic or immediately redirect it.

Redirect was only a partial correction. A router could tell a host to use a different first hop for a destination, but the correction remained on one link. A router on Ethernet could not redirect the host toward a router reached through a different interface. Multihoming turned a deliberately thin list into an under-specified choice.

Three levels refused to become a metric

RFC 4191, published in November 2005, extended Router Advertisements without enrolling hosts in a router-to-router protocol. Its first instrument was a two-bit preference: High, Medium or Low. The fourth bit pattern was reserved.

The small vocabulary was intentional. The RFC says three values reinforce that preference is not a routing metric. An administrator could express “prefer the public exit,” “keep this firewall as a fallback,” or “use this router for ordinary traffic only when the better one is unavailable.” The field did not carry cost, bandwidth, delay, contractual priority or a globally comparable rank.

That limit also allocated responsibility. Preferences had to be configured explicitly by someone who understood the routers and topology. They were not to be derived automatically from an interior routing metric. A router was not supposed to translate its private control plane into a universal order for every attached host.

If the Router Lifetime was zero, the preference was ignored. The router was no longer offering itself as a default, however attractive the two preference bits might appear. A preference without a live offer had no independent force.

A few routes crossed the host boundary

The second instrument was Neighbor Discovery option type 24, the Route Information Option. It carried a prefix length, the same three-level preference, a route lifetime and enough prefix bits to identify the destination range.

This was a small routing table by design. A router could advertise an isolated corporate prefix through a tunnel while a different interface supplied the default Internet route. It could publish a 6to4 range toward a suitable first hop without making that router the best default for everything else. A ::/0 option could even provide a default preference and lifetime different from the values in the Router Advertisement header.

Lifetime made the statement a lease. Zero removed the route learned from that router. All one bits represented infinity, a dangerous promise precisely because it could survive ordinary refresh cycles. A host did not learn that the prefix belonged to the router or existed globally. It learned that, for a bounded interval, this router claimed to be a useful first hop for destinations matching those bits.

The restraint was explicit. Routers should not advertise preferences or routes by default and should not dump their complete routing tables to hosts. The RFC recommended no more than seventeen Route Information Options per advertisement per link. That arbitrary ceiling carried an architectural message: expose the small decision surface a host needs, not the machinery by which routers arrived at it.

Longest prefix spoke before preference

RFC 4191 described three kinds of host so the extension could arrive without pretending universal adoption. A Type A host continued to ignore both additions. A Type B host understood default-router preference but ignored specific route options. A Type C host used both in a conceptual routing table.

For Type C, destination specificity came first. The host found the longest matching prefix. Only when several routes had the same prefix length did High, Medium and Low break the tie. A Low route for a narrow corporate range therefore beat a High default for traffic inside that range. The narrow statement answered a more specific question.

Reachability then constrained the result. A host bypassed a route whose first-hop router was known unreachable and considered the next candidate. If it had no reachability information, it initially assumed the router reachable; preference did not manufacture a probe result. When route information changed, affected Destination Cache entries had to be invalidated or removed so next-hop determination could run again.

The host could also apply configured values that overrode advertisements. The wire format transported a recommendation; the receiving system retained a local policy surface. That distinction kept the extension compatible with networks whose security or business rules could not be expressed in two bits.

Recovery required useful curiosity

Avoiding a preferred but unreachable router created another problem: how would the host notice its return? Waiting for its next periodic advertisement could take many minutes, especially if the failure lay in an intervening switch while the router itself kept operating.

The answer was bounded probing. If the host had useful traffic that would have used the preferable router, it should send a Neighbor Solicitation to test that router while using an alternative. It must not probe merely because an unused route existed, and it must rate-limit the test to no more than once per minute per router.

This ordering is important. The preference supplied a reason to care about recovery. Actual traffic supplied a reason to spend packets. Neighbor reachability supplied the observation. None of the three replaced the others.

Dynamic truth needed a quiet interface

A router could condition an advertised prefix on a link or route learned elsewhere, but RFC 4191 warned against exposing unstable routing dynamics directly to hosts. Implementations should decouple host announcements from a flapping route table and wait for stability before advertising an unstable prefix.

The advice recognized a change in blast radius. Inside a router, a route flap affects control-plane convergence. Exported into thousands of host caches, it also forces repeated next-hop decisions and invalidations at the edge. A small convenience field could become a distributed event amplifier if it mirrored every interior movement.

Withdrawal therefore had to be coherent. When an interface stopped advertising itself and sent Router Lifetime zero, it should set the lifetimes of its Route Information Options to zero as well. Removing the default while leaving narrow routes alive would create a misleading residue of authority.

The advertisement was not authenticated truth

The security problem predated the extension. RFC 3756 catalogued how forged Router Advertisements, Redirects and Neighbor Discovery messages could alter a host's first-hop state. RFC 4191 gave an attacker finer instruments: claim High preference or publish a narrow route to attract only selected traffic.

Specificity can make the manipulation quieter. A false default disrupts much of a host's traffic and is likely to be noticed. A false route for one management, payment or corporate prefix can divert a smaller and more valuable class. The option contains no signature proving that the sender administers the destination or deserves the traffic.

An infinite lifetime can keep a malicious route relevant and keep recovery probing alive. Yet even that does not make the route an unavoidable command: known unreachability allows the host to consider alternatives, and local controls can reject or override the preference. Securing who may speak Router Advertisements remains separate from interpreting what an accepted advertisement means.

The source address exposed the next boundary

Destination choice did not finish the problem. RFC 8028, published in 2016, considered networks with several provider prefixes and first-hop routers. A packet bearing one provider's source prefix could be discarded if sent through another provider's ingress filter, stateful firewall or reverse-path check.

The later rule associated the source address with the router that had advertised its prefix. A host should give a packet to a first hop that appeared to know the chosen source. A route could therefore be the best destination match and still be the wrong operational egress for that packet's return path.

This refinement did not invalidate RFC 4191. It demonstrated the value of keeping its claim narrow. Router preference answered one bounded question about a destination and first hop. Source selection, filtering, firewall state and return-path policy remained separate facts that running hosts had to combine.

Sources and limits

The baseline Default Router List comes from RFC 2461 and its revised Neighbor Discovery specification, RFC 4861. The preference bits, Route Information Option, Type A/B/C host models, selection order, probing and configuration limits are defined by RFC 4191. The threat model is documented in RFC 3756, and the later source-prefix/first-hop association comes from RFC 8028.

These standards do not measure present deployment, vendor defaults, global support or recovery time. They do not prove that an advertised route is reachable, authorized, safe or globally valid. Their defensible historical claim is smaller: IPv6 gave hosts a thin, expiring route vocabulary while keeping observation and final selection local.