28.02.2025

О переходе на IPv6

Зачем, собственно, переходить на новый протокол? Бурный рост сети интернет в 1990-е годы привёл к значительному расходованию доступных IP адресов. Стало очевидно, что тенденция увеличения количества устройств приведёт к тому, что адресное пространство IP просто исчерпается.

Подробнее о том, почему протокол так отличается от старой версии я уже писал ранее в заметке «Знакомство с IPv6 на практике». Если кратко, то расширение адресного пространства требует обновления программного обеспечения на всём парке устройств, а значит нет необходимости тянуть за собой все недостатки старого протокола, которые были выявлены за время его использования.

Новая версия протокола IP может предоставить всё тоже самое, что предоставляла старая версия IP. При этом у новой версии нет недостатка в количестве адресов и имеется значительный запас адресного пространства.

Так в чём же проблема? На самом деле если бы сейчас произошло чудо и всё сетевое оборудование вдруг лишилось IPv4 и обзавелось поддержкой IPv6, то пользователи вряд ли бы что-то заметили. Программного обеспечения жёстко завязанного на IPv4 не так много. Но, увы, чудес не бывает, поэтому некоторое время придётся жить в мире где есть две версии протокола.

Избавляемся от IPv4

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

Выключаем IPv4 и пробуем выйти в интернет. Конечно, не забываем о том, что DNS серверы нам тоже нужны доступные по IPv6. Благо, есть даже бесплатные у Google, Cloudflare и многих других. Что же у нас доступно по IPv6? Youtube, Яндекс, Facebook, Instagram, BBC и др. Вроде бы ничего не изменилось. Всё работает как и раньше.

Запускаем торрент клиент и идём на любимый трекер. Пробуем загрузить что-нибудь. И тут видим первую проблему. Большая часть раздач не грузятся. Некоторые раздачи идут, но медленно, некоторые работают без проблем. А виной всему то, что мы потеряли доступ к основной части пиров, которые работают только с IPv4 протоколом.

Мессенджеры тоже могут вести себя странно. Некоторые могут работать нормально, некоторые не работать. Опят таки дело тут в отсутствии поддержки IPv6 со стороны сервера. При этом даже если мессенджер работает, то аудио и видеозвонки могут не проходить. Как и с торрентами, проблема может быть в том, что соединение происходит по IPv4 адресу.

Как насчёт того, что может понадобиться в РФ? Зайдём на сайты: Госуслуги, Сбербанк, ВТБ, ВКонтакте, Ростелеком… Увы, но сайты недоступны. Это совсем не то, что нам надо. Можно ли эту проблему как-то решить? Можно.

NAT64 или получаем доступ к узлам с IPv4

Первое, что мы можем сделать - каким-то образом обеспечить связь с узлами, которые используют только IPv4 адреса. Что необходимо, чтобы отправить пакет узлу с IPv4 адресом? Нам тоже нужен IPv4 адрес. Поскольку от адресации IPv4 внутри сети мы избавились, то нам нужен будет какой-то промежуточный узел, который сможет взаимодействовать по IPv6 с нашей сеть и по IPv4 с нужным нам узлом. Ничего не напоминает? Да это же всем известный NAT, который используется в IPv4 повсеместно, в том числе на вашем домашнем маршрутизаторе. Но есть небольшая разница. Если в нашем случае нам нужно преобразовывать IPv6 в IPv4 и обратно, то ранее было преобразование IPv4 в другой IPv4 и обратно. Таким образом, чтобы не путать эти типы NAT, обозначим старый как NAT44, а наш новый тип NAT64, в соответствии с версиями IP на нашей и удалённой стороне.

Всё новое - это хорошо забытое старое. Теперь в нашей сети появился специальный шлюз, который выполняет преобразование из IPv6 в IPv4 - NAT64. Теперь любой узел нашей сети может отправить запрос на шлюз и через него получить ответ от узла IPv4. Например, пусть наш шлюз имеет адресацию 2001:db8::/64. В этом случае он может использовать адресацию 2001:db8::/96 для отображения всех адресов сети интернет. Если нам необходимо обратиться к узлу 1.1.1.1, то мы просто посылаем запрос не на 1.1.1.1, а на адрес 2001:db8::101:101. Чтобы было удобнее для людей, существует специальная запись для такого применения адресов: 2001:db8::1.1.1.1. В этом случае часть IPv6 адреса, которая содержит IPv4 адрес, записывается как есть.

Поскольку некоторое время NAT64 будет актуален, то для него был выделен специальный диапазон адресов: 64:ff9b::/96. Именно его рекомендуют использовать внутри вашей локальной сети для вашего шлюза NAT64. Таким образом адрес 1.1.1.1 превращается в 64:ff9b::1.1.1.1, что также можно записать также как 64:ff9b::101:101.

Отлично. Доступ к узлам IPv4 мы получили.

$ ping 64:ff9b::1.1.1.1
PING 64:ff9b::1.1.1.1 (64:ff9b::101:101) 56 data bytes
64 bytes from 64:ff9b::101:101: icmp_seq=1 ttl=59 time=48.4 ms
64 bytes from 64:ff9b::101:101: icmp_seq=2 ttl=59 time=53.8 ms

Но что-то тут всё равно не так. Там, где мы указываем IPv4 адреса, мы можем сменить 1.1.1.1 на 64:ff9b::1.1.1.1. Но IP адреса мы указываем редко. В большинстве случаев мы используем доменные имена при обращении к серверам интернета. Поэтому выполним следующий шаг и перейдём к настройке специального DNS сервера.

DNS64 или обманываем клиентов

Что происходит, когда какое-то приложение обращается по определённому доменному имени? Прежде чем обратиться к IP адресу сервера система должна этот адрес найти. Чтобы его найти, ваше устройство обращается к DNS серверу, который возвращает соответствующий доменному имени IP адрес. Рассмотрим типичный ответ на примере домена music.yandex.ru:

$ host music.yandex.ru
music.yandex.ru has address 213.180.204.186
music.yandex.ru has IPv6 address 2a02:6b8::186
music.yandex.ru mail is handled by 10 mx.yandex.net.

В данном ответе мы получили записи 3 разных типов:

A - содержащую IPv4 адрес: 213.180.204.186;
AAAA - содержащую IPv6 адрес: 2a02:6b8::186;
MX - адрес почтового сервера.

Что происходит, когда какое-то приложение пытается получить доступ к music.yandex.ru? Выбором протокола обычно занимается не само приложение, а операционная система. Если у вас на устройстве есть публичный IPv6 адрес, то получив подобный ответ, возможно, ОС попытается обратиться сначала к IPv6 адресу сервера, если это не удаётся, то произойдёт попытка связаться с сервером по IPv4 адресу. Есть и более сложные алгоритмы выбора протокола, например, описанный в RFC 8305 (Happy Eyeballs версии 2). Этот алгоритм позволяет обеспечить наиболее быстрый ответ сервиса в случае если возникли какие-то проблемы с работой IPv6, но при этом сервис по прежнему доступен по IPv4.

Приложениям совершенно не важно какой протокол будет использован на нижних уровнях. Что это значит для нас? То, что мы можем обмануть их и вместо соединения с IPv4 адресом заставить их соединиться с IPv6 на нашем шлюзе NAT64, который уже, далее, обеспечит соединение с нужным нам узлом по протоколу IPv4.

Для примера возьмём домен sberbank.ru.

$ host sberbank.ru
sberbank.ru has address 194.54.14.168
sberbank.ru mail is handled by 60 email12.sberbank.ru.
sberbank.ru mail is handled by 40 email11.sberbank.ru.

На нём также имеются почтовые MX записи, но нас они не интересуют. Мы видим одну запись типа A, которая указывает на адрес 194.54.14.168. Т.е. приложение запросив этот адрес будет пытаться связаться с указанным ему IPv4 адресу. Как мы можем перенаправить этот запрос на наш шлюз NAT64? Всё просто. Нужно создать поддельную запись типа AAAA, которая будет указывать на наш шлюз. Вносим необходимые правки в настройки нашего DNS сервера и теперь его ответ будет немного иной:

$ host sberbank.ru
sberbank.ru has address 194.54.14.168
sberbank.ru has IPv6 address 64:ff9b::c236:ea8
sberbank.ru mail is handled by 60 email12.sberbank.ru.
sberbank.ru mail is handled by 40 email11.sberbank.ru.

Как вы могли заметить, теперь ответ содержит AAAA запись, которая указывает на адрес 64:ff9b::c236:ea8 (64:ff9b::194.54.14.168). В таком случае наша операционная система обнаружив запись AAAA для запрашиваемого узла просто попытается с ним связаться по этом адресу, передавая данные на наш шлюз NAT64. Бинго! Проверим ещё раз как теперь работает наш интернет. Теперь такие сайты, как Госуслуги, Сбербанк, ВТБ, Ростелеком и многие другие заработали!

NAT64 в связке с DNS64 позволили нам получить доступ к большей части ресурсов интернета.

К сожалению, есть небольшой недостаток такого подхода. DNS64 ломает DNSSEC. Если вы пользуетесь этим механизмом, то можете заметить, что теперь у сайтов без IPv6, но имеющих DNSSEC теперь сломан. Увы, починить это никак нельзя. С другой стороны, использование DNSSEC в РФ само по себе проблематично. Например, оператор, который предоставляет государственные услуги - Ростелеком, имеет сломанный DNSSEC на своём домене rt.ru. Если вы используете DNSSEC, то вы можете продолжить его использовать только на вашем DNS сервере. Клиенты теперь не будут доверять доменам у которых есть только A записи и нет AAAA и включен DNSSEC.

Но, с другой стороны, синтез AAAA записей можно поручить резольверу непосредственно на устройстве. В этом случае мы будем иметь корректные подписи DNSSEC.

В некоторых операционных системах возможно выставить приоритеты использования IPv4 и IPv6 адресов. Например, в ОС Linux это делается с помощью настройки функции getAddrInfo в файле конфигурации /etc/gai.conf.

CLAT

Итак. Мы восстановили доступ к большей части ресурсов интернета. Но остаётся вопрос торрентов и некоторых других приложений, которые не используют доменные имена при своей работе и оперируют непосредственно IPv4 адресами, а значит будут обращаться непосредственно к этим адресам. Что делать в этом случае?

В нашей сети, которая работает только по протоколу IPv6 есть свой шлюз NAT64. Его можно назвать также PLAT (provider-side translator). Нам нужен IPv4 адрес, чтобы приложения могли отправлять пакеты IPv4, как они того желают. Сделаем свой транслятор адресов NAT46. Для этого создадим виртуальный интерфейс с IPv4 адресом и весь трафик, который будет направляться на него будем перенаправлять на наш NAT64. Такой транслятор называется CLAT (customer-side translator). Вместе CLAT и PLAT представляют собой архитектуру 464XLAT, которая позволяет передавать по сети IPv6 пакеты IPv4.

Плохая новость: CLAT необходимо устанавливать на каждое устройство, если ваша сеть работает только по протоколу IPv6. Хорошая новость: использование CLAT делает ваш доступ в интернет полноценным, а его реализация есть на большинстве мобильных ОС без дополнительной настройки. Вам будут доступны все сервисы сети без каких-либо ограничений. И ещё одна хорошая новость. Если NAT64 предоставляет ваш оператор, а его сеть построена исключительно на IPv6, то CLAT можно установить на ваш маршрутизатор и также как и раньше пользоваться NAT. Только не NAT44, как раньше, а NAT46. При этом провайдеры могут применять более эффективные методы трансляции на своей стороне и более эффективное разделение нагрузки на NAT между клиентами. Конечно, в этом случае необходимо согласовывать с провайдером какой маршрутизатор подходит и как его правильно настроить. Но вернёмся к CLAT непосредственно на конечных устройствах.

Android поддерживает CLAT начиная с версии 4.3, с 2013 года. Однако, в зависимости от поставщика, могут быть некоторые отличия. Например, мне не удалось использовать CLAT на старом телефоне с Android 5.0. MIUI на телефоне Poco X3 NFC не позволяет отключить IPv4 для сотовых сетей даже несмотря на выбор режима только IPv6. Наиболее свежие телефоны с Android, в том числе, умеют распознавать специальную опцию DHCPv4 и могут не получать IPv4 адреса и активировать CLAT (проверял на Poco C40).

В iOs от Apple имеется своя реализация CLAT начиная с версии 12.0, которая была выпущена в 2018 году. Кроме этого, Apple требует, чтобы все приложения, которые публикуются через их App Store работали в сетях IPv6.

MacOS также имеет встроенную поддержку CLAT начиная с версии Ventura (13).

Представитель Microsoft в начале 2024 года завил о том, что компания планирует расширить поддержку CLAT в том числе и на интерфейсы не сотовых сетей в Windows 11.

В различных дистрибутивов Linux можно найти пакеты clatd, которые позволяют использовать CLAT.

В целом, самая лучшая ситуация с мобильными устройствами. Они давно готовы к работе в сетях IPv6 без IPv4. А вот самый большой сегмент рынка стационарных устройств и ноутбуков на базе Windows до сих пор может работать полноценно только при использовании сотовых сетей.

Автоматизация

Всё конечно хорошо, что мы можем отключить IPv4, запустить CLAT, указав нужный нам диапазон или каким-то образом его обнаружить. Можно ли это как-то автоматизировать?

Обнаруживаем наличие NAT64 в сети

Одним из первых вариантов автоматизации описан в RFC 7050 «Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis». Суть этого метода заключается в том, что устройство производит запрос на специальный домен ipv4only.arpa.. В случае, если у вас активен DNS64, то вы получите ответ, который содержит AAAA записи, которые будут указывать на используемый NAT64 префикс:

[~]$ nslookup ipv4only.arpa.
Server:  127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: ipv4only.arpa
Address: 192.0.0.170
Name: ipv4only.arpa
Address: 192.0.0.171
Name: ipv4only.arpa
Address: 64:ff9b::c000:aa
Name: ipv4only.arpa
Address: 64:ff9b::c000:ab

Всё просто и изящно. НО! Адрес DNS сервера очень легко сменить прямо на устройстве. Например, это легко делается в Windows. В таком случае может возникнуть любой из двух случаев: ложное обнаружение отсутствие NAT64, так и ложное обнаружение NAT64. Кроме этого, если каким-то образом злоумышленник изменит ваш DNS сервер на свой или вы сами пропишите подконтрольный ему DNS, то весь ваш трафик IPv4 может быть перенаправлен на NAT64 злоумышленника, где можно как записывать весь трафик, так и просматривать данные, которые не достаточно надёжно защищены.

Мириться с этим было нельзя и в апреле 2020 года был выпущен RFC 8781 «Discovering PREF64 in Router Advertisements», который добавляет специальную опцию в анонсы маршрутизаторов. Да. Это тоже не самое безопасное место, где можно разместить информацию. Можно подключиться к вредоносной сети. Но в таком случае, вы, по крайней мере, можете понимать, что вы подключаетесь к среде, не вызывающую доверие и ваш трафик может быть перехвачен не зависимо от используемого протокола. Вы в любом случае вынуждены доверять RA, иначе вы не сможете подключиться к сети. Если ваша сеть защищена от фейковых RA и DHCP, то вы также получите гарантированно безопасный префикс NAT64.

Увы, но реализация этого протокола немного затянулась. В пакете odhcpd, который используется в OpenWrt поддержка этого RFC появилась только в версии 23.05. В пакете radvd поддержка появилась ещё позже, только в конце 2024 года с выходом версии 2.20.

Получил PREF64 операционная система может настроить свой локальный резольвер DNS на синтез AAAA записей, что сделает проблему нарушения DNSSEC не актуальной, ведь система может проверить A запись и, убедившись, в её легитимности, синтезировать AAAA. Но, в любом случае, остаётся возможность использовать DNS64, что не требует никаких вмешательств в операционную систему. Главное, чтобы вы могли доверять вашему DNS серверу, также как при использовании RFC 7050.

Отказываемся от получения IPv4 адреса, если он не нужен

С проблемой обнаружения NAT64 разобрались. Второй вопрос. Что делать со старыми клиентами, которые не могут работать без IPv4? Если вы выдаёте серые адреса, то особой проблемы нет. Но сли вы провайдер и выдаёте белые адреса? В этом случае все клиенты могут взять себе IPv4 адрес нужен он ему или нет. На этот случай также был реализован RFC 8925 «IPv6-Only Preferred Option for DHCPv4», который добавляет специальную опцию в DHCPv4. В случае если клиент умеет работать в сети IPv6-only, он при запросе DHCPv4 отправляет запрос на получение опции 108, которая в свою очередь, может быть отправлена DHCPv4 сервером и содержать количество секунд, на которое клиент должен отключить свой DHCPv4 клиент и больше не запрашивать IPv4 адрес. Если на клиенте при этм включен механизм CLAT, то он вообще не будет испытывать никаких затруднений, а пул IPv4 адресов сети не будет использован.

Итог

Какой же алгоритм использовать, чтобы быть клиентом IPv6-only в сети IPv6-mostly или в сети с двойным стеком?

Обнаруживаем наличие в сети NAT64 с помощью RFC 8781. Если в ответе маршрутизатора (RA) есть опция PREF64, то наша сеть имеет NAT64. Просто настраиваем локальный резольвер синтез AAAA записей и продолжаем:

Если настройками не задано получение IPv4 адреса, просто включаем CLAT.
Иначе пробуем получить IPv4 адрес от DHCPv4. В запросе указываем опцию 108 согласно RFC 8925. Если DHCPv4 отвечает опцией 108, но отключаем DHCPv4 на указанное количество секунд и включаем механизм CLAT.
Если DHCPv4 сервер не отвечает, то включаем механизм трансляции CLAT.

Опционально. Если префикс NAT64 был не указан, но при этом мы не получили IPv4 адрес от DHCP или просто не запрашивали, то используем RFC 7050 и запрашиваем ipv4only.arpa.. Если префикс NAT64 обнаружен, включаем CLAT. Резольвер настраивать не нужно, т.к. работает DNS64. Я бы сделал это опцией, которую нужно включать вручную.

Заключение

Протокол нового поколения IPv6 является полноценной заменой IPv4. Во время перехода от IPv4 к IPv6 для поддержания полноценного доступа ко всем ресурсам интернета необходимо использовать дополнительно оборудование и программное обеспечение. Однако в процессе перехода нагрузка на это оборудование будет постепенно снижаться, что выгодно отличает этот вариант от использования NAT44 на сетях провайдеров, где нагрузка на оборудование, выполняющее эти функции, только возрастает с каждым годом.

Обратите внимание, что заметки могут обновляться со временем. Это может быть как исправление найденных ошибок, так и доработка содержания с целью более полного раскрытия темы. Информация об изменениях доступна в репозитории на github. Там же вы можете оставить в Issue ваши замечания по данной заметке.

Если данная заметка оказалась вам полезной, можете поблагодарить автора финансово.