[Перевод] Развёртывание сетей доступа преимущественно на основе IPv6
Одним из методов перехода к IPv6 является сеть, где большая часть клиентов вообще не пользуются IPv4, и этот протокол предоставляется только для устаревших устройств. В настоящее время существует несколько RFC, которые описывают как правильно всё реализовать, чтобы ваша сеть работала подобным образом. Именно подобную сеть я и решил организовать на основе своего маршрутизатора на базе OpenWRT. Что должна уметь моя сеть?
полноценно предоставлять всем клиентам IPv6 с использованием SLAAC и DHCPv6;
делегировать префиксы IPv6 другим маршрутизаторам (DHCP-PD);
выдавать IPv4 адреса клиентам, которые его запросят, при этом клиенты должны иметь возможность отказаться от получения IPv4;
все клиенты должны иметь полноценный доступ в интернет.
Вся необходимая теория отлично описана в статье Ondřej Caletka от 21 ноября 2022 года. Следующие главы моей заметки представляют из себя перевод этой статьи. В тексте активно используется термин «IPv6-mostly», что можно перевести как сеть, которая преимущественно работает на протоколе IPv6. Для лаконичности я не стал переводить это обозначение и в тексте буду указывать «IPv6-mostly», когда речь идёт о таких сетях.
Развертывание сетей доступа преимущественно на основе IPv6
Двойной стек — наиболее распространенный способ развертывания IPv6 в сетях доступа. Недавний стандарт определяет сети доступа преимущественно на основе IPv6 («IPv6-mostly»), обеспечивая подключение IPv4 только для устаревших устройств, в то время как современные устройства могут работать только с IPv6. Он уже хорошо поддерживается и позволяет операторам связи постепенно отказываться от IPv4 в сетях доступа.
Многие операторы связи пытались перевести большую часть своих сетей только на IPv6, чтобы решить проблему нехватки адресации IPv4. Для сетей абонентов это создаёт проблемы, поскольку всё ещё существует множество устаревших устройств, приложений и/или служб, которые не могут работать должным образом в среде с только IPv6. Сети с двойным стеком, возможно, являются наилучшим решением для абонентов, но при этом никак не решается проблема нехватки IPv4.
Мобильные телефоны готовы, настольные компьютеры — нет
Уровень поддержки сетей IPv6-mostly заметно отличается для разных типов устройств, или, точнее, зависит от их операционных систем. В целом, не должно быть никаких проблем с предоставлением сетей IPv6-mostly (с NAT64 и DNS64 для организация доступа к узлам с устаревшими IP) для мобильных операционных систем iOS и Android. В случае iOS, Apple заставляет всех разработчиков приложений публиковать приложения, которые поддерживают работу в сетях IPv6-mostly. Для веб-сайтов, работающих только через IPv4 или сломанным двойным стеком, где IPv6 фактически не работает, есть поддержка Happy Eyeballs версии 2 (RFC 8305), которая обеспечивает стабильное и быстрое подключение не зависимо от состояния сети. Наконец, при подключению к компьютеру также существует механизм трансляции на стороне пользователя (Customer-Side Translator — CLAT), так что подключенное устройство получает сеть с двойным стеком, несмотря на то, что мобильная сеть может работать только с IPv6.
В случае Android, движок CLAT является важной функцией, смягчающей проблемы с сетями доступа на основе только IPv6. Он позволяет немодифицированным устаревшим приложениям работать без серьёзных проблем, поскольку с точки зрения приложения, устройство по-прежнему подключено к сети с двойным стеком. Устройства iOS и Android работают в мобильных сетях только IPv6 по всему миру, поэтому можно с уверенностью ожидать, что серьёзных проблем возникнуть не должно.
Что касается настольных операционных систем, ситуация менее удовлетворительная. Пользователи Windows, Linux и macOS по-прежнему могут свободно устанавливать приложения из различных источников, включая устаревшие приложения, использующие устаревшие API-интерфейсы, которые работают только с IPv4. Такие приложения не будут работать, если устройству не будет предоставлен IPv4. В то же время, движка CLAT, который бы решал эти проблемы, практически не существует. Для Linux есть скрипт clatd, но он не является стандартной частью какого-либо распространенного дистрибутива (однако обсуждение внедрения такого функционала в NetworkManager и systemd активно ведётся в настоящее время, в начале 2025 года — прим. пер.). В Windows есть движок CLAT, но он активируется только при прямом подключении модема WWAN к машине. Таким образом, ноутбук с Windows может подключаться к мобильным сетям, работающим только на базе IPv6, и по-прежнему поддерживать приложения, работающие только с IPv4.
Из-за этого ограничения настольных операционных систем развертывание сетей доступа только на основе IPv6 может вызвать проблемы для определенного числа пользователей. Поэтому сетевые операторы вынуждены запускать сети с двойным стеком, несмотря на то, что значительное число устройств больше не требуют IPv4.
Отключите IPv4 с помощью параметра DHCP
Чтобы такое стало возможно, сравнительно недавно был принят RFC 8925, который добавляет новую опция DHCP под номером 108, называемую «предпочтение только IPv6» («IPv6-only Preferred»). Она позволяет указать устройству о возможности нормально работать в сети IPv6-mostly. Это делается путем указании этой опции при запросах DHCP. Если сервер DHCP знает, что конкретная сеть поддерживает работу только с IPv6, он включит такую опцию в ответ, что заставит клиента остановить получение адреса IPv4 через DHCP. Поэтому, несмотря на то, что сеть поддерживает двойной стек, адресация IPv4 предоставляется только устаревшим клиентам, не запрашивающим опцию «IPv6-only Preferred» DHCP. Это может помочь сократить размер пула адресов IPv4.
Мне было любопытно узнать, используется ли эта новая опция DHCP на современных устройствах. Для этого я решил измерить количество устройств, запрашивающих эту опцию в сети RIPE Meeting во время RIPE 84 в Берлине в мае 2022 года. В течение недели я собирал сообщения DHCP в файл PCAP. Затем я создал простой анализатор с помощью Scapy, который подсчитывает, сколько уникальных MAC-адресов запросили опцию DHCP о предпочтении только IPv6. Вот результаты:
Unique MACs: 1441
Option 108 enabled: 951 65%
Если предположить, что количество уникальных MAC-адресов соответствует количеству подключенных устройств, это означает, что почти две трети устройств поддерживают работу в сетях только с IPv6. Учитывая тот факт, что RFC 8925 появился совсем недавно, это очень хороший результат (тестирование проводилось спустя менее 2 лет после принятия этого RFC — прим. пер.). Оказалось, что параметр DHCP запрашивается не только всеми последними устройствами Android и iOS, но и последними устройствами с macOS (12.0.1 и новее). Ни одна из этих платформ не имеет настроек, которые позволили бы пользователям изменять это поведение по умолчанию. Это было бы не очень хорошо, особенно в случае с macOS, где устаревшие приложения, работающие только с IPv4 всё ещё могут быть запущены.
В macOS есть CLAT
Оказалось, что инженеры Apple учли эту проблему и фактически включили CLAT в последние версии macOS. Он активируется только при выполнении следующих условий:
DHCP-сервер отвечает опцией «IPv6-only Preferred»;
в объявлении маршрутизатора (RA) имеется опция PREF64 (RFC 8781), содержащая префикс NAT64.
Второе требование довольно интересно, так как все предыдущие решения проблем с сетями только IPv6 на macOS использовали обнаружение префикса NAT64 с помощью DNS64 (RFC 7050). Но поскольку этот тип обнаружения использует неаутентифицированный DNS, есть некоторые проблемы с безопасностью. Параметр PREF64 в свою очередь, несмотря на то, что он также неаутентифицирован, но он передаётся совместно с другими параметрами конфигурации сети, и, таким образом, может быть немного более доверенным. Если оба требования выполнены, активируется CLAT, что видно в выводе команды ifconfig. Его функцию можно проверить, попытавшись выполнить ping адреса IPv4.
Новая опция DHCP проста, новая опция RA — сложнее
Итак, чтобы создать правильную сеть доступа IPv6-mostly, нам нужно поддерживать как новую опцию DHCP — сообщающую совместимым клиентам не использовать IPv4 — так и новую опцию RA — несущую префикс NAT64. Первая довольно легко реализуема на большинстве DHCP-серверов, поскольку RFC 8925 не требует какой-либо специальной обработки на стороне сервера. Таким образом, любой DHCP-сервер, поддерживающий пользовательские опции DHCP, можно настроить на предоставление опции 108 тем клиентам, которые её запрашивают, содержащей только 32-битное значение таймера того, как долго стек IPv4 должен оставаться деактивированным.
Что касается опции PREF64 для RA, каждый маршрутизатор должен быть обновлен для поддержки этой новой опции. К счастью, поддержка медленно появляется в программных маршрутизаторах:
есть реализация прототипа на Python;
есть запрос на включение изменений для FRR;
добавлена поддержка в radvd 2.20;
добавлена поддержка в odhcpd, используемого в OpenWRT.
DNS64 по-прежнему необходим для Safari и iOS
Поскольку опция PREF64 RA активирует движок CLAT, возникает соблазн попробовать запустить сеть без DNS64, ведь в этом случае весь трафик IPv4 будет принудительно проходить через движок CLAT. Это работает без проблем на Android, а также с большинством приложений на macOS, за одним большим исключением — Safari. Каким-то образом Safari отказывается использовать движок CLAT, и без DNS64 он просто не будет загружать никакие ресурсы, поддерживающие только IPv4, ни по доменным именам, ни при явном указании IPv4. Та же ситуация справедлива для iOS. С одним только PREF64 и без DNS64 большинство приложений не могут получить доступ к Интернету IPv4.
Это означает, что сеть IPv6-mostly должна использовать DNS64 в дополнение к NAT64, опции PREF64 RA и опции «IPv6-only Preferred» DHCP. Это окажет некоторое влияние на устаревшие устройства, использующие сеть с предпочтением только IPv6 в режиме сети с двойным стеком. Поскольку IPv6, как правило, предпочтительнее IPv4, все приложения с поддержкой IPv6 будут предпочитать использовать NAT64 вместо собственного IPv4. Собственный IPv4 будет использоваться только в особых случаях, таких как устаревшие приложения работающие только с IPv4 или использующие адреса IPv4 напрямую. Измеряя объем собственного трафика IPv4 в сети, можно определить, происходят ли такие случаи или нет, и, возможно, в какой-то момент времени принять решение полностью отказаться от IPv4.
Сеть с предпочтением только IPv6 выглядит многообещающе
Из моих тестов следует, что сеть с предпочтением только IPv6, выполняет свою задачу по предоставлению полноценной сети пользователям при использовании наименьшего количества ресурсов IPv4. С другой стороны, есть некоторая дополнительная сложность настройки по сравнению с традиционными сетями с двойным стеком и нет прямой экономии на ресурсах IPv4, поскольку IPv4 всё ещё должен быть развернут везде для поддержки устаревших устройств. Однако в ближайшие годы ожидается, что объём непосредственно трафика IPv4 в таких сетях снизится до уровня, когда будет разумно вообще не развертывать IPv4. В традиционных сетях с двумя стеками дефицитные адреса IPv4 назначаться большинству устройств, даже тем, которые в них не нуждаются, поэтому вероятно, необходимые пулы DHCP будут продолжать расти и дальше.
Настраиваем IPv6-mostly сеть
На этом перевод статьи закончен. Рассмотрим как же можно практически реализовать подобную сеть. Я использовал для тестирования недавно вышедшую OpenWRT 24.10.0, но всё это должно работать и в 23.05.
Для построения сети нам необходимы следующие службы:
NAT64;
служба, отвечающая за запросы маршрутизаторов RA (Router Advertisement);
DHCPv6;
DHCPv4;
DNS64.
Вопросов настройки NAT64 я сейчас не буду касаться, ведь ранее уже рассматривал в своей статье настройки Jool и Tayga для реализации этого функционала. Там же приводятся примеры настройки DNS64. Кроме этого, NAT64 и DNS64 могут предоставлять и сами операторы связи, тогда настраивать его у себя вообще нет никакой необходимости.
В теории, кроме NAT64 и DNS64, со всеми остальными задачами справляется демон Dnsmasq из состава OpenWRT. Однако в официальных сборках у него отключена часть функционала, которая касается IPv6. Для RA и DHCPv6 в составе OpenWRT есть собственный компонент odhcpd, который также урезан по функционалу, чтобы не конфликтовал с Dnsmasq. Самым первым соблазном было использовать комбайн Dnsmasq, который вроде как должен уметь обслуживать все виды запросов. Я попробовал заменить урезанную версию пакета dnsmasq на dnsmasq-full, которая работает также как DHCPv6 сервер и демон RA. При этом я полностью отключил odhcpd.
В ходе тестирования были выявлены следующие недостатки:
DHCPv6 сервер не умеет в DHCP-PD, т.е. полученный от провайдера префикс вы не сможете раздавать другим маршрутизаторам в своей сети;
вылез какой-то странный баг, что при смене PD от провайдера демон помнил все предыдущие префиксы и передавал их в RA, что могло вызвать неработоспособность IPv6 сети на клиентах;
DNS резольвер ничего не знает о DNS64, поэтому при своей работе должен полагаться на вышестоящий DNS сервер или дополнительный сервис на маршрутизаторе, который будет предоставлять необходимы функционал;
аналогично п. 3, Dnsmasq не умеет работать с DNS используя технологии DNSoverTLS и DNSoverHTTP, а для включения одновременно DoT/DoH и DNS64 приходится выстраивать матрёшку из сервисов, которые друг другу пересылают DNS запросы, или использовать полноценный DNS сервер.
Из плюсов Dnsmasq можно выделить довольно вменяемый и удобный веб-интерфейс в luci, а также то, что его функционал покрывает базовые потребности обычных пользователей интернета. Плохая работа с IPv6 и вовсе скрыта от пользователя путём замены этой части на функционал отдельного пакета odhcpd-ipv6only.
Решаем проблему с DNS64 и DoH/DoT
Как я уже говорил ранее, что непосредственно Dnsmasq не умеет работать ни как DNS64, ни использовать DoH/DoT. Существуют такие пакеты как totd, https-dns-proxy и др., которые запускаются как отдельные сервисы и реализуют необходимый функционал. Ими вполне можно пользоваться, но мне больше нравится вариант с полноценным DNS сервером. На выбор в OpenWRT можно установить как минимум:
bind — одна из старейших реализаций;
unbound — более современная и легковесная реализация, которая в некоторых системах вытеснила собой bind;
knot — ещё одна реализация.
Все указанные выше сервисы являются OpenSource решениями. Рассматривать bind я не стал, хотя ранее с ним встречался и использовал в локальной сети. Для маршрутизатора лучше выбрать более легковесные реализации.
Для unbound, кроме самого сервера, также имеются пакеты с реализацией графического интерфейса для его настройки через luci. Конечно, он заметно уступает интерфейсу dnsmasq и, для не сведущих пользователей, может показаться запутанным. Однако он вполне позволят выполнить все необходимые настройки.
Что касается knot, то я не нашёл для него веб-интерфейса, а значит его настройкой придётся заниматься через консоль.
Исходя из вышеизложенного, я решил, что оптимальным вариантом будет установка unbound. При установке пакета luci-app-unbound добавляется новый пункт основного меню «Службы → Рекурсивный DNS». Фактически вся его настройка сводится к включению DNS64 с указанием префикса DNS64, что можно сделать на вкладке «Unbound → Дополнительно». Кроме этого, в разделе «Зоны» можно выбрать уже существующие конфигурации для пересылки запросов к Cloudflare или Google DNS с использованием DNSoverTLS. Есть возможность добавить и свою конфигурацию или изменить уже существующие.
ВНИМАНИЕ!!! В процессе замены DNS сервера может возникнуть ситуация, когда ваш маршрутизатор потеряет DNS. В таком случае перестаёт работать opkg и пропадёт возможность скачивать список пакетов и сами пакеты. Будьте к этому готовы и заранее скачайте всё необходимое или обеспечьте себя резервным каналом доступа в интернет. Лично я выбрал для себя вариант со сборкой прошивки с необходимым набором программ через Firmware Selector. В любом случае, поищите заранее как правильно заменить DNS сервер, благо, в интернете есть готовые инструкции.
Добавляем PREF64 в RA
С этим нет никаких проблем. Даже в официальных сборках OpenWRT установлен пакет odhcpd-ipv6only, который прекрасно справляется с этой задачей, не говоря уже о полнофункциональном odhcpd.
Настроить PREF64 в RA можно с помощью luci. Для этого необходимо перейти в «Сеть → Интерфейсы», где выбрать соответствующий интерфейс «lan» или иной (если вы значительно изменили настройки по умолчанию). Необходимая нам настройка префикса NAT64 находится в разделе «DHCP-сервер → Настройки IPv6 RA».
В процессе проверки RA я столкнулся с тем, что префикс NAT64 якобы не транслируется. Вся проблема заключалась в том, что в установленной у меня ОС Fedora был установлен пакет radvdump 2.19, который я и применял для тестирования. Как оказалось, поддержка PREF64 появилась только в версии 2.20, которая вышла в конце 2024 года. На момент написания статьи версия 2.20 проходит тестирование, а также мейнтейнеры пакета хотят отвязать его от использования libbsd с помощью патча, который нужно протестировать, поэтому просят немного подождать, либо принять участие в тестировании. К счастью у меня была возможность загрузить Archlinux, который уже сейчас использует radvdump 2.20.
Альтернативным вариантом проверки является просмотр дампов IP пакетов с помощью, например, tcpdump или Wireshark. В таком случае вы увидите реальное содержимое пакета и можете убедиться в присутствии PREF64 в анонсе маршрутизатора.
Добавляем опцию 108 в DHCPv4
Вот тут я не нашёл решения, которое меня полностью устраивает. На текущий момент odhcpd не поддерживает опцию 108 или я не нашёл, как её указать. Из вариантов решения: оставить dnsmasq, который будет работать только как DHCPv4 сервер, либо использовать другие DHCPv4 серверы, например, kea. Особой необходимости отключать IPv4 для своих устройств в сети я не видел. К тому же это можно сделать вручную, например, на Linux. Поэтому я не стал особо тестировать эту опцию. Скажу только одно. Если у вас относительно современный телефон не старше 2020 года, то скорее всего он воспользуется опцией 108 и не будет получать IPv4 адрес и будет использовать CLAT.
Если вы будете тестировать ваш DHCPv4 сервер, то обратите внимание на то, что DHCPv4 сервер может не отдавать опцию 108 клиентам, которые её не запрашивают! Например, при просмотре дампов IP пакетов в момент запроса IPv4 адреса от NetworkManager из Fedora никакой опции 108 DHCPv4 сервер не выдаёт, даже если в качестве сервера используется Dnsmasq. Опцию можно добавить через luci в настройках «lan» в разделе «DHCP-сервер → Расширенные настройки». Достаточно добавить в «DHCP настройки» значение, например,»108,0:0:7:8», которая укажет устройству количество секунд, на которые следует отключить DHCPv4 клиента. В данном варианте указано 30 минут или 1800 секунд, что можно записать как 0×708 в шестнадцатеричной системе счисления.
Увы, но если вы заменяете dnsmasq на odhcpd, то эта опция перестаёт работать. В результате все клиенты начинают получать IPv4 адрес не зависимо от того, что они имеют возможность его не использовать. Надеюсь это будет исправлено в будущих версиях odhcpd.
После тестирования, я отказался от опции 108, т.к. не хотел тянуть dnsmasq только из-за DHCPv4. Кроме того, в моей сети используются серые IPv4 и недостатка в них нет, поэтому построение такой сети не имело какого-то значимого практического смысла. Меня вполне устраивает сеть, где я могу вручную отключить IPv4 и всё будет работать.
Заключение
В целом у меня получилось настроить сеть c предпочтением только IPv6, но с возможностью выдачи IPv4 для устаревших клиентов. Мобильные устройства на базе Android и iOs прекрасно работают в таких сетях и не используют адреса из пула IPv4. ОС Linux также вполне может работать в такой сети без IPv4, но потребуется ручная настройка и установка дополнительных пакетов. Только Windows не может полноценно работать с интернетом без IPv4. Но даже в ней основная часть ресурсов остаётся доступной только за счёт использования DNS64 в паре с NAT64. Не работают только приложения, которые жёстко завязаны на IPv4.
