Ещё есть всякие трюки, которые заставляют ALG работать не так, как задумано. Например, можно заставить пользовательский браузер отправить HTTP-запрос, который ALG ошибочно посчитает DCC-соединением между IRC-клиентами. И дырявые реализации UPnP, подверженные не только CSRF, но и просто выполняющие запросы, пришедшие снаружи, тоже встречаются в домашних роутерах.
Конечно. Но и WannaCry будет долго перебирать /64, чтобы случайно дойти до десктопа, который находится в сети, на границе которой почему-то не включили фаервол.
IPv6 существует тоже достаточно давно. Просто пугающая плашка «небезопасное соединение!» и снижение позиций в поисковых выдачах действуют сильнее, чем невозможность посмотреть на анимированную черепашку и раскрашенный четвёртый эпизод звёздных воин. Профит от https тоже многим неочевиден.
Такой пакет может отправить из соседнего порта коммутатора, если провайдер не спускает по VLAN на каждого абонента. Или врезаться в провод и временно самому стать интернет-провайдером.
Домохозяйка готова менять роутеры быстрее, чем датацентры, её проще мотивировать. В домашних роутерах как правило есть и wi-fi, поэтому достаточно соседу поставить ещё более мощный генератор помех, и сервисам потокового видео поднять качество, и вот всё начинает совсем плохо работать, и пора идти в магазин за новым.
Пока не внедрён DNS SRV, можно использовать DNS AAAA. С IPv4 так не получится, потому что столько адресов за разумные деньги никто домой не даст.
Проброс ещё неудобен тем, что когда транзитных узлов несколько (роутер-десктоп-виртуалка), то нужно либо настраивать делегацию внутренних IPv4-сетей, либо пробрасывать порты по цепочке. А в IPv6 можно тупо свалить всё в один бридж LAN (где домашняя /64), и оно будет работать.
Порты очень уж неудобно пробрасывать. Приходится запоминать, что 2200 — это роутер, 2201 — NAS, а 2202 — десктоп. А в другой сети порты выделены по-другому. А потом на десктопе появляются контейнеры с виртуалками, и схема становится ещё сложнее. Скорее бы DNS SRV всюду заработал.
Вы предлагаете изменить протокол IP так, чтобы он оперировал человекочитаемыми именами вместо адресов? И использовать эти имена вместо адресов для того, чтобы принимать решения о маршрутизации?
А как сделать так, чтобы было сильно удобнее, а не чуть? Если вообразить, что у вас есть возможность щелчком пальцев задеплоить любой выдуманный вами протокол на все устройства мира, и одним махом переписать весь легаси-код на его использование.
Кейс становится гораздо менее специфичным, если заменить выключатель на смартфон.
Вы справедливо заметили, что relay через облако решает проблему, но такой подход обладает по крайней мере следующими недостатками:
1. Проблема с приватностью. Зачем внешнему сервису знать о каждом моём нажатии на выключатель?
2. Такой подход подталкивает неопытного разработчика к неправильному подходу при проектировании, когда и лампочка, и выключатель всецело доверяют сервису. Если сервис сказал лампочке «выключатель попросил тебя включить», то ей приходится верить ему.
3. Если сервис упал или даже перестал существовать, то у пользователя пропадает не только возможность менять конфигурации, но и использовать уже запрограммированное поведение в своём умном доме.
При наличии end-to-end связности между лампочками и выключателями таких проблем нет. В момент конфигурации лампочка может запомнить публичные ключи всех выключателей, которым позволено управление светом, а потом получать от них команды напрямую.
Поэтому на маршрутизаторе с другой стороны может быть фаервол.
И если единственный сервис, который биндится на IN[6]ADDR_ANY — это хорошо настроенный sshd, то почему бы и нет?
Если пофантазировать, что светлое будущее наступило, и везде внедрён IPv6, то будет достаточно купить даже неуправляемый (хотя уже и сейчас таких чипов-то и не делают) коммутатор, в любой порт вставить шнурок от провайдера, в любые другие порты вставить свои компьютеры.
То же самое при адекватном провайдере — купил, пришёл, воткнул — работает.
Не знаю сценария DreamingKitten, но мне удонбо делать ssh hostname на внутренние удалённые узлы, ничего не настраивая, кроме, возможно, фаервола на той стороне. Увы, SSH, в отличии от HTTP, не умеет virtual host.
С каких пор наличие MUST в стандарте начало останавливать людей от публикации и продажи недоделок?
С тем же успехом можно продавать коробку с антенной без беспроводного модуля внутри. Или корпус от жёсткого диска с гайками для веса. Это не будет IPv6-роутером, а попытка об этом заявить потребителю станет обманом.
Тогда производитель будет вынужден написать, что у него почти IPv6-соместимый роутер, что уже не столь привлекательно выглядит.
Такое уже есть в NAT64. Поднимаем транслятор на /96 префиксе и получаем возможность ходить на 64:ff9b::192.168.0.1 (в канонической форме — 64:ff9b::c0a8:1). Останется только переписать весь софт, у которого IPv4 прибит гвоздями и рядом с транслятором поселить пачку костылей для тех протоколов, у которых IP-адреса утекают на верхние уровни ((T)FTP, SIP, RTSP, PPTP, L2TP и прочие).
Всё то же самое, что и с IPv4 — закрыться фаерволом на границе сетей.
Проброс ещё неудобен тем, что когда транзитных узлов несколько (роутер-десктоп-виртуалка), то нужно либо настраивать делегацию внутренних IPv4-сетей, либо пробрасывать порты по цепочке. А в IPv6 можно тупо свалить всё в один бридж LAN (где домашняя /64), и оно будет работать.
Запоминать их совсем не обязательно, например NAT64 обычно поднимают в паре с DNS64, чтобы github.com резолвился в 64:ff9b::8c52:7603.
Вы справедливо заметили, что relay через облако решает проблему, но такой подход обладает по крайней мере следующими недостатками:
1. Проблема с приватностью. Зачем внешнему сервису знать о каждом моём нажатии на выключатель?
2. Такой подход подталкивает неопытного разработчика к неправильному подходу при проектировании, когда и лампочка, и выключатель всецело доверяют сервису. Если сервис сказал лампочке «выключатель попросил тебя включить», то ей приходится верить ему.
3. Если сервис упал или даже перестал существовать, то у пользователя пропадает не только возможность менять конфигурации, но и использовать уже запрограммированное поведение в своём умном доме.
При наличии end-to-end связности между лампочками и выключателями таких проблем нет. В момент конфигурации лампочка может запомнить публичные ключи всех выключателей, которым позволено управление светом, а потом получать от них команды напрямую.
И если единственный сервис, который биндится на IN[6]ADDR_ANY — это хорошо настроенный sshd, то почему бы и нет?
То же самое при адекватном провайдере — купил, пришёл, воткнул — работает.
Не знаю сценария DreamingKitten, но мне удонбо делать
ssh hostnameна внутренние удалённые узлы, ничего не настраивая, кроме, возможно, фаервола на той стороне. Увы, SSH, в отличии от HTTP, не умеет virtual host.Это сломает TCP в текущем виде. Но можно пытаться это исправить с помощью SCTP и MPTCP.
С тем же успехом можно продавать коробку с антенной без беспроводного модуля внутри. Или корпус от жёсткого диска с гайками для веса. Это не будет IPv6-роутером, а попытка об этом заявить потребителю станет обманом.
Тогда производитель будет вынужден написать, что у него почти IPv6-соместимый роутер, что уже не столь привлекательно выглядит.