У меня у самого уже несколько лет работает бот на PHP для сайта. Но сам код кому-то показывать стыдно. Благо функций у бота немного. Но и без этого сложно в той лапше разбираться. Новый функционал ещё больше усложнит код. А чтобы переписать, нужна какая-то хорошая идея.
Уже которая статья про то ка сделать бота для телеграм и ни в одной нет примера как разбирать запросы оптимальнее. Бот для телеграм делается элементарно с помощью веб-сервера с поддержкой любого языка программирования. Хоть на C пишите. Проблема больше в разборе Update. Нужно как-то выделить нужные сообщения, исключить ненужные, проанализировать сообщения, предложить пользователю дополнить ответ и прочее. Об этом никто не пишет.
На VDS вообще не проблема. Ставишь certbot, выпускает сертификат через него и он сам обновляется. Можно ещё руками поставить acme.s, который поддерживает не только Let's Encrypt. Но со вторым надо руками добавлять задание в cron для автоматического обновления сертификатов.
На своём опыте убедился, что чат-боты бесполезны более, чем полностью. Они никогда не могут дать ответа на вопрос. Никогда не анализируют ответ, зато цепляются за ключевые слова и выдают ответ на вопрос, который они себе придумали. Кучу времени уходит на то, чтобы пробиться через тупого бота и выйти на оператора, который в течении пары минут сразу решает вопрос. А некоторые службы поддержки так забаррикадировались, что там не только боты тупые, но и сотрудники центра. Банально, меняли оборудование, снесли настройки VLAN. Для того, чтобы восстановить работоспособность сети может уйти несколько дней чтобы пробиться через оператора и адресовать запрос для работника, который выполнит несколько команд на новом оборудовании провайдера.
Для телеграм ботов есть такая приятная штука, как webhook. Для него достаточно обычного веб-сервера. При запросах пользователей просто отcылается https запрос по указанному URL. А дальше вы уже можете на любом языке программирования разобрать его и подготовить ответ. Т.е. бота можно даже не на VDS, а на виртуальном хостинге разместить где есть веб-сервер и нужный вам язык программирования. При использовании webhook пользователи получают ответ от бота максимально быстро, на сколько это может делать ваш сервер.
Буквально недавно вышел ролик про историю X11 - https://www.youtube.com/watch?v=k8PaxLYOYdo Не вдавался в подробности, но ролик заставляет формировать отношение, что X11 устарел и создаёт одни проблемы. Интересно было бы узнать правда ли рассказана в ролике и, если нет, то можно даже статью на Хабр написать.
Подтверждаю. Больше 20 лет писал на PHP. Первому моему сайту уже 21 год стукнуло. И всё время был на нативном PHP. Постепенно из проектов пришлось вытаскивать куски и делать своё подобие фреймворка. С каждой новой версией постоянно что-то ломал, переделывал. Приходилось попутно менять и свои сайты на нём. В конце концов задумался, что надо с этим что-то делать. Решил копнуть Symfony. Со скрипом попробовал запустить некоторые страницы своего первого сайта. Показалось очень медленно. Но потом, покопавшись в документации, нашёл как собирать проект под prod. И оказалось, Symfony быстрее того, что я за все эти годы нагородил :-D Да, не совсем честно, потому что в моём коде нужно только оптимизировать автозагрузку и никакого файлового кэша... Но кого это сейчас волнует! Кэш соберётся при деплое. К тому же теперь есть относительно чёткая структура проекта (к которой надо постепенно привыкать, а не городить что попало). Единственное, что стало заметно хуже - взаимодействие с БД. Я постоянно пользовался PostgreSQL. В Doctrine это конечно всё работает. Но если по всем правилам создавать сущности для каждой таблицы, то задолбаешься их настраивать. При создании миграции Doctrine делает какую-то дичь, например, удаляет хорошо названные индексы, которую создал сам PostgreSQL и делает свой такой же с названием, не говорящим человеку ничего. Все миграции надо руками переписывать. Но я только в начале пути, как-нибудь разберусь. И да. если кто хочет сравнить какой код работает быстрее, нативный или Symfony, то tavda.info написан на symfony, а old.tavda.info написан на чистом PHP. Только сильно сервер не бомбите :-D Там слабая машина, на наплыв пользователей не рассчитана.
Ну так и IPv4 адресов почти в 2 раза меньше, чем населения на планете. А мы ещё хотим устройства подключать разные. А вот в IPv6 совсем другой расклад. Там даже если весь 2000::/4 раздать, то каждому жителю земли достанется больше 2000 сетей /48. Даже если население земли вырастет в 2000 раз... всё равно каждому достанется по одной сети /48. Но это будет наименьшая проблема при таком перенаселении.
А как вы используете/планируете использовать ещё 254 сети?
Я всё пытаюсь понять, в чем польза от выделения домохозяйствам чего-то большего, чем /60 , если оно никак не может быть использовано?
Ну мало ли что будет в будущем. Может появятся сети различные, одна на Matter для умного дома, другая Bluetooth нового поколения. и всем им надо будет отдельные префиксы. И они могут быть вложенными, т.е. одной сети, например, Matter может не хватить.
А выделение /48 сетей на пользователя, а точнее на подключение, исходит для того, чтобы более равномерно распределить пользователей по всей адресации, чтобы не столкнуться с такой же проблемой, когда IPv4 адресов стало не хватать и пришлось нашинковывать мелкие сети. А эти сети все должны быть в таблице маршрутизации снижая эффективность маршрутизации. Когда мы делаем такой запас, мы заботимся о будущем. Ну не понадобится подобное, примут новые правила распределения адресного пространства, более эффективное для 4000::/4, чем было в 2000::/3.
Если хотите аналогию, то представьте,что у нас есть поезд огромный из кучи вагонов, но билеты продают только в первые два, чисто для экономии пространства остальных вагонов. А потом кто-то из пассажиров решил взять с собой друга, но друга поселяют уже в другом купе или даже вагоне, потому что рядом с вами уже всё занято. Логичнее равномерно распределить пассажиров по всему составу, чем заставлять их набиваться в одном месте, всё равно он поедет весь.
/56 с динамическим префиксом не так уж и плохо, потому что это легко переделать. Если только провайдер не запросил сеть маленького размера ввиду того, что изначально планировал раздавать /56. Но и тут спасут уровни выше, которые могли резервировать сеть побольше для этого провайдера, на случай, если захотят расширяться.
Я привёл пример, когда один из клиентов сети - другой маршрутизатор, запросил у головного отдельный префикс, чтобы раздать своим клиентам. По сути WiFi на нём стал WAN портом. В этом случае я именно задействовал вторую из выделенных мне сетей, т.е. 2/256.
Зачем ещё какому-то клиенту может потребоваться использовать другой префикс, кроме как раздать его в другой сети? На OpenWRT нужный префикс можно запросить через DHCPv6.
У меня IPv6 от Ростелеком. В качестве маршрутизатора устройство на OpenWRT. Оно вполне способно выделить нужный префикс из имеющегося /56. Например, была необходимость подключить устройство. которое не ловило WiFi нормально. Зато полуживой маршрутизатор D-link это делал отлично. Я его подключил в качестве клиента по WiFi. Маршрутизатор запросил себе префикс /64 и раздал его клиентам по проводу. Подключив к маршрутизатору устройство я получил полноценный доступ в интернет по IPv6. По IPv4 интернет тоже работал через костыль NAT64 на основном маршрутизаторе. DNS64 тоже на нём настроен и любая внутренняя сеть может работать полностью на IPv6 без IPv4.
Для мобильного точно нельзя выделять /64, так как к нему может быть подключен компьютер.
Кстати, интересный вопрос. Теоретически Android должен получить префикс от провайдера, чтобы использовать его в той сети, которую раздаёт. Так он легко сможет дать отдельную сеть для USB подключения и для WiFi отдельную. При этом никакого NAT не нужно будет в силу того, что у нас есть несколько сетей /64 полноценных. Кто знает, умеет Android в такое? А iOS?
А если по запросу выдаётся /56 - все не так и плохо?
Даже если выделяется /56, должны резервировать /48, на будущее. Гораздо проще потом задействовать то, что не используется, чем потом выдавать вторую сеть тому, кому не хватило. Да и адрес сервера, если тебе выделили /48 смотрится гораздо лучше, например так 2001:db8:12ac::1. Но экономят обычно именно раздавая одну /48 своим клиентам по /64, например, адрес сервера будет таким 2001:db8:12ac:31::1. Тут даже просто дать дополнительную сеть /64 нельзя, потому что этот диапазон будет занят другим клиентом.
С домохозяйтвами попроще, потому что, скорее всего, всё выдаётся динамически. Сегодня выдавали /64, завтра выдают /56. Потенциально две проблемы. Во-первых, возможно провайдер запросил префикс недостаточного объёма и если под него не зарезервировали пространство, то придётся опять нашинковывать адресацию. Во-вторых, если рядом с вами на /64 сидит кто-то ещё чревато потенциальной проблемой, что из-за соседа могут забанить всю сеть /56, а то и /48 на каком-нибудь сервисе, например, если у соседа заражённый компьютер и он атакует этот сервис.
В IPv6, кстати, даже устройства в такой схеме могут общаться через маршрутизатор. А могут общаться напрямую, если у них адреса из публичные из разных сетей. Тоже тема для статьи о маршрутизации в сетях IPv6. Есть интересные вещи, которых в IPv4 не было.
Если протокол обнаружения соседей NDP работает в вашей сети нормально, то узлы будут общаться напрямую. Если сломаете или ограничите, то они могут воспользоваться услугами маршрутизатора, если, конечно, смогут. P.S. Я упоминал, что в заметке речь только об unicast адресах.
Даже это мелкое изменение требует изменения ПО на ВСЁМ парке устройств. Ваше изменение делает протокол не совместимым с IPv4. К тому же вы не так много добавили в адрес и с нехваткой адресов можно вновь столкнуться очень быстро. Опять таки, адреса раздаются иерархично. Допустим мы решили проблему с обновлением ПО, чтобы оно стало поддерживать наш новый протокол (кстати, для IPv6 до большинства относительно современных устройств она уже решена). Этого одного байт недостаточно, чтобы распределить блоки между LIR, RIR и прочими. Опять придётся нашинковывать адресацию, как сейчас это обстоит в IPv4. Проходим весть тот же процесс с обновлением ПО, но толком так и не решаем проблему с адресным пространством, все косяки протокола тянем за собой, ещё и имеем новую адресацию, которую тоже как-то надо совмещать со старой на время перехода, да и все проблемы IPv4 тянем за собой... Великолепный план, отличный, как Швейцарские часы!
Большинство вообще может не столкнуться с необходимостью где-то водить IPv6 адрес. Многие и без ввода IPv4 обходятся. При этом чтобы сеть IPv4 сама настроилась, нужен DHCP сервер. Если он по какой-то причине не работает или отсутствует, то мы вынуждены вводить руками IPv4 адрес устройства, IPv4 адрес маршрутизатора в качестве шлюза, маску сети, адреса DNS серверов. В IPv6 всё это предоставляет маршрутизатор с помощью анонса. Как пользователь, максимум, что вы можете сделать, выбрать адресацию для своей сети из fd00::/8. Если использовать DHCPv6, можно дать важным устройствам постоянный короткий IPv6 адрес. Например, адрес маршрутизатора может стать равным fd33::1. Т. е. команда ping будет выглядеть так: `ping fd33::1`. Тяжело запомнить?
А вообще, нормальный маршрутизатор предоставит вам услуги DNS. И, например, дома я спокойно могу войти по IPv6 на свой «сервер умного дома» на Raspberry Pi с помощью команды ssh raxxla. Мой DNS на маршрутизаторе автоматом добавит мой домен, например, raxxla.example.org, найдёт этот адрес во внутренних записях и вернёт внутренний адрес IPv6. Я даже один раз забыл адрес этого сервера, просто потому что давно им не пользовался. Зайдя по доменному имени (его я использую постоянно) спокойно посмотрел.
Кроме полноценного DNS есть ещё LLMNR и mDNS. Их тоже, при необходимости можно включить и настроить, и надобности в прямом указании IPv6 не будет.
По большей части, прямое указание IPv6 адресов требуется только тем, кто занимается настройкой сети или устранением неисправности. Как правило, эти люди отлично себе представляют что такое шестнадцатеричная система счисления. Так что «неудобство» записи IPv6 сильно преувеличено. Их практически не нужно запоминать и писать руками в большинстве случаев.
Предыстория про нехватку неотъемлемая часть повествования, чтобы сразу отсечь вопросы «почему бы просто инженерам не добавить дополнительных бит в адрес». До сих пор есть те, кто думает, что можно был ничего не ломая просто добавить и больше ничего не делать. Именно так поступили разработчики, но поняли, что дополнительные биты просто некуда разместить не потеряв совместимость. А если теряется совместимость, то зачем тащить за собой ворох старых проблем?
Я особо не заметил недостатков IPv6, кроме того, что заголовка IP вырос с минимальных 20 байт до 40. Зато он стал постоянного размера. Так что разница может быть заметна только на пакетах очень маленького объёма, если вообще будет заметна. Есть не всегда полноценная поддержка протокола в софте. Но это не проблема самого протокола, это проблема ПО конкретного железа. Чтобы осветить это в статье, нужно попробовать много разного железа. У меня этот набор ограниченный. Большая часть железа IPv6 протокол поддерживает. Я даже ради эксперимента переводил свою домашнюю сеть только на IPv6 и спокойно пользовался всем необходимым. Для Steam и торрентов пришлось поставить clatd, но это из-за того, что они напрямую работают с IPv4 адресами и не пользуются DNS. Ну и в торрентах чаще попадаются пиры только с IPv4, но и с IPv6 тоже не мало. Пока IPv4 доминирует в рунете, поэтому смысла полностью уходить на IPv6 пока нет, проще пользоваться дома дуалстэком. Но если его доля IPv4 заметно упадёт, то вполне возможно задействовать и вариант с NAT64+DNS64.
Если включить прокси, то у адреса будут A и AAAA записи. При этом можно проксировать хоть на IPv4 адрес, хоть на IPv6.
У меня у самого уже несколько лет работает бот на PHP для сайта. Но сам код кому-то показывать стыдно. Благо функций у бота немного. Но и без этого сложно в той лапше разбираться. Новый функционал ещё больше усложнит код. А чтобы переписать, нужна какая-то хорошая идея.
Уже которая статья про то ка сделать бота для телеграм и ни в одной нет примера как разбирать запросы оптимальнее. Бот для телеграм делается элементарно с помощью веб-сервера с поддержкой любого языка программирования. Хоть на C пишите. Проблема больше в разборе Update. Нужно как-то выделить нужные сообщения, исключить ненужные, проанализировать сообщения, предложить пользователю дополнить ответ и прочее. Об этом никто не пишет.
На VDS вообще не проблема. Ставишь certbot, выпускает сертификат через него и он сам обновляется. Можно ещё руками поставить acme.s, который поддерживает не только Let's Encrypt. Но со вторым надо руками добавлять задание в cron для автоматического обновления сертификатов.
На одной чаше весов - стабильная работа, на другой - слитые в интернет персональные данные клиентов банка.
На своём опыте убедился, что чат-боты бесполезны более, чем полностью. Они никогда не могут дать ответа на вопрос. Никогда не анализируют ответ, зато цепляются за ключевые слова и выдают ответ на вопрос, который они себе придумали. Кучу времени уходит на то, чтобы пробиться через тупого бота и выйти на оператора, который в течении пары минут сразу решает вопрос.
А некоторые службы поддержки так забаррикадировались, что там не только боты тупые, но и сотрудники центра. Банально, меняли оборудование, снесли настройки VLAN. Для того, чтобы восстановить работоспособность сети может уйти несколько дней чтобы пробиться через оператора и адресовать запрос для работника, который выполнит несколько команд на новом оборудовании провайдера.
Для телеграм ботов есть такая приятная штука, как webhook. Для него достаточно обычного веб-сервера. При запросах пользователей просто отcылается https запрос по указанному URL. А дальше вы уже можете на любом языке программирования разобрать его и подготовить ответ. Т.е. бота можно даже не на VDS, а на виртуальном хостинге разместить где есть веб-сервер и нужный вам язык программирования. При использовании webhook пользователи получают ответ от бота максимально быстро, на сколько это может делать ваш сервер.
Буквально недавно вышел ролик про историю X11 - https://www.youtube.com/watch?v=k8PaxLYOYdo
Не вдавался в подробности, но ролик заставляет формировать отношение, что X11 устарел и создаёт одни проблемы. Интересно было бы узнать правда ли рассказана в ролике и, если нет, то можно даже статью на Хабр написать.
Подтверждаю. Больше 20 лет писал на PHP. Первому моему сайту уже 21 год стукнуло. И всё время был на нативном PHP. Постепенно из проектов пришлось вытаскивать куски и делать своё подобие фреймворка. С каждой новой версией постоянно что-то ломал, переделывал. Приходилось попутно менять и свои сайты на нём. В конце концов задумался, что надо с этим что-то делать. Решил копнуть Symfony. Со скрипом попробовал запустить некоторые страницы своего первого сайта. Показалось очень медленно. Но потом, покопавшись в документации, нашёл как собирать проект под prod. И оказалось, Symfony быстрее того, что я за все эти годы нагородил :-D Да, не совсем честно, потому что в моём коде нужно только оптимизировать автозагрузку и никакого файлового кэша... Но кого это сейчас волнует! Кэш соберётся при деплое. К тому же теперь есть относительно чёткая структура проекта (к которой надо постепенно привыкать, а не городить что попало). Единственное, что стало заметно хуже - взаимодействие с БД. Я постоянно пользовался PostgreSQL. В Doctrine это конечно всё работает. Но если по всем правилам создавать сущности для каждой таблицы, то задолбаешься их настраивать. При создании миграции Doctrine делает какую-то дичь, например, удаляет хорошо названные индексы, которую создал сам PostgreSQL и делает свой такой же с названием, не говорящим человеку ничего. Все миграции надо руками переписывать. Но я только в начале пути, как-нибудь разберусь. И да. если кто хочет сравнить какой код работает быстрее, нативный или Symfony, то tavda.info написан на symfony, а old.tavda.info написан на чистом PHP. Только сильно сервер не бомбите :-D Там слабая машина, на наплыв пользователей не рассчитана.
А там есть ещё 3000::/4, 4000::/4... И так до e000::/4.
Ну так и IPv4 адресов почти в 2 раза меньше, чем населения на планете. А мы ещё хотим устройства подключать разные. А вот в IPv6 совсем другой расклад. Там даже если весь 2000::/4 раздать, то каждому жителю земли достанется больше 2000 сетей /48. Даже если население земли вырастет в 2000 раз... всё равно каждому достанется по одной сети /48. Но это будет наименьшая проблема при таком перенаселении.
Ну мало ли что будет в будущем. Может появятся сети различные, одна на Matter для умного дома, другая Bluetooth нового поколения. и всем им надо будет отдельные префиксы. И они могут быть вложенными, т.е. одной сети, например, Matter может не хватить.
А выделение /48 сетей на пользователя, а точнее на подключение, исходит для того, чтобы более равномерно распределить пользователей по всей адресации, чтобы не столкнуться с такой же проблемой, когда IPv4 адресов стало не хватать и пришлось нашинковывать мелкие сети. А эти сети все должны быть в таблице маршрутизации снижая эффективность маршрутизации. Когда мы делаем такой запас, мы заботимся о будущем. Ну не понадобится подобное, примут новые правила распределения адресного пространства, более эффективное для 4000::/4, чем было в 2000::/3.
Если хотите аналогию, то представьте,что у нас есть поезд огромный из кучи вагонов, но билеты продают только в первые два, чисто для экономии пространства остальных вагонов. А потом кто-то из пассажиров решил взять с собой друга, но друга поселяют уже в другом купе или даже вагоне, потому что рядом с вами уже всё занято. Логичнее равномерно распределить пассажиров по всему составу, чем заставлять их набиваться в одном месте, всё равно он поедет весь.
/56 с динамическим префиксом не так уж и плохо, потому что это легко переделать. Если только провайдер не запросил сеть маленького размера ввиду того, что изначально планировал раздавать /56. Но и тут спасут уровни выше, которые могли резервировать сеть побольше для этого провайдера, на случай, если захотят расширяться.
Я привёл пример, когда один из клиентов сети - другой маршрутизатор, запросил у головного отдельный префикс, чтобы раздать своим клиентам. По сути WiFi на нём стал WAN портом. В этом случае я именно задействовал вторую из выделенных мне сетей, т.е. 2/256.
Зачем ещё какому-то клиенту может потребоваться использовать другой префикс, кроме как раздать его в другой сети? На OpenWRT нужный префикс можно запросить через DHCPv6.
У меня IPv6 от Ростелеком. В качестве маршрутизатора устройство на OpenWRT. Оно вполне способно выделить нужный префикс из имеющегося /56. Например, была необходимость подключить устройство. которое не ловило WiFi нормально. Зато полуживой маршрутизатор D-link это делал отлично. Я его подключил в качестве клиента по WiFi. Маршрутизатор запросил себе префикс /64 и раздал его клиентам по проводу. Подключив к маршрутизатору устройство я получил полноценный доступ в интернет по IPv6. По IPv4 интернет тоже работал через костыль NAT64 на основном маршрутизаторе. DNS64 тоже на нём настроен и любая внутренняя сеть может работать полностью на IPv6 без IPv4.
Кстати, интересный вопрос. Теоретически Android должен получить префикс от провайдера, чтобы использовать его в той сети, которую раздаёт. Так он легко сможет дать отдельную сеть для USB подключения и для WiFi отдельную. При этом никакого NAT не нужно будет в силу того, что у нас есть несколько сетей /64 полноценных. Кто знает, умеет Android в такое? А iOS?
Даже если выделяется /56, должны резервировать /48, на будущее. Гораздо проще потом задействовать то, что не используется, чем потом выдавать вторую сеть тому, кому не хватило. Да и адрес сервера, если тебе выделили /48 смотрится гораздо лучше, например так 2001:db8:12ac::1. Но экономят обычно именно раздавая одну /48 своим клиентам по /64, например, адрес сервера будет таким 2001:db8:12ac:31::1. Тут даже просто дать дополнительную сеть /64 нельзя, потому что этот диапазон будет занят другим клиентом.
С домохозяйтвами попроще, потому что, скорее всего, всё выдаётся динамически. Сегодня выдавали /64, завтра выдают /56. Потенциально две проблемы. Во-первых, возможно провайдер запросил префикс недостаточного объёма и если под него не зарезервировали пространство, то придётся опять нашинковывать адресацию. Во-вторых, если рядом с вами на /64 сидит кто-то ещё чревато потенциальной проблемой, что из-за соседа могут забанить всю сеть /56, а то и /48 на каком-нибудь сервисе, например, если у соседа заражённый компьютер и он атакует этот сервис.
В IPv6, кстати, даже устройства в такой схеме могут общаться через маршрутизатор. А могут общаться напрямую, если у них адреса из публичные из разных сетей. Тоже тема для статьи о маршрутизации в сетях IPv6. Есть интересные вещи, которых в IPv4 не было.
Если протокол обнаружения соседей NDP работает в вашей сети нормально, то узлы будут общаться напрямую. Если сломаете или ограничите, то они могут воспользоваться услугами маршрутизатора, если, конечно, смогут.
P.S. Я упоминал, что в заметке речь только об unicast адресах.
Даже это мелкое изменение требует изменения ПО на ВСЁМ парке устройств. Ваше изменение делает протокол не совместимым с IPv4. К тому же вы не так много добавили в адрес и с нехваткой адресов можно вновь столкнуться очень быстро. Опять таки, адреса раздаются иерархично. Допустим мы решили проблему с обновлением ПО, чтобы оно стало поддерживать наш новый протокол (кстати, для IPv6 до большинства относительно современных устройств она уже решена). Этого одного байт недостаточно, чтобы распределить блоки между LIR, RIR и прочими. Опять придётся нашинковывать адресацию, как сейчас это обстоит в IPv4. Проходим весть тот же процесс с обновлением ПО, но толком так и не решаем проблему с адресным пространством, все косяки протокола тянем за собой, ещё и имеем новую адресацию, которую тоже как-то надо совмещать со старой на время перехода, да и все проблемы IPv4 тянем за собой... Великолепный план, отличный, как Швейцарские часы!
Большинство вообще может не столкнуться с необходимостью где-то водить IPv6 адрес. Многие и без ввода IPv4 обходятся. При этом чтобы сеть IPv4 сама настроилась, нужен DHCP сервер. Если он по какой-то причине не работает или отсутствует, то мы вынуждены вводить руками IPv4 адрес устройства, IPv4 адрес маршрутизатора в качестве шлюза, маску сети, адреса DNS серверов. В IPv6 всё это предоставляет маршрутизатор с помощью анонса. Как пользователь, максимум, что вы можете сделать, выбрать адресацию для своей сети из fd00::/8. Если использовать DHCPv6, можно дать важным устройствам постоянный короткий IPv6 адрес. Например, адрес маршрутизатора может стать равным
fd33::1. Т. е. команда ping будет выглядеть так: `ping fd33::1`. Тяжело запомнить?А вообще, нормальный маршрутизатор предоставит вам услуги DNS. И, например, дома я спокойно могу войти по IPv6 на свой «сервер умного дома» на Raspberry Pi с помощью команды ssh raxxla. Мой DNS на маршрутизаторе автоматом добавит мой домен, например, raxxla.example.org, найдёт этот адрес во внутренних записях и вернёт внутренний адрес IPv6. Я даже один раз забыл адрес этого сервера, просто потому что давно им не пользовался. Зайдя по доменному имени (его я использую постоянно) спокойно посмотрел.
Кроме полноценного DNS есть ещё LLMNR и mDNS. Их тоже, при необходимости можно включить и настроить, и надобности в прямом указании IPv6 не будет.
По большей части, прямое указание IPv6 адресов требуется только тем, кто занимается настройкой сети или устранением неисправности. Как правило, эти люди отлично себе представляют что такое шестнадцатеричная система счисления. Так что «неудобство» записи IPv6 сильно преувеличено. Их практически не нужно запоминать и писать руками в большинстве случаев.
Предыстория про нехватку неотъемлемая часть повествования, чтобы сразу отсечь вопросы «почему бы просто инженерам не добавить дополнительных бит в адрес». До сих пор есть те, кто думает, что можно был ничего не ломая просто добавить и больше ничего не делать. Именно так поступили разработчики, но поняли, что дополнительные биты просто некуда разместить не потеряв совместимость. А если теряется совместимость, то зачем тащить за собой ворох старых проблем?
Я особо не заметил недостатков IPv6, кроме того, что заголовка IP вырос с минимальных 20 байт до 40. Зато он стал постоянного размера. Так что разница может быть заметна только на пакетах очень маленького объёма, если вообще будет заметна. Есть не всегда полноценная поддержка протокола в софте. Но это не проблема самого протокола, это проблема ПО конкретного железа. Чтобы осветить это в статье, нужно попробовать много разного железа. У меня этот набор ограниченный. Большая часть железа IPv6 протокол поддерживает. Я даже ради эксперимента переводил свою домашнюю сеть только на IPv6 и спокойно пользовался всем необходимым. Для Steam и торрентов пришлось поставить clatd, но это из-за того, что они напрямую работают с IPv4 адресами и не пользуются DNS. Ну и в торрентах чаще попадаются пиры только с IPv4, но и с IPv6 тоже не мало. Пока IPv4 доминирует в рунете, поэтому смысла полностью уходить на IPv6 пока нет, проще пользоваться дома дуалстэком. Но если его доля IPv4 заметно упадёт, то вполне возможно задействовать и вариант с NAT64+DNS64.