IPv6: IANA раздала последние блоки, провайдер закрыл кран, мы начали тестировать dual-stack

Три дня назад IANA официально закрыла реестр свободных IPv4-адресов. Последние пять блоков /8 ушли к региональным регистраторам (RIR) - по одному каждому. RIPE NCC свой получил. Дальше RIR будут раздавать то, что есть в их запасах, и когда запасы кончатся - всё. Конец очереди.

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

Что это означает прямо сейчас

Для большинства клиентских площадок, которые у нас в обслуживании, ситуация неплохая: адреса уже выданы, они никуда не денутся. Проблема возникает в двух случаях:

• Открытие новой площадки или офиса - получить дополнительный блок IPv4 станет гораздо сложнее и дороже, чем год назад.
• Рост числа публично-доступных сервисов - каждый новый публичный адрес теперь это дефицитный ресурс, который надо планировать заранее.

NAT решает часть проблемы внутри периметра - мы и так давно строим внутренние сети на RFC 1918. Но NAT не решает вопрос, если клиент хочет несколько десятков публичных IP под серверы или мультихоминг. Вот тут IPv6 перестаёт быть «чем-то для будущего» и становится практической задачей на этот квартал.

Тест dual-stack на пограничных маршрутизаторах

Начали с лабораторного стенда на двух Cisco 7200. Схема простая: один имитирует пограничный PE провайдера с поддержкой IPv6, второй - наш CPE. Задача - поднять dual-stack так, чтобы IPv4 и IPv6 работали параллельно, без деградации существующего трафика.

С точки зрения IOS это выглядит довольно прямолинейно. На физических интерфейсах добавляешь ipv6 address, включаешь ipv6 unicast-routing глобально, настраиваешь OSPFv3 или статику для IPv6-маршрутов рядом с обычным OSPF для IPv4. Маршрутизатор гоняет оба стека независимо, конфликтов нет. BGP с провайдером тоже поднимается без сюрпризов - отдельная IPv6 address-family в существующей BGP-сессии или новый пиринг, по договорённости с провайдером.

Практические шероховатости, которые мы поймали:

• Анонсирование маршрутов по умолчанию - в IPv6 нет привычного ip default-network, логика немного другая. Нужно явно редистрибьютить или анонсировать ::/0, иначе хосты в IPv6 уходят в никуда.
• ND (Neighbor Discovery) вместо ARP - на сегментах с большим количеством хостов надо следить за ND-кешем и таймаутами, иначе на нагруженных интерфейсах появляется лишний шум.
• Firewall-правила нужно писать заново - ACL для IPv6 в IOS это отдельные списки, они не наследуют IPv4-правила. У нас несколько клиентов с довольно объёмными политиками доступа, перенос займёт время.

На стенде всё работает. Следующий шаг - тест на реальном пограничном оборудовании одного из клиентов, у которого провайдер уже подтвердил готовность к dual-stack пирингу.

6in4-туннели для тех, кто не готов

Есть три офисных площадки, где провайдер местный и IPv6 в его ближайших планах не значится. Для них пробуем 6in4 - инкапсуляцию IPv6 в IPv4, протокол 41 поверх обычного IPvIP.

Механика такая: на нашей стороне - Cisco с глобальным IPv4-адресом и IPv6-префиксом от туннельного брокера (пользуемся Hurricane Electric, их бесплатный сервис покрывает нужды для тестов). На стороне офиса - либо Cisco с поддержкой tunnel-интерфейса типа ipv6ip, либо Linux-машина с ip tunnel add. Статический туннель, фиксированные endpoints, MTU 1480.

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

Главная проблема туннелей - это не техника, а операция. Туннель дополнительная сущность, которую надо мониторить, включать в схему сети, учитывать при диагностике. Когда провайдер на той стороне перестраивает что-то в своей IPv4-сети - туннель может упасть или начать терять пакеты, и разбираться в этом сложнее, чем с нативным подключением.

Что дальше

DNS мы ещё не трогали вплотную - нужно проверить, как клиентские резолверы и authoritative-серверы ведут себя с AAAA-записями рядом с A. BIND 9 это поддерживает нормально, но надо убедиться, что нет неожиданных предпочтений на клиентской стороне.

Адресация внутренних сетей в IPv6 - отдельная задача. Диапазон fd00::/8 для ULA выглядит логичным аналогом RFC 1918, но привычка к коротким адресам типа 192.168.1.x ещё долго будет давать о себе знать в операционных процессах - в шаблонах документации, скриптах мониторинга, голове коллег.

Общий вывод после первой недели тестов: технически всё работает, Cisco IOS поддерживает IPv6 без экзотических плясок. Сложность не в протоколе - в операционной обёртке. Правила доступа, мониторинг, документация, обучение коллег - вот где реальная работа. На это мы закладываем несколько месяцев, а не недель.