Improving the lives of users with IPv6 and SCTP

Published on December 06, 2010

Improving the lives of users with IPv6 and SCTP

Original author: Dan Wing and Andrew Yourtchenko
  • Transfer
From the translator: I did not find a suitable "low-level network" blog on the hub and at first I even doubted whether this translation should be done. But still, we are all developers (I hope, at least the majority), and the problem with IPv6 described in the article is now more relevant than ever. Until now, I have to abandon my favorite Russian Debian mirror (, due to the fact that a too advanced mirror works fine over IPv6, and my provider issues IPv6 addresses, but IPv6 traffic does not route, yes. In general, I contacted Ole J. Jacobsen, editor-in-chief of The Internet Protocol Journal, and with his blessing I am publishing this article. Go.

To be successful, new technologies must bring joy to users. In the process of finding the best way to introduce technology, as a rule, several approaches are invented, researched, tried, and discarded. This article discusses two such approaches for IPv6 and Stream Control Transmission Protocol (SCTP) [10].

Modern browsers, web servers and operating systems support IPv4 and IPv6. IPv6 is also supported by several major content providers, including Google, NetFlix, and Facebook. However, their content cannot be called widely available over IPv6 due to the conflict between IPv6 technology and business realities.

Connection in web browsers and operating systems includes the execution of DNS queries to AAAA (IPv6 - approx.) and A (IPv4 - approx. per. ) records, and then attempts to connect sequentially to the resulting IPv6 and IPv4 addresses. If the IPv6 path is unavailable (or slow), the connection can gobble up a lot of time before the program starts trying traditional IPv4. The process will be especially painful on average websites requesting objects from different sites - every IPv6 problem will cause a delay. In combination with the operating system and the browser, if IPv6 is not available, the delay can result in brakes from 20 seconds to several minutes [2]. A typical message flow from a TCP client is shown in Figure 1. Obviously, such a delay is unacceptable for users who escape from braking by disabling IPv6 protocol support [3] or by avoiding IPv6-enabled sites.

Figure 1: Normal Web Browser Behavior

The problem of “broken” IPv6 networks is widespread [6]. The provision of content is a business, both direct (for example, playing streaming video) and indirect (selling ad impressions). If users experience lags while viewing IPv6-enabled content (for technological reasons mentioned above), they immediately get a great incentive to visit other sites. This scenario means lost profits and is categorically not suitable for business. Considering that all consumers of today's Internet can reach content via IPv4, including IPv6 is a big business risk, as some consumers will suffer from it. Large content providers studied the situation for some time and eventually published the results [7] showing that the number of IPv6 failures is too large,

IPv6 problems are caused by several reasons. This is a new technology, and the quality of the IPv6 network is still not at the same level as for IPv4, due to point tunnels, uncontrolled tunnels [11] (usually 6to4) and incorrectly configured firewalls, in addition, failures of individual routers and connections also quite easily cause IPv6 failures. Many applications continue to support only IPv4, and network administrators rely on dual-stack equipment to transparently switch to IPv4 during IPv6 failures.

However, such switches are not transparent to users - they take many seconds or even minutes! To avoid these problems, content providers have only one way out - do not give out their AAAA records to those whose IPv6 connection may be broken or slow.

To work around this problem, Google created a white list of DNS servers to which they will provide their AAAA records [8]. However, in its current incarnation, DNS whitelisting does not scale well, since the Internet provider must first prove its good IPv6 connection with Google, after which Google will whitelist the provider’s DNS servers. The scalability problem is that there are thousands of internet providers in the world, and whitelisting is becoming a tedious manual task for both providers and Google. In addition, if each content provider enters a white list of DNS, each Internet provider will have to work with several content providers at once to ensure the profitability of the IPv6 network deployed among their users!

In addition to this, whitelisting DNS does not guarantee a working (or fast) IPv6 network, since there is no direct connection between good IPv6 connectivity and the presence of AAAA records on the DNS server of a user Internet provider. Even with the best design and network design, there will still be cases when only one path is available - either IPv4 or IPv6 - while the second mode of transport is not available. The result will be excessive delays for clients supporting IPv4 or both stacks, depending on what kind of failure happened.

This situation contributes to the user experience that the Internet or a particular site has “fallen”. The user will prefer to go to another site, probably never returning to the "fallen" one.

Happy eyes

Note transl.: the original uses “happy eyeballs” which literally translates as “happy eyeballs,” but in Western telecom “eyeballs” usually means “Internet users.”

This problem is solved by a different approach. Instead of slowly trying to establish a connection over IPv6, and then over IPv4, the application makes simultaneous attempts to establish a connection immediately through IPv4 and IPv6.

Simultaneous connection attempts consume a slightly larger part of the channel and double the number of connection attempts to the server. To reduce unnecessary traffic, a cache is also used that stores the history of successful and failed connection attempts through IPv4 / 6. We call this approach: “Happy Eyes” [1], since it is the eyes (users) that are happier - their computer instantly displays content, although the network speed decreases and (Figure 2).

Figure 2: Two-Stack Browser Implementing Happy Eyes

Obviously, sending TCP SYNs over IPv6 and IPv4 doubles the number of connection attempts made by the client. This excess connection can be reduced by remembering by the application which protocol was used in the previous connection — IPv6 or IPv4 — and using this information in subsequent attempts. A possible complication of this cache depends on the memory (or disk), but even simple caching can be very effective. When connected to a new network (3G, various Wi-Fi networks or physical Ethernet), you can determine the connectivity of this network and, if necessary, clear the attempt cache, partially or completely.

Thus, doubling the number of connection attempts occurs only when connecting to a new network. In this case, the initial connection attempt will be delayed due to the fact that IPv6 (or IPv4) will be tried first. In any case, if the IPv6 (or IPv4) route is not available, there will be no significant brakes noticeable to the user. The goal of Happy Eye is to keep IPv6 enabled, while saving users from crashes so that visiting sites with IPv6 does not cause any brakes.

With this approach, users gradually migrate from IPv4 to IPv6, instantly returning to IPv4 if necessary. This solution demonstrates a significant improvement over existing web browsers. The obstacle for this idea is that it must be implemented in each individual application. Although updating browsers is an additional hard work, there are only five major browsers [9], and in addition, browsers benefit immediately from such active connection attempts. In addition, browsers still often update in the name of fast JavaScript engines and other new features.

Another idea for determining the health of IPv6 is to send pings or other simple requests to some IPv6 resource on the Internet and disable IPv6 if the resource does not respond. This approach is an obstacle to the internal IPv6 traffic of enterprises (which can go quite well, while there is no access to IPv6 Internet), as well as disabling IPv6 will break IPv6 capabilities embedded in the operating system (for example, DirectAccess on Windows or Back to My Mac on Mac OS X). The advantage is that if IPv6 is disabled, no application will suffer from its crash and delays associated with switching to IPv4.

New Transport - SCTP

In addition to the problem of choosing a network layer protocol, a similar problem exists at the transport level. Perhaps this will come as a surprise to someone, but besides TCP, there is another transport protocol - flow control protocol (SCTP). SCTP provides significant advantages over TCP and was designed taking into account the problems that had to be encountered in the implementation and implementation of TCP [4].

Unlike IPv6 and IPv4, for which there are different DNS records (AAAA and A), we do not have a special record showing that the application can or should use a different transport protocol. But even if we could designate SCTP support in DNS, somewhere in the course of following the route, SCTP may be blocked, reducing the usefulness of this DNS record. A route can also be blocked by NAT or a firewall, expecting exclusively TCP or UDP.

Happy Eyes also describes a technique in which a client can simultaneously try to connect using both TCP and SCTP. If necessary, these attempts are made by the application, and the application must select the transport that responded faster and cache this information to reduce flood during subsequent attempts to connect to this server. The connection scenario is shown in Figure 3.

Figure 3: Client implementing “Happy Eyes” to choose between TCP and SCTP

Combining IPv6 / IPv4 selection with SCTP / TCP selection, a web browser running on a computer connected to the new dual-stack network sends four packets: IPv4 TCP SYN, IPv6 TCP SYN, IPv4 SCTP INIT and IPv6 SCTP INIT. Based on the answers, the browser decides which transport protocol and address space (IPv6 or IPv4) to prefer and drops the remaining connections. As described previously, the connection information is cached for later use in order to reduce the consumed channel bandwidth and server resources.


New technologies aimed at improving the lives of users will be successful only if they meet expectations - they improve this very life. Since many companies make all their profits by working on the Internet, any deterioration in service means lost profits. Therefore, the deployment of new technology should not adversely affect the user experience. This article describes one of the mechanisms that developers can use to avoid the negative reaction of your users.


[1] Dan Wing, Andrew Yourtchenko, and Preethi Natarajan, “Happy Eyeballs: Trending Towards Success (IPv6 and SCTP),” Internet-Draft, Work-in-Progress, July 2009: html / draft-wing-http-new-tech
[2] “Broken IPv6 clients,” Lorenzo Colitti, June 2010:
[3] “Google Trends” :
[4] P. Natarajan, “Leveraging Innovative Transport Layer Services for Improved Application Performance,” February 2009: http: //
[5] Carolyn Duffy Marsan, “Google, Microsoft, Netflix in talks to create a shared list of IPv6 users,” Network World, March 2010:
[6] Tore Anderson, “IPv6 brokenness experiment, November results,” November 2009: /pipermail/ipv6-ops/2009-December/002707.html
[7] Igor Gashinsky, “IPv6 & recursive resolvers: How do we make the transition less painful?” March 2010: /77/slides/dnsop-7.pdf
[8] “Access Google services over IPv6”:
[9] “Usage share of web browsers”: http: / /
[10] R. Stewart, Ed., “Stream Control Transmission Protocol,” RFC 4960, September 2007.
[11] Gunter Van de Velde, Ole Troan, and Tim Chown, “Non-Managed IPv6 Tunnels considered Harmful,” July 2009:

Final from the translator

Please forgive me for my tongue-tied language overlapping with the overly scientific style of the article. I hope you were interested. Now for a minute of required information:

Reprinted with permission from The Internet Protocol Journal (IPJ) from Volume 13, Number 3, September 2010. IPJ is a quarterly technical journal published by Cisco Systems. See

Reprinted with permission from The Internet Protocol Journal (IPJ), Volume 13, No. 3, September, 2010. IPJ is a quarterly technical journal published by Cisco Systems. See