Way back in the dark ages, it was not uncommon to have multi-homed
HOSTS: one leg on the ARPANET, the other arm on some local LAN
segment. The application and/or network stack on that machine was
left with a decision to choose which interface address it ought to
use when binding some local association endpoint address. It's
"easy" when the other end is on the same network; e.g., directly
attached.
The Internet architecture never gave the end system some mechanism
to help it make this binding decision when trying to communicate
with non-local peers. There are hacks in implementations; like the
local resolver having some sorting policy for the A records returned
when doing a DNS query, with the assumption that the application was
going to try them in turn. But that was just a hack. There was no
protocol to ask the network "which of address should I use to
talk to this remote end system?"
So here we are today, a couple of decades later, with the promise of a
different type of end-system multi-homing (having multiple addresses
on a single) interface due to IPv6 multi-provider multihoming with
provider specific addresses, and still no means to decide which of the
alternatives are preferable when deciding to launch some traffic into
the network.
right you are. multi-homing was avoided in IPv4 because it didn't work
well, and the problems have never been solved, not even in IPv6.
the best known way to solve this problem is by expecting all addresses
to have global scope and to be equally reachable from anywhere, modulo
link failures. SLs prevent this from working.
Keith