Идентификаторы интерфейса с особыми свойствами и протоколы на их основе

Подобный механизм защищает конфиденциальность подвижных, странствующих пользователей, которые возят с собой свой компьютер. А можем ли мы подобным образом помочь маскировке оседлых пользователей? Да, если позволим хосту время от времени менять адрес, даже пока он связан с одной и той же точкой подключения. В общем случае хост не может свободно сменить префикс подсети, так как он задан точкой подключения. Нам придется ограничиться все тем же идентификатором интерфейса. Весь адрес, составленный из префикса подсети и случайного идентификатора интерфейса, мы обозначим как временный (temporary), потому что время его жизни заведомо ограничено. Этим он отличается от обычного автоматически назначенного адреса, который может существовать на интерфейсе неограниченно долго благодаря постоянной регенерации объявлениями RA.

Давайте интегрируем эту схему в уже существующий цикл жизни адреса: пробный, предпочтительный, устаревший, недействительный, — как показано на рис. 6.2. Временный адрес начинает свою жизнь как пробный, потому что его обязательно надо проверить на уникальность по DAD. Если адрес действительно уникальный, то он становится предпочтительным, и с него можно устанавливать исходящие сеансы. В противном случае надо просто сгенерировать новый случайный идентификатор интерфейса и начать все сначала. На всякий случай число таких попыток создать уникальный идентификатор ограничено величиной TEMP_IDGEN_RETRIES — по умолчанию 3 раза [§3.3 RFC 4941]. Действительно, если несколько попыток подряд не удались, то налицо какой-то непредусмотренный нами сбой.

Временный адрес обречен на то, чтобы рано или поздно стать устаревшим. Он не может оставаться предпочтительным дольше, чем указано настройках хоста. в^{2 Параметр REGEN_ADVANCE, по умолчанию 5 с [§3.4, §5 RFC 4941].} После этого адрес уже не годится для открытия новых прикладных сеансов. Поэтому было бы неплохо создать и назначить новый адрес чуть заранее, чтобы у сетевого интерфейса всегда был хотя бы один предпочтительный временный адрес. У сетевого интерфейса IPv6 может быть много адресов, и не будет никакой беды в том, что времена жизни старого и нового адресов перекроются.

По нашей задумке новый адрес должен быть другим, так что ему потребуется новый случайный идентификатор интерфейса. Конечно, его можно генерировать каждый раз, когда в нем возникнет необходимость. Но если вычислительные ресурсы хоста ограничены, а требования к степени конфиденциальности не настолько высоки, чтобы каждый адрес хоста был случайным, достаточно время от времени генерировать один случайный идентификатор для каждого из сетевых интерфейсов [§3.5 RFC 4941]. Период регенерации должен быть таким, чтобы преемник устаревшего адреса отличался от него .^{3 То есть он должен быть короче, чем TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR.}

Тем временем устаревший адрес продолжит свое существование, чтобы активные прикладные сеансы спокойно завершились штатным порядком. В них этот адрес уже "засвечен", и нет никакой необходимости торопить его полное исчезновение. Тем не менее, рано или поздно его стоит объявить недействительным и удалить, чтобы избежать слишком большого числа адресов на интерфейсе. Ведь с каждым адресом связаны ресурсы хоста и сети: структуры в оперативной памяти, группа искомого узла и т.п. Поэтому действительное время жизни временного адреса тоже ограничено, хотя и довольно продолжительным интервалом .^{4 Параметр TEMP_VALID_LIFETIME, по умолчанию неделя [§3.3, §5 RFC 4941].}

Рис. 6.2. Жизненный цикл временного адреса IPv6

В остальном временный адрес следует тем же правилам, что и другие автоматически назначенные адреса. В частности, сообщения RA тоже управляют его временем жизни. Это можно представить себе вот каким образом. У простого адреса всего два таймера, один предпочтительного времени жизни, а другой действительного, и оба они перезапускаются по сообщению RA, если в нем упомянут соответствующий префикс. А у временного адреса вместо этого две пары таймеров. В каждой паре один таймер по-прежнему перезапускается сообщениями RA, зато второй взведен единожды, в момент создания адреса, и ведет монотонный отсчет времени. Тем не менее, сработать первым может любой из спаренных таймеров, и тогда адрес перейдет в следующее состояние.

Вот так незначительной доработкой уже готовых механизмов нам удалось решить задачу конфиденциальности адресов IPv6. Конечно, выдать пользователя может не только его сетевой адрес, но в многоуровневой системе защиты все элементы важны, так как злоумышленник может атаковать на любом уровне. Поэтому расширения для конфиденциальности — если и не достаточное, то уж точно необходимое средство, чтобы противостоять охоте за персональной информацией. Но пока за вами не следят, или если вас это не очень беспокоит, расширения для конфиденциальности удобнее держать выключенными, потому что они затрудняют анализ и отладку работы сети. Поэтому у этих расширений должен быть выключатель, и его положение по умолчанию должно быть "выкл" [§3.6 RFC 4941].