RFC 1256 ICMP Router Discovery Messages

Network Working Group                                 S. Deering, Editor
Request for Comments: 1256                                    Xerox PARC
                                                          September 1991

ICMP Router Discovery Messages

Сообщения ICMP Router Discovery

PDF

Статус документа

Этот документ определяет стандарт IAB Standards Track для сообщества Internet, и требует обсуждения и внесения усовершенствований. Для выяснения состояния стандартизации и статуса данного протокола необходимо обратиться к “IAB Official Protocol Standards”. Документ является результатом работы группы IETF Router Discovery. Распространение данного документа не ограничено.

Аннотация

Этот документ задаёт расширения протокола управляющих сообщений Internet (Internet Control Message Protocol или ICMP), обеспечивающее хостам сетей с групповой или широковещательной передачей возможность определения адресов IP соседних с ними маршрутизаторов.

1. Терминология

Ниже приведены определения терминов, имеющих точный смысл в этом документе

system – система

Устройство, реализующее протокол Internet (IP) [9].

router – маршрутизатор

Система, пересылающая дейтаграммы IP, как указано в [2]. Это не включает системы, способные пересылать IP, где эта функциональность отключена, а также системы, пересылающие IP лишь для соблюдения опций IP Source Route.

host – хост

Любая система, не являющаяся маршрутизатором.

multicast – групповой [обмен]

Использование службы IP multicast [4] или IP broadcast [6], если явно не указно иное.

link – канал (соединение)

Коммуникационное устройство или среда, через которые системы могут взаимодействовать на канальном уровне (протокольный уровень, расположенный непосредственно ниже IP). Иногда для этого применяется термин «физическая сеть» (неточно). Примерами каналов являются ЛВС (возможно, связанные мостами с другими ЛВС), распределенные сети «хранения и пересылки» (store-and-forward), спутниковые каналы и соединения «точка-точка» (point-to-point).

multicast link – групповой канал

Канал в котором поддерживаются групповые (multicast) или широковещательные (broadcast) услуги IP. Это включает широковещательные среды, такие как ЛВС и спутниковые каналы, отдельные каналы «точка-точка» и некоторые среды store-and-forward (например, сети SMDS) [8].

interface – интерфейс

Точка подключения системы к каналу. Возможно (хотя и необычно) наличие у системы нескольких интерфейсов к одному каналу. Интерфейсы однозначно указываются индивидуальными (unicast) адресами IP, интерфейс может иметь не один такой адрес.

multicast interface – групповой интерфейс

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

subnet – подсеть

Одна подсеть сети IP, разделённой на подсети [7], или одна сеть IP без подсетей, т. е. объект, идентифицируемый адресом IP с соответствующей маской подсети. На одном канале может быть несколько подсетей.

neighboring – соседство

Наличие адресов IP из одной подсети.

2. Обзор протокола

Прежде, чем хост сможет передавать дейтаграммы IP за пределы непосредственно подключённой подсети, он должен узнать адрес хотя бы одного работающего маршрутизатора в этой подсети. Обычно это достигается чтением списка адресов маршрутизаторов из файла конфигурации (возможно, удалённого) при загрузке. На групповых каналах некоторые хосты могут узнавать адреса маршрутизаторов путём прослушивания трафика протокола маршрутизации. У обоих методов имеются существенные недостатки – файлы конфигурации должны поддерживаться вручную, что вызывает существенную административную нагрузку и не позволяет отслеживать динамически изменения в доступности маршрутизаторов, а для прослушивания протоколов маршрутизации хосты должны понимать используемые протоколы маршрутизации, которые могут быть разными в различных подсетях и могут меняться в любой момент. Этот документ задаёт дополнительный метод обнаружения маршрутизаторов на основе пары сообщений ICMP [10] для применения на групповых каналах. Этот метод избавляет от необходимости ручной настройки и не зависит от протокола маршрутизации.

Сообщения ICMP для обнаружения маршрутизаторов называются Router Advertisement (анонс маршрутизатора) и Router Solicitation (запрос маршрутизатора). Каждый маршрутизатор периодически передаёт групповые сообщения Router Advertisement с каждого из своих multicast-интерфейсов, анонсируя IP-адреса(а) этого интерфейса. Хосты узнают адреса соседних маршрутизаторов, просто прослушивая эти анонсы. При старте хоста, подключённого к групповому каналу он может передать групповое сообщение Router Solicitation для запроса незамедлительных анонсов вместо ожидания прибытия периодических. Если анонсы не приходят, хост может повторить запрос несколько раз, но затем должен воздерживаться от передачи дополнительных запросов. Любые маршрутизаторы, которые запускаются позднее или не были обнаружены из-за потери пакетов или временного разделения канала, в конечном итоге будут обнаружены по из периодическим (незапрошенным) анонсам. При высоком уровне потерь на канале или его частом разделении увеличивается частота передачи анонсов, а не число разрешённых хостам запросов.

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

Router Advertisement включает уровень предпочтения для каждого анонсируемого адреса маршрутизатора. Когда хосту нужно выбрать адрес применяемого по умолчанию маршрутизатора (т. е. для конкретного адресата хост не был перенаправлен или настроен использовать определённый адрес), предполагается, выбор адреса маршрутизатора с наибольшим уровнем предпочтения (см. параграф 3.3.1 в [1]). Администратор сети может настроить уровни предпочтения для адресов маршрутизаторов, чтобы рекомендовать или предостерегать от использования конкретных маршрутизаторов в качестве принятых по умолчанию. Router Advertisement включает также поле lifetime (срок действия), указывающее максимальную продолжительность времени, в течение которого анонсированные адреса считаются действительными адресами маршрутизаторов для хостов при отсутствии дальнейших анонсов. Это служит для того, чтобы хосты со временем забывали о маршрутизаторах, которые вышли из строя, стали недоступными или перестали выступать как маршрутизаторы.

По умолчанию анонсы передаются 1 раз в течение 7 – 10 минут, а срок действия составляет 30 минут. Это означает, что при использовании заданных по умолчанию значений не будут эффективно обнаруживаться «чёрные дыры», т. е. отказы первого интервала активного пути. В идеале такие «чёрные дыры» следует определять достаточно быстро, чтобы переключиться на дугой маршрутизатор до того, как в транспортных соединениях и сессиях верхних уровней возникнет тайм-аут. Предполагается, что на хостах уже имеется механизм обнаружения «чёрных дыр», как [1]. Хосты не могут зависеть от Router Advertisement для этой цели, поскольку анонсы могут быть недоступны или административно отключены на любом канале или от любого конкретного маршрутизатора. Поэтому принятые по умолчанию значения частоты и срока действия анонсов были выбраны так, чтобы вносимая ими нагрузка на каналы и хосты была пренебрежимо малой даже при наличии большого числа маршрутизаторов. Однако администраторы, желающие применять такие анонсы для обнаружения «чёрных дыр», могут использовать меньшие интервалы и сроки действия.

3. Формат сообщений

Сообщение ICMP Router Advertisement

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Num Addrs   |Addr Entry Size|           Lifetime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Router Address[1]                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Preference Level[1]                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Router Address[2]                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Preference Level[2]                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
|                               .                               |

Поля IP

Source Address

Адрес IP, относящийся к интерфейсу, через который передаётся сообщение.

Destination Address

Настроенное значение AdvertisementAddress или IP-адрес соседнего хоста.

Time-to-Live

1, если в поле Destination Address указан групповой адрес IP и значение не меньше 1 в иных случаях.

Поля ICMP

Type

Code

Checksum

16-битовое дополнение до 1 суммы дополнений до 1 для сообщения ICMP, начиная с поля ICMP Type. При расчёте контрольной суммы значение поля Checksum предполагается нулевым.

Num Addrs

Число адресов маршрутизатора, анонсируемых в сообщении.

Addr Entry Size

Число 32-битовых слов данных на каждый адрес маршрутизатора (2 для описанной здесь версии протокола).

Lifetime

Максимальное число секунд, в течение которых адреса маршрутизатора могут считаться действительными.

Router Address[i], i = 1..Num Addrs

Адрес(а) IP передающего маршрутизатора на интерфейсе, через который передаётся сообщение.

Preference Level[i], i = 1..Num Addrs

Предпочтения для каждого Router Address[i] как адреса принятого по умолчанию маршрутизатора по отношению к другим адресам маршрутизатора в той же подсети. Это целочисленное (со знаком) дополнение до 2 и большее значение указывает более высокий приоритет.

Сообщение ICMP Router Solicitation

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Source Address

Адрес IP, относящийся к интерфейсу, через который передаётся сообщение, или 0.

Destination Address

Настроенное значение SolicitationAddress.

Time-to-Live

1, если в поле Destination Address указан групповой адрес IP и значение не меньше 1 в иных случаях.

Поля ICMP

Type

Code

Checksum

Reserved

0 при передаче, игнорируется при получении.

4. Спецификация маршрутизатора

4.1. Переменные конфигурации маршрутизатора

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

Переменные для каждого группового интерфейса

AdvertisementAddress

IP-адрес получателя, используемый в групповых сообщениях Router Advertisements с этого интерфейса. Разрешается использовать только адреса all-systems (224.0.0.1) и limited-broadcast (255.255.255.255). Предпочтительно применять адрес all-systems, когда это возможно, чтобы сообщение получили все слушающие хосты на локальном канале, поддерживающие групповую адресацию IP.

Значение по умолчанию 224.0.0.1, если маршрутизатор поддерживает групповую передачу IP на интерфейсе, иначе 255.255.255.255

MaxAdvertisementInterval

Максимальное время между передачей групповых Router Advertisement с этого интерфейса (в секундах). Значение должно быть не меньше 4 и не больше 1800.

Значение по умолчанию 600.

MinAdvertisementInterval

Минимальное время между передачей групповых Router Advertisement с этого интерфейса (в секундах). Значение должно быть не меньше 3 и не больше MaxAdvertisementInterval.

Значение по умолчанию 0.75 * MaxAdvertisementInterval.

AdvertisementLifetime

Значение, помещаемое в поле Lifetime сообщений Router Advertisements, передаваемых с этого интерфейса (в секундах). Значение должно быть не меньше MaxAdvertisementInterval и не больше 9000.

Значение по умолчанию 3 * MaxAdvertisementInterval.

Переменные для каждого IP-адреса маршрутизатора на его групповых интерфейсах

Advertise

Флаг, указывающий, будет ли адрес анонсироваться.

Значение по умолчанию TRUE (адрес анонсируется).

PreferenceLevel

Предпочтительность адреса для принятого по умолчанию маршрута по отношению к другим адресам маршрутизатора из той же подсети. Это 32-битовое целочисленное (со знаком) дополнение до 2 и большее значение указывает более высокий приоритет. Минимальное значение (hex 80000000) служит для указания того, что адрес (даже при его анонсировании) не будет использоваться хостами для принятого по умолчанию маршрута.

Значение по умолчанию 0

Настраивать адрес с уровнем предпочтения hex 80000000 (вместо установки Advertise = FALSE) полезно при использовании анонсов для обнаружения «чёрных дыр», упомянутых в разделе 2. В частности, маршрутизатор, используемый для доступа лишь к конкретным адресатам IP, может анонсировать свой адрес с уровнем hex 80000000 (чтобы соседи не использовали его для маршрута по умолчанию для произвольных адресатов IP) с ненулевым сроком действия (чтобы соседние хосты, перенаправленные на него или настроенные на его использование могли обнаружить отказ по отсутствию анонсов).

Предполагается, что без явной настройки уровня предпочтения маршрутизатор может устанавливать его в соответствии с метрикой принятого по умолчанию маршрута (при наличии), а не использовать принятое по умолчанию значение 0, как указано выше. Таким образом, маршрутизатор с лучшей метрикой для заданного по умолчанию маршрута будет анонсировать для своего адреса более высокий уровень предпочтения (отметим, что метрика маршрутов кодируется так, что меньшее значение более предпочтительно, поэтому нужна «инверсия» при его преобразовании в уровень предпочтения в сообщениях Router Advertisement). Такая стратегия может снизить объем трафика ICMP Redirect на некоторых каналах за счёт повышения вероятности наилучшего выбора хостом маршрута для произвольных получателей. С другой стороны, трафик Redirect редко создаёт значительную нагрузку на каналы, а в некоторых случаях такая стратегия приведёт к росту трафика Redirect вместо его снижения (например, на каналах де для наиболее часто выбираемых получателей лучше применять маршрутизаторы, отличные от имеющего наилучший маршрут по умолчанию). Этот документ не даёт рекомендаций по этому вопросу и разработчики могут попробовать описанную стратегию, если они поддерживают также статическую настройку предпочтений, как указано выше.

4.2. Проверка сообщений маршрутизаторами

Маршрутизатор должен отбрасывать без уведомления принятые сообщения Router Solicitation, не прошедшие указанных ниже проверок.

Поле IP Source Address содержит 0 или адрес соседа (адрес, который совпадает с одним из принадлежащих маршрутизатору адресов на приёмном интерфейсе с учётом связанной с ним маски).
Поле ICMP Checksum имеет действительное значение.
ICMP Code = 0.
Размер ICMP (выводится из размера IP) не меньше 8 октетов.

Содержимое поля ICMP Reserved и все октеты после первых 8 байтов игнорируется. Будущие изменения протокола, совместимые с прежними версиями, могут задавать содержимое поля Reserved или дополнительных октетов в конце сообщения, несовместимые изменения могут использовать другие значения в поле Code.

Запросы, прошедшие проверку, называются действительными (valid solicitation).

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

4.3. Поведение маршрутизатора

Маршрутизатор присоединяется к группе IP all-routers (224.0.0.2) на всех интерфейсах, где он поддерживает групповую адресацию IP.

Термин «анонсирующий интерфейс» (advertising interface) относится к любому работающему и разрешённому групповому интерфейсу, где имеется хотя бы 1 адрес IP с флагом Advertise = TRUE. С каждого такого интерфейса маршрутизатор периодически передаёт сообщения Router Advertisement, содержащие указанные ниже значения.

Настроенный для интерфейса адрес AdvertisementAddress в поле получателя в заголовке IP.
Настроенный для интерфейса срок действия AdvertisementLifetime в поле Lifetime.
В полях Router Address[i] и Preference Level[i] указываются адреса и уровни предпочтения всех интерфейсов, где флаг Advertise = TRUE. В маловероятной ситуации, когда адреса и приоритеты не помещаются в одно сообщение (в соответствии с MTU на канале), передаётся несколько анонсов, каждый из которых содержит столько адресов сколько может поместиться (или сколько осталось для последнего анонса).

Анонсы не являются строго периодическими и в интервал между последовательными сообщениями вносится случайная поправка для предотвращения синхронизации анонсов от нескольких маршрутизаторов на одном канале. Это выполняется за счёт поддержки на каждом анонсирующем интерфейсе своего таймера для интервалов передачи. При каждой отправке группового анонса через интерфейс для его таймера устанавливается случайное значение с однородным распределением из настроенного интервала MinAdvertisementInterval – MaxAdvertisementInterval, а следующий анонс передаётся по завершении отсчёта таймера и для таймера устанавливается новое случайное значение. Маршрутизаторам рекомендуется включать какое-либо уникальное значение (например, свой адрес IP или адрес канального уровня) в затравку (seed), используемую для инициализации генератора псевдослучайных значений. Хотя диапазон случайных значений задаётся в секундах, в фактически задаваемых случайных значениях следует использовать минимальные интервалы, доступные для системного таймера.

Если для нескольких первых анонсов (до MAX_INITIAL_ADVERTISEMENTS) с интерфейса случайно выбраны интервалы больше MAX_INITIAL_ADVERT_INTERVAL, для таймера следует устанавливать значение MAX_INITIAL_ADVERT_INTERVAL. Использование меньших интервалов между начальными анонсами повышает вероятность быстрого обнаружения маршрутизатора, когда он впервые становится доступным в условиях возможной потери пакетов.

В дополнение к периодическим незапрошенным анонсам маршрутизатор предаёт анонсы в ответ на действительные запросы, полученные на любом из анонсирующих интерфейсов. Маршрутизатор может передавать отклики напрямую по индивидуальному адресу запросившего хоста (если это не 0) или по групповому адресу, заданному AdvertisementAddress. В последнем случае для таймера интервалов на интерфейсе устанавливается новое случайное значение как и при отправке незапрошенных анонсов. Индивидуальный отклик может, а групповой должен задерживаться на случайное время не более MAX_RESPONSE_DELAY, чтобы избежать синхронизации с другими отвечающими маршрутизаторами и позволить ответить на несколько запросов, полученных за короткое время, одним групповым откликом.

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

Следует отметить, что интерфейс может стать анонсирующим в моменты, отличные от запуска системы, в результате восстановления после отказа интерфейса или действия администраторов, таких как:

включение интерфейса, административно отключённого ранее и имеющего один или несколько адресов с флагом Advertise = TRUE;
включение пересылки IP (т. е. переходом хоста в состояние маршрутизатора) при наличии на интерфейсе одного или нескольких адресов с флагом Advertise = TRUE;
установка для флага Advertise значения TRUE на одном или нескольких адресах интерфейса, ранее не имевших Advertise = TRUE, или добавление адреса с флагом Advertise = TRUE.

В таких случаях маршрутизатор должен начать отправку периодических анонсов на новом анонсирующем интерфейсе, ограничив для нескольких первых анонсов интервал значением MAX_INITIAL_ADVERT_INTERVAL. Если хост становится маршрутизатором, система должна также присоединиться к группе IP all-routers на всех интерфейсах, где маршрутизатор поддерживает IP (независимо от того, являются ли они анонсирующими).

Интерфейс может перестать быть анонсирующим в результате действий через систему управления, таких как:

административное отключение интерфейса;
выключение системы или запрет пересылки IP (маршрутизатор становится хостом);
установка для всех адресов интерфейса флага Advertise = FALSE.

В таких случаях маршрутизатору рекомендуется (но не требуется) передать через интерфейс финальный групповой анонс, идентичный прежним, но с полем Lifetime = 0. Если маршрутизатор становится хостом, система должна также выйти из группы IP all-routers на всех интерфейсах, где маршрутизатор поддерживал IP (независимо от того, являются ли они анонсирующими).

При установке для одного или нескольких интерфейсов флага Advertise = FALSE через систему управления с сохранением Advertise = TRUE для других адресов маршрутизатору рекомендуется передать 1 групповой анонс, содержащий лишь адрес, для которого устанавливается Advertise = FALSE, с Lifetime = 0.

5. Спецификация хоста

5.1. Переменные конфигурации хоста

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

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

PerformRouterDiscovery

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

Значение по умолчанию TRUE

SolicitationAddress

IP-адрес получателя, используемый для передачи с интерфейса сообщений Router Solicitation. Разрешены лишь групповой адрес all-routers (224.0.0.2) и адрес ограниченного широковещания 255.255.255.255. Адрес all-routers является предпочтительным, когда это возможно, т. е. на каналах, где все анонсирующие маршрутизаторы поддерживают IP.

В параграфе 3.3.1.6 [1] указано, что реализация хоста должна поддерживать настраиваемый список адресов принятых по умолчанию маршрутизаторов. Назначение сообщений ICMP для обнаружения маршрутизаторов состоит в устранении такой необходимости для хостов, подключённых к групповым каналам. На каналах без поддержки групповой передачи и групповых каналах, где такие сообщения ICMP (ещё) не поддерживаются на маршрутизаторах или отключены административно, по-прежнему требуется настраивать список используемых по умолчанию маршрутизаторов на каждом хосте. Каждая запись списка должна включать указанные ниже переменные конфигурации.

RouterAddress

IP-адрес принятого по умолчанию маршрутизатора.

Значение по умолчанию не установлено.

PreferenceLevel

Уровень предпочтения RouterAddress как адреса принятого по умолчанию маршрутизатора относительно других адресов маршрутизатора в ту же подсеть. В RFC с требованиями к хостам не задано кодирование этого значения. Для передачи предпочтений в Router Advertisement и настройки через систему управления здесь предлагается указывать их 32-битовыми целочисленными дополнениями до 2 со знаком, где большие значения указывают более высокий уровень предпочтения. Минимальное значение (hex 80000000) зарезервировано для адресов, которые не используются в качестве принятых по умолчанию, т. е. применяются только как адреса конкретных получателей IP, о которых хост был проинформирован через конфигурацию или сообщения ICMP Redirect.

Значение по умолчанию 0.

5.2. Проверка сообщений хостами

Хост должен отбрасывать без уведомления полученные Router Advertisement, не соответствующие указанным ниже условиям:

поле ICMP Checksum корректно;
ICMP Code = 0;
ICMP Num Addrs не меньше 1;
ICMP Addr Entry Size не меньше 2;
размер ICMP (выводится ил размера IP) не меньше 8 + (Num Addrs * Addr Entry Size * 4) октетов.

Содержимое дополнительных слов информации на уровне адреса (сверх полей Router Address и Preference Level), а также все октеты за пределами первых 8 + (Num Addrs * Addr Entry Size * 4) игнорируются. В будущих версиях протокола, совместимых с прежними, могут задаваться дополнительные слова данных на уровне адреса или дополнительные октеты в конце сообщения. При несовместимых изменениях могут применяться другие значения Code.

Анонсы, прошедшие проверку, называются действительными (valid advertisement).

Хост должен отбрасывать без уведомления любые полученные сообщения Router Solicitation.

5.3. Поведение хоста

На любом интерфейсе, где хост поддерживает групповой обмен IP, он будет членом группы all-systems (224.0.0.1). Это выполняется автоматически, как указано в [4], и не требует действий протокола обнаружения маршрутизаторов.

Хост никогда не передаёт сообщений Router Advertisement.

Хост отбрасывает без уведомления сообщения Router Advertisement, принятые на интерфейсе, для которого установлен флаг PerformRouterDiscovery = FALSE, и не передаёт сообщений Router Solicitation с этого интерфейса.

Хост не может обрабатывать анонсы, пока он не знает своих адресов IP и масок подсетей для интерфейса, на котором принят анонс. На некоторых каналах хост может использовать то или иное сочетание сообщения BOOTP [3], RARP [5], ICMP Address Mask [7] для определения своего адреса и маски. В процессе определения адреса и маски на интерфейсе хост может сохранять действительные анонсы, принятые через интерфейс, для последующей обработки. Это позволяет параллельно выполнять обнаружение маршрутизаторов и определение адреса и маски.

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

Если адреса ещё нет в списке принятых по умолчанию маршрутизаторов на хосте, в список добавляется новая запись, содержащая адрес с соответствующим уровнем предпочтения, а для таймера устанавливается значение Lifetime из анонса.
Если адрес уже имеется в списке принятых по умолчанию маршрутизаторов в результате полученных ранее анонсов, уровень предпочтения для адреса обновляется, а таймер устанавливается в соответствии с новым анонсом.
Если адрес уже имеется в списке принятых по умолчанию маршрутизаторов в результате настройки конфигурации системы, уровень предпочтения для него не меняется и с интерфейсом не связано таймера. Отметим, что адреса маршрутизаторов, полученные из поля Gateway в фирменных расширениях пакета BOOTP [11], считаются настроенными адресами, для них по умолчанию устанавливается уровень предпочтения 0, а таймер не задаётся. Адреса из поля giaddr в пакете BOOTP [3] указывают ретранслятор BOOTP, который может не быть маршрутизатором IP, и такие адреса не следует включать в список принятых по умолчанию маршрутизаторов на хосте.

По завершении отсчёта таймера для любой записи, созданной в результате получения анонса, эта запись удаляется.

Для сокращения размера хранилища записей о принятных по умолчанию маршрутах хост может сохранять не все записи, полученные из анонсов. В этом случае хосту следует отрасывать адреса с низким уровнем предпочтения в пользу записей с более высоким уровнем. Желательно иметь в списке более одного принятого по умолчанию маршрутизатора, чтобы при обнаружении отказа используемого в данный момент маршрутизатора хост мог сразу же переключиться на другой, не ожидая приьытия следующего анонса. Адреса маршрутизаторов, анонсируемые с уровнем предпочтения hex 80000000, не используются хостом для принятых по умолчанию маршрутов и могут не включаться в список, если только их таймеры не применяются для обнаружения «чёрных дыр», как описано в параграфе 4.1.

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

Хосту разрешено (но не требуется) передавать до MAX_SOLICITATIONS сообщений Router Solicitation с любого их интерфейсов после какого-либо из событий:

инициализация интерфейса при старте системы;
повторная инициализация интерфейса после отказа или временного запрета через систему управления;
переход маршрутизатора в статус хоста путём отключения пересылки IP через систему управления;
смена значения флага PerformRouterDiscovery = FALSE на TRUE через систему управления.

IP-адресом получателя запросов является настроенный для интерфейса параметр SolicitationAddress. IP-адресом источника может быть адрес интерфейса или 0, если хост ещё не определил адрес интерфейса.

Если хост передаёт запрос по одному из указанных выше событий, ему следует задержать отправку на случайное время из диапазона 0 – MAX_SOLICITATION_DELAY. Это позволяет избежать перегрузки при одновременном запуске на канале множества хостов, что может происходить при восстановлении питания после отказа. Хостам рекомендуется при генерации случайного значения включать в качестве затравки то или иное уникальное значение, например адрес IP или канального уровня. Хотя диапазон случайных значений задан целыми числами, для задержки лучше использовать значения , соответствующие дискретности таймера. Хост может отложить запросы по событиям до момента, когда ему впервые потребуется принятый по умолчанию маршрутизатор.

При получении действительного анонса хотя бы с одним адресом, имеющим отличный от hex 80000000 уровень предпочтения, после какого-либо из указанных выше событий, хост должен воздержаться от передачи каких-либо запросов через принявший анонс интерфейс (даже если запросы ещё не передавались), пока снова не произойдёт какое-либо из указанных событий. Несколько разрешённых повторов запроса при отсутствии анонсов следует отправлять с интервалами SOLICITATION_INTERVAL без внесения случайной задержки.

6. Константы протокола

Константы маршрутизаторов

         MAX_INITIAL_ADVERT_INTERVAL       16 секунд
         MAX_INITIAL_ADVERTISEMENTS        3 передачи
         MAX_RESPONSE_DELAY                2 секунды

Константы хостов

         MAX_SOLICITATION_DELAY            1 секунда
         SOLICITATION_INTERVAL             3 секунды
         MAX_SOLICITATIONS                 3 передачи

Дополнительные константы протокола определены форматами сообщений в разделе 3 и переменными конфигурации маршрутизаторов и хостов в параграфах 4.1 и 5.1. Константы протокола могут быть изменены в будущих версиях.

7. Вопросы безопасности

Это расширение ICMP позволяет любой системе, подключённой к каналу, представлять себя заданным по умолчанию маршрутизатором для хостов, подключённых к этому каналу. Любой трафик, переданный такому самозванцу, может быть перехвачен, отброшен или изменён путём внедрения, удаления или изменения пакетов. Следует отметить, что для большинства групповых и широковещательных каналов, где предполагается использование протокола, прослушивание пакетов уже доступно любой системе, подключённой к каналу, а используемый на каналах протокол распознавания адресов (Address Resolution Protocol или ARP) даёт аналогичные возможности вызвать отказ в обслуживании и изменение потока сообщений. Для сред, где такие угрозы неприемлемы, имеются переменные конфигурации, позволяющие отключить на хостах динамическое обнаружение маршрутизаторов.

Формат сообщений Router Advertisement определён так, что в сообщение можно добавлять дополнительную информацию совметимым с прежними версиями путём. Одним из вариантов использования такой возможности является добавление цифровых подписей или иной формы аутентификации анонсов, чтобы хосты могли проверить их подлинность. Этот вопрос оставлен для дополнительного изучения.

Литература

[1] Braden, R., Editor, “Requirements for Internet Hosts — Communication Layers”, RFC 1122, USC/Information Sciences Institute, October 1989.

[2] Braden, R., and J. Postel, “Requirements for Internet Gateways”, RFC 1009, USC/Information Sciences Institute, June 1987.

[3] Croft, B, and J. Gilmore, “Bootstrap Protocol (BOOTP)”, RFC 951, Stanford and SUN Microsystems, September 1985.

[4] Deering, S., “Host Extensions for IP Multicasting”, RFC 1112, Stanford University, August 1989.

[5] Finlayson, R., Mann, T., Mogul J., and M. Theimer, “A Reverse Address Resolution Protocol”, RFC 903, Stanford University, June 1984.

[6] Mogul, J., “Broadcasting Internet Datagrams”, RFC 919, Stanford University, October 1984.

[7] Mogul J., and J. Postel, “Internet Standard Subnetting Procedure”, RFC 950, USC/Information Sciences Institute, August 1985.

[8] Piscitello D., and J. Lawrence, “Transmission of IP datagrams over the SMDS Service”, RFC 1209, Bell Communications Research, March, 1991.

[9] Postel, J., “Internet Protocol – DARPA Internet Program Protocol Specification”, RFC 791, DARPA, September 1981.

[10] Postel, J., “Internet Control Message Protocol – DARPA Internet Program Protocol Specification”, RFC 792, USC/Information Sciences Institute, September 1981.

[11] Reynolds, J., “BOOTP Vendor Information Extensions”, RFC 1084, USC/Information Sciences Institute, December 1988.

Адрес автора

Stephen E. Deering

Xerox Palo Alto Research Center

3333 Coyote Hill Road

Palo Alto, CA 94304

Phone: (415) 494-4839

EMail: deering@xerox.com

Комментарии к документу можно направлять по адресу gw-discovery@gregorio.stanford.edu.

Перевод на русский язык

nmalykh@protokols.ru