IPv6 World Launch в июне: проверяем инфраструктуру на dual-stack и находим неприятное

В июне этого года ISOC, Google, Facebook, Akamai, Cisco и ещё несколько десятков крупных игроков планируют постоянно включить IPv6 на своих публичных сервисах. Не на день и не в тестовом режиме - насовсем. Называется это IPv6 World Launch, и дата поставлена: 6 июня 2012.

Мы решили не ждать лета и провести аудит прямо сейчас - посмотреть, что из нашей инфраструктуры и инфраструктуры клиентов в управляемой поддержке реально готово к dual-stack, а что потребует работы.

Результаты оказались интереснее, чем мы рассчитывали.

Что проверяли и как

Разбили задачу на несколько слоёв: адресация и маршрутизация, безопасность на уровне L2, конфигурации хостов и сервисов, DNS. Прошлись по каждому стенду, который сопровождаем, и по собственным узлам.

Адресация и маршрутизация. Здесь всё относительно прилично. Оба основных апстрима уже анонсируют IPv6-префиксы, получить блок /48 или /56 от провайдера не проблема. Маршрутизаторы Cisco и Juniper, которые стоят у большинства клиентов, dual-stack понимают давно. BGP-сессии с IPv6-адресацией поднимаются без особых сюрпризов. Это, пожалуй, самый зрелый слой.

DNS. Тут ситуация пёстрая. AAAA-записи добавить несложно, но выяснилось, что несколько внутренних зон настроены так, что резолвер при получении AAAA-запроса ведёт себя непредсказуемо - то отвечает NXDOMAIN, то уходит в таймаут. Это не катастрофа, но каждый такой случай нужно пройти руками. Публичные зоны чище, внутренние - заметно хуже.

Хосты и сервисы. Linux-серверы с актуальными ядрами dual-stack поднимают нормально. Windows Server 2008 R2 тоже. Проблемы начались в паре мест, где IPv6 был явно отключён в реестре или через sysctl «чтобы не мешал» - кто-то когда-то решил так сделать, и это успело забыться. Нашли, раскомментировали, проверили.

Неприятный сюрприз: RA-guard

Вот где нас поджидало по-настоящему неудобное открытие.

В IPv6-сетях Router Advertisement (RA) - это механизм, с помощью которого маршрутизатор сообщает хостам о своём существовании и раздаёт им параметры сети через SLAAC. Проблема в том, что RA может отправить любой хост в сегменте - намеренно или по ошибке. Достаточно одной Windows-машины с включённым IPv6 и неправильно настроенным ICS, и весь сегмент получит «левый» дефолтный маршрут.

RA-guard - это функция коммутатора, которая фильтрует RA-пакеты и пропускает их только с доверенных портов (там, где стоит маршрутизатор). Аналог DHCP snooping для IPv4, только для IPv6.

Мы прошлись по парку коммутаторов. Результат: больше половины оборудования RA-guard не поддерживает вообще. Это в основном управляемые коммутаторы среднего ценового сегмента - D-Link DES/DGS серий нескольких лет выпуска, часть оборудования HP ProCurve старших моделей. Там либо функции нет в прошивке, либо есть, но реализована частично и не распространяется на IPv6 NDP в полном объёме.

Cisco Catalyst и Catalyst Express в парке с этим справляются. Juniper EX тоже. Но они в меньшинстве.

Что это означает практически

Включить IPv6 в сегментах без RA-guard - значит открыть возможность для RA-spoofing атак изнутри сети. Любой скомпрометированный хост или просто плохо настроенная машина может перехватить трафик всего сегмента, подсунув себя в качестве шлюза. В IPv4 DHCP snooping и dynamic ARP inspection давно закрывают аналогичные векторы - в IPv6 без RA-guard этой защиты нет.

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

Что попало в план замен

По результатам аудита составили список по клиентам и по собственным узлам. Несколько позиций:

• D-Link DES-3526/3550 - RA-guard отсутствует, прошивки с поддержкой нет. Подлежат замене при следующем цикле обновления оборудования.
• HP ProCurve 2610 - частичная поддержка NDP inspection, но не полная. Требует дополнительного тестирования и, вероятно, замены.
• Несколько неуправляемых коммутаторов в небольших сегментах - там вопрос решается изоляцией и переводом сегментов на управляемые устройства.

Cisco Catalyst 2960 и 3560 в парке - нормально, RA-guard работает, тестировали на стенде.

Где мы сейчас

До 6 июня четыре месяца. Для большинства клиентов это не означает, что нужно срочно мигрировать всё на dual-stack - большинство внутренних сервисов вполне проживёт на IPv4 ещё долго. Но несколько сценариев уже актуальны сейчас:

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

Практический вывод из аудита не самый приятный: слабое место оказалось там, где его меньше всего ожидали. Маршрутизаторы, серверы, DNS - это всё решаемо относительно быстро. А вот парк коммутаторов, купленных несколько лет назад, теперь требует планового обновления раньше, чем мы закладывали. Бюджеты пересматриваем.