IPv6 в стриминге и реальность dual-stack

Опубликовано: 2026-05-20 · Время чтения: 11 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 со статистикой Google IPv6 (март 2026: 50.10% на 28 марта), отчётом APNIC Labs по IPv6-capability (апрель 2026: 43.13%), Cloudflare Radar (апрель 2026: 40.1% HTTP-запросов), IETF RFC 8305 (Happy Eyeballs v2, декабрь 2017), draft-ietf-happy-happyeyeballs-v3 (в работе), RFC 6052 (синтез IPv6-адресов, октябрь 2010), RFC 6877 (464XLAT, апрель 2013), RFC 6147 (DNS64, апрель 2011) и RFC 8925 (опция DHCPv4 IPv6-Only-Preferred, октябрь 2020).

TL;DR

IPv6 в измерении Google впервые перешёл рубеж 50% – 28 марта 2026 года – и теперь колеблется в диапазоне 45–50% по миру. Франция держит 86%, Индия и Германия – выше 70%, основной мобильный трафик в США идёт натив-IPv6. Dual-stack в 2026 году – это пол, а не оптимизация: каждый URL обслуживается одновременно по IPv4 и IPv6, выбор пути отдан клиенту через Happy Eyeballs (RFC 8305), и значимая часть зрителей приходит из IPv6-only мобильных сетей через NAT64 + 464XLAT. Места, где dual-stack ломается, предсказуемы – старые smart TV, корпоративные прокси, которые срезают AAAA, IPv4-only WebRTC SFU и signed URL, привязанные к IP.

Зачем это понимать

Каждый продакт-менеджер, который запускает стриминг-продукт в 2026 году, рано или поздно ловит один и тот же разговор: «Почему на ноутбуке работает, а на телевизоре клиента – нет?» или «Почему французского трафика меньше, чем обещает рынок?» Ответ обычно тот же: где-то в цепочке доставки IPv6 поддержан наполовину. CDN отдаёт обе семьи, но origin слушает только IPv4; signed-URL нормализуется в IPv4-форму, и IPv6-клиент получает 403; WebRTC SFU объявляет только IPv4 ICE-кандидатов, и мобильный зритель из IPv6-only сети не соединяется. Каждая поломка по отдельности не катастрофа, но вместе они – это разница между потоком, который «работает на большинстве сетей», и потоком, который шипится на весь мир.

Что изменилось в 2026 году – цифры, на которые стоит смотреть

Главная цифра – 50.10% IPv6-capability, измеренная пользовательским пробником Google на 28 марта 2026 года, первый день, когда глобальное среднее перешло паритет (Google IPv6 Statistics, март 2026). Линия не закрепилась выше 50%, но веха пересобрала планировочный базис: продукт 2026 года, который рассматривает IPv6 как меньшинство, неверно калибрует свою аудиторию.

Три измерения дают одну и ту же картину. APNIC Labs – пробники через рекламные теги – намерили 43.13% глобальной IPv6-capability в апреле 2026 года. Cloudflare Radar – HTTP-запросы, наблюдаемые на edge Cloudflare – зафиксировал 40.1% по IPv6 в апреле 2026 года. Методологии расходятся примерно на 10 пунктов, потому что считают разные вещи, но порядок величины тот же: четыре-пять из каждых десяти запросов к современному стриминг-эндпойнту приходят по IPv6.

Региональное распределение неравномерно, и эта неравномерность важнее глобального среднего. Франция – 86% IPv6-capability в феврале 2026. Индия – около 72%, Германия – 71%, Вьетнам и Бельгия – около 60%, США – около 53%. Стриминг-продукт, чей длинный хвост зрителей концентрируется в любой из этих стран с высоким IPv6, увидит >70% трафика через IPv6, даже когда глобальный средний показатель ближе к 45%. Рынки калибруются под себя, не под мировое среднее.

Второй сдвиг 2026 года – мобильные операторские сети переходят в IPv6-only. Крупные операторы США (T-Mobile, Verizon, AT&T) держат IPv6-only на мобильном data-path с 2014–2016 годов, но мобильный трафик стал доминирующим в стриминге так, как не был на момент первоначального переключения. На таких сетях устройство получает только IPv6-адрес; IPv4-only назначение достигается через NAT64 на стороне оператора и 464XLAT на устройстве (RFC 6877, апрель 2013) – для HTTP-стриминга это работает, но для WebRTC и любого протокола, который вшивает IPv4-литерал в payload, остаётся источником тонких сбоев.

Нажмите, чтобы увеличить

Dual-stack – что это реально значит в стриминговом pipeline

Dual-stack хост работает параллельно по IPv4 и IPv6: слушает на обоих и разговаривает с любой семьёй. В стриминге dual-stack живёт на четырёх слоях, и включить нужно каждый – цепочка ломается по самому слабому звену.

Слой 1 – DNS. Авторитетный DNS-сервер публикует запись A (IPv4) и запись AAAA (IPv6) для каждого хоста, который резолвит плеер: origin, CDN edge, сигналинг, TURN. Отсутствие AAAA – самый частый dual-stack-промах; без них плеер выбирает IPv4 просто потому, что IPv6 ему никто не объявил.

Слой 2 – CDN edge. Каждый крупный CDN (Cloudflare, Akamai, Fastly, CloudFront, Bunny, Google Cloud CDN) обслуживает dual-stack по умолчанию, но property всё равно должен быть включён. Edge разговаривает с клиентом по той семье, которая выиграла гонку Happy Eyeballs.

Слой 3 – origin pull. Подтягивание CDN из origin – отдельный выбор. CloudFront, Cloudflare и Fastly поддерживают IPv6-to-origin; много кастомных origin до сих пор слушают только IPv4 и заставляют CDN ходить через лишний IPv4 NAT-маппинг. Если CDN поддерживает – включайте IPv6 на origin pull.

Слой 4 – WebRTC ICE candidates. Каждый WebRTC media-сервер (mediasoup, Janus, LiveKit, SFU на Pion) обязан объявлять и IPv4-, и IPv6-host-кандидаты в SDP, плюс IPv6-reflexive-кандидатов от dual-stack STUN-сервера. Без этого IPv6-only мобильный клиент идёт через NAT64 оператора, чтобы добраться до SFU – а UDP поверх NAT64 в зависимости от оператора падает в 5–15% случаев.

Happy Eyeballs – алгоритм, который прячет беспорядок

Когда dual-stack клиент подключается к dual-stack серверу, он запускает Happy Eyeballs – алгоритм, стандартизированный в RFC 8305 (декабрь 2017, версия 2) и сейчас обновляемый как draft-ietf-happy-happyeyeballs-v3.

Механика в одном абзаце. Клиент параллельно резолвит AAAA и A, стартует IPv6 TCP-попытку, как только пришёл IPv6-адрес, ждёт 250 мс (Happy Eyeballs Delay), затем параллельно запускает IPv4-попытку. Какой handshake завершится первым – тот и выиграл; проигравший отменяется. 250 мс – достаточно мало, чтобы быть незаметным на рабочем IPv6, и достаточно много, чтобы замаскировать медленный путь. Современные браузеры, curl, Node.js, Python asyncio, Go-пакет net и большинство нативных мобильных стеков шипятся с этим по умолчанию.

Практическое следствие успокаивает: между IPv4 и IPv6 за клиента не выбираете вы – клиент выбирает сам, идёт по более быстрому пути и тихо переключается, если одна семья сломана. Ваша задача – чтобы обе семьи реально работали. Битые AAAA-записи, заблэкхоленные IPv6-маршруты или IPv6-сервера, которые тихо роняют пакеты, обходят Happy Eyeballs так, что в дашбордах это всплывает как «странные медленные загрузки».

Нажмите, чтобы увеличить

Где IPv6 реально ломается в 2026 году

Четыре класса сбоев продолжают повторяться.

Старые smart TV. Roku включил ограниченную поддержку IPv6 в RokuOS 12.0.0-4178 (середина 2024), но раскатка неровная. Прошивки Samsung Tizen на протяжении нескольких поколений шипятся с выключенным IPv6 по умолчанию; OSN+ публикует документированный workaround, в котором зрителю предлагается отключить IPv6 на телевизоре, чтобы починить буферизацию. Vidaa и старые webOS ведут себя аналогично. Держите IPv4-пути first-class неопределённо долго для аудитории на TV.

Корпоративные сети и прокси. Многие энтерпрайз-сети деплоят исходящие HTTP-прокси, которые срезают AAAA или слушают только IPv4. Устройство по Happy Eyeballs пробует IPv6 первым, попадает в чёрную дыру, после 250 мс откатывается на IPv4 – каждое соединение платит штраф, видимый в startup-time low-latency live-стрима.

Signed URL и IP-bound токены. Token-системы, которые биндятся на IP клиента, должны одинаково обрабатывать 203.0.113.42 и 2001:db8::42. Типичный баг: бинд на ту семью, через которую прилетел auth, а потом 403, когда запрос плеера в CDN приходит через другую семью. Биндитесь к сессии, не к IP; или нормализуйте до префикса /64 для IPv6 и /24 для IPv4.

WebRTC на IPv6-only мобильных. IPv4-only media-сервер заставляет IPv6-only клиентов идти через carrier NAT64; UDP-on-NAT64 падает в 5–15% случаев в зависимости от оператора. Сделайте dual-stack SFU и STUN/TURN, перечислите обе семьи в каждом candidate pool.

Математика вслух. Возьмём стриминговый продукт с миллионом ежемесячных зрителей, тяжёлым по Индии, где ~30% трафика приходит из IPv6-only мобильных сетей. С IPv4-only SFU и 10% NAT64 failure rate: 1 000 000 × 30% × 10% = 30 000 неуспешных сессий в месяц. Dual-stack SFU возвращает их все ценой одного конфигурационного изменения.

Типичные ошибки

Ошибка 1: считать, что «CDN обслуживает IPv6» – этого достаточно. CDN – самая лёгкая часть. Origin, сервис signed-URL, TURN, DNS-авторитет и аналитический эндпойнт – всем нужны AAAA-записи и dual-stack-сокеты. Прогоните dig AAAA по каждому хосту в сетевом waterfall плеера, прежде чем называть IPv6 готовым.

Ошибка 2: тестировать IPv6 только из офисной сети. В офисе IPv6 скорее всего чистый; сети ваших зрителей варьируются дико. Используйте публичный IPv6-пробник (Test-IPv6.com, ISC checker или синтетический монитор) минимум из четырёх географий, совпадающих с вашим трафиком.

Ошибка 3: хардкод IPv4-литералов в манифесты, ad tag'и или beacon-URL. Манифест, в который вшит http://203.0.113.42/segment-001.ts, обходит Happy Eyeballs – клиент не может попробовать IPv6, потому что URL его не спрашивал. Всегда используйте хостнеймы. Та же ловушка живёт в VAST-ответах от старых ad-серверов.

Ошибка 4: забыть про data-channel-путь для WebRTC. WebRTC-медиа – это UDP, оно проходит NAT64 криво; data-каналы – это SCTP-over-DTLS-over-UDP, проходят ещё хуже. Dual-stack SFU убирает класс ошибок целиком.

Ошибка 5: отключить IPv6 на серверах, потому что «он глючит». Соблазнительный фикс, который тихо роняет вашу IPv6-аудиторию. Найдите причину, поправьте конфиг – не ампутируйте адресную семью.

Где сюда вписывается Фора Софт

Фора Софт с 2005 года строит видеостриминг, WebRTC, конференцсвязь, OTT, телемедицину, e-learning, видеонаблюдение и AR/VR – 239+ выпущенных проектов. IPv6-готовность – это тип работы, которая никогда не светится в маркетинговом питче и всегда всплывает в operations review: dual-stack TURN-кластеры для телемедицинских клиентов, чья пациентская база сидит за мобильным NAT64; AAAA-aware DNS health-чеки для OTT-клиентов, входящих на IPv6-тяжёлые европейские рынки. Мы выпускаем продукты, в которых обе адресные семьи включены end-to-end и инструментированы по семьям отдельно – деградация на любом пути всплывает в дашборде, а не в письме от клиента.

Ключевые выводы

• IPv6 впервые в истории достиг 50% пользователей Google 28 марта 2026 года – IPv4-only больше не оборонимый дефолт.
• Распределение региональное: Франция 86%, Индия 72%, Германия 71%, США 53%; калибруйтесь по своей аудитории, не по глобальному среднему.
• Dual-stack живёт в DNS, на CDN edge, в origin pull и в WebRTC ICE candidates – все четыре слоя должны быть включены.
• Happy Eyeballs (RFC 8305) делает выбор адресной семьи за клиента за 250 мс; ваше дело – чтобы оба пути реально работали.
• Smart TV, корпоративные прокси, IP-bound токены и IPv4-only WebRTC SFU – места, где IPv6 всё ещё ломается.
• Держите IPv4 first-class неопределённо долго для TV-аудитории; IPv6-only-деплой для стриминга пока нежизнеспособен.

Что читать дальше

• TCP и UDP в стриминге: выбор, который делает каждый протокол – транспортные выборы, которые едут поверх IP.
• NAT, файерволы, STUN, TURN, ICE: как WebRTC реально доходит до телефона – почему dual-stack ICE-кандидаты важны на мобильных сетях.
• Реальность последней мили: мобильные, спутник, 5G, Wi-Fi 6/7 – сетевые условия, где IPv6 проявляется жёстче всего.