Кратко

  • RFC 903 решал конкретную задачу холодного старта: бездисковый узел знал аппаратный адрес, но перед использованием IP должен был получить протокольный адрес.
  • RARP выполнял запрос на канальном уровне. Сервер отвечал по поддерживаемой им таблице соответствий аппаратных и протокольных адресов; ответ не удостоверял устройство и не доказывал, что загрузка завершилась.
  • Явного ответа «не найдено» протокол не предусматривал. При отсутствии ответа клиент ждал тайм-аут и не мог понять, отсутствовала ли запись, потерялся ли пакет или не ответил сервер.
  • RFC 950 и BOOTP показывают, почему одного адреса недостаточно для настройки узла: могли понадобиться шлюз, сервер имён, маска подсети и файл загрузки.

Первый вопрос возникал до IP

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

В RFC 903, опубликованном в июне 1984 года, Ross Finlayson, Timothy Mann, Jeffrey Mogul и Marvin Theimer предложили RARP. В документе описан хост, который запрашивает свой протокольный адрес у внешнего источника через широковещательную среду вроде Ethernet. ARP решал обратную задачу: находил аппаратный адрес, когда протокольный уже известен. RARP начинал с аппаратного адреса и спрашивал соответствующий протокольный.

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

Ответ хранился у локального сервера

RFC 903 намеренно определил RARP как отдельный протокол канального уровня. Он повторно использовал формат пакета ARP, но назначил отдельные коды операций для обратного запроса и ответа. Когда хост запрашивал собственный адрес, он помещал один и тот же аппаратный адрес в поля отправителя и цели. Сервер, знавший этот адрес, мог вернуть соответствующий протокольный адрес.

Ответ зависел от состояния сервера. RFC говорит, что один или несколько серверов RARP ведут базу соответствий аппаратных и протокольных адресов. Обычный ARP устроен иначе: хосты накапливают соответствия адресов соседних узлов в кэше, и роли клиента с сервером не разделяются. Поэтому RARP вводил операционную зависимость: клиент мог спросить, но кто-то на месте должен был поддерживать таблицу сервера в рабочем состоянии.

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

Молчание не означало «не найдено»

RFC 903 определяет обратные запросы и ответы, но не пакет «не найдено» или сообщения об ошибке. Авторы объясняют это тем, что отвечать могут несколько серверов. Вместо отдельного отказа RFC требует от запрашивающего дождаться тайм-аута, если ответ не приходит в разумный срок.

Так обмен оставался небольшим, но наблюдение клиента было неоднозначным. Тайм-аут мог означать, что запись отсутствует; могли также потеряться запрос или ответ, не работать канал или быть недоступны все серверы. Молчание не различало эти случаи. Запись в журнале загрузки «тайм-аут RARP» сама по себе не устанавливала причину.

При разборе сбоя эта граница важна. Отсутствие ответа показывает, что получил клиент — ничего, — но не доказывает, что адрес не был назначен. Исходный документ ясно обозначает предел, хотя и не задаёт диагностику для разделения всех причин.

Одного адреса не хватало для настройки хоста

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

BOOTP, специфицированный годом позже, сохранил поиск IP по аппаратному адресу и добавил возможность передавать больше загрузочной информации, в том числе необязательное имя файла. Его схема также позволяла загрузку через шлюзы. RFC 951 прямо сопоставляет подход IP/UDP с аппаратными пакетами RARP канального уровня и специальными изменениями ядра или драйвера для доступа к таким пакетам. RFC 1542 позднее уточнил работу ретрансляторов BOOTP; RFC 2131 описывает DHCP как развитие BOOTP с автоматическим выделением повторно используемых адресов и параметрами конфигурации.

Эта последовательность не доказывает, что все сети отказались от RARP в один день. Она показывает, как изменился вопрос: узнать заранее заданный адрес было полезно, но загрузка через маршрутизируемые сети требовала более широкого обмена и пути ретрансляции.

Запись — не само устройство

Заметка 72 Хенга Лу даёт более позднюю аналитическую рамку, а не свидетельство о 1984 годе: запись описывает реальность, но не создаёт её. RARP не был глобальным реестром, однако это различие применимо и здесь. Таблица сервера координировала локальное соответствие, но не превращала выданный адрес в доказательство владения оборудованием, личности пользователя или успешной работы.

Исторический вклад протокола был уже и практичнее. Хост мог обратиться к уже доступному ему каналу за единственным адресом, нужным для начала IP-обмена. Ограничение было и затратой: локальные соответствия требовали обслуживания, молчание не объясняло себя, а ответ не составлял полную конфигурацию.

Источники

RFC 903 — A Reverse Address Resolution Protocol; RFC 826 — An Ethernet Address Resolution Protocol; RFC 950 — Internet Standard Subnetting Procedure; RFC 951 — Bootstrap Protocol; RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol; RFC 2131 — Dynamic Host Configuration Protocol. Заметка 72 — более поздняя редакционная рамка, а не исторический источник.