Как стать автором
Обновить

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

Как мне кажется, это* может говорить о двух вещах:

  1. Стандарт IPv6 оказался неудачным. Как минимум, с точки зрения его распространения. Человеко-ориентированность тоже может вызывать вопросы.

  2. Производители железа с закрытыми прошивками тормозят развитие IT-индустрии.

*Покрытие в 30% за всё время - это ужасно мало. Сам я про этот протокол узнал точно больше 10 лет назад, когда ещё Windows XP SP3 была актуальна.

Железо и софт давно поддерживают ipv6. Уже 10 лет использую. Самое и сложное получить адреса конченым пользователям, приходится городить 6to4 или всякие vpn, т.к. домашние провайдера не спешат внедрять по причине отсутствия интереса, спецов, видимо соотношение затрат на выхлоп - никакое. Большинство внедрений ipv6 у нас это энтузиазм технарей из самих провайдеров, за что им спасибо.

Кстати Мегафон сейчас тестирует ipv6 на мобильной сети, проверяйте свои телефоны, возможно вы уже приобщились к ipv6. Если все будет ок, то в будущем доля ipv6 трафика в России заметно подрастёт.

Самое сложное это не сколько получить адреса, сколько понять (объяснить) что это дает конечному пользователю?

Мой провайдер уже пару лет выдает ipv6 и уже два года висит статус: "Мы тестируем технологию, пока бесплатно, но вот-вот сделаем за деньги...", причем они до сих пор не могут определиться с ценой. Ок, допустим. Включаем\настраиваем, и-и-и-и? не происходит ничего - интеренет дома не работает быстрее, качество связи такое же, резонный вопрос - зачем мне все это?

А между тем проблем прибавляется - каждая железка становится видна в интернетах. Т.е. на каждой железке по уму надо настраивать firewall. И, если с ПК еще +- можно заморочиться, то как быть с телевизорами, мобилками и прочим IoT? NAT неплохо помогал изолировать сеть при помощи одной железки(роутера) с дефолтными настройками.

*P.s. может я чего не знаю о ipv6? с радостью почитал бы о плюсах для конечного пользователя.

А зачем на каждой железке настраивать? Фаервола на доманшнем роутере вполне хватит.

Я целиком поддерживаю позицию, что NAT как был рожден костылем, так им и остался, и должен умереть. Но вот с фаерволами и IPv6 тоже есть косяки. Например, мой домашний случай: мне провайдер выдает префикс динамический (статику даже за деньги не дают), раз в пару дней он может и поменяться. Есть некоторые сервисы, которые я бы хотел, чтобы были доступны из интернета. При этом в правилах фаерволла можно прописывать только полные статические адреса, поэтому приходится мутить костыли-скрипты, которые переделывают правила на лету при получении нового префикса. В IPv4 такая ситуация бы решилась логичной связкой DynDNS + NAT, что было бы (имхо) меньшим костылем.

Ну тут как бы не в сложности настройки фаервола дело, а в том, что провайдер дурак. Динамические ipv6 разве что для сотовых абонентов годятся, где фаервол стоит на стороне оператора и все входящее по умолчанию блокирует. Но это тоже дичь, потому что адреса получаются не полнофункциональные.

Провайдер-то дурак, но всё же хотелось чтобы и девайсы тоже имели поддержку IPv6 не просто для галочки. Вот ещё вспомнил про косяк с этим динамическим префиксом — если он меняется, то не все девайсы (в частности винда) правильно понимают RA о том, что новый адрес должен быть в приоритете. В результате все исходящие соединения идут от старого адреса, который уже недоступен глобально, т.к. у провайдера или роутера такого маршрута уже нет.

Для сотовых операторов динамический /64 имеет смысл для агрегации маршрутов. А вот в чем смысл динамических префиксов и почему нельзя за абонентом прибить один префикс — не знаю.

Повторюсь, я не очень хорошо знаю ipv6 и может чего-то не понимаю, но:

  1. Мой маршрутизатор подключается к ISP и в client options IPv6 передает ID (мак с префиксом).

  2. По этому ID провайдер авторизирует, присваивает IPv6-адрес маршрутизатору как клиенту и выдает /64 подсеть.

  3. Остальные клиентские устройства, ломятся на DHCPv6 провайдера и благополучно забирают свои IPv6, т.е. DHCPv6 на моем маршрутизаторе отключен.

  4. На межсетевом экране (МЭ) маршрутизатора естественно можно создать общие правила уровня: исходящий - пущать, входящий ивалидный - дропать.

Примерно так это выглядит у скайнета. Теперь, т.к. DHCPv6 находится не у меня, то IPv6 устройства может измениться в любой момент (условно). Следовательно я не могу прописывать конкретные правила (открыть 80\443 порт на входящий только для этого IPv6). Сами понимаете - один ребут и тыква. Заблокировать доступ в интернет одному устройству, так же становится проблемой. Окей, можно открыть 80\443 порт для всех, но тогда на IoTe надо блокировать руками (сами понимаете такого функционала нет).

Можно сделать вывод, что основная проблема - внешний DHCPv6. Но, допустим, поднимаю свой, прописываю статические правила на МЭ и-и-и-и провайдер меняет пул. Снова все правила превращаются в тыкву.

Т.е. надо писать писать скрипты которые на МЭ, при смене пула переписывать все правила... такое себе удовольствие.

Ну на самом деле, из префикса /64 найти айпишник какой-то конкретной железки в 32 степени сложнее чем найти ваш ipv4 айпи во всём интернете. Так что закрывать для всех не так уж обязательно.

Секьюрити бай обскурити)

Эм... так как бы вектор угрозы не только шодан с ботнетом.

Я на своем ПК веду дев.разработку или использую какой-нибудь удобный сервис (веб-морду для торрент-клиента). Сейчас я могу не парится с паролями, аунтификацией и пр. Однако, стоит мне зайти с использованием IPv6 на какой-ндибудь ресурс (сомнительный, взломанный или еще какой) то тут же могу получить сканером. Прикольно, теперь надо настраивать 3 файрвола и апдейтить правила на них.

Вы можете разрешить DHCPv6 (или только ICMPv6, зависит от реализации) трафик от стыка с оператором в сторону локальной сети. Дай бог, левых DHCPv6 серверов не будет в сети оператора, если они контролируют этот момент.

НЛО прилетело и опубликовало эту надпись здесь

Мой провайдер, пока что тестирует IPv6 и предоставляет услугу бесплатно, но уже сейчас есть пометка о том что это временно, и услуга, после выхода в прод, будет стоить денег =)

Самое забавное, что сейчас они дают белый IPv4 бесплатно 8)

А зачем выпускать телевизор в интернет?

Вы получите IP6 и повесить его на роутере. А ваша домашняя ЛВС так и останется на ip4. Проблем то) У вас же нет ограничений в маршрутизации трафика с внешнего интерфейса роутора с ipv6 на внутренние интерфейсы в сети ipv4.

В мобильном МТС давно включил себе ipv6, в дом ру тоже в лк включается уже сколько лет. Так что всё есть, но смысла в домашней локалке для него не вижу.

Поддерживать то может и поддерживают но при этом:
ЭрТелеком выдает /64 домашним юзером (кладя на рекомендации RIPE про мин /56) и как тогда настраивать нормально локалку если надо несколько подсетей и дома не один компьютер? WiFi в бридж с проводной сетью и со всеми виртуалки и докером? Адреса динамические и могут слететь если не использовать долго(при том что для IPv4 есть услуга со статическим).reverse-DNS для зоны IPv6? А что это?(для IPv4-адреса услуга с reverse-DNS есть).
Но у ЭрТелекома оно хоть есть. В отличии от билайна.
Нормально (и с совсем чем надо) работает разве что туннель от HE но у них нет эндпоинтов в России и при тарифе в >100+ Мбит/с — получаются тормоза по IPv6 для например 4K Youtube
(Tunnelbroker.ru — нет reverse DNS)
У мобильных операторов — у МТС все хорошо. Вот только часть моих мобильных железок — на ТиньковМобайле (и мне он — нравится). Про IPv6 не слышно.


Как MultiWAN нормальный делать без IPv6 NAT не очень понятно. С хитрым балансингом да. (нет, я конечно понимаю что по хорошему тут /48 PI надо и анонсы. Мне как домашнему пользователю даже есть с чего это анонсить. Только вот ЭрТелеком с Билайном почему то -:) не хотят такое для домашнего пользователя поддерживать )
Но правда IPv6 NAT заявлен в RouterOS 7 которая уже в Stable.


Про поддержку софтом:
Win11, Android Emulator, HTTP Toolkit — наличие в сети IPv6 = не проходит тест соединения эмулятора с хостом. Что можно было так сломать?


Вот и стоит у меня IPv6 и нативный от ЭрТелекома и через he.net. Стоит настроенный и отключенный. Сделать виртуалку на хостинге поблизости на которую вытянуть несколько IPv4-адресов которые прокинуть домой + сделать дома reverse-proxy сложнее но меньше геммороя. И все работает.
:(

Мне кажется, проблема с таким долгим введением протокола связана с тем, что пока всё прекрасно работает. IPv4 заканчиваются, но это пока коснулось, как написано в статье, только крупных провайдеров. Острой необходимости в переходе на IPv6 пока нет. А всем пока хватает NAT и использования одного ip несколькими абонентами. А вот когда действительно не будет новых свободных адресов, все будут за сервисами или компаниями, тогда переход на v6 сильно ускорится.

Это начало касаться и простых пользователей облачных платформ. Тот же Hetzner начал хотеть денег за публичный IPv4

Для начала было бы неплохо построить единый Internet на IPv6. На сегодня единой связности нет. Tier 1 оператор Cogent, через которого подключено пол планеты, не хочет бесплатно возить traffic от Google и гиганта 4to6 — Hurricane Electric, а те не хотят платить, потому связности между ними нет вообще. Не то, чтоб на соседнюю улицу ходил traffic через Амстердам, а вообще нет никакой связности. Это — показатель реальной востребованости IPv6.

Hosting-площадки тормозят неимоверно. Так уж и быть, мы вам выделим аж /64, но не отдадим потому, что у вас доку́́ментов нет, вот вам 16 или 32 IPv6 адреса под расписку с записью каждого в панели управления, а то ходють тут!

Провайдер-независимый pool адресов? Вот вам quest на неделю и ежегодная оплата $250/150 за строчку в базе данных. Это к вопросу о
а большинство компаний до сих пор работает с IPv4

А что ж им не работать, если весь смысл IPv6 раскрывается полностью, только если работать с «белыми» адресами внутри сети! И что, менять внутреннюю адресацию при смене/добавлении ISP?

Пока что нехватку IPv4 ощутили лишь крупные интернет-провайдеры

Операторы, в особенности сотовые, выдали пользователям CGNAT-овский 100.0.0.0/8 и живут, не тужат. Зачем вам P2P, вы что — террорист? Пользуйтесь правильными централизованными ресурсами, через их сервера и общайтесь.

Один свет забрезжил — WebRTC и его использование видео-конферецсвязью. Но тут нет видимого пользователю эффекта. То, что сегодня Zoom/Teams не тормозили, потому что WebRTC связался напрямую через IPv6, это никому не понятно.
Поправка: Carrier-grade NAT address pool — 100.64.0.0/10.

Для начала было бы неплохо построить единый Internet на IPv6. На сегодня единой связности нет. Tier 1 оператор Cogent, через которого подключено пол планеты

А какой процент планеты не имеет иного подключения к миру, кроме как через Cogent? У ISP есть традиция подключаться ко всем, но канал покупать, только по фактической необходимости. Если меньше трафика будет ходить через Cogent, то и каналов у него купят меньше.

Hosting-площадки тормозят неимоверно

У них панели управления устаревшие, они по другому не могут… Если Вам действительно нужны триллионы адресов, то эмигрируйте на более современную площадку. Да, вероятно это выйдет дороже.

Провайдер-независимый pool адресов?

Крайне не желателен, если мы не хотим, чтобы в BGP появился триллион префиксов, а каждое перестроение таблиц маршрутизации занимало сутки.

И что, менять внутреннюю адресацию при смене/добавлении ISP?

Да, как приходится править DNS при смене адреса, так же придётся перенастраивать сеть. Но вообще по хорошему нужно производить настройку адресации, отталкиваясь от DHCPv6 prefix delegation, в том числе с подстройкой времени жизни адресов. IPv6 это про автоконфигурацию и если это не слишком частый случай, то эту автоконфигурацию придётся писать самому. Не всё же время админу в потолок плевать.

Пользуйтесь правильными централизованными ресурсами

И платить не забывай за их проксирование всей информации с их анализом и сливом всем заинтересованным лицам (не государству). К тоже же как показала практика перехода Skype с P2P на клиент-серверную архитектуру, обеспечение приличного качество транзитного трафика это слишком дорогое удовольствие.

А какой процент планеты не имеет иного подключения к миру, кроме как через Cogent?

В США — через одного, в Европе тоже встречаются. Это в пост-советских странах традиционно нет Tier 1, а «на Западе» в том и смысл — подключился к Tier 1 и больше ни о чём не думаешь.

У них панели управления устаревшие, они по другому не могут… Если Вам действительно нужны триллионы адресов, то эмигрируйте на более современную площадку. Да, вероятно это выйдет дороже.

Oracle Cloud достаточно современная? Ей от силы 5 лет вообще.
OVH — отсталые или дешёвые?
Триллионы может и не нужны, а вот автоматическая смена IP вполне себе рекомендована RFC7721.
И тут ведь главное — принцип. Если мы пообрубаем у IPv6 все преимущества, зачем он тогда вообще? И если для полноценного использования IPv6 нужно куда-то переходить, то не легче ли отказаться от IPv6?

Провайдер-независимый pool адресов?

Крайне не желателен, если мы не хотим, чтобы в BGP появился триллион префиксов, а каждое перестроение таблиц маршрутизации занимало сутки.

«Потребности в колбасе нет». Базовая функция IPv6 — «белые» адреса — «крайне нежелательна», так и запишем.

Да, как приходится править DNS при смене адреса, так же придётся перенастраивать сеть. [...]

Извините, я не буду это комментировать. Я про сеть масштаба предприятия (enterprise) говорил.
Oracle Cloud достаточно современная? Ей от силы 5 лет вообще.
OVH — отсталые или дешёвые?
Устаревший софт можно писать и в нынешнем году. Тот же Oracle начал внедрять IPv6 недавно и до сих пор работает не всё. Дают они кстати по /56.
Базовая функция IPv6 — «белые» адреса — «крайне нежелательна», так и запишем.
Динамические адреса, тоже «белые». На таком адресе можно открыть порт для приёма соединений откуда угодно, без костылей с не всегда работающим STUN и создания аналогов TCP over UDP. FTP, Torrent, прямое соединение в IRC, всё это будет работать через IPv6-адреса, даже если они конфигурируются автоматически и иногда меняются.
Извините, я не буду это комментировать. Я про сеть масштаба предприятия (enterprise) говорил.
А сути это и не меняет. IPv6-адреса должны перенастраиваться при переезде к другому провайдеру, так же как сайты перенастраивают DNS при переезде на другой сервер.

>IPv6-адреса должны перенастраиваться при переезде к другому провайдеру, так же как сайты перенастраивают DNS при переезде на другой сервер.

Извините, что вклиниваюсь в ваше обсуждение, но я правильно понимаю, что если есть два сетевых подключения: основное и резервное, то при переключении на резервное соединение от другого провайдера, необходимо всем устройствам менять IPv6-адреса, а при восстановлении основного соединения менять ещё раз? Причём всё это носит обязательный характер?

Я к тому, что в случае с NAT+IPv4 всё делается изначально сильно проще. Или я что-то неверно понял?

В случае бизнеса, резерв можно получить от того же провайдера, что и основной канал. В худшем случае можно протащить туннель через пиринг с другим провайдером, покупать при этом полноценный доступ в интернет у второго провайдера вовсе не обязательно, только линию по городу. Если возможности оформить такой резерв нет, то придётся вещать через radvd подсети с низким ttl и отключать вещание при отвалившимся интернете. Как только ttl истечёт хосты забудут свои основные адреса. Так же можно в этом случае добавить NPTv6, чтобы хотя бы http работал в это время. Но естественно все существующие подключения и подключения к адресам основного канала отвалятся. Это такой же костыль как и резерв NAT+IPv4.
P.S. Естественно рассчитывать стоит только на провайдера у которого у самого не одна нога.

>Это такой же костыль как и резерв NAT+IPv4.
Судя по вашему описанию, костыль с IPv6 несколько больше.

>В худшем случае можно…
Вы знаете, вот вариант NAT+IPv4 способен настроить начинающий, если речь о самом простом исполнении. А вот в реализацию описанного вами сценария - этим же человеком я не верю.

>В случае бизнеса, резерв можно получить от того же провайдера, что и основной канал.
Но это не защищает, в случае проблем у самого провайдера.

>P.S. Естественно рассчитывать стоит только на провайдера у которого у самого не одна нога.
От этого как раз и должно спасать резервное подключение от другого провайдера, а не надежда на лучшее.

Если резерв не может сохранить sip-звонок от президента к генералу во время боевых действий, то этот резерв и не резерв вовсе. Если человек не может его настроить, то ему стоит дать деньги тому, кто может. Любый сетевик способный сдать экзамены по CCNA способен настроить такой резерв. Если Вам хватает резерва через NAT, то можете выключить и включить роутер, оно само как-нибудь настроится.
Но это не защищает, в случае проблем у самого провайдера.
Если сеть провайдера сделана правильно, то любой обрыв будет замещён менее чем за секунду. Проблемы обычно бывают на последней миле, все остальные каналы закольцованы. А если нет, то не используйте такого провайдера неспособного дать хоть какие то гарантии даже внутри своей сети.
Дают они кстати по /56.

Поведение Oracle Cloud полностью соответствует моему первому комментарию. Это у них документировано.

А сути это и не меняет. IPv6-адреса должны перенастраиваться при переезде к другому провайдеру, так же как сайты перенастраивают DNS при переезде на другой сервер.

Вынужден с вами не согласиться. Аналогия с сайтом, извините, совсем неуместна. Если уж проводить аналогии с DNS, то на ум приходит недавняя всемирная смена корневых ключей DNSSEC, вот примерно тот масштаб, и то, последствия были не так значительны.
Крайне не желателен, если мы не хотим, чтобы в BGP появился триллион префиксов, а каждое перестроение таблиц маршрутизации занимало сутки.

Как тогда предлагается делать MultiWAN? С учетом что NAT в IPv6 официально тоже нету.

Как быть с софтом? Куча софта не воспринимает ipv6 адрес в принципе. 1с ная защита вообще глючит, если ipv6 включена на сервере свойствах подключения

А этому софту точно нужно внутрь ip заглядывать?

Ну вы ж платите за поддержку этой 1C? Вот пусть чинят.

Quake 3 в котором ipv6 есть с 2000 года.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий