On Wed, 20 Oct 2010 21:15:35 -0500 James Hess <mysidia@gmail.com> wrote:
On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman <matthew@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