Improving the lives of users with IPv6 and SCTP
From the translator: I did not find a suitable “low-level network” blog in Habré, and at first I even doubted whether to make this translation. But still, we are all developers (I hope, at least the majority), and the IPv6 problem described in the article is more relevant now than ever. Until now, I have to give up my favorite Russian Debian mirror (ftp.chg.ru), because the too advanced mirror works fine on IPv6, and my provider gives IPv6 addresses, but IPv6 traffic is not routing, yes. In general, I contacted Ole J. Jacobsen, editor-in-chief of The Internet Protocol Journal, and with his blessing I publish this article. Go.
To be successful, new technologies must bring joy to users. In the process of finding the best way to implement the technology, as a rule, they come up with, research, try and drop several approaches. 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 via IPv6 due to the conflict between IPv6 technology and business realities.
')
Connecting in web browsers and operating systems includes performing DNS requests to AAAA (IPv6 - approx. Lane ) and A (IPv4 - approx. Lane ) records, and then trying to connect in series with 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 to try traditional IPv4. The process will be especially painful on average websites requesting objects from different sites — each IPv6 problem will cause a delay. In combination with the operating system 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 are saved from inhibition by disabling IPv6 protocol support [3] or avoiding IPv6-enabled sites.
Figure 1: Normal Web Browser Behavior
The problem of “broken” IPv6 networks is quite widespread [6]. Content delivery is a business, both direct (for example, streaming video playback) and indirect (selling advertisements). If users experience lags while browsing IPv6-capable content (for the technological reasons mentioned above), they immediately have a great incentive to visit other sites. This scenario means lost profits and is absolutely 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 this. Large content providers have been studying the situation for some time and finally published the results of [7], showing that the number of IPv6 failures is too large to include IPv6 AAAA for their content.
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 pin tunnels, uncontrolled tunnels [11] (usually 6to4) and incorrectly configured firewalls, in addition, failures of individual routers and connections are also quite easy to cause IPv6 failures. Many applications continue to support only IPv4, 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 away their AAAA records to those who have an 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, maintaining the DNS white list does not scale well, since the Internet provider must first prove its good IPv6 connection with Google, after which Google will list the provider's DNS servers. The problem of scalability lies in the fact that in the world, generally speaking, there are thousands of Internet providers, and maintaining the white list turns into tedious manual work, both for providers and for Google. In addition, if each content provider enters a DNS white list, each Internet provider will have to work with several content providers at once to ensure the profitability of an IPv6 network deployed among their users! Therefore, content providers began to work together to approve the requirements for white-listing DNS and create a common service to automate this process [5].
In addition to this, DNS whitelisting does not yet guarantee a working (or fast) IPv6 network, as there is no direct connection between good IPv6 connectivity and the presence of AAAA records on the DNS server of the user's Internet provider. Even with the best design and network design, there will still be cases where only one path is available — either IPv4 or IPv6 — while the second type of transport is not available. The result will be excessive delays for clients supporting IPv4 or both stacks, depending on what kind of failure has occurred.
This situation contributes to the user feeling that the Internet or a specific site has “fallen”. The user prefers to go to another site, probably never to return to the "fallen."
Note Lane: “happy eyeballs” is used in the original, which literally translates as “happy eyeballs,” but in Western eyeballs, 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 via IPv4 and IPv6.
Simultaneous connection attempts consume a slightly larger portion of the channel and double the number of attempts to connect to the server. To reduce unnecessary traffic, a cache is also used, which stores the history of successful and failed attempts to connect via IPv4 / 6. We call this approach: “Happy eyes” [1], since it is the eyes (users) that are happier — their computer instantly displays the contents, although the speed of the network decreases (Figure 2).
Figure 2: A two-stack browser that implements Happy Eyes
Obviously, sending a TCP SYN over IPv6 and IPv4 doubles the number of connection attempts made by the client. This excess connection can be reduced by the application memorizing which protocol was used during the previous connection — IPv6 or IPv4 — and using this information on subsequent attempts. The possible complication of this cache depends on the memory (or disk), but even simple caching can be very effective. When connecting 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 retry cache, partially or completely.
Thus, doubling the number of connection attempts happens 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 not be significant noticeable brakes to the user. The goal of “Happy Peepholes” is to keep IPv6 on, while saving users from its downfalls - so that visiting IPv6 sites does not cause any brakes.
With this approach, users gradually migrate from IPv4 to IPv6, instantly returning to using IPv4 if necessary. This solution demonstrates a significant improvement over existing web browsers. The obstacle for this idea is that it needs to be implemented in each individual application. Although updating browsers is an extra hard job, there are only five main browsers [9], and in addition, browsers benefit instantly from such active connection attempts. In addition, browsers still often update in the name of fast JavaScript engines and other new features.
Another idea to determine if IPv6 is working is to send pings or other simple requests to some IPv6 resource on the Internet and disable IPv6 if the resource has not responded. This approach is an obstacle to internal IPv6 enterprise traffic (which can go quite well, while access to the IPv6 Internet is not available), and disabling IPv6 will break the IPv6 capabilities embedded in the operating system (for example, DirectAccess in Windows or Back to My Mac on Mac OS X). The advantage is that if IPv6 is disabled, no application will suffer from its fall and delays associated with switching to IPv4.
In addition to the problem of choosing a network layer protocol, a similar problem exists at the transport level. It may be a surprise for someone, but in addition to TCP, there is another transport protocol, the flow control protocol (SCTP). SCTP provides significant advantages over TCP and was designed to meet the challenges that faced when implementing and implementing 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 the DNS, somewhere during the route the SCTP may be blocked, reducing the usefulness of this DNS record. The route can also be blocked by NAT or a firewall, waiting only for TCP or UDP.
Lucky 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 choose a transport that responds faster, and cache this information to reduce flooding during subsequent attempts to connect to this server. The connection script is shown in Figure 3.
Figure 3: A client that implements Lucky Eyes to choose between TCP and SCTP
Combining IPv6 / IPv4 with SCTP / TCP, a web browser running on a computer connected to a new two-stack network sends four packets: IPv4 TCP SYN, IPv6 TCP SYN, IPv4 SCTP INIT and IPv6 SCTP INIT. Based on the responses, the browser decides which transport protocol and address space (IPv6 or IPv4) to prefer and discards the remaining connections. As described earlier, connection information is cached for later use to reduce bandwidth consumption and server resources.
New technologies aimed at improving the lives of users, will be successful only if they meet the expectations - they will improve this very life. Since many companies make all their profits 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: http://tools.ietf.org/ html / draft-wing-http-new-tech
[2] "Broken IPv6 clients," Lorenzo Colitti, June 2010: https://sites.google.com/site/ipv6implementors/2010/agenda
[3] Google Trends: http://www.google.com/trends?q=enable+ipv6%2C+disable+ipv6
[4] P. Natarajan, "Leveraging Innovative Transport Layer Services for Improved Application Performance," February 2009: http://www.cis.udel.edu/~amer/PEL/poc/pdf/NatarajanPhDdissertation.pdf
[5] Carolyn Duffy Marsan, “Google, Microsoft, Netflix users,“ Network World, March 2010: http://www.networkworld.com/news/2010/032610-dns-ipv6- whitelist.html
[6] Tore Anderson, “IPv6 brokenness experiment, November results,” November 2009: http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html
[7] Igor Gashinsky, “IPv6 & recursive resolvers: How do we make the transition less painful?” March 2010: http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf
[8] "Access Google services over IPv6": http://www.google.com/intl/en/ipv6
[9] “Usage share of web browsers”: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[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: http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels
Please forgive me for my tongue-tiedness, superimposed on the overly scientific style of the article. I hope you were interested. And now a minute of mandatory information:
Reprinted with permission from The Internet Protocol Journal (IPJ), from volume 13, No. 3, September 2010. IPJ is a quarterly technical journal published by Cisco Systems. See www.cisco.com/ipj
Reprinted with the Internet Protocol Journal (IPJ), Volume 13, No. 3, September, 2010. IPJ is a quarterly technical journal published by Cisco Systems. See www.cisco.com/ipj
To be successful, new technologies must bring joy to users. In the process of finding the best way to implement the technology, as a rule, they come up with, research, try and drop several approaches. 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 via IPv6 due to the conflict between IPv6 technology and business realities.
')
Connecting in web browsers and operating systems includes performing DNS requests to AAAA (IPv6 - approx. Lane ) and A (IPv4 - approx. Lane ) records, and then trying to connect in series with 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 to try traditional IPv4. The process will be especially painful on average websites requesting objects from different sites — each IPv6 problem will cause a delay. In combination with the operating system 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 are saved from inhibition by disabling IPv6 protocol support [3] or avoiding IPv6-enabled sites.
Figure 1: Normal Web Browser Behavior
The problem of “broken” IPv6 networks is quite widespread [6]. Content delivery is a business, both direct (for example, streaming video playback) and indirect (selling advertisements). If users experience lags while browsing IPv6-capable content (for the technological reasons mentioned above), they immediately have a great incentive to visit other sites. This scenario means lost profits and is absolutely 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 this. Large content providers have been studying the situation for some time and finally published the results of [7], showing that the number of IPv6 failures is too large to include IPv6 AAAA for their content.
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 pin tunnels, uncontrolled tunnels [11] (usually 6to4) and incorrectly configured firewalls, in addition, failures of individual routers and connections are also quite easy to cause IPv6 failures. Many applications continue to support only IPv4, 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 away their AAAA records to those who have an 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, maintaining the DNS white list does not scale well, since the Internet provider must first prove its good IPv6 connection with Google, after which Google will list the provider's DNS servers. The problem of scalability lies in the fact that in the world, generally speaking, there are thousands of Internet providers, and maintaining the white list turns into tedious manual work, both for providers and for Google. In addition, if each content provider enters a DNS white list, each Internet provider will have to work with several content providers at once to ensure the profitability of an IPv6 network deployed among their users! Therefore, content providers began to work together to approve the requirements for white-listing DNS and create a common service to automate this process [5].
In addition to this, DNS whitelisting does not yet guarantee a working (or fast) IPv6 network, as there is no direct connection between good IPv6 connectivity and the presence of AAAA records on the DNS server of the user's Internet provider. Even with the best design and network design, there will still be cases where only one path is available — either IPv4 or IPv6 — while the second type of transport is not available. The result will be excessive delays for clients supporting IPv4 or both stacks, depending on what kind of failure has occurred.
This situation contributes to the user feeling that the Internet or a specific site has “fallen”. The user prefers to go to another site, probably never to return to the "fallen."
Happy eyes
Note Lane: “happy eyeballs” is used in the original, which literally translates as “happy eyeballs,” but in Western eyeballs, 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 via IPv4 and IPv6.
Simultaneous connection attempts consume a slightly larger portion of the channel and double the number of attempts to connect to the server. To reduce unnecessary traffic, a cache is also used, which stores the history of successful and failed attempts to connect via IPv4 / 6. We call this approach: “Happy eyes” [1], since it is the eyes (users) that are happier — their computer instantly displays the contents, although the speed of the network decreases (Figure 2).
Figure 2: A two-stack browser that implements Happy Eyes
Obviously, sending a TCP SYN over IPv6 and IPv4 doubles the number of connection attempts made by the client. This excess connection can be reduced by the application memorizing which protocol was used during the previous connection — IPv6 or IPv4 — and using this information on subsequent attempts. The possible complication of this cache depends on the memory (or disk), but even simple caching can be very effective. When connecting 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 retry cache, partially or completely.
Thus, doubling the number of connection attempts happens 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 not be significant noticeable brakes to the user. The goal of “Happy Peepholes” is to keep IPv6 on, while saving users from its downfalls - so that visiting IPv6 sites does not cause any brakes.
With this approach, users gradually migrate from IPv4 to IPv6, instantly returning to using IPv4 if necessary. This solution demonstrates a significant improvement over existing web browsers. The obstacle for this idea is that it needs to be implemented in each individual application. Although updating browsers is an extra hard job, there are only five main browsers [9], and in addition, browsers benefit instantly from such active connection attempts. In addition, browsers still often update in the name of fast JavaScript engines and other new features.
Another idea to determine if IPv6 is working is to send pings or other simple requests to some IPv6 resource on the Internet and disable IPv6 if the resource has not responded. This approach is an obstacle to internal IPv6 enterprise traffic (which can go quite well, while access to the IPv6 Internet is not available), and disabling IPv6 will break the IPv6 capabilities embedded in the operating system (for example, DirectAccess in Windows or Back to My Mac on Mac OS X). The advantage is that if IPv6 is disabled, no application will suffer from its fall 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. It may be a surprise for someone, but in addition to TCP, there is another transport protocol, the flow control protocol (SCTP). SCTP provides significant advantages over TCP and was designed to meet the challenges that faced when implementing and implementing 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 the DNS, somewhere during the route the SCTP may be blocked, reducing the usefulness of this DNS record. The route can also be blocked by NAT or a firewall, waiting only for TCP or UDP.
Lucky 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 choose a transport that responds faster, and cache this information to reduce flooding during subsequent attempts to connect to this server. The connection script is shown in Figure 3.
Figure 3: A client that implements Lucky Eyes to choose between TCP and SCTP
Combining IPv6 / IPv4 with SCTP / TCP, a web browser running on a computer connected to a new two-stack network sends four packets: IPv4 TCP SYN, IPv6 TCP SYN, IPv4 SCTP INIT and IPv6 SCTP INIT. Based on the responses, the browser decides which transport protocol and address space (IPv6 or IPv4) to prefer and discards the remaining connections. As described earlier, connection information is cached for later use to reduce bandwidth consumption and server resources.
Conclusion
New technologies aimed at improving the lives of users, will be successful only if they meet the expectations - they will improve this very life. Since many companies make all their profits 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.
Links
[1] Dan Wing, Andrew Yourtchenko, and Preethi Natarajan, "Happy Eyeballs: Trending Towards Success (IPv6 and SCTP)," Internet-Draft, Work-in-Progress, July 2009: http://tools.ietf.org/ html / draft-wing-http-new-tech
[2] "Broken IPv6 clients," Lorenzo Colitti, June 2010: https://sites.google.com/site/ipv6implementors/2010/agenda
[3] Google Trends: http://www.google.com/trends?q=enable+ipv6%2C+disable+ipv6
[4] P. Natarajan, "Leveraging Innovative Transport Layer Services for Improved Application Performance," February 2009: http://www.cis.udel.edu/~amer/PEL/poc/pdf/NatarajanPhDdissertation.pdf
[5] Carolyn Duffy Marsan, “Google, Microsoft, Netflix users,“ Network World, March 2010: http://www.networkworld.com/news/2010/032610-dns-ipv6- whitelist.html
[6] Tore Anderson, “IPv6 brokenness experiment, November results,” November 2009: http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002707.html
[7] Igor Gashinsky, “IPv6 & recursive resolvers: How do we make the transition less painful?” March 2010: http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf
[8] "Access Google services over IPv6": http://www.google.com/intl/en/ipv6
[9] “Usage share of web browsers”: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[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: http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels
Final from translator
Please forgive me for my tongue-tiedness, superimposed on the overly scientific style of the article. I hope you were interested. And now a minute of mandatory information:
Reprinted with permission from The Internet Protocol Journal (IPJ), from volume 13, No. 3, September 2010. IPJ is a quarterly technical journal published by Cisco Systems. See www.cisco.com/ipj
Reprinted with the Internet Protocol Journal (IPJ), Volume 13, No. 3, September, 2010. IPJ is a quarterly technical journal published by Cisco Systems. See www.cisco.com/ipj
Source: https://habr.com/ru/post/109389/
All Articles