nanog mailing list archives
Re: IPv6 Multi-homing (was IPv6 /64 links)
From: Douglas Otis <dotis () mail-abuse org>
Date: Mon, 25 Jun 2012 16:06:15 -0700
On 6/25/12 12:20 PM, William Herrin wrote:
On Mon, Jun 25, 2012 at 1:09 PM, Douglas Otis <dotis () mail-abuse org> wrote:On 6/25/12 7:54 AM, Owen DeLong wrote:It would have been better if IETF had actually solved this instead of punting on it when developing IPv6.The IETF offered a HA solution that operates at the transport level. The transport is SCTPHi Douglas, SCTP proposes a solution to multihoming by multi-addressing each server. Each address represents one of the leaf node's paths to the Internet and if one fails an SCTP session can switch to the other. Correct?
Dear William, Yes. An SCTP association periodically checks alternate path functionality.
How does SCTP address the most immediate problem with multiaddressed TCP servers: the client doesn't rapidly find a currently working address from the set initially offered by A and AAAA DNS records. Is there anything in the SCTP protocol for this? Or does it handle it exactly the way TCP does (nothing at all in the API; app-controlled timeout and round robin)?
This is addressed by deprecating use of TCP, since SCTP offers a super-set of the socket API. It can also dramatically expand the number of virtual associations supported in a manner similar to that of UDP while still mitigating source spoofing.
Is the SCTP API drop-in compatible with TCP where a client can change a parameter in a socket() call and expect it to try SCTP and promptly fall back to TCP if no connection establishes? On the server side, does it work like the IPv6 API where one socket accepts both protocols? Or do the apps have to be redesigned to handle both SCTP and TCP?
The SCTP socket API is defined by: http://tools.ietf.org/html/rfc6458 As the world adopts IPv6, NAT issues become a bad memory of insecure middle boxes replaced by transports that can be as robust as necessary. IMHO, TCP is the impediment preventing simplistic (hardware based) high speed interfaces able to avoid buffer bloat. Regards, Douglas Otis
Current thread:
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?), (continued)
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Justin M. Streiner (Jun 22)
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Masataka Ohta (Jun 25)
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Tim Franklin (Jun 25)
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Masataka Ohta (Jun 25)
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Owen DeLong (Jun 25)
- IPv6 Multi-homing (was IPv6 /64 links) Douglas Otis (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Christopher Morrow (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Douglas Otis (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Christopher Morrow (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) William Herrin (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Douglas Otis (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) William Herrin (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) William Herrin (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Cameron Byrne (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Mikael Abrahamsson (Jun 25)
- Re: IPv6 Multi-homing (was IPv6 /64 links) Douglas Otis (Jun 26)
- Re: IPv6 /64 links (was Re: ipv6 book recommendations?) Owen DeLong (Jun 21)
- Re: ipv6 book recommendations? Cutler James R (Jun 06)
- Re: ipv6 book recommendations? valdis . kletnieks (Jun 06)