> 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