Кратко

  • RFC 919 выбрал поле хоста, заполненное единицами, для значения «все хосты» и определил 255.255.255.255 как локальный broadcast, который нельзя пересылать.
  • RFC 922 распространил эту схему на подсети без изменения формата IP-дейтаграммы.
  • RFC 1122 стандартизировал отправку форм с единицами и рекомендовал приёмникам распознавать старые формы с нулями.

Когда адрес назначения перестал обозначать один компьютер

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

Служба оставалась ненадёжной: дейтаграмма могла потеряться, прийти не по порядку или повториться. Каждый слушающий хост также тратил ресурсы на обработку, поэтому это не был надёжный групповой транспорт.

Почему выбрали единицы

Для совместимости требовался номер хоста со значением «все хосты». RFC 919 выбрала значение, состоящее из одних единиц, поскольку оно вряд ли уже принадлежало реальному компьютеру.

255.255.255.255 обозначал все хосты подключённой физической сети и не должен был пересылаться. Адрес 36.255.255.255, напротив, обозначал все хосты сети 36: шлюз мог доставить дейтаграмму туда и только затем преобразовать её в широковещание канального уровня. Область определялась положением битов в иерархии адреса.

Нулевые поля сохраняли значения «не задано» и обозначение сети. Стандарт выбрал единицы, но не мог мгновенно устранить старые реализации, использовавшие нули.

Иерархия подсетей

RFC 922 распространила ту же логику на поля сети, подсети и хоста, не меняя IP-дейтаграмму. В зависимости от полей, заполненных единицами, и действующей маски адрес мог охватывать локальную физическую сеть, удалённую физическую сеть, конкретную подсеть или все подсети IP-сети. Шлюзам также запрещалось повторно передавать дейтаграмму в физическую сеть, из которой она пришла.

Распознавание требовалось и на границе ARP. ARP-сервер не должен был отвечать на запрос к широковещательному адресу: не распознавший специальное назначение хост мог создать петлю и резко увеличить число повторных передач.

Стандартные отправители и терпимые приёмники

RFC 1122 определила четыре стандартные формы: ограниченное широковещание {-1,-1}, направленное к сети {network,-1}, направленное к подсети {network,subnet,-1} и направленное ко всем подсетям {network,-1,-1}.

Хосты обязаны были распознавать стандартные формы; для совместимости им рекомендовалось принимать и нестандартные варианты, где -1 заменён нулями, включая варианты систем на базе 4.2BSD. Интерфейс мог выбрать форму отправки, но по умолчанию следовало использовать все единицы.

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

Почему ограниченная область была устойчивее

RFC 1122 рекомендовала ограниченное широковещание для подключённой сети. Оно не зависело от того, одинаково ли все машины понимают номер сети и маску. Пересылка направленного широковещания оставалась политикой шлюза, зависящей от безопасности и производительности.

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

Источники