Привет! Я Лев, системный администратор технической поддержки в Selectel. Мы с вами живем в мире, окутанном «волшебными» тайнами. Как говорится, в интернете все кажется физикой, когда не знаешь магию.
Вот уже много лет слышно про вот‑вот ожидающийся переход на шестую версию IP‑протокола. И все никак этого не происходит. Да и мало кто задумывается, сколько этих версий вообще существует.
В этой статье пристальнее посмотрим на привычную аббревиатуру. Разберем, почему IPv6 никак не заменит предшественника и чего ждать сетевым инженерам, если это все‑таки случится.
Содержание
→ Что такое IP
→ IPv1, IPv2, IPv3
→ IPv4 не бесконечный
→ «Бесконечный» IPv6
→ Текущий уровень внедрения IPv6
→ Утилиты сетевой диагностики для разных версий IP
→ Заключение
Что такое IP
Переместимся ненадолго во вторую половину прошлого века.
В 1969 году Агентство передовых исследовательских проектов (ARPA, Advanced Research Projects Agency) Министерства обороны США запустило экспериментальную сеть ARPANET, ставшую прародительницей современного интернета. У проекта было несколько целей:
устранить несовместимость различных хостов из-за разрозненных форматов сообщений;
сделать сеть децентрализованной, чтобы она оставалась рабочей, даже при выходе отдельных частей из строя;
повсеместно перейти к коммутации пакетов, а не каналов, чтобы не занимать монопольно всю среду передачи — дробление же сообщений на небольшие независимые фрагменты позволит обмениваться данными одновременно множеству хостов на одной физической линии связи.
Цели хорошие. Но как их осуществить?
Компьютеры сети ARPANET соединялись через специальные шлюзы — маршрутизаторы IMP (Interface Message Processor), которые умели передавать пакеты данных. Однако конечные хосты зачастую «не понимали» друг друга — сказывалась несовместимость разных операционных систем и внутренних стандартов.
Нужен был единый протокол передачи данных.
Его разработкой занялась NWG (Network Working Group) — группа молодых ученых под руководством Стива Крокера, аспиранта из Калифорнийского университета в Лос-Анджелесе.
Примечательно, что руководители ARPA сознательно давали полную свободу молодым романтикам вроде Крокера. И седые профессора, и крупные телекоммуникационные компании того времени, как та же AT&T, попросту не верили в перспективность пакетных сетей и отказывались ими заниматься.
Энтузиасты из NWG справились с задачей. В декабре 1970 года вышел NCP (Network Control Program) — первый единый протокол «хост–хост». Через несколько месяцев его успешной эксплуатации также и сетевой интерфейс ARPANET стал стандартом.
Теперь любой университет или лаборатория ARPA легко подключались к сети — достаточно было просто установить ПО с поддержкой NCP. Он стал основой для первых в истории протоколов прикладного уровня Telnet и FTP и первой сетевой электронной почты.
В 1972 году ARPA была переименована в DARPA (Defense Advanced Research Projects Agency), чтобы подчеркнуть военную направленность (Defence — оборонный).
Именно такое название встречается чаще всего, однако на многих документах тех лет можно заметить первоначальную аббревиатуру — ARPA.
С ростом ARPANET все сильнее сказывались критические архитектурные ограничения NCP. Протокол не поддерживал связь разнородных сетей — таких как, спутниковых и радиосетей. В обработке ошибок NCP полагался на саму ARPANET и при потере пакета не мог запросить его повторную отправку.
Предстояло решить новую задачу, иного уровня — объединить разрозненные сети.
В 1974 произошло знаковое событие, которое сильно повлияло на архитектуру будущей глобальной сети. Винтон Серф и Роберт Кан опубликовали статью «A Protocol for Packet Network Intercommunication» в журнале «IEEE Transactions on Communications», где описали архитектуру нового протокола, получившего название TCP (Transmission Control Protocol).
Самое время задаться вопросом: «Статья же про IP, а TCP тут причем?»
Дело в том, что изначально TCP был единым протоколом, объединяющим функции современных TCP и IP. Его главными преимуществами стали:
аппаратная независимость — функционирование протокола обеспечивалось поверх любых типов сетевых технологий;
надежность передачи — реализовывались механизмы управления передачи данных и автоматической ретрансляции утерянных пакетов данных;
сквозная глобальная адресация — каждому сетевому узлу назначался уникальный идентификатор в масштабах всей сети;
межсетевое взаимодействие — для интеграции разнородных сетей применялись специализированные устройства.
В 1978 году TCP разделился на две части: собственно сам TCP, отвечающий за надежную доставку данных и управление потоком, а также максимально простой и универсальный IP — фокусирующийся исключительно на адресации и маршрутизации пакетов между сетями. Рождение IP зафиксировали в серии документов — включая исторический IEN 28/RFC 760, позже, в 1981 году, обновленный до знакомого всем RFC 791.
Управление соединениями в то время находилось целиком в ведении сетей. IP снимал с них всю заботу: сам принимал пакет, сам сверял адрес, сам перенаправлял при необходимости. Немаловажно, что при этом IP никак не гарантировал ни правильную очередность движения данных, ни даже сам факт их доставки. Вся ответственность за логику обработки пакетов — на TCP.
Физические сети разной природы IP объединил, в том числе, и благодаря способности «перенарезать» пакеты под требования промежуточных сетей, после чего, на выходе, пересобирать их обратно.
Каналам связи и программам больше не требовалось адаптироваться — они теперь могли вообще ничего не знать друг о друге. Такая архитектурная независимость упростила разработку и повысила надежность ПО. IP оказался способен передавать данные любым способом: по проводам, радиоволнам, телефонным линиям…
Пришло время сплотить абсолютно разнородные сети.
Объединение произошло 1 января 1983 года и получило неофициальное название Flag Day — в американской культуре означающее радикальный, фундаментальный переход из одного состояния в другое. В эту ночь сеть ARPANET целиком перешла с NCP на современный TCP/IP.
Сейчас нам кажется, что речь идет просто об очередном витке развития технологий — каких уже и не счесть. Тогда же происходила настоящая технологическая драма.
Чиновники в DARPA осознавали, что поэтапный, — а значит, и спокойный — переход неосуществим из‑за принципиальной несовместимости протоколов. Обновление должно произойти быстро и повсеместно.
Пришлось не только развернуть информационную кампанию, но и мотивировать участников, даже оказывать на них психологическое давление. Дедлайн был назначен за несколько лет. Владельцам мейнфреймов поручалось написать или установить код для работы с TCP/IP на своих операционных системах.
В новогоднюю ночь администраторы ARPANET полностью и окончательно отключили механизмы обработки NCP на всех маршрутизаторах IMP. Сеть раскололась на две части: из успешно прошедших и опоздавших. Последние, хоть физически и были подключены, оказались не способны обмениваться данными — их пакеты уходили «в никуда».
Прозевавшие дедлайн администраторы — в праздничный день, без сна и новогоднего настроения — в спешке перенастраивали свои мейнфреймы на TCP/IP. Вскоре практически вся ARPANET заработала на новом сетевом стеке.
Провались переход тогда, глобальный интернет появился бы, но с задержкой и был бы другим. Разрозненные ведомственные и коммерческие сети еще долго нащупывали бы путь, как работать совместно.
Прошло несколько месяцев после Flag Day, и ARPANET разделилась. Военная часть закрылась в MILNET, а оставшаяся — вышла в мир и превратилась в то, что мы теперь называем «интернет». Связующей и стал IP, название которого дословно описывает его роль — Internet Protocol.
В современных сетях IP — это протокол третьего уровня модели OSI, он отвечает за идентификацию устройств.
Перенос и продление домена по 1 ₽
С легкостью переходите в Selectel от любого другого провайдера. Сайт продолжит работать без остановки.
IPv1, IPv2, IPv3
Сколько себя помним, на слуху только IPv4 — не так ли? Но были ли предшественники? Небольшой исторический экскурс удовлетворить любознательность.
Самый первый прообраз IP появился внутри раннего описания объединенного протокола TCP (версия 0 TCP, март 1977 года). В нем еще не было четкого разделения на транспортный и межсетевой уровни, но зачатки IP-функций (адресация, маршрутизация) уже присутствовали.
Информации о первой версии сохранилось очень мало. Известно, что она существовала в виде черновых спецификаций и экспериментальных реализаций в конце 1977 – начале 1978 года.
Вторая версия стала уже задокументированным протоколом. В августе 1977 года в заметке IEN 2 (Internet Experiment Note) она описывалась как отдельный межсетевой протокол с собственным заголовком, в поле Version которого прямо указывалось значение 2.
В феврале 1978 года Винт Серф предложил доработанный формат заголовка в документе IEN 26.
Именно в этот период оттачивались ключевые поля: «время жизни» (TTL), тип сервиса и контрольная сумма. Все это приблизило протокол к его современному виду.
Параллельно в IEN 28 вышла уточненная спецификация, фактически содержавшая элементы будущей третьей версии.
IPv4 не бесконечный
В сентябре 1981 года был опубликован RFC 791, определивший Internet Protocol Version 4, который оказался стандартом на десятилетия.
Основными характеристиками протокола стали:
32-битное адресное пространство — дает теоретический максимум в 4,3 млрд уникальных адресов;
фрагментация и сборка дейтаграмм — позволяет передавать данные через сети с различными значениями MTU (Maximum Transmission Unit, определяющий максимальный размер пакета в байтах для прохождения без предварительного разбиения на части);
заголовок переменной длины — содержит поля для управления маршрутизацией и служебной обработкой пакетов;
поле TTL — механизм, предотвращающий бесконечное блуждание пакетов в сети за счет ограничения количества переходов.
На момент создания и проектирования IPv4 казалось, что такого количества адресов устройств хватит надолго. К концу 1980‑х годов стали появляться первые коммерческие интернет-провайдеры, предоставляющие доступ к сети на основе TCP/IP для бизнеса и частных лиц.
Интернет стал охватывать все больше и больше людей во всем мире, и уже к началу 1990‑х годов стало очевидно, что 32‑битное адресное пространство IPv4, теоретически позволяющее адресовать около 4,3 млрд устройств, окажется недостаточным для растущего интернета. В 1992 году инженеры IETF начали работу над следующим поколением Internet Protocol.
Во время разработки нового стандарта IP архитекторы сети задумались, как еще можно решить проблему исчерпания адресов в сети и устранить другие ограничения IPv4.
Ответом стала технология NAT (Network Address Translation), позволяющая локальной сети использовать частные IP-адреса из диапазонов RFC 1918 — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — и выходить в интернет через один публичный IP провайдера.
При исходящем запросе роутер заменяет частный IP источника на свой публичный и записывает порт в таблицу трансляции (NAT table); входящий ответ возвращается по порту тому же устройству. Это работает для TCP/UDP-сессий, где соединение инициируется клиентом, — серверы в интернете «не видят» внутренние адреса.
Технологию трансляции сетевых адресов можно разделить на три подвида.
1. Статический NAT создает фиксированное соответствие «один к одному» между частным IP (например, 192.168.1.10) и публичным (например, 203.0.113.10), которое администратор настраивает вручную.
2. Динамический NAT использует пул публичных IP-адресов, выдавая их внутренним устройствам по принципу «первым пришел — первым обслужен». Когда сессия заканчивается (по таймауту), адрес возвращается в пул для повторного использования — это «многие ко многим» без портов.
3. PAT (Port Address Translation) — самый экономичный вид, где множество устройств (до 65 тыс на IP) делят один публичный адрес, различаясь портами. Роутер ведет таблицу трансляций, сопоставляя внутренние пары «IP‑адрес и порт» с внешними, отслеживая состояние сессий для обратного маршрута. Операторы такой тип NAT называют CGNAT.
Провайдер применяет ту же логику к тысячам клиентов, используя зарезервированный диапазон 100.64.0.0/10 (RFC 6598) для внутренних адресов. Шлюз CGNAT связывает частную «IP‑адрес и порт» клиента с публичной, отслеживая активные сессии в огромной таблице, вмещающей до нескольких миллионов записей.
Один публичный IP, например 203.0.113.1, делится на 50−65 тыс портов между 100−500 пользователями. Такое соотношение вызвано современной сетевой нагрузкой. Одна только набитая рекламой, скриптами и аналитикой веб‑страница может сходу занять десятки портов. Вдобавок, часто за одним IP скрывается целый домашний зоопарк устройств.
«Бесконечный» IPv6
IPv5
Пятая версия была зарезервирована не для продолжения основной линейки IP, а для экспериментального протокола Internet Stream Protocol (ST), ориентированного на передачу мультимедиа в реальном времени.
Позже появилась его обновленная спецификация ST2 (с тем же номером версии), но широкого распространения этот стандарт так и не получил. Источник: ipv4.global.
Разработка нового протокола, первоначально известного как IPng (IP Next Generation), завершилась в 1995 году публикацией RFC 1883, которая и определила IPv6 (Internet Protocol Version 6). Ключевых инноваций оказалось несколько.
1. 128-битная адресация — количестов уникальных адресов равно примерно 340 ундециллионам, что делает их исчерпание практически невозможным.
2. Упрощенная структура заголовка — фиксированный базовый заголовок, оптимизированный для высокоскоростной обработки маршрутизаторами.
3. Автоконфигурация — возможность автоматической настройки сетевых параметров без участия DHCP-серверов. Взамен новая версия предлагает использовать SLAAC — механизм, позволяющий устройствам самостоятельно генерировать уникальный адрес без использования DHCPv6-сервера.
4. NDP (Neighbor Discovery Protocol) вместо ARP — построен на ICMPv6 и полностью заменяет функции предыдущего протокола, а также добавляет обнаружение маршрутизаторов с перенаправлением трафика. Ключевые сообщения включают:
RS / RA (Router Solicitation / Router Advertisement) — для поиска маршрутизаторов и их настройки;
NS / NA (Neighbor Solicitation / Neighbor Advertisement) — для сопоставления IP с MAC через solicited-node multicast вместо широковещательной рассылки;
Redirect — для указания лучших путей.
Параметр |
IPv4 (DHCP/ARP) |
IPv6 (SLAAC/NDP) |
Автоконфигурация адресов |
DHCP-сервер |
SLAAC без сервера и stateless DHCPv6 |
Разрешение адресов |
ARP broadcast |
NDP multicast ICMPv6 |
Нагрузка на сеть |
Высокая от broadcast-запросов |
Низкая от multicast-запросов |
Безопасность |
Уязвим к spoofing‑атакам |
Использование опций CGA (Cryptographically Generated Addresses) и SEA (Signed Extension Authorization) |
5. Поддержка QoS — встроенные механизмы приоритезации трафика через поле Flow Label минимизируют задержки и потерю пакетов для важных приложений, таких как видеозвонки.
6. Мобильность (Mobile IPv6) — оптимизированная поддержка роуминга и смены точек подключения без разрыва существующих соединений.
Технические и организационные барьеры
Так почему же человечество сразу не перешло на более продвинутый протокол?
Тому несколько причин — например, отсутствие прямой совместимости.
IPv4 и IPv6 — это два совершенно разных протокола, которые не понимают друг друга напрямую. Пакет, отправленный с IPv6-адреса, не может быть доставлен на устройство с IPv4-адресом без специальных переходников. Для этого придумали следующие механизмы.
Dual-Stack — это сетевая конфигурация, которая одновременно поддерживает как IPv4, так и IPv6. Она позволяет устройствам и сетевой инфраструктуре взаимодействовать с использованием взаимозаменяемых протоколов IPv4 или IPv6, обеспечивая совместимость как со старым IPv4, так и с новым IPv6.
Технология Dual Stack (двойной стек) может применяться и на отдельном устройстве, и в масштабах всей сети. Во втором случае одновременную работу с IPv4 и IPv6 должны поддерживать все сетевые узлы, а на их интерфейсах необходимо настроить оба типа IP-адресов.
Клиент понимает, к какому стеку обращаться, в первую очередь благодаря DNS. При запросе домена резолвер возвращает все доступные записи: A для IPv4 и AAAA для IPv6. Наличие AAAA-записи лишь сигнализирует клиенту о том, что сервер поддерживает современный протокол, но не обязывает использовать именно его. Итоговый выбор всегда зависит от приоритетов операционной системы и конкретного приложения.
Для выбора протокола клиент использует алгоритм Happy Eyeballs. Сначала клиент пытается подключиться по IPv6 (с таймаутом 250−300 мс), параллельно инициируя соединение по IPv4. Если ответ по шестой версии приходит быстрее, используется она, в противном случае — IPv4. Такой подход минимизирует задержки в смешанных сетях, где современный протокол иногда работает медленнее предшественника или вовсе недоступен.
На практике это выглядит так.
Клиент отправляет DNS-запрос для нужного домена — например, example.com.
В ответ приходят записи обоих типов, например: A (192.0.2.1) и AAAA (2001:db8::1).
Клиент практически одновременно инициирует TCP-соединение по всем полученным адресам.
Для работы используется тот протокол, который ответил первым. Этот успешный выбор кешируется вплоть до завершения текущей сессии.
NAT64 — это технология, которая позволяет транслировать адреса между сетями IPv4 и IPv6. Ее ключевое отличие — базовая единица сети использует только одну версию протокола (это может быть, например, локальный компьютер). Важное преимущество такого подхода — перенос всей вычислительной нагрузки по взаимодействию с протоколом IP на маршрутизатор. Оконечные устройства освобождаются от необходимости поддерживать двойной стек.
Каждый из этих методов не только добавляет задержку и сложность в настройке, но и является потенциальной точкой отказа.
Существенное техническое препятствие на пути к полному переходу на IPv6 — наличие в мире большого числа legacy-оборудования. Купленный пять лет назад домашний маршрутизатор, скорее всего поддерживает IPv6.
Теперь представим огромные корпоративные сети с множеством сетевого оборудования десятилетней давности. Значительная часть этой инфраструктуры либо вообще не работает с IPv6, либо делает это чисто номинально, с урезанной функциональностью. Замена такого парка — колоссальные затраты.
Среди множества организационных причин, осложняющих переход на новую версию, можно выделить несколько основных.
Во-первых, финансовый аспект: большинству бизнесов, работающих сейчас с сетевым оборудованием, экономически невыгодно переходить на IPv6. Большие компании, конечно, уже внедряют эту технологию, но предпочтение пока отдается IPv4. Смена стандарта — значительная статья расходов на обучение персонала, обновление ПО, замену железа, время на тестирование, — причем не приносящая сиюминутной прямой прибыли.
Во-вторых, дефицит квалифицированных кадров. На данный момент на рынке доминирует IPv4, и системных администраторов или сетевых инженеров, умеющих работать с шестой версией, все еще мало. Изучение нового стека потребует времени и вложений в сотрудников, что неизбежно повлечет и дополнительные издержки.
В‑третьих, далеко не все сетевое оборудование полноценно поддерживает IPv6.
Текущий уровень внедрения IPv6
Оценить масштабы внедрения IPv6 помогает статистика Google, которая ведется с 2009 года. По данным на апрель 2026 года, с новым протоколом работают 45% пользователей Google. Активнее всего эту версию используют в Индии, Германии и США.
В России уровень внедрения IPv6 составляет около 10%, и в основном протокол применяется мобильными операторами связи и некоторыми провайдерами. В нашей панели управления также можно познакомиться с IPv6 и арендовать адреса этой версии для выделенных серверов.
Утилиты сетевой диагностики для разных версий IP
Для работы с IPv6 на сервере и на локальном компьютере нужно настроить сеть. Рассмотрим примеры конфигурации для Windows Server и Linux.
Windows
Для проверки текущих сетевых параметров в командной строке (cmd) используются следующие команды.
ipconfig /all— отображает полную информацию о конфигурации TCP/IP всех сетевых адаптеров на компьютере. Можно увидеть IP-адрес, маску подсети, основной шлюз, DNS- и DHCP-серверы, MAC-адрес, статус аренды IP и другие параметры для каждого интерфейса (Ethernet, Wi-Fi, виртуальные адаптеры).route print— выводит таблицу маршрутизации IPv4 и IPv6, показывая, как система направляет пакеты к разным сетям. Отображаются интерфейсы, метрики, а также постоянные и активные маршруты.
Также для Windows можно проверить настройки сетевого адаптера:
По умолчанию в Windows Server ICMP-запросы заблокированы. Перед проверкой необходимо отключить эту блокировку в настройках межсетевого экрана:
Set-NetFirewallRule -Name FPS-ICMP-ERQ-In -Enabled True -Profile Any -Action Allow
Проверим доступность IP‑адреса сервера из нашего примера, а затем удостоверимся, что порт удаленного рабочего стола открыт. По умолчанию служба RDP (Remote Desktop Protocol) использует порт 3389:
ping -6 2a00:ab00:533:1::100 nmap -6 -Pn -p 3389 2a00:ab00:533:1::100
Также для проверки можно воспользоваться сайтом CentralOps.net.
Linux
Посмотрим также, как настройка сети будет выглядеть на Linux. Для проверки используем стандартные команды:
ip address ip route
Для настройки IPv6 в дистрибутивах Linux, использующих утилиту Netplan (например, Ubuntu), потребуется отредактировать конфигурационный файл в формате YAML. Чаще всего он располагается по пути /etc/netplan/50-cloud-init.yaml.
Файл открывается в любом текстовом редакторе с правами суперпользователя, например:
sudo nano /etc/netplan/50-cloud-init.yaml
На изображении ниже приведен пример конфигурационного файла сети (в разных дистрибутивах могут встречаться несущественные отличия). Также рекомендуем ознакомится со статьей документации о том, как «Подключить дополнительные публичные IP-адреса»:
После внесения изменений в конфигурационный файл сети, изменится IP‑адрес сервера, шлюз, а также добавятся DNS:
Заключение
Кажется, что переход на IPv6 — вопрос времени, а не выбора. Технические преимущества стандарта очевидны: 128-битная адресация, механизм автоконфигурации SLAAC и расширенные возможности для мобильных устройств. Однако на практике глобальная сеть по‑прежнему остается двухстековой.
Сказываются как организационные, так и сугубо технические факторы. С одной стороны, миграцию тормозят высокая стоимость, дефицит профильных специалистов, множество устаревших систем и отсутствие быстрой окупаемости для бизнеса. С другой — аппаратные реализации IPv6 на многих сетевых устройствах все еще остаются «сырыми» и могут содержать критические ошибки.
Вот и получается, что протокол нового поколения успешно применяется лишь в определенных сегментах — мобильные сети, современные облачные сервисы, — где ПО сразу разрабатывалось с учетом новых стандартов. В масштабах же всего интернета ситуация иная.
Наверное, окончательная смена архитектуры неизбежна. Однако IPv4 будет с нами еще очень долго — возможно, не одно десятилетие. Срок полного отказа от старой инфраструктуры теперь зависит исключительно от экономических стимулов, требований регуляторов и стратегий магистральных провайдеров. Вопрос о том, когда именно произойдет этот качественный сдвиг — через пять, десять или двадцать лет, — остается открытым.
Комментарии (130)
Koshol
19.06.2026 08:09IPv8 нужно продвигать уже)
Void-Cowboy
19.06.2026 08:09тот самый IPv8 в который хотят встроить сразу цензуру? Точнее механизм валидации чтоб не лазили где не попадя кто не надо?
nachaevviktor
19.06.2026 08:09Смотрю на эту историю с IPv6 и честно, удивляться тут нечему. IPv4 до сих пор держится из-за NAT, старого оборудования и банально огромных затрат на переход. IPv6 уже давно есть, но мир сети слишком большой и инертный, чтобы быстро всё поменять. Так что это не не заменил, а заменяет, но очень медленно.
StraNNicK
19.06.2026 08:09ещё один момент есть, про который обычно не вспоминают.
Если настроить dual-stack IPv4+IPv6, довольно быстро сталкиваешься с тем, что если удалённый сервис доступен по IPv4, но недоступен по IPv6 — то это означает, что сервис недоступен. Fallback не происходит.
понятно, что это не проблема протокола, но де-факто он просто добавляет ещё одну точку отказа.
и я чувствую себя ретроградом, но пришёл к выводу, что если нет чёткого понимания зачем тебе IPv6, то проще его отключить.
firegurafiku
19.06.2026 08:09если удалённый сервис доступен по IPv4, но недоступен по IPv6, то это означает, что сервис недоступен
Если я правильно понял, что вы имеете в виду, то для такого поведения нужна достаточно специфичная ситуация: сервис указал у себя в DNS и A-запись, и AAAA-запись, но по факту по IPv6 не работает, причём не просто не принимает подключения (тогда бы сработал фоллбэк), а принимает, но работает неправильно.
Это, конечно же, однозначный косяк сервиса, а не протокола.
Кстати, в Windows можно настроить приоритет IPv4 в подобных случаях, правда, делается это, почему-то, через реестр:
Hidden text
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows
Guidance for configuring IPv6 in Windows for advanced usersHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\ DisabledComponents = 0x20StraNNicK
19.06.2026 08:09всё верно, это именно косяк сервиса (я об этом сразу написал)
но, к сожалению, он встречается чаще, чем хотелось быприоритет IPv4 выставить можно, но в таком случае, чем это отличается от полного отключения IPv6?
NAI
19.06.2026 08:09мир сети слишком большой и инертный
Что-то это не мешает wi-fi'ю обновляться каждые 5-7 лет. Сейчас сложно найти устройство под wi-fi 4. Они конечно есть, но это совсем уж начальный уровень.
Второе, инертность и затраты, как-то не помешали провайдерам перейти с 10 мб\с, на 100 мб\с, а затем и на 1G. 2G\3G\LTE\4G\5G, соответственно, у мобильных операторов. Я тут кстати с удивлением обнаружил, что собрать сетку на 100 мб\с SFPихах дороже чем на гигабитных.
Проблема IPv6 в том что она не нужна конечному потребителю -> провайдеры не могут это продавать -> нет смысла тратить время и деньги. Бонусом идет забавный факт, что конечному пользователю еще время на настройку Firewall'ов потратить надо, так-то. В вашей мобиле fw настроен? Уверены что какой-ндь ES File Explorer поднимет сервис без вашего ведома, который будет голой попой торчать в IPv6.
Отсылка
...особенность ES File Explorer состояла в том, что даже единичный запуск приложения на Android-устройстве провоцировал его превращение в HTTP-сервер с открытым портом 59777. Именно он позволял участникам локальной сети, к которой подключена жертва, перехватывать ее данные, а также получить доступ к информации об устройстве, что в свою очередь могло послужить основанием для взлома или совершения других деструктивных действий.
Я уж молчу про то что не у всех есть компетенции.
Anselm_nn
19.06.2026 08:09тот самый аргумент о глобальной видимости каждого устройства каждым и является проблемой, 99% устройств могут иметь дыры и при выставлении их голой жопью в инетрнет, мирайя, петя и ваннакрай покажутся цветочками, а текущий поход, когда конкретное устройство прокидывается наружу (порой не без шаманства) косвенно похоже на политику deny all, что гораздо лучше при неизвестном уровне подготовки пользователя и дырявости устройств.
использовать в локалке глобальную адресацию тоже сомнительной нужности решение, поэтому говорить о том, что ipv4 кончились, из-за роста количества устройств, которым не требуется доступ снаружи, не приходится. при этом кроме ната есть еще всякие сервисы типо CF, nginx где тоже за одним адресом куча сервисов уживается
Heggi
19.06.2026 08:09В локалке (в пределах сегмента) используются link-local адреса (FE80::). Глобальные - только для доступа в другие подсети.
firegurafiku
19.06.2026 08:09и при выставлении их голой жопью в инетрнет
Ничто в IPv6 не заставляет так делать, как был фаервол на домашнем или корпоративном роутере, так и останется. В IPv6 фаерволу не нужно заниматься трансляцией адресов, но контролировать входящие и исходящие соединения он всё ещё обязан.
использовать в локалке глобальную адресацию тоже сомнительной нужности решение
Можно не использовать, есть целая
fd00::/8под локальные адреса. При этом для того, чтобы выпустить устройства из локальной IPv6-сети наружу, фаерволу роутера достаточно пары правил для замены префикса вместо динамической таблицы, отслеживающей все соединения в реалтайме.Кстати говоря, в IPv6 сразу предполагается, что у каждой локалки будет свой рандомный префикс, что весьма удобно, если локальные сети как-то сообщаются. Например, если у вас и дома и на работе
192.168.0.0/24, и вы хотите удалённый доступ в рабочую сеть, кому-то придётся переехать на другой префикс.говорить о том, что ipv4 кончились […] не приходится.
Если они не кончились, почему они такие дорогие? У облачных провайдеров они уже 2 доллара в месяц за штуку, и дальше будет только дороже.
NAI
19.06.2026 08:09был фаервол на домашнем или корпоративном роутере, так и останется
Кто его будет настраивать домашним пользователям?
если домохозяйкам настраивать условный deny all incoming, allow all out, то смысл IPv6 теряется наглухо, т.к. те же peer-to-peer(voip, конференции) сервисы превращаются в тыкву
Heggi
19.06.2026 08:09Для IPv6 есть аналог uPnP, который добавляет нужные правила на вход.
NAI
19.06.2026 08:09Надо было сразу написать что uPNP не предлагать, т.к. это костыль который работает опять таки в очень ограниченном ряде случаев.
Давайте рассматривать кейс с мобилой и ES File Explorer. Дома\на работе админ делает deny all incoming, allow all out, включает "upnp". А в мобильной сети кто этим будет заниматься? А если я с мобилы на даче шарю интернет, мне его(upnp и firewall) где включать?
Далее, upnp - любая майлварь сможет открыть доступ к моему пк\мобиле? Тоже такое себе.
Вы же в курсе как ms закостылили безопасность? В win10\11 забирают себе два ipv6, один статический, второй динамически, периодически меняется, чтобы по вам не прошлись сканером портов (ну или если даже прошлись, не успели воспользоваться). Решение сомнительное, но вот так.
С ipv6 шаринг сервиса становится приключением. Кейс, рабочий ноутубук
docker up -p 80:80 dev_container(пример условный). Вроде бы все окей, НО. как только я с этим нотуом окажусь в кафе\мобильном интернете, кто и что настраивал на fw вопрос открытый, для меня это сразу не доверенная железка - т.е. FW должен быть настроен на моем ноуте. Возвращаемся к началу... домохозяйка в душе не знает что и кто у нее там включил и поднял. Она хочетработатьлистать котиков из дома\кафе\дачи\рабочего места.В общем, чтобы это все работало нормально нужен или нормальный админ который настроит FW на всех устройствах и МЭ или отказаться от основных фичей ipv6.
none7
19.06.2026 08:09Или statefull firewall на каждом устройстве нуждающемся в защите. Собственно все специалисты по безопасности уже пришли к выводу, что защита сети общим фильтром это мнимая безопасность. Стоит кому-то изнутри сети установить себе трояна или прикреить пароль от Wi-Fi к монитору и вдруг оказывается, что сеть вообще не защищена от внутренних угроз.
Только end-to-end защита может в самом деле что-то защитить. Все остальные меры защиты как временные адреса и использование локальных адресов защиты не гарантируют. Они сужают область атаки, но это как иметь одну дырку в носках вместо двух.
BugM
19.06.2026 08:09Классный план. Только вот принципиально нереализуемый. Каждую лампочку и каждый пылесос никто чем-то оснащать или настраивать не будет.
Что делать будем? Ipv4 при этом отлично работает в реальном мире с реальными устройствами. Которым надо сидеть на натом.
VMcS
19.06.2026 08:09есть целая
fd00::/8ULA задумана как раз чтобв избежать маршрктизации наружу, например для сетей лабораторий, произвондственных сетей заводов, внутренних сетей оборудования и т.д.
Использовать адреса ULA чтобы их затем транслировать - плохая идея, попросту это копирования мышления из IPv4: приватные адреса + N/PAT. Ключевая концепция IPv6 это возврат к глобальным адресам на конечном устройстве. Мир настолько отвык от этой концепции, что она смущает и пугает.
BugM
19.06.2026 08:09Ключевая концепция IPv6 это возврат к глобальным адресам на конечном устройстве. Мир настолько отвык от этой концепции, что она смущает и пугает.
Эта концепция уже признана плохой и в прод никогда не поедет.
Зачем каждой лампочке быть адресуемой извне? Это опасно и не приносит никакой пользы.
2026 год на дворе, вроде всем понятно как сети строить надо. И как не надо. Зачем тянуть в современность идеализм 80тых годов? Он не работает в реальном мире.
VMcS
19.06.2026 08:09Простите, кем конкретно эта концепция признана плохой?
Я нигде не встречал подобной позиции высказываемой всерьез, ни на различных NОG, ни в дискуссиях IETF. Не могли бы вы дать ссылку где почитать?
BugM
19.06.2026 08:09Миром. Теми людьми которые реально строят и эксплуатируют сети.
Четвертый десяток лет "внедрения" ipv6 говорит за себя лучше любых комитетов по комитетам.
VMcS
19.06.2026 08:09Я тот человек, который реально строит и эксплуатирует сети уже 25 лет. Я не претендую на весомость и авторитетность моего личного мнения, но ценю мнение тех людей, которые этот авторитет имеют и помимо работы над своими сетями, проектирования сетевого оборудования и дизайна сетей, занимаются проектированием протоколов и созданием спецификаций. И занимаются они этим не "где-то-там-в-углу", а в форумах NOG, IETF, ETSI, ISO, ANSI и т.д. где их мнения обсуждаются и рецензируются.
Ваше "миром" означает "никем". Прекращайте говорить за всех. Если лично у вас IPv6 не скрепен и вообще от лукавого, то это не значит, что во всем мире это на самом деле так. "Если к вам не прижимаются в парижском метро, это не означает, что метро в Париже не существует".
BugM
19.06.2026 08:09Комитет контролирующий работу комитетов и ведущий журнал для журналов. Ага.
И даже они буквально недавно признали что NAT это великолепная и нужная технология и добавили аналог в ipv6. А вы все еще упираетесь.
Никто, кроме буквально всех частных сетей в мире.
VMcS
19.06.2026 08:09Комитет контролирующий работу комитетов и ведущий журнал для журналов. Ага.
Вы о чем?
И даже они буквально недавно признали что NAT это великолепная и нужная технология и добавили аналог в ipv6.
Кто "они"?
NAT в разных видах есть в IPv6 десятки лет, он нужен для переходного переода миграции на IPv6, нужен для специфичных ситуаций и т.д. То что такой инструмент есть и он бывает нужен - никто не отрицает и никто не пытается выкинуть его из идеологических воззрений. Однако никто не пытается, зная о его отрицательных качествах для дизайна и производительности сетей, делать его рекомендуемой по умолчанию технологией.
Никто, кроме буквально всех частных сетей в мире.
У вас какой-то алтернативный мир.
BugM
19.06.2026 08:09О том что комитет много лет не замечает реальные проблемы. И старательно ничего не делает. Значит это комитет по журналам о журналах. И относить к нему надо соотсвенно.
Вы все пропустили. NAT это несущая технология. И она будет теперь всегда. Она идеально работает во всех типовых случаях. По железу стоит уже дешево. И это уже признали и сделали аналог. Не на переходный период, а навсегда.
У меня реальный мир. Где все сидят на серых адресах и все отлично работает из коробки. Ломать это никому не надо.
VMcS
19.06.2026 08:09О том что комитет много лет не замечает реальные проблемы.
Комитет какой организации?
NAT это несущая технология. И она будет теперь всегда. Она идеально работает во всех типовых случаях. <...> И это уже признали и сделали аналог. Не на переходный период, а навсегда. <...> У меня реальный мир. Где все сидят на серых адресах и все отлично работает из коробки.
Не упадите за край Земли. :)
BugM
19.06.2026 08:09Тех которые должны писать стандарты ipv6. Они
годамидесятилетиями сидели и твердили что NAT вам всем не нужен. И люди логично их игнорировали. Потому что нужен. Вот теперь к ним такое отношение.
VMcS
19.06.2026 08:09Я не хочу вас разочаровывать, но в мире нет людей, которые должны писать стандарты ipv6. Принять участие в написании стандартов может любой человек, включая вас.
Но все же хотелось бы от вас услышать, кто те люди о которых вы говорите и комитет какой организации нас так жестоко обманывал все эти годы?
VMcS
19.06.2026 08:09В группу со статусом "завершена"? Даже странно, почему вас туда не пускают :) Теория заговора, не иначе.
А найти группы 6man или v6ops что вам не позволяет? Или войти в конкретную группу по любому открытому драфту?
Начните с изучения принципов IETF https://www.ietf.org/about/introduction/#principles
Участником может быть любой. Но вам я этого рекомендовать не стану.
NAI
19.06.2026 08:09Простите, кем конкретно эта концепция признана плохой?
Я понимаю, что отвечать вопросом на вопрос плохая практика, но когда слышу такой довод, то всегда хочется спросить - кто будет настраивать firewall на всех этих устройствах? Мы же не можем сделать на межсетевом экране на входе в квартиру
deny all incoming, allow all outиначе теряется концепция связанности устройств. И даже если пропишем такое правило, то где гарантии что в условном кафе есть такое же правило.Особенно весело все это работает для носимых устройств, которые перемещаются между разными сетями (дом-мобила-общ.сеть-работа). У меня есть ноут. на нем поднят dev-сервис где все пароли admin\admin и http(потому что нафиг мне мучаться\тратить время с сертификатами не на prod\stage). Так вот, дома на микроте правило создал, никаких внешних подключений - все ок. Но как только я окажусь в кафе - где гарантии, что мой dev-сервер не окажется голой жопой в интернете?
Соответственно, мне надо или настраивать два файрволла (на МЭ дома, и на ноуте) - что как бы работы х2 плюс это еще уметь надо (а по факту на всех носимых устройствах, что есть х5) или второе, прибивать (проводить аудтит по всем сервисам) сервис к localhost - что тоже требует телодвижений, и иногда весьма прикольных особенно если софт, проприетарный.
Есть вариант конечно на dev-делать все секьюрно, но давайте будем реалистами - мне надо написать код, а не е*ться две недели с обеспечением безопасности.
Отдельный вопрос что делать с устройствами где нет доступа к FW. Вот у меня pixel 7, даже с 17 андройдом, где гарантия что ES File Explorer не откроет 59777, когда я буду подключен к мобильной сети\сети кафе?
Сейчас, везде NAT, и мой 80 порт конечно торчит голой жопой в кафе, но торчит он сугубо в локалке этого самого кафе. Вероятность что там же окажется кулхацкер Васян2000, ничтожно мала.
Можно сказать что и адресов в ipv6 вагон и попадание под сканер портов еще ниже чем в кафе - да. НО это если никуда не ползать! По факту, любой заход на сайт\запущенный торрент\обращение к DNS - палит ipv6.
Я проводил эксперимент - брал торрнетны и стучался сканером портов на ipv6 - угадайте, сколько веб-морд Transmission'а было найдено =)
VMcS
19.06.2026 08:09Резонный вопрос. Но если выделить суть, то вопрос сводится к тому, как управлять файерволами в противовес кажущейся защищенности благодаря скрытию внутренней сети посредством NAT. Фактически стоит исхохить из того, что сеть или устройства должны быть защищены от входящих извне соединений вне зависимости какой стек используется и используется глобальная адресация или NAT? Логично предположить, что в разных зонах определяется - должны ли быть открыты некоторые порты или нет (дома и в кафе - нет, в офисе - да). На практике это вопрс не протокола, а реализации файервола (на устройстве или маршрутизаторе), который может поддерживать отдельные профайлы (с соответствующим набором правил) для каждой локации. Профайл должен содержать делегируемый префикс полученный от аплинка, а так же адрес хоста назначаемый устройству (или, в случае роутера, выдаваемый устройству через SLAAC или DHCPv6). Таким образом, для каждой локации существует отдельный профайл, реализующий политику на основе полного GUA устройства. Профайлы могут переключаться вручную или автоматизированно, например, в зависимости от делегируемого префикса, SSID сети wifi, интерфейса wifi vs мобильная сеть, и т.д.
Касательно динамического открытия портов для входящих IPv6 соединений - есть реализация через UPnP или PCP. В этом плане нет принципиальной разницы от динамического проброса портов на роутере с NAT.
Насчет палева адреса. Сканирование 2^64 адресов в префиксе /64 (а ряд провайдеров делегирует абоненту /56) помноженное на 2^16 портов дает несравнимо большее количество вариантов по сравнению с 2^16 вариантов для единственного публичного IPv4 адреса NPAT. К тому же нынешняя тенденция это генерация случайной хост-части адреса (и ее регулярная смена) взамен генерации адреса используя EUI-64, что делает начтожно малой вероятность обнаружения открытого порта сканированием.
NAI
19.06.2026 08:09то вопрос сводится к тому, как управлять файерволами
Вопрос не про "как", а про "кто". "Как" понятно - профили (общедоступная\частная сеть) еще в win7 появились.
Сейчас домохозяйке не нужен админ, а с IPv6 получается нужен. Не потому что IPv6 плох, а потому что для конечных, не компетентных пользователей несет риск.
Ну и кстати про FW - чет я на андройде не вижу FW в принципе =) 2026 год так-то, количество китай-фонов в которых вообще все что угодно может быть открыто зашкаливает.
Сканирование 2^64 адресов в префиксе /64
Вторая часть абзаца парирует этот тезис - я его специально сразу написал... это работает только если вы ходите на ограниченное количество ресурсов с сильным доверием и аудитом.
VMcS
19.06.2026 08:09"Кто" - в любом случае владелец хоста или сети. Я думаю, что все сведется к обшепринятому подходу - по умолчанию FW должен быть на любом хосте или граничном роутере с политикой по умолчанию accept any to OUT, deny any to IN, если необходимо открыть что-то - внесение правил исключения из правила по умолчанию. Вручную или автоматически через UPnP/PCP - это уже детали. Например такой принцип реализован на всех миллионах наших клиентских маршрутизаторов. Принцип реализован одновременно и одинаково для IPv4 и для IPv6, в этом плане нет никакой разницы между стеками (кроме разве что опции проброса порта через NAT для IPv4, для IPv6 в этом, очевидно, нет необходимости).
На хосте реализация этой защиты является ответственностью производителя OS или на худой случай - владельца хоста. Хорошо если операционка изначально поставляется с файерволом (да еще с профилями по умолчанию), но если нет - логично предположить что владелец должен озаботиться такой защитой. Иначе получится что владелец будет "колоться, плакать, но продолжать грызть кактус".
Я еще раз хотел бы подчеркнуть, что в плане безопасности иметь настроенную фильтрацию (на хосте и в сети) - это обязательный минимум вне зависимости от стеков. А при применении такой политики особых преимуществ у IPv4 c NAT перед IPv6 нет.
это работает только если вы ходите на ограниченное количество ресурсов с сильным доверием и аудитом
Почему? Если взять рандомно генерируемую хостовую часть адреса v6, то эффективность сканирования стремится к нулю. Или я не успел за вашей мыслью.
NAI
19.06.2026 08:09Если взять рандомно генерируемую хостовую часть адреса v6, то
Рандомная генерация происходит, обычно, при инициализации интерфейса и держится до ребута (сужу по win 11). Соответственно, мой запущенный торрент клиет палит IPv6 адрес в DHT-сети, любой скомпрометированный хостинг\либа на cdn, сразу увидит фактический IPv6-адрес.
Да у злоумышленника будет условно 2-3-8(рабочий день) часов, чтобы заняться моим ПК, но ключевое здесь что - рандомайзер не панацея, а костыль, как раз из-за того что
по факту
с fw на конечных устройствах проблемы, пользователи не знают\хотят их настраивать или они там отсутствуют как класс.
И возвращаясь к первой части вашего ответа, это хорошая правильная теория, которая в жизни сейчас не работает (это спустя сколько то там лет внедрения IPv6).
VMcS
19.06.2026 08:09Рандомная генерация происходит, обычно, при инициализации интерфейса и держится до ребута (сужу по win 11).
RFC8981
но ключевое здесь что - рандомайзер не панацея, а костыль
Да нет, это не костыль, это всего лишь побочный эффект архитектуры ipv6. Как и скрытие открытых портов на вашем хосте благодаря NPAT на роутере - это побочный эффект NPAT.
Но NPAT проектировался с другой целью, как и цель архитектуры IPv6 не безопасность, а транспорт. Возьмите тогда для честного сравнения гипотезу, что ваш роутер получает публичную подсеть IPv4 с назначением публичного IPv4 вашему хосту, то есть нет NPAT, только роутинг. Вы получите аналогичную ситуацию. И решать эту проблему должен FW (или хотя бы ACL), а не IP протокол.
Просто NPAT, как раз задуманный в свое время костылем для решения проблемы исчерпания адресов IPv4, но дал полезный побочный эффект в плане безопасности (и то не панацея в плане защиты и контроля лоступа). NPAT, ставший за годы базовой нормой, стал ошибочно аосприниматься как механизм защиты вместо FW. Произошла подмена понятий и вместо нормы ставить FW на каждый хост возникло обманчивое упование на базовую защиту благодаря NPAT.
Вот есть у вас публичный адрес на хосте. IPv4 или IPv6. Что следует предпринять для защиты - прикрутить NAT или настроить FW?
по факту с fw на конечных устройствах проблемы, пользователи не знают\хотят их настраивать или они там отсутствуют как класс.
FW встроен во все популярные современные OS (по крайней мере десктопные - Win, Linux, macOS, etc.) или входит в пакеты антивирусной защиты. Дефолтной настройки достаточно чтобы закрыть потребности 99% пользователей. Оставшийся процент пользователей, которым нужна специфичная конфигурация отличная от дефолтной, знают зачем им это нужно и как ее настроить.
равильная теория, которая в жизни сейчас не работает
Здесь я не согласен. IPv6 еще не стал повсеместным, совершенно верно, но распространяется все больше и больше. Просто это не так пока заметно (хотя резко ускорился в последние годы). Внутренние сети многих крупных компаний уже на IPv6 (тот же Гугл, Фейсбук), андерлеи датацентров - на IPv6 only (AFAIK тот же Yandex в Финляндии), колличество сайтов доступных через оба стека растет.
inkelyad
19.06.2026 08:09Почему? Если взять рандомно генерируемую хостовую часть адреса v6, то эффективность сканирования стремится к нулю. Или я не успел за вашей мыслью.
Он же не про сканирование. Он про сценарий, когда заходишь на какой-то сайт, а сайт(или зловред на сайте, который соединения сканирует) лезет по теперь известному ему адресу. Тому самому, который для соединения с сайтом использовалось.
Heggi
19.06.2026 08:09Есть rfc8981, который заставляет ОСь генерировать случайный IP-адрес раз в некоторое время и исходящие соединения будут идти с нового адреса. Так что у зловреда на сайте не очень большое окно актуальности IP-адреса.
Ну и вообще, от такого файрвол помогает.
inkelyad
19.06.2026 08:09Но как только я окажусь в кафе - где гарантии, что мой dev-сервер не окажется голой жопой в интернете?
У вас и сейчас нет. Потому что у кафе точка доступа от какого-нибудь оператора. Который может оказаться неожиданно щедрым и будет прокидывать белые IPv4 адреса на подключающиеся устройства. CGNAT разных сейчас много где разных есть.
Поэтому да, если ноут с dev окружением подключается в публичные сети, то сервисы на нем надо делать нормально, прикрываясь локальными firewall-ами, нормальной авторизацией и вешаясь на адреса, недоступные снаружи. В IPv6 мире это, как я уже тут указывал - даже удобней. Слушаем только LinkLocal -- и внешний мир будет изолирован.
NAI
19.06.2026 08:09Который может оказаться неожиданно щедрым и будет прокидывать белые IPv4 адреса на подключающиеся устройства.
За 22 года (а именно в 2004 у меня появился первый ноут), я такого не видел ни разу. Вероятность такой штуки еще ниже чем кулхацкер Васян.
прикрываясь локальными firewall-ами, нормальной авторизацией и вешаясь на адреса, недоступные снаружи
Вопрос был кто это будет настраивать домохозяйкам =) Потому что ситуация когда какое-то ПО поднимает сервис в windows вообще ни разу не гипотетическая
Heggi
19.06.2026 08:09Современный уважающий себя бытовой роутер уже имеет дефолтный файрвол, блокирующий входящие соединения. За все роутеры не скажу, возможно китайщина за 1.5 копейки и не имеет таких настроек, но ССЗБ такое покупать вообще.
Плюс винда имеет нормально настроенный файрвол, который для публичных сетей блокирует входящие.
Так что дефолтной домохозяйке не надо ничего настраивать. За неё уже всё настроили.
NAI
19.06.2026 08:09В этой дискуссии мы ходим по кругу.
Где в андройде/яблоке fw? Или в мобильной сети провайдер будет заниматься fw? или мне верить что админ кофейни в 1.5 столика имеет cisco ipv6-certificated (или как оно там у них?) и всё настроил как надо. Еще раз, публичные сети - zero trust, fw должен быть настроен на устройстве.
Если в дефолтном fw будет включено блокировка входящих, то теряется связанность.
При включенном upnp кто будет контролировать сервисы?
Еще раз кто будет заниматься в дивном новом мире всем этими проблемами у домохозяек?
Heggi
19.06.2026 08:09Ради интереса прогнал nmap по своему телефону (android). Все найденные порты - filtered. Никакого специального софта я не ставил.
firegurafiku
19.06.2026 08:09Ключевая концепция IPv6 это возврат к глобальным адресам на конечном устройстве
Эта концепция хороша, если у вас есть своя AS и ваш провайдер позволяет вам анонсировать свой префикс (я бы не ожидал такого от провайдеров домашнего инернета и через двадцать лет). Если же вы используете внутри сети тот префикс, что вам выдал провайдер, то вы не можете нигде хардкодить адреса (например, в правилах правилах маршрутизации или фаервола), иначе при смене провайдера всё сломается. Как будто бы
fd00::/8тут меньшее из зол.VMcS
19.06.2026 08:09Получить PI и свой ASN для компании не проблема, даже с учетом российского законодательства. В глобальном плане это не проблема вообще. Это вопрос стратегии и политики компании.
Вообще IPv6 построенная на применении SLAAC и DHCPv6 изначально предполагает возможность смены префиксов GUA. Смена префикса по причине смены аплинка - это лишь частный и вполне нормальный случай.
Так же IPv6 изначально предполагает множественность адресов на одном сетевом интерфейсе - LLA, один или множество ULA и GUA, что позволяет назначить одному и тому же интерфейсу GUA из делегированных префиксов каждого из ISP-аплинков. Выбор конкретной наилучшей архитектуры резервирования или возможной реадресации - это вопрос отдельный для каждой компании. Чего точно стоит избегать так это NATа как такового.
coolubrovin
19.06.2026 08:09Переход на IPv6 напоминает бесконечный ремонт. Вроде бы все понимают необходимость новых инженерных коммуникаций, но менять всё на лету слишком дорого и рискованно .
VMcS
19.06.2026 08:09Потому что это неправильный метод внедрения. Лучшая практика развертывания IPv6 это включение темы IPv6 в каждый новый проект - на уровне дизайна и/или конфигурации. Финансовые и трудозатраты возрастают незначительно (по сравнению с переходом одним хопом), и постепенно подспудно набирается опыт персонала, а в перспективе 3-5 лет сеть и инфраструктура становится полностью адаптированной к dual stack и в определенный момен переход становится простым и безболезненным.
BugM
19.06.2026 08:09Можно, а зачем? И так все хорошо работает, ipv6 только приносит рандомные баги связности и вызывает непонятные баги в либах. Лучше без него. Проще, дешевле, надежнее.
VMcS
19.06.2026 08:09IPv6 работает на сегодняшний день, причем в продакшене. Баги лечатся (как и любые баги), проблемы находятся и решаются. Это нормальный процесс в любой технологии без исключения. А с таким подходом зачем вам прогресс и эволюция вообще? Костры, голуби, гонец с депешей - это проще, дешевле, надежнее.
Задайте себе вопрос: 30 лет сетевые инженеры тратят силы на разработку, развитие и внедрение протокола IPv6. Есть ли у них серьезные основания на эти усилия или это делается просто ради блажи?
BugM
19.06.2026 08:09В продакшене, но таком что если ipv6 завтра выключить никто ничего не заметит.
40 лет, Карл! И баги до сих пор. Причем баги в каких-то базовых кейсах. Кажется это нерешаемая проблема.
Так не тратят. По остаточному принципу все делается. Не работает, ну и ладно. Через недельку починим. Наверно.
Это не тот прогресс который нужен. Это ломание работающей технологии просто так. Вместо того чтобы исправить то единственное место в котором ошиблись. Хорошие инженеры так не делают.
VMcS
19.06.2026 08:09Часть ресурсов уже IPv6-only. Без IPv6 они не недоступны. Так что заметят.
Баги протокола или реализации в оборудовании? Если последние - заурядное и нормальное дело. Баги находятся, баги исправляются. Если ваш призводитель оборудования не исправляет баги, то пересмотрите свои политику работы с таким производителем. Баги протокола? Будте любезны ссылку на конкретный баг.
По остаточному принципу все делается. Не работает, ну и ладно.
Где? У кого?
Это не тот прогресс который нужен. Это ломание работающей технологии просто так. Вместо того чтобы исправить то единственное место в котором ошиблись. Хорошие инженеры так не делают.
Вам лично не нужен. Вполне возможно. А другим нужен. А если вы видите только одну единственную проблему, которую вызван решить IPv6, то вам стоит углубиться в изучение темы. Как хорошему инженеру.
И, кстати, инженеры не ошиблись. Они приняли рациональное и адекватное решение на тот момент времени.
BugM
19.06.2026 08:09Покажите парочку ipv6 only сервисов. Я что-то ни одного не знаю.
Судя по тому что вокруг себя вижу он никому не нужен. За какими-то редкими исключениями. Плюсов у него все еще нет, а работать и деньги тратить надо. И зачем?
Ошиблись и сильно. Причем прямо в базовых штуках. Они забили на совместимость. Спустя 40 лет это уже очевидно.
VMcS
19.06.2026 08:09Покажите парочку ipv6 only сервисов. Я что-то ни одного не знаю.
https://www.ev6.net/v6sites.php
Можете сами просканировать пространство DNS не предмет FQDN имеющих только RR AAAA без RR A.
Ошиблись и сильно. Причем прямо в базовых штуках. Они забили на совместимость. Спустя 40 лет это уже очевидно.
Читайте протоколы IETF и мемуары участников. Там есть про обоснование размерности IPv4. И выбор протокола на роль NG, про возможность соместимости и почему не уделялось особого внимания процессу перехода на новый протокол. А задним умом любой силен.
BugM
19.06.2026 08:09Прикольно. Списочек как в 90тых.
И заметная часть какие-то тесты. По именам видно. Вторая заметная часть какие-то пустые заглушки. Да я руками прокликал верхнюю часть списка.
Как-то негусто в общем. Не могу сказать что статистически значимое число людей что-то заметит если ipv6 завтра выключат.
Читал, там весело. Костыли на на костылях приправленные авианосцами. Не надо так.
В 80тые уже понимали ценность обратной совместимости. Не надо считать что тогда не знали или не умели хорошо делать. Умели. Но не стали. И за это заслуженно их критикуем.
VMcS
19.06.2026 08:09Можете сами просканировать пространство DNS на предмет FQDN имеющих только RR AAAA без RR A и актуализировать список.
Я верно понимаю, что вы не сетевой инженер?
VMcS
19.06.2026 08:09BugM, Вы вообще в принципиально выигрышной ситуации. Текущее состояние интернета прекрасно соответствует вашим желаниям - IPv4, NAT, все прекрасно работает и будет прекрасно работать еще десятки лет, а то и больше. Всякая ересь и вольнодумство типа ipv6 от лукавого и все никак, уже почитай 30 лет, не завоюет этот мир...
Я единственно что не понмаю - зачем вы вступаете в дискуссии (и под этим постом и ранее, под другими постами на Хабре на тему ipv6)? Я искренне не понимаю что вы пытаетесь разьяснить или доказать? Что ipv6 не нужен не только вам, но и всем остальным? Вам, возможно, нравится спорить о вкусе устриц с теми кто их ел, но со своей стороны я нахожу это занятие бессмысленным и бесперспективным.
BugM
19.06.2026 08:09Все такие статьи пишутся а одних словах. Поехали, пора, мигрируйте, а то опоздаете.
Когда на самом деле нет. Лучше сидеть ровно и не делать ничего. Вот, хочется принести каплю разума хотя бы а комментарии.
Inoriol
19.06.2026 08:09Работаю в компании где вся инфраструктура ipv6-only (забугорный телеком). За последние четыре года прям очень чувствуется что ipv6 дал по газам — уже часто всё работает из коробки, без этого неловкого оборачивания айпишников в квадратные скобочки и замены 0.0.0.0 на [::] в конфигах (очень частое было явление, когда формально поддержка ipv6 есть, а по факте нормально не тестировали или тестировали в dual stack'е).
Так что верно идём в будущее. Уже здесь и домашние интернеты в городах все ipv6 обмазаны, почти все мобильные операторы ipv6-only. Как будто бы полный переход в ближайшие десять лет, с устареванием старого оборудования, почти неизбежен
RockyMotion
19.06.2026 08:09А по факту сайт все еще не перевести на ipv6 - не работает частенько под vpn, нет доступа с части провайдеров и т.д. Причем, что самое интересное, даже если ставить оба ip , то иногда v6 пролетает первым, дает ошибку и все, v4 уже не используется, а пользователю вылетает ошибка dns
maksd_gt
19.06.2026 08:09Я считаю что одна из главных причин, почему не произойдет переход на ipv6 заключается в том, что тогда начнется рассвет p2p сетей. Сейчас они не развиваются из-за отсутствие у подавляющего большинства белого адреса.
P2p сети массового распространения - страшный сон регуляторов и силовиков всех стран. Правительства будут саботировать v6 бесконечно пока рынок не порешает.
Ну и финансово невыгодно бизнесу его внедрять.
Arsch_des_Prasidenten
19.06.2026 08:09Проброс IPv4 соединений за NAT давно существует и работает, p2p клиенты всяких торрентов и т.п. живут и здравствуют
nixtonixto
19.06.2026 08:09Р2Р и сейчас прекрасно живут - есть Р2Р мессенджеры, файлохранилища, даже целые сети типа I2P. Просто из-за недостатков Р2Р и децентрализованности (скорость, нагрузка на батарею устройства, доступность контента) они проигрывают clearnet'у. Поэтому с переходом на IPv6 в этом плане не изменится ничего - кто привык общаться в условном Телеграмме, тот в нём и продолжит общаться.
BabrHabr
19.06.2026 08:09Есть уже переход на ipv6 в некоторых странах 80 процентов пользователей. Прекрати бредить
Wesha
19.06.2026 08:09Вот как банки, с которыми я работаю, начнут поддерживать IPv6 — так и начну задумываться о переходе. А то пока что своими же лапками отрубить себе доступ к своим деньгам — то такое...
firegurafiku
19.06.2026 08:09так и начну задумываться о переходе
Так с вашей стороны всё уже давно готово к переходу: операционные системы на ваших устройствах много лет как поддерживают IPv6, и ваш домашний роутер, скорее всего, тоже. А вот у провайдеров домашнего и мобильного интернета с этим проблемы. Сколько ни задумывайтесь, инфраструктуру провайдера вы не исправите.
своими же лапками отрубить себе доступ к своим деньгам
Так никто не призывает отказываться от IPv4, не на текущем этапе. Сейчас скорее становится нормой ситуация, когда у вас есть и то, и другое одновременно. Когда у меня на компе появился IPv6 в дополнение к IPv4, с точки зрения пользовательского опыта ничего особо не изменилось, просто IPv6-only-сайты теперь тоже работают.
Wesha
19.06.2026 08:09Ну а я вот пришел к одной знакомой, у которой ынторнет поломался — у нее на машине не самая древняя винда, IPv6 поддерживает; провайдер тоже; а вот банк, в котором она банкуется (весьма крупный!) — нет, вот она и забила тревогу. Пришлось с боем уговорить провайдера вернуть ее на v4.
firegurafiku
19.06.2026 08:09Но в интернете миллиард сайтов не поддерживает IPv6 — вернее, игнорируют его существование. Чтобы получилось так, как вы описываете, банку нужно было прям постараться. Например, прописать в DNS некорректную AAAA-запись.
Wesha
19.06.2026 08:09Чтобы получилось так, как вы описываете, банку нужно было прям постараться. Например, прописать в DNS некорректную AAAA-запись.
Можете сами посмотреть, что у
chase.comв DNS записано.
JBFW
19.06.2026 08:09В некоторых случаях IPv6 очень удобен - чего стоят одни только link-local адреса (каждый, кто когда-нибудь настраивал десяток пар 192.168.Х.Х/30, оценит удобство).
Бездонные fd::/8 сети...Но - стоит вывести IPv6 в свою маленькую уютную локалку за NAT, которая всегда воспринималась как дачный участок за высоким забором, с вечно открытым сараем и незапертой машиной на парковке - и тут же оказываешься "посреди центральной площади, набитой туристами" - каждый ходит, смотрит, хочет потрогать, открыть какую-нибудь дверь...
uranik
19.06.2026 08:09ipv6 не взлетит в массы раз уже не взлетел, а времени прошло ого го, теперь жду IPv8 - концептуальный 64-битный интернет-протокол, предложенный в апреле 2026 года в качестве альтернативы протоколу IPv6. Его главная цель решить проблему нехватки адресов IPv4, сохранив при этом полную обратную совместимость
firegurafiku
19.06.2026 08:09ipv6 не взлетит в массы раз уже не взлетел
У меня от нынешней реальности другое ощущение — после долгого разгона IPv6, наконец-то, низенько летит. Почему я так думаю:
на магистральном уровне IPv6-трафик давно и прекрасно передаётся,
у всех хостеров и облачных провайдеров, с которыми я работал, есть IPv6,
во всех бытовых роутерах, которые я видел в последние годы, есть IPv6,
все современные ОС давно отлично работают в IPv6-сетях.
Через десять лет у всех пользователей будет дуалстек, а через двадцать IPv4 останется на правах почётного легаси. И провайдеры последней мили тоже подтянутся — их нынешнее сетевое железо рано или поздно будет заменено на новое, а нового железа без IPv6 они нигде не найдут на рынке, даже если будут искать.
теперь жду IPv8 - концептуальный 64-битный интернет-протокол
Хотите сказать, что это была не первоапрельская шутка? Не вижу никакого смысла всем броситься внедрять IPv8, который существует только лишь в виде текста RFC, вместо того, чтобы завершить переезд на IPv6, для которого:
все необходимые инфраструктурные протоколы давно адаптированы (например, OSPF умеет анонсировать IPv6-префиксы, а в DNS есть записи типа AAAA),
вся необходимая бюрократия давно работает (есть понятная процедура регистрации AS, присваивания префиксов, и т.д.),
и, наконец, для которого давно спроектировано и массово производится сетевое железо (любой роутер сгружает большую часть работы на специализированный кремний).
Undel
19.06.2026 08:09У моего провайдера (небольшого) v6 нет. Да что там... линки 100 мегабитные.
Яндекс.облако - в VPC нет поддержки v6.
alexkuzko
19.06.2026 08:09Немного словил себя на мысли о том, что я это уже читал. Лет десять назад. Что ещё немного и будет шестая версия всюду. А воз как был на месте, так и остался. Какие-то заигрывания для отдельных задач есть, а универсального, без компромиссов, варианта нет. Потому и внедрения нет... Когда он будет, я не знаю...
firegurafiku
19.06.2026 08:09А воз как был на месте, так и остался
Неправда, воз тронулся и медленно едет. Например, я сейчас заглянул в меню офисного МФУ — так вот, там есть поддержка IPv6. Была ли она там десять лет назад?
Anselm_nn
19.06.2026 08:09последнее, что нужно принтеру, это маршрутизируемый внешний ip
по логике ему и исходящие соединения лучше обрубить через нат, а то обновит прошивку и залочится или еще какую подляну замутит, а уж доступ извне... если сотрудникам требуется печатать на принтер не находясь с ним рядом, есть корпоративный впн
inkelyad
19.06.2026 08:09по логике ему и исходящие соединения лучше обрубить через нат
Или посадить на IPv6 LinkLocal, запретив ему получение маршрутизируемого адреса и ничего отрубать не потребуется. А объявлять о своем существовании оно будет через Zeroconf с товарищами.
IPv6 в таком использовании выглядит адекватнее IPv4 с серыми адресами. Потому что любая вещь с серым адресом без проблем лезет наружу, если не принимать мер (а кто их принимает?) А LinkLocal - уж точно изолирован.
alexkuzko
19.06.2026 08:09Так воз никуда не сдвинулся. Принтер это внутренний компонент. Речь про общую связность.
На пальцах - то что внутри своего контура еще можно как-то настроить, подпереть костылями. Но то что за пределами твоего влияния - это и есть тот самый воз, который скорее по кругу катается, чем движется.
Хорошие вещи я не отрицаю, но факты - упрямая штука. IPv6 only это на данный момент возможно только с сильнейшими компромиссами. Эдакий цифровой аскетизм, когда отказываешься от огромного пласта информации (что само по себе может быть как плохо, так и хорошо, но тут плюс на минус нельзя сокращать).
Heggi
19.06.2026 08:09Еще хватает хостеров где ipv6 либо нет вообще (Яндекс, привет!), либо адрес дают за деньги (firstvds, привет!).
BabrHabr
19.06.2026 08:09IPv6 уже взлетел. Уже почти 50 процентов пользуются в мировом масштабе
BugM
19.06.2026 08:09Его все еще меньше 10 процентов. И процент не растет.
Доделать совместимый и нормальный ipv8 гораздо перспективнее чем мучать это.
VMcS
19.06.2026 08:09Какая занимательная статистика. Правда в корне противоречит статистике Гугла, APNIC, RIPE и в частности суммарной статистике наших пиров. Вы дайте уж тогда статистику tier 1.
Будте любезны дать ссылку хотя бы на драфт IPv8 или изложите сравнение IPv8 c IPv6 и IPv4, и разьясните какие проблемы IPv8 решает эффективней IPv6 и каким образом.
BugM
19.06.2026 08:09Это статистика реального трафика. А не теоретической достижимости. Она у всех одинаковая.
Так недавно публиковали. Повырезать оттуда все глупости и сойдет. По сути надо решить ровно одну проблему: добавить один октет к ipv4 адресу. Все остальное должно быть только про совместимость и как с этим жить не ломая ничего.
VMcS
19.06.2026 08:09Это статистика трафика через IPX между сетями, в то время как провайдеры имеют прямые пиры с гуглом, акамаи, различными тьер-1, то есть ваша статистика их не учитывет вовсе. Ваша статистика лишь конкретный частный случай, не репрезентативный если говорить о доли ipv6 в общем трафике. Я могу судить об этой доле с другой стороны: по состоянию на начало этого года, суммарный публичный трафик AS5410 со всеми внешними пирами (приватные+ipx+tier1) : 6.56 Tbps IPv4, 9.34Tbps IPv6. То есть суммарный трафик ISP для IPv6 привышает трафик IPv4 не треть. В понедельник могу посмотреть состояние на сегодняшний день, но сомневаюсь что доля IPv6 за последние 6 месяцев уменьшилась.
Повырезать оттуда все глупости и сойдет. По сути надо решить ровно одну проблему: добавить один октет к ipv4 адресу. Все остальное должно быть только про совместимость и как с этим жить не ломая ничего.
Как, оказывается, все просто. Прям по классике. "Да что тут предлагать?.. А то пишут, пишут… Конгресс, немцы какие-то… Голова пухнет. Взять все, да и поделить..."
BugM
19.06.2026 08:09Конкретная AS не говорит вообще ни о чем. Там разное бывает. Крупный IX заметно показательнее.
Непросто. В совместимость надо вложить много сил. Это сложная задача которую надо решать. А вот фичи не нужны.
VMcS
19.06.2026 08:09Говорит. Тем более, что это AS второго по величине французского провайдера c 27M мобильных абонентов и 5М наземных. Если у вас есть статистика других провайдеров - давайте сравним/проанализируем.
Непросто. В совместимость надо вложить много сил. Это сложная задача которую надо решать. А вот фичи не нужны.
А зачем, если уже вложено столько сил в разработку IPv6? Начинать разработку другого протокола с той же самой целью и встретить те же самые трудности поддержки софтом и оборудованием, да еще сохранив все родовые травмы IPv4? Весьма альтернативно-одаренная идея. Спасибо, но нет.
NAI
19.06.2026 08:09Правда в корне противоречит статистике Гугла,
Статистику гугла же разбирали - это статистика по обращению к сервисам гугла. И она была бы релевантной если бы мы пользовались только гуглом. Но мир чуть больше - в нем есть яндексы, vk, habr и прочие рутубы.
Читаем мелкий шрифт https://www.google.com/intl/en/ipv6/statistics.html
We are continuously measuring the availability of IPv6 connectivity among Google users. The graph shows the percentage of users that access Google over IPv6.
Мы постоянно отслеживаем доступность подключения по протоколу IPv6 среди пользователей Google. На графике показана доля пользователей, обращающихся к сервисам Google через IPv6.
VMcS
19.06.2026 08:09Совершенно верно, потому я не ссылаюсь исключительно на Гугл, а на других игроков в том числе. Точно так же можно сказать, что Netflix и Akamai это исключительно видеоконтент, а пому не дает общей картины.
Собственно статистика по IPv6 traffic sharing публикуется редко кем, большинство приводимой статистики показывает IPv6 adoption. Было бы интересно прсмотреть на статистику других ISP, потому как это дает более репрезентативный срез суммарного трафика для совокупности конечных абонентов/потребителей.
NAI
19.06.2026 08:09Ну вот по идее девятка дает - Average: 4939 Gbps IPv6:Average: 66 Gbps
(тут конечно тоже можно докопаться до методики\региона), но мне кажется что статистика с точек обмена траффиком самая релевантная
VMcS
19.06.2026 08:09В России низкий уровень ipv6 adoption ( по разным оценкам от 3% до 30-40%), по сравнению с Штатами/Европой/Южной Америкой/Индией/Китаем (50%-90%)
https://stats.labs.apnic.net/ipv6/
https://www.aelius.com/njh/google-ipv6/
и вообще низкой популярности IPv6 внутри рунета.
IMHO наоборот, статистика на IXP не самая релевантная, так как самая большая часть трафика любого ISP приходится на прямые приватные линки, затем на IXP, затем на tier-1. Через IXP не идет (как правило) трафик на Гугл, Фейсбук, Амазон - а это очень весомая часть сегодняшнего мирового IPv6 трафика.
Наиболее репрезентативную точку зрения могут только сами ISP, суммируя статистику всего своего совокупного трафика.
lazarus_net
19.06.2026 08:09IP6 имеет фундаментальную проблему: адрес не юзер Френдли. Слишком длинный и сложный для задания/передачи. Надо было делать буквенно цифровой с автоматическим кодированием/декодированием. Тогда бы могло взлететь.
Хотя бы 32 буквы латинского алфавита могли бы использовать.
firegurafiku
19.06.2026 08:09адрес не юзер Френдли
Так и IPv4 тоже не юзер-френдли. Это подтвердит любой, кто когда-либо считал маску подсети с длиной префикса, не кратной четырём. Что может быть неудобнее, чем записывать префиксный двоичный адрес в десятичной форме?
Хотя бы 32 буквы латинского алфавита могли бы использовать
Так как считать биты пятёрками так же непривычно, как шестёрками, можно сразу Base64. Естественно, при этом в адресе получится “нецелое” количество букв (128 не делится ни на пять, ни на шесть). Не замечали, например, что ключи Wireguard всегда заканчиваются на паддинг (символ
=)?
NAI
19.06.2026 08:09Слишком длинный и сложный для задания/передачи
Ну во-первых никто не мешает вам использовать 2001:db8:85a3::192:168:10:025
во-вторых, в ipv6 можно развлекаться с 2001:db8:85a3::feed:dead:beef:cafe
trinxery
19.06.2026 08:09Не менее трёх юзеров упомянули чёртов IPv8 и не менее кучи юзеров их плюсанули. Хочется их всех спросить, читали ли они хоть что-то про IPv6 и IPv8, или они просто фанатично ненавидят всё, связанное с IPv6.
ReadOnlySadUser
19.06.2026 08:09Да никому не нужен IPv6. Всем нужен IPv4 с дополнительными адресами. Всё)
BabrHabr
19.06.2026 08:09IPv4 с дополнительными адресами это уже не IPv4 а новый протокол. Всё
ReadOnlySadUser
19.06.2026 08:09Ну, это конечно так, но есть разница) Дополнительный октет в адресе не вводит дополнительных видов адресов, не меняет логику работы ARP и DHCP. Оставляет широковещательнын адреса, фрагментацию пакетов и прочее.
Т.е. формально это новый протокол, но не надо ничего переделывать и все будет просто работать и настраиваться привычным образом. Да, IPv4 не идеален и имеет кучу проблем на уровне протокольной логики, но все эти проблемы так или иначе уже решены в оборудовании. Всё что нужно - это побольше октетов в адресе и всё.
Минимальные затраты на переобучение людей и перенастройку оборудования. Минимальные затраты на правку логики в прошивках. Минимальные изменения в UI интерфейсов. И, что главное, ноль новых уязвимостей из-за неверной конфигурации.
BabrHabr
19.06.2026 08:09Не будет работать. В DNS есть типы записи A и AAAA. Под твой новый формат типа записи нет. -> Переделывать ВЕСЬ СОФТ. Абсолютно весь не только NS сервера потому что у IP адресов ЕСТЬ ЖЕСТКИЙ ФОРМАТ. Затраты точно такие же как на внедрение IPv6. Толку ноль
ReadOnlySadUser
19.06.2026 08:09Ничего подобного. IPv6 фундаментально другой протокол. С другой логикой адресации, с другой логикой резолва имён и полученния адресов на интерфейсах.
Добавив поддержку новых DNS записей и увеличить размер адреса несравненно более простая задача, чем реализация и отладка нового способа общения с сетью
И надо ещё всех сетевиков мира научить IPv6. И домохозяек. И много кого. Научить полностью новой логике значительно сложнее, чем просто научить что в адресе теперь, ну, скажем, 6-8 октетов)
BabrHabr
19.06.2026 08:09Повторяю еще раз. Формат/размер адреса другой = переписать весь софт. Домохозяек ничему учить не надо ради IPv6 хватит выдумывать. Домохозяйки не знают что такое IP.
ReadOnlySadUser
19.06.2026 08:09Под домохозяйками я подразумеваю всех, кто хоть раз бытовой роутер настраивал.
Переписать весь софт для поддержки более широких адресов ЗНАЧИТЕЛЬНО проще, чем переписать весь софт для поддержки новой логики. Это очевидно.
Heggi
19.06.2026 08:09Ваше утверждение было бы верно, если бы ipv6 и ipv8 были бы на равных условиях (т.е. только в виде драфта rfc).
Но на текущий момент поддержка ipv6 уже есть во всех актуальных OS, библиотеках и практически всех приложений. Условному браузеру или игре, подключающейся по доменному имени к серверу, абсолютно побоку что там под капотом, ipv4 или ipv6.ReadOnlySadUser
19.06.2026 08:09Так, я нигде не говорю про IPv8. Я говорю об "IPv4 с более длинным адресом". Можно назвать это хоть IPv4.1.
IPv8 не нужен по той же причине, по которой не нужен IPv6 - он предоставляет фичи, о которых никто не просил и логику, которую никто не знает. Нужен просто IPv4 с более длинными адресами. Ни больше, ни меньше
Heggi
19.06.2026 08:09Вашего "IPv4 с более длинным адресом" даже в виде драфта rfc тогда не существует.
ReadOnlySadUser
19.06.2026 08:09Я вроде и не говорил, что существует. Но 100% наблюдаемых жалоб на IPv4 - это нехватка адресов.
Но вместо нормального и простого решения, происходит типичная разработка комитетом и появляются всякие IPv6 и IPv8
Undel
19.06.2026 08:09В корпоративных сетях IPv6 не появится, наверное, никогда.
1) Большинству компаний вполне достаточно серых диапазонов IPv4 за NAT. Миллиарды адресов там не нужны.
2) Нормальных фаерволлов и вообще средств защиты под v6 мизер.
3) NAT скрывает внутреннюю архитектуру сети
4) То самое легаси. Древняя бизнес-критичная система может быть написана несколько десятилетий назад. Ее модернизация будет золотой.
5) Такое же древнее железо. Условно терминал на складе, касса, счетчик в АСУТП, станок, принтер этикеток могут не поддерживать v6 и менять их ради этого никто не станет.
firegurafiku
19.06.2026 08:09В корпоративных сетях IPv6 не появится, наверное, никогда.
Если значимая часть, хотя бы одна десятая от общего количества сайтов и сервисов в интернете будет IPv6-only, ещё как появится, хотя бы на внешку.
Или представьте, что в какой-то момент возникнет некий ценный для людей сервис, который по каким-то своим техническим или политическим причинам работает только на IPv6. Если завтра OpenAI и Anthropic выключат у себя IPv4, послезавтра IPv6 появится во всех айтишных офисах.
Нормальных фаерволлов и вообще средств защиты под v6 мизер
Вы про аппаратные фаерволы? Увы, ничего не могу про них сказать. А программным фаерволам ничто принципиально не мешает. Как минимум, в линуксе
nftablesполноценно поддерживает IPv6 уже давно.NAT скрывает внутреннюю архитектуру сети
Теоретически, в IPv6 ничто не запрещает устроить трансляцию адресов с маскарадингом, но я не уверен, что такое поддерживается, например, в том же
nftables.Так-то да, это определённая утечка внутренней информации. Возможно, стоило бы как-то её прикрыть, но учитывая масштабы слежки на прикладном уровне, в вебе, не уверен, что стоит начинать решать проблему с сетевого.
Древняя бизнес-критичная система может быть написана несколько десятилетий назад
Никто, в общем-то, на текущем этапе и не призывает отказываться от IPv4. Сначала дуалстек, затем имитация IPv4 средствами IPv6 (см. IPv4-mapped IPv6 address), а там, может, древняя система уже и не нужна будет. Даже если система останется в строю, она будет дополнена слоем совместимости с новой реальностью. Думаю, все наслышаны про древний Коболе в американских банках, но волнует ли это кого-то за пределами этих банков?
терминал на складе, касса, счетчик в АСУТП, станок, принтер этикеток могут не поддерживать v6 и менять их ради этого никто не станет
Эти вещи и сейчас обычно работают в отдельном влане. Ну, останется в IPv6-сети кусочек IPv4, не страшно.
К моменту полного “взлёта” IPv6 они с большой вероятностью придут в негодность, перестанут поддерживаться производителем, морально устареют или просто потеряются.
Undel
19.06.2026 08:09Да, я про большие железные фаеволлы, особенно NGFW. nftables всякие хорошо, но вы их не поставите на канал 100Гбит. И вот в таких вот железках IPv6 часто есть лишь нономинально.
IDS/IPS аналогично.
Всякие flow анализаторы аномалий аналогично.
И т.д.
Что касается умирающих железок и новых систем... А в ТЗ на закупку будет ли требование IPv6? Если его нет в корповой сети, то купят то, что дешевле. И будет снова IPv4. Круг замкнулся.
inkelyad
19.06.2026 08:09Да, я про большие железные фаеволлы, особенно NGFW.
Как-то... подозрительный аргумент. Там же обычно говорится (на глаз - с аргументами, похожими правду), что в IPv6 легче потоки данных выделять, нужные заголовки искать и так далее. Потому что при проектировании IPv6 желания производителей аппаратных железок уже, вроде как, немного учитывали, чтобы эти чипы можно было удешевить.
Вот то что оно может быть за отдельную и дорогую лицензию - в это охотно верится.Undel
19.06.2026 08:09Оно легче для 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 или на локальный сервер эмуляции не сработает.
Вот так вот. А у вендоров поменьше все совсем плохо.
Revertis
19.06.2026 08:09В России уровень внедрения IPv6 составляет около 10%
А почему в статистике Google, на которую вы сами привели ссылку, написано 47%?
NAI
19.06.2026 08:09А почему в статистике Google, на которую вы сами привели ссылку, написано 47%?
Потому что читать мелкий шрифт надо:
Скрытый текст
We are continuously measuring the availability of IPv6 connectivity among Google users. The graph shows the percentage of users that access Google over IPv6.
Мы постоянно отслеживаем доступность подключения по протоколу IPv6 среди пользователей Google. На графике показана доля пользователей, обращающихся к сервисам Google через IPv6.
Рутуб\vk\яндекс\мейл\что-там у нас из крупного, поддерживает ipv6? Вот от того и 10%
Revertis
19.06.2026 08:09А, то есть это разная статистика. У 47% юзеров есть IPv6, но он есть только у 10% серверов.
NAI
19.06.2026 08:09Это статистика о том что у 47% юзеров гугла есть ipv6.
Есть еще пользователи которые не пользуются гуглом. Представьте (мыслительный эксперимент) выдуманную страну Кракожию, в которой забанены все сервисы гугла, нет ipv6, но она генерирует 50% всего мирового траффика (пусть там хостится p*nhub).
Нехитрой математикой за 3 класс общеобразовательной школы получим что реальное количество ipv6-траффика ~23%, а не 47.
BabrHabr
19.06.2026 08:09Как всегда набежала куча некомпетентных с рассказами про IPv8
IPv8 это скам. Никакой обратной совместимости там нет. Принципиально невозможно обеспечить обратную совместимость когда меняется формат/размерность адреса
BabrHabr
19.06.2026 08:09Пишу еще раз минусующим идиотам. Скам под названием IPv8 никакой обратной совместимости не обеспечивает
melodictsk
19.06.2026 08:09Я не видел железо, которые не поддерживают в6 уже лет 10. Все железо у провацдеров давным давно в6 рэди. Скорее не хватает компетенции у админов. У меня в мск на районе есть все крупные провайдеры и никто не даёт в6! Это просто позор. Приходиться городить туннель в НЕ. Есть один плюс от этого, ютуб работает без тормозов.
NAI
19.06.2026 08:09Я не видел железо, которые не поддерживают в6 уже лет 10.
А я вот пару дней назад ставил коммутатор с firmware от 2025 г. который не умеет в ipv6. АСУ ТП передает привет =)
aeder
19.06.2026 08:09Есть две причины, по которой внедрение ipv6 так и будет тормозиться.
IPv6 реально сложный. Человеку требуется тратить существенно больший мозговой ресурс (по сравнению с ipv4) чтобы разобраться в том, как это дело работает.
Реально человечеству нафиг не нужна адресация зиллионов устройств на планете. Любая информационная безопасность становится полным шлаком, если у вас холодильник, розетки, кондиционеры, пылесосы и так далее - все адресуемы снаружи и постоянно сидят в сети.
Да, в IPv6 тоже есть локальные адреса - но реально сети 10.0.0.0/24 более чем достаточно для любой организации (кроме 1-2, которые можно по пальцам пересчитать), а проблемы более высокой когнитивной сложности никуда не деваются.
Я давно работаю с промышленными сетями и информационной безопасностью - и для себя давно пришёл к выводу, что единственный способо более-менее обеспечить безопасность в промышленных сетях - это:
а) делать сети минимально-допустимого размера.
б) никакой маршрутизации между сетями, только прокси-шлюзы протокольного уровня.
Можно смотреть правде в глаза: если у вас есть даже всего сотня устройств в сети, обеспечить их постоянное обновление - и при этом не сломать функционал всей системы - это работа на полную занятость на несколько человек. Бизнес запросто внедрить "ещё тысячу этих модных датчиков", но никогда не будет платить за их актуальное обновление.
Плюс, срок поддержки для большинства устройств сейчас - 1-2 года. И никто их не будет менять до тех пор, пока физически не развалятся.
------------------
Проблема исчерпания адресов в IP4 - она вполне реальна. Но лучше всего её было бы решить простым расширением адресации до 6 или 8 байт, без существенной модификации протокола. Теперь, к сожалению, уже поздно - в IPv6 вложили слишком много ресурсов, чтобы от него отказаться.
iassasin
19.06.2026 08:09решить простым расширением адресации до 6 или 8 байт, без существенной модификации протокола
Пожалуйста, не вводите людей в заблуждение. Выше уже корректно заметили, что любое расширение размера адреса - это существенная модификация протокола, ведущая к переписыванию всего существующего софта в мире. Это совсем не просто и не лучше, чем ipv6, особенно сейчас.
EasyGame
Есть мнение что ipv8 внедрят раньше, чем все перейдут на v6. Обратная совместимость решает.
MoonArsenii
Оно вроде как НЕ обратно совместимо и абсолютно бестолково
BabrHabr
Скам под названием IPv8 никакой обратной совместимости не обеспечивает
geher
,