FSA 10 мар 2023 в 18:44

На что обратить внимание при переходе к IPv6

Простой

8 мин

16K

IPv6*

Обзор

Recovery Mode

+19

Комментарии 9

Cayp 10 мар 2023 в 19:15

netch80 10 мар 2023 в 21:15

Плюсанул за картинку, хоть это сейчас и борьба с ветряными мельницами. Увы, никто делать чуть разумнее (без устарелостей IP4, но и без перекосов IP6) уже не будет.

a_anistratenko 11 мар 2023 в 10:29

Актуальная продуманная технология!

Неделю назад сам перешел, через туннельного брокера He.

Да, надо преодолеть внутренне сопротивление, консерватизм и вникнуть.

none7 11 мар 2023 в 15:26

Как минимум в IPv6 есть Google, Yandex, Facebook. А гиганты на то и гиганты, что выдают трафика больше других. Я скорее слышал вариант «Все популярные сайты есть в IPv4 и IPv6 им не необходим. Вот когда будут популярные IPv6-only сайты, тогда и приходите». У сайтов вообще нет никаких причин внедрять IPv6, кроме телеметрии. А существование P2P трафика не интересует вообще никого. Если он Вам нужен, купите услугу «белый IP».

Драйвером роста IPv6 могут быть корпоративные сети. Так как там непересекающаяся адресация между офисами в разных городах и в сетях партнёров имеет какую-то ценность. Ещё ценность мог бы иметь мобильный IPv6 для обеспечения бесшовных переходов между сетями, но он внедряется как-то совсем тухло.

nickpetrovsky 12 мар 2023 в 14:29

Мой энтузиазм с ipv6 давно угас и перешёл в практические рельсы (я не имею отношения к сетям, терминология может быть некорректна). Объективно он мало что даёт для обывателя кроме некоторых относительно редких случаев. И на практике можно найти компромиссное решение в ipv4. Из того что не было указано в статье, ipv6-only корпоративные сети (MS, Meta etc.) используют именно его по причине недостатка локальных адресов с учётом адресных пространств на контейнеры. То есть у них была практическая проблема и они её решали. Мобильные операторы северной Америки пошли по тому же пути и на самом деле у них ipv6-only с подобием 464xlat, как я понимаю у этого решения тоже была вполне практическая потребность. То есть если вы запустите дома ipv6-only сеть с 464xlat скорее всего разницы на мобильных устройствах вы не заметите вообще.

Поделюсь своим практическим опытом использования ipv6, тут, в Беларуси, есть закон который обязал всех провайдеров его поддерживать, и они его поддержали, правда большинство за отдельную плату. Из положительных моментов я бы отметил вот что: все которыми я пользовался выдают префикс /56 (некоторые даже статический), очень грамотно и полезно если есть в планах сегментировать сеть на vlan (их получится аж 256 по /64). Какая практическая польза, попробую описать реальные +\- конкретно в моём случае:

Выше автор писал о том что якобы это помогает всяким сервисам видео связи, спорное утверждение, так как любой нормальный файрволл настроен на блокировку всех входящих соединений если не разрешено иное, каких-то "лучших практик" для FaceTime или webrtc именно для ipv6 я не нашёл, так что relay сервера избежать это не даёт. (пользы около 0)
Якобы отсутствие NAT всё ускорит, возможно речь идёт скорее о клиентском оборудовании. Из заметного иногда связь с некоторыми европейскими датацентрами стала быстрее на 10-12 Мбит (но иногда и наоборот), возможно связано с тем что трафик движется по отличным от ipv4 линиям связи. (+\-)
ipv6 дал возможность описать конкретные правила для файрвола с префиксами в известных мне сетях и подключаться с планшета к домашнему ssh и rdp (tcp+udp) без vpn, и не светит порт на весь интернет. Удобно и работает крайне надежно даже на мобильной связи. Гипотетически энергопотребление будет меньше из-за отсутствия дополнительного шифрования. Можно было и не описывать строгие правила, так как затраты на пинг одной /64 подсети исчисляется гигабайтами. Условным плюсом можно считать отсутствие необходимости менять стандартный порт, в некоторых мобильных приложениях это имеет смысл. Однако можно настроить мобильный профиль для IPSec и не знать проблем с доступом к локальным ресурсам :) (+, гибкость в пробросе сервисов в интернет и их "условно" бОльшая безопасность)
для того чтобы нормально настроить докер контейнеры в разных комбинациях с сетью в ipv6 придётся использовать vlan и свитч который их поддерживает для отдельного префикса, и как я понял если нет возможности отдавать для докера меньшую подсеть чем /64 все становится в разы сложнее (но вроде как возможно). И весь трафик между сегментами /64 даже в локальной сети будет ходить через маршрутизатор. Так же нет полной ясности как это делать если префикс от оператора только динамический. (-, относительная сложность корректной конфигурации, если выдаваемая подсеть провайдером >= /64 все становится в разы сложнее)
наличие глобального ipv6 адреса != доступу к интернету, камеры и устройства iot могут остаться в жесткой изоляции в отдельном vlan, однако есть возможности вынести видеорегистратор в другую локацию не делая дополнительных туннелей, в критический момент можно подключиться к ним напрямую поменяв правила фаервола (+)
сложность конфигурации роутера, некоторые провайдеры отдают ipv6 по pppoe и после переподключения соединения в Linux на основе Debian/Ubuntu systemd не выполняется обновление конфигурации dhcpcd и клиенты теряют свои адреса. Это известная проблема, возможно уже исправили.
Если у DNS записи есть DNSSEC и нет корректной записи для ipv6, то 464xlat работать не будет или нужно выключать его проверку полностью. (-, редкий случай, как и DNSSEC в целом :) )
Между двумя сетями со статическими префиксами можно настроить защищенный туннель без оверхеда. (+, сам не использовал)

После интеграции ipv6 и интересного времени с его настройкой я пришёл к выводу что он нужен относительно редко и только для специфических потребностей, там раскрываются его сильные стороны. Решение проблем с ним далеко не так очевидны и корректная конфигурация не так проста. Тут скорее желание быть ближе к прогрессу, для энтузиастов я бы рекомендовал сделать дома ipv6-only с 464xlat чтобы даже не иметь dual stack, это возможно будет полезно для разработчиков мобильных приложений ориентированных на страны где ipv6 правило а не исключение.

dartraiden 16 мар 2023 в 22:45

любой нормальный файрволл настроен на блокировку всех входящих соединений

Любая нормальная ОС уведомит пользователя о том, что приложение хочет открыть порт для входящих соединений. В этом плане поведение ничем не отличается от "белого" IPv4. Но, зато не требуется этот самый белый IP покупать, как щедро предложил один из комментаторов выше (чужие деньги тратить я так-то тоже горазд, а вот свои неохота).

Ещё плюс, что раз нет NAT — то отпадает нужда в UPnP, NAT-PMP, PCP и прочих костылях, которые добавляют уязвимостей. Ну, и ALG туда же.

FSA 18 мар 2023 в 15:32

Выше автор писал о том что якобы это помогает всяким сервисам видео связи, спорное утверждение, так как любой нормальный файрволл настроен на блокировку всех входящих соединений если не разрешено иное, каких-то "лучших практик" для FaceTime или webrtc именно для ipv6 я не нашёл, так что relay сервера избежать это не даёт. (пользы около 0)

Сквозная прозрачность сделает возможным прямые соединения для тех, у кого нормально настроен файервол, а значит часть трафика уже не будет лететь через промежуточные узлы с белыми IP, а значит и нагрузка на них снизится, что будет хорошо для тех, у кого файервол настроен криво и нужен промежуточный узел. Видео, между прочим, приличный потом трафика создаёт.

Якобы отсутствие NAT всё ускорит, возможно речь идёт скорее о клиентском оборудовании. Из заметного иногда связь с некоторыми европейскими датацентрами стала быстрее на 10-12 Мбит (но иногда и наоборот), возможно связано с тем что трафик движется по отличным от ipv4 линиям связи. (+\-)

В современных условиях NAT теперь есть даже у провайдеров, не говоря уже о клиентских маршрутизаторах, где без NAT никак. Любой NAT - это вмешательство в пакет IP. Его нужно переписывать по правилам, а это требует некоторого времени. Кроме этого, глобальная таблица маршрутизации IPv4 значительно распухла из-за того, что адресное пространство оказалась чрезвычайно сегментировано и маршруты не получается агрегировать. Никаких даже намёков на улучшение точно не предвидится. Есть RFC 1715 и RFC 3194 из которых понятно, что проблемы с этим начинаются значительно раньше, чем адресация исчерпается, а она уже исчерпана!!! Таблицы для IPv6 значительно меньше и при правильном распределении адресов с проблемой, подобно той, что сейчас IPv4 мы не встретимся ещё долго. Меньше таблицы - меньше нагрузки на маршрутизаторы. Увы, но это можно будет ощутить только после отказа от IPv4, потому что сейчас требуется держать в памяти жирные таблицы IPv4 и IPv6. И оба типа трафика требуют своего внимания.

для того чтобы нормально настроить докер контейнеры в разных комбинациях с сетью в ipv6 придётся использовать vlan и свитч который их поддерживает для отдельного префикса, и как я понял если нет возможности отдавать для докера меньшую подсеть чем /64 все становится в разы сложнее (но вроде как возможно). И весь трафик между сегментами /64 даже в локальной сети будет ходить через маршрутизатор.

А в чём проблема внутри докера продолжать использовать то, к чему привыкли и что у вас работает. Узлам снаружи вообще без разницы как там и что общается. Для них главное, чтобы сервис, к которому они обращаются, имел открытый порт в IPv6 адресации. Да хоть у себя в локалке используйте IPv4. Вопрос в глобальном переходе к IPv6.

наличие глобального ipv6 адреса != доступу к интернету, камеры и устройства iot могут остаться в жесткой изоляции в отдельном vlan, однако есть возможности вынести видеорегистратор в другую локацию не делая дополнительных туннелей, в критический момент можно подключиться к ним напрямую поменяв правила фаервола (+)

Это скорее вопросы к производителям железа. У них и в IPv4 не всё гладко, а если нужен доступ, то нужны дополнительные железки, чтобы его обезопасить. Меняем шило на мыло. Ничего по факту не меняется.

сложность конфигурации роутера, некоторые провайдеры отдают ipv6 по pppoe и после переподключения соединения в Linux на основе Debian/Ubuntu systemd не выполняется обновление конфигурации dhcpcd и клиенты теряют свои адреса. Это известная проблема, возможно уже исправили.

Тут ничего не могу сказать. У меня провайдер выдаёт IPv6. Проблем особо никаких нет, кроме их заботы о моей безопасности и блокировки входящих соединений. Ну и специфический маршрутизатор, который толком ничего с IPv6 не умеет, кроме как раздать одну сеть /64. Будут больше IPv6 использовать, будет и софт допиливаться.

Если у DNS записи есть DNSSEC и нет корректной записи для ipv6, то 464xlat работать не будет или нужно выключать его проверку полностью. (-, редкий случай, как и DNSSEC в целом :) )

Да. Есть проблема с DNSSEC. Но, благо, их исчезающе мало, потому что заморочиться DNSSEC, но при этом совсем не смотреть в сторону IPv6 как-то странно. Если сервисы сами используют IPv6, то с такой проблемой точно не столкнёшься. Но, да. Нужно проверять в каждом конкретном случае. Ну и проблема выплывает только если отказываешься от IPv4 у себя в сети, а не используешь дуалстэк.