Bright future of IPv6: when the new world order finally comes
Yandex.Mail is now able to exchange letters with other mail systems over IPv6. Thus, it becomes the second largest mass mail system in the world to support IPv6.
At first glance, this may not seem very important, but in fact right now the lack of support for IPv6 is stopping many people. In this post I want to talk about how things are now going on with the adaptation of v6 on the Internet, as well as about what we have done right now and why.
')
4 billion IPv4 addresses have already run out. Switching to IPv6 will allow online 3.4 Ă— 10 38 devices. And we have a future ahead, when more and more devices for each person will be connected to the Internet and when all the people of Asia and Africa finally go online following Europe and America. Therefore, the worldwide network is gradually moving to a new communication protocol, the support of which is necessary for any service that is going to work in the future on the Internet.
As you know, as early as September 1981, when the United States Department of Defense Advanced Defense Research Projects Agency published the IPv4 specification, it was clear that the number of addresses was, of course, equal to 2 32 . At first glance, the number seems large. In 1995, the IP address space was used by only 25%, but scientists and engineers have already formulated and published the first specification of the next version of the basic Internet protocol, which they called IPv6. The new protocol laid the possibility of using approximately 3.4 * 10 38 (340 undecillion) addresses, which is almost 10 29 (100 octillion) times more than in the old version. In 2008, the IPv4 address space was already filled by 86%.
In a first approximation, the plan for transferring the Internet to IPv6 was described almost 20 years ago in RFC 1933 , when the specification of the new protocol was published. He meant a complete switch in 2007. This turned out to be a very optimistic estimate. Only in 2000, the first provider, Japanese NTT, declared its readiness to support IPv6. The modern version is described in RFC 4213 , and its tone is somewhat less optimistic.
Almost all of the first decade of the twenty-first century between Internet providers and owners of large Internet resources was a slow discussion about who is responsible for promoting IPv6. Providers said that there is no point in implementing, because there are too few IPv6 resources. The resources responded that since there are almost no users with IPv6 connectivity, there is no need to include this support on the sites. In general, the real problem is chicken and eggs.
However, as time went on, IPv4 addresses were distributed, and in February 2011, ICANN distributed the latest “fourth” addresses to regional registries. There are five of them - APNIC in the Asia-Pacific region, ARIN in North America, AfrNIC in Africa, LACNIC in Central and South America and RIPE in Europe. As early as April 2011, APNIC distributed all IPv4 addresses allocated to a region, except for the last network / 8 (ie, 2 24 or 16777216 addresses) and switched to a special mode of distribution of the last addresses . Similar events in the European Internet segment occurred in September 2012 , and RIPE also switched to the allocation of the latest addresses. By the way, Yandex accidentally got the last block 5.255.192.0/18 (and, accordingly, the address 5.255.255.255) before going into this mode.
To break the vicious circle of shifting problems from providers to Internet resources and back, World IPv6 Day was held in 2011. On this day, several of the world's largest sites included IPv6 per day. The purpose of this inclusion was to test how hardware and software from users, providers and Internet sites respond to the emergence of IPv6. And we raised a copy of the main page of Yandex on the site ipv6.yandex.ru. We described in detail about this launch, preparation for it and the results in one of the presentations of YaC 2012 . There were a lot of results and there were also quite a lot of tasks on these results.
For example, we have experienced problems with traffic loss when connecting to IPv6. In particular, in one of the experiments we opened the suggest.yandex.net service (serving a hint in the search line) over IPv6 for the entire Internet. As a result, it turned out that we were losing up to 2% of requests, which was unacceptable. Theoretically, the operation of systems with IPv6 and IPv4 support assumes that the program (for example, a browser) first tries to connect to an IPv6 address, and if this fails, reconnects via IPv4. The problem is that in modern operating systems the connection timeout can be tens of seconds and, of course, the user will not wait that long.
There is nothing left for us except how to implement DNS AAAA whitelisting - we can only start showing IPv6 addresses to those providers whose IPv6 connectivity we have with Yandex. We are aware of the administrative complexity of supporting whitelists (the problem, in particular, is described here ) and poor scaling in the long term, but for Runet we don’t see any good alternatives.
A year later, on June 6, 2012, on World IPv6 Launch Day, we launched “now truly” with several of our services on IPv6. Then the websites yandex.com, mail.yandex.com and passport.yandex.com became available. This launch was presented on the Russian bottom of IPv6 . It seems that in Russia we have become the first major site that launched IPv6. Vkontakte joined in a few days or weeks, and after a while Mail.ru. Classmates still do not have IPv6 addresses.
In 2013, we turned off white lists support for services in the yandex.com zone, since the situation with IPv6 support in the world is on average better than on the Runet. Services in the yandex.ru zone for the most part still work through whitelists, but we hope that we can abandon this practice in 2014.
Having dealt with websites and user experience, we realized that now we need to pay attention to inter-server interaction. One of the most notable services corresponding to this category was Mail.
Yandex.Mail consists of hundreds of components, many of which work on an open source OpenSoftware such as Postfix or MongoDB . Support for sending / receiving emails over IPv6 appeared in Postfix more than 10 years ago and was tested by many thousands of mail administrators before us. Postfix works for us on sending servers, and also as a universal queue system. Very reliable and multifunctional product. At the reception of mail in Yandex, there is a special high-performance NwSMTP server, created entirely within the company. Asynchronous and very fast, NwSMTP did not support IPv6 for a long time and demanded serious development.
Another important component of mail that has required a lot of improvements is Spam Defense - a set of programs and databases that protect our (and yours, if you receive mail) users from spam and other unwanted emails. Our email antispam algorithms combine statistical and heuristic methods, as well as machine learning, which Yandex is famous for.
A number of factors in deciding whether a letter is spam use the IP addresses of the computers involved. The so-called reputational methods accumulate and use historical information about objects such as domains, IP addresses, individual email addresses. All this in order to make reasonable assumptions about the future of their behavior. Very simplistic, this scheme looks like a hash or an associative array, where the key is, for example, the IP address, and the value is information about how much spam or non-spam we got from this address. Once, storing and using such a hash, even for 2 32 different possible key values, presented certain difficulties in programming. Imagine what happens when you need to store the reputation of IPv6 addresses, the total number of which greatly exceeds even the number of individual bits in the RAM of all Yandex servers.
Fortunately, the IPv6 address space is very thin. Huge sequences, as they say, by design are not used. Additionally, network / 64 standardization as an IPv6 address allocation quantum is an important optimization factor. In general, in the end everything worked as it should.
About a year ago we began to send letters to external servers via IPv6, if they supported it. This part of the work required only fine tuning of Postfix and thorough testing. Reception of mail turned out to be more difficult in the first place because of anti-spam algorithms. Finally, this work is completed - in February 2014 we began receiving letters on IPv6. See:
Now all Yandex.Mail for server-to-server traffic can be received and transmitted using the IPv6 protocol. Here we did not use DNS whitelists, because IPv6 connectivity between servers is generally better than between servers and users. In addition, working with multiple MXs in SMTP allows essentially automatically degrading to IPv4 in the event of IPv6 failure. Finally, SMTP server is not an interactive protocol, so possible connection timeouts do not directly affect the user experience.
This change has gone unnoticed by users, and this invisibility constitutes a special pride for the whole team. A big step forward has been made, guarantees have been created that your mail will be reliably delivered by Yandex both in 2 and 5, and in 10 years, when the old protocols will completely cease to satisfy the needs of humanity and will be discarded.
Interestingly, all modern anti-spam protection operating in the framework of large mail systems, such as Yahoo !, Gmail, Yandex, AOL, Mail.ru, Outlook.com, have been working for several years as part of a kind of common ecosystem. There is a careful exchange of information about the general waves of spam, made certain settings for reliable mutual exchange of letters and so on. We all work closely together even though we are competitors. This, by the way, is one of the reasons why no stand-alone antispam solutions can match the quality of filtering with large mails. They just do not have enough information and nowhere to get it. So, this ecosystem will require some time to configure itself for the widespread use of IPv6. The earlier this work begins, the faster the overall result will be achieved. It is no longer possible to postpone.
When the problem of a shortage of theoretical IPv4 addresses became increasingly real, providers began to use NAT. But in the end it was not a solution. When there are too many devices behind NAT, sites may decide that the robots create a load on them and take measures to protect against such actions.
Such a problem, in particular, became widespread in Belarus . This happened relatively recently, after the transition of RIPE to the phase of address allocation from the last block / 8. Belarusian providers did not have enough supply of IP-addresses and, being in the conditions of their shortage, they went by increasing the number of users for NAT. As a result, some Internet services took the activity of NAT users for the activities of robots, and some of them completely blocked the IP address (and all NAT users) or increased the display intensity of the captcha. Thus, the lack of availability of providers to exhaust IPv4 addresses has led to a decline in the quality of Internet access for users. A similar problem exists for mail systems: there large NAT pools mean that letters sent by the user to NAT can be mistaken for spam and not reach the addressee.
IPv6 traffic graph on www.yandex.ru
Currently, according to various estimates, only about 3% of traffic on the Internet uses IPv6, and 97% use old IPv4. But when such large players as Yandex, Google, VKontakte, Facebook, support IPv6 technically and ideologically, they push providers to support sixth addresses, they push the entire Internet into the future. Of course, it is important for us and ourselves to understand that our services have enough addresses. But even in aggregate, they are much smaller compared to how many sites may appear on the Internet in the future and how many people will get access to it.
At first glance, this may not seem very important, but in fact right now the lack of support for IPv6 is stopping many people. In this post I want to talk about how things are now going on with the adaptation of v6 on the Internet, as well as about what we have done right now and why.
')
4 billion IPv4 addresses have already run out. Switching to IPv6 will allow online 3.4 Ă— 10 38 devices. And we have a future ahead, when more and more devices for each person will be connected to the Internet and when all the people of Asia and Africa finally go online following Europe and America. Therefore, the worldwide network is gradually moving to a new communication protocol, the support of which is necessary for any service that is going to work in the future on the Internet.
From IPv4 to IPv6: transition history
As you know, as early as September 1981, when the United States Department of Defense Advanced Defense Research Projects Agency published the IPv4 specification, it was clear that the number of addresses was, of course, equal to 2 32 . At first glance, the number seems large. In 1995, the IP address space was used by only 25%, but scientists and engineers have already formulated and published the first specification of the next version of the basic Internet protocol, which they called IPv6. The new protocol laid the possibility of using approximately 3.4 * 10 38 (340 undecillion) addresses, which is almost 10 29 (100 octillion) times more than in the old version. In 2008, the IPv4 address space was already filled by 86%.
In a first approximation, the plan for transferring the Internet to IPv6 was described almost 20 years ago in RFC 1933 , when the specification of the new protocol was published. He meant a complete switch in 2007. This turned out to be a very optimistic estimate. Only in 2000, the first provider, Japanese NTT, declared its readiness to support IPv6. The modern version is described in RFC 4213 , and its tone is somewhat less optimistic.
Almost all of the first decade of the twenty-first century between Internet providers and owners of large Internet resources was a slow discussion about who is responsible for promoting IPv6. Providers said that there is no point in implementing, because there are too few IPv6 resources. The resources responded that since there are almost no users with IPv6 connectivity, there is no need to include this support on the sites. In general, the real problem is chicken and eggs.
However, as time went on, IPv4 addresses were distributed, and in February 2011, ICANN distributed the latest “fourth” addresses to regional registries. There are five of them - APNIC in the Asia-Pacific region, ARIN in North America, AfrNIC in Africa, LACNIC in Central and South America and RIPE in Europe. As early as April 2011, APNIC distributed all IPv4 addresses allocated to a region, except for the last network / 8 (ie, 2 24 or 16777216 addresses) and switched to a special mode of distribution of the last addresses . Similar events in the European Internet segment occurred in September 2012 , and RIPE also switched to the allocation of the latest addresses. By the way, Yandex accidentally got the last block 5.255.192.0/18 (and, accordingly, the address 5.255.255.255) before going into this mode.
To break the vicious circle of shifting problems from providers to Internet resources and back, World IPv6 Day was held in 2011. On this day, several of the world's largest sites included IPv6 per day. The purpose of this inclusion was to test how hardware and software from users, providers and Internet sites respond to the emergence of IPv6. And we raised a copy of the main page of Yandex on the site ipv6.yandex.ru. We described in detail about this launch, preparation for it and the results in one of the presentations of YaC 2012 . There were a lot of results and there were also quite a lot of tasks on these results.
For example, we have experienced problems with traffic loss when connecting to IPv6. In particular, in one of the experiments we opened the suggest.yandex.net service (serving a hint in the search line) over IPv6 for the entire Internet. As a result, it turned out that we were losing up to 2% of requests, which was unacceptable. Theoretically, the operation of systems with IPv6 and IPv4 support assumes that the program (for example, a browser) first tries to connect to an IPv6 address, and if this fails, reconnects via IPv4. The problem is that in modern operating systems the connection timeout can be tens of seconds and, of course, the user will not wait that long.
There is nothing left for us except how to implement DNS AAAA whitelisting - we can only start showing IPv6 addresses to those providers whose IPv6 connectivity we have with Yandex. We are aware of the administrative complexity of supporting whitelists (the problem, in particular, is described here ) and poor scaling in the long term, but for Runet we don’t see any good alternatives.
A year later, on June 6, 2012, on World IPv6 Launch Day, we launched “now truly” with several of our services on IPv6. Then the websites yandex.com, mail.yandex.com and passport.yandex.com became available. This launch was presented on the Russian bottom of IPv6 . It seems that in Russia we have become the first major site that launched IPv6. Vkontakte joined in a few days or weeks, and after a while Mail.ru. Classmates still do not have IPv6 addresses.In 2013, we turned off white lists support for services in the yandex.com zone, since the situation with IPv6 support in the world is on average better than on the Runet. Services in the yandex.ru zone for the most part still work through whitelists, but we hope that we can abandon this practice in 2014.
Having dealt with websites and user experience, we realized that now we need to pay attention to inter-server interaction. One of the most notable services corresponding to this category was Mail.
How did the transition to IPv6 in Yandex.Mail
Yandex.Mail consists of hundreds of components, many of which work on an open source OpenSoftware such as Postfix or MongoDB . Support for sending / receiving emails over IPv6 appeared in Postfix more than 10 years ago and was tested by many thousands of mail administrators before us. Postfix works for us on sending servers, and also as a universal queue system. Very reliable and multifunctional product. At the reception of mail in Yandex, there is a special high-performance NwSMTP server, created entirely within the company. Asynchronous and very fast, NwSMTP did not support IPv6 for a long time and demanded serious development.
Another important component of mail that has required a lot of improvements is Spam Defense - a set of programs and databases that protect our (and yours, if you receive mail) users from spam and other unwanted emails. Our email antispam algorithms combine statistical and heuristic methods, as well as machine learning, which Yandex is famous for.
A number of factors in deciding whether a letter is spam use the IP addresses of the computers involved. The so-called reputational methods accumulate and use historical information about objects such as domains, IP addresses, individual email addresses. All this in order to make reasonable assumptions about the future of their behavior. Very simplistic, this scheme looks like a hash or an associative array, where the key is, for example, the IP address, and the value is information about how much spam or non-spam we got from this address. Once, storing and using such a hash, even for 2 32 different possible key values, presented certain difficulties in programming. Imagine what happens when you need to store the reputation of IPv6 addresses, the total number of which greatly exceeds even the number of individual bits in the RAM of all Yandex servers.
Fortunately, the IPv6 address space is very thin. Huge sequences, as they say, by design are not used. Additionally, network / 64 standardization as an IPv6 address allocation quantum is an important optimization factor. In general, in the end everything worked as it should.
About a year ago we began to send letters to external servers via IPv6, if they supported it. This part of the work required only fine tuning of Postfix and thorough testing. Reception of mail turned out to be more difficult in the first place because of anti-spam algorithms. Finally, this work is completed - in February 2014 we began receiving letters on IPv6. See:
% host -t any mx.yandex.ru
mx.yandex.ru has IPv6 address 2a02: 6b8 :: 89
mx.yandex.ru has address 87.250.250.89
mx.yandex.ru has address 93.158.134.89
mx.yandex.ru has address 213.180.193.89
mx.yandex.ru has address 213.180.204.89
mx.yandex.ru has address 77.88.21.89
%
Now all Yandex.Mail for server-to-server traffic can be received and transmitted using the IPv6 protocol. Here we did not use DNS whitelists, because IPv6 connectivity between servers is generally better than between servers and users. In addition, working with multiple MXs in SMTP allows essentially automatically degrading to IPv4 in the event of IPv6 failure. Finally, SMTP server is not an interactive protocol, so possible connection timeouts do not directly affect the user experience.
This change has gone unnoticed by users, and this invisibility constitutes a special pride for the whole team. A big step forward has been made, guarantees have been created that your mail will be reliably delivered by Yandex both in 2 and 5, and in 10 years, when the old protocols will completely cease to satisfy the needs of humanity and will be discarded.
Interestingly, all modern anti-spam protection operating in the framework of large mail systems, such as Yahoo !, Gmail, Yandex, AOL, Mail.ru, Outlook.com, have been working for several years as part of a kind of common ecosystem. There is a careful exchange of information about the general waves of spam, made certain settings for reliable mutual exchange of letters and so on. We all work closely together even though we are competitors. This, by the way, is one of the reasons why no stand-alone antispam solutions can match the quality of filtering with large mails. They just do not have enough information and nowhere to get it. So, this ecosystem will require some time to configure itself for the widespread use of IPv6. The earlier this work begins, the faster the overall result will be achieved. It is no longer possible to postpone.
Why is it important for providers and big players to support IPv6
When the problem of a shortage of theoretical IPv4 addresses became increasingly real, providers began to use NAT. But in the end it was not a solution. When there are too many devices behind NAT, sites may decide that the robots create a load on them and take measures to protect against such actions.
Such a problem, in particular, became widespread in Belarus . This happened relatively recently, after the transition of RIPE to the phase of address allocation from the last block / 8. Belarusian providers did not have enough supply of IP-addresses and, being in the conditions of their shortage, they went by increasing the number of users for NAT. As a result, some Internet services took the activity of NAT users for the activities of robots, and some of them completely blocked the IP address (and all NAT users) or increased the display intensity of the captcha. Thus, the lack of availability of providers to exhaust IPv4 addresses has led to a decline in the quality of Internet access for users. A similar problem exists for mail systems: there large NAT pools mean that letters sent by the user to NAT can be mistaken for spam and not reach the addressee.
IPv6 traffic graph on www.yandex.ru
Currently, according to various estimates, only about 3% of traffic on the Internet uses IPv6, and 97% use old IPv4. But when such large players as Yandex, Google, VKontakte, Facebook, support IPv6 technically and ideologically, they push providers to support sixth addresses, they push the entire Internet into the future. Of course, it is important for us and ourselves to understand that our services have enough addresses. But even in aggregate, they are much smaller compared to how many sites may appear on the Internet in the future and how many people will get access to it.
Source: https://habr.com/ru/post/215535/
All Articles