Комментарии 57
" Однако исследователями найдено множество способов обойти ограничения NAT. Самым простым является заражение машины внутри сети, которая уже сама будет связываться с удалённым центром управления." - вот именно поэтому NAT и выполняет важнейшую функцию безопасности, что просто своим фактом существования сценарий подлома от простого: обнаружение-скан-взлом усложняется до взлома изнутри.
А вообще вот эти все жуткие адреса в хексе не для людей просто. Помимо марщрутизации в ИТ и кибюербезе есть куча других работ и активностей. когда надо работать с адресами: вводить, искать, смотреть, анализировать логи глазками и т.п. И этот хекс просто не влазит в кэш мозга.
выполняет важнейшую функцию безопасности, что просто своим фактом существования
Нельзя подменять фаерволл - нат-ом
вот именно поэтому NAT и выполняет важнейшую функцию безопасности, что просто своим фактом существования сценарий подлома от простого: обнаружение-скан-взлом усложняется до взлома изнутри
В сети IPv6 эту функцию выполняет, как и положено, файервол. Например, в OpenWRT по умолчанию запрещён доступ к узлам внутри сети извне, без всякого NAT. Если вам нужен такой доступ, то это нужно явно прописать в правилах файервола.
Если бы не для людей оно бы и осталось чередой бит. Начнёте работать с IPv6 - быстро привыкните. Это если бы секретари возмущались от обилия форм бюрократии. Либо вы с этим работаете либо как обычный человек изредка с этим будете сталкиваться.
новый протокол не будет иметь обратной совместимости
Это главное, что затормозило весь процесс внедрения на много лет.
Верно, с адресами работают люди, а не роботы, адреса в хексе действительно жутковаты и контринтуитивны - не важно сколько дополнительных возможностей это дает.
В процессе разработки настолько важной вещи стоило бы проконсультироваться с психологами, админами-обывателями, а не принимать решения в узком кругу технарей-супергиков.
Начнем с того, как человек воспринимает числа: с возрастом в мозгу формируется отдельный элемент для каждого из часто используемых чисел величиной более 10. То есть, 127 мы запоминаем не как 1,2,7 а именно как 127 (сто-двадцать-семь). У нас есть оперативная память, позволяющая сохранить указатели на ограниченное число однородных объектов (принято считать, что в среднем это число равно 7). Обычный ipv4 тратит на запоминание 4 объекта, еще и место на порт остается (порт займет от 1 до 2 "указателей"). В чем ужас ipv6 для нашей памяти? Использование букв. Это для компьютера HEX числа нормальны. Наша память пытается запомнить [2001]:[0][db][8]:[2023]:[09][10]:[]:[12], минимум как 9 объектов (и это я еще скостил - 2001 или 2023 могут пройти за 1 объект, не как [20][01], так как это значения годов, которые мы часто встречали и которые по крайней мере у меня воспринимаются как цельное понятие; а db проходит единым из-за ассоциации с database).
Но эти 9 объектов разного подтипа - числа, слово db и пустота []. И значит еще неявное количество памяти нужно для коррекции подтипов объектов. А еще есть нагрузка на память из-за нефиксированности числа запоминаемых объектов ("а это точно вся длина что мы вспомнили, больше ничего нет?"). Ведь в ipv4 мы запоминаем всего 4 числа с пределом 255, простая самопроверка.
Теорию информации не обманешь. Если в адресе ipv6 хранится намного больше бит информации, то и помнить мы будем вынуждены больше, как бы там не укладывала информацию наша нейросетка.
Ну и про NAT: обязательность его использования автоматически создает некоторую защиту. И речь не о том, что стоит или нет расчитывать на NAT, как на средство безопасности. Нужно понимать, что в реальности люди-неспециалисты (неперфекционисты, непрофессионалы) предпочитают использовать технологии в минимально жизнеспособном виде. И если без NATa не обойтись, то когда он станет не нужен многие будут забывать про файервол / отключать / убирать его (а неудобно же, нужно настраивать, а и так работает и прочее).
В таких серьезных вещах, как сетевой протокол (всего человечества!) не место максимализму. Нужно подходить со здравым консерватизмом, высокой обратной совместимостью во всех аспектах контакта технологии с людьми.
Когда-то, когда размышляли о вариантах решения проблемы с лимитом адресов, я наивно предполагал, что решение будет наподобие такого:
Дополнительные 2 числа трудновато запомнить, но еще возможно. И хватит на 100+ лет. А еще можно было бы сделать автоматическую конвертацию протоколов, а не городить 2 параллельных сетевых стека. Старая адресация вошла бы, как часть новой. Новые устройства работали со старыми, старые с новыми (с нюансами естественно, задиапазонную часть адреса можно было бы передавать с помощью некого костыля, что на срок жизни устройств годный вариант и решающийся обновлением ПО). Но нет, любят все стереть и начать с чистого листа, как в присказке: "у нас есть 100 легаси стандартов, но все они плохие. а давайте сделаем новый, который лучше. теперь у нас 101 стандарт". При этом адресов заложили столько, что хватит на всю галактику (а на практике просто выносит память).
Как бы так не вышло, что к моменту полного внедрения ipv6 во всем мире и отказа от ipv4, актуальность ipv6 упадет, да потребуется разрабатывать новый стандарт (появятся какие-нибудь космические сети, квантовые сети, потребующие реализации своих особенностей и т.д.).
Я считаю, что внедрение ipv6 проходит крайне неудовлетворительно - до сих пор нельзя иметь сервер (для сервисов людям) лишь с ipv6 адресом. 99% локальных и магистральных провайдеров должны поддерживать ipv6 на всех уровнях, лишь тогда можно будет сказать, что он внедрен.
Я сам с сетями давно общаюсь. Мне наоборот казалось странным, что IPv4 адреса записаны десятичными цифрами. Это жуть как неудобно, когда настраиваешь сеть, отличную от /16 и /24. В ВУЗах целые контрольные работы студенты делают, где их учат правильно в десятичном виде распределять адреса. Если бы использовали шестнадцатеричную систему счисления, как делали программисты раньше, да и сейчас на низком уровне, то не было бы гораздо проще. А так приходится запоминать кучу магических цифр, как минимум 4, 8, 12, 16, 20, 24, 28, 32, 64, 96, 128, 160, 192, 224, 240, 252, 254... Если смотришь дамы в том же Wireshark,то IP адреса явно не видны, потому что записаны в шестнадцатеричном виде...
Но, если в IPv4 не имеет большого значения в какой системе указаны адреса, запись адреса заметно не изменится, то в IPv6 из-за размера адреса использование десятичной системы дополнительно раздуло бы и без того не короткую запись IP адреса.
А ещё представьте себе, чтобы вы делали в десятичной системе, если бы провайдер выделил бы вам сеть /56, как, например, делает сейчас Ростелеком? Например, 2a01:620:c130:a300::/56. тут мы чётко видим, что нам доступны последние два нуля перед двойным двоеточием. a3 всегда остаётся постоянным в нашей адресации.
Да, десятичная форма адреса это странно и неудобно для программиста. В случаях кодинга работа с ipv4 часто идет в HEX. Хотя это касаемо именно нативных/низкоуровневых приложений. В ЯП высокого уровня с адресами больше работают в текстово-десятичной форме.
Чтобы люди были с шестнадцатеричной системой "на ты", ее следует преподавать с самого начала, как обычный счет. И мыслить все время в ее категориях. Чтобы в памяти сформировались отдельные ассоциативы, хотя бы для 00-FF.
Но мне кажется, наша природная нейросеть не предназначена для естественной (неосознанной) работы с числами. Хотя бы вспомнить, как мы работаем с десятичной системой, запоминаем таблицу умножения. Для нас проще помнить числа, чем вычислять их.
А буквы помнить сложнее, чем числа (потому что пул букв больше, и не важно, что в HEX только до f).
На низовой работе админов регулярно приходится запоминать адреса, чтобы перенести их на иной носитель (на настраиваемый роутер, сервер, в список какого-нибудь ПО, на бумажку для другого админа). Для любого ipv4 адреса я способен 1 раз посмотреть, условно целую минуту побегать-поделать что-то и воспроизвести результат в другом месте. С ipv6 такое не прокатит, нужно смотреть 2-3 раза на источник. Уйти, держа весь результат в памяти не выйдет, приходится брать бумажку.
При том я в программировании немало поработал с HEX числами. Но все равно, даже в иной предметной области (значение цвета) 0BA5F2D7 мне проще временно помнить, как 195-424-98-3 (4 объекта одного типа), чем как BA-5-F-2-D-7 (6 объектов разного типа).
Воспроизвести голосом/надиктовать HEX тоже трудно - ведь в отличие от цифр у букв нет длинных прочтений, только их алфавитные звуки (и тут привет фонетический алфавит, Борис-Анна-пять-Федор-два-Денис-семь). Хотя... чем не идея и запоминать в такой форме, мне нравится.
Я понимаю, что HEX-представление дает удобство вычисления масок. Но плата рабочей памятью за это кажется слишком дорогой в случае ipv6.
Большинство вообще может не столкнуться с необходимостью где-то водить IPv6 адрес. Многие и без ввода IPv4 обходятся. При этом чтобы сеть IPv4 сама настроилась, нужен DHCP сервер. Если он по какой-то причине не работает или отсутствует, то мы вынуждены вводить руками IPv4 адрес устройства, IPv4 адрес маршрутизатора в качестве шлюза, маску сети, адреса DNS серверов. В IPv6 всё это предоставляет маршрутизатор с помощью анонса. Как пользователь, максимум, что вы можете сделать, выбрать адресацию для своей сети из fd00::/8. Если использовать DHCPv6, можно дать важным устройствам постоянный короткий IPv6 адрес. Например, адрес маршрутизатора может стать равным fd33::1. Т. е. команда ping будет выглядеть так: `ping fd33::1`. Тяжело запомнить?
А вообще, нормальный маршрутизатор предоставит вам услуги DNS. И, например, дома я спокойно могу войти по IPv6 на свой «сервер умного дома» на Raspberry Pi с помощью команды ssh raxxla. Мой DNS на маршрутизаторе автоматом добавит мой домен, например, raxxla.example.org, найдёт этот адрес во внутренних записях и вернёт внутренний адрес IPv6. Я даже один раз забыл адрес этого сервера, просто потому что давно им не пользовался. Зайдя по доменному имени (его я использую постоянно) спокойно посмотрел.
Кроме полноценного DNS есть ещё LLMNR и mDNS. Их тоже, при необходимости можно включить и настроить, и надобности в прямом указании IPv6 не будет.
По большей части, прямое указание IPv6 адресов требуется только тем, кто занимается настройкой сети или устранением неисправности. Как правило, эти люди отлично себе представляют что такое шестнадцатеричная система счисления. Так что «неудобство» записи IPv6 сильно преувеличено. Их практически не нужно запоминать и писать руками в большинстве случаев.
Эх, возможно, Вы даже не представляете сколько существует рядовых админов-эникеев, вынужденных настраивать локальные сети в диких (в плане развития) уголках ИТ. А ведь их гораздо больше профессионалов, которые разбираются в масках, днс и маршрутизации. Я бывал таким рядовым специалистом, да порой продолжаю быть.
Для меня не проблема настроить ipv6, но это делать как-то не удобно что ли (по указанным выше причинам трудности переноса адреса в своей памяти или голосовой передачи адреса собеседнику).
Простые эникеи, зачастую бывшие студенты на нижайше оплачиваемой работе, делают все по инструкциям и особенно не разбираются. Невольно и неосознанно тормозят подобные процессы перехода, а организациям без них не обойтись (продвинутых админов просто слишком мало).
Под термин админ-эникей я подвожу не только сотрудника провайдера, днями обжимающего витуху и параллельно рассказывающего клиенту, как выключить и включить (кстати, в нашем провайдере нет поддержки ipv6 в принципе). Это и мелкий инди-разработчик какой-то железки, работающей с сетью, знания которого недостаточны для реализации ipv6. Это и китаец, распотрошивший старую проприетарную прошивку западной IP камеры и адаптирующей ее под свой продукт-копию (привет китайским железкам у провайдера, в которых таки есть ipv6, но 50/50; или китайским IP камерам, где его нет нигде). Много таких примеров можно отыскать в разных сферах.
Конечно, при нужде всегда найдется человек, который разбирается в работе сети и осилит ipv6... но это просто не нужно, ибо оказывается - НЕ обязательно для нормальной деятельности, и так все работает. Ведь общеизвестно "работает - не трогай". Вот и внедряем, пока не сменится целое поколение людей (а то и 2 будет в итоге).
А вообще, нормальный маршрутизатор предоставит вам услуги DNS. И, например, дома я спокойно могу войти по IPv6 на свой «сервер умного дома» на Raspberry Pi с помощью команды ssh raxxla. Мой DNS на маршрутизаторе автоматом добавит мой домен, например, raxxla.example.org, найдёт этот адрес во внутренних записях и вернёт внутренний адрес IPv6. Я даже один раз забыл адрес этого сервера, просто потому что давно им не пользовался. Зайдя по доменному имени (его я использую постоянно) спокойно посмотрел.
а ещё есть mdns например avahi, оно даже иногда работает..
raxxla? Вау!
часто идет в HEX
Всё время читаю не как "в hex", а как "в НЁХ" с соответствующим отношением. :)
в иной предметной области (значение цвета) 0BA5F2D7 мне проще временно помнить, как 195-424-98-3
А это, вероятно, означает, что у вас цвет сжатый не по стандартной RGBA-системе (и кстати, не вижу в этом хексе 424 и 3, где?). Можете поделиться?
Хорошая статья, для общего обозрения. Особенно отмечу, что рассказали почему NAT не фаервол. Многие начинающие админы свято верят в него, и жутко удивляются почему /me на их принтере "война и мир" печатает после банального route add 192.168.1.0/24 via 172.20.1.16. Я бы только предысторию про нехватку убрал - думаю, что если человек читает про v6 - он уже в курсе, что к чему и почему. Но совсем не рассказали про недостатки - я например никак не приму, самоназначение адресов в моем колхозе, трудности в внедрении от производителей железа - иногда кажется, что каждый хочет свой v6!
Предыстория про нехватку неотъемлемая часть повествования, чтобы сразу отсечь вопросы «почему бы просто инженерам не добавить дополнительных бит в адрес». До сих пор есть те, кто думает, что можно был ничего не ломая просто добавить и больше ничего не делать. Именно так поступили разработчики, но поняли, что дополнительные биты просто некуда разместить не потеряв совместимость. А если теряется совместимость, то зачем тащить за собой ворох старых проблем?
Я особо не заметил недостатков IPv6, кроме того, что заголовка IP вырос с минимальных 20 байт до 40. Зато он стал постоянного размера. Так что разница может быть заметна только на пакетах очень маленького объёма, если вообще будет заметна. Есть не всегда полноценная поддержка протокола в софте. Но это не проблема самого протокола, это проблема ПО конкретного железа. Чтобы осветить это в статье, нужно попробовать много разного железа. У меня этот набор ограниченный. Большая часть железа IPv6 протокол поддерживает. Я даже ради эксперимента переводил свою домашнюю сеть только на IPv6 и спокойно пользовался всем необходимым. Для Steam и торрентов пришлось поставить clatd, но это из-за того, что они напрямую работают с IPv4 адресами и не пользуются DNS. Ну и в торрентах чаще попадаются пиры только с IPv4, но и с IPv6 тоже не мало. Пока IPv4 доминирует в рунете, поэтому смысла полностью уходить на IPv6 пока нет, проще пользоваться дома дуалстэком. Но если его доля IPv4 заметно упадёт, то вполне возможно задействовать и вариант с NAT64+DNS64.
Смотрите, а если вот порассуждать, как можно было бы (понятно, что "фарш обратно не провернуть"): мы вводим именно подверсию ipv4, выбрасываем работу с контрольной суммой, а в ее полях храним по 1 байту для входящего/исходящего адреса. Один доп. байт это конечно не 2, но увеличения всех адресов в 256 раз все равно ощутимо хватило бы человечеству на ближайшее столетие. Верно?
Всегда проще чуть-чуть скорректировать старый протокол, старый код, чем с нуля реализовывать и внедрять новое, что в итоге заняло 20+ лет, а не 1 цикл обновления hardware. А инженерной утопии, когда каждое устройство будет иметь свой IP (одно из обоснований адресации ipv6), не наступит, но не потому что адресов не хватит, а потому что уже начинают понимать, что это не правильно и не безопасно. И не все пользователи - инженеры, а точнее почти все НЕ инженеры.
А потом внезапно оказывается, что во всем выпущенном в мире софте и телекоммуникационном оборудовании адрес хранится в памяти в виде 32-битного числа.
И чтобы все это переписать/переделать — тоже надо 20 лет :)
Даже это мелкое изменение требует изменения ПО на ВСЁМ парке устройств. Ваше изменение делает протокол не совместимым с IPv4. К тому же вы не так много добавили в адрес и с нехваткой адресов можно вновь столкнуться очень быстро. Опять таки, адреса раздаются иерархично. Допустим мы решили проблему с обновлением ПО, чтобы оно стало поддерживать наш новый протокол (кстати, для IPv6 до большинства относительно современных устройств она уже решена). Этого одного байт недостаточно, чтобы распределить блоки между LIR, RIR и прочими. Опять придётся нашинковывать адресацию, как сейчас это обстоит в IPv4. Проходим весть тот же процесс с обновлением ПО, но толком так и не решаем проблему с адресным пространством, все косяки протокола тянем за собой, ещё и имеем новую адресацию, которую тоже как-то надо совмещать со старой на время перехода, да и все проблемы IPv4 тянем за собой... Великолепный план, отличный, как Швейцарские часы!
Я не зря упомянул железо. Да, это не проблема протокола, и как выясняется не проблема вендоров - они считают, что нет проблем. Каждый делает по своему, Android не знает ничего про DHCP6, D-link мне сказал - Multiple inteface no support DHCPv6 mode, hp 521 не умеет статику, итд итп. Зачем надо было сделать такие огромные префиксы и фактически запретить их делить меньше чем на /64, зачем мне в офисе триллион адресов на 10 компов, что бы я бегал по по компам вместо arp -a? Да, может это провайдер жмот, но иной раз у него PTR молебнами клянчишь, про RFC он с тобой говорить не будет. В итоге это становиться проблемой конечных пользователей. Точнее админов на местах, для которых попытка даже попробовать, превращается в танцы с бубном на минном поле.
Излишняя приватность грозит беспределом в своей сетке, и не возможностью найти хост в сети. Да, дома это не важно, когда устройств и с 10 не наберется, а в офисе, когда компов ~500? Никто на ff02:1 никто не отвечает. DUID генерируется на машину, и потом прется с ним во все сетевухи.
Нехватку адресов, кажется решили облаками, и внезапно это оказалось даже удобнее конечному пользователю. Теперь не надо утюгу прописывать адрес, настраивать доступ и файервол - проще завести аккаунт сяоми\хиквижен etc...
Кто в вменяемом состоянии будет тратить на это время, деньги, бороться с ветряными мельницами в виде гугла? Я не против V6, но практика показывает что будущего у него нет. Может у V6.1 какого-то, да. Но как я вижу в 2012 году перспектив было больше чем 2023, там еще была надежда. Получилось как с коммунизмом, вроде идея хорошая, но не получилось, не фортануло.
Угу, только этот IPv6 уже начал катиться в гуано.
Хостеры и провайдеры массово выдают абонентам подсети /64 и даже меньше, с которыми в силу криворукости программистов (в частности хочется передать очередной пламенный привет MS) и уже устоявшихся обычаев просто непонятно что делать.
Рассказывали, что можно будет отлично замапить на одну выданную подсеть все устройства без всяких NAT, а по факту?
Мало ли что там чего рекомендует, и что там в RFC написано: на тебе, дорогой друг, хорошо если /64 и успехов упихать туда восемь домашних устройств и ещё какую-нибудь шляпу за VPN. В результате опять NAT и шлюзы с кучей приседаний. Причём, приседаний значительно более извращённых чем с IPv4.
Как по ipv6 для устройства в домашней сети реализовать WoL из интернета? Если можно, с подробностями.
wol работает на канальном уровне. к ipv6 он не имеет никакого отношения.
как реализовать? отправлять пакет с маршрутизатора или устройства в локальной сети, которое уже доступно из интернета.
Как раз это устройство и должно быть доступно из интернета, иногда, но для этого его сначала надо разбудить. По ipv4 это вообще не проблема, так и пользуюсь. МГТС даёт либо белый ipv4, либо ipv6, одновременно и то и другое у них почему-то невозможно. За белый ipv4 плачУ, само собой. Если бы можно было реализовать WoL из интернета, имея только ipv6, без костылей типа промежуточных устройств, с которых можно разбудить целевое устройство, а напрямую, как с ipv4, просто отсылая пакеты WoL на сетевуху целевого устройства, пусть и через проброс портов, отказался бы от белого ipv4.
С каких пор WoL стал работать по IPv4?
Тем не менее, работает, сам использовал. Да, удивлялся, пробрасывается 9 порт. Пример инструкции по настройке. Кстати, старая статья на хабре, уже тогда так делали.
Я тут немного не в тему, но кажется прошаренные админы читают эту статью - подскажите нубу
Если у меня сеть построенная так: маршрутизатор -> коммутатор -> 2 устройства, и я гоняю траффик между этими двумя устройствами, будет ли он идти через 1 -> коммутатор -> 2 или 1 -> коммутатор -> маршрутизатор -> коммутатор -> 2?
Dhcp сервер понятное дело на маршрутизаторе.
А статья хороша.
если у вас плоская сеть с одним общим адресным пространством то первый вариант, а dhcp сервер тут вообще не при делах
В IPv6, кстати, даже устройства в такой схеме могут общаться через маршрутизатор. А могут общаться напрямую, если у них адреса из публичные из разных сетей. Тоже тема для статьи о маршрутизации в сетях IPv6. Есть интересные вещи, которых в IPv4 не было.
Если протокол обнаружения соседей NDP работает в вашей сети нормально, то узлы будут общаться напрямую. Если сломаете или ограничите, то они могут воспользоваться услугами маршрутизатора, если, конечно, смогут.
P.S. Я упоминал, что в заметке речь только об unicast адресах.
Да, тут вы правы. Я говорил лишь про идеальные условия. Вообщетзамечал на разных роутерах домашнего уровня разное "странное" поведение, влоть до того что на каком-то китайском чуде по умолчанию было запрещено всё общение устройств в локальной сети между собой, не проходил даже icmp. Благо тогда это решилось одной галочкой в настройках (одной из целых 4ёх, настроекат там было весьма куцо).
В коммутаторе есть таблица MAC. Роутер не будет участвовать. Просто отключите его и убедитесь. Когда время лизинга DHCP закончится - вот тогда могут быть проблемы.
АйпиВеШесть они ставят. А он нам на... не нужОн АйпиВеШесть ваш.
tldr - делаем по первому абзацу и всех дел)))
Особо жадные провайдеры могут выделять только одну сеть
/64. Но есть и те, кто щедро выделяет максимально сеть/48.
Почему жадные? Видимо не видят смысла выдавать домохозяйкам неиспользуемые излишества. Если приходящая в дом клиента витая пара втыкается в "WiFi роутер в подарок" то выдавать больше /64 попросту лишено смысла и практика это косвенно подтверждает.
Во-первых, RFC требует не менее /64. И, если не ошибаюсь, настоятельно рекомендует давать /48 и уж точно не рекомендует выдавать /64.
Во-вторых, и потому что, как ни странно, /64 позволяет полноценно полноценно подключить к шлюзу ровно ОДНУ однорагновую подсеть. Банально потому, что сразу несколько других протоколов IPv6 требуют не менее /64 на интерфейс. И куча софта, включая Windows просто не умеет работать с подсетями менее /64 так как есть RFC (на который плевали провайдеры).
То есть с /64 вы без NAT не можете ни роутер второго уровня поставить, ни виртуалку запустить, ни VPN куда-то пробросить. А у нас же цель была избавиться от NAT?
Для офисов и серверов адрес /64 это вообще катастрофа и издевательство.
Проблема в том, что в результате остаётся только вариант "роутер в подарок". Варианта "чёрт с вами, дайте хоть /60, придурки?" просто нет, так как "архитектура" у провайдера такая.
А дальше провайдер начинает таким же макаром офисы подключать и всяких корпоративных клиентов. Ну, не переделывать же из-за них всю структуру сети и билинг? Затем, раз уж всё равно все используют NAT на IPv6, то и хостеры начинают на сервера по /64 выдавать. И мы приходим к тому, что у нас опять бардак и куча NAT.
Рекомендация RFC давать /48 и однозначно шире /64 была именно поэтому: экономии всё равно никакой нет, а типовые конфигурации провайдеров позволили бы в однотипным образом покрыть большинство потребностей без необходимости в NAT.
Каждый бит даёт возможность добавить ещё один уровень подсети без необходимости делать NAT и сложные шлюзы. Маска /60 покрыла бы 99% потребностей пользователей, а /56 хватило бы даже многим корпоративным клиентам.
Но нет, провайдеры плевали на RFC и зачем-то начали экономить IPv6, и мы уже благополучно пришли именно в ту точку, куда иди совершенно точно не нужно было. У меня сейчас на всех VDS/VPS у всех хостеров только по /64 выдано на интерфейс. И пляши как хочешь.
ни роутер второго уровня поставить, ни виртуалку запустить, ни VPN куда-то пробросить
В моем комментарии речь шла исключительно о домохозяйках с роутером в подарок, которым больше /64 по определению не нужно.
Варианта "чёрт с вами, дайте хоть /60, придурки?" просто нет, так как "архитектура" у провайдера такая.
А если по запросу выдаётся /56 - все не так и плохо?
А если по запросу выдаётся
/56- все не так и плохо?
Даже если выделяется /56, должны резервировать /48, на будущее. Гораздо проще потом задействовать то, что не используется, чем потом выдавать вторую сеть тому, кому не хватило. Да и адрес сервера, если тебе выделили /48 смотрится гораздо лучше, например так 2001:db8:12ac::1. Но экономят обычно именно раздавая одну /48 своим клиентам по /64, например, адрес сервера будет таким 2001:db8:12ac:31::1. Тут даже просто дать дополнительную сеть /64 нельзя, потому что этот диапазон будет занят другим клиентом.
С домохозяйтвами попроще, потому что, скорее всего, всё выдаётся динамически. Сегодня выдавали /64, завтра выдают /56. Потенциально две проблемы. Во-первых, возможно провайдер запросил префикс недостаточного объёма и если под него не зарезервировали пространство, то придётся опять нашинковывать адресацию. Во-вторых, если рядом с вами на /64 сидит кто-то ещё чревато потенциальной проблемой, что из-за соседа могут забанить всю сеть /56, а то и /48 на каком-нибудь сервисе, например, если у соседа заражённый компьютер и он атакует этот сервис.
А для мобильного телефона тоже нужно /48 выделять?
Для мобильного точно нельзя выделять /64, так как к нему может быть подключен компьютер.
Для мобильного точно нельзя выделять /64, так как к нему может быть подключен компьютер.
Кстати, интересный вопрос. Теоретически Android должен получить префикс от провайдера, чтобы использовать его в той сети, которую раздаёт. Так он легко сможет дать отдельную сеть для USB подключения и для WiFi отдельную. При этом никакого NAT не нужно будет в силу того, что у нас есть несколько сетей /64 полноценных. Кто знает, умеет Android в такое? А iOS?
А возможно ли настроить soho WiFi так, чтобы каждому клиенту выделялась отдельная /64 ?
У меня IPv6 от Ростелеком. В качестве маршрутизатора устройство на OpenWRT. Оно вполне способно выделить нужный префикс из имеющегося /56. Например, была необходимость подключить устройство. которое не ловило WiFi нормально. Зато полуживой маршрутизатор D-link это делал отлично. Я его подключил в качестве клиента по WiFi. Маршрутизатор запросил себе префикс /64 и раздал его клиентам по проводу. Подключив к маршрутизатору устройство я получил полноценный доступ в интернет по IPv6. По IPv4 интернет тоже работал через костыль NAT64 на основном маршрутизаторе. DNS64 тоже на нём настроен и любая внутренняя сеть может работать полностью на IPv6 без IPv4.
Маршрутизатор запросил себе префикс /64 и раздал его клиентам по проводу.
Нет. В этом случае все клиенты WiFi используют один и тот же /64 префикс и вы фактически утилизируете выделенную вам /56 подсеть всего на 1/256. Мне же интересно, как настроить soho WiFi роутер так, чтобы каждому клиенту выделялся свой собственный префикс /64 из выделенной вам /56 сети. А иначе, какой смысл давать домохозяйствам /56 подсеть, если она никак не используются?
Я привёл пример, когда один из клиентов сети - другой маршрутизатор, запросил у головного отдельный префикс, чтобы раздать своим клиентам. По сути WiFi на нём стал WAN портом. В этом случае я именно задействовал вторую из выделенных мне сетей, т.е. 2/256.
Зачем ещё какому-то клиенту может потребоваться использовать другой префикс, кроме как раздать его в другой сети? На OpenWRT нужный префикс можно запросить через DHCPv6.
я именно задействовал вторую из выделенных мне сетей, т.е. 2/256
А как вы используете/планируете использовать ещё 254 сети?
Я всё пытаюсь понять, в чем польза от выделения домохозяйствам чего-то большего, чем /60 , если оно никак не может быть использовано?
Зачем ещё какому-то клиенту может потребоваться использовать другой префикс, кроме как раздать его в другой сети?
Полученный префикс раздавать не обязательно, можно им самостоятельно пользоваться, полностью отгородившись от соседей.
На OpenWRT нужный префикс можно запросить через DHCPv6.
Это если клиентом является OpenWRT. А как с android телефона запросить нужный префикс?
А как вы используете/планируете использовать ещё 254 сети?
Я всё пытаюсь понять, в чем польза от выделения домохозяйствам чего-то большего, чем
/60, если оно никак не может быть использовано?
Ну мало ли что будет в будущем. Может появятся сети различные, одна на Matter для умного дома, другая Bluetooth нового поколения. и всем им надо будет отдельные префиксы. И они могут быть вложенными, т.е. одной сети, например, Matter может не хватить.
А выделение /48 сетей на пользователя, а точнее на подключение, исходит для того, чтобы более равномерно распределить пользователей по всей адресации, чтобы не столкнуться с такой же проблемой, когда IPv4 адресов стало не хватать и пришлось нашинковывать мелкие сети. А эти сети все должны быть в таблице маршрутизации снижая эффективность маршрутизации. Когда мы делаем такой запас, мы заботимся о будущем. Ну не понадобится подобное, примут новые правила распределения адресного пространства, более эффективное для 4000::/4, чем было в 2000::/3.
Если хотите аналогию, то представьте,что у нас есть поезд огромный из кучи вагонов, но билеты продают только в первые два, чисто для экономии пространства остальных вагонов. А потом кто-то из пассажиров решил взять с собой друга, но друга поселяют уже в другом купе или даже вагоне, потому что рядом с вами уже всё занято. Логичнее равномерно распределить пассажиров по всему составу, чем заставлять их набиваться в одном месте, всё равно он поедет весь.
/56 с динамическим префиксом не так уж и плохо, потому что это легко переделать. Если только провайдер не запросил сеть маленького размера ввиду того, что изначально планировал раздавать /56. Но и тут спасут уровни выше, которые могли резервировать сеть побольше для этого провайдера, на случай, если захотят расширяться.
Ну мало ли что будет в будущем.
Ваша позиция ясна. Но, как видно по ссылке выше, многие провайдеры её не разделяют и выдают в подавляющем большинстве /64 .
IPv4 адресов стало не хватать
ИМХО IPv4 стало не хватать не из-за того, что их очень мало, а из-за того, что в своё время /8 блоки бездумно выделялись абы кому.
Ну так и IPv4 адресов почти в 2 раза меньше, чем населения на планете. А мы ещё хотим устройства подключать разные. А вот в IPv6 совсем другой расклад. Там даже если весь 2000::/4 раздать, то каждому жителю земли достанется больше 2000 сетей /48. Даже если население земли вырастет в 2000 раз... всё равно каждому достанется по одной сети /48. Но это будет наименьшая проблема при таком перенаселении.
Там даже если весь 2000::/4 раздать, то каждому жителю земли достанется больше 2000 сетей /48.
Это слишком грубый расчёт, имхо. Если верить статистике более 54% это reserved.
А там есть ещё 3000::/4, 4000::/4... И так до e000::/4.
А там есть ещё 3000::/4, 4000::/4... И так до e000::/4.
Это очень смелое предположение: перечисленные вами блоки находятся в статусе reserved и нет оснований полагать, что их не постигнет судьба 240.0.0.0/4 который тоже всё ещё reserved.
iOS17.1, isp выдает динамически изменяемый префикс /64. При раздаче через wifi - клиент-windows получил тот же префикс и дополнительно назначил себе 2 адреса /128. Но, к сожалению я не могу ответить на твой вопрос, и провайдер не выдает меньший префикс для тестов
к нему может быть подключен компьютер
А телефоны уже научились нарезать получаемый префикс на мелкие подсети для клиентов? Подскажите как сделать, чтобы при получении /56 телефон смог каждому клиенту по теттерингу давать отдельную /64 ?
Знакомство с IPv6 на практике