Комментарии 48
Кто может внятно аргументировать зачем потребовалось 16 байт, если 8 байт обеспечивает 18 квинтиллионов 446 квадриллионов 744 триллиона 73 миллиарда 709 миллионов 551 тысяча 615 адресов. Если на Земле будет проживать 1 трлн. человек - то каждому достанется по 16 млн. личных IP-адресов. Мало?
Дело ведь не в том что байтов жалко (хотя и это тоже имеет значение, т.к. эти байты будут помножены на количество IP-пакетов). Просто 8 байт даже продиктовать легче - получается формат как у банковской краты - типа ffdd.ccbb.aa99.8877 - и короче и достаточно. Так зачем жадничать?
+64бита там только для того что бы клиенты могли прятаться в невообразимо большом пространстве. Каждому конечному устройству выдают /64 это типа аналог одного ипв4, и устройство регулярно меняет свой адрес внутри этого пространства что бы враги не нашли.
Предположу. А вдруг на одном пользовательском (или промышленном, переносном) устройстве IP будет забирать не само устройство, а каждый крутящийся на нём сервис? Как вариант.
Чтобы через 50-100 лет не переезжать на IPv7
На своем pet проекте я столкнулся c простой проблемой - как мне разместить 4-10 IPv6 адресов за приемлемые деньги, пусть даже сравнимые с IPv4. Амазон предлагает 2^64 адресов. Мне столько не нужно. Меньше выделять он не хочет.
Вторая проблема - она скорее ментальная. Раз я добавляю IPv6, значит я должен позаботиться чтобы сайт проекта был доступен и в IPv6 и в IPv4., Т.е. IPv4 никуда не уходит. И он у веб сайта - не реальный, а локальный, потому что он за NAT. А дальше надо чтобы NAT пропускал IPv6. Он не пропускает. Нужны правила обхода NAT и на входном трафике и на выходном. Думал попробовать с NAT64, который транслирует протоколы, а не только адреса. Но мне это очень не желательно, мне желательно видеть адрес с которого пришел клиент, а не нечто транслированное чем-то как-то. Вот и всё. Как мне при всём желании адоптить IPv6? Только если его будут выдавать мензурками, как в моем любительском проекте, и только если решится проблема как этот протокол будет гулять в прежде IPv4-only локальной сети. Разумеется, я в курсе NP и всех чудес с ICMPv6.
На своем pet проекте я столкнулся c простой проблемой - как мне разместить 4-10 IPv6 адресов за приемлемые деньги, пусть даже сравнимые с IPv4. Амазон предлагает 2^64 адресов
Потому что они не могут дать тебе условную первую /112 тебе, вторую /112 другому клиенту и так раздать всю /64 разным людям. Ведь для для той части интернета что следовала рекомендациям вы будете одним человеком. И чуть что в бан улетите все вместе.
Тогда какой смысл давать /112, если под клиента все равно резервируется больший префикс? Плюс не работает SLAAC с его автонастройкой. Да разве Амазон берет деньги за ipv6?
Меньше выделять он не хочет.
Правильно делает, зачем если от этого только проблемы?
Вторая проблема - она скорее ментальная. Раз я добавляю IPv6, значит я должен позаботиться чтобы сайт проекта был доступен и в IPv6 и в IPv4., Т.е. IPv4 никуда не уходит
Сайт? Это, конечно, мимо вопроса, но входит ли использование cloudflare в вашу модель угроз? Потому что они предоставляют бесплатно абсолютно шикарный сервис. В том числе реверс-прокси для веба, и публично доступный сайт (и даже в дуалстеке) можно развернуть находясь полностью за NAT, не имея публичного адреса
Но мне это очень не желательно, мне желательно видеть адрес с которого пришел клиент, а не нечто транслированное чем-то как-то.
cf это тоже позволяет
Только если его будут выдавать мензурками
Я не понимаю что это решает, как это помогает и чем это лучше /64 (/56 или даже /48)
Спасибо за комментарии
Да разве Амазон берет деньги за ipv6?
Хороший вопрос. Будет ли это /64 требовать больше денег - я помню сервис показал предупреждение, что additional charges may apply - это было достаточно давно, когда я только стартовал проект. Проверю как на сегодняшний момент обстоят дела - скажу. Они и за IPv4 не берут, но только если приходишь со своим. А на практике где ж мне его взять?
Правильно делает, зачем если от этого только проблемы?
Я же не говорю правильно это или нет. Я говорю что переход на IPv6 создает для меня проблемы и на этом примере как раз и иллюстрируется почему IPv6 не очень быстро принимается -- нужны переделки в проекте, которые будут уникальными для IPv6 и стоимость может вырасти, хотя это и не точно, но время точно сожрет.
Сайт? Это, конечно, мимо вопроса, но входит ли использование cloudflare в вашу модель угроз?
Спасибо за рекомендацию. К сожалению это уже поздно в рамках этого проекта, он в продукционной фазе и начинать всю инфраструктуру с нуля - я не готов. К тому же, CF, насколько я понимаю, - это не совсем облако. У меня довольно много сервисов AWS уже используется, начиная от автоматического подъема инфрастуруктуры и мониторинга, и будут еще больше.
Потому что они предоставляют бесплатно абсолютно шикарный сервис.
Проет не полностью вписывается в Free Tier ни в AWS ни в CF - у меня порядка террабайта данных. Никак. По абсолютному большинству остальных сервисов - всё в пределах бесплатного, конечно и так.
Это BYOIP, взять-то себе подсеть v4 не то чтобы сильно большая проблема, но это как раз будет стоить денег, причем неприятных.
нужны переделки в проекте, которые будут уникальными для IPv6
Это возможно
стоимость может вырасти
Некоторые хостеры пытаются его продавать, да, или вообще дают по-штучно. Я бы от таких бежал
К тому же, CF, насколько я понимаю, - это не совсем облако
Для начала мне следует понять что вы вкладываете в слово «облако». Если вы про хостинг виртуальных/выделенных машин - тогда это совсем не облако.
CF - это CDN, и продает услуги CDN. А также это хостинг для доменов и DNS, бонусом дает ещё и свой ревер-прокси (бесплатно для веба, и за деньги для другого трафика, хотя если через ваш сайт ходят большие объемы - могут попросить перейти на платный тариф и для веба), и куча других штук которые я замучаюсь перечислять. Он слишком разросся.
Проет не полностью вписывается в Free Tier ни в AWS ни в CF - у меня порядка террабайта данных.
Оу, читая это
На своем pet проекте
Я совсем не ожидал такого масштаба, тогда да, это неприятно платить уже в два места
Вторая проблема - она скорее ментальная.
Спросите у вашего хостера про IPv6. Есть большой шанс, что вам подскажут, как его включить безо всякого NAT. Сейчас тот же AWS в lightsail дает ipv4 и ipv6 сразу из коробки. Ничего не нужно настраивать.
Однако каких-либо намеков на экспоненциальный рост не наблюдается
Ожидать экспоненциальный рост могут только те, кто очень далеки от внедрения подобных вещей. 20 лет - это нормальный срок для внедрения низкоуровнего протокола во всем интернете. Не верите? Поищите информацию про внедрение TLS. Версия TLS 1.2 представлена в 2008. Предыдущим версиям поставили статус deprecated в 2021 году. А еще через пару лет стали пинками загонять всех на версии 1.2 и 1.3. И это до сих пор в процессе.
Краткая история внедрения TLS в одной картинке
А TLS, кстати, это еще полностью софтовый стандарт. С IPv6 все еще сложнее, потому что нужно, чтобы его поддерживало железо. То есть, всем провайдерам мира нужно поменять железо. А они прям так и спешат это сделать. Поэтому мы имеем очень медленную, линейную скорость. Скорость, примерно равную скорости закупки или обновления оборудования.
Есть еще и фактор необходимости. Сам по себе переход на IPv6, как самоцель, никому не нужен, поэтому про это просто никто не думал. Первый RFC на IPv6 появился в 1998. А поддержка DNS для него появилась только через 10 лет, в 2008. Вдумайтесь, 10 лет IP протокол жил без DNS. А вот с 2008 года на него стали обращать внимание. Как раз, когда задумались про исчерпание IPv4 адресов. И даже в этом случае, финальный RFC на IPv6 появился аж в 2017 году. Финальный RFC со статусом интернет стандарта появился почти через 20 лет. За это время успели обкатать протокол, набить шишки, написать и оптимизировать ПО. Вот как-то так это и происходит в масштабе всего мира.
Поэтому, я бы сказал, что это - отличная новость, если мы уже подходим к 50% внедрения. Как переходить быстрее? Любыми возможными способами. Просьбы, уговоры, угрозы и даже открытый шантаж - все сгодится в этом деле. Всех нужно просто пинать в сторону IPv6. Лучше всего, конечно, работает денежный фактор. Не зря Китай этому помогает на уровне правительства. Им дешевле инвестировать в IPv6, чем закупать IPv4.
Проблема в том, что все преимущества, которые изначально закладывались в IPv6 на практике преимуществами не оказались, так что единственное, что он реально решает - это проблему исчерпания IPv4-адресов. Но пока пытались внедрять IPv6, эту проблему уже научились решать более топорными методами, так что стимулов его внедрять не особо много.
Протокол разрабатывался в 90-х годах под реалии того времени, которые очень сильно изменились. 90% функциональности IPv6 сейчас - это абсолютно никому не нужное тухлое легаси. Вместо того, чтобы заниматься бессмысленным делом, нужно наверное уже подумать, что можно сделать вместо этого.
Но пока пытались внедрять IPv6, эту проблему уже научились решать более топорными методами
Это какими, простите?
На самом деле, исчерпание IPv4 адресов - это самая насущная проблема. От IPv6 сейчас нужно решить именно её. Это главная хотелка. Что там еще придумывают (отказаться от NAT, отказаться от DHCP, каждому устройству по IP адресу) - на все это можно забить. Где-то внедрят - хорошо. Нет - и фиг с ним.
Самая первая проблема IPv6 - работа сервиса на нескольких аплинках либо сценарий "замена IP адреса на роутере" (причин масса, даже банальный "резервный линк через мобильный интернет").
NAT в IPv6 считается моветоном, все устройства во внутренней сети должны иметь либо по несколько интерфейсов (для нескольких ап линков), либо при смене IP адреса (подсети /64) на роутере - быстро переделать адресацию всей внутренней сети.
А ещё балансировка каналов (при разных аплинках и исходящем трафикн) - в IPv4 это всё решается NAT'ом с балансировкой на роутере, а в IPv6 балансировкой должны одновременно все устройства в сети заниматься.
Конечно, все эти проблемы нивелируются наличием собственной AS и роутингом своей подсети через разные каналы. Но мне сложно представить выделение AS каждому пользователю домашней сети, который себе хочет резерв через мобилку. И не представляю процессы организации пиринга всех этих пользователей со всеми операторами.
Самая первая проблема IPv6 - работа сервиса на нескольких аплинках либо сценарий "замена IP адреса на роутере" (причин масса, даже банальный "резервный линк через мобильный интернет").
Мне казалось, что IPv6 никакой замены не предполагается? У сервиса просто изначально два адреса - из сети каждого аплинка? И у всех устройств в сети - тоже, в общем-то.
Мне казалось, что IPv6 никакой замены не предполагается? У сервиса просто изначально два адреса - из сети каждого аплинка? И у всех устройств в сети - тоже, в общем-то.
Именно так. Это и есть с моей точки зрения самая большая проблема IPv6. Вот несколько очень распространённых в наши дни сценариев для сотен тысяч пользователей:
Единственный интернет-провайдер, но есть "резерв" в виде мобильника. Если основной провайдер падает - пользователь вручную подключает резерв и все клиенты идут через резерв, при восстановлении основного - трафик автоматом уходит на основной (это поддерживается из коробки на многих домашних роутерах - начиная от древних D-Link, заканчивая современными Keenetic). В IPv6 при подключении мобильника потребуется "распространить" IP адреса второго провайдера и как-то объяснить, что надо переключиться на него (убрать адреса первого?)
Постоянно подключенный резерв, но канал с оплатой по трафику. Условия те же - переключение при недоступности основного канала. Получается, каждое устройство в сети должно знать про правила использования каналов и проверять доступность интернета через основной канал. Очень сложно.
Маршрутизация разных подсетей через разные каналы. Допустим, у нас есть VPN в второй офис (для домашней сети - VPN в квартиру родителей) и мы хотим во второй офис ходить через этот VPN. Или пусть это будет не VPN, а выделенный физический канал. Потенциально можно решить на уровне роутинга, НО если на удалённой точке IP адреса также динамически выдаются провайдерами, то мы не знаем что и как маршрутизировать. Заводить отдельную подсеть для офисов 1 и 2 и заводить на все устройства IP адреса "общей" подсети и "подсети интернета"? Можно, но как тогда решать вопросы маршрутизации?
Это уже скорее для мелких офисов, но и для домашних пользователей тоже бывает - балансировка каналов. Мы хотим половину клиентов отправлять через один канал, половину через другой. Клиентов обучить такому будет сложно. А если усложнить задачу - видео-контент (условные вк, ок, яндекс видео, всякие кинотеатры) отравляем через провайдера №1, а остальное - через провайдера №2. Получается, каждому устройству в сети нужно объяснить эти правила.
Сейчас в связке IPv4 + NAT все эти задачи решаются на маршрутизаторе, являющемся центральным узлом сети. Он принимает все решения, он проверяет доступность каналов, он выполняет переключения максимально прозрачно для клиентов.
В мире IPv6 все эти задачи внезапно ложатся на все устройства в сети. А это значит, что даже самый наитупейший IoT датчик температуры должен уметь определять падение основного канала и переключаться на резервный, но только в том случае, если устройствам класс "IoT" разрешено переключаться на резерв.
А это значит, что даже самый наитупейший IoT датчик температуры должен уметь определять падение основного канала и переключаться на резервный
Падение пусть определяет gateway сети, а датчик должен уметь получать свой новый публичный IPv6 по DHCPv6, и должен поддерживать NDP расширение ICMPv6, Т.е. да, я согласен, устройства будут должны делать больше телодвижений чем раньше при IPv4 single stack. Потребуется больше места для кода на прошивке.
В IPv6 при подключении мобильника потребуется "распространить" IP адреса второго провайдера и как-то объяснить, что надо переключиться на него (убрать адреса первого?)
Не надо распространять. Они просто сразу есть. Потому что второй провайдер тебе сетку (пусть /56) выделил на постоянной основе и ты ее у себя можешь использовать, даже если канал до провайдера не поднят. Но даже если не так - марштутизатор начинает транслировать RA и устройства быстренько получают адреса и маршруты.
Получается, каждое устройство в сети должно знать про правила использования каналов и проверять доступность интернета через основной канал. Очень сложно.
Через что будут ходить устройства - вроде тоже как через RA делается? Маршрутизаторы всем этим занимаются и шлют устройствам приоритеты - через что ходить.
НО если на удалённой точке IP адреса также динамически выдаются провайдерами, то мы не знаем что и как маршрутизировать.
IPv6. Какие динамические? Адреса выданы провайдерами и прибиты к клиенту. Да, на внешнем порту маршрутизатора может быть динамический адрес, но он никого кроме провайдера не интересует. Главное, чтобы он выданную сеть в нее маршрутизировал.
В мире IPv6 все эти задачи внезапно ложатся на все устройства в сети.
Которые должны понимать, что ему маршрутизатор говорит, да. И не больше.
Не надо распространять. Они просто сразу есть. Потому что второй провайдер тебе сетку (пусть /56) выделил на постоянной основе и ты ее у себя можешь использовать, даже если канал до провайдера не поднят.
Ого, тут интересно. Можете рассказать как?
Я представил простую модель - если дома пропадает интернет, то я подключаю свою мобилку и она становится резервным каналом. Если меня дома нет, но есть жена - она подключит свою мобилку. Потенциально это и ребёнок может сделать, но она этого делать не будет. Операторы у нас у всех разные.
Сейчас резервный канал подключается методом "подключить мобильник по USB к роутеру, на мобильнике поставить галочку <USB-модем>", дальше всё делает роутер.
Как в вашем случае нужно делать?
Предварительно "зарегистрировать" все мобильники на роутере, чтобы он всем устройствам раздал и запомнил свои подсети?
Но что если вот сейчас жена подключила свой мобильник как резерв дома, а я подключу свой мобильник как резерв в другом месте - получится, что связанности между домом и другим местом уже не будет, т.к. адреса пересекаются.
Через что будут ходить устройства - вроде тоже как через RA делается? Маршрутизаторы всем этим занимаются и шлют устройствам приоритеты - через что ходить.
Правильно ли я понимаю, что роутер должен рефлектить все маршруты на все клиенты? Да, у меня не совсем пользовательский сценарий, но сейчас на роутере висит пара сотен маршрутов - все эти маршруты будут отправляться сразу на все устройства?
Выглядит не очень жизнеспособно.
IPv6. Какие динамические? Адреса выданы провайдерами и прибиты к клиенту. Да, на внешнем порту маршрутизатора может быть динамический адрес, но он никого кроме провайдера не интересует.
А вот тут мега-интересно.
Я сталкивался с IPv6 пару раз и оба раза видел динамику - первый раз мне интернет-провайдер периодически менял подсети. Второй раз - МТС, у них выдаваемая IPv6 подсеть зависит от той точки, к которой ты подключен. Грубо говоря, адрес неизменен при нахождении в одном месте, но даже при поездке по городу твой адрес может меняться.
Так не должно быть?
Ну и в любом случае - при смене интернет-провайдера потребуется полный ренамберинг адресного пространства, т.к. подсеть IPv6 привязывается не к конечному устройству (моему роутеру), а к моей учётной записи у конкретного интернет-провайдера.
Как в вашем случае нужно делать?
По идее, в момент настройки каналов и сетей провайдер сообщит, какие они. Их придется прописать на внутреннем интерфейсе любо вручную либо разрешить автоматике.
Но что если вот сейчас жена подключила свой мобильник как резерв дома, а я подключу свой мобильник как резерв в другом месте - получится, что связанности между домом и другим местом уже не будет, т.к. адреса пересекаются.
Не очень понял сценария. У каждого договора должна быть сеть, которую роутер может внутрь раздавать. Адреса, соответственно, пересекаться не будут. А будет - в зависимости от того, какой мобильник подключен, "шли через меня, используя src адрес из такой-то сети".
Правильно ли я понимаю, что роутер должен рефлектить все маршруты на все клиенты?
Не обязательно. Там, если я правильно RFC понимаю, роутер может просто сказать 'предпочитай меня' или дефолт сейчас - такой-то адрес.
Так не должно быть?
Так - может быть. Но это и используемые адреса/сети не должны интересовать клиента. Ну вот вообще. Какой выдался, тот выдался.
Но на выданный адрес в момент подключения должна маршрутизироваться /56 или /48 подсеть, которая всегда одна и та же и которая клиенту известна. Адреса из которой он(его устройства) и используют для своих нужд. Включая "слушаем эту подсеть и эту подсеть" И это можно сделать - потому что IPv6 и подсетей много, на всех клиентов хватит.
То, что операторы таких сетей не дают и маршрутизации не делают - это от лени и нежелания этот самый IPv6 нормально делать.
Ну и в любом случае - при смене интернет-провайдера потребуется полный ренамберинг адресного пространства,
Ну это да. Правда, оно не страшно. Потому что сервисы по именам адресуются и резолвятся во все что-там-сейчас-на-интерфейсе-поставилось. У меня, скажем, вообще в link-local совершенно самостоятельно имена транслируются, по zeroconf протоколам.
Не очень понял сценария. У каждого договора должна быть сеть, которую роутер может внутрь раздавать
У меня есть роутер дома (подключен к провайдеру X), есть роутер в квартире родителей (подключен к провайдеру Y). В качестве резерва могут использоваться мобильники, подключается тот мобильник, чей владелец сейчас рядом с роутером.
Допустим, у моего мобильника есть сеть mobA, у жены - сеть mobB.
Свой мобильник в качестве резерва я могу подключить либо дома, либо в квартире у родителей (если я сейчас там) или вообще в гостях у друзей, если у них отвалился основной интернет.
То есть проблема в том, что "договор" у меня привязан к моему мобильниму телефону, который я могу подключить к разным роутерам.
Адреса, соответственно, пересекаться не будут. А будет - в зависимости от того, какой мобильник подключен, "шли через меня, используя src адрес из такой-то сети".
В этом сценарии нельзя заранее регистрировать адреса на все устройства.
Получается так - я подключаю к роутеру мобильник, мобильник анонсирует всем устройствам "появилась новая подсеть, всем срочно получить адреса из этой подсети и использовать их как рабочий линк".
Не обязательно. Там, если я правильно RFC понимаю, роутер может просто сказать 'предпочитай меня' или дефолт сейчас - такой-то адрес.
Обращу внимание - "для вот этих 100 маршрутов дефолт сейчас тут, для остальных - здесь".
То, что операторы таких сетей не дают и маршрутизации не делают - это от лени и нежелания этот самый IPv6 нормально делать.
А может дело не в лени, а в физической невозможности?
Вашу мысль я понимаю и полностью поддерживаю.
Я хочу на свой роутер завести статические адреса и больше не париться. Если у меня одновременно подключено 2 интернет-провайдерва и мобильник в качестве резерва - пусть они у моего роутера узнают мою подсеть и сами как-то маршрутизируют ... если я со своим роутером уехал в другую страну - путь сами как-то решают.
Звучит красиво, но утопия. Одна только Москва даст несколько миллионов глобальных маршрутов, а по всему миру мы легко получим пару миллиардов уникальных маршрутов по всему миру :(
Правда, оно не страшно. Потому что сервисы по именам адресуются и резолвятся во все что-там-сейчас-на-интерфейсе-поставилось. У меня, скажем, вообще в link-local совершенно самостоятельно имена транслируются, по zeroconf протоколам.
Любые проблемы можно решить, не спорю.
Когда я экспериментировал с IPv6 - меня это не особо-то и останавливало, всё решаемо. Да, много ручника, много сложностей, без NAT'а во многих случаях не обойтись, кое-где нужно ставить экспериментальные прошивки, т.к. в стабильной версии вообще ничего не работает. У меня сейчас дома BGP поднят и это меня нисколько не напрягает - трафик до нужных мне точек может проходить через разные линки в зависимости от доступности маршрутов. НО мне это интересно и можно считать хобби.
Основная проблема в том, что простому домашнему пользователю (и его провайдеру) нужно решение уровня "plug and play" - воткнул и всё заработало само. Сейчас же к этому P&P не готовы ни домашние роутеры ни провайдеры ни сама по себе инфраструктура IPv6 - этот протокол появлялся тогда, когда сегодняшних сценариев просто не существовало.
В итоге получается, что с точки зрения бизнеса весь этот IPv6 как пятая нога собаке. Сложно, дорого, увеличивает нагрузку на поддержку (не забываем, если у клиента что-то не работает и мы говорим "отвали, сам решай" - клиент сам решит методом "сменю провайдера на более адекватного"),... но не даёт каких-то заметных профитов.
Мой личный вывод - IPv6 классная штука для гиков или для крупных датацентров. Тут всё отлично.
Для обычных пользователей и сетей - такое себе.
Получается так - я подключаю к роутеру мобильник, мобильник анонсирует всем устройствам "появилась новая подсеть, всем срочно получить адреса из этой подсети и использовать их как рабочий линк".
Да.
Возникает проблема как устройства между собой общаться будут. В доме обычно много устройств которые общаются просто между собой через роутер. Это получается роутер должен как-то определить что у устройств новые адреса. А если сеть сложнее? Если есть связанные сети через ВПН? Адресация по айпи идёт лесом. Особенно если аварийные переключения на второго или вообще третьего провайдера. В норме поменять на входе только адреса на разрешенные и все работает. Что на ip6 делать?
А может дело не в лени, а в физической невозможности?
Ну да, их кривой биллинг собранный на соплях 15 лет назад не позволяет это сделать. А команды сверху переделать хорошо - все нет…
Вы не правы.
Работаю в индустрии где ipv6 нужен - телекоммуникация, японский мобильный оператор. Это очень важно - чтобы у каждого абонента был уникальный айпишник. У нас поэтому на работе правило, что всё должно быть ipv6-only.
Думаю IoT устройствам которые как на дрожжах растут сейчас ipv6 тоже очень важен. "Топорными" методами там ничего не решить.
Круть, насколько я понимаю кроме техногигантов именно мобильные операторы активнее внедряют v6.
А в случае iot-ятины - протокол matter требует поддержки внутри сети :) правда как я понимаю он будет работать и без GUA
S in IoT is for Security(C), напоминаю.
Если вы выставляете IoT-девайсы прямо в интернет, вы ССЗБ. А без этого им IPv6 не нужен вообще, у вас их должны быть вот прям миллионы, чтобы им это было надо хотя бы теоретически. Мобильным операторам - верю.
Мне кажется есть определённая мисконцепция про IPv6. Мол что если устройство имеет уникальный айпишник и не за NAT'ом, то оно спокойно долбится откуда угодно.
Но нет, файрволлы с IPv6 никто не отменял. То что у него теперь внутренний и внешний айпишник склеены в одну колбасу не то чтобы глобально что-то меняло.
Увы, но определять каждому девайсу, надо ли ему в интернет или нет - это удел энтузиастов-одиночек и матёрых админов компаний. Нормальный IoT вполне может смотреть в интернет. Просто нужно, чтобы у него был как минимум рандомный пароль и функция безусловного автоматического обновления с серверов компании строго подписанными патчами. Да, да, тут сейчас могут взвыть все гики, админы и мимопроходящие, но для массовых устройств для массового пользователя только так.
В России, Беларуси и Казахстане это значение держится на уровне 40%
Это все вместе? Если по РФ смотреть - то для клиентов раз-два и обчелся, а если даже начать рассматривать подробнее тех кто есть - у кого-то из них "в тестовом режиме" и "не для всех". А без клиентов исчезает смысл иметь его на серверах.
Непонятен смысл перехода на IPv6 для корпоративных сетей, например, которые в интернет смотрят одним-двумя аплинками, Exchange'ем и вебмордой RDP-шлюза. Там всё в рамках 172.17.0.0 и 10.0.0.0. Всем обычно хватает. И зачем им переходить на IPv6? Вот чтобы что?
Для корпоративного сектора действительно есть смысл только снаружи сервисам IPv6 выдавать "что бы быть в тренде", а вот вся внутрянка - ну очень сильно в NAT-е увязла...
Для крупных корпоративных сетей IPv6 как раз может быть оправдан - у них банально может заканчиваться внутренняя адресация (10.0.0.0/8 и другие) и переход на IPv6 решит эту проблему.
В то же время им и NAT для IPv6 понадобится, т.к. наружу выставлять свою сеть - самоубийство, в лучшем случае снаружи будут торчать только сервера в DMZ.
я пока не представляю такой сети, которой не хватило бы класса А, особенно с учётом, что она редко вся в одном месте.
Легко.
Давайте попроектируем - строим сеть, в которой будет 7 дата-центров (не обязательно своих, это могут быть и арендованные площадки, кое-где размера в одну стойку), разные зоны безопасности (как минимум INSIDE, DMZ), 15 крупных офисов по стране, нескольок десятков тысяч сотрудников, несколько сотен доп офисов по стране,... а начинать всё проектирование мы будем с активно растущей компании на 20 сотрудников и развитие будет продолжаться 15 лет.
В самом начале вы начинаете строить красиво по канонам cisco и juniper, выдавая на датацентры сразу по /12, потом начинаете дробить эти подсетки в соответствии с запросами, ... а через 5-7 лет уже получаете тихий ужас, в котором даже суммаризация маршрутов превращается в боль.
При проектировании с нуля с понятными планами развития действительно /8 хватит всем. А если у компании был момент взрывного роста, то все эти сети очень быстро заканчиваются.
В России, Беларуси и Казахстане это значение держится на уровне 40%
Автор пытается выдать желаемое за действительное. Реальное проникновение IPv6 в России менее 0,1%. IPv6 оказался очень и очень неудобен как для провайдеров, так и для потребителей (крупных корпоративных сетей), никаких проблем IPv6 не решает, но создается массу новых. Поверьте мне, глобально IPv6 не будет внедрен никогда, а вся статистика - натягивание совы на глобус.
Проблему нехватки IP адресов можно было бы решить простым расшириенет IPv4, там в заголовке предусмотрены опциональные поля в которых можно закодировать еще 32 бита адреса описывающего глобальный сегмент Интернета. По-умолчанию, глобальный сегмент с адресом 0.0.0.0 есть текущий интернет. Постепенно создаются новые сегменты внтури стран или корпораций. Всё существующее железо и софт будет прекрасно работать с таким расширением просто игнорируя новые сегменты глобальной сети. Будут некоторые сложности с рутингом в другие сегменты, но они постепенно разрешаться тунеллированием и заменой оборудования. Если не ошибаюсь, такой способ называется IPv7.
Проблему нехватки IP адресов можно было бы решить простым расшириенет IPv4, там в заголовке предусмотрены опциональные поля в которых можно закодировать еще 32 бита адреса описывающего глобальный сегмент Интернета
в каждом обсуждении IPv6 находится кто-то, предлагающий данное "простое" решение :) Нет, за счет заголовков IPv4 проблему решить нельзя, совместимости не будет. А если совместимость все равно исчезнет, то почему не сделать полностью новый стандарт? Этими рассуждениями, в том числе, и руководствовались разработчики IPv6.
Разработчики IPv6 руководствовались идеалистическими позывами сделать "лучший протокол". В итоге они наворотили такого, что никто его не хочет и не любит, потому что он ломает абсолютно всё! Расширить IPv4 без того, чтобы сломать совместимость можно, эту тему лет 20 назад уже обжевали и обсмаковали.
Расширить IPv4 без того, чтобы сломать совместимость можно
https://habr.com/ru/articles/773708/comments/#comment_26159414
перестраивать некоторые ИБ-решения
Это одна из важнейших причин, потому что они пока просто не знаю, как всё это контролировать, если каждое устройство получит в своё пользование целую подсеть и сможет беспрепятственно связываться с любым аналогичным устройством в любой точке Мира.
Представьте себе "локальную" сеть размером с интернет. Да это же просто кошмар для любого безопасника и непеханое поле для скрипт-кидди и прочих негодяев.
если каждое устройство получит в своё пользование целую подсеть и сможет беспрепятственно связываться с любым аналогичным устройством в любой точке Мира.
Эмм, устройство имеет 1 ip-адрес, мы это можем отслеживать? Если да, то какая, блин, разница с тем, что у устройства будет своя /64? Префикс-то всегда один и тот же, и отслеживать и фильтровать точно также, но подсетями
А что там за ip себе нагенерирует устройство - нас как-бы и не волнует. Но да, никто не хочет читать скучные rfc и рекомендации от RIR, а после внедрять в соответствии с прочитанным
я предполагал, что акцент будет поставлен на самом незначительном, даже вообще не значимом, из моего комментария.
давайте я перефразирую, чтоб у вас не было повода цепляться к словам. вот так: "...если каждое устройство получит возможность беспрепятственно связываться с любым аналогичным устройством в любой точке Мира."
а теперь представьте, что Вы - корпорация, в которой работает примерно миллион устройств и тысяч сто людей, которых Вы уже вот два десятка лет контролируете при помощи всевозможных шлюзов и NAT, а тут Вам говорят, что всё - хватит! и Вам становится очень грустно, но не потому, что Вы не умеете всё то же самое на IPv6, а потому что нет никакого смысла всё это переделывать.
т.е., выражаясь простым языком, Вам нужно будет снести все естественные препятствия и построить на их месте искусственные, чтоб Ваше стадо не разбежалось... но зачем?
это и был основной посыл моего комментария, а не то, о чём Вы подумали)
если каждое устройство получит возможность беспрепятственно связываться с любым аналогичным устройством в любой точке Мира."
У корпораций есть фаерволлы, и допустимо применение политики белых списков. Тогда о каком «беспрепятственно связываться с любым аналогичным устройством в любой точке Мира» идет речь?
Как строить сеть внутри корпорации - пусть решают сами, это их внутренняя боль. Хоть IPX пусть гоняют, им никто не запрещает продолжать внутри использовать ipv4 и nat
Лично мне как обычному пользователю ipv6 не сильно то и нужен, но я все равно решил проголосовать рублём и доплачиваю 5.5 BYN за ipv6.
Как идет миграция на IPv6 — мнения и версии