Prospects for the commercial use of IPv6 in Russia (year 2016)
Having played around with various IPv6 solutions on the stands and appreciating all their charms, I wondered somehow about commercial exploitation. Of course, in the form of dual stack, and not as “IPv6-only”.
The assessment methodology itself was decided to be divided into 2 parts: the use of IPv6 in the implementation of services and the use of IPv6 by end users. He didn’t, of course, experiment with large projects. But the result of the study of small things is ready to share with the community.
To assess the possibility of using IPv6 for services, a server was used that is used by a small company as a mail server. Server is weak: 2 domains, 10-15 accounts on each. Consumers are connected mainly via IMAP4, although a web muzzle is also present. Mostly incoming mail traffic. In the same place the caching DNS used exclusively by a mailer.
For the evaluation of IPv6 by the users, a host was used, which is used as a frontier for distributing the Internet in a small company (5 jobs). The main traffic consumption: surfing the web pages, corporate mail and some social networks - the usual situation in a non-IT office. Well, plus another WiFi access point that distributes the Internet to 3-4 devices on the Android platform.
')
In both cases, the provider provided native IPv6.
For the mail server, duplicate AAAA records have been added to the DNS for MX records. For DNS, a new list of root servers containing IPv6 addresses has been downloaded. The changes in the firewall are minimal: in fact, the rules from IPv4 were duplicated for IPv6.
For end users, along with private IPv4 addresses issued via DHCP, additional IPv6 addresses were issued via SLAAC. Since the provider provided the prefix / 64, each client was assigned a static IPv6 address. To protect the border router, a rule was created that allowed incoming traffic if and only if it was previously requested by the client from the local network.
Any changes in the functioning of the postal service is not marked. Connections to email servers that support IPv6 (yandex.ru, gmail.com, etc.) occur predominantly over IPv6. Timeouts for unavailability work out quite rarely. However, postfix in this case tries to reconnect itself over IPv4 and the resulting delay in delivery in this case can be neglected.
Spammers (for now?) Mostly live on IPv4. But practically none of the blacklists supports IPv6. Not all servers have correctly configured reverse dns zone for IPv6 (but this is treated by weight selection in spam).
From the point of view of users, a problem was noted when Google and Yandex reported on “suspicious traffic from IPv6 addresses” and demanded to confirm that the user is not a robot. After about a week of operation, such requests began to appear less frequently (recall that users are issued IPv6 static by SLAAC), but they have not yet completely disappeared. Complaints about the speed of loading sites and / or the complete lack of access to something has not been reported.
And the most interesting, which is why everything was started (Stable mode. Left schedule for services, right schedule for users):
Well, external services can and should be transferred to the dual stack. In any case, for mail, we have almost twice as much traffic on IPv6. The availability of the service is likely to improve (due to the presence of duplicate links), rather than worsen.
Internal services can be initially built on pure IPv6. Routing will require fewer resources than traditional port forwarding. Simplified network monitoring. All services can be secured with a pair of rules on a border router, while maintaining control access from the outside world.
But the end-user transition to the dual stack is fraught with unexpected problems. There is no need to expect dramatic improvements in access speed or availability of third-party services. IPv6 traffic is still less than IPv4 traffic, but this ratio tends to change.
The assessment methodology itself was decided to be divided into 2 parts: the use of IPv6 in the implementation of services and the use of IPv6 by end users. He didn’t, of course, experiment with large projects. But the result of the study of small things is ready to share with the community.
To assess the possibility of using IPv6 for services, a server was used that is used by a small company as a mail server. Server is weak: 2 domains, 10-15 accounts on each. Consumers are connected mainly via IMAP4, although a web muzzle is also present. Mostly incoming mail traffic. In the same place the caching DNS used exclusively by a mailer.
For the evaluation of IPv6 by the users, a host was used, which is used as a frontier for distributing the Internet in a small company (5 jobs). The main traffic consumption: surfing the web pages, corporate mail and some social networks - the usual situation in a non-IT office. Well, plus another WiFi access point that distributes the Internet to 3-4 devices on the Android platform.
')
In both cases, the provider provided native IPv6.
For the mail server, duplicate AAAA records have been added to the DNS for MX records. For DNS, a new list of root servers containing IPv6 addresses has been downloaded. The changes in the firewall are minimal: in fact, the rules from IPv4 were duplicated for IPv6.
For end users, along with private IPv4 addresses issued via DHCP, additional IPv6 addresses were issued via SLAAC. Since the provider provided the prefix / 64, each client was assigned a static IPv6 address. To protect the border router, a rule was created that allowed incoming traffic if and only if it was previously requested by the client from the local network.
Operating results
Any changes in the functioning of the postal service is not marked. Connections to email servers that support IPv6 (yandex.ru, gmail.com, etc.) occur predominantly over IPv6. Timeouts for unavailability work out quite rarely. However, postfix in this case tries to reconnect itself over IPv4 and the resulting delay in delivery in this case can be neglected.
Spammers (for now?) Mostly live on IPv4. But practically none of the blacklists supports IPv6. Not all servers have correctly configured reverse dns zone for IPv6 (but this is treated by weight selection in spam).
From the point of view of users, a problem was noted when Google and Yandex reported on “suspicious traffic from IPv6 addresses” and demanded to confirm that the user is not a robot. After about a week of operation, such requests began to appear less frequently (recall that users are issued IPv6 static by SLAAC), but they have not yet completely disappeared. Complaints about the speed of loading sites and / or the complete lack of access to something has not been reported.
And the most interesting, which is why everything was started (Stable mode. Left schedule for services, right schedule for users):
Well, external services can and should be transferred to the dual stack. In any case, for mail, we have almost twice as much traffic on IPv6. The availability of the service is likely to improve (due to the presence of duplicate links), rather than worsen.
Internal services can be initially built on pure IPv6. Routing will require fewer resources than traditional port forwarding. Simplified network monitoring. All services can be secured with a pair of rules on a border router, while maintaining control access from the outside world.
But the end-user transition to the dual stack is fraught with unexpected problems. There is no need to expect dramatic improvements in access speed or availability of third-party services. IPv6 traffic is still less than IPv4 traffic, but this ratio tends to change.
Interesting resources on the topic
- Google ipv6 statistics
- Cisco IPv6 adoption monitor
- Check connectivity for IPv6 support
- Russian site about IPv6
- IPv6 on Habré from Kasatka23 part 1 and part 2
- IPv6 on Habré from Loiqig ( bad implementation experience )
Source: https://habr.com/ru/post/306342/
All Articles