IPv6 — это другой интернет

В прошлом посте я обещал написать про IPv6. Возвращаюсь.

Главное, что хочу донести: IPv6 — это не IPv4, в котором адреса стали длиннее. Это другая сеть с другой моделью работы (другой интернет)

Далее без маркетинг буллшита про «340 ундециллионов адресов»

Дело не в размере адресов

Все статьи про IPv6 начинают с того, что 32 бита это 4 миллиарда, а 128 бит — это много. Это правда, но это следствие, а не причина. Причина в том, что весь дизайн IPv6 строился вокруг идеи end-to-end: каждое устройство снова имеет настоящий публичный адрес, как было в раннем интернете до того, как NAT всех «спас».

NAT — это пожарный костыль конца 90-х. Он работает, но цена известна:

• сессии стейтфулные на устройстве, через которое ходит трафик
• p2p-протоколы ломаются, и приходится изобретать STUN/TURN/ICE
• логирование «кто что делал» становится квестом, потому что 50 человек сидят за одним адресом
• провайдеры ставят CGNAT, и теперь у вас NAT внутри NAT

В IPv6 этого нет по дизайну. Ваш ноутбук, телефон, чайник — у каждого свой глобальный адрес. Звучит страшно с точки зрения безопасности, но никто не предлагает выкидывать фаервол. Просто фильтрация и трансляция — это разные функции, и в IPv6 они снова разделены, как и должно быть.

Аналогия: IPv4 + NAT — это многоквартирный дом, где у всего здания один уличный адрес и консьерж записывает в журнал, кому какая посылка. IPv6 — это улица из частных домов, у каждого свой адрес. Фаервол на двери никуда не делся, но почтальону больше не нужен консьерж-переводчик.

Железо и софт

TL;DR

Когда я говорю "другой интернет", это не только про модель. IPv6 — это другой протокол, и его должна понимать каждая железка и каждая программа на пути пакета.

Если лень читать, можете скипнуть этот раздел, дальше тоже самое, только глубже и разбор по уровням, что меняется, а что нет.

Физически все тоже самое

Кабели, оптика, SFP-модули, эзернет-свитчи второго уровня, Wi-Fi точки — всё то же. IPv6-пакет ходит по тому же ethernet-фрейму, что и IPv4, отличается только поле EtherType (0x86DD вместо 0x0800). С точки зрения коммутатора это просто другой тип пейлоада, ему всё равно. Если у вас L2-инфраструктура — переделывать там ничего не надо.

L3 (маршрутизация) — нужна поддержка в железе

Вот тут начинается самое интересное. Современные маршрутизаторы и L3-свитчи форвардят пакеты не процессором, а специализированными чипами (ASIC, NPU). Эти чипы должны уметь парсить IPv6-заголовок, делать lookup по 128-битному адресу в TCAM, обрабатывать NDP. Если железка старая или дешёвая — IPv6 у неё может быть реализован только в software path. То есть формально работает, но пакеты идут через CPU роутера, и производительность падает на порядки. На бумаге IPv6 поддерживается, на практике — линию вы не вытянете.

Та же история с extension headers (опциональные расширения IPv6-заголовка): многие железки не умеют обрабатывать их в hardware, и пакеты с ними отправляются в slow path или вообще дропаются. RFC 7872 прямо документирует, что некоторые транзитные сети роняют такие пакеты. Это известная боль IPv6, и одна из причин, почему extension headers используются осторожно.

При планировании IPv6 надо смотреть не «поддерживает ли устройство IPv6», а «поддерживает ли оно IPv6 в hardware и на какой производительности». В даташитах это часто отдельные строчки, и разница между ними принципиальная.

Фаерволы, IDS/IPS, балансировщики, VPN — отдельная история

Тут поддержка появлялась годами, и до сих пор бывают сюрпризы: фича работает в IPv4 и не работает (или работает иначе) в IPv6. Любой аудит включает отдельную проверку для каждого стека.

ОС — давно готовы

Linux, Windows, macOS, *BSD, iOS, Android — все мейнстримные системы имеют production-quality IPv6-стек уже больше десятилетия. На этом уровне вопросов нет.

Датацентры — синхронное движение всех слоев

Тут IPv6 буксует там, где казалось бы должен был выстрелить раньше всего. Сетевая фабрика (leaf-spine, BGP в underlay, оверлеи VXLAN/Geneve, EVPN) IPv6 умеет, но конфиг дублируется: address-family ipv4, address-family ipv6, два набора route-map, два набора ACL, и ошибка в одной из «половинок» означает, что часть трафика идёт не туда. Виртуализация и SDN (KVM, VMware, OVS, VPP) тоже умеют, но фичи догоняли постепенно — например, conntrack для IPv6 в OVS дозревал ощутимо позже, чем для IPv4. Kubernetes — отдельный сериал: dual-stack стал стабильным только в 1.23 (декабрь 2021), разные CNI (Calico, Cilium, Flannel) добавляли поддержку в своём темпе, kube-proxy iptables vs IPVS ведут себя по-разному. Если запускаете IPv6-only кластер — сюрпризы найдутся от ingress-контроллера до DNS в подах.

Облака — самый показательный парадокс

AWS с февраля 2024 года берёт $0.005/час за каждый публичный IPv4-адрес — около $43.80 в год за один (анонс AWS). На больших инсталляциях это сотни тысяч долларов. Сигнал прозрачный: переходите на IPv6. Но на практике до недавнего времени IPv6-only VPC было невозможно собрать без обходов: SSM Agent требовал IPv4 для связи с Systems Manager, EC2 Instance Connect не поддерживал IPv6 (починили только в октябре 2025), Auto Scaling Groups регистрировали инстансы только по instance-id, который резолвится только в IPv4, у NLB в dual-stack отваливался UDP. Corey Quinn из The Duckbill Group ведёт открытый список таких пробелов на GitHub, и он за 2024–2025 годы заметно сократился, но до полного парирования всё ещё далеко. Актуальный статус по каждому сервису AWS публикует в официальной таблице. У GCP и Azure похожая картина: IPv6 поддерживается, но всегда с оговорками «кроме этого, этого и этого сервиса».

Приложения — реальная боль

Это там, где живут зомби IPv4. Захардкоженные inet_aton() парсеры, поля в БД VARCHAR(15), регулярки на \d+\.\d+\.\d+\.\d+, конфиги мониторинга, шаблоны логов, форматы экспорта в CSV. Я сам видел системы, где IPv6-адрес ломал половину дашбордов, потому что разработчик 10 лет назад положился на формат xxx.xxx.xxx.xxx. Миграция на IPv6 в большой компании — это не сетевой проект, это аудит всех приложений, и вот это самая дорогая часть.

Так что да — это в прямом смысле другой интернет. На физике ничего менять не надо, но всё, что выше, должно понимать новый протокол. И именно поэтому переход растянулся на 25+ лет: дело не только в железе, и даже не только в ОС, а в десятках тысяч приложений, которые годами писались с допущением «адрес — это четыре числа через точку».

SLAAC: устройство само выбирает себе адрес

Это первое, что ломает шаблон. В IPv4 мир такой: либо ты статически вбиваешь адрес, либо DHCP-сервер тебе его выдаёт. Третьего нет.

В IPv6 есть SLAAC — Stateless Address Autoconfiguration. Маршрутизатор анонсит префикс сети (через RA — Router Advertisement), а устройство само генерирует себе адрес внутри этого префикса. Никакого централизованного сервера, никакой базы аренд. Если в сегменте появился новый хост — он сам себя сконфигурил и поехал.

Для админа это поначалу выглядит как «а где мой контроль». Но контроль никуда не делся, он просто переехал: вы управляете тем, что анонсит роутер. DHCPv6 тоже существует, и его используют там, где нужна централизация (например, в корпоративных сетях с привязкой адреса к учётке). Но базовый сценарий — SLAAC, и он действительно работает из коробки.

Один интерфейс — много адресов, и это нормально

В IPv4 у интерфейса один адрес. Если их два — это какая-то экзотика, alias, и обычно что-то странное.

В IPv6 у интерфейса штатно несколько адресов одновременно:

• link-local (fe80::/10) — есть всегда, для связи внутри сегмента
• глобальный unicast (2000::/3) — для выхода в интернет
• privacy address (RFC 4941) — временный, чтобы не светить MAC во внешний мир
• иногда ещё ULA (fc00::/7) — аналог приватных диапазонов

Когда впервые набираешь ip -6 addr и видишь четыре адреса на одном eth0, рука тянется их «почистить». Не надо. Они все нужны, у каждого своя роль. Source address selection (RFC 6724) разбирается, какой адрес использовать для какого трафика.

Практический момент: если вы привыкли в IPv4 закладываться на «один хост — один адрес», в логах и метриках, в IPv6 эта модель сломается. Лучше идентифицировать хост по чему-то другому.

ICMPv6 нельзя дропать

В IPv4 многие админы по привычке режут весь ICMP «на всякий случай». Это и в IPv4-то спорная практика (ломает PMTUD), но в IPv6 это просто выстрел в ногу. ICMPv6 — это не «пинги», это рабочий протокол, без которого сеть не функционирует:

• Neighbor Discovery (NDP) заменил ARP. Узнать MAC соседа — это ICMPv6
• Router Advertisement / Solicitation — это то, как работает SLAAC
• Path MTU Discovery в IPv6 обязателен, потому что роутеры не фрагментируют пакеты. Если пакет больше MTU — отправитель должен сам это узнать через ICMPv6 «Packet Too Big» и уменьшить размер
• DAD (Duplicate Address Detection) — проверка, что выбранный адрес никто уже не занял

Если зарезать ICMPv6 фаерволом — сеть встанет. RFC 4890 описывает, что можно резать, а что нельзя; коротко — почти всё нельзя. Это часто становится сюрпризом для команд, которые перетаскивают IPv4-правила «как было».

Broadcast больше нет

В IPv4 broadcast (255.255.255.255 или x.x.x.255) — это отправить всем в сегменте. ARP, DHCP — всё на нём. Проблема в том, что broadcast будит каждое устройство в сегменте, даже если ему этот трафик не нужен. На крупных L2-сегментах это превращается в шум.

В IPv6 broadcast просто отсутствует. Вместо него — multicast c хорошо определёнными группами:

• ff02::1 — все ноды в сегменте
• ff02::2 — все роутеры
• solicited-node multicast — конкретно для NDP, чтобы спросить «кто такой такой-то адрес» не дёргая всех подряд

Это та самая «другая модель»: мелочь, но влияет на то, как себя ведёт сеть под нагрузкой и как её надо проектировать.

/64 — это атомарная единица

В IPv4 размер подсети — гибкий, от /30 до /8 в зависимости от задачи. В IPv6 принято: подсеть = /64, точка. Не /96, не /80, не «давайте сэкономим адреса».

Почему: SLAAC и куча других механизмов завязаны на 64-битный interface identifier. Урезали префикс — сломали SLAAC. Адресов в /64 столько (2^64), что экономить их на одном сегменте не имеет смысла.

Сначала это выглядит абсурдно — «давать домашнему пользователю /56 (256 подсетей по /64)?». Но именно так и делается. Потому что у пользователя дома уже не один сегмент: основной Wi-Fi, гостевой, IoT-сегмент, лаба. И каждый получает своё /64, а не дерётся за адреса.

Dual stack — то, что выглядит просто, пока не запустишь

На практике никто не переходит на IPv6 одним днём. Все живут в dual stack — IPv4 и IPv6 параллельно на одном интерфейсе. И вот тут начинаются интересные нюансы.

Когда клиент резолвит домен и получает и A (IPv4), и AAAA (IPv6) записи — какой использовать? Ответ: Happy Eyeballs (RFC 8305). Клиент пробует оба, и идёт по тому, что ответил быстрее. Звучит просто, но если ваш IPv6-путь сломан или работает медленнее, пользователь этого не заметит — Happy Eyeballs молча уйдёт на IPv4. И вы будете годами думать, что у вас IPv6 работает, потому что AAAA-записи на месте, а на самом деле трафик идёт по v4.

Из практики: первое, что надо настроить при включении IPv6 — мониторинг по обоим стекам отдельно. Иначе деградация v6 будет невидимой.

Второй момент — приложения. Многие до сих пор пишутся так, что socket() создаётся под AF_INET, и про AF_INET6 никто не думал. На Linux есть IPV6_V6ONLY, и есть IPv4-mapped IPv6-адреса (::ffff:1.2.3.4), которые позволяют одним сокетом обрабатывать оба. Но в коде это часто становится сюрпризом.

Третий — логи и аналитика. Если ваша система логирования режет поле под IP в 15 символов — поздравляю, вы только что потеряли все IPv6-адреса. Прошёл это лично.

Где мы сейчас по цифрам

Самый цитируемый источник — статистика Google по доле пользователей, заходящих на их сервисы по IPv6. 28 марта 2026 года эта доля впервые превысила 50% — 50,1% против 46,33% годом ранее (отчёт The Register, блог Internet Society Pulse). То есть в среднем по миру IPv6 уже не «новая технология», это половина трафика на крупнейших сайтах планеты.

По странам разброс большой. По данным Google и Internet Society на начало 2026, лидеры — Франция, Индия, Германия и Саудовская Аравия с показателями выше 65–75% (по APNIC и более старым замерам Google — местами до 80%+). США в апреле 2025 — 47,6% по Google. Россия и СНГ — заметно меньше, в основном из-за инерции операторов.

Китай к сентябрю 2025 года отчитался о 865 миллионах активных IPv6-пользователей — 77% всех интернет-пользователей страны. Доля IPv6-трафика — 34% от общего, в мобильных сетях 69%, в фиксированных 31% (отчёт CAC через APNIC blog). С 2017 года рост почти в 300 раз — это не органика, это плановая программа на государственном уровне, и она работает.

Альтернативные источники дают чуть более скромные цифры — Cloudflare Radar показывает около 40% HTTP-запросов по IPv6, APNIC видит 43% сетей IPv6-capable. Google смотрит на пользователей (clients-capable), Cloudflare — на запросы, APNIC — на сети, поэтому числа и расходятся. Но направление одно и то же: IPv6 становится мажоритарным протоколом, не заменив IPv4, а сосуществуя с ним.

Параллельно процесс идёт и снизу: облачные провайдеры всё агрессивнее берут деньги за IPv4-адреса. У AWS это $0.005/час, или ~$43.80/год за один публичный v4. У Hetzner и большинства хостеров — отдельная плата за дополнительные IPv4 при бесплатном IPv6. На больших инсталляциях это становится статьёй расходов, и IPv6-only начинает иметь экономический смысл.

Что насчёт IPv8

В прошлом посте я упоминал драфт IPv8 — draft-thain-ipv8-00. Если открыть его, сразу видно, что это работа одного автора (Jamie Thain, One Limited), и она пытается переизобрести вообще всё: DHCP8, DNS8, WHOIS8, ARP8, ICMPv8, OSPF8, IS-IS8, BGP8, SNMPv8, и даже WiFi8. Каждый пакет должен валидироваться через OAuth2 JWT-токен, маршрутизация выдаётся по ASN — то есть каждому держателю ASN полагается ровно 2^32 адресов.

Это не наследник IPv6 и даже не конкурент. Это персональный proposal в виде Internet-Draft (любой может опубликовать — это не означает одобрения IETF), и относиться к нему стоит соответственно. IPv6 — это процесс на 25+ лет, в котором уже половина мирового трафика. Никакой IPv8 этого не отменит, и переход на «IPv4 является собственным подмножеством IPv8» — это не решение проблемы, это её консервация.

Что забрать с собой

Если коротко, что меняется в голове при переходе на IPv6:

• адрес — это не дефицитный ресурс, проектируйте без жадности
• хост — это не один адрес, а много
• ICMP — это не «пинги», это рабочий протокол
• broadcast умер, живёт multicast
• /64 — атомарная подсеть, не делите её
• dual stack — это две независимые сети, и обе нужно мониторить
• end-to-end снова работает, что меняет дизайн приложений (привет, p2p без STUN)

IPv6 — это не апгрейд IPv4. Это другая сеть (другой интернет), и её стоит изучать как отдельный протокол, а не как «то же самое, но с двоеточиями». Иначе вы будете годами писать v4-стайл код, который как-то работает в v6, пока однажды не сломается на проде так, что вы будете долго понимать почему.