Skip to content

CONCEPT Cited by 1 source

Embedded routing in IP address

Embedded routing in IP address is the addressing design where routing information is encoded directly into the IP address itself, so that forwarding decisions can be made by static- route lookup against a small number of prefixes rather than by running a dynamic distributed-routing protocol.

The tradeoff: routing stays simple and fast (no BGP, no OSPF, no gossip convergence) and scales to large fleets with constantly-changing membership, but the address is tied to the routing destination. Move the workload, and the address must change.

Fly.io's 6PN

Fly.io's 6PN is the canonical wiki instance. "We call this scheme 6PN (for 'IPv6 Private Network'). It functions by embedding routing information directly into IPv6 addresses. This is, perhaps, gross. But it allows us to route diverse private networks with constantly changing membership across a global fleet of servers without running a distributed routing protocol."

The post quotes a design heuristic: "As the beardy wizards who kept the Internet backbone up and running on Cisco AGS+'s once said: the best routing protocol is 'static'." IPv6's 128-bit address space is large enough to host both the routing prefix and the endpoint identifier — "we're members of an elite cadre of idiots who have managed to find designs that made us wish IPv6 addresses were even bigger."

What migration does to it

In Making Machines Move, embedding routing in the address becomes a migration tax:

The embedded routing information in a 6PN address refers in part to specific worker servers.

When a Machine migrates to a different worker, its 6PN address must change — because the old address routes to the old worker. DNS is the intended escape hatch: "That's fine, right? They're IPv6 addresses. Nobody uses literal IPv6 addresses. Nobody uses IP addresses at all; they use the DNS. When you migrate a host, just give it a new 6PN address, and update the DNS."

Except — see concepts/hardcoded-literal-address-antipattern — Fly Postgres cluster configs "did use literal IPv6 addresses," which required a fleet-wide config rewrite and an in-guest address- mapping compatibility feature in init as a bridge.

When to use it

Best fit:

  • Very large fleets with constant membership churn where BGP / OSPF convergence cost is prohibitive.
  • Operator-controlled endpoints where address stability isn't a customer-facing contract.
  • Substrate behind a name resolution layer (DNS, a service registry) that customers use instead of literal addresses.

Worst fit:

  • Addresses customers can copy-paste into their own configuration.
  • Workloads that migrate often and assume address stability (the Fly Postgres cluster case).
  • Protocols with address-bound identity (anything that TLS-pins to an IP address).

Seen in

Last updated · 200 distilled / 1,178 read