Перспективы коммерческого использования IPv6 в России (год 2016)

в 15:14, , рубрики: 6in4, IPv6, isp, teredo, ит-инфраструктура, Сетевые технологии, системное администрирование

Поигравшись с разнообразными решениями IPv6 на стендах и оценив все их прелести, задумался я как-то и над коммерческой эксплуатацией. Конечно, в виде dual stack, а не как «IPv6-only».

Саму методику оценки было решено разделить на 2 части: использование IPv6 при реализации сервисов и использование IPv6 конечными пользователями. Над большими проектами эксперементировать, естественно, не стал. А вот результатом исследования мелочевки готов поделиться с сообществом.

Для оценки возможности использования IPv6 для сервисов был взят сервер, используемый небольшой компанией в качестве почтового. Сервер слабенький: 2 домена, по 10-15 аккаунтнов на каждом. Потребители подключаются в основном по IMAP4, хотя WEB-морда также присутствует. Преимущественно входящий почтовый трафик. Там же кеширующий DNS, используемый исключительно почтовиком.

Для оценки IPv6 со стороны пользователей был взят хост, используемый в качестве пограничного для раздачи Интернета в небольшой фирме (5 рабочих мест). Основное потребление трафика: серфинг web-страниц, корпоративная почта ну и немного соцсетей — обычная ситуация в не-IT конторе. Ну плюс еще WiFi-точка доступа, раздающая Интернет на 3-4 устройства на платформе Android.

В обоих случаях провайдер предоставлял native IPv6.

Для почтового сервера в DNS для MX-записей были добавлены дублирующие AAAA-записи. Для DNS был загружен новый список корневых серверов, содержащих IPv6-адреса. Изменения в firewall минимальные: фактически правила из IPv4 были продублированы для IPv6.

Для конечных пользователей вместе с частными IPv4 адресами, выдаваемыми через DHCP, выдавались и дополнительные IPv6-адреса посредством SLAAC. Так как провайдер предоставил префикс /64, каждому клиенту выделялся статический IPv6-адрес. Для защиты на пограничном маршрутизаторе было создано правило, разрешающее входящий трафик в том и только в том случае, если он был ранее запрошен клиентом из локальной сети.

Результаты эксплуатации

Каких-нибудь изменений в функционировании почтового сервиса не отмечено. Соединения с почтовым серверами, поддерживающими IPv6 (yandex.ru, gmail.com и т.п.) происходят преимущественно по IPv6. Таймауты по недоступности отрабатывают достаточно редко. Впрочем postfix в этом случае пытается самостоятельно переподключиться по IPv4 и возникающей задержкой доставки в этом случае можно пренебречь.

Спамеры (пока?) в основном живут на IPv4. Зато практически ни один из blacklist-ов не поддерживает IPv6. Не у всех серверов корректно настроена reverse dns zone для IPv6 (но это лечится подбором веса в спамассасине).

С точки зрения пользователей отмечалась проблема, когда Гугл и Яндекс сообщал о «подозрительном трафике с IPv6-адресов» и требовал подтвердить, что пользователь не является роботом. Приблизительно через неделю эксплуатации такие запросы стали появляться реже (напомню, что пользователям выдается IPv6 статика по SLAAC), но окончательно пока не исчезли. Жалоб на скорость загрузки сайтов и/или на полное отсутствие доступа к чему-либо не поступало.

И самое интересное, из-за чего все и затевалось (Устоявшийся режим. Левый график для сервисов, правый график для пользователей):

Кол-во подключений IPv6 и IPv4

Ну что, внешние сервисы можно и нужно переводить на dual stack. Во всяком случае для почты имеем превышение трафика на IPv6 почти в два раза. Доступность сервиса скорее улучшится (за счет наличия дублирующихся связей), чем ухудшится.

Внутренние сервисы можно изначально строить на чистом IPv6. Маршрутизация потребует меньшего количества ресурсов, чем традиционный проброс портов. Упростится мониторинг сети. Безопасность всех сервисов можно обеспечить парой правил на пограничном маршрутизаторе, сохранив при этом доступ для управления из внешнего мира.

А вот конечных пользователей переход на dual stack череват неожиданными проблемами. Ожидать кардинальных улучшений по скорости доступа либо по доступности сторонних сервисов не следует. Трафик по IPv6 пока все-таки меньше, чем по IPv4, но имеется тенденция к изменению этого соотношения.

Интересные ресурсы по теме

  1. Google IPv6 statistics
  2. Cisco IPv6 adoption monitor
  3. Проверка подключения на поддержку IPv6
  4. Русскоязычный сайт об IPv6
  5. IPv6 на хабре от Kasatka23 часть 1 и часть 2
  6. IPv6 на хабре от Loiqig (неудачный опыт внедрения)

Автор: Vedga

Источник

Поделиться новостью

* - обязательные к заполнению поля