RFC: 919
Оригинал: Broadcasting Internet Datagrams
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 919, Страница 6 из 7

6. Шлюзы и рассылка широковещательных дейтаграмм

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

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

  • Основным правилом предотвращения петель является следующее: «никогда не пересылать дейтаграмму в широковещательном режиме в физическую сеть, из которой она была принята.» Это правило позволяет избавиться от повтора дейтаграмм, которые шлюз принял от самого себя. Однако, этого недостаточно, чтобы предотвратить петли при наличии нескольких шлюзов в одной физической сети.
  • Если дейтаграмма получена из физической сети, в которую она адресована, такую дейтаграмму не следует пересылать. Однако, шлюзу следует рассматривать себя как получателя дейтаграмм (например, при рассылке маршрутных обновлений).
  • В остальных случаях, если дейтаграмма адресована в физическую сеть, к которой подключен шлюз, она должна быть передана в эту сеть с использованием широковещательной адресации на канальном уровне. Шлюз в этом случае так же должен рассматривать себя как получателя дейтаграммы.
  • В противном случае шлюз должен использовать обычную процедуру маршрутизации для выбора следующего шлюза и передать дейтаграмму выбранному маршрутизатору.

7. Широковещательная адресация IP — предложенные стандарты

Для совместимости реализаций IP они должны поддерживать специальный номер для обозначения всех хостов сети (all hosts).

Поскольку сетевой уровень локальной сети всегда отображает адреса IP на адреса канального уровня, выбор широковещательного номера IP (broadcast host number) является в какой-то степени произвольным. Для простоты этот номер не должен совпадать ни с одним из реальных номеров хостов. Номер, содержащий только «1», удовлетворяет этому требованию; использование таких номеров для широковещания было впервые предложено в работе [6]. Такие номера достаточно редко используются для реальных хостов, поэтому использование этого номера для широковещательной рассылки скорей всего не потребует каких-либо изменений в конфигурации сети.

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

Таким образом, хост сети с номером 36 (например) может:
  • Рассылать дейтаграммы своим непосредственным соседям по локальной сети, используя адрес 255.255.255.255
  • Рассылать широковещательные дейтаграммы по всей сети 36, используя адрес 36.255.255.255

Если «все единицы» в поле адреса IP используются для широковещания, значение «все нули» можно использовать для неуказанного адреса (unspecified). Возможно это является причиной появления таких значений в поле отправителя дейтаграмм ICMP Information Request. Однако в соответствии с соглашением о нотации такие адреса (все нули) используются для обозначения сетей. Например, 36.0.0.0 означает "сеть номер 36", а 36.255.255.255 — широковещательный адрес «все хосты сети 36".

Страница 6 из 7

2007 - 2022 © Русские переводы RFC, IETF, ISOC.