После разбора UDP-широковещания и разбиения на подсети в привычном мире IPv4 самое время обратиться к «слону в комнате» — протоколу IPv6. По задумке разработчиков он должен был не просто добавить IPv4 больше адресов, а фактически заново спроектировать протокол под футуристичный мир конца 1990-х и начала 2000-х.
IPv6 был представлен ещё в 1995 году, но так и не смог сколько-нибудь заметно вытеснить IPv4 — и это само по себе повод задуматься, насколько просто переключаться между двумя фундаментальными протоколами интернета. Если бы понадобилось перевести софт с IPv4 на IPv6, что изменилось бы в тех самых механизмах — UDP-широковещании и работе с подсетями?
Для обычного разработчика IPv6 знаком в основном по странным и трудно запоминающимся адресам, а также по множеству кривых реализаций в роутерах. Поэтому первое впечатление от перехода нередко оказывается настороженным.
Широковещание по-новому
В IPv4 UDP-широковещание сводилось либо к вычислению широковещательного адреса интерфейса по его подсети, либо к «лёгкому режиму» с локальным широковещательным адресом. В IPv6 ничего из этого попросту нет. Возникает вопрос: как одинокий UDP-пакет может спросить у всех в сети IPv6, видел ли кто-нибудь нужный сетевой сервис?
Структура multicast-адреса в IPv6
Простой ответ таков: в IPv6 есть специальная link-local multicast-группа по адресу ff02::1, которая работает практически как IP-широковещание. Это аналог мультикаста на адрес 224.0.0.1 в IPv4, так что технически ничего нового здесь нет — просто в IPv4 мультикаст необязателен.
Хотя мультикаст в IPv4 вроде бы поддерживается повсеместно, показательно, что функция «мультикаст всем» на практике почти не встречается. Возможно, это делает мультикаст в IPv4 темой для отдельного разбора — там своя банка червей.
Если взглянуть на это с чуть более философской технической стороны, то трактовать широковещание как частный случай мультикаста вполне логично. Вместо того чтобы выделять подмножество узлов сети, мы просто выбираем вариант «все». По-своему это просто и элегантно.
Дела с подсетями
Если подсети IPv4 — благодатная тема, способная развлекать сисадмина днями напролёт и легко ломающая софт разработчика, который до этого блаженно не подозревал о существовании масок мельче /24, то создатели IPv6 посмотрели на этот источник веселья и решили, что им такого не надо.
В IPv6 у вас одна подсеть, и это /64 — и придётся полюбить все её 2⁶⁴ возможных адресов. Поскольку это примерно в четыре миллиарда раз больше адресного пространства, чем у IPv4, аргумент в пользу того, что подсети становятся не нужны, звучит убедительно.
Разумеется, пока авторы RFC для IPv6 радовались всем этим изменениям, среди сисадминов ходит полушутка, что это худшее, что случалось с ними со времён IPv4.
Стандарт лишь с 2017 года
Ещё один, чуть меньший «слон в комнате» — RFC 8200. Именно тогда, в 2017 году, набор RFC по IPv6 получил уровень зрелости Internet Standard, из-за чего некоторые задались вопросом, был ли вообще оправдан весь предшествующий напор с переходом на IPv6.
Путь стандартов IPv6 к уровню Internet Standard
Это лишь одна из многих претензий, которые сетевики предъявляют к IPv6. Например, известен разбор 2020 года, главная мысль которого в том, что вместо «IPv4 с 64-битным адресным пространством и сглаженными шероховатостями» протокол оброс множеством деталей и сложностей, о которых никто не просил, и обзавёлся новыми недостатками, которых легко было избежать.
Неприятность в том, что выделение адресов IPv4 в интернете практически везде закончилось. Это значит, что вам либо повезло сохранить IPv4-адрес, либо приходится доплачивать хостеру, либо ваше подключение оказывается только на IPv6, а IPv4 прячется за CG-NAT (carrier-grade NAT), который ломает большинство IPv4-специфичных приложений.
Переход с IPv4 на IPv6 тоже болезнен: прямой совместимости между протоколами нет. Предполагается, что IPv6 будет «инкапсулировать» пакеты IPv4 при двойном сетевом стеке на оборудовании. К сожалению, это же означает, что в интернете теперь сосуществуют IPv4-only сегмент, IPv6-only подмножество и узлы с поддержкой IPv4/v6, у которых dual-stack может быть реализован криво.
Очевидно, это мало кому помогает, и есть весомый аргумент, что для локальных сетей IPv4 — это всё, что действительно нужно.
Транслятор NPTv6 соединяет внутреннюю и внешнюю сети
Взгляд со стороны обнаружения сервисов
Идея заменить путаницу с широковещательными адресами IPv4 простым мультикастом хороша, и её вполне стоит опробовать в самом IPv4. Отказ от подсетей — приятное упрощение. А вот сама концепция обнаружения сервисов с IPv6 становится немного странной.
Во-первых, IPv6 не использует NAT, и без немаршрутизируемого (non-routable) префикса ваша локальная сеть не будет «приватной» в привычном по IPv4 NAT смысле. К счастью, IPv6 умеет NPT — по сути тот же NAT, но с префиксами вместо адресов, так что «совсем другое дело».
С маршрутизируемыми префиксами IPv6 можно было бы вести обнаружение сервисов в глобальном адресном пространстве, но это явно нежелательно. Поскольку обнаружение сервисов обычно нужно лишь для устройств в локальной сети, использование IPv6 здесь выглядит как минимум спорно, а в худшем случае — как уязвимость.
В итоге, как бы ни был хорош IPv6 в отдельных аспектах, при взгляде на весь пакет решений хочется, чтобы это был просто IPv4 с большим адресным пространством и обязательными функциями вроде мультикаста. На практике, например, для библиотеки обнаружения сервисов NyanSD пока нет причин использовать UDP-широковещание в стиле IPv6 — даже несмотря на то, что библиотека уже получает IPv6-адрес найденного сервиса.
Не исключено, что этот скепсис окажется ошибкой, и через несколько лет все мы будем сидеть на IPv6-only в локальных сетях — в идеале с глобально маршрутизируемыми адресами, словно вернулись в интернет 1990-х, когда компьютеры включали прямо в модем без всякого NAT.
