End-system controlled, dynamic multihoming and multipath transport#

Saleem Bhatti — University of St Andrews, Scotland, UK.

• Why: Multipath today means MPTCP or waiting on QUIC multipath. This demonstrates generic, end-system-controlled multipath for any transport — with working code, real transatlantic tests, and no changes to routers, applications, DNS infrastructure beyond what exists, or routing. It is a genuinely different architectural bet worth knowing about even if you never deploy it.
• What: ILNP (Identifier-Locator Network Protocol, RFCs 6740-6748) reuses IPv6 address syntax but splits semantics: the routing prefix acts as a mutable Locator while the remaining bits become a stable end-system Identifier — only end systems examine the Identifier bits, so IPv6 routers forward unchanged. Transport state is keyed on the Identifier (not the address), so a connection survives locator changes; dynamic multihoming and multipath are signaled end-to-end via ICMPv6 Locator Updates, no NAT, tunnels, or proxies.
• How: A FreeBSD 14 implementation tested between IETF 124 in Montreal and St Andrews: dynamic 4-way multipath with TCP CUBIC over iperf3, and DASH video streaming over nginx + Firefox with 3-way multipath — using standard, unmodified applications and libraries. Supporting ecosystem exists: DNS NID/L64 records (RFC 6742) in BIND, Unbound, Knot; a Wireshark dissector (v4.6+); FreeBSD binaries published.
• Where applicable: Research testbed; IPv6-only; requires ILNP-aware end-system stacks (FreeBSD today). No network-side prerequisites, which is the interesting inversion — the network stays dumb and the edge controls path selection. Position this as a direction signal for edge-controlled multipath rather than a deployable capability.