Вы задаёте узкоспециализированные вопросы, ответы на которые не так часто встречаются в интернете. Если спрашивать что-то более общее, то он вполне справляется. Даже код может написать на уровне джуна. Другое дело, что этот код и джун сможет написать, если немного познакомится с языком. Но если что-то более сложное попросить, то уже чушь выдаёт. Это как у ребёнка спрашивать, который обложился книжками и умеет быстро по ним искать.
Сервер лучше разместить на домене 2 уровня, а не 3-го. Клиентам тоже удобнее будет. Тем более сервер не обязан размещаться на том же сервере, что и основной сайт, но может это делать.
Сертификаты лучше получать через DNS челлендж, потому что он позволяет получать wildcard сертификаты. Для этого понадобится какой-то DNS хостинг, который поддерживает API. Например, можно использовать Cloudflare даже на бесплатном тарифе. Но на самом деле вариантов много, смотрите что поддерживают certbot или lego. Лично мне больше нравится certbot, потому что он ставится через apt/dnf, уже имеет все необходимые преднастроенные таймеры и достаточно 1 раз попросить получить сертификат домена и дальше всё будет происходить автоматически. С lego всё придётся делать вручную. Возможно это когда-нибудь исправят.
Почему wildcard? Банально удобнее. А если основной веб-сервер и сервер матрицы разнесены на разные машины, то могут возникнуть заморочки с тем, что на сервере матрицы может понадобиться сертификат для домена 2 уровня и сделать это другими способами не получится. А с Wildcard никаких заморочек нет, просто используешь.
Apache не нужен. Если так хочется, то можно поднять что-то более лёгкое, вроде nginx.
В настоящее время вместо turn разработчики рекомендуют использовать Element Call. Его надо устанавливать на сервер. Если честно, то без контейнера совсем не хочется этого делать. А ещё клиенты для Android - Element и Element X не совместимы со аудио/видео связи. Первый работает через turn, второй через Element Call. Element Call более продвинутая штука, но у меня до него руки не доходят. Да и turn хватает пока.
Если кто-то захочет прописать turns:// вместо turn:// есть замачение. Раньше была такая проблема, что сертификаты Let's Encrypt не принимались некоторыми клиентами. На днях столкнулся с подобной проблемой, похоже до сих пор актуально. Просто перевёл сервер на turn:// и всё заработало. Раньше лечили заменой сетификата на turn сервере на другой бесплатный.
Всегда было так. У нас в городе даже на городской перезвонить было проблемой. А всё потому, что нумерация в городе была 5 значной, а CallerID выдавал номер в виде 7 знаков с остатком кода города. Естественно, если набрать этот номер, то никуда не дозвонишься, АТС не примет. А вот сотовые наоборот нормально определялись через 89...
Я вот тут подумал, а какая мне разница как там, через 8 или через 0 набирать. Я последний раз по стационарному телефону звонил с рабочего места. лет 9 назад. Да и то там звонки были или городские или вообще через офисную АТС. Я вообще не понимаю смысла использовать городские номера. Практически везде есть нормальный интернет и всё можно делать через него. А уж звонить в другой город и, тем более, в другую страну однозначно лучше через интернет. А даже если я буду звонить с сотового, то я там и так набираю всегда через +7, т. е. эти изменения вообще никак меня не коснутся. Удивительно, то PSTN ещё жива.
У меня только Fedora и Archlinux. Там случайный. Но у меня ещё и умолчанию работает DHCP в сети и выдаёт маленький адрес интерфейса. Поэтому все коннекты идут обычно с этого адреса на устройствах.
На OpenWrt, да, использует MAC. Пожалуй это единственное устройство в сети такое. Windows, Linux, Andorid не используют MAC. Разве что на Linux изначально может быть не включено Privacy Extensions. Но адрес всё равно случайный используется по умолчанию.
Тогда как в IPv6 провайдер интернета будет знать всю вашу ИЛС. Ему не нужно гадать, тратить ресурсы, требуется всего лишь фиксировать, это требует от него закон. Не забывайте про МАК адрес устройства . Фиксация адресов устройств вашей локальной сети, плюс возможно фингерпринты, снимки устройств проста и не требует ресурсов.
Ну вот у меня на устройствах всех IPv6 адреса меняются. Переподключился я к сети, адрес другой. Сутки прошли, устройство адрес сменило. Что даёт провайдеру знание этих адресов? Я их один раз использовал и больше вряд-ли когда-то снова использую. MAC-адреса мой провайдер вообще не видит, только MAC моего маршрутизатора.
Нет никакой связи. Хотя может быть какие-нибудь Cisco так делают. MAC адреса обычно светятся в link-local адресах fe80::/10. Но ими можно пользоваться только в пределах канала. Эти MAC-адреса и так светятся в кадрах Ehternet. А вот для GUA и ULA адресов адрес интерфейса как правило выбирается по определённому алгоритму (чтобы адрес был случайным, но постоянным в пределах одного префикса), либо вообще выбираются случайно и меняются спустя какой-то период времени (сутки, например).
Остаётся только надеяться, что эти перемены наконец-то добавят доступ по IPv6 к репозиториям. Сейчас вообще без проблем можно развернуть любой сервер на Linux, но как только дело касается деплоя, то все сталкиваются с тем, что зависимости должны скачиваться с github, а для этого твоему серверу нужен доступ в IPv4 интернет...
Я вообще не знаю как выбирать лампочки светодиодные. Купил пару штук в Ашане. Подумал, ну не будут же плохие продавать под собственным именем. Оказалось, могут. Обе лампы умерли в первые же минуты. Одна проработала несколько минут, другая несколько десятков...
А вам известны прецеденты забирания IPv6? А то вот почти год назад Huawei выдали аж /17 подсеть. Вы ещё одобряли такое транжирство. Однако даже спустя всё это время, я не наблюдаю у AS55990 выданного /17 блока. Это тоже норм?
Ну трудно оценить масштаб конторы просто по названию. Я думаю довольно большая. Что у неё есть конкретно, не знаю. Но ей сразу выдали блок достаточного размера, чтобы ей хватило.
Забирать IPv6 пока нет нужды. И там даже не забрать у тех, кому блок делегирован был. Речь о том, чтобы забрать из /48 клиентов и оставить им /56. Это гораздо проще сделать, чем забрать тот же, например, 11.0.0.0/8, который так любят использовать некоторые сотовые операторы РФ, потому что им не хватает серых адресов IPv4.
А что у вас не работает? У меня вот RTSP по IPv6 не работает.
Уверен, для него есть замена, которая работает через IPv6. А то, что железка какая-то не работает - это претензия к производителю. Ну, либо можно накостылить железку, которая будет через IPv6 передавать трафик туда, куда вам нужно. 464xlat в помощь, тот же самый костыль NAT, без которого IPv4 не жизнеспособен.
Кто-то это кто и для каких целей? Можете описать реальный юзеркейс?
На текущий момент у меня нет реальных кейсов.
Как уже писал выше, ~20% выделенных IPv6 уже разбазарены.
Скорее всего мало кому понадобится больше, чем уже выдали. Плюс им могут расширить сети за счёт резервирования диапазонов. Сейчас просто страшно смотреть на то, сколько сетей IPv4 у того же Ростелекома, которые никак не агрегируются. Такая щедрость как раз из этих соображений, чтобы у провайдера были маршруты, которые легко можно агрегировать грамотно распределяя их внутри сети.
Согласен. Но нигде нет ответа на главный вопрос: ЗАЧЕМ? Зачем хомяку 65536 /64 подсетей?
Затем, что это покроет потребности всех и не придётся потом ему выдавать ещё один префикс. Ну и всегда проще забрать, чем потом выделять дополнительное.
Если бы IPv6 действительно помогал экономить ресурсы - не было бы вопросов о целесообразности перехода на IPv6.
Это не про экономию. Это про то, что протокол разрабатывался так, чтобы убрать лишние накладные расходы, которые есть у IPv4, поскольку из-за длины адреса появляются свои проблемы. По факту оба протокола работают плюс-минус одинаково. Я вообще могу на своём ноутбуке выключить IPv4 и у меня практически всё будет работать, кроме тех сервисов, которые напрямую оперируют IPv4 адресами, например, торренты, IP-телефония и т.п. Торренты вполне качаются по IPv6, просто основные пиры на большинстве раздач сидят на IPv4. Телефония тоже может работать по IPv6, если сервис его предоставляет.
Я предлагаю стандартным домашним планам выделять /60 (это 16 /64 подсетей!). Не могу представить реальный юзеркейс, когда бы этого было мало.
Когда-то не могли представить, то кому-то может понадобиться больше 640 КБ памяти. Если сейчас не нужно, возможно понадобится в будущем. Также не забывайте, что у вас одну сетку забирает головной маршрутизатор. Кто-то у него может попросить 4 сети с трёх устройств. Вот и кончились выделенные 16 сетей. Дальше что? Городить NAT? Вот чтобы этого было не нужно делать и так щедро раздают адреса.
Какой зоопарк? Вы и так выделяете префикс. Объясните, пожалуйста, почему префикс /60 это уже зоопарк, а /48 - ещё не зоопарк? И на какой длине префикса возникает зоопарк?
Пока есть прецедент выделения блока 2630::/16, мягко говоря не провайдеру, все эти сухие расчёты разбиваются о реальность транжирства.
BCOP-690 (RIPE-690) чётко говорит, что необходимо каждому абоненту выделять сеть /48. Если провайдер так хочет разделить бизнес и не бизнес сегмент, он может выделять клиентам сеть /56, но резервировать под клиента всё те же /48. Ну а то, как выделяют в реальности блоки и почему могут нарушать правила, уже вопрос не к технарям.
Откуда такая уверенность, что будет после 2000::/ 3 ? Вы в будущее слетали?
Оттуда, что это прописано в протоколе. Есть адреса специального назначения (всякие ULA, мультикасты и прочее), всё остальное под GUA, т.е. те самые публичные IP адреса в интернете. Ну а те адреса 240.0.0.0/4 были адресами класса E. От классовой адресации очень быстро пришлось отказаться, так что вряд ли кто-то думал, что этот диапазон вообще захочет использовать как и другие диапазоны для адресов в интернете. Да даже если и использовать, то это лишь отсрочит неизбежное - нехватку адресов.
Тут хотелось бы больше информации. Вы проводили исследования / замеры накладных расходов между IPv4 и IPv6?
Я просто немного разбирался как работают компьютеры. Умел строить логические схемы, умел программировать на ассемблере. Для меня логично, что когда к тебе приходит какой-то набор байт, ты смотришь определённые байты, принимаешь решение, что делать дальше и отправляешь пакет или дропаешь. Для IPv4 нужно делать тоже самое плюс найти новые значения для некоторых байт (адрес назначения), заменить их, исправить контрольную сумму пакета и только потом уже отправить пакет дальше. Какой алгоритм выглядит проще? А ещё, у IPv6 фиксированная длина заголовка пакета, так что все операции с пакетом можно начать выполнять после получения определённого числа байт без какой-либо дополнительной логики. И я не говорю, что IPv4 плох. Я говорю о том, что разработчики IPv6 исправили то, что показало себя в IPv4 не очень хорошо!
Сколько лет существует IPv6? Какие, пусть даже теоретические, затруднения могут возникнуть у двухкомнатного хомяка с подсетью /60 ?
Предлагаете делить клиентов на 1, 2, 3 комнатные и коттеджи? И как мотом весь этот зоопарк обслуживать?
Есть все основания полагать, что если разбазаривание 2000::/3 продолжиться текущими темпами, то они в обозримом будущем адреса закончатся, а новые не смогут выделять по тем же причинам, по которым сейчас не выделяют адреса из 240.0.0.0/4. Типа много оборудования не поддерживают новую маршрутизацию.
Берём текущую адресацию 2000::/4. Если каждому клиенту будет выделено /48, то у нас остаётся 44 бита на адресацию этих префиксов. Сейчас весь интернет оперирует 32 битами. При этом некоторым клиентам требуется больше одного IPv4 адреса. Здесь же КАЖДЫЙ клиент получает достаточное количество адресов, чтобы больше не запрашивать новых префиксов (возможность запросить есть, но смысла нет, в большинстве случаев). И вы думаете, что адреса закончатся? А ещё есть второй такой же блок с 44 битами: 3000::/4. А когда он кончится, будет 4000::/4 и так далее. И, как я уже писал, в новых диапазонах могут установить другие правила распределения битов между интернет-регистраторами, провайдерами и клиентами. Например, могут решить не разбазаривать адреса в 4000::/4 и выдавать там каждому клиенту только /60. Вам всё ещё мало адресов и вы хотите их экономить?
В IPv6 все адреса от 2000:: до efff:: уже предполагают, что будут использоваться для GUA. Ограничение чисто организационное, что не выдаётся на текущий момент что-то отличное 2000::/3. Блок же 240.0.0.0/4 просто был зарезервирован.
И что лучше: настраивать файрвол (IPv6) или пробрасывать порты (IPv4) чтобы сделать доступными извне устройства локальной сети - пока не очевидно.
Я предпочитаю настроить файервол. Это одно простое правило, где всё понятно. При прохождении пакетов требуется минимум машинного времени для проверки что делать с пакетом, а не приходится лезть в заголовок пакета, что-то там исправлять и уже потом только передавать дальше. Некоторые вещи вообще сделать в IPv4 нельзя. Например, у меня дома один полноценный IPv4. Я не могу в своей локалке поставить два веб-сервера. Мне нужно делать какие-то костыли, например, проксировать запросы через один из серверов на второй, или менять порты, что отрицательно сказывается на читаемости адресов, ибо адрес должен будет включать нестандартный номер порта.
Вы основной логики не поняли. Лучше сразу щедро раздать диапазоны, чем потом городить кучу маршрутов, которые никак не агрегириуются. Такое распределение было выбрано сознательно, чтобы не столкнуться с разрастанием таблиц маршрутизации, которые в IPv4 просто огромные. Даже если операторам выделяют небольшой диапазон, то всё равно резервируют адреса под его расширение. Также и с абонентами. Если им потребуется, не нужно ничего менять. Если не потребуется, в будущем можно забрать и отдать другим.
Разработчик IP думал, что 32 бит должно быть достаточным для интернет-адресов. Почему? Да просто это был эксперимент. 4 миллиарда адресов - это было больше, чем тогда компьютеров в США. Он тогда представить себе не мог, что этот эксперимент утечёт в коммерцию и его будут использовать все. Там кроме небольшого количества адресов есть и ещё куча недочётов, которые в IPv6 исправили. Хотите, чтобы адреса экономили и потом столкнулись снова с чем-то подобным, с чем столкнулись с IPv4? Так, просто интересная заметка по теме про разработчика IP: https://spectrum.ieee.org/vint-cerf-mistakes
Тут нужны подробности: как в домашних условиях в рамках одной WiFi вы планируете раздать каждой лампочке свою собственную /64 подсеть?
Даже если предположить, что каждому контейнеру нужна своя /64, сколько таких контейнеров планируется дома у хомяка?
Ну кто ж его знает как это будет развиваться. Адреса выделяются именно так, чтобы ни у кого не было затруднений в будущем. Опять таки, когда создавали IPv4, то аргументом в пользу 32 бит на адрес было, что даже Минобороны США не будет иметь 4 миллиардов устройств, чтобы ощутить нехватку адресов.
В любом случае, /48 - это тот самый максимум, который решили выделять на 1 абонента просто потому что в пределах адресации IPv6 это можно сделать. Ну и есть резервные варианты.
Откуда информация? Scope: Internet. Reserved for future use
Ок. Тут меня поймали. Однако, как я понял, чтобы этот диапазон адресов задействовать, нужно переделать софт на некотором количестве устройств, которые в текущем варианте будут его неправильно обрабатывать. Такую же доработку софта требует внедрение IPv6. Что выберете? Добавить совсем небольшое количество адресов и продолжать пользоваться костылями в виде NAT или полностью решить проблему с нехваткой адресов?
Даже интересно, какие такие могут появиться потребности у хомяка в двухкомнатной квартире?
IoT, podman/docker
А могут и не добавить, как это произошло с 240.0.0.0/4
Никакой связи с IPv6. 240.0.0.0/4 никогда не предполагалось использовать для обычной адресации в интернете. А все разговоры только из-за того, что IPv4 адресов жёстко нехватает. Оно и не удивительно. Разработчики протокола не думали, что он будет использоваться в коммерческих целях. Это был тестовый протокол для проверки концепций. Поищите, в интернете есть видео одного из руководителей проекта. Он впрямую говорит, что распорядился выделить 32 бита на адрес, потому что ни у кого из тестирующих не будет столько устройств и этого хватит для тестов.
В IPv6 напротив вся адресация, за исключением разве что 0::/3 и ff00::/3 используется или зарезервирована для GUA. Разработчики учли опыт и ошибки IPv4 и заранее предусмотрели возможность изменения стратегии распределения адресов. Если будут какие-то проблемы, то перед выделением новых блоков адресов просто пропишут новую стратегию.
Язык уточняли? Вероятно он на английском проверял, что никаких изменений. Думаете иностранные модели обучают на русских текстах?
Вы задаёте узкоспециализированные вопросы, ответы на которые не так часто встречаются в интернете. Если спрашивать что-то более общее, то он вполне справляется. Даже код может написать на уровне джуна. Другое дело, что этот код и джун сможет написать, если немного познакомится с языком. Но если что-то более сложное попросить, то уже чушь выдаёт. Это как у ребёнка спрашивать, который обложился книжками и умеет быстро по ним искать.
Но в этом случае твой сервер должен иметь сертификат для домена 2 уровня! Тут как раз пригодится Wildcard сертификат.
Несколько замечаний.
Сервер лучше разместить на домене 2 уровня, а не 3-го. Клиентам тоже удобнее будет. Тем более сервер не обязан размещаться на том же сервере, что и основной сайт, но может это делать.
Сертификаты лучше получать через DNS челлендж, потому что он позволяет получать wildcard сертификаты. Для этого понадобится какой-то DNS хостинг, который поддерживает API. Например, можно использовать Cloudflare даже на бесплатном тарифе. Но на самом деле вариантов много, смотрите что поддерживают certbot или lego. Лично мне больше нравится certbot, потому что он ставится через apt/dnf, уже имеет все необходимые преднастроенные таймеры и достаточно 1 раз попросить получить сертификат домена и дальше всё будет происходить автоматически. С lego всё придётся делать вручную. Возможно это когда-нибудь исправят.
Почему wildcard? Банально удобнее. А если основной веб-сервер и сервер матрицы разнесены на разные машины, то могут возникнуть заморочки с тем, что на сервере матрицы может понадобиться сертификат для домена 2 уровня и сделать это другими способами не получится. А с Wildcard никаких заморочек нет, просто используешь.
Apache не нужен. Если так хочется, то можно поднять что-то более лёгкое, вроде nginx.
В настоящее время вместо turn разработчики рекомендуют использовать Element Call. Его надо устанавливать на сервер. Если честно, то без контейнера совсем не хочется этого делать. А ещё клиенты для Android - Element и Element X не совместимы со аудио/видео связи. Первый работает через turn, второй через Element Call. Element Call более продвинутая штука, но у меня до него руки не доходят. Да и turn хватает пока.
Если кто-то захочет прописать turns:// вместо turn:// есть замачение. Раньше была такая проблема, что сертификаты Let's Encrypt не принимались некоторыми клиентами. На днях столкнулся с подобной проблемой, похоже до сих пор актуально. Просто перевёл сервер на turn:// и всё заработало. Раньше лечили заменой сетификата на turn сервере на другой бесплатный.
Всегда было так. У нас в городе даже на городской перезвонить было проблемой. А всё потому, что нумерация в городе была 5 значной, а CallerID выдавал номер в виде 7 знаков с остатком кода города. Естественно, если набрать этот номер, то никуда не дозвонишься, АТС не примет. А вот сотовые наоборот нормально определялись через 89...
Я вот тут подумал, а какая мне разница как там, через 8 или через 0 набирать. Я последний раз по стационарному телефону звонил с рабочего места. лет 9 назад. Да и то там звонки были или городские или вообще через офисную АТС. Я вообще не понимаю смысла использовать городские номера. Практически везде есть нормальный интернет и всё можно делать через него. А уж звонить в другой город и, тем более, в другую страну однозначно лучше через интернет. А даже если я буду звонить с сотового, то я там и так набираю всегда через +7, т. е. эти изменения вообще никак меня не коснутся. Удивительно, то PSTN ещё жива.
У меня только Fedora и Archlinux. Там случайный. Но у меня ещё и умолчанию работает DHCP в сети и выдаёт маленький адрес интерфейса. Поэтому все коннекты идут обычно с этого адреса на устройствах.
На OpenWrt, да, использует MAC. Пожалуй это единственное устройство в сети такое. Windows, Linux, Andorid не используют MAC. Разве что на Linux изначально может быть не включено Privacy Extensions. Но адрес всё равно случайный используется по умолчанию.
Ну вот у меня на устройствах всех IPv6 адреса меняются. Переподключился я к сети, адрес другой. Сутки прошли, устройство адрес сменило. Что даёт провайдеру знание этих адресов? Я их один раз использовал и больше вряд-ли когда-то снова использую. MAC-адреса мой провайдер вообще не видит, только MAC моего маршрутизатора.
Нет никакой связи. Хотя может быть какие-нибудь Cisco так делают. MAC адреса обычно светятся в link-local адресах fe80::/10. Но ими можно пользоваться только в пределах канала. Эти MAC-адреса и так светятся в кадрах Ehternet. А вот для GUA и ULA адресов адрес интерфейса как правило выбирается по определённому алгоритму (чтобы адрес был случайным, но постоянным в пределах одного префикса), либо вообще выбираются случайно и меняются спустя какой-то период времени (сутки, например).
Остаётся только надеяться, что эти перемены наконец-то добавят доступ по IPv6 к репозиториям. Сейчас вообще без проблем можно развернуть любой сервер на Linux, но как только дело касается деплоя, то все сталкиваются с тем, что зависимости должны скачиваться с github, а для этого твоему серверу нужен доступ в IPv4 интернет...
Я вообще не знаю как выбирать лампочки светодиодные. Купил пару штук в Ашане. Подумал, ну не будут же плохие продавать под собственным именем. Оказалось, могут. Обе лампы умерли в первые же минуты. Одна проработала несколько минут, другая несколько десятков...
Ну трудно оценить масштаб конторы просто по названию. Я думаю довольно большая. Что у неё есть конкретно, не знаю. Но ей сразу выдали блок достаточного размера, чтобы ей хватило.
Забирать IPv6 пока нет нужды. И там даже не забрать у тех, кому блок делегирован был. Речь о том, чтобы забрать из /48 клиентов и оставить им /56. Это гораздо проще сделать, чем забрать тот же, например, 11.0.0.0/8, который так любят использовать некоторые сотовые операторы РФ, потому что им не хватает серых адресов IPv4.
Уверен, для него есть замена, которая работает через IPv6. А то, что железка какая-то не работает - это претензия к производителю. Ну, либо можно накостылить железку, которая будет через IPv6 передавать трафик туда, куда вам нужно. 464xlat в помощь, тот же самый костыль NAT, без которого IPv4 не жизнеспособен.
На текущий момент у меня нет реальных кейсов.
Скорее всего мало кому понадобится больше, чем уже выдали. Плюс им могут расширить сети за счёт резервирования диапазонов. Сейчас просто страшно смотреть на то, сколько сетей IPv4 у того же Ростелекома, которые никак не агрегируются. Такая щедрость как раз из этих соображений, чтобы у провайдера были маршруты, которые легко можно агрегировать грамотно распределяя их внутри сети.
Затем, что это покроет потребности всех и не придётся потом ему выдавать ещё один префикс. Ну и всегда проще забрать, чем потом выделять дополнительное.
Это не про экономию. Это про то, что протокол разрабатывался так, чтобы убрать лишние накладные расходы, которые есть у IPv4, поскольку из-за длины адреса появляются свои проблемы. По факту оба протокола работают плюс-минус одинаково. Я вообще могу на своём ноутбуке выключить IPv4 и у меня практически всё будет работать, кроме тех сервисов, которые напрямую оперируют IPv4 адресами, например, торренты, IP-телефония и т.п. Торренты вполне качаются по IPv6, просто основные пиры на большинстве раздач сидят на IPv4. Телефония тоже может работать по IPv6, если сервис его предоставляет.
Когда-то не могли представить, то кому-то может понадобиться больше 640 КБ памяти. Если сейчас не нужно, возможно понадобится в будущем. Также не забывайте, что у вас одну сетку забирает головной маршрутизатор. Кто-то у него может попросить 4 сети с трёх устройств. Вот и кончились выделенные 16 сетей. Дальше что? Городить NAT? Вот чтобы этого было не нужно делать и так щедро раздают адреса.
BCOP-690 (RIPE-690) чётко говорит, что необходимо каждому абоненту выделять сеть /48. Если провайдер так хочет разделить бизнес и не бизнес сегмент, он может выделять клиентам сеть /56, но резервировать под клиента всё те же /48. Ну а то, как выделяют в реальности блоки и почему могут нарушать правила, уже вопрос не к технарям.
Оттуда, что это прописано в протоколе. Есть адреса специального назначения (всякие ULA, мультикасты и прочее), всё остальное под GUA, т.е. те самые публичные IP адреса в интернете. Ну а те адреса 240.0.0.0/4 были адресами класса E. От классовой адресации очень быстро пришлось отказаться, так что вряд ли кто-то думал, что этот диапазон вообще захочет использовать как и другие диапазоны для адресов в интернете. Да даже если и использовать, то это лишь отсрочит неизбежное - нехватку адресов.
Я просто немного разбирался как работают компьютеры. Умел строить логические схемы, умел программировать на ассемблере. Для меня логично, что когда к тебе приходит какой-то набор байт, ты смотришь определённые байты, принимаешь решение, что делать дальше и отправляешь пакет или дропаешь. Для IPv4 нужно делать тоже самое плюс найти новые значения для некоторых байт (адрес назначения), заменить их, исправить контрольную сумму пакета и только потом уже отправить пакет дальше. Какой алгоритм выглядит проще? А ещё, у IPv6 фиксированная длина заголовка пакета, так что все операции с пакетом можно начать выполнять после получения определённого числа байт без какой-либо дополнительной логики. И я не говорю, что IPv4 плох. Я говорю о том, что разработчики IPv6 исправили то, что показало себя в IPv4 не очень хорошо!
Предлагаете делить клиентов на 1, 2, 3 комнатные и коттеджи? И как мотом весь этот зоопарк обслуживать?
Берём текущую адресацию 2000::/4. Если каждому клиенту будет выделено /48, то у нас остаётся 44 бита на адресацию этих префиксов. Сейчас весь интернет оперирует 32 битами. При этом некоторым клиентам требуется больше одного IPv4 адреса. Здесь же КАЖДЫЙ клиент получает достаточное количество адресов, чтобы больше не запрашивать новых префиксов (возможность запросить есть, но смысла нет, в большинстве случаев). И вы думаете, что адреса закончатся? А ещё есть второй такой же блок с 44 битами: 3000::/4. А когда он кончится, будет 4000::/4 и так далее. И, как я уже писал, в новых диапазонах могут установить другие правила распределения битов между интернет-регистраторами, провайдерами и клиентами. Например, могут решить не разбазаривать адреса в 4000::/4 и выдавать там каждому клиенту только /60. Вам всё ещё мало адресов и вы хотите их экономить?
В IPv6 все адреса от 2000:: до efff:: уже предполагают, что будут использоваться для GUA. Ограничение чисто организационное, что не выдаётся на текущий момент что-то отличное 2000::/3. Блок же 240.0.0.0/4 просто был зарезервирован.
Я предпочитаю настроить файервол. Это одно простое правило, где всё понятно. При прохождении пакетов требуется минимум машинного времени для проверки что делать с пакетом, а не приходится лезть в заголовок пакета, что-то там исправлять и уже потом только передавать дальше. Некоторые вещи вообще сделать в IPv4 нельзя. Например, у меня дома один полноценный IPv4. Я не могу в своей локалке поставить два веб-сервера. Мне нужно делать какие-то костыли, например, проксировать запросы через один из серверов на второй, или менять порты, что отрицательно сказывается на читаемости адресов, ибо адрес должен будет включать нестандартный номер порта.
Вы основной логики не поняли. Лучше сразу щедро раздать диапазоны, чем потом городить кучу маршрутов, которые никак не агрегириуются. Такое распределение было выбрано сознательно, чтобы не столкнуться с разрастанием таблиц маршрутизации, которые в IPv4 просто огромные. Даже если операторам выделяют небольшой диапазон, то всё равно резервируют адреса под его расширение. Также и с абонентами. Если им потребуется, не нужно ничего менять. Если не потребуется, в будущем можно забрать и отдать другим.
Разработчик IP думал, что 32 бит должно быть достаточным для интернет-адресов. Почему? Да просто это был эксперимент. 4 миллиарда адресов - это было больше, чем тогда компьютеров в США. Он тогда представить себе не мог, что этот эксперимент утечёт в коммерцию и его будут использовать все. Там кроме небольшого количества адресов есть и ещё куча недочётов, которые в IPv6 исправили. Хотите, чтобы адреса экономили и потом столкнулись снова с чем-то подобным, с чем столкнулись с IPv4?
Так, просто интересная заметка по теме про разработчика IP: https://spectrum.ieee.org/vint-cerf-mistakes
Ну кто ж его знает как это будет развиваться. Адреса выделяются именно так, чтобы ни у кого не было затруднений в будущем. Опять таки, когда создавали IPv4, то аргументом в пользу 32 бит на адрес было, что даже Минобороны США не будет иметь 4 миллиардов устройств, чтобы ощутить нехватку адресов.
В любом случае, /48 - это тот самый максимум, который решили выделять на 1 абонента просто потому что в пределах адресации IPv6 это можно сделать. Ну и есть резервные варианты.
Ок. Тут меня поймали. Однако, как я понял, чтобы этот диапазон адресов задействовать, нужно переделать софт на некотором количестве устройств, которые в текущем варианте будут его неправильно обрабатывать. Такую же доработку софта требует внедрение IPv6. Что выберете? Добавить совсем небольшое количество адресов и продолжать пользоваться костылями в виде NAT или полностью решить проблему с нехваткой адресов?
IoT, podman/docker
Никакой связи с IPv6. 240.0.0.0/4 никогда не предполагалось использовать для обычной адресации в интернете. А все разговоры только из-за того, что IPv4 адресов жёстко нехватает. Оно и не удивительно. Разработчики протокола не думали, что он будет использоваться в коммерческих целях. Это был тестовый протокол для проверки концепций. Поищите, в интернете есть видео одного из руководителей проекта. Он впрямую говорит, что распорядился выделить 32 бита на адрес, потому что ни у кого из тестирующих не будет столько устройств и этого хватит для тестов.
В IPv6 напротив вся адресация, за исключением разве что 0::/3 и ff00::/3 используется или зарезервирована для GUA. Разработчики учли опыт и ошибки IPv4 и заранее предусмотрели возможность изменения стратегии распределения адресов. Если будут какие-то проблемы, то перед выделением новых блоков адресов просто пропишут новую стратегию.