Вспомогательные механизмы

Работа с множеством локальных адресов. Выбор адресов по умолчанию

Как мы сказали в §2.5, у хоста IPv6 может быть несколько сетевых адресов. На самом деле, один адрес бывает только у хоста IPv6, который не подключен к сети, — это адрес обратной связи ::1. Если у хоста есть хотя бы один активный сетевой интерфейс кроме "петли", то число его адресов возрастает до двух, так как этому интерфейсу обязательно назначен внутриканальный адрес IPv6. А если интерфейс хоста получает еще и глобальный адрес IPv6, то адресов у хоста становится три. Как мы видим, три индивидуальных адреса — это минимум для хоста IPv6, подключенного к Internet.

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

Далее, сетевой интерфейс хоста может получить несколько адресов из одной зоны. Для чего это может быть полезно? Адреса из одной подсети назначают, когда, например, функции хоста А переходят хосту Б, а хост А прекращает свое существование. В этом случае можно назначить хосту Б, кроме его собственного адреса, бывший адрес хоста А, и тогда не придется менять настройки других элементов сети: хост Б станет отвечать от имени хоста А, и никто не заметит изменений. Адреса из разных подсетей открывают путь к тому, чтобы использовать одновременные подключения к нескольким провайдерам Internet.

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

Рассмотрим с этих позиций типовой сценарий: локальный хост Л по своей инициативе собирается послать пакет удаленному хосту У. Допустим, что приложение, запущенное на хосте Л, хочет направить в адрес У дейтаграмму UDP или установить с У соединение TCP. Чтобы составить такой пакет, сетевой стек хоста Л — не без помощи приложения и даже самого пользователя — должен перейти от абстрактных названий "Л" и "У" к паре адресов, источника и назначения пакета.

Первым делом пользователь сообщает приложению какой-то идентификатор хоста У, пригодный к машинной обработке. Сегодня в этой роли мы используем имена хостов, так что приложение на входе получит имя У, такое как y.example.org. Обратившись к DNS, приложение получит список адресов, отвечающих данному имени. Как мы уже говорили в §2.11, в общедоступных зонах DNS мы надеемся увидеть только глобальные адреса; между тем, DNS — не единственная база имен, наряду с ней применяют NIS, WINS и даже файл HOSTS.TXT… К чему мы ведем нашу мысль? В общем случае приложение получит множество адресов хоста У, а область действия некоторых из них будет меньше глобальной.

Со своей стороны, хосту Л тоже назначено некое множество адресов. Если во множестве "Л" всего N адресов, во множестве "У" всего M адресов, то можно составить упорядоченных пар адресов, потенциальных кандидатов.

В некоторых случаях конкретную пару выбирает пользователь или какой-то внешний механизм, и тогда приложение посредством сетевого API просит стек хоста Л использовать именно эту пару адресов для связи с хостом У. Например, команда ping6 позволяет указать оба адреса явным образом в командной строке:

ping6 -S FE80::1 2001:DB8::1

Но обычно полагают, что приложение и сетевой стек сами сделают оптимальный выбор адресов по умолчанию, сокращенно DAS (default address selection), для передачи данных между локальным и удаленным хостами [RFC 6724].

В IPv4 процедура выбора сводилась к тому, что приложение перебирало удаленные адреса по одному, пытаясь установить сеанс. Например, так себя ведет клиент telnet:

$ telnet host.example.org

Trying 192.0.2.23...

telnet: connect to address 192.0.2.23: Operation timed out

Trying 198.51.100.7...

telnet: connect to address 198.51.100.7: No route to host

Trying 203.0.113.5...

Connected to host.example.org.

Escape character is '^]'.

NetBSD/vax (host.example.org) (ttyp0)

login:

Сетевой стек, в свою очередь, подбирал локальный адрес для указанного приложением удаленного адреса. К примеру, стек BSD Unix находил по таблице маршрутов выходной интерфейс, а затем брал из списка адресов интерфейса самый первый^{4 G. R. Wright, W. R. Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Addison Wesley, 1995. §22.8, "in_pcbconnect Function".} . Эта процедура продолжалась до тех пор, пока приложению не удавалось установить сеанс или пока оно не исчерпывало список удаленных адресов.

Когда у каждого адреса появляется область действия, такая простая схема DAS может завести в тупик. Достаточно представить себе, что список адресов выходного интерфейса возглавляет внутриканальный адрес, назначенный раньше всех остальных. В этом случае хост Л сможет общаться только со своими соседями по каналу, даже если у него будет не только внутриканальный, но и глобальный адрес. Ведь в §2.4 мы сформулировали такое ключевое правило: чтобы пакет IPv6 достиг адресата, интерфейс назначения должен находиться в зоне адреса источника. Чтобы выполнить это правило, алгоритм DAS должен рассмотреть все локальные адреса и по очереди сопоставить каждый из них с удаленным адресом.

Но какой именно критерий надо использовать при таком сопоставлении? Иными словами, какой из локальных адресов лучше всего подходит данному удаленному адресу? Чтобы критерий, который мы сейчас предложим, было проще алгоритмизировать, давайте сформулируем его в виде транзитивного отношения "лучше/хуже" между двумя потенциальными адресами источника, SA и SB, при данном адресе назначения D. Тогда список локальных адресов можно будет отсортировать по этому критерию, и наилучший адрес сам "всплывет" в начало списка.