Хм. Что же выбрать. Железку, которая будет нужна всегда она всегда будет при дикой нагрузке... Или железку, которую можно разгрузить просто договорившись с поставщиками тяжёлого контента, чтобы они внедряли IPv6.
От кучи барахла, которое работает как NAT все равно не избавишься: понадобится другое барахло, которое работает как брандмауэр.
CGNAT - это конкретные железки, которые ставят операторы у себя чтобы прогонять через них весь трафик IPv4. Они нужны только для IPv4. IPv6 идёт напрямую.
Если вы про домашние маршрутизаторы, то они как были, так и останутся. Просто теперь на них не будет NAT, останется только файервол. Но на таких скоростях это не особо существенно, по сравнению с тем, что через CGNAT множество клиентов пытается смотреть рутуб с вк видео в 4К.
не имеет каких-либо ключевых преимуществ, делающих его существенно лучше для пользователей и/или для провайдеров последней мили
Как это нет? А как же решение главной проблемы IPv4? Пользователям безразлично, у них всё работает, как раньше, а провайдеры избавляются от кучи бесполезного барахла, которое работает как NAT. Меньше железа, которое надо поддерживать, меньше потребления электроэнергии, соизмеримое качество услуг, если не лучше (пинг меньше, ибо IPv6 проще обрабатывать).
Там до сих пор появляются костыли для перевода сети на IPv6. Например, появился RFC как маршрутизатор может анонсировать NAT64 в своём сегменте сети (PREF64). У меня сейчас Android из 2017 года и он в него не умеет, потому что стандарт появился позже. А вот более новые телефоны 2020 года и позже уже прекрасно могут отключить IPv4 и пользоваться PREF64 для доступа к ресурсам на IPv4. Осталось додавить создателей настольных ОС, чтобы они сделали clat доступным по умолчанию. Тогда клиентам будет вообще по барабану дуалстек у них или только IPv6.
Протокол IPv6 принят для замены IPv4 и присутствует на подавляющем большинстве устройств в их ОС. Любой предлагаемый протокол так же бы требовал вмешательства в ПО и глупо было тянуть за собой все косяки, которые были выявлены в процессе эксплуатации (банально, запоминать IP адреса утомительно, даже IPv4, поэтому лучше обеспечить автоконфигурацию сети).
Сам протокол ничуть не хуже IPv4, а если быть точным, то лучше. Просто его нужно изучать отдельно. Он для сетевых администраторов сильно отличается. При этом он для пользователя вообще ничем не отличается, ибо пользователям вообще IP адреса не нужны в повседневной жизни.
Уже сейчас можно перевести сеть только на IPv6, при желании. Нужно просто увеличивать количество специалистов, которые будут готовы эти сети обслуживать (это сложно). NAT64 позволяет максимально упростить взаимодействие с IPv4 сетью.
Пока есть проблемы с небольшим количеством софта, который работает на настольных ОС. Весь этот софт жёстко завязан на сеть IPv4. Проблемы пока решаются со скрипом. При этом мобильные устройства работают в любой сети полноценно, все необходимые костыли для IPv4 в них есть из коробки.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 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.
Есть у меня такой. В рабочем состоянии. Но его проблема в том, что у него WiFi тоолько 802.11g. Т.е. рассчитывать на скорость больше 10 мегабит/с не стоит, а в шумных местах даже на стабильное соединение рассчитывать не стоит. Сама железка тоже слабая. Флешка маленькая, производительность низкая. А вот IPv6 скорее всего можно завести на неофициальной прошивке. Я туда ставил OpenWrt какую-то древнюю. Вполне вероятно, что там поддержка IPv6 была. Сейчас лень проверять, ибо установку больше 10 лет назад уже приходилось делать сборкой из исходников. Флешка маленькая и приходится урезать набор софта.
Привет из 2025 года с цитатой из 2018 про IPv4. Нашёл на Лента.ру, но где-то есть даже видеозапись с подобным высказыванием и её стенограмма в английской википедии. Можете сами поискать, но вот суть:
«Отец интернета» пояснил, что IPv4 никогда не задумывался в качестве «производственной» версии, поэтому при его создании в 1970-х годах использовались грубые расчеты. Сначала ученые размышляли о том, сколько сетей будут использоваться в каждой стране. Они решили, что их будет как минимум две. Затем эксперты попытались посчитать количество существующих на тот момент государств. «Мы не знали точные данные, а Google тогда не было. Так что мы предположили число 128. Поэтому два раза по 128 — это 256, что занимает 8 бит, чтобы показать, в какой стране вы находитесь», — рассказал Серф. Затем перед исследователями стояла задача выяснить количество компьютеров, которые будут подключены к сетям. Так как в то время вычислительные устройства могли позволить себе лишь обеспеченные люди, команда назвала число 16 миллионов компьютеров — это означало, что для адреса хоста требуется 24 бита. «И я подумал, что если все это сработает, то мы создадим систему производственной версии, когда мы лучше поймем, сколько места нам нужно. Что ж, получилось не совсем так, как мы думали», — пояснил ученый. Он добавил, что протокол получил широкое распространение и «ускользнул от лаборатории».
Просто в реальном мире не всегда принимают осмысленное решение. Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования. Его просто взяли и начали использовать. Сам руководитель разработки Винт Серф признавался, что он делал протокол чисто для проверки концепций. IPv6 же изначально создавался для коммерческого использования. И как раз в нём были исправлены косяки IPv4. Банально, руководителю проекта в голову не могли прийти, что, по сути, лабораторным протоколом будет пользоваться весь мир, поэтому выбрал изначально эти 4 байта под адрес. Их хватило бы на все мыслимые и немыслимые эксперименты в то время.
Ну, а IPv6 сейчас вполне себе жив. Те же Индия и Китай активно им пользуются. Европа тоже переходит. Только в РФ с их сувенирным интернетом провайдерам не до этого.
Есть такая штука из 2002: IPv4+4:
Что-то мне подсказывает, что эту штуку нужно было внедрять также на всём парке оконечных устройств. Ну или на большинстве из них. По сути это ничуть не лучше перехода на IPv6, только ещё кучу софта переписывать для поддержки.
Тот же переход многих приложений на IPv6 - это просто замена A записи для нужного домена на AAAA. Именно благодаря этому большую часть софта можно обмануть и заставить работать по IPv6 просто с помощью DNS64. Т.е. модификации софта вообще не требуется.
А вот те вещи, что оперируют IPv4 адресами всё-таки нужно переписывать или приделывать на хосте костыль (clat), чтобы они продолжили работать. Тут уж ничего не поделаешь. Благо их очень мало. Это всякие звонилки, торрент клиенты... т.е. в основном p2p вещи.
Я тоже с лёгкостью назову 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 уже не нужно этим заморачиваться. Если есть маршрутизатор, то сеть сразу работает.
Если бы IPv6 сделали обратно совместимым с IPv4, то всё было бы прекрасно.
Опишите как вы себе это представляете. Инженерам, которые разрабатывали IPv6, это не удалось, поэтому они решили, что раз уж ломают совместимость, поэтому сразу будут менять то, что плохо работало. Поэтому IPv6 так заметно отличается от IPv4, потому что в него не стали тащить старые косяки.
В той же корпоративной среде было и есть дохренище специфичного софта, который дружит только и исключительно с IPv4, и никому не хочется изобретать костыли.
Большинство софта легко обмануть с помощью DNS64 и заставить обращаться к сервисам по IPv6 вместо IPv4. Ну а самый кривой софт, который идёт в обход системы или не кривой, но который оперирует непосредственно IPv4 адресами (торрент клиенты, например) тоже можно обмануть и заворачивать весь IPv4 трафик в IPv6. Но в этом случае требуется вмешательство непосредственно на устройствах. Нужный костыль есть во всех современных мобильных ОС и MacOS. Под Windows косталь пока работает ограниченно, но в Windows 11 сейчас тестируют полноценный костыль. Под Linux есть решения, но их нужно доустанавливать вручную. В NetworkManager тоже пилят свою реализацию, но она пока в стадии тестирования (можете принять участие в тестировании). Т.е. вполне реально сейчас не иметь IPv4 адреса на компьютере и не испытывать никаких затруднений.
Ну, и я уж умолчу про банальную человекочитаемость и запоминаемость IPv6. А ведь это важный человеческий фактор
А вот так с ходу приведите пример хотя бы одного IPv4 адреса, который вы помните наизусть. Часто слышу этот аргумент, но вот мало людей видел, которые помнят IPv4 адреса. А для тех же публичных сервисов можно вполне сделать удобный и короткий IPv6 адрес. Он будет чуть длиннее IPv4, но не критично.
Да я от провайдеров прошу только IPv6 с соблюдением bcop-690. Если будет NAT64, большой рекспект, мне будет проще. Да и понятно, что в случае с NAT64 провайдер думает о будущем, а не латает существующие проблемы своим NAT44. Тем более, что я уже сам сделал NAT64.
Никак не противоречит. Я не говорю, что мой провайдер даёт мне интернет только по IPv6. Я пытаюсь быть сам себе провайдером. Просто ради интереса. Мне просто интересно как будет работать сеть без IPv6. Дома такое легко провернуть. Да, мне пришлось развернуть NAT64, который должен быть у любого современного провайдера, мне пришлось развернуть DNS64, но можно пользоваться и публичными от Google или Cloudflare.
Было бы проще, если бы провайдер давал мне NAT64 и DNS64 по умолчанию. Тогда бы я смог сделать всё то, то я задумал просто на своём основном маршрутизаторе.
И, мой вывод, вполне можно жить в условиях только IPv6 сети. Все вопросы решаются либо на уровне операционных систем (мобильные устройства, в основном), либо на уровне домашнего маршрутизатора. Да, я подключал второй маршрутизатор и раздавал интернет через него. По сути я был сам себе провайдером. И, при этом, любой клиент имел доступ ко всем сервисам в интернете даже при том, что второй маршрутизатор подключался к головному только при помощи IPv6. Спойлер, оба маршрутизатора использовали OpenWrt. Cегодня мне пришлось настраивать дохлый D-link DIR-825 (хозяева квартиры оставили, почему бы и не применить), у которого проблемы с WiFi на 5 ГГц в качестве клиента моей WiFi сети. С настройкой IPv6 особо проблем не возникло. А вот с IPv4 возникли проблемы небольшие. Решил прибиванием IPv4 адресов жёстким.
Вроде говорят, что shall - это когда ты кому-то должен, т.е. не по собственной воле, а will - это твоё желание. Т.е. в юридических документах ты shall, а про свидание с девушкой will.
Любопытный факт. Благодаря тому, что вся семья смотрит ютуб, мой маршрутизатор показывает до 80%, а то и больше, трафика IPv6. Статистика ломается только когда качаю торренты. Там большинство пиров и сидов по IPv4 работает и прямо сразу жёстко ломает статистику. Ещё делал статистику по своему ПК. Но недавно поставил модифицированный NetworkManager и теперь у меня компьютер работают только на IPv6. Просто было интересно что сломается. Пока ничего не нашёл. Всё работает.
А для реализации 464XLAT нам надо и коробку NAT64 иметь (скорее плюсом купить аналогично как и коробку NAT44) и ещё дополнительно обязательно всем подарить совместимые с таким решением CPE
Тут провайдеру решать:
ставить NAT44 и делать в своей сети два стека;
ставить NAT64 и выдавать клиентам CPE подходящие.
И там и там расходы. Но если не внедрять IPv6, то придётся вечно содержать эти самые NAT44 и увеличивать их мощности.
Ну т.е. вы не против того, чтобы сломать совместимость. А теперь представим себе, что мы совместимость сломали и добавили всего 8 бит. Через какое время нам снова нужно будет ломать совместимость, чтобы снова расширить адресацию? Не лучше бы сразу сделать так, чтобы не иметь никаких проблем с адресацией много лет? Именно это и сделали разработчики IPv6. Ну а громоздкость IPv6 - это вынужденно. Как компактно записать 128 бит? Кстати, был один первоапрельский RFC, где предлагали записывать адреса в BASE85, но почему-то на практике это никто не использует. Кстати, а чем вас не устраивает сокращение IPv6 адресов? Вполне реально добиться вот таких адресов 2001:db8:beef::1 для тех узлов, адреса которых нужно помнить. Не сильно то длиннее и сложнее IPv4 адресов получается. Дома вообще можно извратиться, наплевать а рекомендации, и использовать что-то вроде fd00::1, что куда проще, чем 192.168.1.1.
Просто потому что для этого нужно вообще ВСЕ абонентские устройства перевести на IP
Не нужно ВСЕ переводить. Вообще их можно на IPv4 оставить. Просто на маршрутизаторе включаете CLAT, который работает с PLAT провайдера. Вместе это 464XLAT. Т.е. IPv4 трафик от клиентов локалки уходит на маршрутизатор, который заворачивает всё в IPv6. Этот IPv6 трафик по сети провайдера идёт на шлюз NAT64 провайдера и там обратно преобразовывается с IPv4. Провайдер в плюсе, ибо у них вообще нет IPv4 нигде, кроме NAT64. Абоненты могут хоть по старинке всё использовать на IPv4, хоть переводить свою сеть на IPv6.
Сложно сказать. У меня две железки от разных производителей SNR-CPE-ME2-SFP и Routerich AX3000. Сравнивать в лоб... Но если интересно, то рядом разница небольшая. От WiFi 5 скорость 600 мегабит/с, от WiFi 6 - 950 мбит/с. А вот сильно заметно где уровень сигнала слабый, там прямо сильно отличается. У меня как раз ноутбук стоит неудачно. И вот там где на WiFi 5 максимум 20-40 мегабит/с было раньше, там WiFi 6 может и все 400 мегабит/с выжать. А меньше 100 мегабит/с я даже не видел. По идее надо сеть планировать. Но у меня съёмная квартира и тут не будешь провода тянуть куда попало. Да и тема тут такая, что поставил и забыл. Вряд ли большинство потребителей подобного будут что-то делать для улучшения покрытия.
Достаточно бы, условно, добавить к ipv4 один старший октет и хватило бы
Покажите свой профессионализм и объясните куда этот старший октет добавить в заголовок пакета IPv4 так, чтобы не сломать совместимость. Ведь те, кто разрабатывал IPv6 наверно не подумали об этом. Вы просто будете спасителем человечества, если сможете решить эту задачу так, чтобы не менять прошивку всех устройств и не переписывать софт под ваш модифицированный IP протокол.
А если серьёзно, то конечно об этом думали. И не нашли куда дополнительные биты всунуть. Везде ломалась совместимость. Поэтому и решено было полностью переделать протокол и избавить его от всех недостатков IPv4, которые были выявлены. Ну и размер адресов не с потолка взяли.
P.S. А уж как это актуально, когда почти всё современное оборудование работает с IPv6...
Хм. Что же выбрать. Железку, которая будет нужна всегда она всегда будет при дикой нагрузке... Или железку, которую можно разгрузить просто договорившись с поставщиками тяжёлого контента, чтобы они внедряли IPv6.
CGNAT - это конкретные железки, которые ставят операторы у себя чтобы прогонять через них весь трафик IPv4. Они нужны только для IPv4. IPv6 идёт напрямую.
Если вы про домашние маршрутизаторы, то они как были, так и останутся. Просто теперь на них не будет NAT, останется только файервол. Но на таких скоростях это не особо существенно, по сравнению с тем, что через CGNAT множество клиентов пытается смотреть рутуб с вк видео в 4К.
Как это нет? А как же решение главной проблемы IPv4? Пользователям безразлично, у них всё работает, как раньше, а провайдеры избавляются от кучи бесполезного барахла, которое работает как NAT. Меньше железа, которое надо поддерживать, меньше потребления электроэнергии, соизмеримое качество услуг, если не лучше (пинг меньше, ибо IPv6 проще обрабатывать).
Там до сих пор появляются костыли для перевода сети на IPv6. Например, появился RFC как маршрутизатор может анонсировать NAT64 в своём сегменте сети (PREF64). У меня сейчас Android из 2017 года и он в него не умеет, потому что стандарт появился позже. А вот более новые телефоны 2020 года и позже уже прекрасно могут отключить IPv4 и пользоваться PREF64 для доступа к ресурсам на IPv4. Осталось додавить создателей настольных ОС, чтобы они сделали clat доступным по умолчанию. Тогда клиентам будет вообще по барабану дуалстек у них или только IPv6.
Не вижу смысла спорить. Моя позиция такая:
Протокол IPv6 принят для замены IPv4 и присутствует на подавляющем большинстве устройств в их ОС. Любой предлагаемый протокол так же бы требовал вмешательства в ПО и глупо было тянуть за собой все косяки, которые были выявлены в процессе эксплуатации (банально, запоминать IP адреса утомительно, даже IPv4, поэтому лучше обеспечить автоконфигурацию сети).
Сам протокол ничуть не хуже IPv4, а если быть точным, то лучше. Просто его нужно изучать отдельно. Он для сетевых администраторов сильно отличается. При этом он для пользователя вообще ничем не отличается, ибо пользователям вообще IP адреса не нужны в повседневной жизни.
Уже сейчас можно перевести сеть только на IPv6, при желании. Нужно просто увеличивать количество специалистов, которые будут готовы эти сети обслуживать (это сложно). NAT64 позволяет максимально упростить взаимодействие с IPv4 сетью.
Пока есть проблемы с небольшим количеством софта, который работает на настольных ОС. Весь этот софт жёстко завязан на сеть IPv4. Проблемы пока решаются со скрипом. При этом мобильные устройства работают в любой сети полноценно, все необходимые костыли для IPv4 в них есть из коробки.
Не вижу никаких противоречий с высказыванием Серфа. Он как раз и говорил о том, что разрабатывает протокол и ему нужны результаты какие-то. Он волевым решением выбрал длину адреса. Да и тогда никто не мог подумать, что понадобится больше. Даже если он бы решился выбрать больше, на него бы посмотрели как на дурака: «больше 4 миллиардов дорогущих устройств?».
Вот именно. В заголовок пакета напихали всего того, что по их мнению могло бы понадобиться. Никто тогда не мог составить точный прогноз. Как результат, при разработке 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.
Есть у меня такой. В рабочем состоянии. Но его проблема в том, что у него WiFi тоолько 802.11g. Т.е. рассчитывать на скорость больше 10 мегабит/с не стоит, а в шумных местах даже на стабильное соединение рассчитывать не стоит. Сама железка тоже слабая. Флешка маленькая, производительность низкая. А вот IPv6 скорее всего можно завести на неофициальной прошивке. Я туда ставил OpenWrt какую-то древнюю. Вполне вероятно, что там поддержка IPv6 была. Сейчас лень проверять, ибо установку больше 10 лет назад уже приходилось делать сборкой из исходников. Флешка маленькая и приходится урезать набор софта.
Привет из 2025 года с цитатой из 2018 про IPv4. Нашёл на Лента.ру, но где-то есть даже видеозапись с подобным высказыванием и её стенограмма в английской википедии. Можете сами поискать, но вот суть:
Просто в реальном мире не всегда принимают осмысленное решение. Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования. Его просто взяли и начали использовать. Сам руководитель разработки Винт Серф признавался, что он делал протокол чисто для проверки концепций. IPv6 же изначально создавался для коммерческого использования. И как раз в нём были исправлены косяки IPv4. Банально, руководителю проекта в голову не могли прийти, что, по сути, лабораторным протоколом будет пользоваться весь мир, поэтому выбрал изначально эти 4 байта под адрес. Их хватило бы на все мыслимые и немыслимые эксперименты в то время.
Ну, а IPv6 сейчас вполне себе жив. Те же Индия и Китай активно им пользуются. Европа тоже переходит. Только в РФ с их сувенирным интернетом провайдерам не до этого.
Что-то мне подсказывает, что эту штуку нужно было внедрять также на всём парке оконечных устройств. Ну или на большинстве из них. По сути это ничуть не лучше перехода на IPv6, только ещё кучу софта переписывать для поддержки.
Тот же переход многих приложений на IPv6 - это просто замена A записи для нужного домена на AAAA. Именно благодаря этому большую часть софта можно обмануть и заставить работать по IPv6 просто с помощью DNS64. Т.е. модификации софта вообще не требуется.
А вот те вещи, что оперируют IPv4 адресами всё-таки нужно переписывать или приделывать на хосте костыль (clat), чтобы они продолжили работать. Тут уж ничего не поделаешь. Благо их очень мало. Это всякие звонилки, торрент клиенты... т.е. в основном p2p вещи.
Я тоже с лёгкостью назову ULA префикс своей домашней сети, а также DNS Cloudflare: 2606:4700:4700::1111, 2606:4700:4700::1001, а также DNS64 от них же: 2606:4700:4700::64, 2606:4700:4700::6400. А уж ::1 грех не помнить :-D
Основной вопрос, зачем помнить большую часть адресов. Я занимаюсь сетями, поэтому мне удобно помнить некоторые адреса. Но если я просто пользуюсь интернетом, то мне они в большинстве своём не нужны.
А мне не надо помнить ULA в своей IPv6 сети. У меня все узлы самоконфигурируются. Если маршрутизатор им доступен, они получают адрес. Я не помню ни одного случая, когда мне нужно было вводить адрес на интерфейсе каких-либо оконечных устройств в моей сети. А вот с IPv4 приходилось это иногда делать, когда было непонятно, это устройство сломалось или это просто в сети нет DHCPv4 сервера, поэтому устройство не получило адрес. В IPv6 уже не нужно этим заморачиваться. Если есть маршрутизатор, то сеть сразу работает.
Опишите как вы себе это представляете. Инженерам, которые разрабатывали IPv6, это не удалось, поэтому они решили, что раз уж ломают совместимость, поэтому сразу будут менять то, что плохо работало. Поэтому IPv6 так заметно отличается от IPv4, потому что в него не стали тащить старые косяки.
Большинство софта легко обмануть с помощью DNS64 и заставить обращаться к сервисам по IPv6 вместо IPv4. Ну а самый кривой софт, который идёт в обход системы или не кривой, но который оперирует непосредственно IPv4 адресами (торрент клиенты, например) тоже можно обмануть и заворачивать весь IPv4 трафик в IPv6. Но в этом случае требуется вмешательство непосредственно на устройствах. Нужный костыль есть во всех современных мобильных ОС и MacOS. Под Windows косталь пока работает ограниченно, но в Windows 11 сейчас тестируют полноценный костыль. Под Linux есть решения, но их нужно доустанавливать вручную. В NetworkManager тоже пилят свою реализацию, но она пока в стадии тестирования (можете принять участие в тестировании). Т.е. вполне реально сейчас не иметь IPv4 адреса на компьютере и не испытывать никаких затруднений.
А вот так с ходу приведите пример хотя бы одного IPv4 адреса, который вы помните наизусть. Часто слышу этот аргумент, но вот мало людей видел, которые помнят IPv4 адреса. А для тех же публичных сервисов можно вполне сделать удобный и короткий IPv6 адрес. Он будет чуть длиннее IPv4, но не критично.
Да я от провайдеров прошу только IPv6 с соблюдением bcop-690. Если будет NAT64, большой рекспект, мне будет проще. Да и понятно, что в случае с NAT64 провайдер думает о будущем, а не латает существующие проблемы своим NAT44. Тем более, что я уже сам сделал NAT64.
Никак не противоречит. Я не говорю, что мой провайдер даёт мне интернет только по IPv6. Я пытаюсь быть сам себе провайдером. Просто ради интереса. Мне просто интересно как будет работать сеть без IPv6. Дома такое легко провернуть. Да, мне пришлось развернуть NAT64, который должен быть у любого современного провайдера, мне пришлось развернуть DNS64, но можно пользоваться и публичными от Google или Cloudflare.
Было бы проще, если бы провайдер давал мне NAT64 и DNS64 по умолчанию. Тогда бы я смог сделать всё то, то я задумал просто на своём основном маршрутизаторе.
И, мой вывод, вполне можно жить в условиях только IPv6 сети. Все вопросы решаются либо на уровне операционных систем (мобильные устройства, в основном), либо на уровне домашнего маршрутизатора. Да, я подключал второй маршрутизатор и раздавал интернет через него. По сути я был сам себе провайдером. И, при этом, любой клиент имел доступ ко всем сервисам в интернете даже при том, что второй маршрутизатор подключался к головному только при помощи IPv6. Спойлер, оба маршрутизатора использовали OpenWrt.
Cегодня мне пришлось настраивать дохлый D-link DIR-825 (хозяева квартиры оставили, почему бы и не применить), у которого проблемы с WiFi на 5 ГГц в качестве клиента моей WiFi сети. С настройкой IPv6 особо проблем не возникло. А вот с IPv4 возникли проблемы небольшие. Решил прибиванием IPv4 адресов жёстким.
Вроде говорят, что shall - это когда ты кому-то должен, т.е. не по собственной воле, а will - это твоё желание. Т.е. в юридических документах ты shall, а про свидание с девушкой will.
Любопытный факт. Благодаря тому, что вся семья смотрит ютуб, мой маршрутизатор показывает до 80%, а то и больше, трафика IPv6. Статистика ломается только когда качаю торренты. Там большинство пиров и сидов по IPv4 работает и прямо сразу жёстко ломает статистику.
Ещё делал статистику по своему ПК. Но недавно поставил модифицированный NetworkManager и теперь у меня компьютер работают только на IPv6. Просто было интересно что сломается. Пока ничего не нашёл. Всё работает.
Тут провайдеру решать:
ставить NAT44 и делать в своей сети два стека;
ставить NAT64 и выдавать клиентам CPE подходящие.
И там и там расходы. Но если не внедрять IPv6, то придётся вечно содержать эти самые NAT44 и увеличивать их мощности.
Ну т.е. вы не против того, чтобы сломать совместимость. А теперь представим себе, что мы совместимость сломали и добавили всего 8 бит. Через какое время нам снова нужно будет ломать совместимость, чтобы снова расширить адресацию? Не лучше бы сразу сделать так, чтобы не иметь никаких проблем с адресацией много лет? Именно это и сделали разработчики IPv6. Ну а громоздкость IPv6 - это вынужденно. Как компактно записать 128 бит? Кстати, был один первоапрельский RFC, где предлагали записывать адреса в BASE85, но почему-то на практике это никто не использует. Кстати, а чем вас не устраивает сокращение IPv6 адресов? Вполне реально добиться вот таких адресов
2001:db8:beef::1для тех узлов, адреса которых нужно помнить. Не сильно то длиннее и сложнее IPv4 адресов получается. Дома вообще можно извратиться, наплевать а рекомендации, и использовать что-то вродеfd00::1, что куда проще, чем192.168.1.1.Не нужно ВСЕ переводить. Вообще их можно на IPv4 оставить. Просто на маршрутизаторе включаете CLAT, который работает с PLAT провайдера. Вместе это 464XLAT. Т.е. IPv4 трафик от клиентов локалки уходит на маршрутизатор, который заворачивает всё в IPv6. Этот IPv6 трафик по сети провайдера идёт на шлюз NAT64 провайдера и там обратно преобразовывается с IPv4. Провайдер в плюсе, ибо у них вообще нет IPv4 нигде, кроме NAT64. Абоненты могут хоть по старинке всё использовать на IPv4, хоть переводить свою сеть на IPv6.
Сложно сказать. У меня две железки от разных производителей SNR-CPE-ME2-SFP и Routerich AX3000. Сравнивать в лоб... Но если интересно, то рядом разница небольшая. От WiFi 5 скорость 600 мегабит/с, от WiFi 6 - 950 мбит/с. А вот сильно заметно где уровень сигнала слабый, там прямо сильно отличается. У меня как раз ноутбук стоит неудачно. И вот там где на WiFi 5 максимум 20-40 мегабит/с было раньше, там WiFi 6 может и все 400 мегабит/с выжать. А меньше 100 мегабит/с я даже не видел. По идее надо сеть планировать. Но у меня съёмная квартира и тут не будешь провода тянуть куда попало. Да и тема тут такая, что поставил и забыл. Вряд ли большинство потребителей подобного будут что-то делать для улучшения покрытия.
Покажите свой профессионализм и объясните куда этот старший октет добавить в заголовок пакета IPv4 так, чтобы не сломать совместимость. Ведь те, кто разрабатывал IPv6 наверно не подумали об этом. Вы просто будете спасителем человечества, если сможете решить эту задачу так, чтобы не менять прошивку всех устройств и не переписывать софт под ваш модифицированный IP протокол.
А если серьёзно, то конечно об этом думали. И не нашли куда дополнительные биты всунуть. Везде ломалась совместимость. Поэтому и решено было полностью переделать протокол и избавить его от всех недостатков IPv4, которые были выявлены. Ну и размер адресов не с потолка взяли.
P.S. А уж как это актуально, когда почти всё современное оборудование работает с IPv6...