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

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

Аннотация: Разрешение индивидуальных адресов. Правила взаимодействия хостов и маршрутизаторов IPv6 в пределах канала. Критерии "на канале" и "вне канала". Координирующая роль маршрутизаторов.
Ключевые слова: ПО, IP, прямой, точка-точка, PPP, отношение, адрес, таблица, сетевой адрес, путь, RFC, маршрутизатор, mac, ARP, широковещание, ISO, запрос, общая шина, ЛВС, сегменты, группа, поддержка, длина, подсеть, идентификатор, префикс, администратор, OUI, поле, бит, подмножество, механизмы, значение, злоумышленник, TTL, универсальность, механизм безопасности, запрос-ответ, сетевой адаптер, RTT, кэш, запись, TCP, обмен данными, связь, вызов функции, логический, модуль, исходный пакет, информация, таймер, интервал, ядро, автомат, симметрия, место, маршрут, proxy, сценарий, действительный, доступ, конечный автомат, получатель сообщения, тип сообщения, тупиковая ситуация, кадр, исключение, байт, тело сообщения, опция, интерфейс, очередь, маршрутизация, контекст, передача данных, опыт, конвергенция, хост, канальный уровень, адресация, топология, звезда, граф, минимум, операции, конфигурация, матрица, оптимальность, список, алгоритм, диапазон, VLAN, ICMP, обратный, координатор, оптимизация, структура данных, отказоустойчивость, выбрать из списка, приложение, вывод, слово, буфер, компромисс, стек протоколов

Розыск соседей и разрешение адресов

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

Нам удобнее думать о сетевом взаимодействии узлов, поставив себя на место одного из них и назвав его локальным узлом. Тогда все прочие узлы — удаленные.

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

Чтобы нам вскоре не пришлось опровергать наши собственные утверждения, мы сразу же должны оговорить, что подключение узлов к общему каналу — это необходимое, но еще недостаточное условие для прямой передачи пакета между ними. Дело в том, что существуют "неклассические" каналы, в которых не все пары узлов могут обмениваться пакетами напрямую. Подробному обсуждению таких каналов в контексте IPv6 мы посвятим §5.2, а пока что давайте предположим, что наш локальный узел А априори знает, что он может передать пакет узлу Б напрямую, используя определенный канал К. Если это так, то узлы А и Б — соседи (neighbors) по каналу К. Пока наше воображение еще не смущено "неклассическими" каналами, мы можем позволить себе упрощенную картину, где соседи А и Б соединены каналом "точка-точка" — например, старым добрым PPP — или же широковещательным каналом — скажем, привычной локальной сетью Ethernet. Эти хрестоматийные случаи иллюстрирует рис. 5.1.

Узлы-соседи по широковещательному каналу (слева) и по каналу                  "точка-точка" (справа)

Рис. 5.1. Узлы-соседи по широковещательному каналу (слева) и по каналу "точка-точка" (справа)

Тем не менее, давайте с самого начала иметь в виду, что, с математической точки зрения, отношение соседства коммутативно, но не транзитивно: если узел Б — сосед узла А, то узел А — сосед узла Б; но если узлы А и Б соседи и узлы Б и В соседи, то это еще не значит, что узлы А и В тоже соседи.

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

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

Теперь подумаем, как локальный узел А обращается к соседу Б. Использует ли он для этого титул, кличку или радиопозывные? Конечно же, нет. Вместо этого узел А применяет адрес IP, присвоенный интерфейсу узла Б. Если у узла Б несколько интерфейсов, то мы имеем в виду, конечно же, один из подключенных к общему каналу К.

Таким образом, узел IP, намереваясь передать индивидуальный пакет, вначале знает только адрес IP удаленного соседа. Так как сосед может быть не только адресатом пакета, но и маршрутизатором, его называют "следующий шаг" (next hop), тем самым подчеркивая, что он может быть не последним на пути пакета.

Следующий шаг пакета от создавшего его хоста иногда называют "первый шаг" (first hop). На самом деле, эта деталь редко имеет значение, так что первый шаг пакета — всего лишь частный случай следующего шага.

Однако, чтобы на самом деле передать пакет дальше, уровень IP должен обратиться к канальному уровню, а тот использует только канальную адресацию и ожидает канального адреса соседа, будь то в явном или неявном виде. Поэтому локальный узел должен найти среди всех соседей по данному каналу именно того, кто обладает адресом следующего шага, и узнать его канальный адрес. Эта процедура известна нам как разрешение адресов (address resolution).

Если канал — типа "точка-точка", то это тривиальная задача, поскольку явный адрес IP и неявный канальный адрес единственного соседа заранее известны.

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

Если же канал многоадресный, то задача существенно затрудняется; ее решение зависит от свойств этого канала. В худшем случае, когда нет никаких вспомогательных механизмов, поможет только заданная вручную таблица соответствия между адресами сетевого уровня и канальными адресами. Но, к счастью, такой случай практически не встречается, а зато мы довольно часто сталкиваемся с каналами, где есть возможность обратиться сразу ко всем соседям и спросить, кому принадлежит искомый сетевой адрес. Эта идея, представленная на рис. 5.2, открывает нам путь к автоматизированному розыску соседей1 Можно встретить термин-синоним "обнаружение соседей". (neighbor discovery) [RFC 4861].

Идея автоматического розыска соседей

Рис. 5.2. Идея автоматического розыска соседей

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

Хотя на первый взгляд может показаться, что разрешение адресов и розыск соседей — одна и та же задача, на самом деле они перекрываются, но не совпадают. Розыск соседей, в общем случае, можно вести по любым критериям, а не только по сетевому адресу. Например, узел может спросить у своих соседей: "Эй, кто из вас — маршрутизатор по умолчанию?" — или: "У кого это из вас жужжит вентилятор?" С другой стороны, разрешение адресов не всегда требует розыска соседей. Так, мы обсудили в §4.1.1, что разрешение групповых адресов IPv4 и IPv6 в групповые же адреса MAC происходит локально, простой подстановкой битов. Розыск не потребуется и тогда, когда требуемые сведения заранее внесены в локальную конфигурацию — то, что мы знали в IPv4 как статический ARP (static ARP).

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

Это логическое разделение полезно иметь в виду, чтобы наше решение не вышло узким и ограниченным. Тем не менее, первой прикладной задачей у нас стоит именно разрешение индивидуальных адресов IPv6 в канальные адреса, когда узел А спрашивает: "Дорогие соседи, кому из вас принадлежит сетевой адрес Б?" — и получает в ответ канальный адрес искомого соседа, если тот на месте.

Нетерпеливые читатели могут найти полный список функций, которые выполняет розыск соседей IPv6, в [§3 RFC 4861]. Но не стоит торопиться, ибо мы придем к этим функциям естественным путем.

Сергей Субботин
Сергей Субботин

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

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

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

 

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

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

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