Summary

  • RFC 5220 described a “half-closed” IPv6 network in which a host's default source-address rule could select an address from a prefix whose network was not reachable from the public Internet.
  • The packet's source and its selected first hop were separate decisions. RFC 5220 documents the possible mismatch, not a named deployment, failure rate, or proof that all multihomed hosts behaved this way.

Two valid prefixes, one unreachable reply

Published in July 2008, RFC 5220 was an Informational problem statement about IPv6 address choice on links with multiple prefixes. It did not introduce a new packet format. Instead, it gathered situations in which the default source- and destination-selection rules of RFC 3484 could be difficult to operate, especially at unmanaged hosts whose users could not be expected to maintain a policy table by hand.

Its most revealing case is called a “half-closed network.” Imagine a small site attached to two upstream networks. One is an ordinary Internet provider. The other is a closed network reached through a VPN. The host has a valid IPv6 address from each. A colleague inside the closed network can reach the host using its private-side address, but a public server cannot route a reply to that same address through the open Internet.

The problem appears when the host starts a connection to a public destination. RFC 5220's example says the default longest-prefix rule can select the closed-network address as the source. The site's normal default route may still send the outgoing packet through the Internet provider. That provider may discard a source prefix it did not delegate; even if the packet gets out, the public server's reply is addressed to the closed-network prefix and cannot return over the public path. “Valid address” and “working conversation” are different claims.

The standards text separates two possible breaks. Ingress filtering can reject the outgoing packet because its source does not belong behind that provider. A half-closed return domain can make a reply undeliverable even when the outgoing packet was accepted. Neither is simply a DNS problem or proof that the host address was malformed.

The host could not infer upstream policy from the prefix

RFC 3484 supplied default comparisons among candidate addresses. Those comparisons did not automatically tell a host which provider would carry a packet or whether the source prefix could receive a return packet over that path. RFC 5220 therefore treated several failures as a coordination problem between the host's address choice and the network's routing policy. In its half-closed example, configuring the host's policy table could avoid the bad choice, but that remedy depended on somebody knowing the topology and keeping the local policy current.

The document was careful about scope. It sorted out cases that might fit the existing selection framework and cases that could need more information or a different mechanism. It did not say every multihomed IPv6 site was broken, nor did it measure how often the examples appeared in production. A diagram is evidence of a failure mode an engineer should consider, not an incident report.

Later documents made parts of the boundary more explicit. RFC 6724 eventually obsoleted RFC 3484. In 2016, Standards Track RFC 8028 described first-hop router selection in multi-prefix networks and the relation between an advertised prefix, a chosen source address and the router used to send it. That later work helps trace how standards reasoning developed; it does not prove the prevalence of RFC 5220's 2008 scenarios or erase the need to verify an actual network's return path.

A standards warning is not a traffic measurement

RFC 5220's historical contribution is the separation it forces: address selection, next-hop choice, provider filtering and return reachability are related, but none is a receipt for the others. Its text identifies plausible configurations and analyzes them. It supplies no operating-system census, packet capture, named outage, or before-and-after measurement. Claims about how many hosts made the wrong choice—or how much later work improved live connectivity—need implementation and operational evidence outside the RFC.

Sources

  1. RFC 5220 — Problem Statement for Default Address Selection in Multi-Prefix Environments
  2. RFC 3484 — Default Address Selection for IPv6
  3. RFC 6724 — Default Address Selection for IPv6
  4. RFC 8028 — First-Hop Router Selection by Hosts in a Multi-Prefix Network
  5. RFC 2827 — Network Ingress Filtering
  6. RFC 4193 — Unique Local IPv6 Unicast Addresses
  7. RFC Editor record for RFC 5220
  8. RFC Editor record for RFC 8028