LINUX.ORG.RU

В основную ветку разработки NetworkManager добавлена реализация CLAT

 464xlat, clat, ,


0

2

В основную ветку разработки NetworkManager добавлена реализация CLAT – компонента технологии 464XLAT (RFC 6877), обеспечивающий работу приложений, понимающих только IPv4, в сетях, работающих исключительно на IPv6.

Сам по себе CLAT не может работать самостоятельно. Для него необходим шлюз NAT64 (может быть как на стороне провайдера, так и в интернете или даже у вас на маршрутизаторе домашнем). В целом, для большинства приложений на современных ОС достаточно использовать DNS64 совместно с NAT64. Однако часть приложений отказывается работать, если на устройстве нет работающего IPv4-адреса. Это возникает или из-за использования устаревших методов работы с сетью, либо из-за использования литералов IPv4 (указание IPv4 напрямую, например, при поиске пиров по IPv4 адресу). Именно эту проблему и решает CLAT. На устройстве создаётся виртуальный IPv4 интерфейс, весь трафик с которого преобразуется и отправляется на шлюз NAT64.

Благодаря использованию CLAT на устройстве, оно может работать в сети, где используется только протокол IPv6 без каких либо ограничений доступа к ресурсам IPv4. Аналогичный механизм уже давно есть во всех современных мобильных ОС, например, в Android начиная с версии 4.3 (2013 г), а в iOs это произошло в 12 (2018 г.). В настоящее время отстающими были настольные ОС. Полноценная поддержка только есть в MacOS начиная с Ventura (13), которая вышла в 2022 году. В Linux для включения подобного функционала было необходимо устанавливать дополнительные пакеты (например, clatd). Поддержка CLAT в Windows также имелась только для WWAN соединений, однако в декабре 2025 года Microsoft также начала проводить тестирование собственной реализации CLAT для всех типов соединений у пользователей Windows 11.

Чтобы использовать CLAT в NetworkManager уже сегодня потребуется установить тестовую версию 1.57. Например, пользователи дистрибутива Fedora могут установить пакет NetworkManager из COPR с ежедневными сборками основной ветки main проекта. Сейчас автоматическая активация clat выключена и необходимо её включать вручную с помощью опции ipv4.clat=yes (позже, после проведения тестирования, планируется включать CLAT по умолчанию автоматически).

Данный функционал планируется добавить в версии NetworkManager 1.58. Актуальной версией сейчас является 1.54. Если судить по циклу выпуска релизов, версия 1.56 ожидается в ближайшие месяцы, а 1.58 должна будет выйти ближе к концу 2026 года.

>>> gitlab.freedesktop.org

★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от Behem0th

Почему обработка данных ускорится и нагрузка уменьшится если количество маршрутизируемых адресов возрастет, а так же увеличится размер адреса?

Почему уменьшатся сетевые задержки? Из-за чего?

Адреса источников назначения и получателя увеличились в 4 раза, при этом размер пакета увеличился всего в 2 раза. Большинству маршрутизаторов в интернете не нужны все 128 бит адреса, им достаточно половины, а то и меньше, чтобы принять решение о маршрутизации. Размер заголовка пакета в IPv6 теперь фиксированный, что упрощает его обработку, т.к. логика обработки пакетов становится проще. В заголовке пакета больше нет контрольной суммы, которую нужно пересчитывать в IPv4 на каждом узле. С TTL там что-то изменили тоже для упрощения обработки. Плюс оптимизации за счёт политик выделения IPv6 префиксов. Адреса выдаются с запасом и не нужно одному провайдеру выделять кучу разных префиксов, как сейчас в IPv4. За счёт этого даже не смотря на большее число адресов, таблицы маршрутизации у IPv6 более компактные, что тоже даёт некоторый выигрыш.

Стабильность и масштабируемость чего? Что станет более стабильный и масштабируемым и почему?

Стабильность и масштабируемость, возможно в плане того, что нужно меньше всяких костылей типа statefull NAT. Это отдельный процесс довольно ресурсоёмкий. Он режет одну сеть на кучу мелких создавая различные проблемы, которые потом решаются разными костылями.

Feonis ★★★
() автор топика
Ответ на: комментарий от firkax

Неужели больше 16 миллионов?

А там и не надо 16 миллионов. IPv4 ведь шинкуются сетями размерами кратными 2^x. Тоже кстати отдельный кайф для каждой сети помнить ещё и какая там должна быть маска сети. Полностью подсети тоже могут не быть заполнены. C IPv6 проще, потому что там сетей всем достаточно и каждая сеть размера /64.

Feonis ★★★
() автор топика
Ответ на: комментарий от Feonis

А там и не надо 16 миллионов. IPv4 ведь шинкуются сетями размерами кратными 2^x

Весьма условное заявление. Да и вообще в целом непонятно какую проблему решаем. Ну да ладно, их дело.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Что-то какая-то чушь. Впрочем, как и большинство идей ip6-адептов. Вместо того чтобы просто послать своему гейту ip4-пакет со своего серого ip4-адреса, мы будем слать его с некоего «виртуального» ip4-адреса и инкапсулировать в ip6-туннель (или не туннель а просто маппинг 4 на 6? не суть) до гейта чтобы на том же самом гейте всё так же натить его внешним ip4-адресом.

Это нужно только софту, который работает с IPv4 адресами напрямую. У меня это торрент-клиент (точнее пиры IPv4) и Steam. Остальной весь софт легко обманывается с помощью DNS64 и вместо IPv4 обращаются к IPv6 узлам. И эта штука нужна только на время перехода, пока IPv4 достаточно популярен. Если просто от него отказаться, то будет недоступна большая часть интернета. С помощью NAT64 мы решаем эту проблему.

на том же самом гейте всё так же натить его внешним ip4-адресом

Смотрите какая штука получается. Сейчас ты посылаешь пакет с «серого» IPv4 адреса, который по твоей локалке достигает твоего шлюза с «белым» IPv4. На этом узле производится операция NAT44. Ответный пакет идёт обратным путём. Когда у тебя NAT64, то схема аналогичная, только твоя локальная сеть построена не на серых IPv4. а на IPv6. Вот и вся разница!

А теперь профит. Когда у тебя схема с IPv4, то весь твой трафик идёт на NAT44. В схеме с IPv6 на NAT64 идёт только трафик IPv4. Если какой-нибудь крупный сервис, вроде Ютуб включает IPv6 на своих серверах, то весь его трафик уже идёт напрямую, минуя твой сервис NAT64.

И ещё не факт, что вам провайдер даст «белый» IPv4. И он весь трафик своих клиентов прогоняет через CGNAT. А это прямо очень плохо сказывается на качестве интернета. И нагрузка на CGNAT всегда высокая, потому что они вынуждены прогонять там ВЕСЬ трафик, т.к. всё идёт по IPv4. А если бы они использовали NAT64, то часть сервисов ушло бы на IPv6, где не нужны никакие NAT, а NAT64 нужно обрабатывать только трафик сервисов IPv4. И чем больше сервисов будет уходить на IPv6, тем меньше нагрузка на NAT64.

Feonis ★★★
() автор топика
Ответ на: комментарий от Somebody

Но это были вовсе не «проблемы IPv4»…

Верно. Это проблема софта на железках. Так же как есть какие-то проблемы при настройке IPv6. Чем больше его будут использовать, тем больше проблем софтовых будет решено. А IPv6 активно используется в Китае и Индии. В Европе тоже много где есть. Так что софт потихоньку пилится… но не у нас.

Feonis ★★★
() автор топика
Ответ на: комментарий от Feonis

А теперь профит. Когда у тебя схема с IPv4, то весь твой трафик идёт на NAT44. В схеме с IPv6 на NAT64 идёт только трафик IPv4

Вот в этом месте ошибка. Указанные отличия касаются только ip4-трафика (будем ли мы в середине его зачем-то конвертировать в ip6 а потом назад или не будет), а ip6-трафик в обоих случаях идёт как и шёл, без участия ip4.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Весьма условное заявление. Да и вообще в целом непонятно какую проблему решаем. Ну да ладно, их дело.

Есть такая величина в сетях с иерархическим распределением адресов - коэффициент плотности узлов. По опыту телефонных сетей и старых вычислительных сетей определили, что когда он становится выше 0,87, то рост сети становится практически невозможным. Для сети 10.0.0.0/8 критическим является значение примерно 1,8 миллионов узлов. Когда ты приближаешься к нему, то начинаешь дробить свои сети, делать между разными сетями разный NAT, чтобы обеспечить связность между сервисами. Вот в Яндексе помозговали и решили, что чем все эти костыли поддерживать, проще взять IPv6, где проблем с адресами нет. Переход на IPv6 позволил сделать им сеть более простой и обеспечил перспективу роста.

Feonis ★★★
() автор топика
Последнее исправление: Feonis (всего исправлений: 2)
Ответ на: комментарий от firkax

Вот в этом месте ошибка. Указанные отличия касаются только ip4-трафика (будем ли мы в середине его зачем-то конвертировать в ip6 а потом назад или не будет), а ip6-трафик в обоих случаях идёт как и шёл, без участия ip4.

Нет никакой ошибки. Я не рассматривал случай дуалстека, а сравнивал сети только IPv4 и только IPv6. В первом случае весь трафик исключительно IPv4, Во втором случае трафик весь IPv6, но часть сервисов направлется на шлюз.

Да, есть ещё схема с дуалстеком. В небольших сетях так можно сделать, тогда нагрузка на NAT44 тоже будет падать также, как и на NAT64. Но если у тебя сеть большая, то тебе придётся заниматься вопросами настройки и безопасности не одной, а двух независимых сетей. Сабж как раз и предназначен для того, чтобы можно было полностью избавиться от IPv4 в твоей сети и не иметь никаких проблем уже сейчас, а не в светлом будущем победившего IPv6.

Feonis ★★★
() автор топика
Ответ на: комментарий от Feonis

Верно. Это проблема софта на железках

Нет. Это пресловутый «человекческий фактор»: проблема в головах пользователей этих «железок», не проверявших «настройки по умолчанию».

Somebody ★★★★
()
Ответ на: комментарий от Somebody

Нет. Это пресловутый «человекческий фактор»

Где-то человеческий фактор и неоптимальные настройки по умолчанию, а где-то недоработки софта.

Feonis ★★★
() автор топика
Ответ на: комментарий от Feonis

а где-то недоработки софта

Ага, «прошивка» в головах пользователей неправильная... :))

P.S. «Локус контроля», привет!.. ;)) :)))

Somebody ★★★★
()
Ответ на: комментарий от firkax

Нет, ты как обычно обобщаешь свой ограниченный личный опыт на весь шарик. Так вот «у меня такая же нога и не болит» это не аргумент

cobold ★★★★★
()
Ответ на: комментарий от firkax

Думаю что эта самая потребность - скорее всего просто графоманское недержание у авторов networkmanager-а.

И такое же недержание у разработчиков Android, которое случилось аж в 2013 году. У Apple тоже. Да и вообще Linux-юзеры так любят скрипты писать, что сделали скрипт, делающий тоже самое, аж в 2014 году. И даже у Microsoft недержание, потому что для WWAN у них тоже своя реализация была…

Feonis ★★★
() автор топика
Ответ на: комментарий от apt_install_lrzsz

В прошлом считалось, что и 32-битного счётчика времени хватит всем, и что после 1999 года жизни не будет.

Когда ты молод и работаешь в молодой отрасли (а на момент написания Unix программированию было чуть за 20 и Unix писали те, кому чуть за 20), то думать о том, что твое решение будет актуально следующие 60+ лет - верх самоуверенности.

BydymTydym ★★
()
Ответ на: комментарий от BydymTydym

Сколько же это узлов должно быть, чтоб не хватало сети 10.0.0.0/8?

Ну вот есть такие организации. Яндексу проще было перейти на IPv6, а вот Билайн просто присвоил себе для внутренней адресации диапазоны 11.0.0.0/8 и 12.0.0.0/8, выдавая их своим клиентам.

Feonis ★★★
() автор топика
Ответ на: комментарий от apt_install_lrzsz

Учитывая, как в итоге всё повернулось, какие из этого можно сделать выводы?

Можно делать вывод о том, что иногда результаты превосходят самые смелые ожидания.

BydymTydym ★★
()
Ответ на: комментарий от apt_install_lrzsz

В прошлом считалось, что и 32-битного счётчика времени хватит всем, и что после 1999 года жизни не будет. Ну и к чему это в итоге привело?

Просто были ограничения на железо. Сделали как сделали. Да и запас был неплохой, до 2038 года. Мы до сих пор ещё этот рубеж не пересекли. И, кстати, есть время, чтобы всё исправить.

(режим иронии) И зачем увеличивают таймштапм до 64 бит. Добавили бы просто дополнительный бит и спокойно всё под это переделали.

Feonis ★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.