IPv6 was designed with a serene assumption that turned out to be wrong: a host has one address per interface, and that address routes wherever it needs to go. In the real world — especially with residential multihoming, enterprise dual-WAN, and IPv6 PA (provider-aggregatable) addressing — a single interface routinely holds two or more addresses from different prefixes, each delegated by a different upstream. RFC 8028 is the small but load-bearing patch that makes this scenario actually work.

The failure mode. Imagine a laptop on Wi-Fi with two routers on the link: Router A advertises prefix 2001:db8:a::/64, Router B advertises 2001:db8:b::/64. The host autoconfigures one address from each. Both routers announce themselves as defaults. The host picks a source address using RFC 6724 (Default Address Selection) — say 2001:db8:a::1234 — and then, independently, picks a next-hop router. If it picks Router B, the packet leaves with a source address that belongs to A's network. Router B's upstream ISP applies BCP 38 ingress filtering and drops it. Black hole. The user sees "the internet works sometimes."

The fix. RFC 8028 updates Neighbor Discovery (RFC 4861) with one rule: when a host has multiple default routers and multiple source addresses, it MUST prefer a router that advertised the prefix of the chosen source address. If no such router exists, fall back to normal default router selection. The host learns which router announced which prefix from the Router Advertisement itself — the PIO (Prefix Information Option) is now a binding between router identity and source prefix, not just a hint about what to autoconfigure.

Design decisions worth noting.

• The rule is source-address driven, not destination-driven. The application or the kernel picks the source first; routing follows. This is the inverse of how most engineers think about routing, but it's the only way the layering works without bouncing the address choice up to the application.
• RAs gained an implicit semantic: "these prefixes are reachable via me, and packets sourced from them should come back through me." RFC 8028 doesn't change the wire format — it changes how a conforming host interprets it.
• It explicitly does not solve destination-based routing, PvD (Provisioning Domains), or policy routing. RFC 7556 and later RFC 8801 (PvD) tackle that bigger picture. RFC 8028 is the minimum viable correctness fix.

Why this matters in 2026. Multihomed IPv6 is no longer exotic. A typical home with fiber + LTE failover, an enterprise with two ISPs and SLAAC on the user VLAN, a datacenter ToR with two upstreams — all of them hit this problem the moment a host gets addresses from both upstreams. Without RFC 8028, the symptoms are intermittent and look like packet loss, not a routing bug, which makes them maddening to debug. With it, Linux (since around kernel 4.x via net.ipv6.conf.*.accept_ra_rt_info_* and related knobs), modern Windows, and macOS quietly do the right thing.

Historical note. Fred Baker (Cisco fellow, IETF chair 1996–2001) and Brian Carpenter (IAB chair, longtime IPv6 architect) wrote this near the end of a multi-year IETF effort to retrofit IPv6 for the messy realities the original designers had hand-waved away. It's a recurring theme in the v6 saga: an elegant model meets BCP 38, NAT-free multihoming, and PA addressing, and someone has to write the RFC that says "actually, the host has to be smarter."