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

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

Как работала бы подобная схема в IPv4? Допустим, у хоста А был бы адрес (192.0.2.33/24, у хоста Б - (203.0.113.44/24, а у маршрутизатора М — (192.0.2.1/24 и (203.0.113.1/24. В этой схеме весь трафик между хостами А и Б неизбежно проходил бы через маршрутизатор М. Почему? Во-первых, если бы хосту А пришла переадресовка ICMP вида "(203.0.113.44 \to (203.0.113.44", то хост А проигнорировал бы ее, потому что следующий шаг в ней не являлся непосредственно подключенным [§3.2.2.2 RFC 1122]: (203.0.113.44 не принадлежал подсети (192.0.2.0/24. А во-вторых, маршрутизатор М не стал бы слать хосту А такую переадресовку [§5.2.7.2 RFC 1812], потому что он заранее знал: она будет проигнорирована. Те же соображения, с точностью до перестановки адресов, определили бы и обратный ход трафика от Б к А.

Теперь же, в IPv6, у хоста А не будет причин не принять переадресовку "Б \toБ" просто потому, что именно маршрутизатор — достоверный источник сведений о топологии канала [§8.1 RFC 4861]. В свою очередь, маршрутизатор М не должен ограничивать переадресовки одной подсетью, если он располагает информацией о том, что хосты А и Б — соседи. И тогда хост А сможет узнать и принять к сведению, что хост Б "на канале" и доступен напрямую, как это показано на рис. 5.19.

Механизм переадресовки

Рис. 5.19. Механизм переадресовки

Обратите особое внимание на это важное различие между переадресовками IPv4 и IPv6 [§3.1 RFC 4861].

Это новое свойство нам следует перенести и на список префиксов. Для этого скажем: элементы списка префиксов не обязаны принадлежать подсетям, в которых находится сетевой интерфейс хоста. К примеру, список префиксов хоста Х с адресом (2001:DB8:33::33/64 вполне может содержать префиксы (2001:DB8:33::/48 (префикс короче подсети) и (2001:DB8:777::/64 (другая подсеть). Все адреса с такими префиксами будут для хоста Х "на канале", и тот сможет слать пакеты их владельцам напрямую.

Теперь нам пора поработать над форматом переадресовки. Как мы уже сказали, она будет разновидностью сообщения ICMPv6 из семейства ND [§4.5 RFC 4861]. Переадресовка — это сообщение с любопытными свойствами. С одной стороны, переадресовка — это полезная подсказка хосту, а вовсе не извещение об ошибке. Поэтому ее численный тип находится в диапазоне справочных сообщений 128–255 и равен 137. С другой стороны, переадресовка высылается в ответ на произвольный пакет IPv6, что отличает ее от других справочных сообщений и роднит с извещениями об ошибках. В этом случае, как мы знаем, служебное сообщение должно содержать в себе начало пакета, который его вызвал, чтобы получатель смог более точно отреагировать на него, например, определив, к какому сеансу TCP относится это сообщение.

Разрешить это противоречие в свойствах переадресовки будет довольно просто, если мы воспользуемся механизмом опций ND и поместим пакет-виновник (или его начало) в специально отведенную для этой роли опцию "переадресованный заголовок" (Redirected Header), показанную на рис. 5.20 Правила работы с ней очевидны:

Опция ND "переадресованный заголовок"

Рис. 5.20. Опция ND "переадресованный заголовок"
  • опция "переадресованный заголовок" имеет смысл только в сообщении "переадресовка", а в прочих сообщениях ND ее следует игнорировать;
  • полезная нагрузка этой опции содержит весь пакет-виновник или его начало, так чтобы суммарная длина пакета ICMPv6 вместе с заголовками IPv6 не превысила максимально допустимое ограничение в 1280 байт, заданное в §3.3.4.

А какие обязательные поля мы поместим в тело переадресовки? Назначение переадресовки заключается в том, чтобы сообщить получателю, что оптимальный путь к адресату Б пролегает через следующий шаг Ш, где Б и Ш — адреса IPv6. Поэтому фиксированная часть тела переадресовки состоит, помимо выравнивания, всего из двух адресов IPv6. Как показано на рис. 5.21 первым из них расположен адрес следующего шага Ш. Так как его владелец — заведомо сосед получателя, то, по терминологии ND, это адрес цели (target address). Непосредственно за ним идет адрес назначения Б.

Переадресовка IPv6

Рис. 5.21. Переадресовка IPv6

Адрес цели идет первым для единообразия с другими сообщениями ND.

Хотя адрес назначения также содержится в копии пакета-виновника (опция "переадресованный заголовок"), его дублирование в фиксированной части переадресовки облегчает работу ее получателя.

Здесь мы видим еще одно важное отличие между переадресовками IPv6 и IPv4. Как мы помним, переадресовка IPv4 могла быть для одного адреса или целой сети, хотя формат переадресовки для сети был классовым и не имел смысла в CIDR. Переадресовка же IPv6 — исключительно для одного адреса, и это позволяет хранить ее сведения в кэше DC.

Адреса Б и Ш вполне могут совпадать. Именно этот случай нам сейчас особенно интересен. Ведь такой переадресовкой маршрутизатор сообщает, что узел Б, он же Ш, находится "на канале".

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

Прочие требования к годной переадресовке вполне предсказуемы [§8.1 и §8.2 RFC 4861]:

  • она защищена механизмом GTSM от засылки извне канала, так что значение "предельного числа шагов" в заголовке IPv6 должно быть равно 255 — см. §5.1;
  • в заголовке IPv6 адрес назначения не имеет права быть групповым, потому что иначе это явная атака на безопасность; Это требование в RFC явно не присутствует, но доказать его нетрудно. Адрес назначения IPv6 переадресовки всегда равен адресу источника пакета-виновника [§8.2 RFC 4861], а тот ни при каких условиях не может быть групповым — мы говорили об этом в §3.2.
  • в теле переадресовки адрес назначения Б не может быть групповым, так как переадресовку никогда не высылают в ответ на групповой пакет;
  • хост-получатель проверяет с помощью своего кэша DC, что адрес источника IPv6 переадресовки совпадает с текущим адресом следующего шага для адреса назначения Б из тела переадресовки. Смысл этой проверки в том, что достоверная переадресовка могла прийти только от маршрутизатора, которым хост действительно пользовался;

Эта проверка также защищает от переадресовок, которые задержались в сети. Например, если хост А был переадресован маршрутизатором М1 к маршрутизатору М2, а тем, с свою очередь, к маршрутизатору М3, то запоздавшая копия переадресовки М1 будет хостом А проигнорирована.

А как быть хосту, если от его текущего маршрутизатора по умолчанию пришла переадресовка вида "Б \toШ", но в кэше DC еще нет записи об адресате Б? Хотя стандарт признает такую переадресовку законной [§8.1 RFC 4861] и рекомендует создать новую запись "Б\toШ" [§8.3 RFC 4861], подобная переадресовка подозрительна, потому что она содержит сведения об адресате, которому хост в обозримом прошлом никаких пакетов не слал. Разобраться в этой ситуации хосту поможет копия пакета-виновника в теле переадресовки.

  • пошаговая адресация маршрутизаторов происходит по их внутриканальным адресам [§8 RFC 4861], и поэтому:

    o

    в заголовке IPv6 адрес источника должен быть внутриканальным, так как переадресовка исходит от маршрутизатора данного канала;

    o

    в теле переадресовки адрес цели Ш должен или совпадать с адресом назначения Б (переадресовка на хост), или быть внутриканальным (переадресовка на другой маршрутизатор).

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

Та же тенденция прослеживается и во взаимодействии между маршрутизаторами IPv6. Так, отношения смежности между маршрутизаторами IS IS [§3 RFC 5308] и OSPF [§2.5 RFC 5340] устанавливаются именно по их внутриканальным адресам.

Пока хосты IPv6 обращаются к маршрутизаторам по внутриканальным адресам, хостам не придется делать исключения из правил "на канале" — "вне канала". Ведь внутриканальный префикс FE80::/10 автоматически попадает в список префиксов "на канале". В противном же случае хост должен был бы постоянно "помнить", что адрес маршрутизатора по умолчанию находится "на канале". Это несложно, но немного нарушает стройность алгоритма передачи пакетов хостом.

Полученный формат переадресовки уже позволяет сообщить сам факт, что адрес назначения — "на канале". Но всегда ли этого достаточно? Допустим, хост А послал пакет адресату Б через маршрутизатор М, получил от маршрутизатора переадресовку вида "Б \toБ" и сохранил это соответствие в своем кэше адресатов DC. Каковы его дальнейшие действия? Когда придет время послать следующий пакет в адрес Б, кэш адресатов DC укажет хосту А, что адрес Б — "на канале" и принадлежит соседу. То есть придет время для розыска соседа Б с помощью протокола ND. В свою очередь, протокол ND подразумевает, что сосед Б может получать групповые пакеты, рассылаемые хостом А.

Но что будет, если канал между А и Б — NBMA без группового вещания между хостами? Тогда на канальном уровне хост А мог бы передавать соседу Б индивидуальные кадры, если бы знал его канальный адрес. В то же время, групповой запрос NS не дойдет до Б. В этом случае розыск соседа закончится неудачей и обмен данными между А и Б окажется невозможным.

Чтобы обойти и эту особенность каналов NBMA, нам достаточно довести до логического завершения новую функцию маршрутизатора IPv6. Как мы уже отмечали, маршрутизатор IPv6 — это координатор передачи данных по каналу между хостами. Тогда именно он и должен сообщить хосту А недостающие сведения. Для этого достаточно дополнить переадресовку уже доступной нам опцией ND "канальный адрес цели" (§5.1) и поместить в нее канальный адрес узла Б.

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

Что хост А сделает с информацией из этой опции? Очевидно, он поместит ее в свой кэш соседей NC. Так как информация исходит от маршрутизатора и еще не подтверждает обоюдной доступности А и Б, подходящим состоянием для записи NC будет ПРОСРОЧЕННАЯ. Этой записью уже можно воспользоваться для непосредственной передачи пакета. Когда хост Б откликнется на этот пакет, то по сигналу вышестоящего протокола запись NC станет ДОСТУПНОЙ. Если же вышестоящий протокол — строго однонаправленный, то хосту Б все равно придется ответить на индивидуальный запрос NS с опцией "канальный адрес источника" (§5.1), который пошлет хост А, когда запись NC перейдет по тайм-ауту в состояние ИСПЫТАНИЕ.

Обратите внимание: хост Б будет обязан пройти тут же самую процедуру переадресовки, чтобы получить право слать прикладные пакета напрямую хосту А, полагая того соседом "на канале".

Последний вопрос о работе этого механизма состоит в том, как маршрутизатор М узнает канальный адрес узла Б в отсутствие полноценного группового вещания. Конечно, последнее средство, пригодное для всех разновидностей NBMA — это ручная настойка кэша соседей М. Однако М сможет найти канальный адрес Б автоматически, если канал NBMA эмулирует групповое вещание по принципу веера, известное как "псевдошироковещание" (pseudobroadcast )20 Using IP Multicast Over Frame Relay Networks. Cisco technology white paper. http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html [ ]: групповые пакеты, рассылаемые М, доходят до всех узлов канала, а групповые пакеты, рассылаемые другими узлами канала, доходят как минимум до М. В этом случае М узнает канальный адрес Б, когда попытается передать узлу Б первый пакет от А и проведет розыск соседа. Кроме того, не исключено, что М уже знает канальный адрес Б, потому что хост Б сам проводил розыск соседа М. Ведь пришедший от хоста Б групповой запрос NS позволит М не только ответить информацией о себе, но и создать запись NC о соседе Б в состоянии ПРОСРОЧЕННАЯ, поскольку такой запрос NS обязательно содержит опцию "канальный адрес источника".

До сих пор мы сознательно ограничивались сценарием, когда канал обслуживает один маршрутизатор, а у каждого хоста один сетевой интерфейс, помимо "петли". Насколько трудно будет снять эти ограничения? Начнем с первого из них и рассмотрим канал с несколькими маршрутизаторами. Чтобы подключенный к тому же каналу хост смог пользоваться их услугами, ему, прежде всего, понадобится список их адресов вместо одного адреса маршрутизатора по умолчанию. Так возникает новая структура данных в памяти хоста: список маршрутизаторов по умолчанию (Default Router List). Сейчас мы допустим, что этот список указан вручную в начальных настройках хоста, а над его автоматическим заполнением мы поработаем чуть позже, в §5.4.2. Мы не станем усложнять нашу конструкцию системой приоритетов и положим, что все маршрутизаторы в списке эквивалентны.

Не имея оснований предпочесть какой-то конкретный маршрутизатор из списка, хост может начать работу, просто выбрав запись случайным образом. Этого уже будет достаточно, скажем, чтобы распределить нагрузку густозаселенного канала на несколько маршрутизаторов. Кроме того, дублирование маршрутизаторов повысит отказоустойчивость сети, если каждый хост сможет самостоятельно обнаружить, что его текущий маршрутизатор "пропал без вести", и выбрать из списка новый, "живой" маршрутизатор. Придется ли нам изобрести для этого новый протокол? К счастью, нет. Ведь в нашем распоряжении уже есть замечательный механизм NUD, для работы которого достаточно протокола ND — см. §5.1. Когда NUD сигнализирует о недоступности текущего маршрутизатора, хост может проверить работоспособность следующего по списку, и так далее. Совсем удалять недоступный маршрутизатор из списка, конечно же, не следует. Ведь вполне может оказаться, что к тому времени, когда последний маршрутизатор в списке засбоит, первый уже вернется в строй. На этом задача о нескольких маршрутизаторах решена.

Конечно, поиск "живого" маршрутизатора открыт для оптимизации. К примеру, хост может активно следить за всеми маршрутизаторами в списке с помощью все того же механизма NUD и ранжировать их по состоянию записи в кэше соседей NC: ДОСТУПНАЯ запись лучше ПРОСРОЧЕННОЙ, а та предпочтительнее НЕПОЛНОЙ.

Справедливости ради заметим, что §3.3.1.2 RFC 1122 требовал от хоста IPv4 обязательной поддержки нескольких маршрутизаторов по умолчанию. В то же время, §3.3.1.4 того же RFC 1122 признавал, что в IPv4 нет надежного и общепринятого способа узнать о недоступности текущего маршрутизатора. Этот конфликт между желаемым и действительным неизбежно сказался на практике IPv4, где список маршрутизаторов по умолчанию можно встретить редко.

Сможем ли мы так же легко и изящно снять второе ограничение и обеспечить эффективную работу хоста IPv6, подключенного к нескольким каналам? Для начала мы вновь обратим внимание на уже известный нам факт: отношение соседства определено только в пределах заданного канала. Иными словами, узел Б не может быть соседом узла А "вообще" — они будут соседями только на вполне определенном канале К. В свою очередь, окном в канал для хоста выступает сетевой интерфейс, а структуры данных хоста, которые управляют передачей пакетов в нашей модели, самым непосредственным образом работают с отношением соседства:

  • запись NC содержит сведения о соседе;
  • запись DC указывает на соседа — следующий шаг;
  • маршрутизатор обязан быть соседом;
  • префикс "на канале" содержится только в адресах соседей.

Поэтому все эти структуры привязаны к определенному сетевому интерфейсу и не имеют смысла для других интерфейсов того же хоста .21 Если только эти интерфейсы не подключены к тому же самому каналу. . Пока хост обладает помимо "петли" ровно одним сетевым интерфейсом, эта связь может оставаться неявной; но, обзаведясь несколькими подключениями, хост должен вести отдельный экземпляр каждой структуры для каждого из своих интерфейсов, не имея при этом центральной структуры данных над ними. В результате у эталонного хоста IPv6 нет универсального критерия, по которому он смог бы предпочесть для передачи пакета один из своих интерфейсов. Этот выбор остается задачей других механизмов и протоколов [Приложение A RFC 4861].

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

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

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

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

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

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

 

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

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