Reverse ARP RARP

Reverse ARP (RARP) — это протокол сетевого уровня стека TCP/IP, предназначенный для обратного разрешения адресов: получения IP-адреса по известному MAC-адресу. В отличие от протокола ARP (Address Resolution Protocol), который отображает IP-адрес на физический адрес в локальной сети, RARP решает обратную задачу — позволяет сетевому устройству, не имеющему собственного IP-адреса (например, бездисковому рабочему станции при загрузке через сеть), выяснить свой IP-адрес путём запроса к RARP-серверу. Протокол был описан в RFC 903 (1984 год) и активно применялся в ранних реализациях бездисковых клиентов, но позже был вытеснен более функциональными протоколами, такими как BOOTP и DHCP.

Принцип работы

RARP работает на канальном уровне (уровень 2) модели OSI, используя непосредственно физический носитель (например, Ethernet). Формат пакета RARP идентичен формату пакета ARP, за исключением поля номера операции (OP): для RARP используются коды 3 (RARP-запрос) и 4 (RARP-ответ). Пакет содержит MAC-адрес отправителя и заполнитель для IP-адреса; при запросе IP-адресное поле заполняется нулями.

Процесс разрешения выглядит следующим образом:

1. Устройство отправляет широковещательный RARP-запрос на MAC-адрес FF:FF:FF:FF:FF:FF (все узлы сегмента сети). В запросе указываются собственный MAC-адрес источника и нулевой IP-адрес.
2. Все устройства в локальной сети получают этот широковещательный кадр, но обрабатывает его только RARP-сервер (или серверы, настроенные отвечать на такие запросы). Сервер сопоставляет MAC-адрес из запроса со своей таблицей (обычно файл /etc/ethers в системах Unix) и находит соответствующий ему IP-адрес.
3. Сервер отправляет RARP-ответ напрямую (unicast) на MAC-адрес запрашивающего устройства, содержащий присвоенный IP-адрес и MAC-адрес клиента.
4. Устройство получает ответ, извлекает IP-адрес и настраивает свой сетевой интерфейс.

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

Формат пакета RARP

Пакет RARP (и ARP) имеет фиксированную структуру (для Ethernet и IPv4):

• Тип оборудования (HRD) — 2 байта, для Ethernet — 1.
• Тип протокола (PRO) — 2 байта, для IPv4 — 0x0800.
• Длина аппаратного адреса (HLN) — 1 байт, для Ethernet — 6.
• Длина протокольного адреса (PLN) — 1 байт, для IPv4 — 4.
• Операция (OP) — 2 байта: 3 — RARP-запрос, 4 — RARP-ответ.
• Аппаратный адрес отправителя (SHA) — 6 байт (MAC-адрес клиента в запросе, MAC-адрес сервера в ответе).
• Протокольный адрес отправителя (SPA) — 4 байта (для запроса — обычно 0, для ответа — IP-адрес сервера).
• Аппаратный адрес получателя (THA) — 6 байт (MAC-адрес сервера в запросе, MAC-адрес клиента в ответе).
• Протокольный адрес получателя (TPA) — 4 байта (для запроса — 0, для ответа — запрошенный IP-адрес клиента).

Длина всего пакета при Ethernet и IPv4 составляет 28 байт (без учёта заголовка Ethernet).

История и применение

RARP был разработан как одно из решений проблемы автоматической настройки IP-адресов для бездисковых рабочих станций, которые не могли хранить конфигурацию в локальном хранилище. Такие устройства (например, терминалы X-Window или ранние персональные компьютеры) при загрузке через сеть (по протоколам BOOTP или TFTP) сначала должны были получить свой IP-адрес.

В конце 1980-х — начале 1990-х годов RARP широко применялся в локальных сетях Ethernet для запуска бездисковых станций. Протокол был прост в реализации и не требовал сложного программного обеспечения: RARP-сервер мог быть запущен на любом Unix-подобном хосте с минимальной настройкой (например, демон rarpd). Однако у RARP были существенные недостатки, которые привели к его постепенному вытеснению.

Ограничения RARP

Основные недостатки протокола:

• Отсутствие поддержки маршрутизации: RARP-пакеты не проходят через слой IP (они отправляются как широковещательные кадры канального уровня), поэтому сервер должен находиться в той же подсети. Для работы с удалёнными серверами RARP непригоден.
• Только IP-адрес: протокол передаёт только IP-адрес. Устройство не получает маску подсети, шлюз по умолчанию, адрес сервера DNS, имена доменов или другую конфигурацию, необходимую для сетевой работы.
• Широковещательная нагрузка: каждый запрос генерирует широковещательный кадр, который доходит до всех узлов сегмента, что может создавать избыточный трафик в больших сетях.
• Отсутствие защиты: RARP не предусматривает аутентификации или шифрования, что делает его уязвимым для атак с подменой ответов (spoofing). Любой узел в сети может выдать себя за RARP-сервер.
• Необходимость статической таблицы: RARP-сервер опирается на предварительно настроенную таблицу соответствий MAC–IP, которая должна администрироваться вручную. Это плохо масштабируется для сетей с большим количеством устройств.

Сравнение с другими протоколами

RARP по функциональности является предшественником и аналогом следующих протоколов:

• ARP (Address Resolution Protocol) — зеркальное решение: ARP отображает IP→MAC, RARP — MAC→IP. ARP используется до сих пор в каждой IP-сети, а RARP устарел.
• BOOTP (Bootstrap Protocol) — протокол, принятый в 1985 году (RFC 951), который расширяет функционал RARP: передаёт не только IP-адрес, но и маску, шлюз, адрес сервера загрузки и дополнительные параметры через опции. BOOTP может работать как через локальную сеть, так и через маршрутизаторы (используя UDP и IP), а также допускает ретрансляторы пакетов (relay). Это делает BOOTP гораздо более гибким, чем RARP.
• DHCP (Dynamic Host Configuration Protocol) — протокол, развился из BOOTP и стандартизирован в 1993 году (RFC 1531, затем современные версии). DHCP обеспечивает полную автоматизацию настройки IP-адресов и других параметров, включая поддержку динамической аренды адресов (lease), широковещательных адресов, DNS-серверов и множество опций. DHCP является современным стандартом для автоматической конфигурации сетевых устройств.

Таким образом, RARP выполнял узкоспециализированную задачу, которая лучше решается более современными протоколами с дополнительными функциями. BOOTP и DHCP полностью покрыли потребности RARP и вытеснили его из практического применения.

Современный статус

Начиная с 1990-х годов, RARP считается устаревшим. Большинство операционных систем (включая Linux, Windows, macOS) либо удалили поддержку RARP из ядра, либо не включают её по умолчанию. Однако некоторые встраиваемые системы (например, ранние устройства на базе RTOS) или старые промышленные контроллеры всё ещё могут использовать RARP в случае отсутствия поддержки DHCP из-за ограниченности ресурсов.

В современных сетях IP-адресация сетевых устройств практически повсеместно выполняется через DHCP. Для начальной загрузки бездисковых станций также применяется PXE (Preboot eXecution Environment), который использует DHCP и TFTP, а не RARP.

Пример реализации

В операционных системах семейства Unix (FreeBSD, Linux) поддержка RARP реализуется через демон rarpd. Для работы необходимо настроить файл /etc/ethers, где указываются пары MAC–IP. Затем сервер запускает rarpd на определённом интерфейсе, и он прослушивает RARP-запросы. Пример содержимого /etc/ethers:

`` 00:1A:2B:3C:4D:5E 192.168.1.10 00:1A:2B:3C:4D:5F 192.168.1.11 ``

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

Протоколы, родственные RARP

Следует также упомянуть протокол INARP (Inverse ARP), который решает задачу, аналогичную RARP, но в контексте Frame Relay (определён в RFC 1293). Он не имеет прямого отношения к Ethernet и TCP/IP. Кроме того, протокол Proxy RARP позволяет одному узлу отвечать на RARP-запросы от имени других узлов (например, сетевой мост может перенаправлять запросы), но это решение не получило широкого распространения.

Источники

1. RFC 903 — A Reverse Address Resolution Protocol (1984).
2. RFC 951 — Bootstrap Protocol (BOOTP) (1985).
3. RFC 2131 — Dynamic Host Configuration Protocol (1997).
4. Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, 1994.
5. Comer, Douglas E. Internetworking with TCP/IP, Volume 1: Principles, Protocols, and Architecture. Prentice Hall, 2000 (особенно главы про ARP и RARP).
6. Многотомное руководство по сетевым протоколам — материалы IETF Working Group.