Форматы адресов IPv6

Структура группового адреса IPv6

До сих пор мы сказали о групповых адресах IPv6 только то, что они полностью займут префикс FF00::/8 и что у них тоже будут области действия. Теперь нам пора уточнить детали.

Прежде всего, заметим, что групповые адреса бывают двух видов: общепринятые и выбранные для каких-то частных целей. Первые из них назначает IANA, внося в соответствующий реестр^{6 http://www.iana.org/assignments/ipv6-multicast-addresses} . Эти назначения носят долговременный характер, так что общепринятые групповые адреса можно охарактеризовать как постоянно назначенные (permanently-assigned). Например, в IPv4 к этой категории относились адреса 224.0.0.1 (все узлы подсети) и 224.0.0.2 (все маршрутизаторы подсети )^{7 http://www.iana.org/assignments/multicast-addresses} . Адреса второго вида каждый выбирает для своих собственных целей или нужд своей организации, не претендуя на монопольное владение ими, и освобождает, когда они больше не нужны. Такие адреса, в противоположность первым, мы назовем временно занятыми (transient). Четко разграничить эти два вида адресов необходимо, поскольку общепринятые адреса важны для работы стандартных протоколов, а значит, конфликты между адресами двух видов способны причинить заметный вред сети.

Групповых адресов у нас довольно много, так что мы не будем ломать голову над оптимальной пропорцией между общепринятыми и временно занятыми адресами: пусть их будет поровну. Тогда надежно отличить временно занятый адрес от общепринятого нам позволит один бит-флаг, который мы обозначим T (transient). Его смысл прост: T = 0 означает общепринятый адрес, а T= 1 — временно занятый [§2.7 RFC 4291].

Раз уж дело дошло до флагов, то давайте выделим для них целый полубайт, как показано на рис. 2.6. На сегодняшний день в нем занято еще два флага, P и R. О назначении флага P мы поговорим в §2.9, а в случае R ограничимся его нулевым значением.

Рис. 2.6. Флаги в групповом адресе IPv6

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

Но это вовсе не значит, что общепринятым групповым адресам области не требуются. Напротив, ограничение области позволяет более тонко управлять множеством узлов — а точнее, их интерфейсов, — на которые указывает тот или иной общепринятый адрес. В групповом вещании IPv4 эта концепция имела рудиментарную форму: общепринятые адреса с префиксом 224.0.0.0/24 относились только к текущей подсети, то есть были внутриканальными. Теперь же, варьируя область, мы сможем избирательно указывать на группу нужного нам "диаметра". Например, если нам дан прикладной протокол FOO [RFC 3092], то у нас должна быть возможность составить как минимум такие адреса:

• все серверы FOO на данном канале;
• все серверы FOO в данном сайте;
• все серверы FOO в Internet.

Чтобы решение этой задачи подошло и общепринятым, и временно занятым адресам, область группового адреса надо закодировать в нем самом как можно проще и независимо от прочих полей. Поступим так: вслед за полубайтом флагов отведем полубайт области. Стандартные значения этого полубайта [§2.7 RFC 4291] приведены в Табл. 2.2.

Прокомментируем эти области.

Область интерфейса (interface-local scope) позволяет ограничить групповую рассылку единственным интерфейсом узла источника. Такой групповой трафик не покинет пределов узла источника; в этом он аналогичен индивидуальному трафику в адрес ::1.

Мы, конечно же, помним, что узел вступает в группу IP не целиком и полностью, а на отдельных сетевых интерфейсах. В терминах общепринятого группового API, ссылка на интерфейс, такая как его номер или имя, — это обязательный аргумент вызовов "вступить в группу X" и "выйти из группы X" наряду с адресом группы [§7.1 RFC 1112, §5.2 RFC 3493]. Именно поэтому область с номером 1 проводит границу вокруг одного интерфейса, а не вокруг всего узла.

Внутриканальная область (link-local scope) нам уже знакома: она охватывает один канал и все интерфейсы, подключенные к нему.

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

В частности, как следует из их названий, область администратора (admin-local scope) отвечает наименьшему участку административной ответственности, область сайта (site-local scope) охватывает один сайт (площадку), а область организации (organization-local scope) — целую организацию, у которой, вероятно, есть несколько сайтов (площадок). Коды, помеченные как "(доступно)", можно назначать областям нестандартной величины, если это необходимо для каких-то частных задач. Разумеется, при этом больший код должен отвечать области большей величины.

Наконец, глобальная область (global scope) не накладывает никаких ограничений на распространение группового трафика.

Мы уже израсходовали в групповом адресе 16 старших разрядов: восемь ушло на префикс FF00::/8; следующие четыре заняты флагами; и еще четыре занимает код области. Значит, у нас осталось 112 младших разрядов. Они-то и составят идентификатор группы (group ID), который позволит различать группы, сосуществующие в пределах зоны. В результате мы получим структуру группового адреса IPv6, изображенную на рис. 2.7.

Рис. 2.7. Формат группового адреса IPv6

Для простоты и единообразия положим, что если адрес общепринятый (T = 0), то группа получает идентификатор во всех областях сразу. К примеру, если группа "все серверы mDNSv6" получит идентификатор 0xFB ,^{8 http://www.iana.org/assignments/ipv6-multicast-addresses/} то мы без труда сможем составить ее адреса разных областей (см. Табл. 2.3), даже не вполне представляя себе, что такое mDNSv6.

С временно занятыми адресами (T = 1) так поступить нельзя, потому что сетевые администраторы разных уровней вполне могут применить один и тот же номер группы для различных целей, если у них нет общей политики в этом аспекте. Здесь области нужны именно для того, чтобы заранее предотвратить возможный конфликт. Благодаря областям, любой сетевой администратор может занять идентификатор группы в своей зоне без оглядки "вниз", "вверх", или "на соседа". Поэтому неудивительно, что временно занятый адрес имеет смысл только в данной зоне и его трактовка никоим образом не распространяется на другие зоны той же или иной величины.

При всех преимуществах этой схемы, ее возможности по разрешению конфликтов не безграничны. Так, в каждой зоне только кто-то один может выбирать временно занятые адреса, а в противном случае снова возникает опасность конфликта. В частности, неясно, кто распоряжается временно занятыми адресами в глобальной зоне. Мы посвятим решению этой проблемы §2.9.

А в завершение текущего раздела давайте "назначим" важнейшие общепринятые группы [§2.7.1 RFC 4291], как показано в Табл. 2.4.

В отличие от IPv4, где поддержка группового вещания рекомендована, но все же носит факультативный статус [§3 RFC 1112, §3.3.7 RFC 1122], в IPv6 групповое вещание — это неотъемлемая часть протокола. Поэтому каждый узел IPv6 обязан состоять в группах "все узлы" на всех активных интерфейсах (FF01::1) и подключенных к ним каналах (FF02::1). В дополнение к этому, маршрутизаторы IPv6 должны вступать в относящиеся к ним группы "все маршрутизаторы" (FF01::2, FF02::2, FF05::2).