IPv6 fc00::/7 — Unique local addresses
Mark Smith
nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Thu Oct 21 02:27:30 UTC 2010
On Wed, 20 Oct 2010 21:15:35 -0500
James Hess <mysidia at gmail.com> wrote:
> On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman <matthew at 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
More information about the NANOG
mailing list