On Wed, 20 Oct 2010 21:15:35 -0500 James Hess <mysi...@gmail.com> wrote:
> On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman <matt...@matthew.at> wrote: > > On 10/20/2010 6:20 PM, Mark Smith wrote: > > Right. Just like to multihome with IPv6 you would have both PA addresses > > from provider #1 and PA addresses from provider #2 in your network. > > Only nobody wants to do that either. > > A perfectly valid way to multihome, right? Setup each host with two > IP addresses, > one in each PA range. Use multiple DNS records, to indicate all > the host's pairs of IPs. > If an ISP link goes down, all the clients' should automatically try > resend the unack'ed packets to the > DNS name's other IPs in 10 or 11 seconds, and recover, without having > to reconnect, right? right?? [ No :( ] > > Automatic failover to other multihomed IPs seems to always have been > left missing from the TCP protocols, for some reason or another. > > Probably good reasons, but that multihoming strategy isn't a very > good one, for now, > due to the disruption of active connections, and bad client > programs that won't look for other DNS records, > even when trying to establish a new connection. > > Perhaps one day, there will be a truly reliable transport protocol, > and an API that allows a bind() > against multiple IPs and a connect() * Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs) * "TCP Extensions for Multipath Operation with Multiple Addresses" https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ and "Architectural Guidelines for Multipath TCP Development" https://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/ > to all a target host's IPs instead of just one, so both hosts can > learn of each other's IP addresses > that are offered to be used for that connection, then "multiple PA > IP addresses" > would be a technically viable multi-homing strategy. > > > -- > -Jh
