Миграция на IPv6: Dual-Stack, туннелирование и NAT64

Зачем мигрировать сейчас#

Исчерпание IPv4-адресов реально. Все региональные интернет-регистраторы исчерпали свои пулы. Организации платят премиальные цены за небольшие блоки IPv4, в то время как адресное пространство IPv6 остаётся бесплатным. Помимо адресации, IPv6 устраняет сложность NAT, упрощает маршрутизацию и всё чаще становится конкурентным требованием, поскольку основные платформы приоритизируют IPv6-трафик.

Бизнес-кейс прямолинеен: ваши пользователи уже в IPv6-сетях (мобильные операторы, облачные провайдеры, современные провайдеры), но вы можете быть не готовы обслуживать их эффективно. Apple требует поддержку IPv6 для iOS-приложений. Google немного выше ранжирует сайты с IPv6. IPv6-трафик растёт на 25-30% ежегодно.

Три подхода к миграции#

Миграция на IPv6 не универсальна. У вас есть три фундаментальные стратегии:

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

Развёртывание Dual-Stack#

Dual-stack означает, что каждое сетевое устройство говорит на обоих протоколах. Сервер имеет IPv4-адрес (192.0.2.10) и IPv6-адрес (2001:db8::10). Приложения выбирают, какой протокол использовать, на основе назначения и предпочтений.

┌─────────────────────────────────┐
│      Application Layer          │
├─────────────────────────────────┤
│  TCP/UDP (Protocol Agnostic)    │
├──────────────┬──────────────────┤
│  IPv4 Stack  │   IPv6 Stack     │
│  192.0.2.10  │  2001:db8::10    │
└──────────────┴──────────────────┘
         │              │
    IPv4 Network   IPv6 Network

Преимущества#

Dual-stack создаёт нулевые проблемы совместимости. IPv4-only клиенты продолжают работать нормально. IPv6-клиенты получают нативную связность. Вы мигрируете в своём темпе без прерывания сервиса или координации с внешними сторонами.

Архитектура сети со временем упрощается. По мере роста внедрения IPv6 вы можете постепенно отказываться от IPv4-сервисов. Никакого дня флага. Никаких миграционных выходных. Только устойчивый прогресс.

Шаги реализации#

1. Проверьте поддержку оборудования

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

2. Разработайте вашу схему адресации

Запросите префикс /48 или больше у вашего провайдера (или RIR для крупных организаций). Спланируйте структуру подсетей. В отличие от жёсткого разбиения IPv4 на подсети, используйте /64 для всех LAN — стандартный размер подсети, который включает SLAAC.

Пример выделения для /48:

2001:db8:0100::/48  - Получен от провайдера
2001:db8:0100:0001::/64  - Серверы дата-центра
2001:db8:0100:0002::/64  - Офисная LAN
2001:db8:0100:0003::/64  - Гостевая сеть
2001:db8:0100:0010::/64  - DMZ

3. Настройте сетевую инфраструктуру

Включите IPv6-маршрутизацию на пограничных маршрутизаторах. Настройте router advertisements (SLAAC) или DHCPv6 для назначения адресов. Обновите правила файрвола — это критично и часто забывается.

4. Развёртывание на серверах

Начните с малорискованных сервисов. Добавьте AAAA DNS-записи. Тщательно тестируйте перед переходом на production-сервисы. Мониторьте паттерны трафика как IPv4, так и IPv6.

5. Включите подключение клиентов

Современные операционные системы обрабатывают dual-stack автоматически. SLAAC настраивает адреса без DHCP. Клиенты получают как IPv4 (через DHCP), так и IPv6 (через SLAAC) адреса и выбирают соответственно.

Happy Eyeballs: выбор протокола#

RFC 8305 определяет «Happy Eyeballs» — алгоритм, который современные системы используют для выбора между IPv4 и IPv6. Понимание этого помогает отлаживать проблемы связности.

Процесс:

1. DNS-запрос возвращает как A (IPv4), так и AAAA (IPv6) записи
2. Система сначала пытается IPv6-соединение
3. Через 50-250 мс (зависит от реализации) начинает попытку IPv4 параллельно
4. Побеждает первое успешное соединение
5. Результат кэшируется для последующих соединений к тому же хосту

Это гарантирует, что пользователи получают лучшую доступную связность без заметной задержки. IPv6 получает предпочтение, но IPv4 остаётся запасным вариантом.

Вы можете протестировать это поведение с нашим инструментом IPv6 ping. Сравните время отклика для dual-stack назначений.

Механизмы туннелирования#

Туннелирование оборачивает IPv6-пакеты внутри IPv4, позволяя IPv6-связность через IPv4-only инфраструктуру. Думайте об этом как о временном обходном пути, а не постоянном решении.

Оригинал: [IPv6 Header | Data]
Туннелированный: [IPv4 Header | IPv6 Header | Data]

6in4: ручные туннели#

Самый простой метод туннелирования. Настройте две конечные точки вручную, и IPv6-пакеты текут через IPv4-сети как протокол 41 (не UDP или TCP — чистый IP-протокол 41).

Пример конфигурации Linux:

# Создать туннельный интерфейс
ip tunnel add he-ipv6 mode sit remote 209.51.161.14 local 203.0.113.50 ttl 255
 
# Назначить IPv6-адрес (от tunnel broker)
ip addr add 2001:470:1f0a:1ab::2/64 dev he-ipv6
 
# Поднять канал
ip link set he-ipv6 up
 
# Добавить маршрут IPv6 по умолчанию
ip route add ::/0 dev he-ipv6
 
# Проверить
ping6 google.com

Ключевые моменты:

• Протокол 41 должен проходить через файрволы/NAT (часто блокируется)
• Конечные точки туннеля нуждаются в статических IPv4-адресах
• Hurricane Electric и другие tunnel brokers предоставляют бесплатные конечные точки
• Добавляет ~10-30 мс задержки в зависимости от расположения tunnel broker

6rd: быстрое развёртывание провайдера#

6rd позволяет провайдерам предоставлять IPv6 клиентам через существующую IPv4-инфраструктуру. Провайдер запускает relay-серверы, а клиентские маршрутизаторы автоматически туннелируют IPv6-трафик.

В отличие от 6to4, 6rd использует специфичные для провайдера префиксы и контролируемые провайдером релеи, что делает его более надёжным и безопасным. Вы не будете настраивать это вручную — оно автоматически предоставляется, если ваш провайдер поддерживает это.

DS-Lite: IPv4 поверх IPv6#

DS-Lite переворачивает типичный сценарий: он предоставляет IPv4-связность через IPv6-only сеть. Используется провайдерами, переходящими на IPv6-only инфраструктуру, сохраняя при этом IPv4-сервис.

Клиент ----[IPv4-in-IPv6]----> ISP AFTR ----[IPv4]----> Интернет

Клиентское оборудование (элемент B4) туннелирует IPv4 внутри IPv6 к AFTR провайдера (Address Family Transition Router), который выполняет NAT44 перед пересылкой в IPv4-интернет.

Конечные пользователи обычно не настраивают DS-Lite — это управляется провайдером.

Технологии трансляции#

Трансляция конвертирует пакеты между IPv6 и IPv4 на сетевом уровне. Это обеспечивает коммуникацию, когда одна сторона IPv6-only, а другая IPv4-only.

NAT64 с DNS64#

NAT64 транслирует IPv6-пакеты в IPv4 и наоборот. В сочетании с DNS64 обеспечивает прозрачный доступ к IPv4-only сервисам из IPv6-only сетей.

Как это работает:

1. IPv6-only клиент запрашивает DNS для ipv4only.example.com
2. DNS64-сервер видит только A-запись (IPv4), нет AAAA-записи (IPv6)
3. DNS64 синтезирует AAAA-запись, используя NAT64-префикс: 64:ff9b::198.51.100.5
4. Клиент отправляет пакет на синтезированный IPv6-адрес
5. NAT64-шлюз транслирует в IPv4 и пересылает
6. Обратный трафик транслируется обратно в IPv6

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│ IPv6 Client │         │   NAT64     │         │ IPv4 Server │
│             │─────────│   Gateway   │─────────│             │
│2001:db8::1  │  IPv6   │  + DNS64    │  IPv4   │198.51.100.5 │
└─────────────┘         └─────────────┘         └─────────────┘

Общеизвестный NAT64-префикс: 64:ff9b::/96 (RFC 6052)

NAT64 требует stateful-трансляции — шлюз поддерживает состояние сессии, как традиционный NAT44. Это создаёт те же проблемы масштабирования, что и IPv4 NAT.

464XLAT: включение IPv4-приложений#

464XLAT расширяет NAT64, добавляя клиентскую трансляцию (CLAT), позволяя IPv4-only приложениям работать в IPv6-only сетях.

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ IPv4 App     │      │              │      │ IPv4 Server  │
│              │      │ IPv6-only    │      │              │
│ 192.0.0.1    │      │ Network      │      │ 198.51.100.5 │
└──────┬───────┘      └──────────────┘      └──────────────┘
       │                                             │
    CLAT (устройство)                          PLAT (провайдер)
    NAT46                                       NAT64

Мобильные сети широко используют 464XLAT. Ваш телефон работает на IPv6-only стеке, но устаревшие IPv4-only приложения всё ещё работают прозрачно. Android и iOS оба поддерживают CLAT нативно.

Выбор вашей стратегии#

Фреймворк принятия решений на основе характеристик сети:

Есть нативный IPv6 от провайдера?
   │
   ├─ ДА ──> Развёртывайте dual-stack (рекомендуется)
   │          1. Включите IPv6 на пограничном маршрутизаторе
   │          2. Настройте SLAAC/DHCPv6
   │          3. Обновите правила файрвола
   │          4. Добавьте AAAA-записи в DNS
   │
   └─ НЕТ ──> Нужен IPv6 немедленно?
              │
              ├─ ДА ──> Используйте tunnel broker
              │          (Hurricane Electric и т.д.)
              │
              └─ НЕТ ──> Запросите IPv6 у провайдера
                        или планируйте график миграции

Матрица выбора стратегии#

Распространённые ошибки#

1. Неполная конфигурация файрвола#

IPv6-трафик часто обходит правила IPv4-файрвола. Команды безопасности настраивают обширные IPv4-политики, но полностью забывают про IPv6. Результат: нефильтрованная IPv6-связность.

Решение: Применяйте эквивалентные политики безопасности к обоим протоколам. Если вы блокируете порт 23 (telnet) на IPv4, блокируйте его на IPv6. Используйте stateful inspection для обоих.

2. Неправильные конфигурации DNS#

Публикация AAAA-записей без работающей IPv6-связности ломает доступ для IPv6-enabled клиентов. Happy Eyeballs помогает, но вызывает задержки и откат к IPv4.

Решение: Публикуйте AAAA-записи только после проверки, что IPv6-связность работает. Мониторьте паттерны как A, так и AAAA запросов. Настройте обратный DNS (PTR-записи) для IPv6-адресов.

3. Проблемы совместимости приложений#

Приложения, которые жёстко кодируют предположения об IPv4, отказывают с IPv6:

• Хранение IP-адресов в 32-битных целых числах
• Regex-паттерны, соответствующие только формату IPv4
• Отсутствие квадратных скобок для IPv6-адресов в URL: http://[2001:db8::1]:8080/
• Привязка к 0.0.0.0 вместо :: (IPv6 wildcard)

Решение: Тщательно тестируйте приложения с IPv6-only связностью. Используйте dual-stack тестовые среды. Проверяйте код на предположения об IPv4.

4. Слепые зоны мониторинга#

Сетевой мониторинг часто отслеживает IPv4-метрики, но игнорирует IPv6. Вы не заметите, если IPv6-связность деградирует или полностью отказывает.

Решение:

• Мониторьте IPv6- и IPv4-трафик отдельно
• Настройте специфичные для IPv6 проверки здоровья
• Отслеживайте распределение предпочтений протокола (какой процент трафика использует IPv6)
• Оповещайте о проблемах доступности IPv6

Используйте наш калькулятор подсетей IPv6 для планирования адресации и наш инструмент ping для проверки связности.

Начните просто#

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

Как только освоитесь, расширяйтесь на production-сервисы. Большинство современной инфраструктуры поддерживает IPv6 с минимальной конфигурацией. Техническая миграция прямолинейна — организационные изменения и тщательное тестирование занимают больше времени.

Туннелирование служит временным мостом, если вы не можете получить нативный IPv6 немедленно. Но давите на своего провайдера для нативной поддержки. Трансляция обрабатывает крайние случаи, но не должна быть вашей основной стратегией.

Внедрение IPv6 продолжает ускоряться. Начиная сейчас, даже постепенно, вы позиционируете свою сеть для будущего, пока ваши конкуренты спешат догонять позже.

Связанные статьи#

• Включение IPv6 — Практическое руководство по включению IPv6 на ваших устройствах и маршрутизаторах
• IPv6 в облаке — Научитесь развёртывать IPv6 на AWS, Azure и Google Cloud