Опубликован: 30.07.2013 | Уровень: для всех | Доступ: платный
Лекция 3:

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

< Лекция 2 || Лекция 3: 123456 || Лекция 4 >

Структура группового адреса 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 ограничимся его нулевым значением.

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

Рис. 2.6. Флаги в групповом адресе IPv6
О назначении флага R можно узнать из RFC 3956. Знакомство с этим документом пройдет легче и интереснее, если читатель сперва завершит вместе с нами "работу" над основными элементами IPv6 в рамках данной книги.

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

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

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

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

Таблица 2.2. Общепринятые коды области группового адреса IPv6 [§2.7 RFC 4291]
Код Значение
0 (резерв)
1 область интерфейса
2 внутриканальная область
3 (резерв)
4 область администратора
5 область сайта
6-7 (доступно)
8 область организации
9-13 (доступно)
14 глобальная область (вселенная)
15 (резерв)

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

Область интерфейса (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) — целую организацию, у которой, вероятно, есть несколько сайтов (площадок). Коды, помеченные как "(доступно)", можно назначать областям нестандартной величины, если это необходимо для каких-то частных задач. Разумеется, при этом больший код должен отвечать области большей величины.

Справедливости ради заметим, что для групповых адресов IPv4 были также предложены административно заданные области действия [RFC 2365].

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

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

Формат группового адреса IPv6

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

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

Таблица 2.3. Групповые адреса серверов mDNSv6 разных областей действия
Адрес Точная группа
FF01::FB Все серверы mDNSv6 на том же интерфейсе, что и источник пакета
FF02::FB Все серверы mDNSv6 на том же канале, что и источник пакета
FF03::FB Все серверы mDNSv6 в том же сайте, что и источник пакета
FF04::FB Все серверы mDNSv6 в Internet

На практике может оказаться, что общепринятая группа имеет смысл не во всех областях. Например, группа FF02::5, "все маршрутизаторы OSPF", определена только в области канала. В этом случае идентификатор группы зарезервирован в других областях. Так, группы FF01::5 и FF05::5 никогда назначены не будут, и это позволит избежать путаницы.

Составьте групповые адреса разных областей для протокола ASAP, получившего десятичный идентификатор группы 307.

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

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

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

Таблица 2.4. Адреса важнейших общепринятых групп IPv6 [§2.7.1 RFC 4291]
ID Адрес Группа
0 FF0x:: (резерв)
1 FF0x::1 "все узлы"; определена для таких значений кода области x: 1 (интерфейс) и 2 (канал)
2 FF0x::2 "все маршрутизаторы"; определена для таких значений кода области x: 1 (интерфейс), 2 (канал) и 5 (сайт)
А почему нет стандартных групп FF04::2 и FF08::2? Дело в том, что группа "все маршрутизаторы" охватывает только маршрутизаторы индивидуального трафика (unicast), а потому она имеет смысл только в областях, определенных для индивидуальных адресов, тогда как области администратора (x = 4) и организации (x = 8) для индивидуальных адресов не определены. Область интерфейса (x = 1) для них тоже не определена, но, как мы уже сказали, эта область играет роль интерфейса "петля" для группового трафика. Еще одно общепринятое назначение — особенно важное для нас — это групповые адреса для примеров в учебниках и документации. Для них выделено целое семейство префиксов FF0x::DB8:0:0/96 [§3 RFC 6676].

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

Одним из плодов этого решения будет то, что IPv6 сможет полностью избавиться от широковещания. Широковещательный адрес IPv4 превращался в такой же канальный адрес, например, MAC FF-FF-FF-FF-FF-FF, создавая паразитную нагрузку на станции канала, которые не имели дела с IPv4. Так что теперь, чтобы направить пакет всем узлам IPv6 определенной области, следует использовать подходящий групповой адрес "все узлы". Однако окончательный отказ от идеи широковещания в среде IPv6 произойдет только в §5.3, когда мы рассмотрим все основные ситуации, в которых наш опыт IPv4 подталкивает нас к применению этого режима адресации.
< Лекция 2 || Лекция 3: 123456 || Лекция 4 >
Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.

Александр Худышкин
Александр Худышкин
Россия
Константин Второв
Константин Второв
Россия, Бокситогорск, ЛГОУ им. А.С.Пушкина, 2003