В ядро Linux могут внести изменения, которые навсегда уберут возможность собирать поддержку IPv6 в виде загружаемого модуля. Вместо этого стек IPv6 предлагается либо жёстко встраивать в ядро, либо полностью отключать на этапе конфигурации. Инициатором выступил разработчик SUSE Фернандо Фернандес Мансера, подготовивший серию патчей для ветки linux‑next, на базе которой формируется функциональность будущего релиза Linux 7.1.
Суть предложения сводится к тому, чтобы убрать вариант конфигурации `CONFIG_IPV6=m` и оставить только два состояния: `CONFIG_IPV6=y` (IPv6 встроен в ядро) и `CONFIG_IPV6=n` (поддержка IPv6 полностью отсутствует). Таким образом, стек IPv6 больше нельзя будет собрать как модуль, который загружается и выгружается динамически.
Разработчик объясняет своё решение желанием упростить сопровождение сетового стека и сократить количество специфического кода, который нужен исключительно для того, чтобы корректно обрабатывать ситуации с выгрузкой модуля IPv6. По его словам, нынешняя возможность собирать IPv6 модулем - в основном дань историческим причинам, а не отражение реальных потребностей современных систем.
На практике большинство актуальных дистрибутивов уже давно не используют модульный IPv6. В типичных конфигурациях ядра поддержка IPv6 либо жёстко встроена (по умолчанию включена во всех основных сборках), либо полностью деактивирована в специализированных образах, где он не нужен - например, в сильно урезанных системах, встраиваемых решениях или в некоторых высокоспециализированных серверах.
Основная техническая проблема текущего подхода в том, что при наличии опции `CONFIG_IPV6=m` множество подсистем ядра вынуждены держать в своём коде дополнительные обработчики на случай выгрузки модуля IPv6. Речь идёт не только о сетевом стеке, но и о таких компонентах, как BPF, подсистема фильтрации трафика Netfilter и целый ряд сетевых драйверов. Все они должны корректно реагировать на ситуацию, когда IPv6 был, а затем внезапно исчезает из системы при выгрузке соответствующего модуля.
Это порождает несколько слоёв сложности:
- необходимо хранить и тестировать код обработки редких и неочевидных сценариев, связанных с отключением IPv6 "на лету";
- поддерживающим ядро разработчикам приходится учитывать эти сценарии при доработке сетевого стека;
- возрастает риск трудноуловимых ошибок, которые проявляются только при динамической выгрузке модуля, хотя в реальных дистрибутивах такая возможность почти никогда не используется.
Отказ от модульной сборки снимает все эти вопросы разом: при статически встроенном IPv6 ядро может исходить из предположения, что стек либо всегда присутствует, либо его нет изначально. Не требуется держать код на случай его исчезновения, а значит упрощается логика зависимостей и очистки ресурсов.
С точки зрения архитектуры ядра это шаг в сторону более жёсткой и предсказуемой модели: вместо гибкости конфигурации в рантайме делается ставка на чётко определённую конфигурацию на этапе сборки. Такой подход лучше вписывается в реальный сценарий эксплуатации: администраторы и пользователи дистрибутивов всё равно крайне редко манипулируют именно модулем IPv6, предпочитая управлять протоколом через настройки сети, файлы конфигурации и параметры загрузки.
Исторически идея собирать IPv6 модулем казалась привлекательной: можно было при необходимости загружать поддержку нового протокола, не перегружая ядро и не включая лишний код в минимальные сборки. Однако по мере того как IPv6 стал стандартной частью сетевой инфраструктуры, потребность в такой гибкости практически исчезла. Большинство машин в пользовательском и серверном сегменте работают с ядрами, где IPv6 включён "навсегда", а отключение осуществляется политиками и конфигурационными опциями, а не выгрузкой модулей.
Для разработчиков сетевой подсистемы отказ от модульного IPv6 означает сокращение объёма кода с редкими ветвлениями. Многие проверочные последовательности, которые сейчас обязаны проверять наличие или отсутствие загруженного модуля, смогут быть упрощены. Это снижает порог входа для новых разработчиков, делает код более понятным и уменьшает вероятность регрессий.
Подсистема BPF, активно использующая сетевые структуры и хуки, также выигрывает от предсказуемости: если известно, что IPv6 не исчезнет в произвольный момент времени, можно убрать дефенсивный код и сосредоточиться на производительности и функционале. Аналогично и для Netfilter: цепочки правил и состояния соединений больше не нужно подстраивать под возможность внезапного удаления IPv6-части стека.
Некоторые сетевые драйверы, поддерживающие как IPv4, так и IPv6, сегодня вынуждены учитывать сценарий, при котором IPv6 выгружают, а интерфейс продолжает работать только с IPv4. Это добавляет коду проверок и разветвлений. После принятия предложенных патчей такие сценарии будут попросту невозможны, что опять же упростит драйверы и снизит число потенциальных ошибок.
Для системных администраторов последствия изменения, скорее всего, окажутся минимальными. Если дистрибутив и так поставлял ядро с встроенным IPv6, никаких изменений в привычной работе не произойдёт. Возможности отключать IPv6 на уровне конфигурации сети, sysctl-параметров или опций загрузчика останутся. Отличие лишь в том, что за этим больше не будет стоять модуль, который можно выгрузить, а будет статически встроенный компонент ядра, чьё поведение контролируется настройками.
В более специализированных сценариях - например, при сборке собственного ядра под встраиваемое устройство - от разработчика теперь потребуется сделать явный выбор: либо вообще не включать поддержку IPv6 в конфигурацию, либо собирать её встроенной. Для большинства таких проектов это не станет ограничением, поскольку либо IPv6 не нужен и полностью вырезается для уменьшения размера, либо, наоборот, используется постоянно.
С точки зрения безопасности, упрощение конфигурации и удаление неиспользуемых путей кода тоже можно рассматривать как плюс. Чем меньше в ядре редких и слабо тестируемых сценариев, тем ниже вероятность скрытых уязвимостей, связанных с некорректной очисткой памяти, состояниями гонки при выгрузке модулей и неконсистентными зависимостями. Статически встроенный IPv6 делает поведение системы более детерминированным.
Важно и то, что речь идёт о включении изменений в ветку linux‑next - экспериментальную площадку, где собиваются и обкатываются нововведения, предназначенные для будущих стабильных релизов. Это значит, что у разработчиков дистрибутивов и крупных пользователей будет время оценить последствия, протестировать свои конфигурации и, при необходимости, высказать замечания до того, как изменения окончательно попадут в релизную ветку Linux 7.1.
В перспективе отказ от модульной сборки IPv6 логично вписывается в общий тренд развития ядра: многие давно устоявшиеся и повсеместно используемые подсистемы постепенно переводятся в разряд "базовых", от которых мало кто ожидает полной динамической отключаемости. IPv6 в современных сетях уже перестал быть экзотикой и всё больше воспринимается как обязательный элемент, наряду с классическим IPv4.
Можно ожидать, что после стабилизации и принятия этих патчей мейнтейнерам сетевого стека станет проще развивать новые возможности IPv6 - не оглядываясь на сложные сценарии выгрузки и повторной загрузки. Это особенно актуально на фоне роста числа функций, завязанных на расширенные механизмы маршрутизации, фильтрации и наблюдения за трафиком, которые тесно интегрированы в стек и сложны для динамического "выдёргивания" из живой системы.
В результате переход к модели "встроен или выключен" для IPv6 выглядит скорее естественным завершением давно начавшегося процесса: ядро избавляется от малоиспользуемых опций, которые усложняют поддержку и не дают заметного выигрыша пользователям. Для одних это изменение пройдёт незаметно, для других станет поводом ещё раз пересмотреть свою политику в отношении IPv6, но в целом система станет немного проще и предсказуемее - как для разработчиков, так и для администраторов.
