![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> if multiple addresses are available for a host, the chances are good > that the paths associated with some of those addresses are significantly > better, or worse, than others. with IPv4 multihoming, the routing system > sorts out which path to use. this doesn't work perfectly but at least > the decision is made in light of some information about the nature and > current state of those paths. with IPv6 multihoming, the sending host is > just guessing. it's difficult to believe that this will work well. That's why you add some feedback-based smarts to the address-order selection scheme, and overlap the connection attempts (perhaps separating them by an RTT or so). Given typical distributed apps, feedback selection based on end-to-end latency will be the right answer in almost all cases; bandwidth-based feedback can also potentially be done. Given how hard it is to get an ISP do to anything special for you these days, I really can't see a routing-system-based multihoming actually scale down to, say, individual SOHO networks being multihomed, while multiple-address-based multihoming doesn't require anything special out of the ISP's.. - Bill
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.