Саму методику оценки было решено разделить на 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), но окончательно пока не исчезли. Жалоб на скорость загрузки сайтов и/или на полное отсутствие доступа к чему-либо не поступало.
И самое интересное, из-за чего все и затевалось (Устоявшийся режим. Левый график для сервисов, правый график для пользователей):
Ну что, внешние сервисы можно и нужно переводить на dual stack. Во всяком случае для почты имеем превышение трафика на IPv6 почти в два раза. Доступность сервиса скорее улучшится (за счет наличия дублирующихся связей), чем ухудшится.
Внутренние сервисы можно изначально строить на чистом IPv6. Маршрутизация потребует меньшего количества ресурсов, чем традиционный проброс портов. Упростится мониторинг сети. Безопасность всех сервисов можно обеспечить парой правил на пограничном маршрутизаторе, сохранив при этом доступ для управления из внешнего мира.
А вот конечных пользователей переход на dual stack череват неожиданными проблемами. Ожидать кардинальных улучшений по скорости доступа либо по доступности сторонних сервисов не следует. Трафик по IPv6 пока все-таки меньше, чем по IPv4, но имеется тенденция к изменению этого соотношения.
Интересные ресурсы по теме
- Google IPv6 statistics
- Cisco IPv6 adoption monitor
- Проверка подключения на поддержку IPv6
- Русскоязычный сайт об IPv6
- IPv6 на хабре от Kasatka23 часть 1 и часть 2
- IPv6 на хабре от Loiqig (неудачный опыт внедрения)
Комментарии (25)
artemlight
25.07.2016 23:43-1Гораздо интереснее на ipv6 делается фейловер.
Ибо маскардинг — штука простая. Меняем маршрут в default gateway, сбрасываем таблицу соединений — и снова всё работает. А вот как перебросить ipv6 /64 на другой аплинк — пока представляю очень слабо.
feo_sobolev
26.07.2016 00:24Почему-же, с учетом количества доступных IPv6-адресов, в будущем, не должно быть проблем с тем, чтобы получить свой блок PI-адресов, далее по BGP анонсировать их обоим аплинком. Вот вам фейловер и балансировка! :)
Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
varnav
26.07.2016 03:45Маршрутизация потребует меньшего количества ресурсов, чем традиционный проброс портов. Упростится мониторинг сети.
Почему?remzalp
26.07.2016 06:25Навскидку:
проброс портов — приняли пакет, посмотрели в таблицу NAT, подменили адреса/порты в заголовке, передали дальше
маршрутизация — приняли пакет, посмотрели таблицу маршрутизации, передали дальше
Проброс чуть длиннее операция, плюс на многих железяках маршрутизация работает практически без нагрузки на центральный процессор
Vilos
26.07.2016 09:10Добавлю еще, что на некоторых железяках маршрутизация работает НЕ "… практически без нагрузки на центральный процессор", а совершенно без нагрузки на ЦП и в обход его, на отдельных микросхемах.
Barafu
26.07.2016 09:41А IPv6 эти железки умеют, или скидывают на процессор, который к этому совершенно не готов?
Mystray
26.07.2016 10:04Современные Л3-коммутаторы отлично маршрутизируют и IPv4 и IPv6 аппаратно, на скорости порта. С пакет-фильтром(stateless-файрволом), динамической маршрутизацией и прочими радостями.
Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
navion
26.07.2016 18:28либо Security-девайсы по цене вертолета
ASA стоит разумных денег, у железки за 150 тыр заявлено 180 Мбит для IPS, а простой NAT с FW наверняка и гигабит вытянет.Mystray
27.07.2016 21:21Это все равно не сопоставимо с line-rate 10G-портов на Л3-коммутаторах. Хотя FW туда сложно впихнуть, да
ksg222
26.07.2016 19:33Мы убираем полностью одну функцию — NAT. А значит меньше нагрузка на железо, меньше возможных багов, ошибок при настройке и прочего. Что в любом раскладе хорошо. Просто мы привыкли к NAT, как данности. При этом вряд ли мы поставим на периметр сети компании обычный L3-коммутатор, даже если функций NAT нам не требуется. Всё равно потребуется какой-нибудь более менее нормальный FW/NGFW (statefull).
Другое дело, как я понимаю, провайдеры. Они, избавившись от NAT, могут достаточно хорошо сэкономить на железе.
resau
26.07.2016 09:09«Коммерческое использование» предусматривает получение прибыли, не?
По-моему, тема «перспективы использования IPv6 в целях извлечения прибыли» не раскрыта…Vedga
26.07.2016 09:16В данном контексте «коммерческое» подразумевает использование с целью предоставления услуг, а не в тестовом режиме. См. выводы в конце: если вы предоставляете сервисы, то применять IPv6 можно и нужно. Если вы предоставляете доступ в Интернет конечным пользователям, то внедрение IPv6 принесет пока только дополнительные проблемы для техподдержки пользователей.
Dr_Zoidberg
26.07.2016 11:15-3В 2016 году актуальнее будет заметка «Перспективы коммерческого использования сети Интернет в России (год 2016)»
remzalp
Хотелось бы услышать про обеспечение безопасности внутренних сервисов буквально парой правил. Пока что у меня бытует мнение, что IPv6 довольно хорошая дырка внутрь сети при неправильном подходе.
ValdikSS
Если запрещать все входящие IPv6-соединения по умолчанию, то работать он будет примерно так же, как и за NAT в IPv4. Зато на каждый компьютер свой IP, никаких проблем.
G-M-A-X
Хм.
На CentOS 7 по умолчанию все закрыто.
Дырки из-за дырявых рук.
varnav
В 7.2 minimal файервол по умолчанию даже не установлен.
G-M-A-X
Хм.
Тогда пофиг, что IPv4, что IPv6.
Устанавливаем файервол и все закрыто.
Mystray
Нет, на самом деле бытует ошибочное мнение, будто NAT — инструмент безопасности.
remzalp
А можете привести примеры атак именно на NAT/PAT?
Mystray
Что вы понимаете под «атакой на NAT/PAT»?
Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?
Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
Vedga
# Если интерфейс lan смотрит в локальную сеть, то эти правила разрешают для IPv4/IPv6 только запрошенный из ЛС трафик.
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i lan -m state --state NEW -j ACCEPT