RFC 826¶

RFC 826 — это документ, опубликованный в ноябре 1982 года в серии Request for Comments (RFC) Инженерного совета Интернета (IETF), который определяет протокол разрешения адресов (Address Resolution Protocol, ARP). Документ, написанный Дэвидом К. Пламмером, формально называется «An Ethernet Address Resolution Protocol» и описывает метод динамического сопоставления сетевых адресов (например, IP-адресов) с аппаратными адресами (например, MAC-адресами) в локальных сетях. RFC 826 является одним из фундаментальных стандартов, лежащих в основе работы сетей Ethernet и стека протоколов TCP/IP.

¶История и контекст создания

К началу 1980-х годов сеть ARPANET и развивающиеся локальные сети столкнулись с проблемой несовместимости адресации. Протокол IP (IPv4) использовал 32-битные адреса для идентификации узлов в сети, но на канальном уровне, особенно в сетях Ethernet, для передачи данных требовались 48-битные MAC-адреса (Media Access Control). Необходимо было найти способ автоматического преобразования одного набора адресов в другой без ручной настройки таблиц на каждом узле.

Дэвид К. Пламмер, работавший в корпорации Bolt, Beranek and Newman (BBN), предложил решение, которое позволяло узлам сети самостоятельно узнавать соответствие между IP- и MAC-адресами. Первоначальная версия RFC 826 была опубликована в 1982 году (с датой ноябрь 1982). Позднее, в 1984 году, вышла уточнённая версия, которая стала стандартом (STD 37). С тех пор RFC 826 многократно дополнялся, но его основная концепция осталась неизменной и используется до сих пор.

¶Основные положения протокола (ARP)

ARP, описанный в RFC 826, работает на канальном уровне модели OSI (уровень 2) и предназначен для разрешения адресов в пределах одной локальной сети (broadcast domain). Протокол не маршрутизируется через маршрутизаторы, так как оперирует только в рамках одного сегмента.

¶1. Формат сообщения ARP

Сообщение ARP имеет фиксированную структуру, которая включает следующие поля:

• Тип аппаратного адреса (Hardware Type, 2 байта) — указывает тип канального протокола (например, 1 для Ethernet).
• Тип протокола (Protocol Type, 2 байта) — указывает вышестоящий сетевой протокол (например, 0x0800 для IPv4).
• Длина аппаратного адреса (Hardware Address Length, 1 байт) — для Ethernet — 6 байт.
• Длина протокольного адреса (Protocol Address Length, 1 байт) — для IPv4 — 4 байта.
• Код операции (Operation Code, 2 байта) — определяет тип сообщения: 1 — запрос (ARP Request), 2 — ответ (ARP Reply).
• Аппаратный адрес отправителя (Sender Hardware Address) — MAC-адрес узла, отправляющего сообщение.
• Протокольный адрес отправителя (Sender Protocol Address) — IP-адрес узла, отправляющего сообщение.
• Аппаратный адрес получателя (Target Hardware Address) — в запросе обычно заполнен нулями, в ответе — MAC-адрес искомого узла.
• Протокольный адрес получателя (Target Protocol Address) — IP-адрес, который требуется разрешить.

¶2. Принцип работы

Процесс разрешения адреса с помощью ARP состоит из следующих этапов:

1. Инициализация запроса: Когда узел A (с IP-адресом 192.168.1.10 и MAC-адресом AA:AA:AA:AA:AA:AA) хочет отправить данные узлу B (с IP-адресом 192.168.1.20), он проверяет свою ARP-таблицу (кэш ARP). Если соответствия для IP-адреса 192.168.1.20 нет, узел A формирует ARP-запрос.
2. Широковещательная рассылка: Запрос отправляется на широковещательный MAC-адрес (FF:FF:FF:FF:FF:FF). В поле «Протокольный адрес получателя» указывается IP-адрес узла B (192.168.1.20), а поле «Аппаратный адрес получателя» заполняется нулями. Все узлы в сегменте сети получают этот кадр.
3. Обработка запроса: Каждый узел, получивший широковещательный запрос, сравнивает свой IP-адрес с адресом получателя в запросе. Если адрес не совпадает, узел игнорирует запрос (за исключением некоторых случаев, например, при использовании Proxy ARP).
4. Формирование ответа: Узел B, обнаружив совпадение, формирует ARP-ответ. В этом ответе он указывает свой MAC-адрес (BB:BB:BB:BB:BB:BB) в поле «Аппаратный адрес отправителя». Ответ отправляется напрямую узлу A (на его MAC-адрес AA:AA:AA:AA:AA:AA), а не широковещательно.
5. Обновление кэша: Узел A получает ответ, извлекает из него MAC-адрес узла B и сохраняет соответствие (192.168.1.20 -> BB:BB:BB:BB:BB:BB) в своей ARP-таблице. После этого узел A может отправлять данные непосредственно узлу B, используя его MAC-адрес.

¶3. Кэш ARP (ARP Cache)

Для повышения эффективности и снижения широковещательного трафика каждый узел хранит таблицу соответствий IP- и MAC-адресов, называемую ARP-кэшем. Записи в кэше имеют ограниченное время жизни (TTL, Time to Live). По истечении TTL запись удаляется, и при необходимости отправки данных узел повторяет процедуру разрешения. Типичное время жизни записи в современных операционных системах составляет от 20 секунд до нескольких минут для динамических записей. Существуют также статические записи, которые вносятся вручную и не удаляются автоматически.

¶Модификации и расширения

С момента публикации RFC 826 появилось несколько расширений и модификаций протокола ARP:

• Proxy ARP: Технология, при которой маршрутизатор отвечает на ARP-запросы от имени узлов, находящихся за ним. Это позволяет узлам в одной подсети «видеть» друг друга, даже если они физически разделены маршрутизатором. Proxy ARP описан в RFC 1027.
• Gratuitous ARP: Сообщение ARP-ответа, которое узел отправляет сам себе (или широковещательно) для обновления ARP-таблиц других узлов. Используется при смене MAC-адреса или IP-адреса на узле, а также для обнаружения дублирования IP-адресов (DAD, Duplicate Address Detection).
• Inverse ARP (InARP): Протокол, обратный ARP, который позволяет узнать IP-адрес по известному MAC-адресу. Описан в RFC 2390, применяется в сетях Frame Relay.
• Reverse ARP (RARP): Устаревший протокол, использовавшийся для определения IP-адреса бездисковыми рабочими станциями по их MAC-адресу. Вытеснен протоколом BOOTP и DHCP.

¶Уязвимости и безопасность

Протокол ARP, как он описан в RFC 826, не имеет механизмов аутентификации. Это делает его уязвимым для атак типа «человек посередине» (Man-in-the-Middle, MITM) и отказа в обслуживании (DoS). Основные угрозы:

• ARP-спуфинг (ARP-отравление): Злоумышленник отправляет поддельные ARP-ответы, связывая свой MAC-адрес с IP-адресом другого узла (например, шлюза). В результате трафик жертвы перенаправляется на компьютер злоумышленника.
• ARP-флуд: Злоумышленник отправляет большое количество поддельных ARP-запросов или ответов, перегружая ARP-кэш коммутатора или узла, что может привести к отказу в обслуживании.

Для защиты от этих атак применяются методы статической ARP-таблицы, динамическое обнаружение атак (например, с помощью систем IDS/IPS), а также протоколы безопасного ARP, такие как S-ARP (Secure ARP).

¶Современное состояние

Несмотря на свой почтенный возраст (более 40 лет), RFC 826 остаётся действующим стандартом. Протокол ARP является неотъемлемой частью стека TCP/IP и используется в большинстве локальных сетей на базе Ethernet. Однако с внедрением протокола IPv6 его роль изменилась. В IPv6 функции разрешения адресов выполняет протокол Neighbor Discovery Protocol (NDP), описанный в RFC 4861, который решает те же задачи, но с улучшенной безопасностью и функциональностью. В сетях IPv4 ARP остаётся основным механизмом сопоставления адресов.

¶Источники

• Plummer, D. (1982). An Ethernet Address Resolution Protocol. RFC 826. IETF.
• Postel, J. (1981). Internet Protocol. RFC 791. IETF.
• Mogul, J. (1984). Internet Standard Subnetting Procedure. RFC 950. IETF.
• Braden, R. (1989). Requirements for Internet Hosts — Communication Layers. RFC 1122. IETF.
• Narten, T., Nordmark, E., Simpson, W., & Soliman, H. (2007). Neighbor Discovery for IP version 6 (IPv6). RFC 4861. IETF.
• Stevens, W. R. (1994). TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley.