У меня тоже валяется. Но у неё срок вышел. И банковская карта из неё не вышла, ибо счёт вроде как и не открыли. Но позже выяснил, что в Сбербанке есть какой-то старый закрытый счёт привязанный именно к этой УЭК, который я так и не смог открыть.
Ну при установке Linux можно накосячить. Но, в основном, это от того, что ты плохо понимаешь что делаешь. В популярных дистрибутивах явно указывается что и куда ставить, в том числе и загрузчик. В установщика Windows такого выбора нет.
Я же уже написал, что две системы на одном диске - это наихудший вариант. Им я давно не пользуюсь. Но и с системами на разных дисках установщик Windows может накосячить и поставить загрузчик на другой диск, при этом не выделив пространства под загрузчик на том диске, куда ему сказали устанавливать систему.
Было дело :-D Держал Windows для World Of Tanks, но потом купил новый WiFi адаптер и оказалось, что Windows 8.1 в него не умеет, а Windows 10 не умеет нормально работать с графическим адаптером. Ноутбук, поэтому адаптер не заменишь. Так что Windows окончательно ушёл в прошлое вместе с Миром Танков. Пока была Windows на отдельном диске, настрадался. У меня и 8.1 до 10 сама по себе обновлялась ломая игру и откатываться приходилось по полной, потому что система после обычного отката на 8.1 начинала дико тормозить на HDD. Windows - боль!
Основная проблема - переустановка Windows при наличии дуалбута, да и вообще наличия других систем, которые отличны от Windows. Установщику Windows плевать что у вас там есть и он может поставить загрузочную запись туда, куда ему вздумается, даже если вы указали ему на какой диск ставить. У меня доходило до того, что диск с Windows никак нельзя было запустить без дополнительного диска. Загрузчик был установлен на раздел диска с Linux, а на диске с Windows 8.1 просто не было выделено места под загрузчик, хотя система заняла весь диск. Золотое правило - устанавливаешь Windows, отключи все лишние диски, иначе она их может испортить. В крайнем случае можно произвести начало установки через виртуальную машину, чтобы она видела только один диск, но это не спасёт, если у вас на этом диске есть ещё и Linux. В этом случае придётся вручную восстанавливать загрузчик Linux.
Если у вас Windows и Linux на одном диске, то придётся овладеть скилом восстановления загрузчика Linux. А ещё, могут не устанавливаться некоторые обновления на Windows и чтобы их поставить, нужно установить загрузчик Windows, установить обновления, восстановить загрузчик Linux.
P.S. И не забывайте страдать, если используете Windows!
Сложно жить по закону там, где законов нет. Если понадобится, то в суде найдётся эксперт, который даст нужно заключение. Если кто-то найдёт законный способ от чего-то отказаться, то будет создан новый закон, по которому законное право будет отобрано. Очередная Филькина грамота просто развязывает руки РКН, а тот уже выборочно будет её применять к тому, к кому надо. Тут даже обсуждать нечего.
Небольшой лайвхак как разгрузить NAT: нужно внедрить IPv6. Тогда огромный объём трафика, как минимум с Youtube, уйдёт с NAT на IPv6. А по сути надо стимулировать включать IPv6 на серверах и у клиентов. Это же позволит снизить нагрузку за провайдерский NAT и, в перспективе, полностью уйти от него. В текущих реалиях без IPv4 тяжело только с торрентами и всё, что на битторренте основано, потому что пиров мало или может совсем не быть. У Steam тоже были проблемы, но они решались костылём на клиентской машине. Т.е. вполне реально жить только на IPv6!!! Но вот для дома есть сложные случаи. Можно и вообще построить сеть доступа только на IPv6, но это только если провайдер может позволить себе заказать свои CPE, например, с MAP-T. В РФ о таком пока не слышал, а в Европе и США уже есть. В РФ вообще всё глухо... мне доступно 1,5 провайдера, везде выдают IPv6 криво: Ростелеком режет в мою сторону все соединения и хоронит сквозную прозрачность, а Дом.ру, вроде, выдаёт только /64. А из сотовых первым был МТС, сейчас к нему подключился Мегафон. Про Мегафон точно могу сказать, что работает, сам пользуюсь.
Я тут так много участвовал в дискуссии на счёт протокола IPv6, что забыл одну важную деталь, которая касается посыла статьи! AWS начинает взимать плату за драгоценный ресурс, такой, как IPv4. Так что всего этого можно избежать просто заплатив за роскошь - возможность использовать IPv4. Т. е. если ваш ресурс для вас ценен, просто оплатите услугу и забейте на все сложности, которые могут возникнуть при переходе на IPv6.
И вот что мне показалось странным. Неужели Amazon не предоставляет услуги NAT64? По мне так это самый логичный вариант. Пользователи услуги будут пользоваться готовыми шлюзами в IPv4 сеть и получать все необходимые ресурсы, при этом почти не почувствуют отсутствие IPv4, кроме разве что того, что их сервисы недоступны через IPv4. DNS для этих нужд есть у Googe и Cloudflare, например. NAT64 со специально выделенным диапазоном 64:ff9b::/96 должен предоставить ваш провайдер. Очень странно, что Amazon так не делает. У кого есть возможность, проверьте, должно быть.
Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Да кто ж вам NAT запрещает то? Я бы, пожалуй, вашу задачу тоже бы с ходу решил через NAT. На устройствах пользователей основной IPv6 от провайдера. А на шлюзе маршрутизация нужных адресов в нужный туннель, на конце которого NAT с его собственной адресацией. При чём транслировать можно адреса 1:1, а значит даже состояние не нужно запоминать для соединений.
NAT плох там, где его рассматривают как средство обеспечения защиты сети, хотя он им не является. К тому же, повсеместное применение его приводит к неявному отказу от главного принципа Internet: сквозной прозрачности на сетевом уровне [RFC 2775], когда любой хост А может послать пакет IP любому хосту Б (где А может быть равно Б). В вашем варианте, кстати, сквозная прозрачность нарушена, так что почему бы в этом случае не использовать NAT как средство обхода проблемы.
Воспользуюсь вашим методом. А вы знаете, что в IPv4 используется ARP? Если ваше устройство не отвечает на ARP запросы, то оно не сможет работать, т.е. полной изоляции не получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке ARP. Так что срочно нужно отказаться от IPv4! А если серьёзно, то никто не заставляет вас все ICMP направлять напрямую без какой-либо фильтрации на вашем брандмауэре. И есть вполне конкретные решения для защиты сети. Они другие, не такие как в IPv4. Но и протокол у нас другой, который учитывает ошибки в старом протоколе.
Вы явно недооцениваете инженеров, которые проектировали IPv6.
Цитата из книги «IPv6 для знатоков IPv4», Ярослав Тихий, 31 декабря 2013 г.:
Попробуем для начала консервативный подход. Можно ли расширить адрес IP, не отказываясь от протокола IPv4 и, в частности, от его формата заголовка? Например, мы могли бы поместить новые, расширенные адреса в специальные опции IPv4. ARP справился бы с новыми адресами, так как длина адреса в нем явно указывается. С ICMP ситуация сложнее, так как некоторые типы сообщений ICMP включают в себя адреса IPv4. Наконец, фиксированное смещение адресов от начала заголовка облегчает быструю аппаратную маршрутизацию пакетов, тогда как размещение адресов в опциях значительно усложнило бы ее. Ну, и вообще говоря, опции потому так и называются, что они должны быть факультативными, то есть необязательными для исполнения. Это окончательный аргумент против того, чтобы новые адреса находились в опциях IPv4. В то же время, основной заголовок IPv4 рассчитан только на 32‑битные адреса. Вывод такой, что текущим форматом заголовка IPv4 нам все-таки придется пожертвовать, поскольку в нем нет места для новых адресов.
Теперь, когда мы готовы распрощаться с заголовком IPv4, у нас возникает противоположное искушение: не просто расширить адреса, а радикально переделать протокол IP, чтобы исправить в нем существующие недостатки и добавить новые возможности.
Там есть ответы на большинство вопросов, которые тут задают в комментариях. И почему именно 128 бит, и почему 64 бита на сеть, и почему IPv6 не совместим с протоколом IPv4, и даже почему именно так щедро в настоящее время распределяются адреса IPv6.
Не стоит недооценивать протокол IPv6. Кроме того, что его достаточно хорошо проработали и сделали таким каким он сейчас, учитывайте, что практически всё современное железо так или иначе может работать с этим протоколом. Да, потребности массовой пока нет, поэтому возможности железа ограничены. Но как только критическая масса наберётся и производители софта для железа увидят потребность, они наклепают вам всех необходимых возможностей, которые вам нужны и не нужны. С IPv4 также было. Софт в старых маршрутизаторах тоже был ограничен. Но когда маршрутизаторы стали требоваться почти всем, они обросли разухабистыми веб интерфейсами, где можно настроить кучу всего.
Сам протокол IPv6 по своей природе меньше грузит промежуточные узлы. Маршрутизаторам проще обрабатывать эти пакеты. Если вам нужно фильтровать пакеты, то нужно опять таки запоминать состояние. Но этого требует и NAT. Но при этом нам не нужно переписывать заголовки пакетов, а значит наш маршрутизатор будет меньше загружен при тех же самых возможностях, что есть в IPv4.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки.
Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме тех, что нужны для получения ответов. Получается та же схема, что и при работе NAT, только без NAT. Снаружи до вас не достучаться, но если вы откроете путь для себя изнутри, то пакеты до вас будут ходить. Вашему маршрутизатору не нужно хранить таблицу NAT (но при этом нужно всё так же хранить какие порты у вас активны) и модифицировать каждый пакет, который через него проходит. А уровень защиты получается на том же уровне.
Ну не такие уж и редкие. В России большинство сайтов не имеет IPv6. Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса! Но если у вас был доступен DNS64+NAT64, то вы вполне могли не заметить отсутствие IPv4 на вашей машине. Знаю только одно приложение, которое не умеет в IPv6 сеть - это Steam. Видимо у него внутри вшиты IP адреса серверов. Но и это лечится путём запуска NAT46 непосредственно на вашей машине.
А вообще слышал, что Европейские провайдеры уже строят свои сети только на основе IPv6. Но ведь клиенты будут недовольны, что у них доступа нет? А вот и нет. Используется технология MAP-T. При этом сеть провайдера полностью построена на IPv6. Весь пул адресов они выделяют для NAT64. Один IPv4 адрес они делят между несколькими абонентами. Каждому выделяется определённое количество портов. При чём связь используется статичная, т.е. не нужно сохранять даже состояния соединений. На клиентской же стороне маршрутизатор по классике даёт какую-то серую сеть, типа 192.168.1.0/24 или аналогичную. А все соединения с серверами IPv4 направляются не на обычный NAT, а NAT46, который использует только строго выделенный диапазон портов, который согласован с набором на NAT64 у провайдера. Т.е. схема получается почти аналогичная тому, что есть сейчас с IPv4, только трафик между маршрутизатором клиента и NAT провайдера теперь идёт по IPv6. К тому же теперь провайдерскому NAT не нужно следить за состоянием соединений, т.е. он становится менее требователен к железу. Нагрузка на этот NAT будет постепенно снижаться ввиду того, что больше ресурсов будет доступно по IPv6 напрямую.
/64 вполне обосновывается тем, что имея 64 бита можно вписать в адрес любой существующий MAC адрес и гарантированно получить уникальный адрес ни с кем не пересекающийся. В контексте серверов, это позволит сократить размер адреса благодаря тому что вторая часть будет состоять из нулей. А если ещё учесть сеть /48, которую вы можете легко получить, то можно получить очень короткий адрес.
NAT - это костыль, который был придуман для того, чтобы в сеть могли выйти те узлы, которые его не имели. В IPv6 тоже есть NAT и если вы желаете, то можете его использовать. К тому же NAT64 практически делает незаметным отсутствие IPv4 на машине, но за редким исключением, когда IPv4 адреса жёстко вшиты в программу. Но и для этого найдётся свой костыль в виде NAT46, который нужно установить на само устройство или ваш маршрутизатор (который, кстати говоря, уже занимается NAT44). И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой задачи предназначен.
Основная проблема внедрения IPv6 - это нежелание людей разбираться в новом протоколе. Даже если провайдер вам его предоставляет, можно столкнуться с ситуацией, когда IPv6 перестаёт работать. Домашние провайдеры (например, Ростелеком) отказываются чинить баги ссылаясь на то, что они этот протокол не поддерживают, но по факту предоставляют, т.к. это позволяет снизить нагрузку на перегруженный провайдерский NAT. Все эти проблемы не вина протокола, но при этом, конечно, отпугивает новичков.
Уже сейчас можно перевести сеть на IPv6 и спокойно жить. А чтобы получить доступ к ресурсам IPv4 использовать уже знакомый костыль -NAT. Только в отличие от провайдерского NAT для IPv4, нагрузка на этот NAT будет падать по мере внедрения IPv6 и, в теории, вообще необходимость в нём отпадёт.
По мне так более эффективными для курьеров будут правки OpenStreetMap. Там много что можно обозначить, дорисовать оптимальные пути и это будет максимально быстро доступно другим. Хотя не факт, что быстро... Ибо кроме сохранения данных их нужно уметь использовать, а значит нужны приложения и серверы, которые всё это будут готовить для использования, в том числе курьерами. Но то, что вы описали, однозначно, тоже может быть полезно... Но точно не для курьеров.
Возможно тестируют в европейской части России. На Урале и за ним даже на Ростелекоме работает. Какое-то неудачное время я выбрал для публикации... Обсуждение идёт не материала, а проблем :(
У меня была цель описать как я настраивал свой сервер в условиях ограничений на IPv6. Изначально вообще было непонятно как и что нужно настраивать.
Скрипт для настройки родился чуть раньше. Мне просто надоело руками генерировать ключи. Но потом оказалось, что и остальное тоже можно автоматизировать так или иначе.
За ссылку спасибо, обязательно посмотрю что там другие придумали.
В данный момент достаточно 2000::/3. Позже, когда начнут выделять диапазоны 4000:: и дальше, нужно будет переделывать. Впрочем, можно и сейчас указать ::/0, если желаете.
У меня тоже валяется. Но у неё срок вышел. И банковская карта из неё не вышла, ибо счёт вроде как и не открыли. Но позже выяснил, что в Сбербанке есть какой-то старый закрытый счёт привязанный именно к этой УЭК, который я так и не смог открыть.
Пользовался OsmAnd+, но она перестала обновляться и устанавливаться из Google Play. Проблема массовая, из-за неё слили рейтинг приложения.
Ну при установке Linux можно накосячить. Но, в основном, это от того, что ты плохо понимаешь что делаешь. В популярных дистрибутивах явно указывается что и куда ставить, в том числе и загрузчик. В установщика Windows такого выбора нет.
Я же уже написал, что две системы на одном диске - это наихудший вариант. Им я давно не пользуюсь. Но и с системами на разных дисках установщик Windows может накосячить и поставить загрузчик на другой диск, при этом не выделив пространства под загрузчик на том диске, куда ему сказали устанавливать систему.
Было дело :-D Держал Windows для World Of Tanks, но потом купил новый WiFi адаптер и оказалось, что Windows 8.1 в него не умеет, а Windows 10 не умеет нормально работать с графическим адаптером. Ноутбук, поэтому адаптер не заменишь. Так что Windows окончательно ушёл в прошлое вместе с Миром Танков. Пока была Windows на отдельном диске, настрадался. У меня и 8.1 до 10 сама по себе обновлялась ломая игру и откатываться приходилось по полной, потому что система после обычного отката на 8.1 начинала дико тормозить на HDD. Windows - боль!
Основная проблема - переустановка Windows при наличии дуалбута, да и вообще наличия других систем, которые отличны от Windows. Установщику Windows плевать что у вас там есть и он может поставить загрузочную запись туда, куда ему вздумается, даже если вы указали ему на какой диск ставить. У меня доходило до того, что диск с Windows никак нельзя было запустить без дополнительного диска. Загрузчик был установлен на раздел диска с Linux, а на диске с Windows 8.1 просто не было выделено места под загрузчик, хотя система заняла весь диск. Золотое правило - устанавливаешь Windows, отключи все лишние диски, иначе она их может испортить. В крайнем случае можно произвести начало установки через виртуальную машину, чтобы она видела только один диск, но это не спасёт, если у вас на этом диске есть ещё и Linux. В этом случае придётся вручную восстанавливать загрузчик Linux.
Если у вас Windows и Linux на одном диске, то придётся овладеть скилом восстановления загрузчика Linux. А ещё, могут не устанавливаться некоторые обновления на Windows и чтобы их поставить, нужно установить загрузчик Windows, установить обновления, восстановить загрузчик Linux.
P.S. И не забывайте страдать, если используете Windows!
Сложно жить по закону там, где законов нет. Если понадобится, то в суде найдётся эксперт, который даст нужно заключение. Если кто-то найдёт законный способ от чего-то отказаться, то будет создан новый закон, по которому законное право будет отобрано. Очередная Филькина грамота просто развязывает руки РКН, а тот уже выборочно будет её применять к тому, к кому надо. Тут даже обсуждать нечего.
Небольшой лайвхак как разгрузить NAT: нужно внедрить IPv6. Тогда огромный объём трафика, как минимум с Youtube, уйдёт с NAT на IPv6. А по сути надо стимулировать включать IPv6 на серверах и у клиентов. Это же позволит снизить нагрузку за провайдерский NAT и, в перспективе, полностью уйти от него. В текущих реалиях без IPv4 тяжело только с торрентами и всё, что на битторренте основано, потому что пиров мало или может совсем не быть. У Steam тоже были проблемы, но они решались костылём на клиентской машине. Т.е. вполне реально жить только на IPv6!!! Но вот для дома есть сложные случаи.
Можно и вообще построить сеть доступа только на IPv6, но это только если провайдер может позволить себе заказать свои CPE, например, с MAP-T. В РФ о таком пока не слышал, а в Европе и США уже есть. В РФ вообще всё глухо... мне доступно 1,5 провайдера, везде выдают IPv6 криво: Ростелеком режет в мою сторону все соединения и хоронит сквозную прозрачность, а Дом.ру, вроде, выдаёт только /64. А из сотовых первым был МТС, сейчас к нему подключился Мегафон. Про Мегафон точно могу сказать, что работает, сам пользуюсь.
Я тут так много участвовал в дискуссии на счёт протокола IPv6, что забыл одну важную деталь, которая касается посыла статьи! AWS начинает взимать плату за драгоценный ресурс, такой, как IPv4. Так что всего этого можно избежать просто заплатив за роскошь - возможность использовать IPv4. Т. е. если ваш ресурс для вас ценен, просто оплатите услугу и забейте на все сложности, которые могут возникнуть при переходе на IPv6.
И вот что мне показалось странным. Неужели Amazon не предоставляет услуги NAT64? По мне так это самый логичный вариант. Пользователи услуги будут пользоваться готовыми шлюзами в IPv4 сеть и получать все необходимые ресурсы, при этом почти не почувствуют отсутствие IPv4, кроме разве что того, что их сервисы недоступны через IPv4. DNS для этих нужд есть у Googe и Cloudflare, например. NAT64 со специально выделенным диапазоном 64:ff9b::/96 должен предоставить ваш провайдер. Очень странно, что Amazon так не делает. У кого есть возможность, проверьте, должно быть.
Да кто ж вам NAT запрещает то? Я бы, пожалуй, вашу задачу тоже бы с ходу решил через NAT. На устройствах пользователей основной IPv6 от провайдера. А на шлюзе маршрутизация нужных адресов в нужный туннель, на конце которого NAT с его собственной адресацией. При чём транслировать можно адреса 1:1, а значит даже состояние не нужно запоминать для соединений.
NAT плох там, где его рассматривают как средство обеспечения защиты сети, хотя он им не является. К тому же, повсеместное применение его приводит к неявному отказу от главного принципа Internet: сквозной прозрачности на сетевом уровне [RFC 2775], когда любой хост А может послать пакет IP любому хосту Б (где А может быть равно Б). В вашем варианте, кстати, сквозная прозрачность нарушена, так что почему бы в этом случае не использовать NAT как средство обхода проблемы.
Воспользуюсь вашим методом. А вы знаете, что в IPv4 используется ARP? Если ваше устройство не отвечает на ARP запросы, то оно не сможет работать, т.е. полной изоляции не получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке ARP. Так что срочно нужно отказаться от IPv4!
А если серьёзно, то никто не заставляет вас все ICMP направлять напрямую без какой-либо фильтрации на вашем брандмауэре. И есть вполне конкретные решения для защиты сети. Они другие, не такие как в IPv4. Но и протокол у нас другой, который учитывает ошибки в старом протоколе.
Вы явно недооцениваете инженеров, которые проектировали IPv6.
Цитата из книги «IPv6 для знатоков IPv4», Ярослав Тихий, 31 декабря 2013 г.:
Там есть ответы на большинство вопросов, которые тут задают в комментариях. И почему именно 128 бит, и почему 64 бита на сеть, и почему IPv6 не совместим с протоколом IPv4, и даже почему именно так щедро в настоящее время распределяются адреса IPv6.
Не стоит недооценивать протокол IPv6. Кроме того, что его достаточно хорошо проработали и сделали таким каким он сейчас, учитывайте, что практически всё современное железо так или иначе может работать с этим протоколом. Да, потребности массовой пока нет, поэтому возможности железа ограничены. Но как только критическая масса наберётся и производители софта для железа увидят потребность, они наклепают вам всех необходимых возможностей, которые вам нужны и не нужны. С IPv4 также было. Софт в старых маршрутизаторах тоже был ограничен. Но когда маршрутизаторы стали требоваться почти всем, они обросли разухабистыми веб интерфейсами, где можно настроить кучу всего.
Сам протокол IPv6 по своей природе меньше грузит промежуточные узлы. Маршрутизаторам проще обрабатывать эти пакеты. Если вам нужно фильтровать пакеты, то нужно опять таки запоминать состояние. Но этого требует и NAT. Но при этом нам не нужно переписывать заголовки пакетов, а значит наш маршрутизатор будет меньше загружен при тех же самых возможностях, что есть в IPv4.
Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме тех, что нужны для получения ответов. Получается та же схема, что и при работе NAT, только без NAT. Снаружи до вас не достучаться, но если вы откроете путь для себя изнутри, то пакеты до вас будут ходить. Вашему маршрутизатору не нужно хранить таблицу NAT (но при этом нужно всё так же хранить какие порты у вас активны) и модифицировать каждый пакет, который через него проходит. А уровень защиты получается на том же уровне.
Ну не такие уж и редкие. В России большинство сайтов не имеет IPv6. Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса! Но если у вас был доступен DNS64+NAT64, то вы вполне могли не заметить отсутствие IPv4 на вашей машине. Знаю только одно приложение, которое не умеет в IPv6 сеть - это Steam. Видимо у него внутри вшиты IP адреса серверов. Но и это лечится путём запуска NAT46 непосредственно на вашей машине.
А вообще слышал, что Европейские провайдеры уже строят свои сети только на основе IPv6. Но ведь клиенты будут недовольны, что у них доступа нет? А вот и нет. Используется технология MAP-T. При этом сеть провайдера полностью построена на IPv6. Весь пул адресов они выделяют для NAT64. Один IPv4 адрес они делят между несколькими абонентами. Каждому выделяется определённое количество портов. При чём связь используется статичная, т.е. не нужно сохранять даже состояния соединений. На клиентской же стороне маршрутизатор по классике даёт какую-то серую сеть, типа 192.168.1.0/24 или аналогичную. А все соединения с серверами IPv4 направляются не на обычный NAT, а NAT46, который использует только строго выделенный диапазон портов, который согласован с набором на NAT64 у провайдера. Т.е. схема получается почти аналогичная тому, что есть сейчас с IPv4, только трафик между маршрутизатором клиента и NAT провайдера теперь идёт по IPv6. К тому же теперь провайдерскому NAT не нужно следить за состоянием соединений, т.е. он становится менее требователен к железу. Нагрузка на этот NAT будет постепенно снижаться ввиду того, что больше ресурсов будет доступно по IPv6 напрямую.
/64 вполне обосновывается тем, что имея 64 бита можно вписать в адрес любой существующий MAC адрес и гарантированно получить уникальный адрес ни с кем не пересекающийся. В контексте серверов, это позволит сократить размер адреса благодаря тому что вторая часть будет состоять из нулей. А если ещё учесть сеть /48, которую вы можете легко получить, то можно получить очень короткий адрес.
NAT - это костыль, который был придуман для того, чтобы в сеть могли выйти те узлы, которые его не имели. В IPv6 тоже есть NAT и если вы желаете, то можете его использовать. К тому же NAT64 практически делает незаметным отсутствие IPv4 на машине, но за редким исключением, когда IPv4 адреса жёстко вшиты в программу. Но и для этого найдётся свой костыль в виде NAT46, который нужно установить на само устройство или ваш маршрутизатор (который, кстати говоря, уже занимается NAT44). И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой задачи предназначен.
Основная проблема внедрения IPv6 - это нежелание людей разбираться в новом протоколе. Даже если провайдер вам его предоставляет, можно столкнуться с ситуацией, когда IPv6 перестаёт работать. Домашние провайдеры (например, Ростелеком) отказываются чинить баги ссылаясь на то, что они этот протокол не поддерживают, но по факту предоставляют, т.к. это позволяет снизить нагрузку на перегруженный провайдерский NAT. Все эти проблемы не вина протокола, но при этом, конечно, отпугивает новичков.
Уже сейчас можно перевести сеть на IPv6 и спокойно жить. А чтобы получить доступ к ресурсам IPv4 использовать уже знакомый костыль -NAT. Только в отличие от провайдерского NAT для IPv4, нагрузка на этот NAT будет падать по мере внедрения IPv6 и, в теории, вообще необходимость в нём отпадёт.
По мне так более эффективными для курьеров будут правки OpenStreetMap. Там много что можно обозначить, дорисовать оптимальные пути и это будет максимально быстро доступно другим. Хотя не факт, что быстро... Ибо кроме сохранения данных их нужно уметь использовать, а значит нужны приложения и серверы, которые всё это будут готовить для использования, в том числе курьерами.
Но то, что вы описали, однозначно, тоже может быть полезно... Но точно не для курьеров.
Мне не на чем тестировать. У меня всё работает. Есть подозрение, что проблема связана с CGNAT.
Возможно тестируют в европейской части России. На Урале и за ним даже на Ростелекоме работает. Какое-то неудачное время я выбрал для публикации... Обсуждение идёт не материала, а проблем :(
У меня была цель описать как я настраивал свой сервер в условиях ограничений на IPv6. Изначально вообще было непонятно как и что нужно настраивать.
Скрипт для настройки родился чуть раньше. Мне просто надоело руками генерировать ключи. Но потом оказалось, что и остальное тоже можно автоматизировать так или иначе.
За ссылку спасибо, обязательно посмотрю что там другие придумали.
В данный момент достаточно 2000::/3. Позже, когда начнут выделять диапазоны 4000:: и дальше, нужно будет переделывать. Впрочем, можно и сейчас указать ::/0, если желаете.
Вы правы, недоглядел. Исправил.