Протокол розыска соседей

Модели хоста, канала и подсети IPv6

Если птица ходит уткой, плавает уткой и крякает уткой, то ее называют уткой. (Дж. У. Райли)

CROWD: A witch! A witch! A witch! We've got a witch! A witch!

VILLAGER #1: We have found a witch, might we burn her?

CROWD: Burn her! Burn!

BEDEMIR: How do you know she is a witch?

VILLAGER #2: She looks like one.

BEDEMIR: Bring her forward.

WITCH: I'm not a witch. I'm not a witch.

BEDEMIR: But you are dressed as one.

WITCH: They dressed me up like this.

(Monty Python and the Holy Grail)

Вертит, как цыган солнцем. (Украинская поговорка)

До сих пор мы говорили об узлах IPv6 в целом, практически не проводя границ между хостом и маршрутизатором, и это было вполне оправданно, пока мы обсуждали базовые механизмы IPv6, не зависящие от типа узла.

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

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

1. пользуются таблицей маршрутов одного и того же вида: "префикс следующий шаг" [ср. §3.3.1.2 RFC 1122 и §5.2.4.3 RFC 1812];

   Хотя [§3.3.1.2 RFC 1122] говорил, что полноценная таблица маршрутов — необязательный элемент в сетевом стеке хоста IPv4, на практике она встречается повсеместно.
2. одинаковым способом определяют, является ли удаленный узел соседом, сопоставляя префиксы на своих сетевых интерфейсах с адресом удаленного узла [ср. §3.3.1.1 RFC 1122 и §5.2.4.2 RFC 1812].

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

Проанализируем с этой точки зрения тест на соседство IPv4. Допустим, что узел А собирается передать пакет, адресованный узлу Б, посредством одного из своих интерфейсов И, которому назначены адреса 192.0.2.3/28 и 203.0.113.131/28. Следовательно, с точки зрения узла А, каналу , к которому подключен интерфейс И, назначены подсети 192.0.2.0/28 и 203.0.113.128/28. Если адрес назначения пакета Б равен 192.0.2.8 или, скажем, 203.0.113.136, то узел А немедленно определит, что этот адрес принадлежит соседу, потому что он содержит префикс непосредственно подключенной подсети. С точки зрения IP, такой пакет можно передать напрямую его адресату, полагаясь на канальный уровень стека. В то же время, ни один из адресов 192.0.2.150, 198.51.100.1 или 203.0.113.2 не принадлежит соседу, и, следовательно, такие адресаты доступны только косвенно, через маршрутизатор.

Эта логика IPv4 основана на гипотезе, что все узлы одной подсети — попарно соседи и могут передавать друг другу пакеты напрямую, не задействуя маршрутизатор. Такое допущение, безусловно, справедливо для широковещательных каналов, например, Ethernet, равно как и для соединений "точка-точка". Но насколько оно универсально? Существуют ли каналы, в которых оно не выполняется?

Оказывается, что в действительности спрос на такие каналы есть. Их принято обозначать термином "каналы множественного доступа без широковещания" или аббревиатурой NBMA (Non-Broadcast Multiple Access). Это не совсем точный термин, потому что на практике в каналах NBMA обычно отсутствует не только широковещание, но и свободная адресация одних узлов другими. Простейший пример такого канала — это топология "звезда" (рис. 5.15), где концевые узлы могут передавать пакеты центральному узлу (концентратору), тогда как напрямую обмениваться данными друг с другом концевые узлы не могут. В топологии "звезда" концентратор — сосед любому концевому узлу, и наоборот, но никакие концевые узлы — не соседи друг другу.

Рис. 5.15. Канал NBMA "звезда" и его граф

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

Именно поэтому возникает спрос на искусственное решение, когда одна подсеть назначена множеству подключений, а это автоматически превращает их в один канал согласно фундаментальному правилу IP: "Одна подсеть — это один канал" [§2.1 RFC 4291]. Конечно, такая конструкция напоминает цирковой фокус с легким привкусом обмана. Тем не менее, давайте посмотрим, чего будет стоить ее реализация в IPv6. Ведь мы находимся в поле эксперимента, а искомая возможность вполне востребована. Как обычно, в процессе мы встретим и решим более глубокие и общие задачи.

Новые условия таковы, что канал может обладать нетривиальной логической топологией, когда не все его узлы — соседи. Ранее, когда модель канала была простой и требовала соседства между всеми узлами, эта топология канала была скрыта в самом тесте на соседство IPv4. Теперь же информацию о топологии канала придется задавать и хранить явным образом, например, в виде матрицы соседства, где 1 означает пару соседей, а 0 — разъединенную пару узлов. Такие матрицы для канала "звезда" (рис. 5.15) и широковещательного канала с тем же набором узлов приведены в табл. 5.1 и табл. 5.2, соответственно. Придется ли вводить подобную матрицу в настройки каждого из узлов канала?

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

Однако для IP практическую ценность представляют только топологии, в которых маршрутизатор — сосед каждого хоста. Действительно, в противном случае для беспрепятственной работы канала потребовался бы транзитный трафик через хосты, а это по определению невозможно. Говоря языком элементарной теории графов, граф "звезда" с маршрутизатором в центре будет подграфом любой топологии канала, представляющей интерес в контексте TCP/IP. Это правило иллюстрирует рис. 5.16.

Рис. 5.16. Канал NBMA "бабочка" содержит подграф "звезда"

Тогда маршрутизатор IPv6 будет естественным хранителем информации о топологии канала, потому что он может обслуживать практически неограниченное число хостов (до ) и при этом он заведомо способен передать сведения о топологии канала каждому подключенному хосту. Механизм распространения этих сведений нам сейчас предстоит разработать.

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