Адресация IPv6

Последнее требование выполнимо, только если сетевая топология зон удовлетворяет ряду условий:

• могут ли адрес источника и адрес назначения пакета IPv6 принадлежать разным зонам?
• границы зон проходят сквозь узлы, а не сквозь каналы;
• зоны никогда не перекрываются частично;
• зона большей величины может полностью заключать в себя зоны меньшей величины.

Вдобавок, еще одно топологическое условие нам дает принцип изоляции зон:

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

Чтобы лучше понять все эти условия, рассмотрите пример сложной карты зон на рис. 1.6 и установите, как эта карта выполняет каждое из них.

Рис. 1.6. Пример топологии зон. Допустимая и недопустимая внутрисайтовые трассы в нем

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

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

Например, на рис. 1.7 узлы А и Б соединены каналом. Поэтому узел А может направить узлу Б пакет, выбрав внутриканальный адрес источника и глобальный адрес назначения. Благодаря топологии зон IPv6 это не вызовет неоднозначности, и узел Б, зная входной интерфейс пакета, сможет ответить на него, используя глобальный адрес источника и внутриканальный адрес назначения. В свою очередь, и узел А отнесет адреса в пакете-ответе к их зонам на основании входного интерфейса.

Рис. 1.7. Обмен данными между адресами разных областей

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

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

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

Наконец мы можем сказать, что поняли структуру областей и зон IPv6. Теперь пора выполнить наше обещание и дать администратору сети НИИЧАВО необходимые инструменты, чтобы провести ping узла (а точнее, его интерфейса) FE80::Baa1 в отделе атеизма (канал К4). Какой информации не хватает в командной строке: "ping6 fe80::baa1"? Индекса зоны?

Как мы уже не раз говорили, численный адрес IPv6 сам указывает на свою область, в данном случае канал; индекс зоны тоже содержит в себе эти сведения. Выходит, что дополнить численный адрес индексом зоны было бы избыточно. Чтобы устранить эту избыточность, давайте еще раз просмотрим наши выкладки и решим такой ребус: чему равен полный зонный адрес IPv6 за вычетом адреса численного? Напрашивается такой ответ: он равен сетевому интерфейсу в данной зоне. Ведь именно знание входного интерфейса позволяет узлу дополнить численный адрес его зоной в принятом пакете. Поэтому кандидат №1 на роль удобного и понятного идентификатора, который расширит численный адрес IPv6 до зонного, — это системное имя сетевого интерфейса, подключенного к требуемой зоне. Например, если канал К4 подключен к серверу НИИЧАВО через интерфейс en3, то зонный адрес "FE80::Baa1 на канале К4" достаточно записать в командной строке, например, так: ping6 FE80::BAA1%en3

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

Но насколько безупречна эта конструкция? Ведь все наши предыдущие выкладки насчет топологии зон относились к входящим пакетам, а теперь мы вдруг перескочили к пакету исходящему! Когда пакет — входящий, то все соответствия однозначны: пакет входит через ровно один сетевой интерфейс^{25 Возможно, в квантовых сетях будущего это будет не так.} , который находится в ровно одной зоне каждой области. Но однозначность эта не взаимная, и поэтому ее нельзя просто так обратить для передачи: в одной зоне может находиться несколько интерфейсов данного узла. Например, он может быть подключен двумя интерфейсами к одному и тому же каналу в целях отказоустойчивости и распределения нагрузки. Наконец, все интерфейсы узла могут принадлежать одному и тому же сайту.

Рис. 1.8. Начальная настройка узла: гипотеза взаимно однозначного соответствия между интерфейсами и внутриканальными зонами

Рис. 1.9. Разрешение неоднозначности: два интерфейса подключены к одному каналу

Поэтому окончательную картину соответствия между интерфейсами и зонами способен построить только инженер-проектировщик данной сети. Имена же интерфейсов в системе дают лишь хорошее начальное приближение, которое система способна построить автоматически (см. рис. 1.8), так что администратору останется только скорректировать его, пользуясь картой сети [§6 RFC 4007], — например, как это изображено на рис. 1.9.

Чтобы отразить эту особенность в терминологии, мы дадим текстовому идентификатору зоны отдельное название: zone_id [§11.2 RFC 4007] Такой идентификатор чаще всего совпадает с системным именем одного из интерфейсов, потому что это удобно и понятно, но жесткой связи между ними нет. В результате мы получаем такую текстовую нотацию зонного адреса IPv6:

численный_адрес%zone_id

Если мы хотим записать зонный префикс, то его длину следует поместить, как и прежде, после адреса [§11.7 RFC 4007]:

численный_адрес%zone_id/длина_префикса

Вот пример сочетания внутриканального адреса и длины префикса в одной строке:

FE80::DADA:C001%en5/64

Поскольку системные имена интерфейсов в разных системах выглядят по-разному, то и формат zone_id у них разный. В Табл. 1.2 приведено несколько примеров, как была бы введена команда ping6 по внутриканальному адресу хоста НИИЧАВО в разных ОС.

Кстати, это еще одна иллюстрация того, как идентификация зон локальна для каждого узла.

Чтобы завершить нашу работу над зонной архитектурой IPv6, нам надо рассмотреть последний вопрос: всегда ли в настройках и командной строке адрес IPv6 придется дополнять zone_id? На самом деле, нет. Во-первых, среди всевозможных областей IPv6 есть две области с особыми свойствами:

• У адреса обратной связи ::1 область действия ограничена виртуальным интерфейсом типа "петля". Узлу нужен ровно один такой интерфейс, так что адрес обратной связи дополнять zone_id не надо. Можно сказать, что адрес ::1 — это особый случай внутриканального адреса, который встречается только на виртуальном канале интерфейса "петля" [§6 RFC 4007].
• Глобальный адрес, такой как 2001:DB8::1, наделен в космическую эпоху даже не глобальной, а вселенской областью действия, так что никаких дополнительных указателей он тоже не требует — по крайней мере, пока к Internet не подключатся параллельные вселенные, жители которых тоже изобрели IPv6.

Кроме того, на практике удобно опустить zone_id, если эта информация избыточна. Например, какой смысл указывать его для внутрисайтового адреса, если все интерфейсы нашего узла принадлежат одному сайту, или для внутриканального адреса, если узел снабжен ровно одним интерфейсом помимо "петли"? Обобщить эту мысль можно, рекомендовав реализациям IPv6 поддержку зон по умолчанию, чтобы у каждой области была одна такая зона [§6 RFC 4007]. Тогда сетевой стек по численному значению адреса IPv6 без zone_id сможет "угадать" его зону.

Хотя до сих пор мы говорили про области и зоны индивидуальных адресов IPv6, ограничить область действия мы можем и у группового адреса. Тогда, к примеру, мы сможем назначить общепринятый групповой адрес "все маршрутизаторы данного канала". Подробнее об областях групповых адресов мы поговорим ниже, в §2.8.