Комментарии 681
ipv6 тоже на долго не хватит, так как потребителям выделяются огромные подсети, вместо статичного адреса.
IPv6 создавался как раз с расчетом на это
У четвёрки 4 млрд адресов. У шестёрки 4 млдр раз можно выдать по 4 млдрд адресов каждому из 4 млрд пользователей. И все это можно повторить 4 млрд раз. Как будто должно хватить ну очень надолго
Как будто должно хватить ну очень надолго
говорили что бит не делим, но советские ученые...))
Что бит делим, придумал Клод Шеннон, а не советские ученые. Если вероятности 0 и 1 не равны, уже меньше бита. Простите уж за школьные уроки.
Простите, но это старый анекдот и шутка из 90х. По типу лампового микропроцессора. Классика
типу лампового микропроцессора
Ну, если учесть, что терминальный размер радиолампы лампы измеряется нанометрами, то в каждой шутке есть доля шутки. И да, такие лампы существуют в реальности. Поскольку у них расстояния меду электродами измеряется в диаметрах электронов, то быстродействие у них запредельное, а рабочие напряжения смешные. И да, там нет накала - хватает термоэмиссии при обычной температуре. Правда и токи анода соответствующие.
гуглите котельников, колмогоров, ляпунов
Это смотря какой бит. Гуглите про Сетунь, разработанный в СССР, там был трит. Вообще бинарный бит так популярен, потому что он помехозащищен (нужна большая энергия, чтобы исказить бинарный сигнал), а значит электронная схема проще.
Если 0 это 0 вольт, а 1 это +5в - в двоичной считаем что это помехозащищен.
Добавляем сюда минус 5в и третье состояние - вот и троичная система. И помехозащищенность никак не страдает. Разница только в сложности оборудования.
Так можно договориться, что 16 уровней в QLC-ячейке по помехозащищённости ничем не отличаются от 2 уровней SLC. "Разница только в сложности оборудования".
Чем больше уровней - тем сложней система и хуже помехозащищённость. 3 уровня хуже чем 2, 16 уровней хуже чем 8... Если 2 уровня можно декодировать простейшей схемой (есть напряжение или нет напряжения), то для троичной логики ещё нужно определять полярность напряжения, что в разы усложняет схемотехнику и собственно вбило гвозди в крышку гроба троичной системы. Многоуровневость есть смысл использовать только когда на весь чип небольшое количество блоков компараторов-декодеров (как в чипах памяти), но не когда всё АЛУ работает с многоуровневыми сигналами.
Видимо переключение между состояниями транзистора —затратная по энергии штука, и в миниатюризацию сложно по этой причине — нагревание, усложнение конструкции.
Чем больше уровней - тем сложней система и хуже помехозащищённость.
Не только. Ещё страдает и быстродействие. Если 0-2 вольт это логический 0, а 3-5 вольт это логическая 1, и промежуток 2-3 вольт разделяет их "ещё непонятно", то при возрастании с 1 вольта до 4 достаточно дождаться 3 вольт, и мы уже знаем что сигнал "1", несмотря на то что он продолжает изменяться (расти). Если же у нас есть промежуточные значения на 2, 3 и 4 вольтах - нам нужно ждать, когда сигнал перестанет изменяться в течении достаточно длительного времени, чтобы сделать правильный вывод о его истинном значении.
Только нельзя просто добавить «-5В», нет «удобных» элементов на которых можно строить такую логику в микроэлектронике.
Разница только в сложности оборудования.
Строить её на КМОП? Нафиг-нафиг таких кадавров
Понятно же, что 0 -- это не состояние, а оторванный контакт. Вот +5 и -5 -- это и есть настоящие 1 и 0 и истинная помехозащищенность! :-)
Понятно же, что 0 -- это не состояние, а оторванный контакт.
Железячники и эмбеддеры посылают вам лучи добра со щедрой порцией слабительного, а кто-то, вижу, уже и минус за камент подкинул. Потому что floating - который без подтяжки, это очень детская ошибка, тем более на хороших высокоомных емкостных входах (IGFET - слышали про такое?), но все же совершив ее, можете получить незабываемый опыт дебага того, в чем бага быть казалось бы не может решительно никак.
Вот +5 и -5 -- это и есть настоящие 1 и 0 и истинная помехозащищенность!
Лучше ±12V как в RS-232. И обязательно дифпарой. Тогда это реально работает, даже на значительно более слабых сигналах, в том числе и аналоговых (микромощные по сигналу микрофоны, например, подключают исключительно экранированой дифпарой - это называется balanced audio cable).
Если перед шуткой писать, что это шутка, будет еще менее смешно, чем если после нее поставить смайлик. Будет выглядеть, как будто я не уважаю аудиторию. А я уважаю. Большую ее часть, по крайней мере.
Вам же, знающему о хороших высокоомных емкостных входах, стыдно пенять незнакомым людям, что они пишут что-то, что не бьется в лоб с вашим знанием, да еще и посылать им лучи добра.
Тем более вы в своем последнем абзаце полностью подтвердили тезис из моего комментария, полностью раскрыв его идею.
А вы чего выделываетесь, прав он.
Дай человеку полевой транзистор, он сразу пойдет его использовать. Дай человеку теорию работы полевого транзистора и он придумает как использовать емкость затвора для полезных применений
Дай человеку высказаться и ты узнаешь, что он думает о тебе, о транзисторах и вообще у него дома жена некормленная. Нахрена эти транзисторы? На лампах делали и не жужали.
Вам же, знающему о хороших высокоомных емкостных входах, стыдно пенять незнакомым людям, что они пишут что-то, что не бьется в лоб с вашим знанием, да еще и посылать им лучи добра.
Я на вас не нападаю, а обрисовываю ситуацию - просто взгляд со стороны на лучи э... добра, идущие к вам с разных сторон. В ответ же нападаете на меня вы, как будто это я виноват в происходящем, и как будто я и есть источник этих, как мы их условились называть, лучей, и как будто это не ваше беспричинное нападение на меня, а чуть ли не самозащита. А я-то всего лишь мимо крокодил.
Тем более вы в своем последнем абзаце полностью подтвердили тезис из моего комментария, полностью раскрыв его идею.
Ну так у нас же вроде техническая дискуссия. Если мне нравится ваша идея, поцчему бы мне ее не развить и не дополнить? Любое, в чем вы правы, встречает во мне позитивный отклик. Если же вы находитесь в состоянии вражды со мной, то вам, наверное, и впрямь удивительно, как это я могу с вами согласиться, но дело в том, что я не нахожусь во вражде с вами. Мне кажется, вы просто сами себя перехитрили в том вопросе, который, как говорится, не стоит выеденного яйца. Если я неправ - аргументируйте.
Бит по определению "минимальная неделимая единица информации".
Он не обязательно бинарный, просто он минимальный.
Бит как раз обязательно бинарный. Буква "б" в слове "бит" как раз бинарность и означает.
там был трит
Потому что машина была на магнитных усилителях. Многие здесь хотя бы слышали про такого зверя? Я уже не говорю про принцип его работы. На всякий случай подскажу - сердечник может быть намагничен в двух полярностях или размагничен. Отсюда, и только отсюда, троичность.
бинарный бит так популярен
...потому что у ключа два стабильных состояния - замкнут и разомкнут. Всё.
Сетунь использовала для работы логики две двоичных линии.
В одном бите - 1000 милибит
Microsoft поддерживает
так байт вполне себе делим на части, вот и нули после точки
до 1/100?
Тем более речь идёт о размере файлов, они не могут выражаться в дробном числе байт.
0.13+0.13+0.13+0.13+0.13+0.13+0.13+0.13=1байт
вполне себе в таком представлении
p.s. честно говоря не знаю как оно там в реальности показывает
1/8 - это 0.125, так что MS как обычно пожадничала.
Не подменяйте понятия: тут речь про биты, а не про байты
сантибайты
...разделили бит на кубиты
640кб тоже должно было хватить надолго
Ха-ха
Видимо, кто-то не понял 😁
поясните уж тогда)
Классика же.
Нет, там было "640кб хватит всем". И означает это, что человенк в среднем за жизнь производит не более 640кб информации, которую действительно стоило бы хранить.
640 кБ - это пара книжек в ASCII, без картинок. Какой-то маловатый след у вашего человека.
Речь шла об оперативной памяти.
И? Много кто написал пару полезных книжек?
И? Много кто написал пару полезных книжек?
Если исключить слово "полезных", то я бы, наверное, попробовал пробиться в то небольшое число написавших, но вот ваше условие делает мои шансы слишком призрачными. Пас.
Тут на самом деле возникает масса вопросов - что именно и как именно считать полезным? Почему речь только о книжках?
Много кто написал пару полезных книжек?
Речь шла про "в среднем за жизнь производит не более 640кб информации" - а не про полезное. У человека даже после первой в жизни поездки на курорт или в круиз наберётся впечатлений на 640 кБ аски-текста. Да и дети в сутки загружают в своё ПЗУ несколько килобайт текста.
А если умирает человек
С ним умирает первый его снег
И первый поцелуй и первый бой
Все это забирает он с собой
А если умирает человек
Вы так говорите, как будто может быть как-то иначе. Не стоит вопрос "если", да и вопрос "когда" - лишь несущественная техническая деталь.
С ним умирает первый его снег
И первый поцелуй и первый бой
Все это забирает он с собой
То есть цитата как бы говорит нам: все тлен, будь ты нищий или король. Ну а чтобы было чем себя занять до наступления смерти, многие охотно занимаются работой на работе ради квартиры, убивают друг друга, а также многими другими не менее полезными занятиями, преимущественно сводящимися к разнообразной фаллометрии с реальными или, намного чаще, воображаемыми оппонентами.
Да, остаются книги и мосты,
машины и художников холсты,
да, многому остаться суждено,
но что-то ведь уходит всё равно!
Таков закон безжалостной игры.
Не люди умирают, а миры.
Источник: https://kulturologia.ru/blogs/190218/37910/
Да тут с одной стороны и тлен и нет, но для умершего все равно тлен, все не оставить, но всегда багаж есть
все не оставить
Как раз все оставить. В гробу карманов нет. Наследники раздерибанят, если будет что.
но всегда багаж есть
Поэтому мне нравится концепция аскетизма. Когда нечего терять, то не за что переживать и нечего беречь - еще при жизни. Впрочем, сам Будда учит нас срединному пути, поэтому ни на аскетизме, ни на отвратительных формах гедонизма, зацикливаться не стоит. Не буквально среднее, но точно что-то между ними.
Этим человеком был Билл Гейтс))
Это не так работает.
В IPv6, без использования NAT, на конечного пользователя (домохозяйство, CPE) выделяется целая подсеть длинной 64-80 бит, т.е. в лучшем случае у нас остается 32+32 бит под адресацию разных пользователей (4 млдр * 4 млрд), а в худшем 32+16. Так что не все так радужно.
Но ведь если эти 4*4млрд(sic!) закончатся можно изменить правила назначения адресов и выдавать уже не подсети, а адреса.
Не слишком глубоко знаю ivp6 чтобы понять насколько это взможно, подскажите знающие.
В теории конечно возможно, но в6 заточен под выделение минимум /64 на подсеть. Благодаря этому работает SLAAC - метод автонастройки в6 адреса из MAC сетевой платы или вообще рандомного адреса в случае Privacy extensions.
Всегда можно на это забить и выделять по 1 адресу на 1 устройство.
И оно будет работать. Правда-правда.
Вот закончатся адреса в той 1/8 части адресного пула IPv6 - и начнут следующую восьмушку из тех 7 что сейчас зарезервированы по адресам раздавать.
Кстати, не всё будет работать, там в IPv6 столько всякого лишнего наворотили, что я бы его назвал IPv69 (а в IPv6 ограничился бы небольшим увеличением длины, и были бы домашние подсетки 192.168.0.1.2.3)
Кстати, не всё будет работать
пример можно?
были бы домашние подсетки 192.168.0.1.2.3)
Это все равно ломает совместимость. И если мы ее ломаем, то почему сразу не сделать лучше чем есть сейчас?
И если мы ее ломаем, то почему сразу не сделать лучше чем есть сейчас?
Потому что вопрос подразумевает академический успех и закрывает глаза на скорость внедрения.
Протокол пытались улучшить в академическом смысле, а на практике то был план, в котором бизнес оплатит издержки за неимением выбора. При создании IPv6 не допускали, что ему придётся конкурировать с NAT-на-IPv4. Поэтому казалось, что нет разницы, насколько ломать совместимость: в любом случае ломаем => надо пользоваться моментом => а добавим ещё вот это...
Более длинный коммент рядом.
выделять по 1 адресу
и как это сделать?
реальная история: провайдер выдал /124 или вроде того, есть wifi-роутер, есть планшет с android. как назначить планшету адрес из этой подсети?
ручной ввод адреса, разумеется, есть только для ipv4.
упс, stateful dhcpv6 тут справится
Сейчас выделяется блок 2000::/3, остальные блоки (4000::/3, 6000::/3, 8000::/3, A000::/3, C000::/3) пока зарезервированы. Когда текущий блок будет заканчиваться и нужно будет вводить использование второго блока наступит время для пересмотра стандартов и (возможно) правил выделения префиксов
Блоки 0000::/3 и E000::/3 также заняты под специальное использование
/64 - стандартный префикс хоста, чтобы нормально работал SLAAC. Вроде как избыточно, зато удобно. И вообще, какая разница насколько "огромные" подсети, когда при стандартной маске для клиентов, у которых есть нужда в маршрутизации выделяется /56 (256 подсетей с /64 префиксом), для чуть более крупных потребителей есть /48 (65535 подсетей с /64 префиксом). И таких /48 сетей 2^80, т.е. 1.2 септилиона. Вам точно не хватит? 😉
Зачем моему чайнику подсеть, сравнимая с пуллом ipv4 адресов?
Что будет если таких чайников будет миллиард?
Чайнику она и не нужна. Такая подсеть выделяется вашему роутеру, а чайник выбирает из неё один адрес.
Даже для роутера это огромная подсеть, сравнимая с текущим интернетом.
С ipv4 тоже думали что хватит навсегда.
В сети IPv6, что сейчас распределяют 2000::/3. В ней есть 2⁴⁵ сетей /48 = 35 184 372 088 832. То есть по 4398 сетей на каждого из 8 миллиардов человек. Есть ли вероятность, что население земли вырастет более чем в 4000 раз? Точно нет! Следовательно те, кто выдают меньше /48 на самом деле жадничают без причины. А ведь помимо 2000::/3 есть ещё много сетей аналогичного размера. Так, что даже для колонизации иных планет и связи всех через гиперсвязь есть солидный запас.
Для связи с другими планетами наверняка какой-то новый протокол потребуется. Из-за задержек и т.д. Хотя может и этот настроят, что ждать полчаса загрузки сайта это нормально.
Там по идее L1 уровень должен быть на каких то иных физических принципах для быстрой связи. А дальше уже можно навешивать и текущие логические протоколы.
Быстрая связь невозможна, т.к. информация не может передаваться быстрее скорости света. То есть, протоколы должны быть как минимум настроены на большие задержки и может большее число хопов.
Понятно Ваше мнение.
Но те же кротовые норы до сих пор витают в умах ученых и не отвергаются как что то невозможное, а вполне себе допустимое в нашей вселенной.
Нам сейчас неизвестно, до каких высот может дойти научный и технический прогресс в области связи и перемещения в пространстве в отдаленном будущем. Я бы не был столь категоричен.
Допускаю возможность кротовых нор, но на масштабах много больше масштабов Солнечной системы, а в наших реалиях скорость передачи информации будет ограничена скоростью света, который будет идти в район орбиты Марса порядка получаса, т.е. гипотетический сайт с Марса будет грузиться где-то в течение этого времени в худшем случае. Таким образом еще понадобятся ретрансляторы.
Кротовые норы не отвергаются, как невозможное, потому что они никогда и не описывались, как нечто в нашей вселенной возможное - кротовая нора это решение для бесконечно существующей (из бесконечно далекого прошлого в бесконечно далекое будущее) черной дыры, а у нашей вселенной было начало, и у черных дыр было начало. Кротовая нора это чисто математическая абстракция
Почему не может? Может. Привет от квантовой запутанности
Это материя не может (ну и волны)
(поправьте дилетанта, если что)
Никакая информация не может быть передана быстрее, чем скорость света. Если взять четырехмерное пространство-время и нарисовать в нем конус, который расширяется при движении вдоль оси времени, то вы имеете влияние, только на те точки, что находятся внутри этого конуса. То, что вне его, для вас, можно считать, не существует.
С квантовой запутанностью, если я правильно помню, не все так элементарно, как это объясняют на пальцах обычно. Она не может быть использована для передачи информации.
С ipv4 тоже думали что хватит навсегда.
Так никогда не думали. Винтон Серф, которого иногда называют «отцом интернета», рассказывал, что взял 4 байта практически с потолка. Его задачей была дать хоть какой-то результат (по этой же причине внутри IPv4 пакета куча никому ненужных полей). Он прикинул и решил, что 4 байт для теста достаточно, поскольку ни у кого в США нет такого числа ПК. Но всё пошло не по плану. Протокол утёк в реальный мир... а потом и мир изменился.
А представляете сколько мусора выкинули из заголовка пакета, что при изменении длины адреса IP между IPv6 и IPv4, заголовок пакета IPv6 всего в 2 раза больше минимального размера заголовка IPv4, при том, что адреса отправителя и получателя выросли в 4 раза!!!
Ну во-первых не одному чайнику, а всем вашим чайникам в вашем доме. Даже если вы продвинутый пользователь и у вас чайники и вся другая IoT'ная требуха живет в отдельном VLAN'e, и таких как вы юзеров цельный миллиард, то у меня для вас хорошая новость - /56 сеток всего может быть 4.7 секстилиона (4.72 х 10^21).
Я не думаю, что что человечество расплодится на 4.7 триллиона миллиардов (сейчас нас около 8 миллиардов) 😀
Для наноботов
Кстати интересно, насколько проще или сложнее методы блокировки и ее обхода для ipv6?
РКН просто весь IPv6 трафик заблокирует на ТСПУ. Делов то! /s
Неправда, в реестре довольно много отдельных ipv6 адресов, они просто ресолвят домен сайта и если у него есть в6 адрес то он тоже должен попадать под блокировки.
Уже делают. Когда начали "ограничивать" трубу первые дни ipv6 помогал, потом уже было без разницы с ним или без. Есть и заблокированные сайты, которые имеют обе адресации. Так что.... ipv6 тоже под прицелом
Придумают, зря чтоли им такое бабло выделяют, это не роблокс с дискордом банить, придется напрячься.
Все гораздо проще. Беседовал с одним знакомым, который работает в одном из федеральных провайдеров проводного Интернета. Провайдер перечислен в расстрельном списке. Поскольку я являюсь их клиентом, поинтересовался: "Куда делся этим летом мой "модно-стильно-молодежный" IPv6?" На что получил ответ, что-де поскольку они относятся к "критически важной инфраструктуре" (как провайдер федерального уровня), то их оборудование должно быть "импортозамещенным", чтобы соответствовать законодательству и не лишаться лицензии, вот этим летом они и "импортозаместили", а "импортозаместительное" оборудование про IPv6 ни сном, ни духом. Поэтому провайдеры помельче чтобы оставаться на плаву предпочтут соответствовать законодательству и вложат деньги в "импортозаместительство", а не в "модно-стильно-молодежное". Ну и про методы блокировки. Была тут новость... Спойлер: ТСПУ пытается подняться вплоть до 7 уровня OSI чтобы принять решение о "деградации", поэтому ей неважно что там на 3 уровне: IPv4 или IPv6.
ну это проблемы конкретного провайдера. у нас эр-телеком давно выдаёт ipv6. ростелеком не так давно, но тоже выдаёт. сотовые операторы то выдают, то нет пофиг, так как всё равно не работают.
Эр-телеком у вас и на PPPoE и на DHCP("кабель в порт и будет предложение авторизовать устройство и чуть выше скорость")? Потому что мне они четко сказали что IPv6 - только первое. И даже там - псевдостатика блок /64. На прямые ссылки на RIPE про /56 home user'у и что мол как свою адресацию то внутреннюю - пожали плечами.
Только на pppoe, да.
Разницей в скорости из-за mtu на несколько байт меньше можно пренебречь
про /56 home user'у и что мол как свою адресацию то внутреннюю - пожали плечами.
Именно. И именно подобное обычно и является проблемой, когда оно не работает и начинают придумывать хитроумные сценарии. Потому что /64 на внешнем интерфейсе маршрутизатора - этого недостаточно. Нужны еще сетки для внутренних адресов. А тот адрес, что на внешнем интерфейса маршрутизатора, по идее - вообще клиента интересовать не должен.
Два года назад подключал у эр-телекома поддержку IPv6, настроил роутер. SpeedTest показал ухудшение в скорости примерно в 2 раза. Отключил ipv6, не стал разбираться.
Не знал что провайдеров с ipv6 так мало. Я очень даже удивился тому что там есть мой местный провайдер. И тому что у меня всегда была возможность включить ipv6, а это оказывается привелегия. Спасибо за список.
На что получил ответ, что-де поскольку они относятся к "критически важной инфраструктуре" (как провайдер федерального уровня), то их оборудование должно быть "импортозамещенным", чтобы соответствовать законодательству и не лишаться лицензии
А вы всерьёз ожидали, что они вам скажут что-то типа: "нам жалко денег на нормальных админов, по-этому, тот студент, который умел настроить ipv6 давно уволился?"
IPv6 поддерживается в линуксе 30 лет уже. Аналогично во фре и других. Импортозамещённое оборудование вашего провайдера (спорю на коньяк) работает под линуксом, так что всё там поддерживается.
так что всё там поддерживается
Но никто не поддерживает...
А вы всерьёз ожидали, что они вам скажут что-то типа: "нам жалко денег на нормальных админов, по-этому, тот студент, который умел настроить ipv6 давно уволился?"
Вообще-то я разговаривал с тем самым "студентом", который как раз настраивал и запускал у них IPv6 (сначала как тестовой в эксплуатации, а затем и в "боевой") .
Импортозамещённое оборудование вашего провайдера (спорю на коньяк) работает под линуксом, так что всё там поддерживается.
А почему именно линукс, а не FreeBSD? А Вы понимаете, что речь идет о магистральном оборудовании, а не об оконечных абонентских устройствах? Вы можете привести примеры когда производитель магистрального сетевого оборудования разрешал инженерам своих клиентов вносить изменения в программное обеспечение своего оборудования с сохранением гарантийных и постгарантийных обязательств?
насколько проще или сложнее методы блокировки и ее обхода для ipv6?
Вещи не связанные. Одинаково
без разницы. Единственно, что блокируемый сайт может чаще адрес менять, так что за ним бегать больше. В остальном — то же самое
IPv6 столько лет с нами, а воз и ныне там.
Судя по приведенным в статье же графикам, "воз" совсем уже не там, а постоянно и неумолимо движется вперед. Не везде с одинаковой скоростью. Но движется
И при выборе хостера или провайдера, наличие IPv6 - один из критериев выбора. Понимаю, что не для всех.
Не устану писать под каждой статьёй про ipv6:
IPSec не часть IPv6. если в статье написано про "встроенную поддержку IPSec" - это сразу маркёр перепечатки которую тянут друг за другом все кто ни разу в жизни не работал с IPv6 и просто пишет по мотивам того что прочитал
"ундицилионны" или как их там адресов, - это преувеличение, которое легко сделать если напрямую проецировать опыт работы с ipv4 на ipv6. то что в ipv4 один айпишник, в ipv6 представляет из себя /64 подсеть. любой механизм выделения адресов конечным устройствам подразумевает что вы владеете минимум подсетью /64. провайдеры выдают конечным пользователям сразу по /64 сети, иначе это не работает. а чаще всего и по /56 и по /48. так что реальный объём прям вот адресов которые можно раздать "клиентам" (а не конечным устройствам) ну прямо сильно меньше. меньше /64 сети раздавать в руки даже самого распоследнего василия на модеме 14400 в деревне не получится.
ты не написал, сколько же адресов тогда в пространстве ipv6 по твоей формуле. Это ВСЕГО 18446744073709551616 подсетей /64 (примерно 18,5 квинтиллиона), а если по /48, то 1 208 925 819 614 629 174 706 176 подсетей /48 (примерно 1,2 септиллиона)
проще считать так, количество сетей /48 в 65к раз больше, чес адресов ipv4, которые уже кончились.
то есть много, но не прямо ужас как много, при бестолковом менеджементе можно и это просрать исчерпать
В точку. Любой конечный прямоугольник можно порвать в лохмотья так, что они станут непригодными для дальнейшего рационального использования.
Ну смотрите, сейчас под GUA выделена сеть /3. Туда помещается 536 миллионов подсетей /32 (типичный префикс для среднего провайдера). Существует в мире столько провайдеров? Нет, это получается один провайдер на 15 человек. То есть, префиксов для провайдеров достаточно. Если провайдер выдаст каждому юзеру по префиксу /56, этого ему хватит на 16 миллионов пользователей. Да, в больших странах существуют провайдеры, у которых больше абонентов, но в таком случае они запросят или больший префикс (например, /24), или несколько префиксов /32. Не вижу проблемы, одним словом.
Что-то тут напутано. 1.2 септиллиона - это число адресов внутри подсети /48. А количество таких /48 подсетей всего примерно 300 триллионов.
то что в ipv4 один айпишник, в ipv6 представляет из себя /64 подсеть
Кстати, а зачем?
предположу, потому что вам надо выделить адрес, на который вы захотите повесить более одного устройства. Таким образом это будет некий диапазон адресов.
В случае с v4 у вас все устройства из-за NAT выглядывают в сеть из под одного айпишника, а в случае с v6 у каждого устройства свой адрес
Интересно, а при таком подходе нельзя адреса менять для каждого запроса? Чтобы по внешнему айпишнику, выданному провайдером, было труднее тебя идентифицировать. И не потому ли такая тянучка с внедрением?
Интересно, а при таком подходе нельзя адреса менять для каждого запроса?
Технически - можно.
Чтобы по внешнему айпишнику, выданному провайдером, было труднее тебя идентифицировать.
Ага, как же. Префикс же будет все равно твой. И постоянный - в его динамической смене при использовании IPv6 никакого смысла нет.
IPv6 Privacy Extensions (rfc4941) почти так и работает, только адрес обновляется периодически, обычно раз в сутки. И нацелен он больше на усложнение обнаружения количества устройств в конечной (пользовательской /64/56/48) сети. И на затруднение связывания разных сессий с конкретным устройствами. Ну, и отсутствие MAC адреса в публичном ipv6 тоже будет полезно...
А с каких пор в IPv4 MAС уходит дальше первого хопа (то есть за пределы сегмента сети, «в публичное пространство»)?
усложнение обнаружения количества устройств в конечной сети
Не очень понимаю, как это затрудняет определение количества устройств. Если речь про публичную сеть, где люди часто приходят и уходят - то просто считаешь уникальные адреса, и вот, количество устройств. Если сеть вроде домашней, с редким изменением состава участников - то в общем-то тоже, берёшь и считаешь адреса
Так и делал для обхода ограничения запросов для api. Ребята подумали 8 месяцев и казнили шестого.
del, выше уже было
Вообще-то это одна из базах фич v6 - менять клиентский адрес на каждый запрос, чтобы его не сканировали снаружи - типа секьюрити. И айтишник чайника никто никогда не найдет - просто физически невозможно просканирвать весь диапазон
Особенность реализации.
Вашему роутеру выделяется /64 подсеть и из неё он автоматом (на основе MAC адреса сетевой карты каждого устройства) формирует IPv6 адрес каждому конечному устройству. Конечному устройству также нужен очень жирный блок адресов для фактической работы (устройство может слушать на куче разных адресов, но эти адреса должны быть защищены от возможности поиска перебором возможных вариантов).
А если у вас физический сервер, на котором может быть группа виртуалок, то на этот сервер по стандарту (не обязательному правда) нужно уже /48 подавать, чтобы он дальше этот блок распределял внутри.
Ну то есть любой владелец веб сайта запросто сможет узнать что у клиента за сетевая карта, кем произведена, где и когда продана. И на основе этого выдать таргетированная рекламу. Или передать сведения правоохранителям. Видимо поэтому и не внедряют.
владелец веб сайта запросто сможет узнать что у клиента за сетевая карта, кем произведена
Privacy extensions и рандомизация mac в беспроводных железках этому противодействует.
Да и как оно знание сетевушки поможет таргетированной рекламе? Они и без этого неплохо научились «фингерпринтить устройства»
И да и нет.
В стандарте есть механизм Privacy Extensions for SLAAC (RFC 8981), который позволяет устройствам получать и использовать случайный глобально доступный IPv6 адрес. Расширение не является обязательным, но основные производители ОС ему следуют (чего нельзя сказать про рандомные китайские устройства).
Устройства обычно меняют свой постоянный адрес 1 или несколько раз в сутки.
С другой стороны - провайдер или сайт, к которому ходят очень активно (маркетплейсы, различные аналитики и так далее) могут узнать количество устройств в сети даже при использовании максимально безопасных браузеров (которые обфусцируют всё что возможно).
То есть ввести тариф "на 5 устройств в квартире" станет элементарно, можно даже вводить градацию "100 мегабит на 1 устройство = 50 рублей, на 10 устройств 300 рублей, на 20 устройств 500 рублей, безлимитные устройства 1000 рублей".
Если я правильно понял, чтобы вы получили свой личный загончик в едином большом интернете и могли в этом загоне рулить) NATне нужен.
Что там кстати с приватностью? Ведь заключая договор с провайдером, я фактически назначаюсь админом этой сеточки, а блуждающие по сети пакеты фактически содержат моё ФИО. Т.е. на любом участке мировой сети видно "Иванов И И отправил пакет в ООО "майнкрамфт" и получил другой пакет обратно.
Они и сейчас ваше ФИО содержат, только "достать" его чуть труднее.
Кто "они"?
Сейчас интернет - это лоскутное одеяло, как только пакет (через маршрутизатор) покидает свой лоскут, то по сути весь остальной интернет ничего не знает об этом пакете (кроме того что он вышел из такого-то ласкута).
Замысел же v6, как я помню, был в том, что сеть и адресация в ней становятся глобальными. Каждому физическому и юридическому лицу выдается его персональный адрес (ну точнее префикс). И как бы пакет не блуждал по глобусу в любом месте сети он однозначно указывает на отправителя и получателя. В этом схематозе как бы и маршрутизаторы не нужны, достаточно коммутаторов.
Да нет, идея вообще-то была прямо противоположной - уменьшить сложность маршрутизации путём более аккуратной раздачи адресов.
Ваш префикс выдаётся вам провайдером, и только провайдер знает кому он этот префикс выдал.
Персональные префиксы тоже кто-то предлагал, но это опция для тех, кому оно и правда надо.
Чтобы сеть не сканировали
Получится. Работать правда это будет немного не так как задумано авторами...
меньше /64 сети раздавать в руки даже самого распоследнего василия на модеме 14400 в деревне не получится.
Один из провайдеров VPS, с которыми доводилось иметь дело, выдавал IPv6 адреса штуками. Да, буквально один адрес. Именно /128 сегмент.
То что это неправильно - факт, но и категорично заявлять что такого не бывает - тоже не надо.
Почему неправильно? Это вполне нормально, серверу для коммуникации с интернетом вполне достаточно одного адреса. Все сервера в одном VLAN получат адреса /128 в общей подсети /64 этого VLAN. Скорей интересно зачем серверу собственный делегируемый префикс, под какие задачи?
Скорей интересно зачем серверу собственный делегируемый префикс, под какие задачи?
Например, под виртуализацию
Виртуальные вебсервера на разных доменах, почта-фтп-мессенджер.
Каждому сервису - отдельный адрес.
Можно. Я это и имею в виду при упоминаниии контейнеризации. Это один из аргументов использования DHCPv6-PD с серверами.
Но все же это частный юзкейс. Все описанное вами вполне реализуется в классическом виде на сервере с единственным адресом, так как все сервисы используют разные tcp/udp порты. Это случай по-умолчанию, он проще, особенно с точки зрения хостера.
Могу чисто предложить, что провайдер хотел бы как-то пинговать ваш сервер, а какой адрес вы ему назначите - он не знал, и тупо не придумали ничего, кроме вашего ограничения)
https://www.msk-ix.ru/traffic/
Если кратко, 1. многие привычные вещи научились корректно работать с NAT, пользователь в комфорте и не чувствует необходимости что-то менять. 2. IPv6 не приносит ни прибыли, ни скорости, лишь расходы.
При сегментации и стагнации Интернета, IPv6 будет востребован всё меньше и меньше, так же как в например, в США предлагаются тарифные планы домашнего Интернета с только IPv6 подключением.. технологии применяются там где они необходимы и есть прогресс, коммерческая выгода.
Использование NAT откладывает проблему, но не решает ее. Так или иначе, ресурс IPv4 исчерпан, активная экономия этих адресов (через динамическое назначение и разделение адреса между несколькими клиентами, централизированный CGNAT) усложняет сети, сужает возможности для конечного потребителя и тормозит развитие сетей в целом.
Не стоит связывать замедление распространения IPv6 в последние 10 лет с вновь "вдруг открывшимся потенциалом IPv4". Причина замедления в перекосе абонентского трафика в сторону операторов контента, CDN и крупных соцсетей - что сильно упростило маршрутизацию до 2-3 AS в пути и сильно сократило список успользуемых протоколов.
Прирост эффективности IPv6 по сравнению с IPv4 - 12-20% (по данным исследования Гугла) - за счет исчезновения NAT, отсутствия фрагментации и оптимизации ASIC под IPv6 заголовок. При переходе на IPv6-only, экономия на ресурсах BNG, упрощение архитектуры коллектов и OSS, снижение затрат на разработку софта для клиентских CPE. Для провайдеров - более эффективная маршрутизация на SRv6. Для хостеров - адресация на уровне приложений и контейнеров и опять-таки - программируемая маршрутизация end-to-end благодаря тому же SRv6. IoT, для которого IPv4 тесен. Прибыль от IPv6 есть, все зависит от грамотности его внедрения.
В США и Европе предлагается IPv6 либо в DualStack, либо IPv6-only, но с поддержкой MAP-T, таким образом IPv4 для вас остается доступен до тех пор, пока он вам нужен, но является теперь опциональным сервисом. Стоит говорить про покрытие IPv6 на уровне 60-99% в этих странах и форсирование перевода государственных сайтов и служб на IPv6?
При сегментации и стагнации Интернета, IPv6 будет востребован всё меньше и меньше
Вы явно не в теме.
Посмотрите стоимость блоков IPv4, например, в Российском сегменте, поэтому я не понимаю в каком вымышленном мире у вас что-то заканчивается..
Я даже не соменеваюсь, что мир за пределами российского сегмента вымышлен. :) Но в этом вымышленном мире доступные блоки у всех RIR закончились еще несколько лет назад, а цена за покупку IPv4 хоть и упала, но держится на уровне $20-30 за адрес в зависимости от размера блока. https://www.ipv4.global/all-ipv4-pricing-data/
Так что если вы даже небольшой провайдер с несколькоми сотнями тысяч абонентов, то можете произвести самостоятельно несложный арифметический расчет ваших инвестиций в этот неисчерпаемый ресурс.
Один адрес на сотню абонентов норм.
Итого 20-30 центов на абонента. Копейки. На кофе больше уйдет за неделю.
Что значит "норм"? Для мобильного абонента - чаще всего да, он ограничен только своим терминалом. Для фиксированного подключения, где абонент - это вся его домашняя сеть (со всеми смартфонами, ноутбуками, компами, хбоксами и т.д.) рейт 1:100 даст 650 доступных портов. По нашим исследованиям это на пределе среднего потребления среднестатистической семейной сетью. В пике доходит до 2000 соединений. С учетом возможного роста мы резервируем 8000 портов на абонента, так что 1:100 превращается в 1:8. Ну и далее вопрос в количестве абонентов.
Откуда у вас столько соединений? Открыл свой роутер. 500 соединений от десятка железок дома. У людей в среднем поменьше железок чем у меня.
100 допустим на пределе, но 80 прямо нормально. Итого 30-40 центов на абонента. Пусть даже 50 и запас большой будет. Это все равно копейки.
У меня сейчас около 900 открытых соединений tcp+udp из моей локальной сети в интернет, хотя тоже не показательный случай.
Приведенные мною выше цифры результат внутреннего исследования французского оператора (одного из большой четверки).
Дайте ссылочку почитать
На внутреннее исследование? :)
Вы же на него сослались. Ссылаться на что-то не проверяемое так себе план.
Так ведь мне не надо ничего доказывать, я поделился той базой, которая была использована нами при разработке дизайна CGNAT/MAP-T в нашей сети. Другие провайдеры могут использовать другой подход в оценке. Пригодится вам моя информация - прекрасно, нет - вы можете провести свое собственное исследование и обосновать его для вашей сети.
десятка железок дома
Очень не много.
Сравниваем не с гиками, а со средним пользователем.
У семьи из 4-х человек должны быть телефон, планшет, ноут на почти каждого, плюс как минимум два телевизора и парочка устройств для стриминга. И это минимальный набор.
Планшеты умерли годы назад. Остальное примерно 10 и вышло. С учетом что включено и используется не все сразу.
...wifi-розетки, wi-fi-лампочки, термометры, стиральная машинка, холодильник, планшеты, которые не умерли, чайник, котёл... не 10, а скорее несколько десятков устройств.
У детей не умерли. У меня в доме 5 ноутбуков, телек, PS5, два планшета, 5 телефонов и это не считая всевозможного IoT-барахла.
Дети разные. У моей комп, телефон и 2 попытки было с планшетами. Комп включается для домашки, планшеты не прижились совсем. Прислала тут она мне фильм в телегу, я открыл на компе и стал смотреть. Доча: "нифига себе, а я не догадалась на большом экране открыть, смотрела в телефоне стирая серию перед просмотром следующей, так как память забита."
И многие из ее сверстников и народа постарше, но не ИТшников такие же - если первое умное устройство, что взяли в руки это телефон, то его хватает для всего.
планшет
Это тот самый недотелефон-переросток, из-за которого лет пятнадцать назад была массовая истерия с воплями, что вот это вот якобы сейчас враз и навсегда заменит все десктопы и ноутбуки? Очень, скажем так, нишевое устройство на самом деле - неудивительно, что сегодня про него мало кто вспоминает.
ноут
Это от нищеты. Нормально хочется (и большинству доступно) большого телевизора - да даже хотя бы бюджетно-массовый 27" покажется "большим" против любого ноута, полноразмерной клавиатуры не худшего качества, мониторов (компьютерных колонок с балансным подключением), а также выбора системного блока по пожеланиям и потребностям - от безвентиляторного неттопа до весьма взрослой рабочей/игровой станции или что еще кому-то может захотеться. И это все еще и поддается ремонту и апгрейду по частям. Ноут - это заглушка для командировок и туристических поездок, положить его на заднее сиденье проблемы нет, вдруг понадобится, тем более что телефон его не заменят, как впрочем и планшет.
плюс как минимум два телевизора
Телевизоры вычеркивайте, им в интернет доступ не нужен, а точнее, с точки зрения приватности, вреден.
Прошу вас, только не рассказывайте, что планшет с отдельной клавиатурой это практически ноутбук, а к полноценному ноутбуку можно подключить внешний телевизор и получится примерно десктоп, потому что это костыли. Возможно, кому-то так даже и удобно - почему нет. Но в среднем это именно что костыли, попытка из суррогатов слепить полноценную вещь, в результате которой денег тратится примерно столько же, а иногда заметно больше, а на выходе все равно получается просто кучка слепленных суррогатов, которые так и норовят рассыпаться на отдельные части там, где их недостаточно тщательно примотали изолентой.
Да, изолента - это больше метафора но, опять же, по-разному бывает.
Хрень полная. В одну из эпидемий в 10х, когда абоны стали массово хватать какой-то вирус-спамер делали ограничение 200 сессий на абонента. Заканчивались они только у тех, кто был с вирусом.
рейт 1:100 даст 650 доступных портов.
Только на устаревших NAT системах, с одного адреса можно открыть хоть 1 млн подключений в сторону разных dst ip/dst port
Для исходящих - да. Но имелся в виду расчет в плане количества портов доступных для входящих соединений.
Чаще всего провайдеры используют динамический CGNAT и пользователь не имеет возможности пробросить внешний порт с CGNAT на свой CPE. У нас реализован CGNAT на основе драфта draft-tsou-stateless-nat44-02, что позволяет разделить каждый публичный IP адрес между несколькими абонентами (например 1:8), зафиксировав за каждым абонентом его диапазон портов tcp/udp (65К / 8 соответственно для каждого из транспортных протоколов). CPE абонента производит NAPT во внешний приватный адрес из пула RFC6598, но используя только порты из закрепленного за абонентом диапазона портов. Далее пакет роутится до CGNAT, где транслируется только приватный RFC6598 IPv4 адрес в соответствующий публичный (чистый NAT).
Дополнительный плюс (а в нашем случае это обязательное условие), что при этой статической трансляции, пользователь доступен для входящих соединений (хоть и только в рамках зафиксированного за ним диапазона портов), остается только пробросить в LAN нужные порты на CPE.
Главным преимуществом этой схемы является простота вычисления пула портов в зависимости от приватного адреса. Для кодирования группы портов при рейте 1:8 нужно три старших бита из 16 бит порта, которые равны трем последним битам приватного IPv4 адреса. Таким образом каждому приватному IPv4 адресу соответствует конкретная группа 8К портов. То есть не надо назначать и помнить группу портов для каждого пользователя, только его приватный IPv4 и соответствубщий публичный IPv4 (точнее знать пулы IPv4 - например, приватный /24 - соответствующий ему публичный /27.)
Может оказаться так, что когда весь мир будет переходить на IPv6, блоки IPv4 будут высвобождаться и их цена упадёт? Тогда мы сможем остаться в своём IPv4 загончике, а когда рубильник окончательно опустят, забрать весь IPv4 себе.
Бедный IPv6, я надеюсь что к моим 70 годам (а мне 28) мы всё-таки перейдём на IPv6!
Это сильно зависит от того, где будете жить, когда исполнится 70. Может интернет не везде и не у всех будет
Это сильно зависит от того, будем ли мы жить, когда исполнится 70
Я думаю, после опускания рубильника обе части интернета будут называть интернетом. У нас свой, у них — свой.
А как называется сейчас мобильный интернет в отдельных регионах РФ при опускании рубильника?
Насколько я понимаю, если отрубить интернет по границе, то опускание рубильника в отдельных регионах станет просто ненужным.
Давайте разберемся в понятиях. Упрощённо, есть следующие состояния:
Нормальный интернет
Чебурнет
Нет ничего
Если рубильник опустить на границе, будет п.2. А в мобильных сетях практикуют п.3
Ну официально Чебурнет же продолжат называть Интернетом, это во всех нормативных документах прописано ("информационно-телекоммуникационная сеть Интернет" или как там правильно?). А то, что остальные страны отключились от нашего православного Интернета, ну так это они ССЗБ. Как при разрубании червяка пополам каждая половинка продолжает жить своей жизнью, претендуя на то, что она и есть настоящий Червь, так и тут.
На всякий случай - у той части разрубленного червя которая "хвост" голова не отрастёт (отрасти может только хвост) и она погибнет. Возможно, к сети это тоже относится.
Да, я знаю, популярная легенда. Но есть же животинки менее известные, у которых жизнеспособны обе части. И даже из любого фрагмента может развиться взрослая особь. Вот в КНДР наверняка же внутренняя сетка есть, не знаю, как называется, может быть даже интернет. Может быть, даже на каких-то других протоколах. Это как несколько всемирных шахматных федераций, каждая из которых считает себя самой правильной и у каждой свой чемпион мира.
Во втором сезоне сериала Обратная сторона Луны (там где СССР в альтернативной реальности 2011 года не распался, а стал самой крутой в мире страной), там эта сеть называлась Межсеть.
Тут ещё, кстати, такой момент, что при отключении рубильника на границе в Чебурнете нашем Интернете появится много свободных IPv4 адресов, и не надо будет особо заботиться о переходе на IPv6.
в мобильных сетях практикуют «белые списки». поиск яндекса, например работает.
Просто для информации.
В Франции, если ты оператор и хочешь 5G лицензию ты обязан внедрить IPv6.
То есть ни о каком "мы хотим быть на острие прогресса и дать пользователям новые возможности" тут нет. Увы и ах.
Позвольте полюбопытствовать, откуда такая информация об "обязательствах"? Я о такой не в курсе. Есть общая стратегия недрения IPv6 в мобильных и фиксированных сетях, она всячески привеетствуется ARCEP, но никак не является обязательной. Необходимость IPv6 продиктована технической необходимостью у самих операторов и провайдеров.
Ну не знаю, за что купил, за то и продал.
L’IPv6, un critère indispensable pour la 5G
https://www.frandroid.com/telecom/726609_pourquoi-larcep-va-rendre-obligatoire-lipv6-pour-la-5g
Если буквально, то вы правы. Но контекст немного иной. ARCEP форсировал внедрение IPv6 чтобы выровнять внедрение между операторами. Смотрите годовой очет ARCEP по переходу на IPv6: https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_Barometre_2024_de_la_transition_vers_IPv6.pdf глава 2.1.2. По состоянию на середину 2019 (когда принималось решение n° 2019-1386), Bouygues Telecom уже имел 55% мобильных абонентов с доступом по IPv6. SFR и Orange уже несколько лет готовились в запуску IPv6 и выход этого решения удивительным образом совпал с их готовностью - Orange c середины 2019, SFR - с середины 2020.
Официальная мотивация регулятора - "Обязательство поддерживать IPv6 для обеспечения совместимости сервисов и предотвращения препятствий в использовании сервисов, доступных только по IPv6, в условиях растущего числа терминалов и нехватки адресов IPv4 в RIPE NCC". В реальности, для конечных абонентов - предоставить равные условия при выборе или переходе от оператора к оператору, для операторов - давить на четвертого оператора Free, на которого у других операторов есть зуб за демпинговый выход Free на мобильный рынок в 2012 году.
Короче, там своя политика и мотивация у всех участников, но для конечных абонентов и для распространения IPv6 это было благом.
В Беларуси все операторы связи по закону обязаны предоставлять IPv6: https://habr.com/ru/news/468569/
Недавно поставил Akvorado, посмотрел статистику - это максимум 10% трафика, и то в основном ютуб.
Ну, кстати, с точки зрения чердак-телекома внедрение дуалстека стоит вообще недорого, если в сети нет совсем уж дико древних маршрутизаторов или брасов. Главно чтобы биллинг поддерживал.
В Беларуси все операторы связи по закону обязаны предоставлять IPv6
обязаны, но почему-то 85-90% IPv6 не предоставляют.
Потому что в 90% IPv6 выключен на абонентских устройствах по умолчанию.
Кажется там не так, они обязаны его поддерживать. Но не обязаны предоставлять, тем более на безвозмездной основе
Что-то как-то все равно не верится. В других странах (где процент выше), включен по умолчанию, выходит? Вот случайным образом проверил одного крупного провайдера (www.a1.by) - у сайта нет даже АААА записи.
Тем не менее, у них есть префиксы IPv6: https://bgp.he.net/AS42772#_prefixes6.
Получается, утверждение "В Беларуси все операторы связи по закону обязаны предоставлять IPv6" превращается в "В Беларуси все операторы связи по закону обязаны иметь IPv6 префиксы"? Ну это выходит какая-то пародия, а не закон, обязывающий увеличить поддержку IPv6 на уровне страны.
Наличие префиксов - необходимое условие для предоставления IPv6 клиентам, в то время как AAAA-запись для сайта к предоставлению IPv6 клиентам вообще никак не относится.
хочешь 5G лицензию ты обязан внедрить IPv6.
Так это в стандартах 5G прописано по другому и не может быть
IPv6 не дает плюсов нигде, особенно для частников с сеткой внутри квартиры/дома, а выдает панамку такого размера, что в нее помещается тонна минусов. Как развивать инфру внутри предприятия, да учитывать и контролировать устройства без отдельной команды, заточенной именно под работы с IPv6 - не представляю. Верно сказано про фаерволы - еще такой же объем, немного больше правда, чем под IPv4. До сих пор нормальной работы DHCPv6 нет, а все разговоры про ND как лучший метод распределения адресов из предоставленного префикса - разбиваются после вопросов о контроле адресов и настройках доступов.
И да и нет. Минусов IPv6 дает не больше чем IPv4, недостатки скорей связаны с отставанием в реализации IPv6 в домашнем оборудовании и в домашних маршрутизаторах, что не в последнюю очередь перекликается с отсутствием устоявшегося опыта провайдеров в оргинизации сетей доступа IPv6 для конечных абонентов. В плане тех же файерволов - никакой принципиальной разницы между IPv4 и IPv6 в этом плане нет.
А вот потенцильных плюсов - масса. Если суметь ими воспользоваться.
Как развивать инфру внутри предприятия - есть наработанные гидлайны и методики, все зависит от предприятия, его бизнеса, архитектуры сети. Основная проблема не техническая, а в обучении и переквалификации персонала, потому что главная проблема - копирование образа мышления IPv4 на IPv6.
До сих пор нормальной работы DHCPv6 нет, а все разговоры про ND как лучший метод распределения адресов из предоставленного префикса - разбиваются после вопросов о контроле адресов и настройках доступов.
Простите, а где и в чем нет "нормальной работы DHCPv6"? И в чем проблема с ND? ND не занимается распределением адресов, а если вы говорите про SLAAC, то он прекрасно работает как для LLA, и для назначения GUA адресов особенно в тупиковой сети, где контроль адресов не нужен (например в домашней сети).
Для сетей с необходимостью контроля, DHCPv6 работает вполне эффективно, а недостающая в частных случаях функциональность постепенно покрывается развитием пртокола (например RFC9686)
недостатки скорей связаны с отставанием в реализации IPv6 в домашнем оборудовании и в домашних маршрутизаторах,
Это, кажется, не совсем так. IPv6 именно в домашних устройствах очень резво поначалу вводился - смотри лого IPv6 Ready. Это же была такая возможность убедить народ купить новую железку. Но именно операторы тормозили, после чего производители домашних устройств, посмотрев на это, решили что 'не хотите, не надо'.
Смотря что подразумевать под домашними устройствами. Клиенты? - телевизоры, пылесосы, утюги, видеокамеры? Им требуется лишь базовая поддержка стека - SLAAC, DHCPv6, DNSv6 - собственно этого достаточно чтобы соответствовать наклейке "IPv6 Ready". Что вполне справедливо, ибо "мы поддерживаем и готовы, а есть ли у вас IPv6 - это уже не наша проблема".
Или речь идет о маршрутизаторе? Если роутер предоставляется провайдером, то его форма поддржки IPv6 определяется дизайном принятым самим провайдером, ибо должен определять как роутер получает параметры IPv6 и какие именно (размер делегируемого префикса? поддерживает ли роутер DHCPv6 для LAN клиента или только SLAAC? как сам роутер получает PD, DNSv6, NTPv6 - SLAAC? DHCPv6? через PPP? есть ли сервис IP-TV? mcast v6? есть ли SIP телефония v6 и как она шифруется/тунелируется? Поддерживается ли IPv4 как DualStack или происходит трансляция NAT46 в MAP-T или MAP-E? и т.д.)
Схожий список вопросов если вы используете свой собственный роутер (или файервол) в дополнение к провайдерскому или вместо него. Если провайдерский роутер не позволяет пользователю прописывать статические маршруты (а это часто именно так) и не поддерживает DHCPv6, то получить префикс для сегмента за вашим личным роутером или файерволом будет весьма затруднительно. Да и то, ваш роутер должен поддерживать прокси-icmpv6, что стандартизировано, но ни разу не видел в реальности (кроме как в документации некоторых Cisco). Даже для работе с DHCPv6 ваш роутер должен поддерживать DHCPv6 relay.
Так что то, что вы можете получить в реальности напрямую зависит от того, что и как провайдер способен вам предоставить.
то его форма поддржки IPv6 определяется дизайном принятым самим провайдером, ибо должен определять как роутер получает параметры IPv6 и какие именно
Я давно смотрел, но в сертификации на это лого именно для роутеров много чего на этот счет есть в тестах.
от того, что и как провайдер способен вам предоставить.
Это да. Но для этого лого и нужно было, чтобы оператор знал, какие умения от маршрутизатора ожидать можно и соответственно планировать, как сеть делать.
Там кажется, что много, потому что базовые стандарты сформулированы как список отдельных тестов, по одному тесту на каждую функцию или параметр.
Это хороший документ. Но лого не только для этого, оно упрощало проверку соответствия стандарту, потому что многие производители указывали поддержку того или иного RFC, но либо реализовывали ее не в полном обьеме, либо трактовали стандарт при реализации на свой лад (особенно там где RFC оговаривал "should", а не "must").
А вы можете назвать хоть один домашний маршрутизатор, выпущенный в последние пару лет кто бы НЕ умел ipv6? Я может в своем мире живу, сильно отличном от реальности, но все маршрутизаторы с которыми имел дело за последние 5 лет умели ipv6 (это не очень много моделей, в основном Keenetic, пара Asus, один tplink)
Я, к сожалению, очень мало сталкиваюсь с публичными маршрутизаторами начального или SOHO уровня, потому не могу ответить с уверенностью. Но в роутерах устанавливаемых провайдером своим абонентам такое встречается. И не только прошивка IPv4Only, но и разный обьем поддержки IPv6. Например Freebox не поддерживает DHCPv6, а только SLAAC. Считать ли, что Freebox не умеет IPv6?
Например Freebox не поддерживает DHCPv6, а только SLAAC. Считать ли, что Freebox не умеет IPv6?
нет, поддержки SLAAC вполне достаточно. Например, Андроид тоже не поддерживает DHCPv6 (по идеологическим причинам), но это ведь не значит, что телефоны на Андроиде не умеют в IPv6. Просто им его нужно раздавать через SLAAC.
Поддерживает. Начиная с v11. В том числе DHCPv6-PD, что горячо обчуждалось месяц назад на UK IPv6 Council:
https://www.ipv6.org.uk/wp-content/uploads/2025/10/11_Enterprise_Android_DHCPv6PD_VMcKillop.pdf
https://www.ipv6.org.uk/wp-content/uploads/2025/10/10_Android-DHCPv6PD_RichPatterson.pdf
Ну используется-то далеко не только оборудование, «выпущенное за последнюю пару лет»
отставанием в реализации IPv6 в домашнем оборудовании и в домашних маршрутизаторах
Как же им не отставать если регулярно создаются новые RFC, а старые отменяются. Например на получение подсеток у прова, например на 6to4.
Я несколько лет назад устал за этим следить и с каждой версией линуха дорабатывать networkd файлы и отключил ipv6 у себя в домах с концами.
Что поделать... это проблемы роста. Они пройдут. Даже 20 лет назад было сложно обьять все возможные кейсы и нюансы в переходе к IPv6, сейчас мир IT сильно разросся, стало еще многообразнее и сложнее. Одни технологии ушли в музей, другие стали стандартом по умолчанию. Нормальный процесс эволюции.
20 лет проблем роста? С учётом того что сам интернет существует едва как 40 это всё весьма подозрительно выглядит, уж простите. Тут явно что-то в консерватории не так. Не взлетает этот V6, очевидно же. Несите V8 или V12, посмотрим их. Нужно что-то более жизнеспособное, и кмк с обратной совместимостью с V4
Как знаток (я серьёзно, без наездов) IPv6 подскажите, как на роутере с IPv6 реализовать вот такую модель:
Основной канал - проводной провайдер 1, при недоступности - переключаемся на провайдера 2, при недоступности обоих - на мобильный (USB модем)
Устройства с такими-то MAC адресами ходят строго через провайдера 2, без переключения на резерв
Весь трафик с таких-то устройств отправляется в корпоративный VPN "vpn corporate"
Трафик на такие-то сети (адреса elasticsearch, terraform, которые блокируются от России) отправлять через выделенный VPN "foreign VPN"
На обычном IPv4 эти настройки что на замороченом mikrotik, что на более простом keenetic делаются за пол часа.
Как такое решить в IPv6 я (на моём уровне понимания логики IPv6) не понимаю. Кажется, первая группа вопросов решается получением собственной AS, получением пула PI адресов и организацией пиринга со всеми тремя провайдерами, но я сомневаюсь, что они готовы поднять пиринг с обычным физиком, который платит по 300 рублей.
Вторую группу (корп сеть) порешать можно, если у корп сети получать пул адресов и распределять через домашний роутер. Сложно, но можно.
А как третью решить (в elastic ходить с адресов из другой страны) я вообще не понимаю. Настроить 2 адреса на всех устройствах сети и на всех же прописать роутинг в сторону elastic'а через VPN шлюз - задача хоть и выглядит логичной, но на практике совершенно нереализуема.
Основной канал - проводной провайдер 1, при недоступности - переключаемся на провайдера 2, при недоступности обоих - на мобильный (USB модем)
Каждый внешний интерфейс роутера получает префикс от своего оператора. Анонсирует соответствующие сетки внутрь.
В общем случае после этого каждое устройство внутри получает по три адреса - из адресного пространства каждого оператора. (Тем, которые строго через 2 - это делать запрещаем и используем только адреса 2)
В приоритетах маршрутизации пишется, что роут через 1 - предпочтительней.
Когда оператор 1 падает, маршрутизатор перестает перестает слать его анонсы внутрь, адреса оператора 1 внутри сети пропадают и все начинают ходить только через 2.
Ну и так далее. Без всяких AS и получения пула.
Да, адреса, с которых устранавливались содинения, пропадают и заменяются и уже поднятые соединения ломаются. Но обычно это не страшно. Происходит реконнект и все.
Когда оператор 1 падает, маршрутизатор перестает перестает слать его анонсы внутрь, адреса оператора 1 внутри сети пропадают и все начинают ходить только через 2.Ну и так далее. Без всяких AS и получения пула.
Вы хоть и ответили только на самый простой вопрос, но это тоже полезная информация.
Как быстро произойдёт переключение?
Мой (довольно тупой) кинетик переключается на резерв через пару секунд при падении физического линка (то есть когда порт провайдера уйдёт в down) и через 20 секунд при провале активной пробы (проверяет установку TLS соединения с заведомо доступным хостом). При желании, время переключения можно ещё сократить, но не вижу в этом особого смысла.
Как быстро произойдёт переключение?
Как только внутренние хосты поймут, что роут через адресацию 1 недоступен.
Там должны быть ответы no route от маршрутизатора, событие обрыва соединения от сетевого стека в сторону приложения, реконнект (уже в сторону маршрута с меньшим приоритетом, т.к. самый приоритетный пропал).
А уж как быстро сам маршрутизатор поймет, что линия 1 упала и нужно пакеты из этой сетки отшибать - это смотря как вообще проверка ее живости устроена.
Пробовала такой кейс на роутере с OpenWRT - устройства упорно продолжали пытаться выйти в интернет через отвалившегося провайдера. Проблема решилась с помощью NAT66, что опять приводит в вопросу - а зачем в таком случае IPv6?
Ладно, допустим, MultiWAN - это немного специфический юзкейс, не для типичного пользователя, но факт в том что он не очень совместим с IPv6 без костылей в виде старого доброго NAT.
Пробовала такой кейс на роутере с OpenWRT - устройства упорно продолжали пытаться выйти в интернет через отвалившегося провайдера.
Что-то недонастроено. После отваливания провайдера маршрутизатор RA с 'Router Lifetime' установленным в 0 рассылает? И хосты его не понимают?
А он не рассылает. С чего он должен понять, что нужно что-то разослать, если у меня провайдер отвалился? Если провайдер выдает адрес с сроком действия, допустим, полчаса, то пока полчаса не пройдут, ничего не произойдет.
С чего он должен понять, что нужно что-то разослать, если у меня провайдер отвалился?
Ну так в схеме с NAT-ом и ipv4 понимает же как-то, что нужно начать слать пакетики туда а не сюда, когда отвалился. Почему в IPv6 вдруг резко перестал?
В схеме с IPv4 и NAT-ом работает скрипт, который пингует хосты через разных провайдеров, и если видит что какой-то провайдер недоступен, меняет правила iptables/nftables по маркировке трафика, а дальше вступают в действие правила ip rule направлять трафик с определенными метками по определенному маршруту. Классическая схема. В IPv6 эта схема естественно тоже не работает без NAT, потому что система будет пытаться отправлять пакеты через второго провайдера с source IP первого провайдера - без SNAT/MASQUERADE никак.
пингует хосты через разных провайдеров, и если видит что какой-то провайдер недоступен,
В схеме c IPv6 тот же скрипт говорит тому демону, что RA рассылает "а убей-ка ты этот deafault маршрут в локалке"
потому что система будет пытаться отправлять пакеты через второго провайдера с source IP первого провайдера.
Почему? Маршрут через первого провайдера пропал, все пакетики с src этого провайдера из внутренней сети получили отлуп 'no route' (потому что слать их в сторону второго их смысла нет), соединения отвалились. Приложения инициируют новые соединения, которое будет уже с нового адреса, если маршрут действительно убили.
Почему? Маршрут через первого провайдера пропал
Я говорила про случай, когда маршрут не пропал.
В схеме c IPv6 тот же скрипт говорит тому демону
Отлично. Осталось написать такой скрипт :) Если кто-то напишет и выложит в опенсорс, желательно как пакет для OpenWRT с веб-интерфейсом для настройки, было бы вообще шикарно. А пока, что пакет MultiWAN в OpenWRT, что все лично мне известные аналогичные решения, работают исключительно через iptables/nftables, и ни с какими демонами "говорить" не умеют.
что пакет MultiWAN в OpenWRT, что все лично мне известные аналогичные решения, работают исключительно через iptables/nftables
А еще там скорее всего не обошлось без Policy-based routing.
кто-то напишет и выложит
Этого можно ждать очень долго. Зачастую можно проще засунуть в cron простой скрипт (ChatGPT и т.п. в помощь), который:
Проверит линк
Если линк не работает, то: ip -6 route del default via <YOUR_FAILED_IPv6_GATEWAY>
Когда линк заработает, вернет все обратно
Вот ровно такие же вопросы возникают. Только у меня ещё сложнее - маршрутизация между разными узлами динамическая через OSPF+BFD (иногда падают провайдеры, а ещё чаще по известным причинам - тоннели), префиксы, куда через какой хост выходить, транслируются по BGP... А ещё это всё надо мониторить - что где упало и поднялось.
Настроить всё это на конечных устройствах невозможно (какая динамическая маршрутизация на каком-нибудь принтере? да и даже на смартфоне без танцев с бубном?) Так что по сути придётся городить тот же NAT, только с кучей дополнительных сложностей.
Это всё в IPv4-то довольно головоломная история, как это настроить ещё и для IPv6, для меня глубокая загадка. Так что слава Богу, что IPv6 мне почти ни один провайдер не выдаст даже если очень попрошу :)
Поддерживает ли ваш роутер политики IP SLA? Если да, то вы можете создать сессии тестирования до неких устройств в глубинвх сети каждого аплинка и регулярно их зондировать (политики весма гибки как по испльзуемым протоколам, так и по критериям отказа). В зависимости от статуса SLA для каждого аплинка, вы можете менять метрики маршрутов или вообще убирать их из таблицы.
Эмм... мы с Вами про сильно разные весовые категории. У меня SOHO-сегмент. Просто текущие реалии диктуют необходимость вот этого всего.
Условно говоря, есть 4 дома/квартиры, 2 офиса и 2 арендованных сервера по разные стороны границы РФ. Роутеры в основном микротики (с дополнительно прикрученными к ним малинками для реализации нужных в наше непростое время хитрых протоколов), но есть и вообще бюджетный кинетик. Ну и мобильные пользователи, подключающиеся через VPN-сервер. В домах/офисах - один проводной провайдер и мобильный модем как резерв.
Всё это дело щедро перекрёстно соединено друг с другом туннелями, использующими разные протоколы и периодически попадающими под блокировки, так что OSPF нужен, чтобы маршруты между внутренними подсетями переключались на тот путь, который в данный момент работает, а BFD - чтобы это делалось быстро и не только при полном отвале, но и при деградации качества конкретного линка. Дальше поверх этого каждый роутер дома/офиса или сервер также получает от одного из серверов по BGP перечни префиксов во внешней сети, сформированные на основании GeoIP, реестров блокировок и всяких ручных добавлений, и объединённые в разные community, чтобы к каждому конкретному внешнему хосту ходить через тот узел моей внутренней виртуальной сети, у которого больше шансов успешно до него достучаться.
Главный результат - что конечное устройство, будь оно подключено хоть к домашней/офисной сети на любой из моих "площадок", хоть к VPN-серверу в дороге, получает одинаковый доступ как ко всем внутренним подсетям, так и к внешнему интернету через "правильные" точки выхода, независимо от того, что там отвалилось из каналов между площадками, а что работает. Для него есть один default gateway, а остальное не его проблема (а многие устройства более сложные сценарии и не поддерживают).
И вопрос, собственно (пока сугубо теоретический, т.к. IPv6 мне разве что для арендованных серверов дадут, в остальных местах им и не пахнет) - как достичь того же эффекта в идеологии IPv6? Ну т.е. без NAT? IMHO, никак вообще. А поскольку связность интернета разваливается на глазах, и не только из-за блокировок, то именно такие сценарии с множественными обходными путями всё более актуальны.
Для него есть один default gateway, а остальное не его проблема (а многие устройства более сложные сценарии и не поддерживают).
Это против идеологии IPv6. Там считается, что default gateway-ев может быть несколько(не как портов/устройство - это все может на одном быть, а с точки зрения адресации), с разными приоритетами, хосты этот приоритет учитывают, а роутеры, соответственно, управляют, через кого и с каким src адресом из них трафик пойдет.
Т.е. если на устройствах "это все равно" и "более сложные сценарии не поддерживаются" - то на них IPv6 стек сломан.
в RFC 8678 довольно много написано.
Т.е. если на устройствах "это все равно" и "более сложные сценарии не поддерживаются" - то на них IPv6 стек сломан.
Ну, во-первых, поскольку такие устройства в сети всё равно будут (я искренне сомневаюсь, что выпущенный 20 лет назад бюджетный принтер такое умеет) - то ради них всё равно придётся городить NAT. А раз NAT уже есть - то зачем усложнять себе жизнь параллельной системой?
Во-вторых, если я правильно понял (каюсь, в RFC 8678 пока прочитал только introduction) - выбор source address мы делегируем конечному устройству. В простом случае, если мы просто распределяем трафик между несколькими провайдерами, более или менее понятно, как это делать. Но у меня, скажем, в таблице маршрутизации, определяющей, "через что куда ходить", около 200 тысяч записей. Т.е. конечное устройство должно (а) поддерживать некий протокол передачи ему этих маршрутов и (б) обладать достаточным объёмом памяти / производительностью, чтобы эту таблицу переваривать. Очевидно, что для ещё бóльшего количества устройств эти требования не соблюдаются.
Т.е. идеология IPv6, может быть, хороша в идеальном интернете, существующем в том виде, в котором он задумывался, где каждый хост имеет доступ к каждому хосту. А когда мы вынуждены обходить ситуации "на свой сайт пускаем только из страны А, из страны Б сразу не пускаем, а из страны В пускаем, но ничего не показываем", "трафик на этот список хостов блокируем на гос. уровне" и т.п. - мы так или иначе упираемся в NAT.
Меня больше смущает большое количество частных нюансов (в контексте IPv6), в виде тунелей и внешних серверов, а так же протоколов маршрутизации. Если потенциальные IPv6 адреса должны роутиться посредством IGP, то вам придется поднимать OSPFv3 в довесок к существующему или переходить на ISIS. Без знания топологии вашей сети сложно дать стоящий совет.
В моей топологии много наворочено, да. Но давайте возьмём минимальный самый простой пример, на котором проблема уже имеет место быть:
у меня есть квартира в РФ и квартира за границей, в каждой стоит по роутеру с белыми статическими IPv4 адресами (допустим для упрощения, что эти роутеры умеют вообще во все возможные протоколы), через которые подключается некое количество девайсов, от компов до телефонов, принтеров и всякого IoT;
между роутерами - VPN туннель (опять же для упрощения пусть он будет один);
сейчас с IPv4 для любого устройства в каждой сети свой роутер - default gateway, никаких других маршрутов на конечных устройствах нет;
каждый роутер маршрутизирует пакеты по destination IP:
российский роутер пакеты к российским IP отправляет напрямую через провайдера, а к зарубежным - через VPN-тоннель и зарубежный роутер;
зарубежный роутер, наоборот, к российским IP ходит через тоннель к российскому роутеру, а к остальным напрямую через провайдера;
информацию, какие адреса российские, а какие зарубежные, оба роутера получают по BGP (крутится где-то скрипт, который GeoIP базы периодически скачивает и списки префиксов составляет и раздаёт - для данного вопроса не важно, где).
соответственно, каждый роутер делает NAT.
Теперь предположим, что оба провайдера в РФ и за границей выдали мне по подсетке IPv6 адресов и я радостно хочу перейти в своей сети на IPv6, не теряя преимуществ гео-зависимой маршрутизации. Насколько я понимаю, мои опции:
NPT66 - это совершенно понятно, как сделать, но идеологически неправильно;
выдавать каждому устройству адреса из подсети как российского, так и зарубежного провайдера - а вот в этом случае дальше что? В BGP большая часть устройств не умеет, да и таблицу маршрутизации на десятки тысяч префиксов не все потянут.
Получить свою AS и свой пул IPv6 - это лучшее решение и не слишком затратное (можно получить статус PI договорившись с каким-нибудь LIR'ом). Вопрос обычно упирается в необходимость поднятия BGP с каждым из ваших провайдеров-аплинков, которые не предусматривают BGP c публичными абонентами. Но в России по знакомству и не такое бывает. :) Лучшее - потому что при потере канала ваши устройства не вынуждены менять префикс и переключение возможно без потери соединений (при условии приемлимого времени конвергенции сети). Так же это решение позволяет поддерживать каналы в режиме актив/актив и балансировать трафик между ними.
Чаще всего для частника такое решение недоступно. Так что вариант описаный inkelyad наиболее реальный - получить префикс от каждого из аплинков и раздать всем устройствам в сети.
Можно ли создать политику маршрутизации для группы по их мак адресам - в принципе да, особенно если вы используете EUI-64, тогда MAC адреса используются в создании сетевых адресов устройств (независимо от получаемых префиксов), а значит можно использовать L3 ACL на основе IP адресов ваших устройств. Впрочем, это зависит от возможностей роутера.
Вообще, есть еще вариант с адресами ULA для устройств и использовать NPT66 для замены префикса ULA на префикс активного аплинка и в случае падения основного аплинка - транслировать префикс ULA на префикс запасного аплинка (а затем и третьего). Эта конфигурация работает, но не рекомендуется, потому что является костылем и сводит на нет преимущества "чистого" IPv6 без NATа.
Получить свою AS
В свете ч. 8 ст. 56.2 ФЗ о связи - очень сомнительная идея, даже если она была бы реализуема.
Свою AS легко получить тогда, когда ты хоть в какой-то мере сетевик и готов этим заниматься. Если ты массовый пользователь интернета, которому нужно чтобы просто работало - проблема становится почти неразрешимой.
Я уже тоже пришёл к выводу, что самым простым будет использовать NAT в IPv6, который полностью убивает все преимущества IPv6.
Даже для сетевика это слишком замороченное решение, либо затратное.
Решений на данный момент не так уж много - либо раздать префиксы от всех доступных аплинков каждому устройству, либо NPT66.
Проблема сейчас активно обсуждается. В частности на последнем DENOG17 : https://pretalx.com/media/denog17/submissions/QNDD3G/resources/slides-denog17-ipv_0gJks2a.pdf
Ммда. Вывод - пока multipath протоколы вместо TCP не станут использоваться (когда клиенту известно, что ресурс по двум путям достижим) - все останется плюс-минус там же. Надо начинать рекламировать SCTP и эквиваленты.
Пока нет массовых подключений со множеством путей, то нет и особого смысла в SCTP или MP-TCP. MP-TCP я вижу в обсуждениях более 10 лет, но ни разу не видел реализацию, даже в лабе.
Некоторые симбоксы для интернета преднастроены так, с соединением к суммирующему серверу. Такой своеобразный костыль для обеспечения относительно-быстрого интернета.
MP-TCP я вижу в обсуждениях более 10 лет, но ни разу не видел реализацию, даже в лабе
писали давно уже, что apple для сири использует. снаружи же это как просто tcp выглядит
Очень интересный разбор, спасибо за ссылочку.
Переход на MP-TCP или MP-QUIC (странно, что забыли про SCTP, в котором multipath уже давно реализован) это даже веселее, чем переход IPv4 => IPv6, так как потребует доработки буквально всего ПО в интернете.
Причём тут пока не учтены всякие вещи типа приоритезации использования каналов и необходимости синхронизировать настройки стека на всех устройствах в сети (условно, даже умный пытесос и камера должны понять что именно от них хотят).
По факту это выглядит самым интересным, красивым,... и никогда нереализуемым решением.
Получить свою AS и свой пул IPv6 - это лучшее решение и не слишком затратное
вроде как теперь куда-то на учёт надо вставать, а то и СОРМ за свой счёт ставить…
дальше, возьмём какой-нибудь магазин, основной канал через кабель, резервный — сотовый оператор, ему тоже свою AS получать? BGP настраивать? вы серьёзно?
Чаще всего для частника такое решение недоступно. Так что вариант описаный inkelyad наиболее реальный - получить префикс от каждого из аплинков и раздать всем устройствам в сети.
и как сделать в таком случае, например, «весь трафик в РФ идёт с префиксом A, а за границу — с префиксом B»?
пихать таблицу маршрутизации с тысячами записей на все устройства в сети? что-то такое себе.
а если просто балансировку между каналами делать?
мне гораздо привычнее схема, когда маршрутизация задаётся на одном месте, на роутере
Вообще, есть еще вариант с адресами ULA для устройств и использовать NPT66 для замены префикса ULA на префикс активного аплинка и в случае падения основного аплинка - транслировать префикс ULA на префикс запасного аплинка (а затем и третьего). Эта конфигурация работает, но не рекомендуется, потому что является костылем и сводит на нет преимущества "чистого" IPv6 без NATа
именно. тут мы имеем трудозатраты по внедрению ipv6, но не получаем никаких плюсов.
и да, чтобы всё работало нам ещё nat64/dns64 надо настроить. ибо ipv4-only сервера сплошь и рядом, а ipv6-only кроме ntc.party и не встречал
вроде как теперь куда-то на учёт надо вставать, а то и СОРМ за свой счёт ставить…дальше, возьмём какой-нибудь магазин, основной канал через кабель, резервный — сотовый оператор, ему тоже свою AS получать? BGP настраивать? вы серьёзно?
Я, кстати, не знал про такой выверт российского законодательства. Но было бы странно, чтобы дизайнеры протокола учитывали непредсказуемость Фемиды в каждом отдельном государстве, с другой - да, выбирая оптимальное решение приходится брать такое в расчет.
Если же мы говорим про клиента как юрлицо, то большинство операторов могут предложить решение с предоставлением AS и пула, который может быть анонсирован через другого провайдера (даже при том, что выдаваемый пул входит в глобальный пул выдающего оператора). Тем более что крупные операторы обычно явдяются LIRами и могут зарегистрировать PI для клиента. Я не уверен, что клиент подпадает под требование установки СОРМ, так как не является саб-провайдером и не имеет нисходящих клиентов.
и как сделать в таком случае, например, «весь трафик в РФ идёт с префиксом A, а за границу — с префиксом B»?
пихать таблицу маршрутизации с тысячами записей на все устройства в сети? что-то такое себе. а если просто балансировку между каналами делать?
На уровне хостов - никак. Собственно два PD это решение Active/Backup, оно не подразумевает специфичной логики маршрутизации или лоад-балансинга. Хотя последний может быть возможно реализовать посредством MP-TCP.
мне гораздо привычнее схема, когда маршрутизация задаётся на одном месте, на роутере
Мне тоже. Но дизайн IP подразумевает в этом случае либо отдельную AS и динамический роутинг с аплинками, либо шаманство в виде NAT, PBR и т.д.
именно. тут мы имеем трудозатраты по внедрению ipv6, но не получаем никаких плюсов.
и да, чтобы всё работало нам ещё nat64/dns64 надо настроить. ибо ipv4-only сервера сплошь и рядом, а ipv6-only кроме ntc.party и не встречал
Трудозатраты относительно небольшие, по крайней мере те же по сравнению с подобной схемой с NAPT на IPv4. Но выгода все же есть. NPT66 не NAPT, нет манипуляции с портами, так что хосты внутри сети могут быть доступны извне, а значит главное преимущество IPv6 сохраняется.
nat64/dns64 - это при условии, что провайдерская сеть IPv6Only. Ежели она DualStack, то эта проблема отпадает. Но даже случай IPv6Only - это тоже не архисложно, но метод зависит от архитектуры провайдера.
Если же мы говорим про клиента как юрлицо, то большинство операторов могут предложить решение с предоставлением AS и пула, который может быть анонсирован через другого провайдера (даже при том, что выдаваемый пул входит в глобальный пул выдающего оператора)
вы не поняли про что я.
вот смотрите, есть город, есть сотни магазинов в нём.
магазинам нужен бесперебойный интернет (эквайринг и всё такое). обычно это решается резервным каналом связи.
в вашей картине мира нужно получать по AS на каждый магазин?
Трудозатраты относительно небольшие, по крайней мере те же по сравнению с подобной схемой с NAPT на IPv4.
проблема в том, что эти трудозатраты в случае с дуастеком ложатся плюсом к трудозатратам на ipv4.
и дуалстек получается тупиковая ветвь — возни больше, чем с чистым v4, а выхлопа вообще не видно.
Но выгода все же есть. NPT66 не NAPT, нет манипуляции с портами, так что хосты внутри сети могут быть доступны извне, а значит главное преимущество IPv6 сохраняется
с динамическим префиксом-то? ну так себе…
да и практика показала, что задачи «нужно чтобы все хосты локалки были доступны из инета» нет.
P.S. на днях попалось в тему:
https://rutube.ru/video/private/6b8ed5785336b184467d10d972557698/
вот смотрите, есть город, есть сотни магазинов в нём.магазинам нужен бесперебойный интернет (эквайринг и всё такое). обычно это решается резервным каналом связи. в вашей картине мира нужно получать по AS на каждый магазин?
Нет, конечно. Все же выриант с AS это тотальное решение, когда сеть должна иметь не только резервный канал, но еще и через независимого провайдера. В большинстве случаев для малых клиентов такое резервирование черезмерно, достаточно резервирования через два канала одного провайдера, но по разным технологиям - например FTTO + 4G/5G. В этом случае гараздо проще предоставить клиетну один и тот же PD через оба пути. Клиент защищен от сбоев в разных сетях доступа (Landed vs RAN), а там где общая часть провайдеской сети (бекбон, пиринги) - SLA контракта с провайдерм. Собственно, сегодня это распространенный пакет предлагаемый многими провайдерами для B2B.
и дуалстек получается тупиковая ветвь — возни больше, чем с чистым v4, а выхлопа вообще не видно.
...если не держать в голове, что DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6. Независимо от отношения к IPv6, переход на него неизбежен, потому как проблема исчерпания IPv4 никуда исчезнуть не может, а IPv6, помимо решения проблемы адресации, является более оптимальным с точки зрения сетевых техноглогий. Как именно реализовывать доступ для v4 - это второстепенный вопрос, ибо зависит от конкретных условий.
с динамическим префиксом-то? ну так себе…да и практика показала, что задачи «нужно чтобы все хосты локалки были доступны из инета» нет.
Динамическим - это двусмысленный термин. Префиксы должны назначаться статично, а вопрос доступа решается разными путями. Если ода префикса розданы хостам и оба доступны одновременно, то DNS можно резолвить в оба. Если динамическая замена - DynDNS. Может есть еще варианты, надо подумать.
Рассуждать о такой задаче в общем виде довольно бессмыслено, решения есть и другой вопрос - какое из них оптимально, но оптимальным оно может быть только под конкретную ситуацию и задачи.
В большинстве случаев для малых клиентов такое резервирование черезмерно, достаточно резервирования через два канала одного провайдера, но по разным технологиям - например FTTO + 4G/5G.
ну такое себе. во-первых, это сразу сильно сужает выбор провайдеров.
во-вторых, вероятность того, что два канала одного провайдера перестанут работать вместе, остаётся высокой.
...если не держать в голове, что DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6. Независимо от отношения к IPv6, переход на него неизбежен, потому как проблема исчерпания IPv4 никуда исчезнуть не может
так-то оно так, но адреса ipv4 кончились уже несколько лет как, но их можно купить/арендовать, плюс цена за адрес снижается.
пока не появятся более-менее популярные ipv6-only сервисы, клиенты с ipv4 не озадачатся переходом, "умвр".
более того, сегодня многие клиенты с дуалстеком отключают ipv6. ибо без него работает стабильнее.
пока не появятся более-менее популярные ipv6-only сервисы
Бездоказательно, но категорично выскажу предположение, что появление популярных IPv6-only сервисов невозможно в обозримом будущем только и исключительно из-за того, что без доступа по IPv4 ни один сервис не может стать популярным - слишком много провайдеров в мире не предоставляют IPv6 в принципе, плюс какое-никакое IPv4-only legacy у клиентов тех провайдеров, что IPv6 предоставляют.
Я бы не был столь категоричен. В частности в Индии существует программа перевода государственных сайтов c доступом IPv6Only
https://lafibre.info/images/logiciel/202503_gemini_test_ipv6_inde.pdf
И насколько я знаю, не только в Индии.
Это не "популярные сервисы", а добровольно-принудительно™.
Одно другого не исключает.
Мы, наверное, спорим о терминах. Ни в коем случае не настаиваю, но только чтобы объяснить свое видение, с которым вы можете не согласиться: если буквально YouTube как конкретный пример, или близкий к нему по охвату аудитории сервис, внезапно решить стать доступным только по IPv6, то начнется суета прямо таки мировых масштабов, причем сугубо добровольная со стороны пользователей, на которую придется как-то реагировать и провайдерам, до сих пор сидящих на IPv4 и ни в чем проблем не знающих ни сами по себе, ни их абоненты. Это то, что я понимаю под популярными сервисами. Видимо, вы имели в виду что-то другое, поэтому и спор как будто ни о чем конкретном.
Конечно такой сервис как Youtube не станет просто так и себе в убыток отказываться от части своей аудитории и части своих доходов просто в угоду неким высоким идеям. Естественно во главе стоит здоровый прогматизм. Колличество просмотров (не важно через какой стек) конвертируется в колличество показов рекламы, а из показов - в финансовые доходы. Если принять гипотезу, что доля просмотров через IPv6 будет расти, а доля просмотров через IPv4 будет снижаться, то в какой-то момент последняя сравняется с расходами компании на поддержание этого стека (на лоадбалансеры, на CDN ящики, лицензии и т.д.) и в этот момент компания прекратит поддержку IPv4 (даже при том, что некая доля клиентов IPv4 еще останется). Или не прекратит, если посчитает, что имиджевые потери больше чем технические. Или прекратит раньше, посчитав, что поддержка единственного стека выгоднее в среднесрочной перспективе. Или если будет какое-то давление или наоборот - преференции со стороны регуляторов и политиков.
Я не думаю, что у нас с вами есть разночтения в этом плане.
ну такое себе. во-первых, это сразу сильно сужает выбор провайдеров.во-вторых, вероятность того, что два канала одного провайдера перестанут работать вместе, остаётся высокой.
Спрос рождает предложение. Сейчас найти такие предложения не составит труда, все провайдеры работающие с сегментом B2B в состоянии предложить подобное решение. Тем более, что такие решения не тербуют капитальных затрат для провайдера, ни на оборудование, ни на архитектуру. Связка технологий дана для примера, это может быть FTTx+Mobile, FTTx+xDSL, FTTx+SAT и т.д. или в любых других комбинациях и технологиях. Даже для связки +Mobile не обязательно быть сотовым оператором, можно быть MVNO. B2B вообще гораздо более гибок в этом плане.
То, что два канала одного провайдера перестанут работать вместе очень низка, так как возможные SPOF могут быть только на уровне сетей доступа, а все что выше, начиная от агрегационных сетей и бекбона, имеет избыточность как минимум n+1. Сети наземного доступа и мобильного доступа (RAN) это физически раздельные сети (как минимум до уровня агрегации), а глобальный инцидент если и возможен, то провайдер имеет контрактное обязательство устранить неполадки в течении согласованного времени (SLA обычно 4 часа). Вот если гипотетический простой в 4 часа неприемлим для клиентского бизнеса, то подключаться к двум разным провайдерам имеет смысл.
так-то оно так, но адреса ipv4 кончились уже несколько лет как, но их можно купить/арендовать, плюс цена за адрес снижается.
Можно. Но это как из детской сказки - сколько можно сделать шапок из одной шкуры? 2 можно? Можно. А 3? Можно. А 5? Можно. Хоть 10, если не оговаривать размер получаемых шапок. Так и с IPv4. Можно выкручиваться, докупать адреса, ставить динамический CGNAT и начинать шарить каждый адрес на все большее и большее количество абонентов. Можно так делать? Конечно! Работать будет? Вполне. Некоторое время. Только доступный абонентам сервис будет все уже и уже. Доступ извне? Зачем? P2P сети? Ненужно. SIP телефония? Не скрепно. И т.д. Итог один : вместо поредоставления доступа в интернет, вы предоставляете некий доступ к некому сервису. "Доступ к VK и Госуслугам из дома", "чат с друзьями в MAX", "видео с Рутуба". Остальные пртоколы и сервисы вам не нужны, значит и нечего огрод городить. Тем более заморачиваться с IPv6 от которого ничего кроме головной боли. Мы как-то проглядели момент, когда временное и приносящее неудобства и ограничения решение NAT на IPv4 стало теплым и ламповым, а полноценная свобода доступа в инет стала пугающей и ненужной.
Кстати, цены на блоки IPv4 снижались, но похоже стабилизировались и начинают снова расти в цене. Есть много трактовок причин, суть в том, что это не принципиальное падение интереса к IPv6, а не более чем отсрочка в процессе перехода.
Разумеется отсрочка. И явно не на год.
А на 10 или на 100 никто не знает.
Учитывая цикл обновления оборудования провайдерами и пересмотра архитектуры, я думаю, что в ближайшие 5 лет основной тренд будет в переводе публичных ресурсов на DualStack и предоставление IPv6 по умолчанию. Сама миграция (включая внутренние сети) - ближайшие 10-15 лет.
Тут хорошее видео в комментах выкладывали. С людьми которые руководят всем этим. Это не нужно провайдерам. И мешает контент провайдерам.
Что-то будет только в тех странах где регуляторы заставили. В целом какого-то движения можно не ожидать.
Так дело не оборудовании, оно давно готово.
То, что оборудование поддерживает IPv6, это не значит, что осталось пнуть рубильник и все заработает. Для оператора это:
Дизайн архитектуры, план адресации, написание HLD, LLD, ModOps
Тестирование конфигурации в testbed
Интеграция мониторинга в cockpit
интеграция с СОРМ
Интеграция в утилиты OSS (а то и дописывание утилит)
Обучение инженеров и команд эксплуатации
и многое другое, от маркетинга до поддержки
наконец сама конфигурация на роутерах разных уровней, BNG, MAP-T BR
допиливание софта для пользовательских CPE, со своими дизайном, спецификациями, тестированием
И это отдельно для бекбонов, агрегации, датацентров и т.д.
именно
поэтому ваше
Учитывая цикл обновления оборудования провайдерами
несколько наивно )
чуть выше выкладывал видео, фактически все поигрались с ipv6 и отложили в долгий ящик. потому что реальное внедрение требует расходов, а выхлопа ровно ноль.
Да нет, вполне. Цикл плановой смены оборудования в среднем 5-10 лет, апгрейдов оборудования 4-7 лет (сильно зависит от роли оборудования), обновления софта - 2-3 года. На развертывание IPv6 с нуля (со всеми перечисленными пунктами) в среднем уйдет 1,5-2 года (если не форсировать). Если для развертывания требуются фичи, которые доступгы только в новых версиях и требуется обновление - развертывание обычно координируется с плановым обновлением. Это может сдвинуть время развертывания до 2-3 лет. Если требуется увеличение физической емкости - здесь зависит от конкретной ситуации, конкретного оборудования и его производителя, какого ресурса конкретно не хватает и оценки рисков и рынка. Может привести к дополнительной задержке, а может нет. В любом случае 3-4 года на разворачивание с нуля крупным провайдером это вполне рациональная оценка.
Плюс на это накладывается анализ рынка и планирование бюджета - обычно на 2 горизонта: на 3 года и на 5-6 лет вперед, что тоже кореллирует с оценкой развертывания.
Цикл плановой смены оборудования в среднем 5-10 лет, апгрейдов оборудования 4-7 лет (сильно зависит от роли оборудования), обновления софта - 2-3 года.
это было бы убедительно, если бы все эти сроки не прошли уже по несколько раз.
получается как с термоядом, последние лет 50 говорят «через 20 лет», тут же последние лет 20 говорят «лет через 5».
не удивлюсь, если промышленный термояд случится раньше, чем 90% ipv6 на графике гугла )))
То, что два канала одного провайдера перестанут работать вместе очень низка, так как возможные SPOF могут быть только на уровне сетей доступа, а все что выше, начиная от агрегационных сетей и бекбона, имеет избыточность как минимум n+1.
Вы недооцениваете разнообразие возможных точек отказа.
Вспомните недавний случай с Cloudflare: точкой отказа стал процесс распространения конфигурации.
А вот в схеме с двумя провайдерами сбой в распространении конфигурации одного их них причиной отказа бы не стал.
От ошибок и недочетов в дизайне и в реализации не застрахован никто. Но есть SPOF которые присутствуют изначально, они заложены в самой архитектуре. Например PON или телефонный коллектор не имеют резерва изначально, потеря OLT или DSLAM априори означают потерю всех подключенных к ним абонентов. В противоположенность им подсистема DNS всегда строится с избыточностью, но это не означает, что ошибка в скрипте не может гипотетически положить все сервера разом. Потому есть оценка надежности, есть вероятность отказа, есть методика использования схожих систем от разных производителей чтобы минимизировать риски, есть тесты BCP, есть "план B" для соблюдения SLA даже когда отказывает то, что не должно было отказать.
DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6
Переходной период который идет десятилетия и будет идти еще десятилетия минимум это не переходной период а навсегда. По меркам любого бизнеса. Так к этому и относятся.
Просто надо было делать нормальную обратную совместимость, и уже сам рынок со временем решил бы, умирать IPv4 или нет. Не могу понять, почему в пространстве IPv6 нельзя было выделить подпространство IPv4 и тупо сделать стандартный шлюз туда и обратно.
Его разрабатывали в начале 90тых. Интернет тогда был другим. Тогда технологии менялись очень быстро. Вот и решили что нормально, за несколько лет все перейдут.
Включить пространство v4 в v6 это не проблема вообще. Проблема во всем прочем - нельзя было сделать обратную совместимость, даже просто увеличив поля под адреса в заголоке. Проблема не в IPv6, а в IPv4, последний не поддается модернизации.
Но опять же, решить только проблему нехватки адреса - это костыль, который не решал прочие врожденные недостатки IPv4. И когда стало ясно, что совместимости не будет даже при минимальных изменениях, то было решено создать новый протокол с нуля и заодно исправить недочеты предыдущего протокола. И это правильно.
Точно нельзя? А если подумать?
За окном 2025 года. Прочих недостатков не наблюдается. Нужно только немного увеличить адресное пространство и будет совсем хорошо.
Что мешает заворачивать пакет IPv4 в особый тип пакета IPv6 и передавать его через IPv6? Сейчас уже, конечно, поздновато это делать, но изначально можно было предусмотреть.
Ну и аналогично, уметь заворачивать пакет IPv6 в пакет протокола-надстройки над IPv4.
Нужно, чтобы обе сети могли пропускать трафик друг для друга, тогда переход на чистый IPv6 произошёл бы гораздо быстрее.
Это просто туннелирование, оно никоим образом не решает вопрос оперирования конечных устройств по новому протоколу и фактически означает не-переход на новый протокол.
Как бы и IPv4 over IPv6 и IPv6 over IPv4 были предложены практически с самого начала.
Даже в нескольких вариантах разной степени замороченности. Особенно второе. Что, скорее всего, и было ошибкой, т.к. позволило операторам разными способами лениться и делать вид, что 'внедряют'
Я скорее вот что имел в виду. Если бы машина на IPv6 могла свободно пользоваться всеми ресурсами, которые поддерживают только IPv4, то переход был бы значительно быстрее.
Если бы машина на IPv6 могла свободно пользоваться всеми ресурсами, которые поддерживают только IPv4
Все равно что-то должно IPv6 пакет преобразовать в IPv4 пакет, чтобы IPv4-only устройство его поняло. И этот механизм таки был придуман (там не совсем свободно, но достаточно хорошо)
Прямо тут в обсуждениях ищем NAT64.
Вы не думали что операторы это крупный бизнес, ворочающий миллиардами. Говорить про них "лениться" это изначально неверно ставить вопрос. И такая постановка вопроса только отдаляет от ответа.
Операторам нужно что-то что дает плюсы. Им самим или их абонентам. ipv6 не дает ничего. И стоит денег. И зачем? Нормальная совместимость в обе стороны дала бы оператору плюсы. Можно делать одну сеть и в ней все будет работать, а не две как их сейчас пытаются заставить. И делать эту сеть можно постепенно. Оно будет включаться постепенно.
Постепенное обновление это то что любит крупный бизнес. И расходы на него легко обосновать.
У меня ощущение что MultiWAN для физика(то есть без своих адресов) это тот случай когда нужен NPTv6(облегченный NAT, за счет замены только префикса, тогда роутеру не нужно хранить таблицу NAT).
То есть имеем локальную сеть с приватным /64 диапазоном, далее на выходе каждого интерфейса преобразуем в аналогичный /64.
Как иначе, идей нет.
Три WAN'а можно завести через три дефолтных маршрута с разными метриками. Правила для внутренних устройств — NAT66. Либо можно завести свой глобальный /64 префикс и заставить провайдеров его маршрутизировать. Но последнее сложно, по-моему.
Абсолютно никаких проблем не испытываю с IPv6. Ни внутри офиса, ни дома, ни в провайдерской сети. Работает, есть не просит, настроек по умолчанию в 95% случаев хватает.
Даже самые дешманские роутеры вроде туполинка нынче умеют дуалстек, и даже файерволл на них работает нормально. Случаи когда индусы оставили дыру в прошивке в расчёт не берём, тут и IPv4 не панацея.
Присоединяюсь. С ipv6 вроде бы понятно - каждое устройство получает свой "белый v6-адрес", но в тоже время если хочется доступ к протоколу по схеме ipv4 (nat), то... хрен его знает как это реализовать. Я намучался с домашним микротом когда провайдер даёт через префикс по pppoe, и может я не компетентен, окей, но это очень неочевидно по настройке. Остаётся только отключать ipv6 на ненужных устройствах вручную, потому что хочется избежать лишние зоны потенциальных проблем с сетевой безопасностью. Нет гарантий что условную умную лампочку через сеть по ipv6 не ломанут, а за nat'ом роутера хотя бы роутер выступает "барьером". Так же пробовал v6 раздавать "vpn-клиентам" до своего микрота, тоже нифига, там если внутри канала broadcast'ы не ходят (а-ля "точка-точка" до другого роутера) то хоть руками прописывай - не работает, и в тоже время на ipv4 всё легко, просто, понятно
Pv6 не дает плюсов нигде, особенно для частников с сеткой внутри квартиры/дома
А как же статичный адрес для домашнего NAS и "умного дома"?
IPv6 не дает плюсов нигде, особенно для частников с сеткой внутри квартиры/дома
Ну конечно. Частнику и даёт в первую очередь: прямой доступ до домашних устройств, где сейчас надо или у провайдера просить белый IP, настраивать проброс портов до хранилища или камеры, а так будет доступ до своего домашнего хранилища напрямую, без всяких "облачных сервисов" и прочей параши по обходу NAT.
У меня уже целый интернет внутри интернета, в не VPN, с OSPF с зонами и даже парой Mikrotik CHR на VPS для какой-никакой централизации, чтобы был прямой доступ по IP у устройствам клиентов без покупки каждому белого адреса и сверления дырок в NAT.
прямой доступ до домашних устройств,
Не дает, потому что ОпСоСы положили болт на IPv6, как итог - ну присвоен моему NASу IPv6 адрес, ну доступен он напрямую, подключаться то откуда? С работы нельзя (NDA), с мобилы нельзя, половина (а то и больше) провайдеров не поддерживают IPv6 (тот же дом.ру у родителей так и пишет - сорян, тебе не положено).
Единственный профит от IPv6 - торренты - больше сидов\пиров, прямые подключения, снижение нагрузки на оборудование, но это как бы проблемы провайдера и его профит.
Не дает
Даёт. Всё что вы написали далее — это не проблема IPv6, а проблема его отсутствия.
Хорошая логика, многое объясняет:
- конские цены на жилье - это не проблема застройщиков, а проблема отсутствия денег у вас
- импортозамещение - это не проблема экономики и стимуляции, а проблема его отсутствия
- проблемы с персоналом в ОМС - это не проблемы ОМС, а проблема отсутствия людей
- проблемы с поставками оборудования\закупками\оплаты за границей - это не проблема платежной системы, а проблема ее отсутствия (подразумевается отсутствия той которая работает и в РФ, и за границей)
Ну конечно. Частнику и даёт в первую очередь: прямой доступ до домашних устройств, где сейчас надо или у провайдера просить белый IP, настраивать проброс портов до хранилища или камеры, а так будет доступ до своего домашнего хранилища напрямую, без всяких "облачных сервисов" и прочей параши по обходу NAT.
Я, с вашего позволения, уведу диалог немного в сторону. Собственно даже не диалог, потому что это не возражение вам - возражать тут нечему, а мысли вслух. А именно, по мотивам процитированного и в дополнение к нему хочу сказать, что не уверен, что нынешний (и ближайшего будущего) так называемый IoT массово умеет в IPv6. Какие-то условные "умные" (на самом деле нет) розетки и выключатели на ESP8285 или ESP8566 - разве они смогут в IPv6 чисто аппаратно, по вычислительным ресурсам? А если смогут, то кто будет обновлять им прошивки? Если первый вопрос умозрительно интересен, то второй - очевидно риторический. При всей относительной дешевизне, никто не будет менять эти устройства только из-за какого-то там IPv6, который, к тому же, как выясняется, не у каждого провайдера в мире работает. Не менее неумных уютов с чайниками сказанное касается в примерно той же мере. Второй вопрос, который меня пока что по большей части умозрительно занимает, однако который глобально я бы считал более важным - то, что называют безопасностью. Пока корявые "умные" розетки не торчат голыми задницами наружу и их весьма надежно прикрывает NAT, что само по себе его побочная функция, а вовсе не основная, риски радикализации розеток и принесения ими клятв верности ботнетам остаются умеренными - не нулевыми отнюдь, но уже нельзя просто просканировать порты по случайному адресу и проэксплуатировать общеизвестную в узких кругах уязвимость, до которой производителю "умных" розеток дела нет никакого. Получается как с VPN, задача которого вовсе не в обходе блокировок, но в некоторых частных случаях побочный эффект оказывается ценнее основного предназначения. Так и с NAT, побочный защитный эффект сетевого экрана координально кардинально снижает количество заражений по миру в среднем.
Так-то да, белые IP для всего и возможность, наконец, снова всем связываться со всеми, а не только через проприетарное облако производителя софта для умных розеток - это благо. Но и риски. Что вы выберете, если на кону защита детей™? Да, это сарказм, детектор вас не подвел.
У меня уже целый интернет внутри интернета, в не VPN, с OSPF с зонами и даже парой Mikrotik CHR на VPS для какой-никакой централизации, чтобы был прямой доступ по IP у устройствам клиентов без покупки каждому белого адреса и сверления дырок в NAT.
А вы не показатель. Ни вы, ни любой другой сетевик, что про, что любитель - тут же не корочки важны, а понимание и навык, как это все настроить. Почти все, кроме таких как вы, включая нередко даже совсем уж уважаемых программистов, но в других совсем областях, имеют представление о вопросе от абсолютно нулевого до "ну, примерно слышали, но пока необходимости вникать не было". И все же, настойчиво повторюсь, NAT неплохо прикрывает задницы большого количества устройств, разработчики которого проявили ровно нулевое рвение в обеспечении их безопасности от взлома и злонамеренного использования. Да и разработчики уровнем куда как повыше, бывает, допускают ошибки - я про разработчиков массовых операционных систем, например. В результате устройство, которые ранее мы называли словом роутер, теперь все равно должно оставаться, но выполнять функции сетевого экрана, причем изначально быть сетевым экраном, а не случайно-побочно, как NAT. Иначе, наверное, достаточно неуправляемого коммутатора, чтобы разделить единый кабель от провайдера на всех желающих в доме, но без какой-либо логики. Тогда все вывалится голыми задницами наружу и тогда каждый спасайся кто как может.
Выше в каментах было замечание, что количество адресов в пространстве IPv6 таково, что просканировать их нереально. Плохо ты, брат, мадьяр знаешь © Швейк. Мощности современных ботнетов поболее, чем у парочки школьников, что прочитали новую статью в журнале Хакер.
То есть смешанные чувства именно от того, что свобода принесет риски, и если мы (энтузиасты) к ним готовы - кто буквально, кто подтянется, то безответственная масса просто юзеров - нет. И именно из-за их безразличия проблемы могут быть у нас.
а ESP8285 или ESP8566 - разве они смогут в IPv6 чисто аппаратно, по вычислительным ресурсам?
Могут. Всякому IoT на Link Local (ибо глобально маршрутизируемый IPv6 нафиг надо), похоже, даже легче и проще.
В результате устройство, которые ранее мы называли словом роутер, теперь все равно должно оставаться, но выполнять функции сетевого экрана, причем изначально быть сетевым экраном, а не случайно-побочно, как NAT.
Собственно это и происходит де факто уже много лет. Обычный юзер не имеет (да и не должен иметь) желания собирать у себя целую сеть из отдельных узкоспециализированных устройств и для этого разбираться с кучей технологий и протоколов. Потому вполне логично, что необходимые функции и сервисы интегрируются в одну коробку - роутер, файерволл, точка доступа WiFi, шлюз IP телефонии, файловый сервер. Обьеденить все это в одной коробке логично как для провайдера (которому удобнее предоставлять все эти сервисы как единый пакет услуг в одной коробке), так и для пользователя, так как снимает с него всю головную боль. Наверно это звучит банально и очевидно, но это вполне естественное положение вещей.
Пока корявые "умные" розетки не торчат голыми задницами наружу и их весьма надежно прикрывает NAT,
Но если эту розетку заразят из локальной сети (вполне возможно) - то такая розетка отлично наружу будет ходить, команды от центра управления принимать и сливать разное интересное (если это не розетка, а, скажем МФУ со сканнером). Мало же кто firewall настраивает "это наружу не пускать".
А устройство на IPv6 Link Local - не сможет.
Так что для локальных устройств IPv6 в его локальном использовании - просто замечательно.
что нынешний (и ближайшего будущего) так называемый IoT массово умеет в IPv6.
Те, что я видел, купленные по 700 рублей на маркетплейсах — уже умеют и v6 и по облакам ходить и по wifi работать.
Пока корявые "умные" розетки не торчат голыми задницами наружу и их весьма надежно прикрывает NAT
В современном интернете домашний роутер без закрытой по умолчанию фаерволом внутренней сети весьма маловероятен, а если даже и появится, то шуму будет много и любая домохозяйка будет знать, что он небезопасный.
NAT неплохо прикрывает задницы большого количества устройств, разработчики которого проявили ровно нулевое рвение в обеспечении их безопасности от взлома и злонамеренного использования
Да херово он прикрывает, точнее никак. Розетки ваши никому не нужны, а про "взломанные" асики даже за натом я каждую неделю читаю в чатике копателей криптографических монет.
Так и с NAT, побочный защитный эффект сетевого экрана
координальнокардинально снижает количество заражений по миру в среднем.
Эта проблема решается встроенным в любой роутер фаерволом
А вы не показатель. Ни вы, ни любой другой сетевик, что про, что любитель - тут же не корочки важны, а понимание и навык, как это все настроить.
Тем не менее факт этого гемороя от отсутствия v6 — есть. Без VPN пришлось бы или заказывать статику у операторов(а не все её ещё дают), платить за неё, делать пробросы портов.
Эта проблема решается встроенным в любой роутер фаерволом
Это проблем решается(смотри моей сообщение выше) тем, что устройство должно работать на тех адресах, которые в Интернет не ходят. Но в IPv4 изобрели NAT и теперь каждая железка из 192.168.* ходить в Интернет на сайт производителя и вообще куда попало.
Так что сторонникам IPv6 нужно и эту сторону происходящего тоже рекламировать, а не только глобальную маршрутизацию.
Это проблем решается(смотри моей сообщение выше) тем, что устройство должно работать на тех адресах, которые в Интернет не ходят. Но в IPv4 изобрели NAT и теперь каждая железка из 192.168.* ходить в Интернет на сайт производителя и вообще куда попало.
Убираем в настройках железа шлюз и они никуда не ходят, если на роутере не получается закрыть. В IPv6 как раз NAT нет, и есть link-local адреса, с которых в интернет не походишь.
Убираем в настройках железа шлюз
Имеется в виду случай, где пользователь ничего такого не делает и не думает, что надо. Вроде бы у условных лампочек на IPv4 по умолчанию не так.
В IPv6 как раз NAT нет, и есть link-local адреса, с которых в интернет не походишь.
Так и я про то же. Лампочку, что садится на IPv6 link local ввинтил, она адрес себе выбрала - и работает. Недоступная снаружи независимо от того, что там на маршрутизаторе накрутили.
А нам тут про полезность NAT одна сторона рассказывает, и про полезность глобальной маршрутизации - другая.
В этом смысле IPv6 в локалке полезен даже если у тебя IPv6 связности до глобального интернета нет.
А как ваша недоступная снаружи лампочка включаться будет, когда Алиса попросит китайский сервер, чтобы он ее включил? Мы же про рядовых пользователей, которые лампочки по одной докупают, а не тех которые дизайн умного дома с центральным хабом одновременно с ремонтом и протяжкой электрики заказали вместе с дизайном.
А как ваша недоступная снаружи лампочка включаться будет, когда Алиса попросит китайский сервер, чтобы он ее включил?
Ее включит хаб, работающий в той умной колонке в которой Алиса 'установлена'.
На данный момент включает так, как я описал. Есть китайская сеть лампочек и Алиса, умеющая в их АПИ. и их приложение для телефона, умеющее в их АПИ, а хаба в квартире архитектурно у китайцев не предусмотрено. Так как они готовы продать одну лампочку с приложением в телефон. И работать она будет не из одной локальной сети, а с расположением телефона где угодно на шарике.
Хоть бы кто назвал компанию. Соседний собеседник тут то же самое утверждал, но не сказал производителя.
Но, вообще, я не очень верю, что не предусмотрено. Скорее всего они не хотят и не предлагают API для того, чтобы кто-то другой ими управлял, а их собственный хаб - это можно. Они что, дураки что ли упустить шанс продать еще одну железку.
Производитель известный - Noname. А "облако" держит вообще третья контора, нам известная как Tuya - они устройства, насколько я знаю, не производят в принципе. У Tuya есть конкуренты, я слышал про eWeLink, возможно есть и другие. Но уже только эти два вместе взятые - это почти все китайские устройства. Вернее наоборот, почти все китайские устройства от неисчилимого количества производителей, брендов и перепродавцов, работают через одно из этих "облаков" и, посредством их приложения для телефона, позволяют создавать какое-то подобие сценариев и автоматизации со взаимодействием разных устройств.
То есть все эти разношерстные приспособления, часто собранные на ESP8285, ломятся в свое облако через NAT и слушают порт 6668. Для пользователя оно "просто работает".
А "облако" держит вообще третья контора, нам известная как Tuya
Вот. И именно они на домашний хаб и дерганье устройств по локалке вполне подписались.
Или вот тут - смотрим сколько на картинке квартиры 'Control Hub'
У eWeLink: Ну где-то так (выделение мое):
Enjoy all the local-first features of eWeLink CUBE — from built-in Matter Bridge and Zigbee Dongle compatibility, to CAST dashboards, Docker add-ons, and remote access — without being tied to a specific device.
Так что хотя привязка к их экосистеме и серверам есть - это не означает, что их IoT железки без доступа к интернету работать не могут/не будут. Если не сейчас, то в скором будущем. Хабам, может и нужно будет а вот всему остальному - ой не факт, что оставят это безобразие, что жертва прогресса может без покупки хаба обойтись.
IPv6 тут не нужен, достаточно IPv4. Например в WIndows роль link-local с давних пор отлично выполняет сетка 169.254.0.0/16 (называется это APIPA). Что там с ее поддержкой в IoT - не в курсе, но, в общем-то технических проблем нет.
Выше в каментах было замечание, что количество адресов в пространстве IPv6 таково, что просканировать их нереально. Плохо ты, брат, мадьяр знаешь © Швейк. Мощности современных ботнетов поболее, чем у парочки школьников, что прочитали новую статью в журнале Хакер
даже если сканировать не случайный префикс, а тот, о котором мы точно знаем, что он выдан и используется, то количество адресов в подсети /64 в 4 миллиарда раз больше, чем всех адресов IPv4. Возьмите и подсчитайте, сколько времени займет просканировать только один порт в одной такой подсети. А если нужно проверить несколько портов и префиксов? Если сканировать последовательно, то это займет тысячелетия, потому что пинг, а если параллельно, то сколько нужно инстансов сканера запустить просто для одного префикса? Просто приблизительно прикиньте.
IPv6 не дает плюсов нигде, особенно для частников
Ну лишком категорично. Отсутствие NAT это уже огромный плюс для любого P2P, от торрентов до игр и прямого доступа к домашнему NAS. Не нужно с пробросом портов возиться.
Работающий pmtud в ipv6 (Path MTU discovery) уже того стоит.
ipv6.disable=1 в грубе
недавно переехал с убунты на дебиан, думал может не тргать и хай будет, но всю дорогу что-то где-то косячит из-за недоступности то одного то другого. Вынес нафиг и больше не буду себе ещё и этим жизнь усложнять
Мне вот видится - каждому мобильному устройству присвоить уникальный IP, установить WEB-сервер - и дальше сплошной peer-to-peer без регистрации и СМС. Может, поэтому его и тормозят.
и дальше сплошной peer-to-peer без регистрации и СМС
Ага, даешь ботнет в каждый дом! ;-)
Ботнет это следствие дыр в прошивках и операционках устройств и халатности в настройке файерволов. Никакого прямого отношения к тому или иному стеку это не имеет. Ботнеты и черви появились до развертывания IPv6.
Дык я и не специально про IPv6. Просто сейчас, когда всё за NAT, использовать все эти уязвимости составляет некоторую сложность: надо влезть за NAT, а уникальные доступные ото всюду адреса эту сложность убирают.
А дыры в ПО и ошибки настройки были, есть и будут, вне зависимости от версии IP.
Я понимаю о чем вы хотите сказать и NAT действительно создает иллюзию большей защищенности нежели возможность соединений без трансляции. Но это является одним из распространенных мифов о IPv4 vs IPv6. Механизмы заражения устройств ботнетами весьма разнообразны и некоторые проходят в несколько этапов, зачастую с преодолением NAT в итоге.
Что IPv4 с NAT, что IPv6, оба нуждаются в файерволе, потому сравнивать безопасность "открытых всем ветрам" конфигураций попросту некорректно.
Я понимаю о чем вы хотите сказать и NAT действительно создает иллюзию большей защищенности нежели возможность соединений без трансляции
Не иллюзию - NAT действительно уменьшает поверхность атаки, из-за невозможности атаки с помощью простых входящих подключений.
Механизмы заражения устройств ботнетами весьма разнообразны и некоторые проходят в несколько этапов, зачастую с преодолением NAT в итоге.
Если вы - не засекреченный физик, то опасностью атаки на устройства за NAT можно пренебречь: никто хитрые сценарии специально под вас с проникновением сначала на один хост, потом с него - во внутреннюю сеть, где не что-то стандартное, а зоопарк, под который надо подстраиваться, реализовывать не будет - овчинка выделки не стоит. А потому брандмауэр для внутренних устройств в этом случае не нужен, а на маршрутизаторе не требуется дополнительная конфигурация при появлении устройства во внутренней сети.
Но все эти преимущества испаряются с появлением в ней общедоступных IPv6 адресов. Точнее, ровно той же безопасости можно достичь, если на маршрутизаторе запретить все входящие подключения внуть сети, но поклонники IPv6 так не хотят и соблазняют некими сомнительными "преимуществами".
Точнее, ровно той же безопасости можно достичь, если на маршрутизаторе запретить все входящие подключения внуть сети
это так.
но поклонники IPv6 так не хотят и соблазняют некими сомнительными "преимуществами"
откуда вы это взяли? Нет ничего плохого в том, чтобы иметь на файрволе по умолчанию закрытые входящие подключения. Но разница в том, что если у вас CGNAT, вы никак не сможете открыть порт, а на своем личном роутере сможете.
откуда вы это взяли?
Да вот где-то тут в комментариях уже один из них за P2P топил, да ещё и с аргументацией, что Microsoft с Valve что-то от этого хорошее получат (а мне-то до них какое дело?).
если у вас CGNAT, вы никак не сможете открыть порт, а на своем личном роутере сможете.
CGNAT, как я понимаю, дозвляет то, что в описании Teredo называлось симметрическим NAT - когда комбинация внешнего адреса и порта не определялась однозначно комбинацией внутреннего адреса и порта. Может, его - того, запретить, чтобы Carrier'ы не своевольничали, и добрым людям Torrent'ами зазря пользоваться не мешали? Всё равно ведь он порты с адресами не экономит. Наверное, это проще, чем всю эту мухорайку с IPv6 городить?
Речь не обо мне. Я-то смогу, потому что много какими брандмауэрами за свою жизнь порулил - начиная с ipfw на древней Slackware (ядро Linux 2.0), на котором и NAT-то ещё не было. А вот смогут ли простые люди, да так, чтобы не накосячить? Сомневаюсь.
Да вот где-то тут в комментариях уже один из них за P2P топил
ну, в принципе, да - главным преимуществом IPv6 для обычного юзера является беспроблемный P2P.
CGNAT, как я понимаю, дозвляет то, что в описании Teredo называлось симметрическим NAT
это просто NAT, а какой он - симметрический или нет, зависит от настройки у провайдера.
Может, его - того, запретить
запретить CGNAT? Я был бы не против. CGNAT - это зло. Но вряд ли провайдеры имплементируют у себя CGNAT просто из вредности. Им не хватает IPv4. Вот IPv6 и призван решить данную проблему.
А вот смогут ли простые люди, да так, чтобы не накосячить? Сомневаюсь
не нужно считать всех вокруг идиотами. Если кому нужно (для торрентов, например), то он настроит проброс портов по инструкции (если используется IPv4 без CGNAT). Так же он откроет один порт в файрволе в случае с IPv6.
ну, в принципе, да - главным преимуществом IPv6 для обычного юзера является беспроблемный P2P.
... который этому пользователю практически не нужен.
это просто NAT, а какой он - симметрический или нет, зависит от настройки у провайдера.
Ну да, carrier-grade. Но вот слово "дозволяет" вы проигнорировали. А зря.
запретить CGNAT? Я был бы не против.
Весь запрещать не надо. Только тот, который не конический. Чтобы пробивка тоннелей работала предсказуемо. И сразу решится проблема с тем, что P2P трафик пускать мимо выделенного сервера нельзя. То есть, тем немногим, кому P2P таки нужен - он будет именно как P2P - без узла для обмена трафиком. И ещё раз повторяю, что такое решение проще, чем IPv6, который подобен "Интернационалу": "Весь мир .. мы разрушим. До основанья а затем мы наш мы новый мир построим." Революции нам тут не нужны - от них много побочных эффектов.
не нужно считать всех вокруг идиотами.
Они не идиоты - они специалисты в другой области. В которой идиотом окажусь я, если в нее полезу. И совершенно незачем учить всех что-то там настраивать: чем проще - тем лучше. Ну, а уж как творчески люди могут понимать и выполнять инструкции... А вы так пишете, как будто с этим не сталкивались.
PS Для "без CGNAT" в Windows есть UPnP, и он таки работает, если домашний маршрутизатор поддерживает.
Весь запрещать не надо. Только тот, который не конический
а как это практически сделать? Кто будет смотреть за соблюдением запрета?
И совершенно незачем учить всех что-то там настраивать: чем проще - тем лучше
UPnP не всегда включен и работает, поэтому иногда требуется вручную пробрасывать порты наружу. Это делается достаточно несложно. Так же несложно, как и открыть порт в IPv6.
а как это практически сделать?
Это технический вопрос. ;-)
Кто будет смотреть за соблюдением запрета?
Регулятор. Можно пользователям програмку дать, которая это проверяет, а уж они регулятору сами жаловаться будут.
UPnP не всегда включен и работает
Если не включен - в Windows включается одной галочкой (или, там, движком). Короче - штука вполне пользовательсткая, никаких цифр водить не требует, в отличие от проброса порта, и сделать можно один раз и забыть. И, главное, проброс происходит, только когда надо и только нужного порта, ошибку допустить трудно.
И, главное, не надо весь этот огород с IPv6 у провайдера городить.
... который этому пользователю практически не нужен.
Ага, именно по этому все с свое домашнее видеонаблюдение ходят через китайские облака. Не нужен, ага. И энидеском пользуются, а не бесплатным встроенным RDP именно потому что прямой доступ на нужен. Вы уже настолько привыкли ко всем этим средствам обхода NAT, что их даже не замечаете
Ага, именно по этому все с свое домашнее видеонаблюдение ходят через китайские облака
Ходят, потому что поставщик решения так сделал. Большинство пользователей по-другому и не смогут.
А у поставщика свой резон так делать есть, например, чтобы создать замкнутую экосистему, чтобы другие свои железки с IoT продавать конкуренты не мешали. А потому с IPv6 он сделал бы точно так же, через свое облако.
И энидеском пользуются, а не бесплатным встроенным RDP именно потому что прямой доступ на нужен.
Пользователи (простые) ни тем, ни тем не пользуются. Да и что им делать на домшнем компьютере, если все полезне им данные - в облаке.
Ходят, потому что поставщик решения так сделал. Большинство пользователей по-другому и не смогут.
Он там сделал, чтобы клиенту в мире NAT было прощею
А у поставщика свой резон так делать есть, например, чтобы создать замкнутую экосистему
Какая экостистема у xmeye? Сплошная обуза.
Пользователи (простые) ни тем, ни тем не пользуются.
Ещё как пользуются. Ходят на рабочие компы из дома, из отпуска. Это самые простые пользователи в SOHO сегменте.
Ходят на рабочие компы из дома, из отпуска.
Это уже не домашнее использование. И для него есть штатный способ решения - это RD Gateway на белом IP или за reverse proxy (он по HTTPS работает, в SSL Offload тоже умеет), там заодно можно и разграничение доступа настроить - кому на какие компьютеры ходить можно. Когда-то давно, когда ещё был актуален Forefront TMG, я даже статью про это написал (не на Хабре). Выставлять же сервер RDP 3389-м портом наружу - весьма небезопасно: попытки подбора пароля сразу начнутся, а пользователей построить, чтобы они неподбираемые пароли делали - это сложно, а кое-кого и не построишь, административного веса не хватит. И точно так же со всеми ресурсами локальной сети: не стоит давать к ним доступ из мира, потому что есть по жизни такое правило безопасности: пароли у пользователей следует считать слабыми, всегда.
Это уже не домашнее использование.
Самое, что ни на есть домашнее. Непрофессионалы сами ставят, сами из дома лезут)
И для него есть штатный способ решения - это RD Gateway на белом IP
Вот это профессиональное, да.
а пользователей построить, чтобы они неподбираемые пароли делали - это сложно, а кое-кого и не построишь
Из таких был только владелец компании, и то по удалёнке он не заходил, пароль стоял сложный, а его комп включался с сохранённым. Там своя защита была — ключ от кабинета)
Остальные ставили пароли такие, какие принимал контроллер домена.
И точно так же со всеми ресурсами локальной сети: не стоит давать к ним доступ из мира
Все и не надо, а только некоторые, которым нужен доступ снаружи.
RDP, кстати, наружу висел несколько лет до меня, при мне, пока всех не загнал в VPN, и никто не поломал, хотя один из висевших был даже Windows 2003
Самое, что ни на есть домашнее. Непрофессионалы сами ставят, сами из дома лезут
Но не наоборот, не домой ведь? И я про то, когда домой. На предприятии-то можно всегда по уму сделать безо всякого IPv6, во всяком случае для него белый IPv4 завсегда завести можно.
А так - получается непрофессионально. Диски, к примеру, свои локальные пробрасывают и програмы с них запускают ("а чо такова?").
Остальные ставили пароли такие, какие принимал контроллер домена.
С нестандартной passfilt.dll на каждом? Ну-ну, удачи в поддержке: после первой же проблемы начальство даст команду снести эту х**ню. А стандартными ограничениями много не настроишь - там запросто можно сделать себе общеизвестный пароль типа !QAZ2wsx (мало длины? - добавим 3edc), который у любого скрипт-килди его скрипт пробует - и оно его съест.
А дома у пользователя никаких контроллеров доменов нет. Даже если на роутере Samba поднять можно.
RDP, кстати, наружу висел несколько лет до меня, при мне
Ну, если не ограничивать попытки входа пользователей, то можно. Но не ограничивать страшно.
Короче, основная мысль: IPv6 не дает ключевых преимуществ,, достаточных для того, чтобы заморачиваться переходом на него.
С нестандартной passfilt.dll на каждом?
Самый, что ни на есть, стандартный.
А стандартными ограничениями много не настроишь - там запросто можно сделать себе общеизвестный пароль типа !QAZ2wsx (мало длины? - добавим 3edc), который у любого скрипт-килди его скрипт пробует - и оно его съест.
Кроме пароля ещё имя пользователя есть, откуда анонимный скрипт-кидди его узнает? У меня сервер с открытым ssh домашний больше 20 лет стоит, даже имя пользователя ещё ни разу правильно не ввели, всё root да admin долбят.
Но не наоборот, не домой ведь?
Не следил, может кто-то и лазит. Юзеры, когда надо им, всё умеют. Бухгалтерша в отпуске в Египте сообразила, что если включить VPN и попасть в интернет через конторский интернет, то интернет-банки заработают.
Короче, основная мысль: IPv6 не дает ключевых преимуществ
Оператору не даёт. А пользователи настолько привыкли к костылям, что их уже не замечают, а многие и вовсе считают нормой
А пользователи настолько привыкли к костылям, что их уже не замечают, а многие и вовсе считают нормой
А всё потому что им IPv6 в массе преимуществ не дает: и сами они воспользоваться ими не смогут, и бизнес-модели на их вовлечении для третьих лиц не просматривается (ну, если не считать бизнес-моделью ботнет ;-) ), рисками своими пользователиуправлять тоже не могут - а риски от IPv6 растут...
Потому IPv6 30 лет всё внедряется и внедряется, но внедрится никак не может: нет золота в Серых горахIPv6.
Вот по примерно таким ж пониманиям технологий мы имеем мильарды хостов для ботнетов, которые атаковали на днях Cloudflare. Все те, кто выступают за IPv6 в каждый дом/устройства, отличные технари, безусловно, но вот почему-то упускают из вида, что настроить 1 роутер и защитить всю внутреннюю сеть на пару порядков проще, чем защищать все конечные устройства.
Скажем так, у всех известных мне крупных западных публичных провайдеров, поставлямый провайдером пользовательский роутер имеет на борту файервол активный для IPv4 и для IPv6 для внешних входящих соединений. Если внутри домашней сети есть уже зомбированное оборудование, то дефолтная политика файервола заблокировать эти соединения не в состоянии. В этом плане нет никакой разницы между IPv4 и IPv6.
Вот по примерно таким ж пониманиям технологий мы имеем мильарды хостов для ботнетов
Эмм? Не вижу разницы между атакой по v4 и v6. А методы заражения, как уже сказали, различны и не обязаны быть связаны с v4/v6
но вот почему-то упускают из вида, что настроить 1 роутер и защитить всю внутреннюю сеть на пару порядков проще, чем защищать все конечные устройства.
Нормально закрытый фаерволл на soho-роутере (который скорее всего уже так и настроен по умолчанию) уже не в моде или почему-то он не работает для v6? Настроить блокировку forward для соединений без статуса established,related уже нельзя?
Подмена понятий. Ещё как имеет отношение к стэку.
Голубиная почта - это тоже стэк, приведите пример в каком случае этот стэк не защитит меня от вредоносных писем?
Почему подмена понятий? Я имел в виду, что сам принцип захвата устройства для превращение в члена ботнета возможен как на IPv4, так и на IPv6 - смотря где и какой найдется эксплоит и что доступно затем для отправки трафика. А так хоть ATM, IPX или голубиная почта. Лишь бы голубь знал как пролезть в форточку и так нагадить на роутер, чтобы тот замбировался и вошел в ботнет.
Перефразируя одного известного деятеля, "Зачем вам IPv6, у вас же интернета нет".
Основная проблема IPv6 - он не для людей, а для машин.
Если под внедрением ipv6 имеется ввиду что смартфон получил в автомате адрес от оператора, то пусть так и будет, этот человеконечитаемый адрес находится там-же где лежит его старший брат - МАК-адрес.
Но представить себе ежедневную работу с этимм адресами в корпоративной или домашней сети - ну нафиг. Логи сиема там почитать, правила в фаерволе написать, траблшутить ну или просто попытаться продиктовать это по телефону.. Не.. не нужно, не для людей.
Но представить себе ежедневную работу с этимм адресами в корпоративной или домашней сети - ну нафиг
А зачем? По-хорошему вы должны работать не с сырыми адресами, а с хостнеймами.
Логи сиема там почитать, правила в фаерволе написать, траблшутить ну или просто попытаться продиктовать это по телефону.. Не.. не нужно, не для людей.
Дело привычки. У меня тоже возникают проблемы с ipv6, но я отдаю себе отчет, что это из-за того, что я ленивая задница и нужно как-нибудь закрыть вопрос, перестав отключать ipv6 где только можно.
По-хорошему вы должны работать не с сырыми адресами, а с хостнеймами.
А откуда ж они возьмутся то? Волшебник придёт настроит? Или это новости из идеального мира, где бухгалтер разбирается в настройке DNS?
Решать проблему с нечитаемымой адресацией путём создания менее критичной проблемы с хостнэймами. Звучит как хороший план.
А откуда ж они возьмутся то? Волшебник придёт настроит? Или это новости из идеального мира, где бухгалтер разбирается в настройке DNS?
Ну, протокол mDNS уже придуман, осталось дождаться когда наконец популярные ОС до ума доведут.
Так-то на винде mDNS клиент уже есть, только пока несколько бесполезен (ибо никто протоколом не пользуется).
Так и IPv4 предназначен машинам, а не людям. :) Для читаемости IPv4 к нему был быстро придуман DNS.
Просто когда разрабатывали IPv4, люди работали куда ближе к железу - скорость в 300 бод была вполне значительной, коды непрямую содержали как отображаемые символы, так и управляющие коды, а дебагер представлял собой стальную раскладушку, куда вставлялась перфолента и через матрицу отверстий можно было пробить недостающие дырки.
То, что IPv4 недокрутили, чтобы совсем спрятать под капот - на то есть много причин. Это не значит, что не хотели, даже пытались исправить недостатки всякими "костылями". IPv6 позволил избежать этих недостатков и с самого начала проектировался с механизмами автоконфигурации. Так что для конечного пользователя большой разницы нет.
Как нет ее и для профессионалов, так как нет принципильной разницы в работе с IPv4 и IPv6. IPAM адоптировался, команды роутеров, утилиты отладки, интерфейсы систем управления, SDN - тоже. Ничего в сущности не поменялось. Нужно чуть времени чтобы привыкнуть.
Но представить себе ежедневную работу с этимм адресами в корпоративной или домашней сети - ну нафиг
Полностью согласен с точки зрения человеческого фактора, набрать fe80::dead:beef:cafe:babe по памяти нереально. IPv4 в этом плане куда дружелюбнее, да
Вот я об этом и говорил, когда писал, что IPv6 не для людей. Нельяз заполмнить, нельзя продиктовать быстро, долго вводить, короче мрак. А говорить, что не работайте с ИП, работайте с ДНС именами, так это так в жизни не работает, т.е. днс имена это побочный, не обязательный сервис, а IP адрес первичен. Какой нибудь IPS будет отдавать алерты по ИП-адресам, логи доступа снаружи - по ИП адресам, в общем эта абстракций на практике не работает, не удобна, не для людей.
Логи сиема там почитать, правила в фаерволе написать, траблшутить ну или просто попытаться продиктовать это по телефону..
Вы пытаетесь натянуть на v6 ваши представления о работе с v4. Не надо так, это неправильно. Вам не нужно их запоминать, диктовать по телефону… особенно с учетом того что у устройства для работы SLAAC должна вообще /64 подсеть быть доступна. И оно способно как менять адреса, так и иметь их десятки активными на интерфейсе
ipv6 гораздо лучше подходит для создания распределенной архитектуры сети, где каждое устройство может являться сервером, и доступно для адресации по айпи адресу (постоянному), как по уникальному идентификатору, независимо в какой физической сети оно находится и как подключено. Это исключает необхолимость создания "пробивающих" NAT-ы рандеву серверов, которые являются необходимым и узким местом при создании всяких месенджер в, которые у нас так любят блокировать.... возможно , торможение внедрения ipv6 связанно именно с боязнью появления анонимных, не убиваемых распределеных платформ, под которые уже легко будут написаны любые приложения - от корпоративных месенджеров и звонилок, до криптообменок и управления будущим, путем размещения анонимных ставок на события....
возможно , торможение внедрения ipv6 связанно именно с боязнью появления анонимных, не убиваемых распределеных платформ
Торможение внедрения IPv6 связанно исключительно с масштабностью необходимых изменений в сети без явной краткосрочной отдачи, на обновление програмного обеспечения, если оно разработано самой компанией и работает многие годы (первый закон "работает - не трогай" никто не отменял). Но в первую очередь все упирается в затраты на обучение персонала и острой нехватке сетевых дизайнеров, способных организовать переход компании на IPv6. IPv6 это фундаментальное изменение, которое необходимо делать планомерно и постепенно, а не в режиме аврала. Потому вызывает у менеджмента опасения и откладывается до лучших времен.
А плавно и постепенно его делать дорого. Надо две сети поддерживать десятилетиями.
Вот и получается что ни так ни сяк особого смысла и мотивации нет. Заплатить 40 баксов за ipv4 адрес выгоднее со всех сторон.
Нет, не так дорого. Например, требования к поддержке IPv6 включаются в список критериев при выборе нового оборудования (в цикле его регулярного обновления), в список требований дизайна архитектуры новых проектов, в список критериев при выборе нового ПО, разрабатывается план адресации IPv6 компании, включаются в требования к выбору провайдеров-аплинков и т.д. IPv6 внедряется по принципу best-effort, оказией, подспудно. Железо и программы не поддерживающие IPv6 вполне возможно сами уйдут в процессе цикла обновления еще до момента реального перехода на IPv6 компанией, а с другой стороны, вы будете уверены, что железо и софт, установленные на момент перехода, совместимы с IPv6. Такая постепенная миграция в фоновом режиме экономит время и усилия инженеров и менеджеров, требует куда меньших затрат и главное - позволяет избежать ошибок дизайна и сюрпризов в момент самого перехода. Параллельно это позволяет натренировать кадры (а точнее позволить кадрам самообучиться). Менеджменту легче согласиться на расход несколькх часов в неделю/ в месяц на этот фоновый процесс, нежели запускать революционный проект прехода на IPv6, с кучей инженеров, тестировщиков, шефом проекта, KPI, планингом и дедлайном. А главное с риском аварии в момент перехода или с упущением чего-то важного.
Да можно закрыть на время глаза заплатив за покупку IPv4 адресов. А если прогноз роста потребности - сотни тысяч адресов? Миллионы? Это не инвестиции, это просто потери, они не вернутся.
Все можно. Но все стоит денег. Прямо каждый пункт из вашего плана стоит денег. А его поддержка в рамках десятилетий стоит еще больше денег.
И деньги то в целом есть. Но выгода нулевая и непонятно зачем их на это тратить?
Нельзя ответить на "сферический вопрос в вакууме". Есть ли выгода и какова она - зависит от бизнеса компании. Для провайдеров это избегание покупки IPv4 и оптимизация и повышение эффективности тренспортной сети, для хостеров и облачников - новый уровень работы с приложениями и контейнерами, упрощение автоматизации развертывания хостов, для сетевых программистов - упрощение работы со стеком... Для компании производящей болты, шурупы и проволочки для бутылок шомпанского - наверно никакой. Тысячи случаев и в каждом случае своя ситуация.
Приведите пример бизнеса кому это выгодно. За исключение тир1 магистралов и бигтеха.
От покупки ipv4 адресов никуда не деться. И провайдеры и бизнес обязаны их покупать что бы они не строили. Дай бог к концу столетия можно будет рискнуть поднять ipv6 only сервис или такого же провайдера. Но я скорее верю в то что сделают Ipv8 и закопают это недоразумение.
Оптимизации нет, есть траты. Они превышают все то что может дать более оптимальная обработка ipv6 железом.
Облачники и хостеры продают адреса, а не покупают. Вы не путайте. От того есть у них ipv6 или нет количество клиентов не изменится. Опять траты и никакой прибыли. Ладно, супер дешевые хостеры могут продавать виртуалки без Ipv4 адресов. Небольшой спрос на дне рынка на них есть.
И так везде.
Это выгодно в первую очередь провайдерам, это выгодно крупным компаниям с крупными сетями - банкам, страховым компаниям. Это не умозрительно, это высказываемый ими интерес, обсуждаемый на конференциях - на Cisco Live, на IPv6 Council, на различных NOG, на конференции ARCEP.
В чем выгода-то? Выгоду считаем в долларах. Сумма выгоды должна хотя бы превышать затраты на кофе.
Провайдеры замечательно сдают ipv4 в аренду и платят смешные 30-50 центов за абонента на покупку адресов себе. Им норм. Кофе точно дороже.
Крупным? А зачем им? Очень крупным может быть удобным строить внутренние сети на ipv6, но тоже сомнительное решение. Подсети Ipv4 всяко хватит для любого кластера. Ipv6 только немного упростит маршрутизацию в обмен на проблемы совместимости. Тут есть сомнения, верю что ipv6 и выдержит паритет с кофе.
Внешние сервисы все равно всем на ipv4 строить десятилетиями.
Подсети Ipv4 всяко хватит для любого кластера
Внутреннего? Наверное, но даже так некоторые одаренные во внутреннюю сеть раздают что-то типа 11.х.х.х.
А плавно и постепенно его делать дорого. Надо две сети поддерживать десятилетиями
Обновление оборудования cgnat тоже не бесплатные
Простите, вы знаете или вы считаете? В данный момент все знакомые мне европейские провайдеры вкладываются во внедрение IPv6 в свои сети. Это состоявшийся факт, а не теоретические выкладки, доступные по отчетам регуляторов и обсуждаемые на конференциях. Я знаю архитектуру этих сетей и обьемы абонентских баз, оставшиеся резервы IPv4, стоимость решений CGNAT и MAP-T, а так же оценку затрат на приобретение дополнительных пулов и почему менеджмент желает этого избежать. Итог один - провайдеры Франции, Германии, Англии, Испании и других стран стремятся ускорить переход своих сетей на IPv6. Потому я не понимаю, что вы хотите доказать? Что все эти провайдеры ошибаются и живут в мире своих фантазий?
Замечу, что миграция затрагивает не только пользовательский оверлей, но начинается так же миграция андерлея, в частности преход на IPv6 маршрутизации между RAN и ядром мобильной сети (и внутри ядра), разворачивание IPv6 underlay в фабриках ЦОДов. И мы далеко не первые в этом плане. Сколько лет назад Яндекс начал стрить свои ЦОД IPv6-Only? Вы правда считаете, что эти усилия продиктованы не рентабельностью, а исключительно любовью к красивым новым технологиям?
Так их регулятор заставил. Они не хотят.
Кажется что это не самая маловажная причина. С учетом количества проблем с ipv6. С другой стороны это типичный бигтех, для него смысл определенный есть.
Нет. Не заставлял. Разворачивание IPv6 началось задолго до участия регуляторов в этом вопросе. Да и то, кроме требования IPv6 для получения частот 5G, других фактов обязывания операторов в этом вопросе я не знаю. ARCEP занимается пропагандой IPv6, но никак не проталкиванием в приказном порядке.
Вся документация того же ARCEP доступна в открытом доступе, можете изучить и контраргументировать.
Разворачиванием IPv6 в том числе занимаются и малые операторы и хостеры, которые под понятие бигтех не подпадают вообще никак.
Никто не спорит что знакомые вам провайдеры внедряют IPv6.
Вопрос был про выгоду: в чем выгода?
Мы тут сетевеки, поясните на пальцах, поймем.
Да я вроде ничего загадчного не говорил. Давайте с точки зрения провайдера.
Решается в перспективе вопрос исчерпания запасов IPv4 провайдера. Следует отметить, что западная традиция подразумевает выделение каждому абоненту фиксированного доступа одного постоянного публичного IPv4 адреса, так как иначе абонент не может считаться участником интернета. Это можно долго обсуждать, но стоит зафиксировать это как изначальное условие. Последствие - прямая угроза исчерпания резервов с ростом абонентской базы или потолок роста. Фиксированные CGNAT и MAP-T позволяют включить экономию и отсрочить исчерпание, выиграть время на массовый переход на IPv6, затем потребность в IPv4 станет уменьшаться. Но альтернативного решения нет. Использовать динамический CGNAT или более агрессивное соотношение трансляции (мы используем 1:8) значит предложить условия хуже конкурентов на рынке, для маркетинга и менеджмента это не приемлимо. Это прямые финансовые риски.
С MAP-T абонентский CPE получает только IPv6 адрес (вместо IPv4+IPv6 сегодня в DualStack). Это дает уменьшение требуемых ресурсов на BNG, упрощение процесса конфигурации CPE (DHCPv6 вместо DHCPv4+DHCPv6 сегодня), упрощение обслуживания базы Radius OSS (включая акаунтинг). Оптимизация CAPEX/OPEX.
Отказ от IPv4 на CPE позволяет перевести в перспективе агрегационные сети и бекбон на IPv6Only, что сильно упрощает управление сетями с точки зрения стека протоколов (хотя это менее критично сейчас, после перехода на SR/MPLS и отказа от LDP). Оптимизация CAPEX/OPEX.
Позволяет перейти на SRv6, что даст значительные возможности для гараздо более эффективной маршрутизации и управлению трафиком end-to-end, включая разные уровни SLA, слайсинг, и т.д. Оптимизация CAPEX, новые сервисы для клиентов (особенно корпоративных).
Для разработчиков прошивки CPE отказ от IPv4 дает снижение затрат на разработку прошивки примерно на треть. Оптимизация OPEX.
Для разделяемых между операторами сетей доступа RAN 2G/3G/4G/5G переход на IPv6 для коммуникации с ядром сети каждого оператора дает значительное упрощение адресации, отсутствие конфликтов, более эффективную маршрутизацию и балансировку трафика (за счет более грамотного плана агрегации). Оптимизация CAPEX.
Это пример тех случаев применения IPv6 которые мы считаем обоснованными и выгодными за счет экономии и оптимизации. Есть еще пара десятоков юзкесов, которые мы считаем потенциально интересными, но пока о них рано говорить (включая SDN, перевод андерлея DC на IPv6 и т.д.).
Боже, что вы несете.
Начнем прямо с пункта 1
Решается в перспективе вопрос исчерпания запасов IPv4 провайдера. Следует отметить, что западная традиция подразумевает выделение каждому абоненту фиксированного доступа одного постоянного публичного IPv4 адреса
Это в какой стране эльфов ipv4 не продают с кучей красных флажков что мол вас атаковать будут а принудительно или хотя бы бесплатно выдают частному клиенту на типовом тарифе?
Провайдер все еще расходует меньше 50 центов (не в месяц, вообще навсегда) на тот кусочек ipv4 который надо потратить на абонента и не переживает вообще.
Боже, что вы несете.
Я несу вам свет знания о том, что происходит в мире.
Вас это возможно сильно поразит, но большинство крупных операторов в Западной Европе и в США десятилетиями предоставляют частным абонентам публичные IPv4 адреса. Без каких-либо красных флажков. Потому что это является нормальной ситуацией по-умолчанию.
Вы, конечно, можете жить согласно своей личной реальности, но прочая действительность к счастью об этом не в курсе. Мне как-то странно спорить и доказывать то, что является окружающим меня фактом, а так же доказывать выбор сделанный (а следовательно обоснованный технически и финансово) моей компанией - вторым по размеру и охвату оператором Франции. Как собственно и обьяснять положение дел в отрасли, в которой я работаю более 17 лет (и более 25 лет в IT).
Если вас интересует конструктивная беседа на тему - с удовольствием, если вы желаете спорить ради спора или вашего самоутверждения - простите, меня это не интересует. Уважайте собеседника и читателей.
Франция. Вы ключевое слово сказали. Смотрим пару крупных провайдеров Франции.
Orange - не выдает
Vodafone - 7.5 евро в месяц
И тому подобное.
Все как везде. Интернет везде устроен одинаково.
Вы решили ткнуть меня носом в положение дел во Франции и ссылаетесть на сайт https://www.broadband.co.uk/ дающий обзор английских операторов? С вами все в порядке?
Вас не затруднит, если вы намерены спорить, хотя бы предварительно исследовать тему в первоисточниках? Или хотя бы взять адекватеный обзор? Я облегчу вам жизнь. Вот отчет ARCEP (французского регулятора) касательно всех четырех основных французских операторов - Orange, Free, Bouygues Telecom и SFR. https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_2021_Barometer_of_the_Transition_to_IPv6.pdf
The four operators all have different IPv4 address sharing practices depending on their fixed network technologies:
- The majority of Free fixed network customers (75% in xDSL and 85% in FttH) as well as a small proportion of Bouygues Telecom customers (5% in xDSL and 2% in FttH) have a shared IPv4 address. However, these ISPs offer a dedicated IPv4 address free of charge on request.
- As of this year, some SFR customers also have a shared IPv4 address (8% in FttH) and this operator does not offer a dedicated IPv4 address on request for these customers.
- With regard to fixed 4G access, while Bouygues Telecom and SFR customers have a dedicated IPv4, Free and Orange customers have a shared IPv4 address.
These two ISPs do not offer dedicated IPv4 for fixed 4G.
- This sharing of IPv4 between several customers could become generalized in the coming years to face the shortage of IPv4.
И это при том, что отчет концентрируется именно на введении shared адресов операторами в последние годы, а не о практике существовавшей десятилетиями и приведшей к исчерпанию. Но вы же разбираетесь в теме, не так ли?
а что , разве не просто обновить прошивки роутеров, и установить в винду новые протоколы?
В теории несложно. На практике же... Одно дело провайдерское оборудование (включая провайдерский роутер дома у пользователя), другое дело - личное оборудование пользователя. Даже у провайдера процесс обнаружения проблем, выпуск патчей, их тестирование, процесс обновления - это очень сложный процесс, да и то, есть место лени и халатности. Чего уж говорить про обычного пользователя, котрый даже при критическом обновлении винды может до последнего тянуть с необходимой перезагрузкой?
Одна из проблем - у роутеров кое что использует аппаратное ускорение (процессоры то дохлые) а в софте...медленеее
ipv6 гораздо лучше подходит для создания распределенной архитектуры сети, где каждое устройство может являться сервером
Судя по всему, пользователям такая архитектура не нужна. Например, они не заводят каждый свою страничку, при том, что тезническая возможность делать так есть,, а идут в соцсеть, где о технических вопросах позаботятся специально обученные люди.Так что бояться блокирующим тут нечего.
А пользователям об этом знать не обязательно. Микрософт и Valve давно уже применяют методы оптимизации доставки на основе P2P протоколов. При использовании IPv6 компьютеры будут обмениваться трафиком напрямую, без NAT. Но это не значит что трафик будут ходить туда-сюда бесконтрольно, FW никто не отменял.
А пользователям об этом знать не обязательно. Микрософт и Valve давно уже применяют методы оптимизации доставки на основе P2P протоколов
Не виду ни одной причины помогать этим жирным котам: бабло они все равно берут за контент, так что простым людям дешевле не будет. Пусть себе ещё серверов ставят, не обеднеют.
Единственное известное мне применение P2P, полезное простым люям - это торренты. Но они пока и так неплохо жиивут - пока провайдеры у себя симметрических NAT не понаставили: конические NAT пробивалками проходятся хорошо, так что трафик может идти напрямую, а не через пробивалки. А ещё есть UPnP (раньше, по крайней мере, был), который шлюзу NAT напрямую может сказать,.что нужно входящее соединение.
FW никто не отменял.
Брандмауэр надо настраивать, и настраивать правильно. Одно дело, когда эта настройка - тупой запрет всех входящих (как в NAT), это просто, но вы же явно хотите большего.
Единственное известное мне применение P2P, полезное простым люям - это торренты
Аудио- и видеозвонки тоже становится беспроблемнее. Всякие удалённые управлялки. И т.п.
Не нужно держать постоянно открытые соединения, и следить чтобы они не закрылись. Не нужно думать как соединить два хоста из-за ната.
Удаленные управлялки - они через облако всё больше, т.е. внешние серверы. Так пользователям и производителям почему-то удобнее. Аудио/видеосвязь - тоже. P2P в нынешнем интернете, если говорить про приложения, не сильно востребована, и интернет у нас - несимметричный (кто-то даже говорит - феодальный): есть белая кость - провайдеры услуг - и есть черная кость - пользователи, и они - не разу не пэры (peer).
Удаленные управлялки - они через облако всё больше, т.е. внешние серверы. Так пользователям и производителям почему-то удобнее
Так конечно удобнее, чем сношения с натом у оператора и на своем роутере, или с добычей белого адреса у оператора.
В мире ipv6 удобнее будет по-другому.
Так конечно удобнее,
Да.
В мире ipv6 удобнее будет по-другому.
Не будет. Прична тут другая: большинство людей, которые специалисты в других областях, а не в этих ваших сетях, не могут сами содержать свою частную инфраструктуру, квалификация нужна. И вряд ли захотят нанимать для этого специалистов с квалификацией, если можно пользоваться централизованной инфраструктурой - так дешевле.
Наличие технической возможности и пользы довольно быстро создаст приложения, которые решают данную проблему прозрачно для пользователей. Webrtc, syncthing и прочие не на пустом месте появились.
Наличие технической возможности и пользы довольно быстро создаст приложения
Нет. "По одной кнопке" только вода из бачка сливается :-) . Даже наличие красивых и внешне понятных приложений не позволит пользователям решать концептуально сложные задачи. Например, наличие GUI на Windows Server не сильно понижает порог входа в администрирование сетей на нем на предприятиях, всё равно для успешной работы приходится много чего знать, GUI/CLI - лишь малая часть из этих необходимых знаний. Здесь у нас, конечно, не кровавый энтерпрайз, домашняя локал - она попроще, но всё равно, обычных людей требование уметь в ту же сетевую безопасность напрягает. А без этой безопасности сейчас никак: интернет по уровню безопасности напоминает средневековую большую дорогу, которая с разбойниками.
Уж ввести в приложении хостнейм или IP могут все, было бы желание. Ничуть не сложнее, чем создать аккаунт в облаке, привязать туда регистратор и создать в регистраторе пароль.
«Открыть порт» в роутере тоже не нужно иметь чёрный пояс по сетям.
Так конечно удобнее, чем сношения с натом у оператора и на своем роутере
Только производители в большинстве своем не оставляют пользователю возможности сношаться с роутером и безальтернативно предлагают свое облако.
С чего бы это? Однозначно ради удобства пользователей, а не для получения дополнительной прибыли /s
А ещё есть UPnP (раньше, по крайней мере, был), который шлюзу NAT напрямую может сказать,.что нужно входящее соединение.
И какой от UPnP толк, если оператор выдал на роутер серый адрес?
Никогда не разбирался, может ли в существующем протоколе маршрутизатор быть клиентом UPnP для другого маршрутизатора. Но техничеких ограничений, которые бы этому препятствовали, не вижу.
Наприме, в несколько сходном по задачам (тоже надо трафик внутрь на неочевидные снаружи адреса пробрасывать) IGMP, например, такое есть.
А вы точно хотите, чтобы каждое пользовательское устройство, каждое тупое реле ворот, каждый умный чайник (не видевший апдейтов никогда в жизни), каждая виндовая шара в домохозяйстве стали "сервером распределённой архитектуры сети"?
Да ещё и со скачущим рандомным адресом из-за бреши в приватности, которую пробил SLAAC.
А вы точно хотите, чтобы каждое пользовательское устройство, каждое тупое реле ворот, каждый умный чайник (не видевший апдейтов никогда в жизни), каждая виндовая шара в домохозяйстве стали "сервером распределённой архитектуры сети"
чтобы такого не было, существует файрвол. Да даже без него, сколько времени займет поиск активного адреса в /64 подсети? Это если мы уже знаем, что используется определенный GUA префикс. Можете подсчитать?
Да, прямое сканирование IPv6 сети невозможно. Но пассивный наблюдатель прекрасно будет видеть, сколько чайников в вашей сети. Поверхность атаки меньше, но отнюдь не нулевая.
А насчёт фаервола, внимание вопрос: если на домашних маршрутизаторах фаервол по умолчанию будет всё запрещать и для общения с внешним миром надо отдельно проковыривать порты, то...чем это лучше по сравнению с NAT? Что там нужна настройка для доступа извне, что здесь. IPv6 - это же типа чтобы всё было просто и безопасно. Что стало проще и что стало безопаснее?
И как вы на фаерволе будете прописывать разрешения на доступ для устройств с рандомным адресом, которые появились в ответ на SLAAC?
И как вы на фаерволе будете прописывать разрешения на доступ для устройств с рандомным адресом, которые появились в ответ на SLAAC?
Для этого мы «займем» постоянный адрес, в дополнении к адресу от SLAAC
Но пассивный наблюдатель прекрасно будет видеть, сколько чайников в вашей сети
каким образом?
По IP-адресам. Компрометация любого узла провайдера автоматически откроет доступ ко всем чайникам в его зоне ответственности. Куда уж проще чем посмотреть source-ip
По IP-адресам
так они постоянно меняются случайным образом (все, что после префикса). Мак-адрес в изначальном виде в IPv6 адрес давно уже не вставляют (в популярных ОС). Как будем определять чайники в этой ситуации?
С учетом нынешних законов. Мне вот не хочется, чтобы провайдер домашнего интернета видел всю инфраструктуру моей сети. К примеру возьмем смартфон. Захожу в интернет со смартафона по вайфай через роутер и нат, в том числе випиэн. И какое конкретно устройство зашло, может у меня еще 5 смартфонов , провайдеру интернета определить сложно. А вот ip6 подобную возможность, может провайдеру интернета предоставить. Задача сегодня я со своего смартфона захожу из проводного интернета из дома в Москве , завтра из гостиницы в Новгороде. Зачем копить статистику работы конкретного устройства. И я к примеру плачу за статический ип4 адрес , а ип6 отключен на роутере и мне это ничуть не мешает.
Privacy extensions сделали специально для этого. Каждое устройство можно создать (и создаёт) несколько IPv6-адресов, которые меняются со временем.
Это надо знать и надо специально настраивать. а NAT настраивать не надо. Он предоставляет "приватность" из коробки
Не, не надо знать - оно само.
Тут другая проблема, наоборот: не так просто заблокировать на роутере конкретную железку в сети, именно потому что у нее адреса меняются.
Это, конечно, замечательно! Но как оно стыкуется с необходимостью поддерживать доступ к этому устройству извне?
В принципе если сильно хочется - "классический" NAT на IPv6 можно сделать. Даже вот Mikrotik сдалась и сделали NAT66 в RouterOS
Главная проблема нового протокола кроется в его дизайне. IPv6 не совместим с IPv4 — это фактически отдельная сеть. Устройство или сайт с IPv6 не сможет напрямую «общаться» с узлом, у которого только IPv4.
Отмечу, разработчики шестой версии сознательно не стали делать её надстройкой над IPv4, решив радикально обновить протокол
хочешь миграцию на десятилетия - забей на совместимость
Вопрос к специалистам протокола: есть ли соответствующая литература, прочитав которую человеку станет понятно как пользоваться и конфигурировать ipv6 для практического его применения так же свободно, как и ipv4? Не обрывочные сведения и преимущества, а нормальное описание (не RFC конечно), с которым я, имея дома микрот, например, могу поднять на тестовом стенде локалку и внешне доступный сервер.
И да и нет. Конкретная конфигурация зависит от конкретного прозводителя - Cisco, Nokia, Huawei, Microtik, Linux, Windows - следует смотреть документацию. Хотя при разном синтаксисе все они оперируют одними у теми же понятиями и принципами и понимая эти принципы и протоколы, не составляет труда создать нужную конфигурацию. В сети полно туториалов для конфигурировании того или иного устройства. Куда важнее это понимание самих принципов.
Из литературы я могу порекомендовать "IPv6 Fundamentals" - by Rick Graziani - 2ed (CiscoPress, 2017). Самая лучшая из всех книг что я видел по основам IPv6, как по материалу, так и по изложению.
Есть несколько книг от O'Reilly, например "IPv6 Essentials" - by Silvia Hagen 3ed - O'Reilly, 2014, но после "IPv6 Fundamentals" она уже вторична.
По планированию адресации есть "IPv6 Address Planning" - by Tom Coffeen - O'Reilly, 2014.
По DNS - "DNS and BIND on IPv6" - by Cricket Liu - O'Reilly, 2011 (хотя несколько устарела)
Все эти книги можно найти в электронном виде в рунете :)
"IPv6 для знатоков IPv4", Ярослав Тихий - 2013, https://maxim.int.ru/stuff/ipv6_ru.pdf несколько скомкана, но дает много для понимания базы и философии IPv6. Рекомендую в дополнение к "IPv6 Fundamentals".
Разумеется есть многое, что пришло в IPv6 в последние годы (виртуализация, IPv6 в датацентрах, в сетях предприятий, SRv6 и т.д.), но это уже специализированные вещи.
Спасибо за список литературы! Хоть я уже и пенсионер, и так и не использовал IPv6 в проде, но любопытно будет поизучать.
Простой ответ - нет. Особенности реализации зависят от вендора всего обрудования, что у вас на пути от розетки провайдера до того, что в руках. Если это Микротик - то форумы, потом документации тонна, и потом, когда все запустите, постоянная мысль - а верно ли фаервол работает, и нет ли прямого входа к моим устройством извне...
Я вижу только одну необходимость, чтобы перейти дома на IPv6 - это IoT устройства на основе Matter-over-Thread
Начните с подключения ipv6 через туннельного брокера - это бесплатно, и даст возможность звести в локальной сети кучу адресов ipv6, поиграться...
Насколько я понял, для использования брокера нужен статический публичный IPv4. У меня пока всё остановилось на том, что мой IPv4 недоступен извне.
Да, но самый примитивный VDS/VPS с фиксированным адресом решает эту проблему. Заводите подсеть туда, оттуда - к себе.
Нужен публичный, да. Но не обязательно статика, если брокер позволяет его менять через api/ddns. Вообще был кто-то из брокеров раздававших через wireguard, там и публичный ip не нужен
Раньше набирали 8 для звонка по межгороду или заказной 07. Краткие себе цифры. Например IP с адресом 0 - это null, 1 - это localhost, 1.0 - память, 2.1 - диск, 4.3.2 - домовой провайдер, 6.4.6.4 - широкополосный спам, 4.2.4.2.4.2.4.2 - Вояджёр-3. Адресация должна быть хешируемой и по-хорошему содержать типизацию устройств, чей это адрес, сервер, эндпойнт, транслятор, а также управляющие команды и микро-байткод. То есть сам IP адрес это уже микро-пакет переменной длины с конкретным назначением, карточки уже вполне с этим могут справляться. Просто в то время маска была в прямом смысле маской на чём-то вроде К555ЛА3 и с приёмником пакета на 74HC165, больше этим причин заниматься нет, включая IP6.
То есть сам IP адрес это уже микро-пакет переменной длины с конкретным назначением, карточки уже вполне с этим могут справляться.
Коммутаторы с аппаратной поддержкой, которые в наше время маршрутизаторами работают, любят поля постоянной длинны. В частности, из-за этого в IPv6 меняли структуру заголовков пакетов, чтобы избежать их переменной длины.
Это всё навязанное легаси и инерция по разработке спецификации под переменную длину с учётом современных реалий с точки зрения методов доставки данных а не аппаратуры-драйверов. То есть фактически в карточке появляется локальный контроллер который занимается коммутацией, кешированием, транспортом помимо основного, который осуществляет маршрутизацию и применяет правила. Это сопоставимо с внедрением С-подобных сущностей, например как OpenCL/CUDA для программирования внешних сопроцессоров. Вот эту необходимую по сути оснастку всё никак не тронут с места, вместо этого предлагаются прыжки с костылями на основе инструментов полувековой давности. Если посмотреть с точки зрения того как там летают данные обёрнутые адресами то это фактически протокол внутри протокола (причём уровень вложенности уже вышел за разумные пределы) который давным давно уже развернуть как единое целое.
принципы полувековой давности с универсальным форматом данных позволяют интернету работать уже полвека, не требуя ежедневного апгрейда всея Сети с заменой железа, софта и приложений, потому что где-то в спецификацию рядом с "домовым провайдером" добавили "провайдера голубиной почты", актуального для Зимбукту, и теперь всему миру надо обновлять протоколы.
Избыточность - обратная сторона универсальности.
А так-то можно было бы и CAN-шину на глобус натянуть...
В данном случае соблюдается принцип скорее "работает - не трожь". Работоспособность поддерживается уже просто неприличными человеко-часами а также неясным состоянием удобства из разряда "я принёс компьютер и хочу его объединить с другим в один клик, воткнуть ещё в параллель какую-то коробку с RJ-45 и видеть её как значок или панель в Dos Navigator". В любом случае паровоз рано или поздно сменится электротягой и дизелем. Можно конечно приспосабливаться, затолкав в котёл тяговую аппаратуру и прикрутив мотор к детандеру, но это сомнительный девайс получается. Вопрос скорее уже не в аппаратуре а в обучении этим принципам и наличии групп поддержки, которые готовы 20+ лет мейнтейнить то что жалко выбрасывать.
Пока IPv6 не начнут включать по умолчанию везде, где только можно, нормального распространения не будет.
У меня одной знакомой провайдер поставил роутер, сконфигурённый под v6 — и у неё тут же отвалились все веб-сайты банков.
За что вы так пользователей не любите? Каждой второй домохозяйке придется платить непонятному компьютерному мастеру чтобы отключил и интернет наконец-то нормально заработал.
ещё в 2011 году Microsoft выкупила у обанкротившейся Nortel блок адресов примерно за 7,5 млн долларов, а к настоящему времени средняя цена одного IPv4-адреса достигла 60 долларов
Спасибо за абсолютно бессмысленное сравнение. Какого размера блок-то? В 2011м за n адресов заплатили $7.5M, в 2025 за 1 адрес заплатили $60. Что это нам говорит о динамике? Абсолютно ничего, покуда n может быть любым, от 1 до бесконечности 16 миллионов.
Тем более, что на сегодня блок /16 продается по $17-18 за IP.
Цена $60 была два-три года назад.
Уже вижу $14 : https://auctions.ipv4.global/
Вангую выйдет IPv8 который объединит IPv4 и IPv6
Не выйдет.
Ну итаниум без обратной совместимости утоп, то же будет с любым не любящим IP4 протоколом. Ждем AMD64 в мире сетей.
Любой другой протокол будет несовместим с IPv4, его просто нельзя нормально расширить. Считаете, когда проектировали IPv6, об этом не задумывались?
Любой другой протокол будет несовместим с IPv4, его просто нельзя нормально расширить. Считаете, когда проектировали IPv6, об этом не задумывались?
Конечно нет, тогда было слишком унизительно думать о расширении IPv4 "хоть тушкой, хоть чучелом". А теперь слишком унизительно вспоминать об этой возможности.
Почитайте, как процесс происходил.
В конце 1994 опубликовали RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng). В нём начали с того, что
If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it.
А продолжили тем, что нужны фичи. Нужно много фич. И нам тут из минобороны позвонили... у них вертолёты на кораблях. Да, тоже нужно - не обсуждается.
Naval surface combatants carry some aircraft
(at a minimum, a helicopter or two)
(the ships that move around)
the ships carrying the aircraft
each aircraft has its own network
must be mobile internetworks
There is also the requirement for dynamic mobility;
a plane might take off from aircraft carrier A and land on carrier B
These requirements are not limited to just the navy
Через месяц подвели итоги в RFC1752 - отбор прошли 3 протокола и, как ни странно, они все сложные.
The biggest problem the reviewers had with SIPP was with IPAE, SIPP's transition plan. The overwhelming feeling was that IPAE [IP Address Encapsulation] is fatally flawed and could not be made to work reliably in an operational Internet.
____
Надо было начать с расширения IPv4 вправо. Это, конечно, приятно, когда органу есть что распределять, но проще автоматически сделать владельца одного IPv4 владельцем 2^(8/16/32) IPng-адресов. Владельцем обычно будет провайдер, использующий IPv4-адрес под CGNAT.
2^8, если переиспользовать поле Identification при форсировании Don't Fragment - недостаточно из-за неравномерного распределения адресов (мало IPv4 у стран Азии). Ещё 6 бит, если получится задействовать Fragment Offset.
2^16+, если заставить железо поддерживать IPv4 Options либо навсегда инкапсулировать новый заголовок (с расширенной частью адреса) в IPv4.
В этом направлении думали в EIP (1992), IPv4+4 (2002), xIP (2009), EnIP, IP45.
все, что вы описываете - это костыли. Зачем городить костыли для которых все равно нужно будет переписывать весь пользовательский софт, если можно сделать похожий, но в то же время отдельный протокол, исправив известные недостатки существующего протокола?
Я согласен с единственным - плохо, что поначалу упирали на дуалстек и сравнительно поздно реализовали технологии перехода, где на конечное устройство выдается нативно только IPv6, а IPv4 ходит через трансляторы/инкапсуляцию.
TL;DR: затем, что ценность IPv6 в скорости перехода на него, а не в его архитектуре.
Костыльность - вероятно, фундаментальное свойство нашей вселенной. С появления теории относительности картина всё хуже и хуже.
Вокруг нас есть инфраструктурные вещи. Протоколы интернета. Водопровод. Ядро линукса. Их ценность в том, что ими все пользуются и они работают. Сколько костылей в линуксе по сравнению с чистой академической разработкой? Насколько медные трубы круче полипропилена? Каковы недостатки IPv4 по сравнению с IPv6? Ответы: 1) нафиг мне операционка без приложений, 2) третью неделю воды нет!11, 3) да проехали уже, не до того нынче.
исправив известные недостатки
NAT: при подключении к интернету можно сэкономить на "белом" адресе и расплачиваться недоступностью извне во многих ситуациях.
IPv6: при аренде VPS можно сэкономить на IPv4-адресе и расплачиваться недоступностью извне во многих ситуациях.
Ради этого стоило ждать 30 лет. То есть новому протоколу нужен NAT/прокси, чтобы не получилось как с NAT*, но без нового протокола... то есть такие сравнения вообще должны закончиться в конце нулевых.
* а может и на самом деле хуже, потому что
NAT-VPS: при аренде VPS можно сэкономить на "белом" адресе и получить связность лучше IPv6 за счёт "белых" портов.
затем, что ценность IPv6 в скорости перехода на него, а не в его архитектуре
скорость перехода это отдельный вопрос. Что бы не придумали вместо IPv6, переход на это был бы таким же мучительным. Проблема перехода в том, что пока что и обычного IPv4 хватает большинству. Реально с IPv4 можно жить еще много лет. Просто NAT будет обрабатывать больше соединений, цены на v4 адреса будут выше, соответственно, комфорт пользователей местами будет страдать, платить им придется больше, но интернет глобально работать будет, не сломается.
Но не переходя на новый протокол сейчас, мы берем в долг у будущих себя. Ведь рано или поздно это сделать придется, прогресс не остановить. Мне сложно представить, что через условные 10 лет в одних странах будет 100% поддержка провайдерами IPv6, и в то же время в других странах останутся нынешние 2-5%. Не исключено, что большие глобальные интернет-сервисы будут со временем урезать объем внешних каналов с IPv4 интерфейсом, таким образом те из провайдеров, которые к этому времени успеют перейти на IPv6, получат конкурентное преимущество. Конечно, это актуально только для стран, которые будут иметь доступ к этим глобальным интернет-сервисам. "Чебурнету" не поплохеет даже если он навсегда останется на IPv4. Вон у Северной Кореи есть всего тысяча IPv4 адресов и ни одного IPv6. И ничего, никто не жалуется.
Но не переходя на новый протокол сейчас, мы берем в долг у будущих себя. Ведь рано или поздно это сделать придется, прогресс не остановить.
Мы не знаем, каким путем идет прогресс, поэтому лучше вперед него не бежать. Например, текущий способ использования сети предполагает наличие в ней сравнительно малого количества узлов, предоставляющих услуги (серверов) и гораздо большего числа узлов-клиентов, которые сами никаких услуг не предоставляют, а лишь обращащаются к серверам. В такой архитектуре клиентам полноценные адреса не нужны: для связи клиентов с серверами достаточно иметь занчительно меньшее количество полноценных узлов-шлюзов, которые передают обращения клиентов к серверам и (обязательно) блокируют входящие соединения к оконечным клиентам. В такой конфигурации полноценные адреса требуются только адресам и шлюзам и IPv4 хватит надолго (думаю, навсегда). И эта конфигурация вполне соответствует тому как сеть используется сейчас и, похоже, будет использоваться в обозримом будущем. А необходимость обеспечить двухстороннюю связь между всеми узлами сети появится, полагаю, примерно тогда же, когда мы придем к победе коммунистического труда (;-)), хотя не исключено, что мы ко всему этому все же придем.
Но вот пока IMHO стоит не заморачиваться: лучшее - оно враг хорошего, а хорошая, годная сеть, которая адекватна тому, как эта сеть используется потребителями, у нас уже есть, на IPv4.
Мы не знаем, каким путем идет прогресс, поэтому лучше вперед него не бежать
ну как бы не совсем не знаем: https://www.google.com/intl/en/ipv6/statistics.html
Уже практически 50% глобально. Путь небыстрый, но стабильный.
Что бы не придумали вместо IPv6, переход на это был бы таким же мучительным.
Я долго думал, как можно прийти к такой мысли и понял, что вы нашли её в "Красной книжечке"... дайте почитать.
"IPv6 to a network engineer is like Communism to a Marxist" - 2013.
Внутри IETF на разборе полётов в 2010 задавались вопросом: Если мы такие умные, почему мы не можем разработать IP-протокол следующего поколения и выработать технически осуществимую стратегию внедрения и сосуществования?
IPv6 - история про амбиции. IETF изначально не мог принять недостаточно амбициозный (достаточно реализуемый) план и это было приправлено деньгами пузыря доткомов. А когда наломал дров, не мог сдать назад. Бесконечный тупик. Да, где-то в ~2045 планируется полный переход на доделанный IPv6, но может получиться как в анекдоте про фальшивые ёлочные игрушки (если интернет в привычном понимании уже кончится).
Itanium иногда считают успехом из-за того, что он потопил конкурентов с их high-end RISC (ну или они сами вовремя умерли). Отменённый IPv6 в альтернативной реальности выглядел бы примерно так же из-за победы над OSI-протоколами (например, федеральная программа GOSIP, 1990-1995).
Вместо IPv6 придумали NAT. Он решал проблему сразу. Но не целиком. Дальше требовалась доработать NAT, чтобы появилась связность между частными адресами (IPv4+4, PR-IP). Но не при живом IPv6.
Там был не только разбор полётов, но и знатный срач. Тыдыщ:
you are one of the main persons behind the failure of IPv6. The living example of the IETF ivory tower
if it was not for your blind opposition to NAT, we could be living in a world of 6to4 implemented in the ubiquitous NAT box
Look what you have done: not only we have more NATv4 than ever, but now we also have NAT46, NAT64, NAT464...whatever and all of these with heavy ALG layers to make it more palatable.
Congratulations.
И ещё много
- Вендоры не хотели добавлять 6to4.
- Вендоры устали от систематического торпедирования нами всего, что выглядит как NAT, ходит как NAT и квакает как NAT и постоянных напоминаний, что их продукт - это хлам в пластиковой коробке...
Один говорит, что проблема IPv6 в том, что это IPv4 с лишними битами, а надо было всю систему менять (Noel Chiappa, автор одного кандидата на IPng - Nimrod). Другой говорит, что проблема IPv6 как раз в обратном - мы же в него стремились добавить побольше фич, чтобы использовать шанс.
- Не думаю, что протокол IPv4 был разработан таким образом, чтобы допускать совместимое расширение.
Японец ему про свой PR-IP (про "белые" порты как сущность первого класса с поддержкой в вебе, в DNS, в ARP, которые как бы расширяют адрес почти до 48 бит). И не только ему, всем. Все молчат.
Да? Может быть: 1. Принять IPv6 как его изначально сделал Стив Диринг.
Это может показаться совершенно нелепым предложением... но у IPv4 на самом деле есть Options! (про три предложения из 1992-1994 не вспоминали)
- Отложить вскрытие, пациент ещё живой, хоть и с задержкой в развитии.
- Вивисекция!
Я тут понял. План с дуал-стеком 15 лет назад опирался на то, что у всех есть публичный IPv4... а если у всех есть публичный IPv4, то значит их всем хватает... а если их всем хватает, то зачем им IPv6?
- NAT даёт связность там, где её не было.
- Нет, NAT лишает связности там, где она была.
So currently, a NAT provides:
A degree of de-facto firewalling for everyone.
An immunity to renumbering for enterprises.
Fully automated network routing for ISPs.
- 99% приложений ходят через настроенный NAT, нужен только проброшенный порт.
- Существенные нарушения фундаментальных архитектурных принципов IP.
Изначально предполагалось, что IPSEC станет достаточно сильным стимулом для обновления.
С тех пор IPSEC был отделён, и мы обнаружили, что безопасность на пакетном уровне далеко не так полезна, как безопасность на транспортном уровне.
_______
2001:
>> Вы действительно думаете, что сотрудники IETF (и другие) разработали IPv6 без предварительного тщательного анализа?
> Noel Chiappa: На самом деле, многие в IETF так считают (Это сообщение отправлено вам через NAT-бокс, который я купил в ларьке прямо через улицу. Забавы ради надо было спросить, есть ли у них IPv6...)
Через 5 лет запоёте по-другому. Масштабируемость, QoS, мобильные устройства, веб-устройства прибьют v4 - и UMTS добавит остроты.
В журнале в 1999:
"This represents the first time the IETF has seriously and formally examined the possibility of IPv6 not succeeding," says Noel Chiappa, a participant in the July meeting and a former area director for the IETF. "Before we had Plan A - IPv6 - and there was no Plan B. Now we're starting to work on one."
Because IPv6 products were not widely available to solve the Internet address shortage, many network managers deployed NAT devices as a quick fix.
"We were assuming a transition between IPv4 and pure IPv6," Carpenter says
В статье в 1998:
The reasons for this lack of interest in gateways that lose informations and hence are imperfect within the Internet seems to be a drive toward "purity" in the design (Eidnes, 1996). As this purity is likely to be increasingly difficult to maintain in the future, it would be interesting to investigate more closely the role of and attitudes toward gateways within the Internet.
Конфликт "юзер хочет видеть в локалке за файрволом/NAT'ом доверенную зону, а архитектор считает своим долгом уничтожить эту привычку" куда-то в неолит уходит.
Я не совсем понимаю, можете объяснить на пальцах, как можно было расширить IPv4 без обновления сетевого стека ОС и оконечного оборудования?
Вот, кстати, еще на эту тему: с таймстампом
Расшифровка, если не хочется смотреть видео:
Скрытый текст
one little problem IPv6 is not backwards compatible
with ipv4 now you would think the bright
engineers at the ITF would have figured
out a way to make this backwards
compatible and the problem really isn't
that we couldn't have done it with V6 we
could have but we would have had to
change V4 once in order to make
V4 have the backwards compatibility so
that we could then roll out V6 it's a
lot like if every cell phone in the
world could dial seven digits and only
seven not six not eight the number shall
be seven and seven shall be the number
if you could dial only seven digits and
we ran out of numbers and we suddenly
introduced 14 digits well the problem
really is that yeah you could I could
call you because I dial seven zeros and
your seven digits with my new funky
funky 14 digigit phone but you couldn't
call me because my 14 digits and someone
else's 14 digits may have the same lower
seven digits and we overlap the problem
was the existing base of ipv4 machines
it's code guys has tables and buffers
and they're all set up for 32 bits and
there's no way to generically change
that to make it accommodate 32 bits and
128 bits unless we first upgraded V4 and
the decision was trying to upgrade V4 is
as hard as trying to roll out V6 we'll
just roll out V6
Так вы на предпосылку своего вопроса посмотрите - "одинаковая мучительность перехода на любой IPng следует из необходимости обновления сетевого стека ОС и оконечного оборудования". Она очевидно ложная, потому что сетевой стек и оконечное оборудование давно обновлены под IPv6.
А выступление вы подозрительно обрезали, там всего одного предложения не хватает: "...and the decision was trying to upgrade V4 is as hard as trying to roll out V6, we'll just roll out V6. This is a in-te-res-ti-ng design decision that was made in 1994". Там не говорится, что решение (и понимание проблемы) было верное. Говорится, что оно ин-те-рес-ное и нам в этом интересном мире теперь жить (reality of life, suck it up). И дальше, что IETF игнорировала проблему перехода вплоть до ~2008 (26:30).
Она очевидно ложная, потому что сетевой стек и оконечное оборудование давно обновлены под IPv6
сетевой стек - да, но ведь разве не проблемы с оконечным оборудованием тормозят провайдеров от перехода? Или какая причина? То, что админы провайдеров знают IPv4 и не знают IPv6? А разве им не придется учить, как работать с "IPv4+4"?
Тыдыщ
Хмм, у Keith Moore отношения с NAT как у Катона Цензора с Карфагеном. Катон не дожил до падения Карфагена. Муру 65 лет. У него есть личный длинный список Things that NATs break.
И камень преткновения у IETF не столько в NAT, сколько в идее, что локалке можно доверять больше, чем внешнему миру. В мире без NAT сейчас бы шла битва против файрвола на домашнем роутере. Вместо вечного "NAT - это (не) файрвол" было бы "файрвол на CPE это вам не файрвол на конечном устройстве".
unrealistic to assume that most threats to the networks are from outside the network, or that any kind of perimeter security will protect a network of significant size from attack. - Keith Moore, 2003
...Security Islands (i.e., firewalls). The prevalent IETF perspective is that Security Islands are "A Bad Thing". [из корпоративных пожеланий по IPng, 1994, RFC1687]
Ещё кусочки истории:
- В 2000 госрегуляторы хотели заложить возрастной рейтинг в диапазоны IPv6-адресов.
- В 2000 в рассылку IETF озабоченно написали: IPv6 скоро кончатся, спасёт только адрес переменной длины. And in 2030: "Of course, nobody in 2000 realized that we'd eventually need 1048576 listener addresses for each of our cellphones and wristwatches..."
В реальности длины IPv6 не хватает Китаю для номера паспорта, грубо говоря. Их инициатива New IP (2019, pdf) про то, что хорошо бы "Identity (people ID)" сделать частью адреса и обменять приватность на подотчётность. "А глаза такие добрые-добрые..." (метаанекдот про Ленина).
- В 1994 подумывали про TCPng (wonderful new TCP-like protocol) - про QUIC-от-комитета. Для "TCP6" (обычный TCP, адаптированный к IPv6) надо подправить pseudo-header для контрольной суммы (сделано), добавить поддержку >64КБ (заброшено в IPv6) и ещё что-то. Предлагали расширить порты до 32 бит.
Напишите статью. Хотя бы компиляцию истории обсуждений ipv6. Жаль если столько классных штук умрет в ветках комментариев.
Поддержу просьбу @BugM — здесь в комментариях материала на статью о злоключениях IPng уже наберётся.
ценность IPv6 в скорости перехода на него, а не в его архитектуре
Из ваших слов получается, что ценность IPv6 ничтожна, потому что скорость перехода на него ничтожна. Не нулевая, нет, но как-то почти неизмеримо малая.
Абсолютную полезность измерять не хочется, но эту общую идею вроде до оскомины 30 лет назад повторяли.
Совещание в 1993:
The fact that the Internet is doubling in size about every 11 months means that the cost of transition to IPng (in terms of equipment and manpower) is also increasing.
If the cost of transition outweighed the pain of other solutions (application gateways or address translators) customers would not deploy IPng.
IPng should appear simply like a new release of IPv4; although this would not necessarily bring new features...
Вот это "If we can't transition to the new protocol, then no matter how wonderful it is" из RFC1726 (1994).
"We were assuming a transition between IPv4 and pure IPv6" журналу в 1999 под спойлером в комменте выше.
_____
И мне кажется, или план IETF опирался на одну очень крупную идею, которая не сбылась из-за затянутого перехода?
Интернет переходит на чистый IPv6
=> не надо больше маршрутизировать IPv4 между AS
=> большая ожидаемая выгода (цена TCAM-памяти?), потому что IPv4 фрагментированно распределялся мелкими блоками ("IPv4 swamp")
=> ради возможности "дефрагментации" отказались от расширения IPv4 вправо через Options или инкапсуляцию доп. заголовка как в IPv4+4 (был шанс избежать изменений в BGP, автоматически сделать каждого владельца IPv4 владельцем ~2^24 IPv4+4, уменьшить число технологий перехода...).
Была ли такая жертва во имя маршрутизации-в-мире-без-IPv4?
Абсолютную полезность измерять не хочется
Осторожно озвучу свое предположение: инженегры - ITEF, кто угодно еще из причастных, скорее всего хотели как лучше. Я недостаточно компетентен, чтобы судить, получилось у них или нет, но для меня выглядит так, что получилось сделать что-то очень переусложненное. А дальше произошло столкновение с реальностью, в которой все началось с дефицита сетевого, особенно абонентского, оборудования с поддержкой IPv6 - а раз абонентам это не нужно, вернее абоненты даже знать не знают, что такое вообще бывает, то не нужно и Tier III провайдерам. А дальше, когда дефицит адресного пространства начал этих самых провайдеров неиллюзорно поджимать, жертвы дефицита адресов обложились NAT-костылями - вполне хорошими, годными костылями. И нет признаков, что ситуация быстро, если вообще когда-либо в короткой перспективе порядка десятилетия-двух, поменяется, тем более дефицит адресов не значит, что их вообще нет - нет новых, еще не распределенных адресов, а уже распределенные никуда не делись, их можно арендовать или перекупить, и в общем-то их не так уж и мало в абсолютном исчислении. То, чем заняты провайдеры Tier II и Tier I, как-то плохо экстраполируется на Tier III и их абонентов, поэтому хотя это все, казалось бы, один и тот же интернет, практики магистральных провайдеров и их оборудование это совсем не то же самое, что практики провайдеров последней мили, их оборудование и оборудование их абонентов. А абонентам в основной своей массе вообще все равно, что и как там устроено, мелкому бизнесу нужно, чтобы работал их сайт и прием платежей, а физикам - просто лазить по сайтам, смотреть ютьюбы и тому подобное в ассортименте. А оно работает? Да, работает. Тогда зачем что-то менять и платить за замену деньги? Под платить за замену я подразумеваю не столько аппаратный апгрейд, хотя местами и его тоже, сколько оплату работы сетевиков, которые параллельно с уже отлаженным IPv4 должны построить IPv6, отладить его и не поломать IPv4, а потом поддерживать два стека одновременно, потому что отключить IPv4 пока что еще нельзя без потерь - четверть века уже как нельзя.
Переход рискует оказаться если не буквально бесконечным, то фигурально он точно уже оказался именно таким.
Заметьте, я не апеллирую к тому, что IPv6 "лучше", "хуже" или что-то в этом роде - это отдельный разговор, как раз по тематике Хабра, статьи на эту тему таки были и, надеюсь, еще будут в ассортименте, потому что там писать - не переписать как много нового для привычного к IPv4 нужно понять и научиться использовать. Я лишь говорю о том, что если оценивать ценность IPv6 по скорости перехода, то эта ценность не имеет смысла, чтобы о ней вообще всерьез упоминать.
Уже понятно что 16 дополнительных бит в ipv4 почти хватает. Добавляем один октет к текущим адресам и ничего больше не трогаем.
Называем ipv8. Хватит за глаза на любое разумное время.
Текущие адреса объявляем новыми где этот октет 000.
Совместимость, простота, человекопонятность, удобство и просто все работает так же.
Совместимость,
нет, конечно же. это ещё один стандарт, несовместимый ни с ipv6, ни с ipv4. какая мотивация переходить на него?
Совместимость же. Железо понятным образом обновляется, и никакого дуалстека после этого. Один адрес, один октет, один стек.
Как адресовать старые адреса в новой ipv8 сети понятно. Любой путь ipv4 узлы -> ipv8 узлы будет достижим. Обратный тоже, но нужен бордер который октет отрежет. Затраты для провайдеров локальные и понятные. RFC написать дело нехитрое.
Добавляем один октет к текущим адресам и ничего больше не трогаем
в смысле "добавляем октет"? Вы же понимаете, что "внутри" никаких октетов нет, адреса находятся в бинарном виде? Другая длина адреса означает другую структуру IP-пакета, а значит, потерю совместимости.
Совместимость делается на основе бумаг. RFC. Я чуть дальше в ветке написал одно из возможных решений. Которое не требует поддержки везде чтобы работало.
Пакеты понятно что другие.
Формат пакета естественно надо делать удобным для обработки на железе, в идеале на существующем железе без сильной просадки производительности. Чтобы только софт все обновили на своих дорогих железках. Помечтать и квартал подумать над обратной совместимостью можно, но тут я уже не уверен что выйдет. Но если выйдет это вообще идеально.
Совместимость делается на основе бумаг.
ну что это значит на практике? Если формат IPv4 пакета утвержден давно, захардкожен везде в софте, в железе. Другая длина работать попросту не будет без изменения всего этого софта и железа. Или вы теоретик, а как реализовать на практике, пусть думает кто-то другой?
Вот так. Надо с первого дня продавать мысль что все ваше железо и все ваши устройства уже работают с ipv8 при наличии у вашего провайдера подходящей железки. А провайдерам продавать мысль что надо обновить всего лишь бордеры и все их клиенты тут же станут лучшими с поддержкой нового протокола. Микрософт так вообще с радостью выпустит вин12 с эксклюзивной поддержкой ipv8 на уже существующем железе.
Как это сделать на уровне железа с минимальными затратами надо думать. Это сложная, но решаемая проблема. Большие железки довольно гибкие на самом деле. А их производители с радостью продадут всем владельцам обновление за пару тысяч долларов. Вот вместе с ними и надо думать как правильно сделать.
Мелким железкам оно не надо. Архитектура гарантирует что все будет работать прозрачно, а люди привыкнут 000 додумывать со временем.
Мелкие роутеры все обновятся и научатся быть бордерами которые все что надо конвертируют. Запас производительности там уже есть.
PS: Кто сказал что формат пакета должен быть один? Один легаси, совместимый со старым железом но не оптимальный. Второй не тормозит, но не совместим со старым железом. Так можно получить и совместимость и повышение продаж. Повышение продаж всем, провайдерам нужна производительность, домохозяйствам будем продавать экюномию электричества и бесплатное расширение канала на 42 процента.
Надо с первого дня продавать мысль что все ваше железо и все ваши устройства уже работают с ipv8
почему это они работают? Если изменить формат пакета IPv4, софт и железо так же само не будут работать. А если не изменять, то куда поместить дополнительный адрес? Ну вот давайте сейчас, возьмите существующий формат IPv4, переделайте его в ваш "IPv8" и покажите нам.
при наличии у вашего провайдера подходящей железки
ну и чем это будет отличаться от IPv6?
Перечитайте еще раз. Бородер провайдера можно все конвертировать при верно написанном RFC.
Совместимостью, отсутствием двух сетей и далее по списку
Бородер
что это?
можно все конвертировать при верно написанном RFC
"верно написанный RFC" имеет магические свойства? Еще раз, обратную (backward) совместимость с IPv4 сделать можно, но прямую (upward) - нет. Все равно нужно будет менять софт и железо, как минимум на крайних узлах сетей. Ну так зачем все эти полумеры, если можно сделать новый протокол с новой архитектурой, где будут учтены недостатки v4? Собственно, поэтому новый протокол и сделали.
Бордер провайдера. Общее название для любых железок стоящих на границе сети.
Ну вот сделали совсем новый. И как оно получилось?
Надо максимизировать совместимость и решать только существующие проблемы. Эти требования ipv6 полностью провалил.
Бордер провайдера. Общее название для любых железок стоящих на границе сети.
ок. Допустим, ваш провайдер обновил свой бордер, и вы тоже обновили свой роутер и свой софт. А мой провайдер и я остались на старом софте-железе, ничего не знаем про новый "IPv8". Как мне напрямую связаться с вашим компьютером? Откуда мой софт должен знать, как правильно сформировать IPv4 пакет, чтобы он дошел до вашего личного "IPv8" адреса?
Их придется обновить. Тут не возражаю.
Это все еще реальная задача в отличии от обновить весь софт и все железо под ipv6. Объем работ несопоставимо меньше.
Их придется обновить. Тут не возражаю
то есть, чтобы мне, как юзеру IPv4, коммуницировать с вами, юзером нового "IPv8", все равно придется обновить свой софт и железо? Так а в чем тогда разница с IPv6 получается? То же самое. Промежуточные узлы можно не обновлять? Но в IPv6 при использовании туннелей и relay серверов промежуточные узлы тоже можно не обновлять.
Нет конечно. Ваш провайдер обновит одну железку у себя и все само заработает.
Одну концептуально, физически их штук пять наверно.
Ваш провайдер обновит
зачем ему это делать? Если он не обновил железку под IPv6, почему обновит под "IPv8"?
и все само заработает
ну как минимум ОС на девайсах придется обновить ведь? Вы скажете: "это несложно, производители ОС быстро сделают", но ведь и поддержку IPv6 они тоже достаточно быстро сделали. Проблема не в софте, а в провайдерах, которые не хотят включать IPv6, даже если их маршрутизаторы все поддерживают. А если не поддерживают, то не хотят покупать те, которые с поддержкой. И то же самое будет с вашим "IPv8", ведь админам провайдеров нужно будет разбираться с настройкой этого протокола в любом случае, это для конечных абонентов переход может случиться незаметно.
В результате в случае с "IPv8" мы наделаем кучу костылей но не получим видимого преимущества в плане миграции. Поэтому я не удивлен, что было решено делать архитектурно другой протокол вместо нагромождения костылей на IPv4.
Когда провайдеру надо обновить несколько самых больших железок и получить понятный бонус который можно продавать это будет сделано за несколько лет.
ОС придется. Но это вообще не выглядит проблемой. МС просто сделает фичу в одном из своих больших обновлений. И все просто заработает при наличии поддержки у провайдера. Никто ничего и не заметит.
С ipv6 проблема в том что этого недостаточно. Нужны какие-то невнятные настройки каждой приложеньки и каждой железки. Я не знаю как на моем пылесосе ipv6 включить, куда уж там среднему пользователю.
Совместимость это очень важно. Прозрачная работа без любых дополнительных действий пользователя это супер важно.
Когда провайдеру надо обновить несколько самых больших железок и получить понятный бонус который можно продавать это будет сделано за несколько лет
как-то это не очень работает для IPv6. Вернее, работает, но не для всех провайдеров.
С ipv6 проблема в том что этого недостаточно. Нужны какие-то невнятные настройки каждой приложеньки и каждой железки
правда? А я чет не в курсе. Роутер раздал IPv6 по дуал-стеку и все устройства, которые IPv6 поддерживают, подхватили адреса. Которые не поддерживают до сих пор, то они и ваш "IPv8" не будут поддерживать.
Приложения тем более настраивать никакие не надо. Все работает прозрачно.
Я не знаю как на моем пылесосе ipv6 включить
обычно это просто галка в настройках сети. И в большинстве случаев ничего настраивать не нужно - включил и все заработало. Нужно оговориться, что от провайдера тоже многое зависит. Если провайдер будет использовать какую-то нетипичную конфигурацию или нетипичный префикс, то тут да, возможны проблемы. Но предполагаемый "IPv8" от подобного тоже не застрахован.
Не работает потому что непонятно что это провайдеру даст. И обновлять надо прямо все железо, а не только бордеры. То есть дороже и профит непонятен, у пользователей оно все равно работать нормально не будет. В моем кейсе надо обновить несколько конкретных железок и потом радостно продавать пользователям новы фичи.
А кто-то поддерживает, но не работает нормально, а кто-то конфликтует. Я вот вообще не уверен за свой пылесос.
Точно не надо? Вы обычный Докер пробовали заводить под ipv6? Я пробовал, больше не хочу.
И софт который я пишу за деньги под ipv6 пришлось дорабатывать. Прямо код писать, тестировать и все как полагается. За приличную сумму для бизнеса.
Оно все нетипичное и требует поддержки от каждой приложеньки. Я предлагаю как такого избежать. Делаем все максимально прозрачно. Бордером ipv4->ipv6 выступает любой маршрутизатор который такое умеет. По дефолту провайдерский. Пользовательский софт живет под ipv4, пока явно не объявит что хочет жить на ipv8, ОС разводит сама. Серверный софт вроде бы придется дописать, но с учетом реверспрокси можно и не дописывать.
Пользовательский софт живет под ipv4, пока явно не объявит что хочет жить на ipv8
и пока он живет под IPv4, не сможет работать с "IPv8", потому что не знает, как формировать пакет для "IPv8". Чем это по сути отличается от IPv6? Я не вижу разницы.
Оно все нетипичное и требует поддержки от каждой приложеньки
если "приложенька" использует стандартные апи ОС и не лезет туда, куда ей лезть не надо, все будет работать из коробки. Конечно, если в приложении хардкодить размер адреса IP, или конкретные адреса-диапазоны, то вылезут проблемы. Но это нужно делать только если софт network-специфичен.
Более того, для поддержки "IPv8" таким же образом нужно патчить network-специфичный софт.
Я вот вообще не уверен за свой пылесос
его можно оставить в сети IPv4, в любом случае провайдеры, даже те, которые перешли на IPv6, доступ в сеть IPv4 отключать не будут еще очень долго. Она (сеть IPv4) будет просто со временем скукоживаться, но связность между IPv4-островами будет поддерживаться с помощью IPv6.
Или вы имеете в виду, что "IPv8" будет обратно совместимым с IPv4? Да, так можно, но все железо и софт, уже созданные под IPv4, будут несовместимы с "IPv8". То есть, что мы выиграем? Для использования нового протокола все равно нужно полностью обновлять весь зоопарк устройств. Так же, как в случае с IPv6. Да, в сетях "IPv8" будет бесшовная работа с пакетами IPv4, но и сейчас нет проблем туннелировать IPv4 в IPv6.
Тут в комментах есть отличная ссылочка про то что туннелирование сделано так ужастно что не работает. Считаем что его нет.
Вы шутите? Как это не работает? Я прямо сейчас использую IPv6 через туннель к брокеру. И все прекрасно работает.
Вот так. Качество ужастное. Мои личные впечатления с той статьей совпадают.
Качество ниже пяти девяток это не работает.
Можно ссылку на статью?
Да, здесь говорится про туннели, но именно про бесплатные публичные 6to4 и Teredo. Эти типы туннелей сейчас убиты, к сожалению, поэтому смысла обсуждать их сегодня нет. Прямо сейчас я использую туннель через брокера (локальный брокер в моей стране, не Hurricane Electric) и этот вариант работает отлично. Сама технология туннелирования в интернете используется повсеместно (любой ВПН это тоже туннель, к примеру), поэтому в этом моменте проблемы быть не может.
Туннель может запустить сам провайдер для своих абонентов. И так даже работало поначалу до того, как повсеместно поддержку получил дуалстек.
Формат пакета естественно надо делать удобным для обработки на железе
Как это сделать на уровне железа с минимальными затратами надо думать. Это сложная, но решаемая проблема
Спасибо, не нужно. Уже сделано в v6, при чем лучше чем в v4, в том числе и через упрощение заголовков.
Совместимость, простота, человекопонятность, удобство и просто все работает так же.
Нет никакой совместимости, обновление софта, обновление железа. Соответственно никакой простоты, это снова годы и годы. Человекопонятность? А ради чего? А удобство… не вижу принципиальной разницы, не занимайтесь ручным вводом адресов, оно вам не надо.
Затраты для провайдеров локальные и понятные
Никакого выигрыша перед затратами для перехода на v6
Так можно получить и совместимость и повышение продаж.
И выиграет только продажник? Ни пользователь, ни провайдер… Но инженеры получат свои человеко-часы на бесполезную работу
Альтернатива еще много десятилетий жить как есть. До конца века я бы сказал. Она точно лучше?
Я не понимаю почему разработка и внедрение вашего варианта «IPv8» могут пройти быстрее и безболезненнее чем окончательный переход на IPv6. Там «боли» ровно столько же, сколько было с v6, но путь надо начинать с начала, а добавление лишних 16 бит несёт меньше пользы чем доступное пространство в v6 при распределении по /64 на каждое оконечное устройство
Из за совместимости и прозрачности. Ну и из-за того что не ломаются нормальные кейсы использования сети. Вроде NAT.
IPv6 не летит из-за своей концепции «мы весь мир разрушим до основания, а затем мы новый мир построим». Вот ее и надо исправлять.
Оставляем все что отлично работает. Приватные адреса, nat, dhcp и далее по списку. Чайнику не надо выбирать себе адрес и не надо быть адресуемым из интернета.
Не трогаем текущих ipv4 клиентов. Они должны работать сколько угодно времени. Трансляцию и адресацию таких клиентов и таких пакетов вставляем прямо в стандарт. Провайдеры на своих Нат железках это без проблем поднимут.
И получается что возможна постепенная миграция, без двойных сетей. И не ломается ничего из стандартных решений.
Из за совместимости и прозрачности.
Нет никакой совместимости в вашей схеме, это новое железо и софт. И годы на стандартизацию и запуск. Это тот же самый
мы весь мир разрушим до основания, а затем мы новый мир построим
Только в результате ты сможешь зачем-то запоминать десятичные цифры адреса. Мне это также непонятно как и необходимость запомнить ipv6-адреса.
А поддержка v6 уже часто есть сегодня.
Оставляем все что отлично работает. <...> nat...
Мы тут придерживаемся разных позиций. NAT - это костыль от безисходности, а не «отлично работает». Нет, я не говорю что он вообще не работает, это не так. NAT - это инструмент и свою задачу он выполняет, как может, пусть и это создает проблемы.
Чайнику не надо выбирать себе адрес и не надо быть адресуемым из интернета
Тебе не надо думать какой адрес получил чайник. Ему вообще должно неплохо житься на Link-local. Это вопрос не к стеку, а к вендору, если он хочет GUA и не умеет в фаерволл
И получается что возможна постепенная миграция, без двойных сетей. И не ломается ничего из стандартных решений.
Невозможна, мы также будем иметь две сети, одна из которых будет уметь слать пакеты во вторую, а вторая - нет. Мы снова имеем дуалстек, только вторую сеть мы спроектировали не с нуля, а с оглядкой на плохие решения в первой
P.S. Ты вообще знаешь что 127.0.0.1 - не единственная корректная форма записи? Можно ведь и 3232235786, или 0x7F000001
Второй и не надо. Та же железка которая сейчас натит будет конвертировать все как надо. Это конкретная железка и ее купить или обновить это реальная задача, в отличии от обновления всего.
Вот с таким подходом к нату понятно почему ipv6 не летит. Нат это идеальная технология для современного мира. Чайник не адресуем. И это видно прямо на нем, не надо думать через что он подключен и как это что-то настроено.
Джейсон это идеальный формат для 99.99 процентов задач потому что он человекочитаем. Это важная характеристика. Не надо ее просыпать просто так. А ipv6 ее просыпал просто так. В такой размерности адресов нет смысла. Можно смело делать меньше и сохранять понятность для человека.
Про адреса не думать хорошо пока все работает. А вот как что сломалось или пошло не по плану…
Это две стороны одной медали. Сеть - это то что создано для человека и действительно, идеальный вариант это удобство чтения и использования. Домохозяйке с чайником даже не надо 192.168, достаточно розетка номер 1 и шнур номер 2. Всё. Равно как JSON -> CSV, достаточно нажимать кнопку "запятая" без всяких скобочек и кнопки вверх-вниз. Но вот далее когда начинается транспорт её запросов, там будет уже другой вариант, когда нужно организовать общение уже уровня сервер-сервер. И там уже вообще говоря человеку не место, идентификаторы присваиваются автоматически. UUID чем не IP8, да ещё и с временной меткой. Там и дату отправки пакета можно прикрутить, чтобы спустя хотя бы лет 10 он был доставлен, если эту выпавшую флешку воткнуть заново.
А дальше начинается малый бизнес. 10-30 сотрудников. У них уже есть офисная сеть, какие-то принтеры, какие-то общие файлики, 1C, CRM, отказоустойчивость хотя бы минимальная и все такое. Опять же IOT в офисе какой-то стоит.
Все это поддерживает кто-то недорогой на полставки. Ему надо понятно чтобы было.
Варианта для домохозайки уже не хватает, а умений делать сложные штуки еще нет.
ipv4 с натом и простым переключением на резервный канал от другого провайдера подходит и им тоже. Это настроит как раз тот самый недорогой человек на полставки и оно будет работать годами без проблем. На том же самом Кинетике чуть ли не мышкой все накликать можно. А вот с ipv6 появляются вопросики.
Ну итаниум без обратной совместимости утоп
Ну он утоп не столько из-за совместимости, сколько из-за плохой совместимости vliw с реальной жизнью. Ну и дикий ценник.
Интересный нюанс проявился в России. Долгие годы все инструменты цензуры и блокировок заточены под IPv4-адреса. Файлы запрещённых сайтов, в основном, содержат списки IPv4-сетей. Да и существующая инфраструктура DPI у провайдеров настроена на старый протокол.
Откуда дровишки? Точно так же все VPNы на v6, адресах работают, как и на v4, с регулярными отвалами.
Интересно, а когда Ipv6 будет везде, будут ли его студенты использовать для настройки ip адресации в Cisco packet tracer?
Статья хорошая, но упущен главный менеджерский аргумент. Переход на IPv6 - это OPEX с неясным выхлопом и кучей рисков, а покупка блока IPv4 - это понятный CAPEX. Пока второе проще заложить в бюджет чем первое - никто никуда не полетит, бизнес не любит R&D в проде
Узколобые в своей идеалистичности разработчики IPv6 удалили NAT. А не нужон он им теперь, адресов же много! В результате:
1. SLAAC полностью убивает приватность устройств, поэтому надо генерировать узлу второй рандомный адрес и следить, чтобы это работало. А с рандомным адресом написание правил для МСЭ становится поистине увлекательным
2. Переключение офиса без AS на резервного провайдера становится тем ещё квестом, так как надо единомоментно во всей сети поменять адреса. Или хранить на каждом устройстве пул адресов двух провайдеров. В корпоративной сети на тысячи машин это бред. Есть конечно Preffix Address Translation. Но тогда опять же возвращаемся к неоднозначным правилам для МСЭ
Бред какой-то. Два жутких костыля в очень непродуманный протокол. IPv4 на его фоне гораздо разумнее.
А с рандомным адресом написание правил для МСЭ становится поистине увлекательным
Эм.. А префикс тебе на что? А нормально закрытые фаерволлы? А постоянные ipv6-адреса, если тебе нужно принимать входящие соединения на сервере?
так как надо единомоментно во всей сети поменять адреса.
тебе кто-то мешает раздать все адреса сразу?
Хорошо, я могу и нормально закрытый фаервол и даже statefull DHCPv6. Только почему надо рассказывать, что эта свистопляска для пользователей удобнее, безопаснее и благостнее классической архитектуры?
тебе кто-то мешает раздать все адреса сразу?
Т.е. если у меня два провайдера и в офисе несколько сотен устройств, то каждое должно иметь адреса из двух префиксов и самостоятельно решать проблему доступности дефолта? И это не является усложнением? Или может это более безопасно?
даже statefull DHCPv6
Раз уж мы заговорили о SLAAC, для того чтобы занять постоянный IPv6 в сети не нужен DHCPv6. Его можно занять сразу на устройстве
Только почему надо рассказывать, что эта свистопляска для пользователей удобнее, безопаснее и благостнее классической архитектуры?
Что вы понимаете под классической архитектурой? Нам сначала нужно договориться об этом. А пользователю удобнее просто потому что «воткнул и работает», ему не нужно знать про ip, про privacy extensions, про MAC-адреса. Его фаерволл на роутере будет блокировать непрошенные соединения из вне, а established/related - будут бегать. Ну и естественно возможность прямых соединений - это приятно
каждое должно иметь адреса из двух префиксов и самостоятельно решать проблему доступности дефолта?
Абсолютно нормальная ситуация, это может сделать устройство, или это может сделать маршрутизатор объявив для префикса lifetime 0
И это не является усложнением?
Усложнение? Не думаю, возможно даже упрощение. Не нужно думать о трансляции адресов
Или может это более безопасно?
А должно быть? По-моему одинаково. Хотя сканировать пространство ipv6 - бесперспективное
Не нужно думать о трансляции адресов
У вас фобия именно на трансляцию? Хорошо, мы не будем думать о NAT, зато будем думать о нормально закрытом фаерволе, SLAAC, privacy extension и пр.
И вместо того, чтобы ковырять ненавистный всем сторонникам IPv6 NAT для проброса порта будет ковырять нормально закрытый МСЭ
А админ будет заботиться о двойной адресации в офисе.
Все наработались, всё с ног на голову перевернули, зато победили мерзкий NAT.
У вас фобия именно на трансляцию?
У меня нет на неё фобии, мне она просто не нравится. Если её можно избежать - её лучше избежать. Если избежать нельзя - ну штош, будем с тем что есть.
Хорошо, мы не будем думать о NAT, зато будем думать о нормально закрытом фаерволе, SLAAC, privacy extension и пр.
Зачем мне об этом думать? Оно есть и работает. Я вот уже забыл.
будет ковырять нормально закрытый МСЭ
Задача одного уровня сложности с пробросом порта через NAT, но в отличии от NAT нормально закрытый фаерволл не ломает связность сети.
А админ будет заботиться о двойной адресации в офисе.
Но зачем ему это делать?
Все наработались, всё с ног на голову перевернули, зато победили мерзкий NAT.
Ага
Это всё от того, что адрес устройства не соответствует его месту в сети. Это неисправимый на данный момент недостаток всей IP-архитектуры. Адрес, в общем виде, должен назначаться устройством по заявлению а не присваиванием ему со стороны. Далее, он может получить уникальный виртуальный идентификатор, уходящий уже в таблицы трансляции для многоранговой сети. А вместо этого создаётся некий образ обратной совместимости, на самом же деле это по сути сетевой идентификатор высокой разрядности с околонулевой вероятностью коллизий. То есть в идеальном варианте должен быть бесшовный стек 4<->6, но что-то пошло не так. Хотя могли бы первые 4 байта 4-ки с checksum ввести как суффикс для 6. Тогда и сам адрес можно было бы без ошибок записать а остальные байты это сетевая виртуальная машина, которая парсит уже назначение пакета.
Хотя могли бы первые 4 байта 4-ки с checksum ввести как суффикс для 6
::ffff:192.0.2.1 корректный суффикс, последние две группы заменены на ipv4-адрес. v4 также можно записать и в hex-нотации (вероятно где-то даже будет проводиться автоматическое преобразование). Ну и формально там два варианта нотации, но вариант без "ffff" объявлен deprecated
Существует для отображения v4 в v6
Первым делом отключаю IPv6 на домашнем роутере после его покупки. Без должной настройки это дыра в безопасности, а грамотно настроить не сможет не то, что домохозяйка, но даже более-менее шарящие люди.
Надо придумать ip7 обратно совместимый с ip4 и ip6.
IPv6 — очень хорошая и полезная технология, вопрос другой, что он (как это ни странно) — не замена IPv4. Т.е. технически им можно заменить IPv4, но если подумать, то смысла в этом мало.
Это нишевый протокол, который на последней миле нужен только небольшому количеству энтузиастов.
Уточнение: нишевый — не значит "плохой" или "неполноценный".
Пример: насколько я знаю (могу ошибаться, но для иллюстрации годится), адресация внутри яндекс.облака сделана на чистом IPv6 и это прекрасное архитектурное решение, где IPv6 уместен и удобен (а IPv4, соответственно, не очень).
Осталось только найти в нём какую-то пользу, кроме разрядности адресации
ну вот, я искал. Не нашёл.
>Главная проблема нового протокола кроется в его дизайне. IPv6 не совместим с IPv4 — это фактически отдельная сеть. Устройство или сайт с IPv6 не сможет напрямую «общаться» с узлом, у которого только IPv4. Отмечу, разработчики шестой версии сознательно не стали делать её надстройкой над IPv4, решив радикально обновить протокол.
Прочитав эти фразы, можно полностью предсказать все описанное в статье на все 30 лет вперед и еще на десятилетие в будущее.
Делаем что-то новое принципально несовместимое со старым, да еще и такое, чтобы переход был максимально болезненным и дорогим.
Само собой ради того, чтобы это новое было прям таким красивым, изящным и нравилось его разработчикам.
Сколько было таких историй в IT и сколько еще будет. В свое время так IBM проиграла рынок операционок для PC со своей OS/2 против заботившейся о совместимости Microsoft (когда-то я переводил про это статьи - раз, два, три). Потом сама Microsoft ровно по тем же самым причинам проиграла рынок уже мобильных операционок Google. Джоэл Спольски написал про это популярную статью аж в 2000 году, хотя сейчас наверное уже сложно понять, что за Netscape такой там описывается, да и самого Спольски уже наверное забыли и постепенно забывается созданный им Stack Overflow.
Из личной практики. Работал в крупном хостинге. Миллионы сайтов. Сотни гигабит исходящего трафика. Много клиентов, названия которых вы видите каждый день.
Когда я вышел с предложением внедрить IPv6, мне задали всего несколько вопросов:
- за счет каких ресурсов внедрение (а ресурсов нужно очень много - куча софта, железа, мониторинг, DDoS protection - все заточено под IPv4)?
- что получит бизнес в результате внедрения?
Тут все внедрение и закончилось.
IPv6 реально красив. Но в действительности не нужен. Ни операторам, ни генераторам контента, ни клиентам. Админам тоже лишние проблемы и к чему.
Я, кстати, в конце концов, дома тоже отключил - надоело вылавливать плавающие глюки dualstack.
Из личного опыта. Работал в крупной компании, занимающейся освещением нескольких крупных городов. Десятки миллионов населения. Города, про которые вы слышите почти каждый день. Когда я предложил перевести освещение с лучин, свечей, керосиновых ламп на электричество, мне задали всего несколько вопросов:
за счет каких ресурсов внедрение (а ресурсов нужно очень много — генераторы, провода, трансформаторы — все заточено под свечи, лучины и керосинки)?
что получит бизнес в результате внедрения?
На этом внедрение и закончилось. Электричество реально удобно. Но на деле не нужно. Ни операторам, ни клиентам, ни людям. И у тех, кто этим всем управляет, тоже лишние проблемы. Я в итоге дома тоже электричество отключил — надоело вылавливать перебои с подачей энергии. /s
Подобные аргументы "против" выглядели более или менее здраво, когда доля IPv6 в мировом трафике была мизерна. Сейчас она приближается к 50%
Пример некорректный
за счет каких ресурсов внедрение (а ресурсов нужно очень много — генераторы, провода, трансформаторы — все заточено под свечи, лучины и керосинки)?
что получит бизнес в результате внедрения?
1) за счет городского/федерального бюджета
2) заказ на реализацию освещения в городе
тут спрашивать надо что заказчик получит от реализации этого проекта, компания которая занимается освещением - не заказчик
Самое смешное во всём этом, что RUVDS, в блоге которой опубликована эта статья и сам не выдаёт клиентам своего хостинга IPv6 адреса. Взял один и был очень удивлён, что его нет.
Совместимость - главная причина. Это все равно что Майкрософт выпустит новую версию офисного пакета, несовместимую со старыми форматами документов.
Автор точно никогда не внедрял IPv6. Говорю так, потому сам это внедрил и знаю не понаслышке что и как.
По факту внедрение провайдером дуалстека имеет не те проблемы что в статье описаны.
Например, если провайдер предоставляет подключение PPPoE, то 99% оборудования на сети провайдера не требуют поддержки IPv6, а на магистралях IPv6 уже давно обязателен!
Реальные причины медленного внедрения описываю из первых рук т.к. внедрил дуалстэк на 100% покрытия ISP. Т.е. уже лет 5 как любой абонент может себе подключить дуалстэк при условии что его оборудование это умеет делать, ну тот же WiFi-роутер например.
Вот что реально имеет значение
----------------
1. Поддержка IPv6 на железе провайдера - лет 10 назад имело решающее значение, но вот уже лет 5 как проблем нет. На магистральной части сети и в ядре у провайдера железо почти всегда "более свежее" чем на периферии, и следовательно настроить его под дуалстэк и NDP -не проблема!, На перифериипри том же PPPoE-терминировании это не играет вообще никакой роли! Для IPoE - нужна адекватная поддержка NDP и в целом ряда связанных с NDP фич ограничений и безопасности. В схеме "vlan per user" - будет ещё проще. По сути это стартовый и сейчас наименее важный вопрос.
2. поддержка в билинговой системе - это может быть сложно в каких-то системах, но вряд-ли прямо таки критично. Безусловно это требует некого внедрения, как и любые сервисы у ISP. В целом это не настолько и сложно как следующие пункты.
3. Наиболее технически сложные проблемы связаны именно с абонентскими CPE (WiFi-роутеры в 99% случаев) -вот тут до недавнего времени была полная засада с поддержкой дуалстека, особенно с нормальной поддержкой такового. Но сейчас большинство роутеров дуалстек поддерживают, особенно в PPPoE. И, как показала практика, даже наличие адекватной поддержки дуалстека в роутерах проблему не решает кардинально без одного важного условия. Об этом далее.
4. Как ни странно но именно на текущий период (конец 2025г) ещё более важное условие не просто потенциального внедрения IPv6, а именно как массового штатного подключения абонентов к сети Интернет - это банально условие того что в идеале роутер из коробки имеет включенную поддержку IPv6, либо же в компромиссном варианте его стартовый визард настройки должен по дефолту иметь включенным функционал дуалстека и... внезапно! этот функционал должен автоматом понимать какой вид подключения IPv6 используется провайдером. Да-да, этих видов автоматического предоставления IPv6-адресации наплодили минимум 3, а ещё есть их сочетания (О боже! О чем думали эти люди??? ) Я бы для ISP ограничил это все использованием IA_NA или IA_PD адресации, ну и RA конечно, куда же без него! Я знаю подобных на 100% дуалстэковых роутеров на пальцах одной руки - это совсем мало. Выход лишь один - провайдер сам их не начнет массово абонентам предоставлять вместо ширпотреба "за 3 копейки"!
Ещё раз. Если владелец сделал сброс настроек роутера- после этого по дефолту дуалстек на роутере должен быть и он должен быть рабочий как для внешки так и для выдачи в LAN-сегменте и безо всяких "плясок с бубном"! Это краеугольный камень МАССОВОГО внедрения, кто бы чего не воображал иначе. Потому что даже если вы каждый роутер правильно настроите и отдадите абоненту, сброс настроек роутера - всего лишь вопрос времени...
Другой подход - использовать ACS-сервер, который при старте девайса сам его настроит правильно. Но тут проблем больше чем профита, особенно если в сети зоопарк CPE.
У ОПСОС-ов с этим пунктом как раз всё очень хорошо - у них это сразу продумано норм. И именно мобильные операторы (тот же МТС) после внедрения IPv6 имели огромный процент использования сервиса абонентами, более 70% сразу же.
5. Адекватные контент провайдеры с IPv6 и вообще сайтописатели и прочие ресурсы в самом Интернет с IPv6. Этот пункт влияет именно на соотношение IPv4 и IPv6 трафика у пользователя с дуалсткеком. Чем больше % трафика переходит на IPv6 - тем ближе мы к главной цели - отказу от супер-костыльного IPv4+NAT+NAT (и даже ещё пару раз +NAT на стороне другого абонента у другого провайдера!!!). NAT - это вынужденная мера, которая превращена в обязателную!
Гиганты Интернета двигают IPv6, тот же гугл например. А вот мелкие участники - не сильно серьезно это делают. Даже игроделы, онлайн-кинотеатры и пр. не особо шустро шевелятся. Хотя уже пошустрее чем пару лет назад.
На ресурсах в РФ по этому вопросу есть к чему стремиться. Похвалить навскидку могу только Яндекс - у них подход более-менее глобальный на свои сервисы.
6. Сейчас вопрос менее критичен, но на старте был очень злободневный - нагрузка на техподдержку больше с дуалстэком чем с просто IPv4. И даже некие репутационные потери могут быть, хотя виновники в большинстве случаев вне ЗО провайдера.
Казалось бы пользователь получат прогресс, но в то же время и связанные с этим недоработки на всех вышеперечисленных пунктах.
Прример: Некий сайт на IPv6 версии показывает тупо страницу-заглушку, а на IPv4 - все с ним отлично. Виновник - владелец сайта, но страдает пользователь с дуалстэком.
Проблемы прошивок роутеров - туда же! проблемы адекватного инжиниринга IPv6-маршрутов во внешке - туда же! И много чего ещё.
Автор точно никогда не внедрял IPv6. Говорю так, потому сам это внедрил и знаю не понаслышке что и как.
А можете рассказать, какой профит ваша контора получила? В частности, компенсировал ли он хотя бы рост нагрузки на техподдержку.
Но сейчас большинство роутеров дуалстек поддерживают, особенно в PPPoE.
Насколько вам от этого "сейчас" легче? Вопрос связан с тем, что вряд ли пользователи меняют свое оборудование, если оно и так работает - скорее они сменят провайдера ;-), если его внедрение IPv6 нарушает их покой.
Я вот в этом плане пользователь нетипичный: крайний раз я менял маршпутизатор пять лет назад, из-за скачка напряжения от молнии, прилетевшей рядом с телефонной линией (у меня была ADSL), а предыдущий - ещё за 10 лет до того, по той же причине. А потому я сказать ничего не могу - у меня оба раз за 20 с лишним лет замена была вынужденная.
А можете рассказать, какой профит ваша контора получила? В частности, компенсировал ли он хотя бы рост нагрузки на техподдержку.
По профиту оценить трудно, как минимум мы это делали потому что всё текущее оборудование позволяло это сделать. В бОльшей степени это был энтузиазм и стремление быть современной компанией. В то время (2018 - 2022г.) популярность IPv6 набирала обороты и этот проект скорее был заделом на будущее (быть готовыми к новой реальности) а так же задачей в будущем минимально "вляпаться" в NAT (в то время мы всем абонентам выдавали "белые" IP) заранее подготовив абонентов к дуалстеку.
После опытного внедрения, набив много шишек начиная со стенда, проработав вопросы с вендорами железа стало понятно что "не так страшен черт...".
И поскольку наше оборудование уже было готово на скажем 90-95% и наша билинговая система была так же настроена на этот сервис - решили не останавливаться и предоставлять превентивно сервис дуалстека всем желающим. Конечно абонент может отключить эту возможность и использовать только IPv4 независимо от своего оборудования. Но обычно достаточно лишь настроить дуалстэк на CPE и получить его, или не настроить и не получить.
Профит скорее всего есть в данный момент только как "конкурентное преимущество", но и по доп. затратам нам это ничего не стоит. Но ведь это же вложения в будущее, по сути мы в него переходим постепенно, а не как у нас обычно и аврально по типу "внезапно пришла зима".
Доп нагрузка на ТП была в самом начале, но тогда и % использования буалстека был низким. Потенциально в сети с поддержкой дуалстека наверное около 35-40%, но реально используют его кмк не более 20%. Это очень прилично для оператора ШПД.
И хотя по количеству трафика IPv6 у этих абонентов составляет примерно около 16% (на общем фоне это вообще около 7% трафика), оно составляет реально много по количеству коннектов мимо NAT.
% роста за последние несколько лет можно сказать что остановился и кмк это в первую очередь потому что в рунете контент-ресурсов по IPv6 представлено мало.
Например всякие IVI и т.п. жирные поставщики трафика (да и торренты тоже) всё ещё отдают в зоне IPv4 - потому-то в количестве трафика IPv6 процент не большой.
Как только такие крупные контент-провайдеры начнут отдавать в IPv6 - у нас % трафика резко подскочит. Например тот же яндексовский kinopoisk давно в зоне IPv6 работает, а вот IVI - пока нет.
Насколько вам от этого "сейчас" легче? Вопрос связан с тем, что вряд ли пользователи меняют свое оборудование
Вы правы - замена роутеров у абонентов процесс не быстрый. Но есть факторы ускоряющие этот процесс. Переход со 100Мбит на 1Гбит часто это означает замену роутера. Желание поиметь более скоростной и современный стандарт WiFi - ещё более частый случай замены роутера, а ещё абоненты желают иметь MESH - тоже означает замену роутера(ов). Тем не менее более половины роутеров с сети наверное "умирают своей смертью". К тому же есть ещё вторичный рынок для роутеров через "условный авито", после чего роутер продолжает жить у другого абонента, но так же в нашей сети, либо он переходит в нашу сеть от другого провайдера.
Все роутеры, которые мы сами предоставляем абонентам, предварительно тщательно тестируются на предмет соответствия всех нужных нам функций в т.ч. правильного дуалстэка.
IPv6 в принципе в сети продвигается почти что только благодаря тем моделям роутеров, которые мы сами продаем абонентам (причем у нас они дешевле чем в магазине), либо если такие же роутеры ставят сами абоненты. Остальной "зоопарк" роутеров почти никак не играет роли.
Кстати, есть редкие модели роутеров, которым категорически нельзя работать в IPv6, это старые модели с багами. Самый опасный - DIR-615 именно с некой версией прошивки 2.5.x. Если не знать об этом, он может устроить в сети "переполох". Мы это прошли давно и научились подобное нивелировать.
Из позитивного, буквально полгода назад наш проверенный годами поставщик предоставил модель, в которой IPv6 включен из коробки - это переломный момент, потому что в нашей сети это станет локомотивом, протянувшим IPv6 ещё более массово.
Да, на рынке есть уже и другие роутеры с такой тенденцией, но эта тенденция пошла совсем недавно в глобальном масштабе продаж роутеров. До этого нам было намного сложнее предоставлять IPv6 конечному потребителю.
Важно понимать что IPv6 должен стать обыденностью для абонентов, а не экзотикой для гиков. Абонентам не нужно в этом разбираться, им просто нужен Интернет "хоть по синему лучу, хоть голубями". IPv4 - это же просто обыденность получения услуг от провайдера, дуалстэк - уже новая реальность и он должен быть доступен всем.
С пользователями мне всё почти (я не понял только, что это за услуга MESH - то есть что от нее получает пользователь) понятно, и, похоже, они пользы от IPv6 не видят и деньги за него платить не готовы, так?
Жаль, что вы не раскрыли, какой профит от внедрения IPv6 вы получаете как оператор, для ваших внутреених прцессов.
я не понял только, что это за услуга MESH
Не услуга, в контексте роутеров/AP обычно идёт речь когда стоит несколько железок раздающих wifi объединенный в одну сеть. В идеале это все прозрачно для устройства и момент перехода между точками доступа незаметен. Сейчас продают комплекты роутеров которые автоматом в такую собираются, и между ними и AP с «быстрым роумингом» все же есть отличия по работе
В целом mesh-системы намного более «user friendly» для бесшовного wifi на небольшой территории чем альтернативы годами работающие в «энетрпрайзе»
Теперь понял. Когда-то и у меня был такой MESH, в конце нулевых годов. Но IPv6 там не требовалось, и вообще IP тоже - там все на L2 разруливлось (если что, это были AP, а не маршрутизаторы, аутентифкация была через RADIUS на КД.
А вот дома мне такое не нужно - единственный маршрутизатор светит на всю квариру (а еще немного на улицу). Ну, возможно, если бы дом был панельный и монолитный, понадобилось бы, но у меня - хороший советский кирпич образца 1960 года.
Могу оценить IPv6 только со стороны клиента. Сам дома так настроил сеть, что могу пользоваться полноценно интернетом отключив IPv4. Увы, провайдер не предоставляет NAT64, так схема была бы проще, поскольку пришлось NAT64 поднять на своём маршрутизаторе.
Мобильные устройства прекрасно работают в сетях только с IPv6. Более того, могут легко раздать интернет с APN только с IPv6 и при этом выдать клиентам IPv4 адреса. Т.е. провайдер работают исключительно на IPv6, но при этом пользователь имеет доступ и к IPv4 сервисам.
Всё плохо с «настрольными» ОС, за исключением MacOS. Нет, большая часть сервисов будет доступна как и прежде, но некоторые вещи отваливаются. Например, торренты теряют очень много сидов, т.к. в основном все раздают на IPv4 (но всё зависит от раздачи, что-то и по IPv6 можно сказать). Также не работает Steam, точнее работает только в оффлайн режиме. Но всё чинится с помощью clat (как раз он есть на всех мобильных ОС). В Linux придётся ставить clat руками. Например, у меня сейчас стоит модифицированный NetworkManager с поддержкой clat. На текущий момент с точки зрения пользователя всё работает, но есть некоторые косяки, которые не исправили, например, не работает трасировка маршрута, mtr 1.1.1.1 выдаёт недоступность, но mtr 64:ff9b::1.1.1.1 вполне себе всё показывает. Для Windows 11 Microsoft недавно анонсировало расширение clat для всех типов соединений. Увы, пока не могу протестировать. Плюс, похоже даже Windows 10 в пролёте.
Как вывод.
В целом вообще никакой проблемы перейти на IPv6 с помощью DualStack. Клиентский софт потихоньку подтягивается и скоро позволит работать без ограничений в сетях IPv6only. По сути это тот же протокол IP, поэтому вообще никаких проблем нет с большинством софта. Большинство сервисов IPv4 вообще можно обмануть и обращаться к ним из IPv6 сетей. Скорее проблема найти сервис IPv4, который нельзя обмануть (это если устаревшие вызовы ОС использует софт, либо оперирует непосредственно IPv4 литералами).
Провайдеры тоже легко могут перейти на сеть IPv6only, но только если будут предоставлять абонентам свои CPE, которые обеспечат абонентам дуалстек. При этом провайдеры избавляются от CGNAT c NAT44 и заменяют его на NAT64, нагрузка на который будет падать со временем.
При этом провайдеры избавляются от CGNAT c NAT44 и заменяют его на NAT64, нагрузка на который будет падать со временем.
Согласен с вашими выводами, очень хорошо описали и в точку о многом.
Но вот по цитате - категорически не согласен!
КМК если уже внедрен дуалстек и CGNAT c NAT44, то теряется смысл это всё переводить в IPv6-only на стороне аболнентов + замена варианта NAT44 на NAT64
Ведь всё уже внедрено и работает, более того - нагрузка на NAT44 постоянно уменьшается т.к. контент постепенно переползает в IPv6, а тут бац! и давайте начнем "перевнедрять" и это же глобально на всю сеть! Нет, на такое бизнес точно не подпишется, тем более что в плане совместимости у NAT64 всё еще есть проблемы, тогда как NAT44 работает "как автомат Калашникова"
нагрузка на NAT44 постоянно уменьшается т.к. контент постепенно переползает в IPv6
Так в том то и весь прикол, что ставят CGNAT, но при этом не внедряют IPv6! А зачем? У них ведь и с IPv4 всё работает. Фактически число абонентов растёт, аппетиты растут, а всё это идёт через CGNAT. Если же ты внедряешь NAT64, то у тебя уже сеть построена на IPv6 и тогда трафик действительно уходит на IPv6 постепенно.
Если же внедряют IPv6 и используют CGNAT, то молодцы, можно и так. Тогда доля IPv4 действительно будет сокращаться. Но приходится двойную работу делать в сети, чтобы IPv6 и IPv4 предоставить абонентам.
замена NAT44 на NAT64 - это только в теории гладко, может у мобильных операторов как то получится, а вот у ШПД - никак.
Просто потому что для этого нужно вообще ВСЕ абонентские устройства перевести на IPv6, в т.ч. и те, что в домашних LAN-сетях. Сделать это одномоментно просто нереально.
С дуалстеком всё проще - IPv4-only девайсы будут отмирать постепенно, всё будет у всех работать либо по IPv4, либо по IPv6
Просто потому что для этого нужно вообще ВСЕ абонентские устройства перевести на IP
Не нужно ВСЕ переводить. Вообще их можно на IPv4 оставить. Просто на маршрутизаторе включаете CLAT, который работает с PLAT провайдера. Вместе это 464XLAT. Т.е. IPv4 трафик от клиентов локалки уходит на маршрутизатор, который заворачивает всё в IPv6. Этот IPv6 трафик по сети провайдера идёт на шлюз NAT64 провайдера и там обратно преобразовывается с IPv4. Провайдер в плюсе, ибо у них вообще нет IPv4 нигде, кроме NAT64. Абоненты могут хоть по старинке всё использовать на IPv4, хоть переводить свою сеть на IPv6.
Это собственно так и работает с применением MAP-T (или MAP-E).
CPE пользователя получает только IPv6 PD, используемый для адресации LAN пользователя. Так же эта LAN адресуется как обычно IPv4 RFC1918. Пользовательский трафика IPv6 роутится нативно. Трафик IPv4 декапсулируется на CPE, данные инкапсулируются (в случае MAP-T) в пакет IPv6, где адрес назначения IPv6 в части префикса содержит адрес BR (шлюз CGNAT), а в части интерфейса - переведенный в hex адрес назначения IPv4. Пакет нативно роутится через IPv6Only бекбон провайдера до BR, где данные декапсулируются из пакета IPv6 и создается пакет IPv4 с адресом назначения извлеченным их интерфейсной части адреса IPv6, а адресом источника IPv4 ставится публичный адрес IPv4 из пула на BR. Для ответного пакета трансляции происходят в обратном порядке.
Не нужно ВСЕ переводить.
Точно не нужно???
А как же "Трафик IPv4 декапсулируется на CPE" и т.д. ?
Как это сделать на текущих CPE без поддержки CLAT MAP-T и т.п.?
Т.е. вот с дуалстеком мы ставим условно только одну железку (или пару-тройку) NAT44 за условно 1-5 лямов руб.
А для реализации 464XLAT нам надо и коробку NAT64 иметь (скорее плюсом купить аналогично как и коробку NAT44) и ещё дополнительно обязательно всем подарить совместимые с таким решением CPE ?
3000 руб за одну новую CPE (надеюсь не дороже?) умножаем условно на 100000 абонентов = 300 лямов подарить? И это не считая затрат по замене у абонентов, что будет тоже довольно затратно и по деньгам и по времени и т.п.
На этом фоне CGNAT коробка NAT44 выглядит буквально как "копейки"
Бизнес план просто АГОНЬ! Акционеры точно согласятся!
Необязательно речь идет о замене CPE, вполне возможно достаточна доработка софта. CPE поставляется провайдером? Тогда это затраты провайдера на доработку ПО CPE для поддержки MAP-T. Собственно это логично, так как необходимое изменение ПО связано с выбором архитектуры сети провайдером, точнее это часть провайдерской архитектуры. Если CPE личное пользовательское, то реализация MAP-T существует у многих производителей (включая OpenWRT). В конце-концов это не какой-то стремный хак, а стандарт (RFC7599).
Ваш вариант с MAP-T - это обязательное наличие такого функционала на любом подключаемом оборудовании клиента, причем не в перспективе замещения за 2-5 лет, а вот прям сразу же и у всех без исключения абонентов. Это ключевое условие использования подобной технологии предоставления дуалстека в конечной домашней сети ( сеть LAN роутера ), а на сети провайдера - IPv6 OnLy
Нет, я понимаю если например новый провайдер начинает внедрять это "с нуля", т.е. вот нет у него абонентов и он начинает подключать и раздавать свои CPE MAP-T. Это вот такая бизнес модель с жестким условием, подобное было иранее и есть сейчас - например провайдеры делали сеть DOCSIS, GPON с предоставлением своего абонентского железа, или например шифрованный ТВ-контент - тоже только на оборудовании провайдера.
Так вот если это делается с нуля - всё замечательно, если этот способ дает 100% совместимость с обеими протоколами IP и это всех устраивает. Да я и сам с удовольствием так сеть бы строил СЕЙЧАС, но сейчас мы уже имеем построенную ранее сеть и работаем с тем что есть.
А что у нас есть ? А то что сеть изначально была построена как IPv4 и в ней в качестве CPE сейчас имеется 200-300 моделей роутеров (и не только WiFi), из которых примерно 70-80% EoL.
В этом случае ни о каком варианте MAP-T с массовым обновлением прошивок и т.п. и речи быть не может. Единственный вариант - выбросить бОльшую часть этого барахла и взамен подарить всем роутеры с поддержкой MAP-T, затраты я уже выше прикидывал.
Как итог...
На данный момент обычный дуалстек, с небыстрым внедрением - это единственный практически реализуемый способ внедрения IPv6, который ни от кого не требует авральных мер.
Текущими темпами лет через 5 у нас уже должно быть 50-70% роутеров с поддержкой дуалстека, причем больше всего на такую перспективу сработает эволюция стандартов WiFi, которая как локомотив тянет за собой модернизацию CPE. А новые CPE - это плюсом и поддержка IPv6.
p.s.
На сети провайдера нет никакого напряга с инфраструктурой под оба типа протокола IPv4/IPv6 т.к. по факту подавляющее кол-во оборудования - это просто коммутация, для которой настройка что просто под IPv6, что под оба протокола IPv4/IPv6 имеет минимальные отличия.
Самые большие сложности - это настройка NAT всяких разновидностей на границе с Интернет.
Текущими темпами лет через 5 у нас уже должно быть 50-70% роутеров с поддержкой дуалстека
я думаю их сейчас уже около того, условные dir-300 не особо живут в совремнном эфире многоэтажек, да и вообще в основном уже умерли по естественным причинам (чаще всего это конденсаторы или БП /опять же конденсаторы/, но пользователю проще поменять, чем разбираться)
В целом я полностью согласен с вашей оценкой. В действительности так и просходит и мы прошли через это - от IPv4Only, на DualStack (сейчас это 5/6 парка абонентов xDSL/FTTH), CGNAT чтобы выиграть время на разработку и тестирование MAP-T и наконец сам MAP-T. Коллекты (от доступа до BNG) DualStack, что позволяет иметь абонентов всех типов в общем коллекте и легко мигрировать из одного типа в другой. Например абонент которого не устраивает MAP-T имеет возможность переключиться обратно на DualStack (это менее 1% от мигрированных на MAP-T). Это решает в том числе проблему несовместимости CPE абонента. В ближайшее время вопрос отключения IPv4 в коллектах в планах не стоит, но в перспективе, с обновлением парка и/или миграцией подавляющего большинства абоенентов на IPv6 - не проблема. То есть в конечном итоге - да, когда-нибудь, предвидится.
Я единственное не понял, откуда 200-300 моделей роутеров? Имеются в виду CPE предоставляемые провайдером? У нас дай бог десяток моделей наберется, бОльший зоопарк провайдеру тянуть смысла нет. Пользовательские собственные CPE? Можно, но абонент либо поддерживает MAP-T, либо запрашивает возврат своей линии на DualStack и тогда использует стандартный набор параметров DHCPv4/v6.
Я единственное не понял, откуда 200-300 моделей роутеров? Имеются в виду CPE предоставляемые провайдером? У нас дай бог десяток моделей наберется, бОльший зоопарк провайдеру тянуть смысла нет. Пользовательские собственные CPE? Можно, но абонент либо поддерживает MAP-T, либо запрашивает возврат своей линии на DualStack и тогда использует стандартный набор параметров DHCPv4/v6.
Да, это "Пользовательские собственные CPE"
Запрета их использования не было и нет. Не спрашивайте у меня почему, я сам не знаю ответа.
Хотя самые массовые модели - это свои от провайдера, но ведь и сам провайдер ранее предоставлял модели разные и многие без дуалстека. Их ещё есть немало в сети.
Огромный зоопарк моделей TP-Link, я этого вендора уже перестал понимать - они штампуют столько моделей, что наверное уже сами устали их поддерживать. Видимо оно хорошо продается, потому и много...
Более 200 - это только то что можно прямо или косвенно распознать. А есть ещё и несколько тысяч всякого неопознанного, или же специфичного - цыски всякие у юриков и т.п.
Интересно. Точнее интересная политика, хотя видимо подход как в штатах - либо аренда, либо свой собственный роутер. В Европе провайдер по умолчанию предоставляет свой роутер, это входит в абонемент. Хотя можно обойтись своим собственным оборудованием, но это исключительно гики, их доли процента. Потому вопросов совместимости не стоит ни у провайдера, ни у абонентов.
У меня в одном месте ADSL, роутеру больше 10 лет точно (бесплатная аренда от провайдера). Меня пока устраивает, а провайдер, видимо, боится отключать, т.к. я, скорее всего, уйду к другому в таком случае.
А для реализации 464XLAT нам надо и коробку NAT64 иметь (скорее плюсом купить аналогично как и коробку NAT44) и ещё дополнительно обязательно всем подарить совместимые с таким решением CPE
Тут провайдеру решать:
ставить NAT44 и делать в своей сети два стека;
ставить NAT64 и выдавать клиентам CPE подходящие.
И там и там расходы. Но если не внедрять IPv6, то придётся вечно содержать эти самые NAT44 и увеличивать их мощности.
Вы конечно правы, если общемировую тенденцию смотреть.
Но в РФ я пока не вижу перспектив увеличения доли IPv6 трафика в потреблении. Потому и будет увеличение объемов NAT44.
У провайдера сейчас забота не стремление идти в ногу со временем, а скорее выжить с учетом расходов по "складированию мертвых тонн данных о трафике"...
Сам дома так настроил сеть, что могу пользоваться полноценно интернетом отключив IPv4.
пришлось NAT64 поднять на своём маршрутизаторе
по-моему противореячащие друг другу пункты, ваше решение больше не про отказ от ipv4, а про замену провайдерского адреса ipv4 адресом хостинг-провайдера.
провайдеры избавляются от CGNAT c NAT44 и заменяют его на NAT64, нагрузка на который будет падать со временем
так оно так и происходит, и в штатах, и в азии есть мобильные операторы, которые дают клиентам только ipv6 (+nat64)
Мобильные устройства прекрасно работают в сетях только с IPv6. Более того, могут легко раздать интернет с APN только с IPv6 и при этом выдать клиентам IPv4 адреса.
не понял что вы имеете в виду
по-моему противореячащие друг другу пункты
Никак не противоречит. Я не говорю, что мой провайдер даёт мне интернет только по IPv6. Я пытаюсь быть сам себе провайдером. Просто ради интереса. Мне просто интересно как будет работать сеть без IPv6. Дома такое легко провернуть. Да, мне пришлось развернуть NAT64, который должен быть у любого современного провайдера, мне пришлось развернуть DNS64, но можно пользоваться и публичными от Google или Cloudflare.
Было бы проще, если бы провайдер давал мне NAT64 и DNS64 по умолчанию. Тогда бы я смог сделать всё то, то я задумал просто на своём основном маршрутизаторе.
И, мой вывод, вполне можно жить в условиях только IPv6 сети. Все вопросы решаются либо на уровне операционных систем (мобильные устройства, в основном), либо на уровне домашнего маршрутизатора. Да, я подключал второй маршрутизатор и раздавал интернет через него. По сути я был сам себе провайдером. И, при этом, любой клиент имел доступ ко всем сервисам в интернете даже при том, что второй маршрутизатор подключался к головному только при помощи IPv6. Спойлер, оба маршрутизатора использовали OpenWrt.
Cегодня мне пришлось настраивать дохлый D-link DIR-825 (хозяева квартиры оставили, почему бы и не применить), у которого проблемы с WiFi на 5 ГГц в качестве клиента моей WiFi сети. С настройкой IPv6 особо проблем не возникло. А вот с IPv4 возникли проблемы небольшие. Решил прибиванием IPv4 адресов жёстким.
Мне кажется, IPv6 просто не дали шанса. Пока IPv4 можно уплотнять костылями, бизнес выберет костыли. Ровно по той же причине, почему старые системы в компаниях живут вечно
Не везде можно долго использовать старье. Обычно это залог потери первенства в конкуретной борьбе со всеми вытекающими.
Что выберет бизнес - это и вопрос аргументации со стороны технической дирекции.
Мне кажется, IPv6 просто не дали шанса.
Не согласен. Из этой статьи и ряда других статей про IPv6 мы знаем, что он не просто для того, чтобы увеличить адресное пространство, но и вообще лучше во всем. И ему примерно тридцать лет уже, что по меркам IT ужас какое старое. Какие еще нужны шансы? Адресное пространство IPv4 очевидно исчерпано, белые адреса поделены и теперь доступны только за отдельную плату, потому что когда начинается дефицит, то цена растет. Поэтому еще раз, какие еще нужны шансы протоколу, который одновременно решает очевидную проблему дефицита адресов и, согласно прочитанных статей, просто лучше во всем?
Пока IPv4 можно уплотнять костылями, бизнес выберет костыли.
Тем более что это не приносит неудобств. А переход на v6 тянет за собой обновление оборудования и/или софта, переучивание или найм еще сетевиков, кто это сможет настроить и поддерживать - чтобы в результате получить что? Бизнес обычно прагматичен, если что-то не приносит прибыли ни сразу, ни в обозримой перспективе, то инвестировать туда может оказаться не инвестицией, а просто потреннями деньгами, которые иначе можно пустить в оборот или потратить на себя.
Ровно по той же причине, почему старые системы в компаниях живут вечно
Концепция не чинить то, что исправно, довольно хорошо вписывается в логику ведения бизнеса. Старая система, поэтому, будет работать до тех пор, пока она справляется с нагрузкой (в пределах возможностей апгрейда) и пока затраты на поддержание очевидно ниже затрат на замену - замена должна окупиться в разумные сроки, а не радовать нескольких гиков на зарплате или даже лично хозяев бизнеса своей модерновостью.
ИМХО. С ipv6 перегнули. Желание оставить запас сыграло против. Достаточно бы, условно, добавить к ipv4 один старший октет и хватило бы. NAT не плохо, и не костыль. Зачем каждому устройству выдавать не один адрес, а целый пул мне тоже не понятно. И с точки зрения администрирования сети.. это ужас какой-то. Банально проверить пинг: в случае ipv4 запомнить dns гугла элементарно, а теперь вопрос как запомнить dns Google в ipv6? Да, если работаешь с этим каждый день и если разобраться в принципе, то запомнишь. Но набирать в разы дольше чем ipv4. А теперь представляем когда нам надо попинговать паручку другую хостов по ipv6.. без таблицы и копипаста уже не уедешь. А если надо челоеку далëкому от ИТ продиктовать какой dns надо прописать? Представляем.. и ужасаемся. Кроме технической стороны (обновления железа), мне кажется ipv6 банально не удобен, просто во всëм. Так что я бы посомневался что он вообще взлетит, не получится ли что через десяток лет придëт осознание что нужно иное решение, а ipv6 был изначально хорошей инженерной идеей, но плохой в жизни?
А много ли IPv4 конечные потребители Интернет знают наизусть?
Даже продвинутые игроманы зачастую не могут ответить какой IP у его игрового сервера.
Остальные оперируют доменными именами, а с этой точки зрения версия IP не имеет никакого значения.
Кроме этого, для контент ресурсов в Интернете часто используются укороченные IPv6 адреса, хотя и они немного длиннее чем IPv4
Ну и даже технари со временем привыкают, тем более что не обязательно это держать в голове, можно и в файлах :)
Достаточно бы, условно, добавить к ipv4 один старший октет и хватило бы
Покажите свой профессионализм и объясните куда этот старший октет добавить в заголовок пакета IPv4 так, чтобы не сломать совместимость. Ведь те, кто разрабатывал IPv6 наверно не подумали об этом. Вы просто будете спасителем человечества, если сможете решить эту задачу так, чтобы не менять прошивку всех устройств и не переписывать софт под ваш модифицированный IP протокол.
А если серьёзно, то конечно об этом думали. И не нашли куда дополнительные биты всунуть. Везде ломалась совместимость. Поэтому и решено было полностью переделать протокол и избавить его от всех недостатков IPv4, которые были выявлены. Ну и размер адресов не с потолка взяли.
P.S. А уж как это актуально, когда почти всё современное оборудование работает с IPv6...
я не говорил что надо было так поменять что бы не сломать совместимость. я сказал что вдреса ipv6 слишком громоздки.
Ну т.е. вы не против того, чтобы сломать совместимость. А теперь представим себе, что мы совместимость сломали и добавили всего 8 бит. Через какое время нам снова нужно будет ломать совместимость, чтобы снова расширить адресацию? Не лучше бы сразу сделать так, чтобы не иметь никаких проблем с адресацией много лет? Именно это и сделали разработчики IPv6. Ну а громоздкость IPv6 - это вынужденно. Как компактно записать 128 бит? Кстати, был один первоапрельский RFC, где предлагали записывать адреса в BASE85, но почему-то на практике это никто не использует. Кстати, а чем вас не устраивает сокращение IPv6 адресов? Вполне реально добиться вот таких адресов 2001:db8:beef::1 для тех узлов, адреса которых нужно помнить. Не сильно то длиннее и сложнее IPv4 адресов получается. Дома вообще можно извратиться, наплевать а рекомендации, и использовать что-то вроде fd00::1, что куда проще, чем 192.168.1.1.
NAT не плохо, и не костыль.
Это точка зрения того, кто ничерта не понимает о маршрутизации.
NAT - это огромный костыль особенно в масштабах провайдера.
Я не говорю даже о сквозной доступности, которая сейчас обросла такой кучей костылей и прочего что просто "ужос". Вы попробуйте сделать обычную несимметричную маршрутизацию от конечного пользователя (с серым IPv4) в Интернет.
Допустим что провайдер желает зарезервировать свой внешний доступ, тупо поставив ещё один маршрутизатор на внешку. И т.к. это резервирование - настоятельная рекомендация поставить его на другой площадке (даже в другом городе).
Так вот чтобы у конечного потребителя всё работало хорошо, нужно чтобы его серый IP на "внешку" был транслирован везде в один и тот же белый IP. А это значит что почти в 100% реализаций подобного, трафик абонента должен полностью весь проходить через одну и ту же железку NAT. Эта железка конечно тоже может резервироваться, но только по принципу "трафик абонента идет весь через любую одну из железок NAT".
В итоге резервирование сетей с серыми адресами очень сильно усложняется - вместо двух пограничных маршрутизаторов будет еще полстойки этого всего связанного с NAT, и всё равно никакой гибкости не получится, а только куча костылей!!!
Тогда как с реальными (белыми) IPv4 и IPv6 - никаких проблем с любыми способами маршрутизации не возникает и делается это тупо только железками-маршрутизаторами и парой -тройкой каналов связи.
В этом плане был хороший подход на оборудовании Redback(Ericsson) SmartEdge - там NAT делался прямо на сессиях абонентов, и в итоге на выходе из коробки были только белые IP, которые можно было далее как угодно маршрутизировать по любым сетям стандартными способами. Но такое решение и ранее и сейчас было неприемлемым для всевозможных СОРМ и т.п. структур.
В общем как ни крути все подобные мысли "NAT - это здорово" озвучиваются обывателями которые думают что "NAT защищает", тогда как защита - это тема отдельная и делается она грамотной настройкой файерволов, на тех же кстати WiFi-роутерах это делается даже по дефолту и даже для IPv6 там есть подобное.
был транслирован везде в один и тот же белый IP
Реализация трюка с anycast и анонсом одного ip из разных мест в случае NAT будет сильно неприятной?
Да, я понимаю что скорее всего среди isp наверное никто с anycast не играется, но всё же
Как раз священность всего со всем и не нужна. И более того она зло.
Интернет уже давно разделился на клиентов и сервера. Возможность обратиться к клиенту вредна и должна отключаться на уровне стандарта. Нат эту проблему отлично решает.
Интернет уже давно разделился на клиентов и сервера. Возможность обратиться к клиенту вредна и должна отключаться на уровне стандарта
р2р такой: "ну да, ну да, пошел я нахер".
Сколько там его осталось? Если сравнивать со всеми телефонами и домашними подключениями?
Надо защищать телефоны людей и дома людей. Их слишком просто хотя бы задудосить. Надо чтобы по дефолту это никто не мог сделать. А это НАТ. Провайдерский.
Естественно все это должно отключаться по галочке занедорого. Для тех кому надо.
мобильные сети между прочим - это одни из первых кто IPV6 в железе начал использовать задолго от общей тенденции. Им просто было мало IPv4 для своих даже внутренних задач.
И наконец поймите что провайдерский NAT - это не защита, тем более от DDoS. Снимайте розовые очки, изучите матчасть.
Пример простейший:
Как только абонент "пробивает" себе наружу например UDP-трансляцию, она автоматически в обратную сторону становится доступна любому IPv4 из Интернета. И это норма, потому что именно так строится связь P2P и прочая даже клиент-серверная между всеми кто находится "за NAT".
Далее уже сам абонент может на своем оборудовании сетевую фильтрацию строить, ну так и на дуалстеке он её точно так же может строить. И в прошивках роутеров можно ограничивать входящие соединения в т.ч. и по IPv6. Уверенность что NAT сильно защищает - это "уютная байка", которая для ленивых удобна, ведь не надо вникать в тонкости сетевых фильтров...
Провайдер может защищать от DDoS любые свои адреса, тем более что снаружи они все смотрятся как белые. Для этого есть совершенно другие механизмы, которые кстати в т.ч. должны защищать эти самые железки NAT44, а не абонентов за ними. Ведь если DDoS будет приличный, он вполне способен избыточно нагрузить и те самые железки NAT44, и даже каналы связи.
В последнем случае вообще ничто не поможет, если только на внешних линках магистральные провайдеры не помогут DDoS порезать.
Это как раз защита. Причем идеальная. NAT открывается только для того IP на который сходили из-за него. Весь остальной интернет ничего не увидит.
Все "серверное" за нормальным провайдерским натом естественно не работает.
Пора уже понять как работает современная защита домашних сетей. Никто дома ничего не настраивает. Покупается или берется из шкафа случайный роутер и включается в розетку. Больше ничего не делается. Все сделает провайдерский НАТ.
Провайдер сам разберется как прикрыть свои железки от дудоса. Он большой и там работают квалифицированные технари.
Причем идеальная. NAT открывается только для того IP на который сходили из-за него
кстати, может быть подскажете. Вот есть два основных варианта реализации NAT, при которых "NAT открывается только для того IP на который сходили из-за него" - Cone restricted NAT и Symmetrical NAT. При этом у симметрического есть критический недостаток - если два юзера сидят за ним, то они никак не смогут общаться напрямую, даже если очень захотят. Вопрос - кто и зачем придумал Symmetrical NAT, если поставленную задачу отлично решает Cone restricted? Какие-то хейтеры р2р? Это же какой-то бред - принципиально убивать р2р. Зачем? Я просто не понимаю.
Регулярно сканировать 4 миллиарда умножить на 65 тысяч портов совсем несложно и недорого. Чтобы клиентское железо не атаковали.
Это ведь не ответ на мой вопрос. При Cone restricted NAT будет то же самое (защита от входящих запросов с IP, к которым не было предварительного исходящего запроса), разница только в том, что symmetrical NAT запрещает технику обхода NAT с помощью STUN, а обычный restricted NAT - нет.
При этом symmetrical NAT более требователен к ресурсам (так как там, где можно обойтись одним внешним портом, он открывает отдельный на каждый внешний адрес), то есть, менее выгоден провайдерам. Но почему-то целых 30% провайдеров его используют. Вот я и пытаюсь понять, кто "изобрел" такой вид NAT, единственная цель которого - полностью запретить P2P траффик. Это вопрос не исключительно к вам, может кто другой знает ответ.
Это же какой-то бред - принципиально убивать р2р. Зачем? Я просто не понимаю.
Владельцу вненего шлюза так проще жить: не надо отслеживать состояние узлов за NAT, чтобы балансироовать нагрузку от NAT, он может взять первый попашийся шлюз и порт, и использовать его. По примерно той же причине веб-программисты не любят привязку сеансов конкретных пользователей к конкретным хостам (sticky sessions): и возможности масштабирования снижаются, и не с каждыого хоста такому сеансу можно добавить перформасу: нужно отслеживать состояние сеанса, и не переключать его на тот же самый хост.
И потому, кстати, когда мне вещают про то, что маломощные хосты IPv6 вместо NAT можно будет централизованно закрыть брандмауэром, у меня всякий раз возникает вопрос - а кто это делать будет? Если провайдер будет предоставлять для этого свой Carrier-Grade Firewall, то у него возникнет точно такой же соблазн балансировать как-то попроще, как и в случаяъ с Carrier-Grade NAT (AKA CGNAT), который симметрический: потому что брандмауэр - это примерно такая же хрень с состоянием, как и шлюз NAT. Потому есть у меня подозрение что, все равно придется тогда отказаться от услуг провайдера по защите трафика входящих подключений и колхозить что-то самим пользователям, с ожидаемыми (в лучшем, и в типовом случаях) результататами - а потому мне и не верится в светлое IPv6-ное будущее.
можно будет централизованно закрыть брандмауэром, у меня всякий раз возникает вопрос - а кто это делать будет?
Дома стоит роутер? Он умеет в IPv6? Если да и его можно отнести к SOHO, то с высокой долей вероятности он уже по умолчанию блокирует forward во внутрь
Если же его можно отнести к enterprise-сегменту - там может быть по-разному, в том числе может возникнуть необходимость его настроить вручную
Если же его можно отнести к enterprise-сегменту
Вопрос первый:
А точно можно? Он в метрики, централизованные логи и алерты и прочий кровавый энтерпрайз умеет? И нет ли в нем точки единого отказа? И как он горизонатльно масштабируется? А без всего этого энтерпрайз - не интерпрайз.
может возникнуть необходимость его настроить вручную
А вопрос второй - кто будет настраивать и дырки в прошивке штопать? Я-то, не вопрос, и дома справлюясь. А как простые люди?
Ну, и чем воэ это
с высокой долей вероятности он уже по умолчанию блокирует forward во внутрь
А чем - лучше чем NAT? Чем хуже - понятно: не так дубово. В наше время галлопирующей инновации у проиводителей прошивки могут всякие фантазии возникнуть, например, на темы свежих стандартов - эти же деятели из IETF и прочих -они же никак вокруг своей любимой игрушки IPv6 успокоиться не могут, всё норовят что-нибудь улучшить, вместо того, чтобы просто оставить работать приемлемо.
Вопрос первый:А точно можно? Он в метрики, централизованные логи и алерты и прочий кровавый энтерпрайз умеет? И нет ли в нем точки единого отказа? И как он горизонатльно масштабируется? А без всего этого энтерпрайз - не интерпрайз.
Утрачен контекст, не имеет значения. А у SOHO-железок фаерволл сейчас активен по умолчанию наверное везде
А вопрос второй - кто будет настраивать
Тот кто поставил себе это вместо SOHO-железки, я подразумеваю, что он понимал что делает. Ну а если нет, то кто ему виноват?
и дырки в прошивке штопать?
Эмм, вендор? У таких железок обычно лучше с поддержкой чем у SOHO. С другой стороны в мире полно дырявых даже не EOL-железок, вне зависимости от их направленности на рынок.
А чем - лучше чем NAT? Чем хуже - понятно: не так дубово.
Не ломает связность сети, а это много. Ну и не нужен cgnat у isp
А у SOHO-железок фаерволл сейчас активен по умолчанию наверное везде
...
Не ломает связность сети, а это много.
Как же не ломает, если брандмауэр? Он же к абонентам входящий трафик блокировать будет? Или каждый оабонент должен сам там всё настроить? Зачем это им?
Короче, опять вы тут про сказочную действительность про светлое будущее с IPv6 рассказываете...
Может, лучше решить маленькую проблему, чем "до основанья, а затем"? Например, заставить CGNATчиков починить у себя STUN? Не, я понимаю, что большинство всё это P2P без надобности, но ведь есть меньшинство, и оно тоже деньги платит.
PS По-моему вы тут и я с вами отвлеклись от действительно интересного вопроса автора: почему CGNAT - он такой, что делает хуже там, где мог бы этого не делать? Я свое предположение высказал, а вы?
А за IPv6 мне спорить даже не хочется: там и так очевидно, почему он не взлетает и вряд ли взлетит по доброй воле - разве что его в воздух подымут административными методами: пинками или примерно как русский из анекдота кошку горчицу лизать заставил.
Это как раз защита. Причем идеальная. NAT открывается только для того IP на который сходили из-за него. Весь остальной интернет ничего не увидит.
NAT провайдера в более чем половине случаев работает в другом режиме - это реалии, причины не вижу смысла здесь обсуждать.
А вот файервол как раз это делать умеет на 100% на WiFi-роутере для любого из протоколов, для IPv6 отключается одной галочкой т.е. по дефолту такой файерволн тоже включен.
Более гибкие настройки (если такое кому нужно) можно делать на соответствующем роутере, или например через консоль в SOHO-роутере (обычно там почти полноценный Linux/BSD, или что то своё с консолью) , но это тоже другая тема.
Кто боится DDoS, то защита от него - это тоже тема отдельная, и у провайдеров есть услуги и по защите от DDoS.
В любом случае NAT - это механизм используемый для решения вопросов нехватки IPv4 адресов. Некая защита на нем от доступа извне имеется, но это лишь побочный эффект. Кстати, провайдерский NAT никак не защищает от доступа внутри своей сети т.к. такая связь работает по тем же серым IP напрямую, такое только домашний роутер может ограничить. В пролвайдерской сети могут быть сотни тысяч и даже миллионы серых IP. И как вы в такой сети будете защищаться без NAT-а провайдера???.
Я в современном мире вижу всё чаще как вместо хорошо настроенного фаервола делают настолько монстрообразные "комплексные решения", что NAT на этом фоне смотрится некой "детской поделкой". Трафик от стороны запросившей до стороны получателя и обратно выстраивается в такое привязанное к централизованным система решение что неудивительно насколько легко можно подсматривать, цензурировать и использовать по полной программе частные данные "человеков".
Ну и напоследок.
Каким образом на каких протоколах и т.п. будет работать LAN -сегмент абонента, определяется не мантрой "NAT защищает", а реалиями развития Интернета и заложенных в домашние устройства технологий (роутеров в т.ч.)
Ну я допускаю что где-то в деревнях еще остались дикие провайдеры с плохим железом, но это им надо обновиться а пользователям бежать от них надо.
Никакой внутрисети не существует уже много лет. Опять в деревнях может и есть, но у всех нормальных провайдеров полная изоляция клиентов друг от друга. Решение такое же. Провайдерам сделать нормально, пользователям бежать от них к нормальным.
НАТ все еще защищает от всего. Вообще от всего. Настраивать и платить не надо. Оно просто работает. Не ломайте то что работает.
Веры в пользовательское железо давно нет. И не надо. Пусть и дальше работает что-то. Никаких проблем с этим нет, все уже придумано и в продакшене.
Как только абонент "пробивает" себе наружу например UDP-трансляцию, она автоматически в обратную сторону становится доступна любому IPv4 из Интернета.
Это не верно, точнее - не всегда верно. Есть (и AFAIK он намассовый) такокой режим работы NAT - restricted cone NAT- в котором, несмотря на то, что один и тот же внешний порт всегда может транслироваться только в одинаковый внутренний, для "пробития" надо чтобы первый пакет ушел со стороны узла за NAT на тот IP, для которого нужно разрешить входящий трафик, иначе трафик блокируется.
Для отключения связности к вам будет достаточно всего навсего обычного вашего WiFi-роутера причем с любым вариантом IP-протокола. Файервол это превосходно порешает - разрешит создавать соединения только "от вас, но не к вам", а далее все работает по установленному соединению. Только лишь NAT для защиты недостаточно.
Стандарт закрывающий прямую связность? Вы часом не в органах работаете? Или может Чебурнет разрабатываете уже с новыми стандартами???
Весь Интернет изначально построен на принципах прямой связности или сквозной доступности, а воплощение этого вот новомодного принципа "Интернет уже давно разделился на клиентов и сервера" как раз рушит связь и делает клиентов подконтрольными и зависимыми. Весь Интернет сейчас работает через пень-колоду в первую очередь именно от тех кто пытается контроллировать "кто куда может подключаться, а куда не может".
К тому же найти клиента по его IPv6, если он сам себя не обозначил - тот ещё квест, сканированием IP умаетесь это решить. Более того, периодическая смена IPv6 на клиенте - это обычное дело, ведь даже в минимального размера IPv6 сети адресов гораздо больше чем сейчас во всем IPv4 диапазоне.
Мир изменился. Нынче есть миллиарды людей которым просто надо чтобы их любимый сайтик работал а лампочка включалась с приложеньки. При этом им нужна бесплатная встроенная в стандарты защита от дудоса стоящего 10 баксов в сутки.
Интернет строили в другие времена для другого использования. Нынче надо делать под современную реальность.
Ненаходимость это плохая защита. Люди они имеют привычку разбрасывать свои данные везде. Надо нам подумать за них и сделать хорошо для них.
Защита за деньги и ресурсы провайдера это идеально. У провайдера есть специалисты, широкие каналы и деньги. Пусть любой обиженный сосед который смог вычислить человека по ip дудосит провайдера. Провайдер этого и не заметит. Стандарт который позволяет дудосить этого человека тратя всего десятки баксов в день не нужен.
Защита за деньги и ресурсы провайдера это идеально.
Защита за отдельные деньги - наверное, что то в принципе провайдеры и предлагают, типа защиты от DDoS и прочее.
Но (если вы вдруг не в курсе) провайдер на уровне закона как раз ОБЯЗАН не ограничивать никак трафик абонентов для доступа к ресурсам Интернет. Иначе можно лицензии лишиться.
Всякие ограничения доступа к любым ресурсам - это не провайдер, это РКН, ФСБ и прочие полномочные органы, более того - почти всегда это вообще другое оборудование вне ЗО провайдера.
Интернет уже давно разделился на клиентов и сервера.
Причем делится но названиям неправильно. Когда какая-софтина управляет умной лампочкой, чтобы она включилась - это именно лампочка, так-то, сервер, а не то что у производителя в облаке стоит.
И когда (из за NAT-а), лампочка должна это соединение устанавливать, чтобы спросить 'что сделать надо' - это костыль.
Возможно, даже более вредный, чем кажется.
Потому что если соединение на лампочку - то можно firewall настроить в духе
"На лампочку инициировать соединение можно, а с лампочки - никуда нельзя"
После любой потенциальный узел ботнета, который на этой лампочке обосновался, обламывается.
А сейчас этим зараженным лампочкам, камерам, утюгам и холодильникам ничего не мешает интернет пространство мусором забивать, потому что их 'излучение' успешно NAT-ится.
Нет. Сейчас правильно. За сервером стоит команда, которая его и обновит и прикроет, а на лампочку всем пофиг. Она может уже не поддерживаться уже 3 года и иметь любые дыры.
Никто ничего не будет настраивать. Лампочка должна включаться и выключаться. Остальное не нужно.
NAT им помогает быть защищенными. От всего. Вообще от всего. И не важно какой софт с какими паролями или дырами на них стоит. И это не зависит от того что перед ними, смотришь на лампочку с ip 192.168.10.42 и понимаешь что все с ней хорошо.
Я очень хочу чтобы весь iot просто не включался в сеть с несерыми ip. Пока человек не поставит специальную галочку в настройках. Это серьезно повысит безопасность. Неiot тоже вообще. Открытых на весь мир Монг слишком много.
Простая дефолтная защита которую можно проверить локально это вообще очень круто. Любая приложенька смотрит свой ip и понимает все хорошо или все плохо одним ифчиком. Это прямо гениальное инженерное решение. Не надо это терять.
Сети надо делать для людей, а не как вам кажется правильным.
PS: Домашних роутеров это все тоже касается. 15 летний Dlink с настройками по умолчанию это нормально. Он решает задачу человека. Пусть работает. От любой атаки из интернета его прикроет провайдер.
За сервером стоит команда, которая его и обновит и прикроет, а на лампочку всем пофиг. Она может уже не поддерживаться уже 3 года и иметь любые дыры.
И на лампочке поставился узел ботнета, который через NAT долбит окружающих, участвуя в DDoS. Так что хозяину, может быть, и пофиг. А вот всему остальному интернету лучше бы, чтобы с лампочки наружу ничего не ходило.
Я очень хочу чтобы весь iot просто не включался в сеть с несерыми ip.
Ну так (смотри мои сообщения в окрестности этого) IPv6 мир для этого тоже лучше предназначен. Весь IoT сажается на Link Local и от остального интернета изолирован. Новые железки постепенно туда и двигаются - смотри протокол Matter.
Человеку хочется включать лампочку с телефона, а это сервер. Значит лампочке надо ходить в интернет.
То есть весь обычный умный дом перестает работать, классная идея.
а это сервер.
На умной колонке/телевизоре, что в той же сетке живет. У продвинутых - специально купленный хаб.
Собственно, именно поэтому производителям и есть некий смысл хождение в интернет с лампочек выпиливать. Во первых, им рано или поздно им башке настучат за ботнеты 'на лампочках'. Во вторых - этот самый хаб дополнительно продать можно.
Ну и, собственно, с телефона, пока он в локалке - работать будет и без этого.
Не будет работать автоматизация, когда телефона дома нет. А это снова смотри возможность продать еще одну железку.
Берем обычного человека. Он видит умную лампочку в магазине и покупает ее. Ставит на телефон приложеньку, фоткает qr, вкручивает лампочку и она работает.
Вы предлагаете все это сломать и сделать взамен что-то на порядок сложнее и дороже для пользователя. Просто потому что вам так хочется.
Может не надо? Сеть все еще надо строить для людей, чтобы им удобно было ей пользоваться.
Берем обычного человека. Он видит умную лампочку в магазине и покупает ее. Ставит на телефон приложеньку, фоткает qr, вкручивает лампочку и она работает.
И она работает, пока он дома, управляемая прямо этой приложенкой.
А если хочет автоматизации, пока дома нет - ну пускай раскошеливается на еще одну железку. Или старый смарт с той же приложенкой, что дома остается, использует. Или в свой телевизор ее ставит.
Так что никакого особого усложнения нет.
Отличный план. Выставить людям ограничения, заставить платить и сломать то что уже работает чтобы не отказались. И чего это оно так плохо внедряется?
Сейчас, если пропадает интернет, лампочка перестает включаться или отключаться. Это очень удобно и позволяет использовать такие лампочки в относительно критичных сценариях. Ну, то есть нет. Но интернет редко пропадает надолго даже в типичных бытовых, без резервирования, условиях. А вот "облако" производителя лампочек может прекратить свое существование враз и навсегда - примеры известны. Покуда вы про обычный стиральный порошок обычных людей, то вариант аккуратно расковырять, найти UART, подпаяться туда и перепрошить на опенсорсную прошивку с поддержкой [пропускаю некоторые действия] управления домашним сервером (локально, без зависимости от интернета) и телеграм-ботом (то же самое "облако") выглядит сомнительным с точки зрения массовости таких решений.
И это приемлемый риск. Это в конце концов лампочка. Они обычно умеют работать с выключателя.
И прекращение работы это приемлемый риск. Это все еще лампочка. Она дешевая с понятным и не очень большим сроком службы.
Не надо ничего делать. Надо купить и пользоваться если хочется.
Старайтесь в любых своих представлениях о будущем не ломать то что работает. Причем работает массово и неплохо.
Я не согласен насчет приемлемого риска в том смысле, что типичный покупатель вообще едва ли понимает риски. Но это не для спора с вами, просто мысли вслух где-то рядом с обсуждаемой темой.
Старайтесь в любых своих представлениях о будущем не ломать то что работает. Причем работает массово и неплохо.
Тут я с вами согласен примерно полностью. Причем что идеологически (мем про новый единый стандарт вместо 14 разных), что экономически (копроэкономика одноразовых вещей не то, что я поддерживаю).
Типичный покупатель просто покупает и пользуется. Сломается ну и фиг с ней. Сломается по любой причине. Шанс что сломается из-за отключения сервера минимален на самом деле. А то что без интернета ничего не работает все уже в курсе.
Вот и хорошо, значит все должно продолжать работать пока не сломается физически по естественным причинам. Значит нужна обратная совместимость со всем.
И чего это оно так плохо внедряется?
Именно в локалке, даже без внешней связности - отлично внедряется, если специально не отключать.
Берем два компа с виндой, втыкаем в коммутатор и пингуем по имени. -- с очень большой вероятностью все по Link Local пойдет.
Или со смарта на комп (или наоборот) -- аналогично.
Открыл свой роутер. Хороший масовый Кинетик. Довольно новый. Он разумно из коробки выдает всем устройствам ipv4 адреса со своего dhcp сервера. Все просто работает, без страшных нечитаемых адресов и непонятных слов. Зачем что-то ломать?
Зачем что-то ломать?
Потому что DDoS - проблема. И идут они с ботнетов:
Nearly 70% of HTTP DDoS attacks originated from botnets already known to Cloudflare.
И всякие IoT, которым доступ наружу разрешили - в эти ботнеты и входят.
А решения вы так и не предложили. Сломать людям удобные фичи это не решение.
Я предлагаю хотя бы какие-то улушения. Вроде заставить производителей не подниматься не несером ip с настройками по умолчанию.
А решения вы так и не предложили.
Предложил.
IoT вешается на IPv6 Link Local. После этого оно из локальной сети - управляется, для большого Интернета - безопасны.
Сомнительное неудобство (что нельзя работать без управляющего центра внутри локальной сети) - решается установкой этого центра. У большинства уже есть, куда этот центр поставит, да и отдельной железкой он не так чтобы дорогой.
Оно при этом перестает работать. Классно, ага. Пользователю не нужен центр, он лампочку хочет и чайник. И уже купил их в соседнем магазине. И они должны работать.
Оно при этом перестает работать.
Вы же сами выше писал:
Сломается ну и фиг с ней. Сломается по любой причине.
Ну вот тут 'любая причина' - та, что IPv6 ввели. Идет и покупает ту, которая работает в новых условиях.
Кроме того, что именно ломается-то? Приложение стоит? Стоит. Кнопочкой в нем лампочка/чайник включаются, не вставая с постели? Включаются. Все хорошо и что-то заметят только те странные, что хотят лампочку дома с работы дергать.
Не, это вы хотите сознательно сломать. Оно работает, производитель поддерживает. Но по мнению кого-то там надо все сломать. Чтобы люди купили еще раз.
А оно так не будет работать. Я смотрю на то что у меня есть, все работает исключительно через сервер производителя. И новое продается такое же. Производители тоже не понимают вашу идею. У них все уже хорошо и удобно для пользователя.
Производители тоже не понимают вашу идею.
Смотря какие. Скажем Яндекс. "Подключается к умному дому с помощью Станции или Хаба по новому универсальному протоколу Matter"
Tuya (вот уж на сколько все хочет к своим серверам все привязать): тоже вписалась.
Производитель ваших лампочек - наверняка тоже модели с ним умеет.
А Matter - локальное управление в себя включает.
IoT вешается на IPv6 Link Local
Ещё раз на всякий случай напомню: IPv6 в обязательные требования тут не входит: в IPv4 есть APIPA ровно для этого.
мой устройства дома на NAT роутера. зачем мне иначе? (бывают исключения, но это именно исключения для которых есть решений). поэтому NAT не костыль. при этом я не буду спорить что в каких-то сценариях, NAT - помеха.
Ютуб поддерживает этот протокол. Мой провайдер тоже. У меня спокойно Ютуб работает без всяких VPN
Это не достоинство/преимущество ipv6, это косяки с настройкой DPI
Любопытный факт. Благодаря тому, что вся семья смотрит ютуб, мой маршрутизатор показывает до 80%, а то и больше, трафика IPv6. Статистика ломается только когда качаю торренты. Там большинство пиров и сидов по IPv4 работает и прямо сразу жёстко ломает статистику.
Ещё делал статистику по своему ПК. Но недавно поставил модифицированный NetworkManager и теперь у меня компьютер работают только на IPv6. Просто было интересно что сломается. Пока ничего не нашёл. Всё работает.
Кратко статья выглядит как рассказ о том как скупой платит дважды. Что корпорации и провайдеры готовы сколь угодно придумывать заплаток что бы лишний раз сэкономить. А то что все бремя такой (экономии) потом валом свалится на внуков и правнуков. Делая переход ещё сложнее и дороже, ибо сеть пользователей интернета к тому времени будет раз в 50 больше чем в старые времена, и все это заменять. Это уже проблема внуков и правнуков. Главное что здесь и сейчас сэкономили себе на жизнь.
Если бы IPv6 сделали обратно совместимым с IPv4, то всё было бы прекрасно.
Подозреваю, что это охренеть как сложно или подразумевает ну очень много компромиссов и уступок, но факт есть факт.
В той же корпоративной среде было и есть дохренище специфичного софта, который дружит только и исключительно с IPv4, и никому не хочется изобретать костыли.
Ну, и я уж умолчу про банальную человекочитаемость и запоминаемость IPv6. А ведь это важный человеческий фактор
Что мешает сделать для такого софта некий мэппинг IPv4<->IPv6 на уровне системы? Софт будет думать, что работает с IPv4, ну и пусть думает...
Если бы IPv6 сделали обратно совместимым с IPv4, то всё было бы прекрасно.
Опишите как вы себе это представляете. Инженерам, которые разрабатывали IPv6, это не удалось, поэтому они решили, что раз уж ломают совместимость, поэтому сразу будут менять то, что плохо работало. Поэтому IPv6 так заметно отличается от IPv4, потому что в него не стали тащить старые косяки.
В той же корпоративной среде было и есть дохренище специфичного софта, который дружит только и исключительно с IPv4, и никому не хочется изобретать костыли.
Большинство софта легко обмануть с помощью DNS64 и заставить обращаться к сервисам по IPv6 вместо IPv4. Ну а самый кривой софт, который идёт в обход системы или не кривой, но который оперирует непосредственно IPv4 адресами (торрент клиенты, например) тоже можно обмануть и заворачивать весь IPv4 трафик в IPv6. Но в этом случае требуется вмешательство непосредственно на устройствах. Нужный костыль есть во всех современных мобильных ОС и MacOS. Под Windows косталь пока работает ограниченно, но в Windows 11 сейчас тестируют полноценный костыль. Под Linux есть решения, но их нужно доустанавливать вручную. В NetworkManager тоже пилят свою реализацию, но она пока в стадии тестирования (можете принять участие в тестировании). Т.е. вполне реально сейчас не иметь IPv4 адреса на компьютере и не испытывать никаких затруднений.
Ну, и я уж умолчу про банальную человекочитаемость и запоминаемость IPv6. А ведь это важный человеческий фактор
А вот так с ходу приведите пример хотя бы одного IPv4 адреса, который вы помните наизусть. Часто слышу этот аргумент, но вот мало людей видел, которые помнят IPv4 адреса. А для тех же публичных сервисов можно вполне сделать удобный и короткий IPv6 адрес. Он будет чуть длиннее IPv4, но не критично.
А вот так с ходу приведите пример хотя бы одного IPv4 адреса, который вы помните наизусть
Оптимистично спросили) многие с легкостью назовут какие-нибудь: 1.1.1.1, 8.8.8.8, 9.9.9.9, 127.0.0.1, 192.168.1.1…
Я тоже с лёгкостью назову ULA префикс своей домашней сети, а также DNS Cloudflare: 2606:4700:4700::1111, 2606:4700:4700::1001, а также DNS64 от них же: 2606:4700:4700::64, 2606:4700:4700::6400. А уж ::1 грех не помнить :-D
Основной вопрос, зачем помнить большую часть адресов. Я занимаюсь сетями, поэтому мне удобно помнить некоторые адреса. Но если я просто пользуюсь интернетом, то мне они в большинстве своём не нужны.
192.168.1.1
А мне не надо помнить ULA в своей IPv6 сети. У меня все узлы самоконфигурируются. Если маршрутизатор им доступен, они получают адрес. Я не помню ни одного случая, когда мне нужно было вводить адрес на интерфейсе каких-либо оконечных устройств в моей сети. А вот с IPv4 приходилось это иногда делать, когда было непонятно, это устройство сломалось или это просто в сети нет DHCPv4 сервера, поэтому устройство не получило адрес. В IPv6 уже не нужно этим заморачиваться. Если есть маршрутизатор, то сеть сразу работает.
del
Инженерам, которые разрабатывали IPv6, это не удалось, поэтому они решили, что раз уж ломают совместимость, поэтому сразу будут менять то, что плохо работало.
Обсуждение IPv6 всегда в эту демагогию уходит. IPv6 должен был к нулевым успешно конкурировать с провайдерским NAT. Он не смог. Значит, он неудачен, инженеры ошиблись, остальное не принципиально. Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы.
Период между принятием и предполагаемым завершением внедрения (50 лет, 1995-2045) у IPv6 как у ITER, но там чистая наука и даже внезапное закрытие проекта почти никого не затронет.
Да, совместимость не сохранить целиком, но каждое лишнее расхождение имеет цену в годах. Одно решение - плюс пять лет, другое решение - ещё плюс пять лет, так отведённые на внедрение ~15 лет и кончатся (начало 90-х - конец нулевых).
Есть такая штука из 2002: IPv4+4:
two type A records can be used to store the level 1 and level 2 parts of the 4+4 address.
For example, the level 1 and 2 parts of the IPv4+4 address of the machine foo.bar.edu are stored under _l1.foo.bar.edu and _l2.foo.bar.edu.
Auxiliary protocols, such as DHCP, ARP, RARP, router discovery, etc., need not be modified.
IPv4+4 packets are minimally encapsulated IP packets
The first three rows of fields in the IPv4+4 header are interpreted in the same manner as the IPv4 header, with the exception that the Protocol 1 field is set to a value that specifies IPv4+4 encapsulation.
Upgraded NATs, called realm gateways, are integral part of the 4+4 architecture.
If routers are also upgraded in an area, the special role of the realm gateways diminishes and they simply reduce to ordinary routers.
There is no need for temporary transition mechanisms (such as tunneling, tunnel brokers, 6to4, 6over4 or DSTM
Поздно? Но она не на пустом месте появилась, она опиралась на предыдущие наработки.
Предыдущие наработки отвергли? Ну, это была работа IETF - выбрать верное направление.
Была слишком неясная ситуация? Объявить вотум недоверия всем предложениям - это тоже решение, можно потерять 5 лет, а потом сэкономить 30. Учесть неясность и уменьшить горизонт планирования - тоже решение (не пытаться предсказать будущие потребности сверх расширения адресов).
Обсуждение IPv6 всегда в эту демагогию уходит.
Просто в реальном мире не всегда принимают осмысленное решение. Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования. Его просто взяли и начали использовать. Сам руководитель разработки Винт Серф признавался, что он делал протокол чисто для проверки концепций. IPv6 же изначально создавался для коммерческого использования. И как раз в нём были исправлены косяки IPv4. Банально, руководителю проекта в голову не могли прийти, что, по сути, лабораторным протоколом будет пользоваться весь мир, поэтому выбрал изначально эти 4 байта под адрес. Их хватило бы на все мыслимые и немыслимые эксперименты в то время.
Ну, а IPv6 сейчас вполне себе жив. Те же Индия и Китай активно им пользуются. Европа тоже переходит. Только в РФ с их сувенирным интернетом провайдерам не до этого.
Есть такая штука из 2002: IPv4+4:
Что-то мне подсказывает, что эту штуку нужно было внедрять также на всём парке оконечных устройств. Ну или на большинстве из них. По сути это ничуть не лучше перехода на IPv6, только ещё кучу софта переписывать для поддержки.
Тот же переход многих приложений на IPv6 - это просто замена A записи для нужного домена на AAAA. Именно благодаря этому большую часть софта можно обмануть и заставить работать по IPv6 просто с помощью DNS64. Т.е. модификации софта вообще не требуется.
А вот те вещи, что оперируют IPv4 адресами всё-таки нужно переписывать или приделывать на хосте костыль (clat), чтобы они продолжили работать. Тут уж ничего не поделаешь. Благо их очень мало. Это всякие звонилки, торрент клиенты... т.е. в основном p2p вещи.
Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования.
Сам руководитель разработки Винт Серф признавался, что он делал протокол чисто для проверки концепций.
Банально, руководителю проекта в голову не могли прийти
Их хватило бы на все мыслимые и немыслимые эксперименты в то время.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 1-2 года:
зафиксировали длину IPv4-адреса ради скорости
за кучу денег пересадили на протокол всю военку, это будет MIL-STD-1777
в журнале
"Вестник компьютеризации"Computerworld пишут о годноте для бизнеса, за ваши налоги, без вендор-лока IBM, скоро в широком доступе
Собственно, история
Середина 1978: в IPv4 ещё адрес переменной длины, на месте контрольной суммы стоят длины адресов.
Конец 1979: "Vint ... cited the performance of the system as a key issue" - пора фиксировать длину адреса.
"Rosenthal recalls: ... Vint Cerf and company went off to invent TCP at the time because they got lots of DOD money to make networks work"
"Throughout 1979, Kahn and Cerf lobbied the DOD to make TCP/IP an official communication protocol standard"
"in December 1980, the DOD publicly unveiled TCP/IP"
Computerworld 1981: "May 15 ... plans to market TCP/IP as part of its VAX/VMS network software package for DEC" и пересказ остального: "на ваши налоги сделали протокол (военный стандарт) - как у IBM, только лучше и без вендор-лока, его уже тестируют на процессорах IBM, DEC, Honeywell, CDC, HP и PerkinElmer. В следующем году он будет широко доступен коммерческим пользователям".
а в протокол была заложена расширяемость (ну вдруг кто-то зачешется), спецификация требует: "each internet module must be able to parse every option [options = блок переменной длины в конце заголовка]"
IPv6 же изначально создавался для коммерческого использования.
Ещё одна былина.
"Самолёт может взлететь с авиносца А и сесть на авианосец Бэ" - Технические критерии по выбору IP нового поколения, 1994.
Он создавался как IPv4 - для всех, и для особого клиента в том числе - для родной военки.
И как раз в нём были исправлены косяки IPv4.
Присмотритесь:
Перед новогодними праздниками (декабрь 1994, RFC1726): нужен протокол с безупречным планом миграции.
После новогодних праздников (январь 1995, RFC1752): подписываем протокол без плана миграции, единственный из трёх.
Что последовало за этим дальновидным решением?
Wikipedia / List of IPv6 transition mechanisms
Stateless IP/ICMP Translation
Tunnel broker
6rd
Transport Relay Translation
NAT64
DNS64
ISATAP
464XLAT /2013? всего на 18 лет опоздал, ну ничего/
Dual-Stack Lite (DS-Lite)
V4-via-v6 routing
MAP
4rd
NAT-PT
NAPT-PT
Это у нас архитектура, понимать надо.
Может, фильм снимем, где IETF в ушанках с балалайками и водкой заседает?
Ну, а IPv6 сейчас вполне себе жив.
Я повторюсь, он должен быть не жив, а внедрён 15 лет назад. Так в RFC написано, в предновогоднем. Там в 2010 году видят возможность для внедрения следующего протокола. Не консервативную, но и не раннюю, а в самый раз. Как раз к 1995 прошло ~15 лет после утверждения IPv4, а это ещё 15 лет.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 1-2 года:
Не вижу никаких противоречий с высказыванием Серфа. Он как раз и говорил о том, что разрабатывает протокол и ему нужны результаты какие-то. Он волевым решением выбрал длину адреса. Да и тогда никто не мог подумать, что понадобится больше. Даже если он бы решился выбрать больше, на него бы посмотрели как на дурака: «больше 4 миллиардов дорогущих устройств?».
а в протокол была заложена расширяемость (ну вдруг кто-то зачешется), спецификация требует: "each internet module must be able to parse every option [options = блок переменной длины в конце заголовка]"
Вот именно. В заголовок пакета напихали всего того, что по их мнению могло бы понадобиться. Никто тогда не мог составить точный прогноз. Как результат, при разработке IPv6 выкинули всё ненужное. При этом увеличили длину адреса в 4 раза (и источника и получателя), но сам заголовок пакета стал фиксированного размера и увеличился только в 2 раза, по сравнению с самым маленьким пакетом IPv4, который мог бы быть и больше. Переменная длина заголовка пакета кстати тоже создаёт некоторый геморрой при обработке. В IPv6 это учли.
Присмотритесь:
Про TUBA слышал. Как я понял его не взяли по причине того, что были проблемы с эффективной обработкой пакетов на узлах.
Могу гадать почему выбрали именно такой вариант, но как мне кажется для каждого из протоколов в любом случае бы пришлось перелопачивать весь софт работы с сетью. При этом IPv6 прекрасно подходит в качестве замены IPv4. После того как IPv6 появился в ОС большинство приложений вообще не знаю на каком из версий протокола они работают. Т.е. их вообще не нужно переписыать. Основаная проблема перехода в том, что невозможно обеспечить доступ к ресурсам IPv6 из сети IPv4 без костылей. При этом обеспечить обатный доступ можно привычным для IPv4 механизмом - NAT64.
Всё это разнообразие механизмов нужно разбить на 2 части:
Обеспечение адресами IPv6 тех, кому не предоставляется нативный IPv6 адрес - туннели;
Средства для взаимодействия между IPv4 и IPv6. По сути это просто разновидности NAT.
Для других протоколов получилось примерно бы тоже самое.
Как вывод. В современном мире вполне можно полностью перевести всю сеть исключительно на использование IPv6. Конечно, для IPv4 сети нужно будет сделать свой шлюз, примерно такой же, какой сейчас используется в IPv4 между серой и белой адресацией, т.к. мы просто меняем тип NAT. Если нас не интересует сеть IPv4, то этот шлюз не нужен. Увы, но пока избавиться от NAT64 - это мечты. Но при этом тот же Linux без проблем ставится и обновляется в сетях только с IPv6. А вот если вы используете репозитории на github или ваш проект подтягивает зависимости... придётся этот шлюз ставить и использовать. Самый упоротый софт можно заставить работать с помощью костыля непосредственно на устройстве. Мобильные ОС это умеют из коробки. Для настольных ОС пока ситуация сложная, но она решается. Microsoft объявила о том, что будет расширять поддержку clat для Windows 11 и уже даже вроде можно что-то рабочее от них получить. В Linux поддержка добавляется через установку пакетов на некоторых дистрибутивах. Но тоже поддержку пилят в том же NetworkManager, который практически является стандартом для дестопных версий Linux. Я уже сейчас использую NetworkManager из тестовой ветки, который позволяет мне в сети с NAT64 полностью отключить IPv4 на моём компьютере. Когда этот патч войдёт в релиз, то у меня компьютер сам будет знать, что сеть не требует получения IPv4 и можно работать без него пользуясь услугами NAT64 для доступа к ресурсам IPv4.
Не вижу никаких противоречий с высказыванием Серфа
Интервью с Серфом: адрес зафиксировали в 1973, 128 стран, 24 бита на сеть, 16 миллионов компьютеров на сеть - для эксперимента точно достаточно.
Документы: фиксация адреса откладывается до 1979±1 - уже не эксперимент, а крупный оборонный проект и мотив решения - скорость (не MVP для доработки). 1979 - это уже 100К продаж TRS-80 и статья о том, как военные уплотняют мультимедиа для сетей (7 аудиокодеков).
Где-то здесь ошибка.
Даже если он бы решился выбрать больше, на него бы посмотрели как на дурака: «больше 4 миллиардов дорогущих устройств?».
100К продаж с "starting price of US$600" - перспективы можно углядеть (IBM сразу углядела, до IBM PC два года).
А если на два года в прошлое (1977), то там Xerox в своём протоколе расширяет адрес до 32+48 бит (MAC-адрес). Xerox тоже что-то знал.
Никто тогда не мог составить точный прогноз. Как результат, при разработке IPv6 выкинули всё ненужное.
Это инфраструктура (вроде водопровода), тут всё-таки не важно, насколько приятно выкидывать легаси и переписывать с нуля.
Переменная длина заголовка пакета кстати тоже создаёт некоторый геморрой при обработке. В IPv6 это учли.
В IPv4+4 - тоже. Если бы продавливали решение через Options, то пакет с extra-addr-option тоже был бы фиксированной длины. Если бы совсем отбросили амбиции и попытались набирать ~14 бит через запрет фрагментации, то одинаковой длины с IPv4.
Обеспечение адресами IPv6 тех, кому не предоставляется нативный IPv6 адрес
Так речь о том, чтобы автоматически наделить владельца белого IPv4 адресами нового протокола (~2^(14..32) штук).
Средства для взаимодействия между IPv4 и IPv6. По сути это просто разновидности NAT.
В перечисленных мной вариантах это должен быть обычный NAT. И как можно было принять 464XLAT через ~15 лет после IPv6? ("Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы")
Для других протоколов получилось примерно бы тоже самое.
То есть совсем другое.
заставить работать с помощью костыля
IPv6 - сам по себе костыль, только в особом смысле - костыль из башни слоновой кости с синдромом второй системы. Он должен был дать адреса и смотреться выгоднее CGNAT'а в нулевых. Сверх этого можно давать фичи, но давать их вместо - нельзя.
Ещё из RFC1726: "4.1 Архитектурная простота. Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать". Отлично подходит к IPv6.
Они промахивались насчёт IPsec, насчёт лёгкости миграции с IPv4, насчёт связности, возведённой в абсолют, потому что из начала 90-х было трудно предсказать ситуацию через 10-20 лет - и не надо было этого делать. Надо было в соответствии с цитатой отсекать всё, что помешает полному переходу через 15 лет.
В перечисленных мной вариантах это должен быть обычный NAT. И как можно было принять 464XLAT через ~15 лет после IPv6? ("Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы")
15 лет заняло понимание что совместимость нужна и без нее ничего не будет.
С новыми стандартами совместимости может и поедет. Оно уже как-то нормально выглядеть начинает. И приватная адресация появилась и связность 4-6 в обе стороны понятно как делать. Но костыли, которых можно было бы избежать подумав сразу при написании стандарта.
Там до сих пор появляются костыли для перевода сети на IPv6. Например, появился RFC как маршрутизатор может анонсировать NAT64 в своём сегменте сети (PREF64). У меня сейчас Android из 2017 года и он в него не умеет, потому что стандарт появился позже. А вот более новые телефоны 2020 года и позже уже прекрасно могут отключить IPv4 и пользоваться PREF64 для доступа к ресурсам на IPv4. Осталось додавить создателей настольных ОС, чтобы они сделали clat доступным по умолчанию. Тогда клиентам будет вообще по барабану дуалстек у них или только IPv6.
Скоро наступит 2026. Все еще нет поддержки того что нужно в массовых ОС и железках. Ну еще лет 15 наверно, если в следующем году поддержат. Чтобы железо и софт без поддержки ушли в историю массово.
И всего-то надо было стандарт правильно написать в 90тых. Подумав про миграцию и совместимость. А не дописывать ключевые штуки спустя десятилетия.
В появление в 2050 году первых ipv6 only сервисов можно верить. Раньше я на 2100 ставил бы.
Не вижу смысла спорить. Моя позиция такая:
Протокол IPv6 принят для замены IPv4 и присутствует на подавляющем большинстве устройств в их ОС. Любой предлагаемый протокол так же бы требовал вмешательства в ПО и глупо было тянуть за собой все косяки, которые были выявлены в процессе эксплуатации (банально, запоминать IP адреса утомительно, даже IPv4, поэтому лучше обеспечить автоконфигурацию сети).
Сам протокол ничуть не хуже IPv4, а если быть точным, то лучше. Просто его нужно изучать отдельно. Он для сетевых администраторов сильно отличается. При этом он для пользователя вообще ничем не отличается, ибо пользователям вообще IP адреса не нужны в повседневной жизни.
Уже сейчас можно перевести сеть только на IPv6, при желании. Нужно просто увеличивать количество специалистов, которые будут готовы эти сети обслуживать (это сложно). NAT64 позволяет максимально упростить взаимодействие с IPv4 сетью.
Пока есть проблемы с небольшим количеством софта, который работает на настольных ОС. Весь этот софт жёстко завязан на сеть IPv4. Проблемы пока решаются со скрипом. При этом мобильные устройства работают в любой сети полноценно, все необходимые костыли для IPv4 в них есть из коробки.
Сам протокол ничуть не хуже IPv4, а если быть точным, то лучше.
Тут как раз тот случай, что лушее - враг хорошего. IPv6 не имеет каких-либо ключевых преимуществ, делающих его существенно лучше для пользователей и/или для провайдеров последней мили. А потому он не может вытеснить IPv4, который всё ещё достаточно хорош, чтобы с него не требовалось переходить.
не имеет каких-либо ключевых преимуществ, делающих его существенно лучше для пользователей и/или для провайдеров последней мили
Как это нет? А как же решение главной проблемы IPv4? Пользователям безразлично, у них всё работает, как раньше, а провайдеры избавляются от кучи бесполезного барахла, которое работает как NAT. Меньше железа, которое надо поддерживать, меньше потребления электроэнергии, соизмеримое качество услуг, если не лучше (пинг меньше, ибо IPv6 проще обрабатывать).
А как же решение главной проблемы IPv4?
А она в нашей реальности не наблюдается. От кучи барахла, которое работает как NAT все равно не избавишься: понадобится другое барахло, которое работает как брандмауэр. И оно не очень то другое, оно должно точно так же обеспечивать поддержание контекста сессиий - брандмауэру сесссии нужны не меньше, чем NAT-шлюзу. А без брандмауэра в нашей реальности нельзя.
От кучи барахла, которое работает как NAT все равно не избавишься: понадобится другое барахло, которое работает как брандмауэр.
CGNAT - это конкретные железки, которые ставят операторы у себя чтобы прогонять через них весь трафик IPv4. Они нужны только для IPv4. IPv6 идёт напрямую.
Если вы про домашние маршрутизаторы, то они как были, так и останутся. Просто теперь на них не будет NAT, останется только файервол. Но на таких скоростях это не особо существенно, по сравнению с тем, что через CGNAT множество клиентов пытается смотреть рутуб с вк видео в 4К.
Провайдеру точно так же нужен будет нат или стейтфулл фаервол для ipv6. Чтобы защитить своих клиентов. И от интернета и друг от друга.
Его функции и стоимость примерно неотличимы от текущего cgnat. Но он другой и платить надо еще раз.
Хм. Что же выбрать. Железку, которая будет нужна всегда она всегда будет при дикой нагрузке... Или железку, которую можно разгрузить просто договорившись с поставщиками тяжёлого контента, чтобы они внедряли IPv6.
Железки не так считаются и выбираются. Подобное железо нужно на весь канал и всех клиентов. Чтобы работало все нормально всегда.
И самое главное cgnat железо уже есть, уже работает и с ним уже умеют работать технари. А тут надо покупать что-то неведомое и учить людей с ним работать. Траты, лишние траты.
Провайдеру точно так же нужен будет нат или стейтфулл фаервол для ipv6. Чтобы защитить своих клиентов
что, простите? Какой еще фаервол у провайдера? Нет, спасибо, такого нам не надо. Фаервол должен быть только на конечном оборудовании - на роутере и в ОС пользователя. И так оно и работает сейчас. На Виндовс по умолчанию включен файрвол, на роутерах тоже (которые умеют работать с IPv6, а такие сейчас все, выпущенные за последние n лет).
Обычный. Без которого у вас все пользователи убегут. И он естественно есть у всех.
Представьте вы обычный провайдер. Основные клиенты мобилки. С тарифами по паре десятков гигабайт. Без фаервола даже запускаться нельзя.
Проводному на самом деле тоже. Железо у пользователей разное. Обычно старое. Каналы узкие. Без файрвола вы не можете их защитить.
Вы как будто до сих пор в 90тых где интернет необязательная приблуда гиков, а не домохозяек которые без него жить не могут.
Не путайте файервол в слое доступа и в ядре. Первый дешевле, плюс и правда защищает клиентов, в том числе друг от друга. Второй дорогой и никого не защищает, но NAT-то нужен именно тут.
Куда и как это ставят я не уверен. Но кажется что на входе проще. Там толстые каналы и большие железки. Зачем мусор по своей сети гонять?
Защищает точно так же как НАТ. Надо гарантировать невозможность обратиться из интернета к оборудованию абонента.
Второй дорогой и никого не защищает
Следует отметить, что от дикого интернета клиентов защищает и тот, и другой.
И он естественно есть у всех
зачем вы говорите за всех? Не нужно этого делать. Личный пример - мой мобильный оператор запустил IPv6, я, конечно же, проверил работоспособность - раздал по WiFi с телефона интернет на компьютер, там поднял простенький веб-сервер и смог зайти на этот сервер с другого провайдера (который поддерживает IPv6) безо всяких проблем. Данный факт значит, что у оператора файрвола в общем случае нет (возможно есть на 25 порту, это распостраненная практика). И это правильно! Потому что если у провайдера есть файрвол, то это значит, что для абонента это ничем не будет отличаться от CGNAT, а зачем тогда вообще уходить на IPv6, если связность не улучшится?
Я не исключаю, что какие-то провайдеры действительно могут ставить свой файрвол, но не думаю, что это является нормой. Разве что у вас в наличии статистика, подтверждающая вашу инфу.
Основные клиенты мобилки. С тарифами по паре десятков гигабайт. Без фаервола даже запускаться нельзя
вы пробовали сканировать порты на мобилках? Это не ВиндовсХР, на мобильных ОС попросту нет сервисов, которые постоянно держат открытые порты наружу. А если даже домохозяйка скачает такое приложение, как только оно будет свернуто, ОС закроет стек.
Вы как будто до сих пор в 90тых где интернет необязательная приблуда гиков, а не домохозяек которые без него жить не могут
домохозяйки используют роутер (где есть файрвол) и Виндовс, где тоже есть файрвол. Я не знаю, как можно взломать домохозяйку в этих условиях. А если она установит себе троян, то он сделает исходящее подключение и тут уже не важно, файрвол будет или NAT.
У нас порты закрывают по умолчанию. Все. И это правильно. У вас тоже к этому придут. После какого-то количества жалоб и ботнетов.
Возможно открытие по галочке может быть за какую-то небольшую плату. Это и сейчас так работает.
Разницы и нет. Вам про это с самого начала говорят. Никаких плюсов пользователям или провайдерам ipv6 не дает. Только проблемы и расходы.
Ну не нужна обычному человеку доступность его устройств из интернета. Она ему наоборот сильно вредит.
Возможно открытие по галочке может быть за какую-то небольшую плату. Это и сейчас так работает
"за плату" - отличная идея! Может еще за каждый открытый порт отдельно плату взимать? Вот провайдер-то обрадуется. Настолько продавать воздух мало кто умеет.
Ну не нужна обычному человеку доступность его устройств из интернета. Она ему наоборот сильно вредит
а можно провайдер не будет за меня решать, нужна ли мне доступность моих устройств? Или я не имею права поднять у себя сервачок, к примеру? Может нужно оформить юрлицо для этого? Или лицензию у государства купить?
Вы постоянно твердите одно и то же, как фанатик. Пожалуйста, приведите реальные примеры ботнетов, которые возникли в сети IPv6 несмотря на использование файрволов на роутерах пользователей.
На секундочку, на сегодня в некоторых странах IPv6 уже доступен 50-80% юзеров, значит, если угроза реальна, подобные прецеденты должны существовать.
У вас тоже к этому придут. После какого-то количества жалоб и ботнетов
я в этом не уверен. К примеру, сейчас нашел пример одного из больших американских провайдеров (T-Mobile), который начал развертывать IPv6 еще в середине десятых годов и данный пост за 2020 год подтверждает, что сам провайдер порты не блокирует, сервер поднять возможно. Может, к сегодняшнему дню они поменяли политику? Не знаю, более новой информации я не нашел.
Конечно можете. Поставив галочку и возможно заплатив немножко денег. Я не понимаю кто вам мешает прямо сейчас это сделать? Это сит совершенные копейки.
А вот 99 домохозяйкам вокруг вас это не нужно и они галочку не поставят. И сейчас не ставят и потом не будут.
Провайдеры вообще не тупые. И живую не в мире розовых пони 90тых.
Ботнетов на домашних устройствах море. Из недавнего громкого помню историю про микротики и принудительное обновление кинетиков.
Я не видел исследований как география ботнетов коррелирует с ipv6. Погуглю на досуге, интересный вопрос.
Поставив галочку и возможно заплатив немножко денег. Я не понимаю кто вам мешает прямо сейчас это сделать? Это сит совершенные копейки.
это если провайдер имплементирует такую галочку. Чего он делать совсем не обязан. У меня, к сожалению, нет статистики, какой процент провайдеров при работе с IPv6 блокирует порты по умолчанию и делает галочку, какой процент просто блокирует порты и не дает возможности разблокировать, а какой не блокирует порты вовсе.
Возможно, в свободное время создам опрос на реддите, чтобы потом оперировать хоть какими-то данными.
Ботнетов на домашних устройствах море
можете предоставить ссылки на конкретные случаи? Хочу углубиться в вопрос.
https://blog.cloudflare.com/meris-botnet/ Вот самый известный. Ботнет как раз был сделан через уязвимость доступную через интернет. То есть любое устройство которое нашли и которому можно обратиться заражается. Железки околодомашнего уровня.
С локациями зараженных узлов сложно. Оно сильно искажено. Не палят сразу все.
В России все дают белый адрес рублей за 300 в месяц. И блокируют только несколько совсем опасных портов вроде 25. Не вижу причин почему кто-то не будет давать или не будет порты открывать по запросу. Цена в любом случае смешная.
Вот самый известный
так а где там IPv6 упоминается? Этот ботнет управлялся по IPv6, или доступ к уязвимым роутерам получали через IPv6 или что?
Просто возможность обратиться к устройству из интернета.
В чаяниях апологетов ipv6 такая возможность должна быть у любого устройства.
Мы ходим по кругу, как мне кажется. Чтобы к устройству нельзя было обратиться из интернета, существует файрвол на роутере. К тому же, пространство адресов IPv6 нельзя просто взять и полностью просканировать, значит, у злоумышленников поле для маневра сокращается.
Да, нельзя быть на 100% уверенным, что у всех пользователей включен файрвол и что хоть у кого-то из них не найдется уязвимость, но давайте решать проблемы по мере их возникновения. Некоторые провайдеры до сих пор выдают белые IPv4, большинство провайдеров еще 10-15 лет назад выдавали белые IPv4 (CGNAT сравнительно недавно получил массовое распространение) и переход на CGNAT произошел не потому, что провайдеры внезапно захотели "защитить" своих пользователей, а по причине нехватки белых IPv4.
Поэтому я не до конца понимаю вашу позицию.
Фаервол должен быть только на конечном оборудовании - на роутере и в ОС пользователя.
Конечное оборудование, в ближайшей перспективе - это всякий IoT (условно, "лампочки"), из которого китайцы для удешевления (а удешевление - это конек китайцев, за что их любят) выкинули всё, что можно. Надеяться на его защищенность стремно, особенно, в некоторой перспективе, с учетом вновь наденных уязвимостей - а они будут. Городить для всего этого зоопарка управление обновлениями - та ещё задачка, китайцы вряд ли ее решать будут. Так что желателен защищенный периметр, и остается только роутер на периметре. Другой аспект: в схеме с защищенным периметром можно внутри позволить функциональность побольше, чем в диком интернете (ну, например, MS Network), не сильно при этом заморачивая пользователя, в схеме с защитой конечного оборудования настраивать это сложнее. И это - ещё одна причина делать схему с защищенным периметром.
А управлением брандмауэром периметра простого пользователя лучше не напрягать. Без управления же можно реализвать только простейшую защиту периметра по "системе ниппель" - ровно ту, которую дает NAT.
Либо брандмауэром на периметре так или иначе будет управлять провайдер (он будет счастлив, да ;-) , впрочем, с дургой стороны, он сможет продавать это как услугу).
остается только роутер на периметре
да, роутер в любом случаем будет, не будет же IoT устройство подключаться напрямую к провайдеру. Разве что провайдер мобильный, но там будет скорее всего отдельный тариф и на этом тарифе (и только на нем) уже можно сделать файрвол.
Без управления же можно реализвать только простейшую защиту периметра по "системе ниппель" - ровно ту, которую дает NAT
да, я тоже говорю об этом. И это бессмысленно, на мой взгляд - зачем вводить IPv6, если для юзера ничего не изменится, то есть нельзя будет открыть порт по желанию.
Всё-таки это безнадёжная история была. Скандалы, интриги, расследования!
Если кратко:
SIPP был в том числе политическим оружием IETF против ISO (и Винтон Серф в этот раз на стороне ISO).
Здесь не до аспектов внедрения, надо застолбить место и убедительно выиграть по фичам.
Ключевые решения приняты в 1992 - до CIDR, до DHCP, до SSL, до NAT и приватных IPv4-диапазонов, до осознания, что фичи IPng портируются обратно в IPv4 (IPsec, DiffServ).
По расширению IPv4 через Options к 1994 было 3 предложения, но с учётом конъюнктуры они бессмысленны (про-ISO'шный конкурент SIPP критиковался как тормоз прогресса, а они тогда - задний ход).
"Победу" CGNAT над IPv6 заметили в прессе в 1999.
Нашёлся RFC, который видел все проблемы IPv6 из 1994 года.
______
SIPP имел одну неочевидную задачу - победить ISO в борьбе за влияние. Правительство США в 1990 запланировало переход на протоколы ISO [pdf, с. 29]. Серф как глава крупного Internet Society (ISOC), связанного с IAB, выступал за замену своего IPv4 на ISO'шный CLNP (TUBA) (близко к IS-IS?) [с. 44].
CLNP предложили на роль IPv7 (7 - фальстарт) летом 1992. И стало ясно, что его надо отстранять, вместе с ISO(совпадение-не-думаю)C ("ISO(silent)C"). Чтобы у IETF было светлое будущее.
Разговоры в 1992:
An argument was advanced against TUBA: its development would not help advance the longer-term research.
IPv7 (CLNP) a mistake
First, adopting CLNP means buying into the ISO standards process.
we have to face the painful reality that any future changes that the Internet community wishes to see in the network layer will require ISO approval too.Second, CLNP deals with only *one* of the several issues facing IP, namely address depletion. At the same time, it forces us to take a giant step back on other issues. CLNP does *not* support multicasting.
CLNP as IPv7 seems destined to be a technical step backwards and to place a severe crimp on protocol innovation at a time when we need to innovate
The IAB, in a draft statement issued in June after meeting in Kope, favored TUBA. This raised a storm of hate mail, and the draft statement was retired
CLNP addressing plan is bogus, and the CLNP encodings are, to say the list, suboptimal. You are right to mention that we need "another kind of toy"; promising ideas are appearing in the ongoing debate.
Было три серьёзные группы:
одна объединится вокруг SIPP,
другая занимается TUBA,
третья - TP/IX (aka IPv7(другой(их всего 3))) => CATNIP.
CATNIP перенимал ISO'шную адресацию и "CATNIP integrates CLNP, IP, and IPX", так что он тоже неверный.
Сбор требований к новому протоколу в 1993, озвучивание требований в 1994, подведение итогов между тремя протоколами в 1995 - это, видимо, уже декорации для принятия SIPP.
В 1994 сформировалось ещё одно предложение по расширению IPv4 (третье предложение по опциям после EIP и TP/IX (ADDEXT)) - Address Extension by IP Option Usage (AEIOU). И... его не воспринимали как кандидата на IPng сами авторы. Презентовали как штуку на тот случай, если IPng задержится до исчерпания адресов, получили ответ - а зачем нам штука, которая только затруднит переход на IPng.
Капитан ВМС в 1996 в своей магистерской (ADA311814) видел ситуацию так:
SIPP was the proposal that differed least from IPv4, had the most details defined and (most importantly) had the best-thought-out transition plan.
В 1999 в Network World замечают, что
Originally, the IETF thought ISPs would want to move to IPv6 to meet customer demand for new Internet addresses/ However, ISPs have so widely deployed network address translation (NAT) devices ... that they're no hurry to move IPv6".
А в 1994 в IETF шли странные споры о том, зачем вообще нужны частные адреса.
There was a fair amount of spirited debate on RFC 1597, revolving around whether or not it was mandatory, that it was not always applicable if a site would eventually connect to the Internet, etc. Many feel that private addresses are a mistake, while others point out that it is irresponsible to use global address space for numbering hosts that never talk outside their site.
Ранние сомнения в IPng были в RFC1669 в 1994 - там замечают цену, нехватку NAT64, конкуренцию с CGNAT и то, что внедрение отложится до полного исчерпания адресов:
Can IPng compete against IPv4? ... Existing IPv4 users will migrate to IPng for one of three possible reasons:
New functionality not found in IPv4
Reduced costs by using IPng: It is quite unlikely ...
To gain connectivity to otherwise unreachable IPng hosts ... uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion
As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment.
some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet
it is not clear that IPng will secure sufficient following to attain market viability compete against IPv4 and the inevitable arrival of network address translation devices
В 1993 на заседании IETF озвучивали, что "The market will resist any IPng that does not just look like a new release of IP. Co-existence, and ease and cost of transition, should be key decision criteria", но в хорошем смысле (не "надо остановиться и задуматься", а "TUBA ещё меньше похожа на IPv4, чем SIPP!"). Дальше: рынок надо направлять, потому что сам он не сможет принять рациональное решение.
Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования. Его просто взяли и начали использовать.
Там ещё интереснее было. Международные бюрократы из ITU-T примерно в те же времена лепили и продвигали свой стек стандартов OSI (набор рекомендаций X.200), насколько я понимаю, базой им служи DECNet. Сейчас от это стека мало что осталось: наверное, только семиуровневая модель для собесебований, да протокол маршрутизации IS-IS со своими ни на что не похожими адресами CLNS, который приспособили для маршрутизации IP. И вот эти адреса - они изначально были существенно переменной длины, и никакого их исчерпания видно не было. Но с плодом творчества бюрократов случилось то, что и должно случаться с плодами творчества бюрократов - в жизнь не пошло.
А вот те вещи, что оперируют IPv4 адресами всё-таки нужно переписывать или приделывать на хосте костыль (clat), чтобы они продолжили работать. Тут уж ничего не поделаешь. Благо их очень мало. Это всякие звонилки, торрент клиенты... т.е. в основном p2p вещи.
Ни хрена их не мало. Это ещё всякий софт для локалок. В Unix/Linux-мире его мало, а на ПК - наоборот: всякие MS Network и пр. Впрочем там и IPv4 - не обязательно базовый протокол.
А, главное - поддержка разных адресов в коде sockets (то есть, всего нынешнего стека работы с TCP/IP): есть там набор функций для работы с именами и адресами gethostbyname/gethostbyaddr, используются они весьма широко, якобы, рассчитаны на работу с разными семействами адресов, но семейства задаются каждое своей константой (AF_xxx) и для IPv4 и IPv6 семейства эти константы разные (AF_INET и AF_INET6), и отводимые под адреса области памяти - тоже разные. Что там в диком мире творится, сколько програм захардкожено на IPv4 - страшно представить. Но clat, конечно, поможет привести всю эту кучу к мередиану. Наверное ;-)
Например, какие-то старые коммутаторы не знают про 128-битные адреса, где-то маршрутизаторы поддерживают IPv6 только после прошивки (которую производитель уже и не выпускает), а какое-то серверное ПО внезапно ожидает в поле IP-адрес не более 15 символов длиной… Зачастую проще не трогать этот устоявшийся «зоопарк», чем пытаться его перевести на новые рельсы.
Вот здесь не понял я. Неужели до сих пор остались устройства, до сих пор работающие? Ведь они со временем не изнашиваются и не требуют замены на новое оборудование уже с поддержкой нужных технологий? И нельзя сделать уже два параллельных трафика в зависимости от поддержки оконечного оборудования клиента?
Неужели до сих пор остались устройства, до сих пор работающие?
Работает? Не трогай! ©
Ведь они со временем не изнашиваются и не требуют замены на новое оборудование уже с поддержкой нужных технологий?
Там особенно нечему изнашиваться, механики немного, одна только электроника. Даже бытовые копеечные роутеры уровня DIR-320 первых аппаратных ревизий не проблема найти в живом виде и сегодня, просто они мало кому нужны сейчас даже как бекап на случай издыхания еще двух-трех роутеров, когда-то замененных в качестве апгрейда более новыми, и на всякий случай сохраненных. Так и провайдеры не станут обновлять оборудование только потому, что новое, молодежное™. Что неремонтопригодно сдохло или таки уже настолько устарело, что больше не имеет практической применимости, как вышеупомянутые DIR-320 - да, заменяется.
И нельзя сделать уже два параллельных трафика в зависимости от поддержки оконечного оборудования клиента?
Можно. Только кто за это заплатит?
DIR-320
Есть у меня такой. В рабочем состоянии. Но его проблема в том, что у него WiFi тоолько 802.11g. Т.е. рассчитывать на скорость больше 10 мегабит/с не стоит, а в шумных местах даже на стабильное соединение рассчитывать не стоит. Сама железка тоже слабая. Флешка маленькая, производительность низкая. А вот IPv6 скорее всего можно завести на неофициальной прошивке. Я туда ставил OpenWrt какую-то древнюю. Вполне вероятно, что там поддержка IPv6 была. Сейчас лень проверять, ибо установку больше 10 лет назад уже приходилось делать сборкой из исходников. Флешка маленькая и приходится урезать набор софта.
Основная проблема IPv6 как и у любой гораздо более совершенной версии уже работающего и популярного решения это сложность и обратная несовместимость.
128 бит для адреса с моей точки зрения это колоссальная ошибка, которая сделала конфигурацию просто человеко не читаемой, но взамен дала очень призрачное преимущество.
Кажется 64 бит хватило бы с запасом, при этом без проблем можно было отобразить старые 32 битные адреса на 64 со стандартным филером, что возможно позволило бы поженить ipv4 и ipv6 и значительно упростить переход на новую версию.
Кажется это как раз та история, где перфекционизм инженеров сыграл злую шутку со всей индустрией.
И в целом мне кажется, что ipv6 так до конца и не внедрят, просто один из бигтехов заморочится и родит компромиссный протокол с обратной совместимостью на который все радостно в итоге и переедут.
Как Лу Хэн сколотил состояние $300 млн на африканских IP-адресах
Тёмная история IPv6: почему мы 30 лет «переходим», но так и не перешли