Кратко

  • Преемник временного адреса создаётся заранее: некоторое время интерфейс может одновременно держать стабильный адрес, предпочитаемый временный адрес и его новый временный преемник. Затем прежний адрес становится устаревшим для новых соединений, но ещё обслуживает уже открытые.
  • Стандарты 2001, 2007 и 2021 годов последовательно уточняли генерацию, настройку и сроки жизни. В действующем механизме рекомендуемый максимум валидности по умолчанию сокращён до двух суток, а предпочтительный срок по умолчанию остаётся равным суткам.
  • Ротация сокращает простую корреляцию по неизменному адресу источника, но не даёт анонимности, шифрования или аутентификации и не устраняет стабильные адреса, префиксы, учётные записи, журналы либо наблюдение на пути.

Представим не смену одной таблички другой, а короткое наложение состояний. На интерфейсе остаётся стабильный адрес. Для новых исходящих сеансов выбран временный. Ещё до конца его предпочтительного срока хост начинает готовить преемника, чтобы успеть сгенерировать его и проверить уникальность. В течение этого окна оба временных адреса существуют одновременно. Старый затем становится deprecated — устаревшим, — однако продолжает быть valid, то есть валидным. Уже установленные соединения не обязаны обрываться. Только по окончании валидного срока адрес становится invalid и больше не может использоваться ни как источник, ни как назначение.

Такое наложение показывает настоящую конструкцию механизма. Конфиденциальность создаёт не сама случайность битов, а управление жизненным циклом адреса, который обычно выбирается для новых исходящих обращений. Предпочитаемый адрес можно использовать без ограничений. Устаревший не следует выбирать для новых коммуникаций, но его сохранение защищает работающие сеансы от искусственного разрыва. Невалидный адрес покидает сетевую жизнь. Поэтому «устарел» и «перестал существовать» — разные события с разными последствиями.

2001 год: ограничить постоянство идентификатора

Первый стандарт этого ряда вышел в январе 2001 года. Его исходной проблемой был глобально уникальный, неизменный идентификатор интерфейса. Такой идентификатор позволял связывать транзакции, совершённые в разных контекстах. Ответом стали дополнительные глобальные адреса с меняющимися идентификаторами, предназначенные прежде всего для инициирования исходящих сеансов.

У механизма с самого начала была важная граница. Депрекация адреса не означала завершения соединения. Она прекращала его обычный выбор для новых коммуникаций, тогда как валидный срок оставлял уже начатым сеансам время для продолжения. Тем самым стандарт уменьшал период, в котором один IPv6-адрес служит простым ключом корреляции, но не утверждал, что меняет все наблюдаемые признаки хоста или приложения.

2007 год: больше точности и больше настроек

В сентябре 2007 года новая редакция заменила документ 2001 года. Базовый цикл сохранился, а правила вокруг него стали конкретнее. Проверка Duplicate Address Detection требовалась для каждого временного адреса. Использование можно было включать и выключать отдельно для каждого префикса. Для разных префиксов допускались разные идентификаторы интерфейса, а алгоритм случайной генерации больше не был привязан к MD5.

При этом временные адреса рекомендовалось по умолчанию отключать. Предпочтительный срок по умолчанию составлял одни сутки, валидный — одну неделю. Разрыв между ними нужен не для декоративного запаса: после первых суток адрес обычно переставал привлекать новые соединения, но мог поддерживать старые до полного истечения валидности.

Отсюда следует непривычная картина учёта. Несколько устаревших, но ещё валидных временных адресов могут сосуществовать, потому что связанные с ними коммуникации возникли в разное время. В нормальном режиме на одном интерфейсе для одного префикса имеется не более одного неустаревшего временного адреса — кроме короткого периода регенерации. Число адресов в снимке поэтому нельзя автоматически превращать в число устройств или пользователей.

2021 год: новый исходный выбор и более короткая валидность

В феврале 2021 года действующий стандарт заменил редакцию 2007 года. Он убрал рекомендацию отключать временные адреса по умолчанию. Он также потребовал, чтобы идентификаторы разных временных адресов одного хоста статистически различались, и перенёс вычисление десинхронизирующего фактора на каждый новый временный адрес. Такой фактор мешает множеству адресов вращаться по одному предсказуемому расписанию.

Предпочтительный срок по умолчанию остался равным суткам. Рекомендуемый максимальный валидный срок по умолчанию сократился с недели до двух суток. Но эти числа — параметры конфигурации, а не результаты наблюдения за всеми системами: пользователю должна быть доступна их настройка. Фактическое время дополнительно ограничивается сроком префикса из объявления маршрутизатора и корректируется индивидуальным DESYNC_FACTOR. По одному появлению адреса в журнале нельзя доказать, сколько именно он прожил.

Преемник начинает создаваться за интервал REGEN_ADVANCE до депрекации предшественника. Эта фора нужна, чтобы завершить генерацию и Duplicate Address Detection до потери предпочтительного состояния. Механизм тем самым избегает ложного выбора между приватностью и непрерывностью: новый идентификатор готов к исходящим соединениям, пока прежний ещё корректно обслуживает уже начатое.

Новая сеть должна получить новый идентификатор

Смена канала подключения имеет самостоятельный смысл для конфиденциальности. При переходе на новый линк хост должен удалить временные адреса старого линка и сгенерировать новые, чтобы один рандомизированный идентификатор не сопровождал его между сетями. Однако краткое падение и восстановление линка не следует безусловно считать сменой сети, если реализация умеет различать эти события.

Даже правильная смена временного идентификатора не стирает префикс. Постоянный или редкий префикс способен связывать активность, особенно если им пользуется мало хостов. На интерфейсе может одновременно сохраняться стабильный адрес. Действующий стандарт допускает и конфигурацию только с временными адресами, поэтому наличие стабильного адреса нельзя ни предполагать всегда, ни исключать без данных конкретного хоста.

За пределами обещания

Временные адреса не шифруют заголовки или содержимое пакетов. Они не аутентифицируют устройство либо человека и не дают анонимности. Учётная запись, cookie или поведение приложения могут связать сеансы независимо от адресной ротации. Анализ размеров и времени пакетов остаётся возможным. Сторона на локальном пути, например маршрутизатор по умолчанию, способна видеть набор адресов хоста. Получатель, перед которым пользователь вошёл в учётную запись, может связать этот временный адрес с вошедшим пользователем.

Серверные и сетевые журналы также не исчезают. Поэтому отдельный адрес источника не доказывает долговременную идентичность устройства или человека, но его смена не доказывает и отсутствие наблюдаемости. Для обоснованного операционного вывода нужны метка времени, префикс, интерфейс или линк, контекст потока либо приложения и срок хранения, охватывающий наложение предпочтительного и валидного состояний.

Эта дисциплина важна в обе стороны. Система безопасности может ошибочно посчитать последовательные адреса разными субъектами. Следователь может приписать старое наблюдение нынешнему владельцу адресного контекста, не имея временной связи. А слишком долгий журнал может фактически восстановить именно ту цепочку корреляции, окно которой стандарт пытался сократить.

Источники