On Wed, 26 Mar 2003, Louis A. Mamakos wrote: > 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. So unlike the dialup modem/wireless card/10+100 Ethernet/USB/Bluetooth network connections on today's multihomed-host laptops; multihoming is increasingly the common case, and it is not handled well. L. > 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. Adding one more site-local address doesn't make this > problem any harder to solve, I think. > > > louie > > > > > > _______________________________________________ > This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. > <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>