IPv6 World Launch: день X прошёл - считаем потери и разбираем dual-stack на периметре

Итак, день X наступил. 6 июня 2012 года Google, Facebook, Bing и ещё несколько десятков организаций постоянно включили AAAA-записи на своих публичных именах. Ряд крупных ISP в разных странах одновременно раздал IPv6-адреса на весь абонентский пул - не в тестовом режиме, а штатно.

Мы готовились к этому с февраля - аудит инфраструктуры клиентов показал тогда неприятную картину с RA-guard на коммутаторах. Часть работы успели сделать. Теперь смотрим, что фактически произошло в день запуска.

Главный сюрприз: сломался не периметр, а домашние роутеры

Пока мы занимались RA-guard и серверными конфигурациями, самая массовая поломка пришла оттуда, откуда её никто особо не ждал: от домашних роутеров сотрудников, работающих удалённо, и от малых офисов с потребительским оборудованием.

Механика проблемы простая. Как только крупные ISP включили IPv6 на абонентских портах, домашний роутер начал получать RA от провайдера и пытаться установить IPv6-связность. Большинство современных роутеров поддерживают это через SLAAC. И здесь начались варианты:

• Роутер настроил IPv6, но DNS резолвер не умеет AAAA. Браузер получает AAAA-запись для google.com, пытается соединиться по IPv6, а стек роутера молча роняет пакеты. Пользователь видит «сайт недоступен» при живом IPv4.
• Роутер настроил IPv6, но NAT64/DNS64 не настроен. Часть трафика уходит по IPv6, часть по IPv4, приложения ведут себя непредсказуемо.
• Роутер настроил «кривой» IPv6 с правильным адресом, но неверным шлюзом. Happy eyeballs отрабатывает, но с задержкой в несколько секунд на каждое соединение - пользователь уверен, что интернет «лагает».

У нас в этот день прилетело несколько звонков вида «всё стало медленно» и один «перестала открываться почта». Все - от малых офисов или удалённых сотрудников на потребительских роутерах. На управляемых периметрах с нормальным оборудованием всё прошло тихо.

Что такое dual-stack на периметре - и почему это не «просто добавить AAAA»

На корпоративном периметре dual-stack - это не переключатель, это архитектурное решение с несколькими слоями.

Адресация. Нужен блок IPv6 от провайдера или PI-блок. Большинство наших клиентов с нормальным оборудованием уже получили /48 или /56 - это не проблема.

Маршрутизация. BGP-сессии с апстримом по IPv6, анонс собственного префикса, внутренние маршруты. На Cisco и Juniper работает, и работало ещё до этого дня. Проблема была только у клиентов со старыми firmware на граничных устройствах - двух таких мы закрыли заранее.

Фаервол. Это главная засада. ACL-логика, которая есть для IPv4, не переносится на IPv6 автоматически. Нужно явно прописывать правила для нового стека - и не забыть про ICMPv6, который нельзя просто заблокировать весь, как иногда делают с ICMP в IPv4. Без корректной обработки ICMPv6 (особенно Neighbor Discovery) IPv6 просто не работает.

DNS. AAAA-записи для публичных сервисов - это просто. Внутренние зоны сложнее: нужно убедиться, что internal резолверы умеют корректно обрабатывать AAAA-запросы и не уходят в таймаут при их отсутствии.

Мониторинг. Zabbix и Nagios у большинства клиентов настроены на IPv4. IPv6-адреса нужно добавить отдельно - иначе мониторинг не видит нового стека вообще, даже если он сломан.

Что по итогам дня

На управляемой инфраструктуре крупных клиентов - без неожиданностей. Подготовка сработала. Публичные сервисы, у которых мы добавили AAAA-записи заранее, начали получать IPv6-трафик - немного, но стабильно.

На периметре одного клиента обнаружили, что правила фаервола для ICMPv6 были написаны слишком агрессивно: заблокировали Packet Too Big, в результате Path MTU Discovery перестал работать и соединения по IPv6 падали на крупных пакетах. Поправили за час, но симптом был неочевидный - TCP-сессии устанавливались, а потом зависали.

Малый бизнес и удалённые сотрудники - вот где был настоящий день хаоса. Там решение в большинстве случаев простое: отключить IPv6 на роутере и подождать, когда провайдер и производитель оборудования наладят нормальную поддержку. Неудобный, но рабочий вариант на сегодня.

Вопрос с RA-guard на коммутаторах, который мы зафиксировали в феврале, остаётся открытым - он не острый прямо сейчас, но план замены оборудования по-прежнему актуален. IPv6 в локальных сетях - это следующий этап, до которого ещё нужно дойти аккуратно.