Оно легче для L4 фаерволлов. Но в 2026 L4 это легаси, у всех L7.
Возьмем для примера Check Point (один из 3 мировых лидеров). Более-менее поддержка появилась только в последних версиях, и то с ограничениями.
Во-первых, политика IPv4 и политика IPv6 работают и настраиваются независимо. Т.е. нет единого списка правил.
Далее. Для SDWAN IPv6 поддерживается только в сценариях Local Breakout.
Overlay VPN и выбор туннелей в SD-WAN не поддерживаются. Правила типа Overlay с IPv6-объектами игнорируются.
DHCPv6 Prefix Delegation на некоторых типах интерфейсов всё еще имеет проблемы с получением маршрутов и требует ручной донастройки через rdisc6.
Remote access VPN полноценно не поддерживает IPv6-only стек для терминации клиентов. Только дуалстек, IPv6 адрес клиенту выдать нельзя.
Авторизация администраторов в SmartConsole с использованием IPv6-адресов через SAML не поддерживается.
Anti-Spam не обрабатывает IPv6
Geo-Protection для IPv6-адресов работает неточно
QoS обрабатывает IPv4 и IPv6 независимо. Из-за этого Bandwidth metrics и иерархические деревья правил могут рассчитываться некорректно, если через интерфейс одновременно проходят оба типа трафика.
В IPv6-only сети отправка файлов на проверку в облако Threat Cloud или на локальный сервер эмуляции не сработает.
Вот так вот. А у вендоров поменьше все совсем плохо.
Да, я про большие железные фаеволлы, особенно NGFW. nftables всякие хорошо, но вы их не поставите на канал 100Гбит. И вот в таких вот железках IPv6 часто есть лишь нономинально.
IDS/IPS аналогично.
Всякие flow анализаторы аномалий аналогично.
И т.д.
Что касается умирающих железок и новых систем... А в ТЗ на закупку будет ли требование IPv6? Если его нет в корповой сети, то купят то, что дешевле. И будет снова IPv4. Круг замкнулся.
В корпоративных сетях IPv6 не появится, наверное, никогда.
1) Большинству компаний вполне достаточно серых диапазонов IPv4 за NAT. Миллиарды адресов там не нужны.
2) Нормальных фаерволлов и вообще средств защиты под v6 мизер.
3) NAT скрывает внутреннюю архитектуру сети
4) То самое легаси. Древняя бизнес-критичная система может быть написана несколько десятилетий назад. Ее модернизация будет золотой.
5) Такое же древнее железо. Условно терминал на складе, касса, счетчик в АСУТП, станок, принтер этикеток могут не поддерживать v6 и менять их ради этого никто не станет.
Если мы говорим именно про навык программирования - да ИИ вреден. Другой вопрос - а нужен ли этот навык в конкретном случае. Есть навык сварить суп, а есть готовый суп из кулинарии, который нужно засунуть в микроволновку и нажать кнопку. Есть навык начертить деталь, а есть навык напечатать на 3д принтере готовый файл. Есть навык игры на скрипке и записанная фонограмма.
Сейчас многие люди с помощью LLM пишут для себя какие-то скрипты, конфиги, миниаппы. И зачастую им нет нужды учииться программировать, для них это как суп в микроволновке одной кнопкой.
А вот если нужно написать реально большой проект, со сложной неочевидной архитектурой, который еще и с каким-то легаси взаимодействует... Вот тут нужны человеческие навыки.
Использовать чисто WiFi устройства избегаю. Во-первых, они на 99% завязаны на облака производителей - а значит при малейшем сбое связи "превращаются в тыкву". Во-вторых, архитектура WiFi сети представляет собой "звезду" в центре которой роутер. Это значит, что роутер будет и единой точкой отказа и крайне нагруженным узлом: держать соединение с десятками и сотнями WiFi устройств способны лишь немногие роутеры.
Мой выбор - центральный узел Home Assistant и умные устройства на Zigbee или Matter. Zigbee хорош тем, что это устоявшийся протокол с mesh сетью. Matter хорош тем, что позволяет бесшовно связывать устройства из разных экосистем. При этом Thread является более перспективным транспортом для Matter, но WiFi встречается у производителей чаще.
MQTT - неплохая прослойка для интеграции. Позволяет стандартизовать обмен данными.
Информация
В рейтинге
4 040-й
Зарегистрирован
Активность
Специализация
Инженер по безопасности, Архитектор информационной безопасности
Оно легче для L4 фаерволлов. Но в 2026 L4 это легаси, у всех L7.
Возьмем для примера Check Point (один из 3 мировых лидеров). Более-менее поддержка появилась только в последних версиях, и то с ограничениями.
Во-первых, политика IPv4 и политика IPv6 работают и настраиваются независимо. Т.е. нет единого списка правил.
Далее. Для SDWAN IPv6 поддерживается только в сценариях Local Breakout.
Overlay VPN и выбор туннелей в SD-WAN не поддерживаются. Правила типа Overlay с IPv6-объектами игнорируются.
DHCPv6 Prefix Delegation на некоторых типах интерфейсов всё еще имеет проблемы с получением маршрутов и требует ручной донастройки через rdisc6.
Remote access VPN полноценно не поддерживает IPv6-only стек для терминации клиентов. Только дуалстек, IPv6 адрес клиенту выдать нельзя.
Авторизация администраторов в SmartConsole с использованием IPv6-адресов через SAML не поддерживается.
Anti-Spam не обрабатывает IPv6
Geo-Protection для IPv6-адресов работает неточно
QoS обрабатывает IPv4 и IPv6 независимо. Из-за этого Bandwidth metrics и иерархические деревья правил могут рассчитываться некорректно, если через интерфейс одновременно проходят оба типа трафика.
В IPv6-only сети отправка файлов на проверку в облако Threat Cloud или на локальный сервер эмуляции не сработает.
Вот так вот. А у вендоров поменьше все совсем плохо.
Да, я про большие железные фаеволлы, особенно NGFW. nftables всякие хорошо, но вы их не поставите на канал 100Гбит. И вот в таких вот железках IPv6 часто есть лишь нономинально.
IDS/IPS аналогично.
Всякие flow анализаторы аномалий аналогично.
И т.д.
Что касается умирающих железок и новых систем... А в ТЗ на закупку будет ли требование IPv6? Если его нет в корповой сети, то купят то, что дешевле. И будет снова IPv4. Круг замкнулся.
У моего провайдера (небольшого) v6 нет. Да что там... линки 100 мегабитные.
Яндекс.облако - в VPC нет поддержки v6.
В корпоративных сетях IPv6 не появится, наверное, никогда.
1) Большинству компаний вполне достаточно серых диапазонов IPv4 за NAT. Миллиарды адресов там не нужны.
2) Нормальных фаерволлов и вообще средств защиты под v6 мизер.
3) NAT скрывает внутреннюю архитектуру сети
4) То самое легаси. Древняя бизнес-критичная система может быть написана несколько десятилетий назад. Ее модернизация будет золотой.
5) Такое же древнее железо. Условно терминал на складе, касса, счетчик в АСУТП, станок, принтер этикеток могут не поддерживать v6 и менять их ради этого никто не станет.
Если мы говорим именно про навык программирования - да ИИ вреден. Другой вопрос - а нужен ли этот навык в конкретном случае. Есть навык сварить суп, а есть готовый суп из кулинарии, который нужно засунуть в микроволновку и нажать кнопку. Есть навык начертить деталь, а есть навык напечатать на 3д принтере готовый файл. Есть навык игры на скрипке и записанная фонограмма.
Сейчас многие люди с помощью LLM пишут для себя какие-то скрипты, конфиги, миниаппы. И зачастую им нет нужды учииться программировать, для них это как суп в микроволновке одной кнопкой.
А вот если нужно написать реально большой проект, со сложной неочевидной архитектурой, который еще и с каким-то легаси взаимодействует... Вот тут нужны человеческие навыки.
Beta переводит вас с python matter server на новый node.js matter server (впрочем официальная замена и так будет вот-вот).
Тестовый DCL не нужен, если вы не разработчик девайсов.
А нужно в Matter Server Environment Variables добавить: MATTER_DCL_PRODUCTIONURL=https://on.main-net.trustasia.com
Кстати, в последних версиях DCL сертификаты ставятся локально при инсталляции и не фетчатся каждый рестарт.
Использовать чисто WiFi устройства избегаю. Во-первых, они на 99% завязаны на облака производителей - а значит при малейшем сбое связи "превращаются в тыкву". Во-вторых, архитектура WiFi сети представляет собой "звезду" в центре которой роутер. Это значит, что роутер будет и единой точкой отказа и крайне нагруженным узлом: держать соединение с десятками и сотнями WiFi устройств способны лишь немногие роутеры.
Мой выбор - центральный узел Home Assistant и умные устройства на Zigbee или Matter. Zigbee хорош тем, что это устоявшийся протокол с mesh сетью. Matter хорош тем, что позволяет бесшовно связывать устройства из разных экосистем. При этом Thread является более перспективным транспортом для Matter, но WiFi встречается у производителей чаще.
MQTT - неплохая прослойка для интеграции. Позволяет стандартизовать обмен данными.