Здравствуйте, ·, Вы писали:

·>Здравствуйте, netch80, Вы писали:

N>>>>Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF и аналогично уважаемых домашних организаций. TLDR: для отдельных взаимодействий запрашивается временный IP в дополнение к основному, генерируется случайно так, чтобы не совпал с выдаваемыми автоматом (то есть не соответствовал EUI-64 из MAC адреса). Живёт этот IP до закрытия последнего использующего его сокета (или аналога).
N>>·>Что-то не вижу в этом rfc твою интерпретацию. Читаем "Problem Statement": "Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier". Т.е. это не для обеспечения секретной передачи, а для сокрытия корреляций в сетевой активности.
N>>На каком потолке ты вынашел про "секретную передачу" и что это "моя интерпретация"?
·>Выделил болдом выше. нет, эти трое не предлагают, как ты заявляешь, обеспечивать некую безопасность в этом rfq.

Ещё раз задаю вопрос: где у меня про "секретную передачу" и что это "моя интерпретация"?

N>>·>Как я понял, по сути это как бы способ для замены NAT+DHCP, но только позволяет делать stateless реализацию на клиенте без какого участия роутера, делает ненужным и NAT, и DHCP.
N>>Во-первых, NAT ни при чём.
·>Временная часть адреса — это эквивалент внутренним, невидимым ipv4 адресам за натом.

А апельсин — эквивалент паровоза.

·> В ipv6 адреса целиком выставляются наружу и видны целиком всему миру. Поэтому их и предгалают рандомизировать, обеспечивая ту же невидимость.

N>>Во-вторых, заменой DHCP здесь служит SLAAC в целом. Только первичный адрес конструируется из MAC на основании префикса из router advertisement, который явно запрошен (если тот не успел случайно себя анонсировать именно в этот момент), а такие вот вторичные захватываются на основании описанного рандома и уже известного префикса.
·>Ну да. А суть этого rfq — замена DHCP+NAT таким образом, чтобы сохранять непрозрачность сетевой активности.

Что такое rfq?

И снова, NAT у них не участвует вообще как концепция.

N>>·>Для секретности есть IPSec, который поддерживается в ipv6 нативно, а не как нашлёпка в ipv4.
N>>1) Хватит ретранслировать бредовые сказочки образца 2000 года, это тогда почему-то некоторые утюги вещали то, что ты говоришь. IPSec в IPv4 и IPv6 отличается только деталями формата пакета, в остальном они идентичны.
N>>2) IPSec требует настройки на уровне всего хоста (граничного раутера) и работает хост-хост или сеть-сеть. Догадываешься, почему это так мало используется сейчас?
·>Я не об этом. А о том как обеспечивать безопасность на уровне IP.

А я о том, используется ли вообще безопасность на уровне всего IP (всех его взаимодействий хотя бы с конкретным другим IP). И нет, обычно это не делается (VPN не считаем, хотя transport mode IPSec это тоже VPN — VPN не сводится к такому IPSec).

N>>>>При этом никакого scope для того, чтобы через этот временный IP нельзя было достичь тех ресурсов, которые сидят на основном IP и ожидают поступающих соединений (или аналогов), не предполагается.
N>>·>Читаем вместе: "Temporary addresses are typically employed for initiating outgoing sessions". Причём тут "ожидают поступающих соединений"?? Читай 2й параграф секции 2.2 про incoming.
N>>(mode=Snape) Обычно рекомендуется не просто прочитать буквы написанного, а ещё и подумать над ним:
N>>1) Появление нового адреса на интерфейсе означает, что автоматически все слушающие сервисы, которые прибиндились на звезду, будут принимать и на этот адрес тоже.
·>Причём тут прибиндившееся сервисы??! Речь идёт о "initiating outgoing sessions"!

При том, что они с хорошей вероятностью присутствуют на таком хосте.
Я ж говорю, включайте думалку.

N>>И ни один существующий на сейчас стек не предполагает защиты от этого, и проблема в принципе не озвучена.
·>А она вообще есть? И причём тут этот rfq?

Да, проблема есть.
Повторяю вопрос, что такое rfq?

N>>2) Typically это не must и даже не should (согласно RFC2119). Это вообще, как они говорят, informational часть. А если посмотреть на практику, возьмём тот же SIP. Пусть мы создали такой IP и создаём звонок с него. В сигнализации будет участвовать этот IP? Если нет, то мы раскрыли основной. Если да, то мы уже должны принимать входящий поток на него.
·>Не понял. А на ipv4 за Натом кто куда будет соединяться?

IPv4 не влияет.
NAT — влияет, трансляцию во многих случаях надо открывать явно.