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

    Поигравшись с разнообразными решениями 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 (неудачный опыт внедрения)

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 25

      –1
      Хотелось бы услышать про обеспечение безопасности внутренних сервисов буквально парой правил. Пока что у меня бытует мнение, что IPv6 довольно хорошая дырка внутрь сети при неправильном подходе.
        +2
        Если запрещать все входящие IPv6-соединения по умолчанию, то работать он будет примерно так же, как и за NAT в IPv4. Зато на каждый компьютер свой IP, никаких проблем.
          0
          Хм.
          На CentOS 7 по умолчанию все закрыто.
          Дырки из-за дырявых рук.
            0
            В 7.2 minimal файервол по умолчанию даже не установлен.
              +1
              Хм.
              Тогда пофиг, что IPv4, что IPv6.
              Устанавливаем файервол и все закрыто.
            +4
            Нет, на самом деле бытует ошибочное мнение, будто NAT — инструмент безопасности.
              –1
              А можете привести примеры атак именно на NAT/PAT?
                0
                Что вы понимаете под «атакой на NAT/PAT»?
                Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?

                Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
              0
              # Если интерфейс lan смотрит в локальную сеть, то эти правила разрешают для IPv4/IPv6 только запрошенный из ЛС трафик.
              -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
              -A FORWARD -i lan -m state --state NEW -j ACCEPT
              –1
              Гораздо интереснее на ipv6 делается фейловер.
              Ибо маскардинг — штука простая. Меняем маршрут в default gateway, сбрасываем таблицу соединений — и снова всё работает. А вот как перебросить ipv6 /64 на другой аплинк — пока представляю очень слабо.
                0
                Почему-же, с учетом количества доступных IPv6-адресов, в будущем, не должно быть проблем с тем, чтобы получить свой блок PI-адресов, далее по BGP анонсировать их обоим аплинком. Вот вам фейловер и балансировка! :)
                Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
                0
                Маршрутизация потребует меньшего количества ресурсов, чем традиционный проброс портов. Упростится мониторинг сети.

                Почему?
                  0
                  Навскидку:
                  проброс портов — приняли пакет, посмотрели в таблицу NAT, подменили адреса/порты в заголовке, передали дальше
                  маршрутизация — приняли пакет, посмотрели таблицу маршрутизации, передали дальше
                  Проброс чуть длиннее операция, плюс на многих железяках маршрутизация работает практически без нагрузки на центральный процессор
                    0
                    Добавлю еще, что на некоторых железяках маршрутизация работает НЕ "… практически без нагрузки на центральный процессор", а совершенно без нагрузки на ЦП и в обход его, на отдельных микросхемах.
                      0
                      А IPv6 эти железки умеют, или скидывают на процессор, который к этому совершенно не готов?
                        0
                        Современные Л3-коммутаторы отлично маршрутизируют и IPv4 и IPv6 аппаратно, на скорости порта. С пакет-фильтром(stateless-файрволом), динамической маршрутизацией и прочими радостями.
                        Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
                          0
                          либо Security-девайсы по цене вертолета

                          ASA стоит разумных денег, у железки за 150 тыр заявлено 180 Мбит для IPS, а простой NAT с FW наверняка и гигабит вытянет.
                            0
                            Это все равно не сопоставимо с line-rate 10G-портов на Л3-коммутаторах. Хотя FW туда сложно впихнуть, да
                            0
                            Мы убираем полностью одну функцию — NAT. А значит меньше нагрузка на железо, меньше возможных багов, ошибок при настройке и прочего. Что в любом раскладе хорошо. Просто мы привыкли к NAT, как данности. При этом вряд ли мы поставим на периметр сети компании обычный L3-коммутатор, даже если функций NAT нам не требуется. Всё равно потребуется какой-нибудь более менее нормальный FW/NGFW (statefull).
                            Другое дело, как я понимаю, провайдеры. Они, избавившись от NAT, могут достаточно хорошо сэкономить на железе.
                    0
                    «Коммерческое использование» предусматривает получение прибыли, не?

                    По-моему, тема «перспективы использования IPv6 в целях извлечения прибыли» не раскрыта…
                      0
                      В данном контексте «коммерческое» подразумевает использование с целью предоставления услуг, а не в тестовом режиме. См. выводы в конце: если вы предоставляете сервисы, то применять IPv6 можно и нужно. Если вы предоставляете доступ в Интернет конечным пользователям, то внедрение IPv6 принесет пока только дополнительные проблемы для техподдержки пользователей.
                      0
                      Оффтоп: это у вас на заббиксе шкурка такая или заббикс сам новой версии?
                        0
                        Просто заббикс, недавно скачанный с офсайта. Ничего специально не красил. Кстати вебморда работает (практически) без глюков на lighttpd и php 71.
                          0
                          3.0 же
                          –3
                          В 2016 году актуальнее будет заметка «Перспективы коммерческого использования сети Интернет в России (год 2016)»

                          Only users with full accounts can post comments. Log in, please.