НОУ ИНТУИТ | IPv6 для профессионалов. Лекция 6: Протокол розыска соседей

Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1863 / 145 | Длительность: 24:05:00

Специальности: Архитектор программного обеспечения

Теги: ipv4, ipv6, компьютерные сети, протоколы

В отсутствие других сведений хосту IPv6 не остается ничего, кроме как передавать (весь исходящий трафик через этот маршрутизатор, так что для хоста это будет (маршрутизатор по умолчанию (default router).

Очевидное исключение — это пакеты, в которых хост адресует сам себя. Их не следует отправлять на маршрутизатор по умолчанию, потому что такие пакеты вообще не покидают границ хоста.

Любой имеющий опыт работы с IPv4 сказал бы, что у нашего модельного хоста есть только маршрут по умолчанию, (::/0, и нет маршрута на непосредственно подключенную подсеть. Однако суть как раз в том, что модель хоста IPv6 целенаправленно избегает появления таблицы маршрутов среди структур данных хоста. Сделано это, не в последнюю очередь, для упрощения минимальной реализации, которая найдет себе место во встроенных системах. Фактически, происходит попытка снять с хоста все функции, которые будут заведомо доступны в маршрутизаторе. Реализация хоста IPv6 может включать в себя эти функции факультативно, но они не обязательны, и их отсутствие не повредит работоспособности хоста.

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

Рис. 5.17. Маршрутизация обратно в канал NBMA и за его пределы

Для топологии "звезда" этого решения будет вполне достаточно, так как у хостов все равно нет иного способа обмениваться данными, кроме как через маршрутизатор, хотя формально они подключены к одному каналу. Такая конфигурация представлена на рис. 5.17.

Теперь усложним топологию канала и допустим, что она включает в себя прямые связи между некоторыми хостами. Для примера рассмотрим топологию "бабочка" (рис. 5.16), где две пары хостов снабжены такими связями. Ее матрица соседства приведена в 5.3. Как мы уже отметили, "звезда" обязательно будет подграфом такой топологии (см. рис. 5.16), и наша простейшая схема работы хоста, с одной стороны, останется возможной. С другой стороны, она утратит свою оптимальность, так как хосты А и Б или В и Г смогли бы обмениваться пакетами напрямую, не создавая нагрузки на маршрутизатор М. Сведения о соседстве хостов А и Б, а также В и Г, хранятся маршрутизатором М. Каким образом М мог бы сообщить, скажем, хосту А, что тот вполне способен передавать пакеты хосту Б напрямую? И когда М следует это сделать? Потребуется ли особый протокол, по которому А запросит недостающую информацию у М?

Таблица 5.3. Матрица соседства для канала "бабочка"
	А	Б	В	Г	М
А	-	1	0	0	1
Б	1	-	0	0	1
В	0	0	-	1	1
Г	0	0	1	-	1
М	1	1	1	1	-

На самом деле, здесь достаточно простой (переадресовки (redirect), которую будет естественно оформить в виде сообщения ICMPv6, принадлежащего к семейству ND [§4.5 RFC 4861]. Последовательность событий может быть такой:

хост А передает пакет, адресованный Б, через маршрутизатор М, и вносит запись вида "Б $\to$ М" в свой кэш адресатов DC;
маршрутизатор М замечает, что в матрице соседства есть прямая связь А–Б;
тем не менее, он не отбрасывает пакет, а исправно передает его Б;
затем, чтобы оптимизировать будущий трафик, М направляет хосту А сообщение ND типа "переадресовка", которое уведомляет, что адресат Б доступен через следующий шаг Б, то есть напрямую;

хост А принимает переадресовку к сведению, исправляя запись Б в кэше адресатов на "Б $\to$ Б";
пока кэш адресатов хоста А содержит запись "Б $\to$ Б", хост А передает пакеты хосту Б напрямую;
когда запись устаревает и удаляется из кэша, вся процедура повторяется с самого начала;
если же переадресовка потерялась и не дошла до хоста А, процедура повторится, как только А передаст следующий пакет в адрес Б;
наконец, если сеть вдруг продублирует пакет с переадресовкой, то запись DC "Б $\to$ Б" не изменится, потому что переадресовка обладает свойством идемпотентности.

Конечно, маршрутизатор М не должен слать переадресовку на (каждый пакет от А к Б, если хост А игнорирует переадресовки и продолжает слать пакеты через М. Из соображений устойчивости и безопасности частоту переадресовок следует ограничивать [§8.2 RFC 4861]. Впрочем, это справедливо практически для всех сообщений ICMPv6.

У этого решения есть несколько очевидных преимуществ. Во-первых, оно использует уже готовые структуры данных, в частности, кэш адресатов хоста. Во-вторых, оно требует всего лишь одного нового сообщения ND с простыми свойствами. В-третьих, оно устойчиво к потере и дублированию переадресовок. Наконец, в-четвертых, матрица соседства, хранимая маршрутизатором М, может изменяться по ходу работы канала, и хост А оперативно обновит свой взгляд на топологию канала без внешнего вмешательства благодаря работе кэша адресатов. Например, если связь А–Б исчезнет, то хост А станет слать трафик в адрес Б через маршрутизатор М, как только устареет прежняя запись в кэше адресатов DC.

Своевременно обнаружить исчезновение связи А–Б и переключиться обратно на маршрутизатор М хосту А помогут механизм (NUD (§5.1) и обратная связь между записями NC и DC. Так, когда NUD сигнализирует недоступность соседа Б, можно удалить заодно и все записи DC, чей следующий шаг равен Б. Тогда время жизни самих записей DC можно и не ограничивать. Мы обобщим эту идею ближе к концу раздела.

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

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

Независимо от версии IP, перед хостом стоит одна и та же основная задача:

(Дано: индивидуальный адрес назначения исходящего пакета IP.

(Вопрос: доступен ли сетевой интерфейс с этим адресом непосредственно, на канальном уровне?

Что означает для хоста H доступность удаленного сетевого интерфейса I на канальном уровне? Очевидно, это значит, что хост H посредством одного из его собственных, локальных интерфейсов J может обмениваться данными канального уровня с интерфейсом I, а значит, и его узлом-владельцем. Ведь всякий сетевой интерфейс а) подключен ровно к одному каналу и б) принадлежит ровно одному узлу. (Когда интерфейс не подключен, он не готов к работе и, с нашей точки зрения, не существует.) Необходимое, но недостаточное условие доступности на канальном уровне — это чтобы у хоста H нашелся интерфейс J, подключенный к тому же каналу L, что и интерфейс I. Дополнительное условие — это фактическая возможность обмена данными на канальном уровне между интерфейсами I и J по каналу L. Если, например, в локальных сетях второе следует из первого, то в каналах NBMA все зависит от логической топологии данного канала.

Будет любопытно отметить, что понятие "петли" (loopback) позволяет обобщить эту конструкцию и на случай, когда интерфейс назначения I принадлежит локальному хосту H. В этом случае тривиальное решение выглядит как J = I. Впрочем, если у хоста несколько интерфейсов, подключенных к каналу L, то возможны и нетривиальные решения, где J $\ne$ I.

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

А вот общепринятые способы найти ответ на данный вопрос в двух версиях IP существенно разнятся.

Как мы уже сказали, хост IPv4 исходил из предположения, что все адреса в одной с ним подсети доступны напрямую. О таких адресах мы говорили, что они непосредственно подключенные (directly connected). У непосредственно подключенного адреса может быть всего два состояния: или он вообще не назначен, или он принадлежит интерфейсу, который доступен локальному хосту на канальном уровне. Все прочие адреса не являются непосредственно подключенными и доступны хосту только через маршрутизатор. Классификацию адресов хост IPv4 проводил с помощью несложной побитовой арифметики, используя список префиксов подсетей, назначенных его собственным интерфейсам. Вдобавок, если результат теста был положительный, то наиболее точный префикс однозначно указывал на интерфейс, сквозь который доступен непосредственно подключенный адрес.

Напротив, хост IPv6 больше не доверяет информации о подсетях, потому что она не всегда отражает действительную топологию каналов. Хост IPv6 не может априори определить, принадлежит ли произвольный адрес соседу, и потому рассчитывает на дополнительные источники информации, чтобы классифицировать каждый адрес назначения индивидуально. (Если об адресе нет иной информации, то хост IPv6 по умолчанию полагает, что соответствующий сетевой интерфейс недоступен на канальном уровне, а адрес находится "(вне канала" (off-link) [§3 RFC 5942].

Обратите внимание на это правило. Оно существенно отличается от общепринятой практики IPv4.

Из каких источников хост может почерпнуть иные сведения? Во-первых, адреса его собственных интерфейсов доступны ему напрямую, потому что хост всегда может послать пакет сам себе, минуя маршрутизатор. Во-вторых, если в настройках хоста указан адрес маршрутизатора по умолчанию, то он также заведомо доступен напрямую. В свою очередь, эта настройка открывает хосту возможность обмена данными с другими хостами, даже если их адреса "вне канала". В процессе этого обмена хост может получить от маршрутизатора переадресовку вида "Б $\to$ Б" и таким образом узнать, что интерфейс с адресом Б доступен ему на канальном уровне. Все эти источники информации сообщают хосту IPv6, что адрес находится "(на канале" (on-link).

Модель, в которой все адреса по умолчанию находятся "вне канала", довольно нова и опыт работы с ней относительно невелик, так что даже некоторые стандарты потребовали корректив. Скажем, все еще действующий стандарт ND предписывал, что адрес — "на канале", если о нем пришло объявление NA, или же если он выступает источником любого сообщения ND [§2.1 RFC 4861]. Однако это поведение противоречит модели, в которой единственный достоверный источник такой информации — маршрутизатор. Кроме того, оно открывает возможность для атаки, когда злоумышленник на канале перехватывает трафик, предназначенный узлу вне канала. Поэтому [п.3 §3 RFC 5942] запрещает хосту подобный трюк.

В то же время, хосту не возбраняется "разогревать" свой кэш соседей NC, заранее создавая в нем записи, но не делая при этом выводов о непосредственной доступности узлов. К примеру, получив запрос NS с опцией SLLA, хост создает о его источнике запись NC в состоянии (ПРОСРОЧЕННАЯ [§3 RFC 5942 и §7.2.3 RFC 4861], потому что в будущем это позволит (сэкономить время и обойтись без явного розыска соседа, как мы обсудили в §5.1. Но воспользоваться этой записью NC для прямой передачи хост будет вправе, только когда маршрутизатор подтвердит, что адресат "на канале", и будет создана соответствующая запись в кэше адресатов DC.

Только теперь, поняв и сформулировав главное различие между алгоритмами теста на соседство IPv4 и IPv6, мы можем безопасно оптимизировать алгоритм IPv6, не рискуя навредить нашему пониманию основ.

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

все внутриканальные адреса, FE80::/10;
подсети, назначенные подлинно широковещательным каналам;
диапазоны адресов меньше подсети, внутри которых топология канала гарантирует прямую доступность.

Кроме того, условно считается, что групповые адреса всегда "на канале", поскольку групповой трафик IP распространяется в сети не так, как индивидуальный. Групповые маршрутизаторы слушают все обслуживаемые ими группы и потому, с точки зрения источника трафика, они ничем не отличаются от рядовых членов группы на том же канале. Подробнее мы поговорим об этом в §6.4. Кроме того, к групповым адресам никогда не применяют ND. Поэтому групповые адреса стоят особняком, и нет смысла пытаться включить их в наш текущий дискурс о критериях "на канале/вне канала".

В первых двух случаях диапазоны адресов уже представлены префиксами. Третий случай не столь важен, но в нем диапазон тоже можно представить набором префиксов. Поэтому вместо произвольных диапазонов мы можем говорить о префиксах "на канале". Если список этих префиксов сообщить хосту, то он сможет эффективнее использовать свое соседство с другими узлами и реже обращаться к услугам маршрутизатора по умолчанию. Соответствующая структура в памяти хоста IPv6 так и называется: (список префиксов (Prefix List). Если адрес назначения содержит в себе один из этих префиксов, то он для данного хоста — "на канале".

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

Свежеполученный опыт подсказывает нам, что список префиксов надо заполнять с осторожностью, чтобы не навредить работе каналов нетривиальной топологии. По умолчанию в этом списке ровно один элемент — внутриканальный префикс FE80::/10 [§5.1 RFC 4861, §3 RFC 5942].

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

В то же время, скажем, интерфейс, подключенный к каналу Ethernet, еще ничего не говорит о фактической топологии этого канала. Например, с помощью частных VLAN топологию такого канала можно ограничить и превратить его из широковещательного в NBMA. По этой причине хосту не следует автоматически вносить в список префиксов подсети только потому, что они назначены интерфейсам определенного типа.

Согласно нашему генеральному плану, точными сведениями о топологии канала обладает маршрутизатор. Поэтому самая достоверная информация о списке префиксов могла бы исходить именно от маршрутизатора. Пока что мы не располагаем подходящим механизмом для этого, но скоро он у нас тоже появится (в §5.4.2).

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

Рис. 5.18. Один канал и один маршрутизатор, но две подсети

Дальше >>

Авторизоваться

IPv6 для профессионалов

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

Вопросы и ответы