Если бы mIPv6 сделали обязательной частью реализации IPv6, то этой проблемы бы не было. Но это бы заятнуло внедрение ещё сильнее. Примерно то же самое с IPsec.
Та же проблема существует и с IPv4. И решения примерно те же.
А какое решение бы вы предложили для реализации роуминга?
Дело тут совсем не в IPv6. Контролировать его получается хуже по двум причинам:
1. Персонал не обучен этому.
2. IPv6 не внедрён посвеместно, поэтому желающие его использовать прибегают к куче различных костылей (различные способы энкапсуляции IPv6 внутрь IPv4), каждый из которых требует отдельного подхода для контроля. В IPv4 проблемы ровно те же — пользователи могут натянуть оверлейную сеть поверх контролируемой и получить «децентрализованный интернет» (всякие TOR, I2P и cjdns это успешно делают). Просто с IPv6 появляется дополнительный стимул эти костыли использовать, вот и вся разница.
Чтобы выключатель смог сходить в облачный сервис для конфигурации умного дома, зарегистрировать себя, потом узнать своё предназначение (например, управление лампочкой), узнать адрес лампочки и дальше ходить в лампочку напрямую.
Если добавить в эту схему пару NATов (скажем, один в wi-fi роутере пользователя, другой у мобильного оператора), то реализовать её будет гораздо сложнее — придётся сооружать relay на стороне сервиса. А когда все находятся в одном общем 128-битном адресном пространстве, end-to-end connectivity обеспечивать гораздо проще.
Только если у него вместе с NAT есть ещё и правильно настроенный фаервол. Иначе ничто не помешает злоумышленнику-соседу сделать ip route add $iot_lamp via $home_user_router и настроить свой TCP/IP стек так, чтобы он не удивлялся работе SNAT на стороне $home_user_router.
Она позволяет экономить ресурсы. От маршрутизаторов всё равно отказаться не получится, а вот под балансировщики нагрузки надо выделить ресурсы, и ещё решить задачу их отказоустойчивости.
В крупном сервисе, у которого одна машина не сможет обработать весь поток входящих в одну точку запросов от балансировщика отказаться не получится. Но у типичного хостинга есть куча мелких клиентов, и целая пачка сайтов влезает на одну машину. В таком случае можно анонсировать адрес сайта, крутящегося на этой машине наружу, и тогда трафик будет сразу приходить на неё.
Если не рассматривать хостинги, а ограничиться домашними пользователями, то возможность повесить по адресу на каждое своё устройство позволит избавиться от целой кучи костылей в виде ALG и обеспечить хорошо работающую end-to-end связность, что может быть полезно для IoT (не той домашней автоматизации, что сейчас, когда устройства разговаривают с единым центром, а именно интернета, когда устройства разговаривают друг с другом).
Давайте попробуем рассмотреть ВК, как альтернативу e-mail+XMPP, содержащую дополнительные возможности (музыка, стена, микробложик, фото и так далее).
Когда ВК только появлялся, для регистрации требовалась почта. Это означает, что у всех первых пользователей почта точно была, как и возможность писать друг другу e-mail. Почему они вдруг перестали для немгновенных сообщений вместо e-mail исползовать ВК?
До того, как эти люди начали пользоваться ВК, эти пользователи наверняка использовали какой-то сервис для мгновенных сообщений, например ICQ. Что заставило их использовать ВК вместо ICQ, где уже сидят все их друзья? Групповых чатов на тот момент в ВК не было.
В Telegram подавляющего большинства всех тех возможностей, которые вы перечислили, вообще нет. Но Telegram популярен.
Человек, который смог установить неофициальный клиент для ВК, наверняка сможет использовать ВК чисто для музыки, не завязывая своё общение на этом сервисе. Поэтому вряд ли это его удержит.
Резюмируя, я пытаюсь узнать, как именно начинается процесс подсаживания на эту иглу. Пока что на этот вопрос ответил Naves, но его ответ отличается от вашего — он объясняет причину качественным маркетингом.
Я не смогу отправить голубя с одной голубятни на другую, если они принадлежат разным «голубиным провайдерам». И будет такая же проблема, как с современными мессенджерами.
А XMPP и e-mail прекрасно ходят с одного сервера на другой, и у каждого есть возможность из своего сервера сделать третий.
Я как раз хочу свои примитивные представления развить и разобраться в причинах, поэтому задаю глупые вопросы.
У того поведения есть, которое вы описали, есть последствия. Вот человеку было наплевать на интероперабельность, и он начал пользоваться моднымсервисом1, потому что там были стикеры. Потом появился модныйсервис2, где сидит большая часть его друзей по какой-то причине (например, у них круче реклама и есть анимированные стикеры). Потом появляется модныйсервис3, где есть каналы-блоги. А потом модныйсервис4, и так далее. И если у человека работой не является сидеть в мессенджерах, то он невольно задумается, а нельзя ли перестать страдать от постоянного пересаживания с одного на другое, от необходимости держать полдесятка приложений на телефоне и переключения между ними, и начнёт искать способ починить проблему.
Да, мигрировать сложно. Я пока не вижу альтернативы тому пути, по которому мы уже идём. Пока на то, что вы предлагаете, уже написаны RFC для IPv6. В чём же тогда разница между IPv6 и IPv4++?
Конкретно эту проблему можно решить по-другому — законодательно запретить вмешиваться в трафик. То, что HTTPS позволяет от этого защититься является лишь приятным побочным эффектом. И работает это только за счёт массовости внедрения — если бы разработчики браузеров и поисковых систем не давили на вебмастеров, то такого массового распространения HTTPS бы не получил, а значит операторы смогли бы портить его там, где им хочется (за исключением какого-нибудь белого списка из банков и госсервисов, чтобы не распугать пользователей). А за счёт массовости они сделать так не могут, ведь слишком многое сломается.
Я это и пытался донести. Реальную ценность представляют только небольшие кусочки информации, передаваемые по HTTP — авторизационные и платёжные данные, коды целостности, прочие секреты.
Типичному сайту-визитке всё это не нужно, его задача — показать десяток картинок и пару страниц текста.
Однако кооперация определённых организаций привела к тому, что и такие сайты стали внедрять HTTPS. Вот точно так же можно и IPv6 пропихнуть в массы.
Я никаким образом не агитирую неиспользование HTTPS. Это как с полнодисковым шифрованием — лучше зашифровать всё, чем долго думать и делать это избирательно, ведь из-за одной маленькой ошибки в конфигурации шифрование может стать бесполезным.
А как транслировать адреса, если транзитные узлы могут не поддерживать IPv4++?
Например, у меня есть 128-битный адрес, и у вас тоже есть 128-битный адрес, но между нами есть провайдер, который умеет только 32-битные адреса.
В обратную сторону проблема уже хоть как-то решена в IPv6, есть NAT64 и DNS64 и даже 464XLAT.
Не получится изменить только длину адреса. Это сломает TCP, UDP (pseudoheaders), NAT, ALG, кучу протоколов (как раз тех, для которых нужен ALG). Вы предлагаете потратить кучу усилий, чтобы всё это починить, а потом, когда этот IPv4++ будет внедрён, начинать внедрять уже полноценный IPv6?
Маршрутов в IPv6 full view не будет больше после его «полного запуска», потому что об этом специально подумали. Например, в RIPE-707, разделе 3.4 Aggregation.
Телевизору нужен внешний адрес, чтобы ходить на внешние сервера, например за видео.
Если для видео будет использоваться RTSP, то понадобятся нетривиальные костыли (PAT, ALG) на том устройстве, которое делает NAT. Это усложняет отладку.
Наличие NAT не означает, что из внешней сети нельзя инициировать соединение с устройством внутри локальной сети за NATом. Чтобы защитить сеть, нужен именно фаервол, который будет разрешать инициировать соединения изнутри, но запрещать снаружи.
Та же проблема существует и с IPv4. И решения примерно те же.
А какое решение бы вы предложили для реализации роуминга?
1. Персонал не обучен этому.
2. IPv6 не внедрён посвеместно, поэтому желающие его использовать прибегают к куче различных костылей (различные способы энкапсуляции IPv6 внутрь IPv4), каждый из которых требует отдельного подхода для контроля. В IPv4 проблемы ровно те же — пользователи могут натянуть оверлейную сеть поверх контролируемой и получить «децентрализованный интернет» (всякие TOR, I2P и cjdns это успешно делают). Просто с IPv6 появляется дополнительный стимул эти костыли использовать, вот и вся разница.
Если добавить в эту схему пару NATов (скажем, один в wi-fi роутере пользователя, другой у мобильного оператора), то реализовать её будет гораздо сложнее — придётся сооружать relay на стороне сервиса. А когда все находятся в одном общем 128-битном адресном пространстве, end-to-end connectivity обеспечивать гораздо проще.
В крупном сервисе, у которого одна машина не сможет обработать весь поток входящих в одну точку запросов от балансировщика отказаться не получится. Но у типичного хостинга есть куча мелких клиентов, и целая пачка сайтов влезает на одну машину. В таком случае можно анонсировать адрес сайта, крутящегося на этой машине наружу, и тогда трафик будет сразу приходить на неё.
Если не рассматривать хостинги, а ограничиться домашними пользователями, то возможность повесить по адресу на каждое своё устройство позволит избавиться от целой кучи костылей в виде ALG и обеспечить хорошо работающую end-to-end связность, что может быть полезно для IoT (не той домашней автоматизации, что сейчас, когда устройства разговаривают с единым центром, а именно интернета, когда устройства разговаривают друг с другом).
Когда ВК только появлялся, для регистрации требовалась почта. Это означает, что у всех первых пользователей почта точно была, как и возможность писать друг другу e-mail. Почему они вдруг перестали для немгновенных сообщений вместо e-mail исползовать ВК?
До того, как эти люди начали пользоваться ВК, эти пользователи наверняка использовали какой-то сервис для мгновенных сообщений, например ICQ. Что заставило их использовать ВК вместо ICQ, где уже сидят все их друзья? Групповых чатов на тот момент в ВК не было.
В Telegram подавляющего большинства всех тех возможностей, которые вы перечислили, вообще нет. Но Telegram популярен.
Человек, который смог установить неофициальный клиент для ВК, наверняка сможет использовать ВК чисто для музыки, не завязывая своё общение на этом сервисе. Поэтому вряд ли это его удержит.
Резюмируя, я пытаюсь узнать, как именно начинается процесс подсаживания на эту иглу. Пока что на этот вопрос ответил Naves, но его ответ отличается от вашего — он объясняет причину качественным маркетингом.
А XMPP и e-mail прекрасно ходят с одного сервера на другой, и у каждого есть возможность из своего сервера сделать третий.
У того поведения есть, которое вы описали, есть последствия. Вот человеку было наплевать на интероперабельность, и он начал пользоваться моднымсервисом1, потому что там были стикеры. Потом появился модныйсервис2, где сидит большая часть его друзей по какой-то причине (например, у них круче реклама и есть анимированные стикеры). Потом появляется модныйсервис3, где есть каналы-блоги. А потом модныйсервис4, и так далее. И если у человека работой не является сидеть в мессенджерах, то он невольно задумается, а нельзя ли перестать страдать от постоянного пересаживания с одного на другое, от необходимости держать полдесятка приложений на телефоне и переключения между ними, и начнёт искать способ починить проблему.
Где я неправ?
Типичному сайту-визитке всё это не нужно, его задача — показать десяток картинок и пару страниц текста.
Однако кооперация определённых организаций привела к тому, что и такие сайты стали внедрять HTTPS. Вот точно так же можно и IPv6 пропихнуть в массы.
Я никаким образом не агитирую неиспользование HTTPS. Это как с полнодисковым шифрованием — лучше зашифровать всё, чем долго думать и делать это избирательно, ведь из-за одной маленькой ошибки в конфигурации шифрование может стать бесполезным.
Например, у меня есть 128-битный адрес, и у вас тоже есть 128-битный адрес, но между нами есть провайдер, который умеет только 32-битные адреса.
В обратную сторону проблема уже хоть как-то решена в IPv6, есть NAT64 и DNS64 и даже 464XLAT.
Если для видео будет использоваться RTSP, то понадобятся нетривиальные костыли (PAT, ALG) на том устройстве, которое делает NAT. Это усложняет отладку.