Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

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