stringtranslate.com

Протокол разрешения адресов

Протокол разрешения адресов ( ARP ) — это протокол связи, используемый для обнаружения адреса канального уровня , например MAC-адреса , связанного с заданным адресом интернет-уровня , обычно адресом IPv4 . Это сопоставление является важнейшей функцией в наборе интернет-протоколов . ARP был определен в 1982 году в RFC  826, [1] , который является интернет-стандартом STD 37.

ARP требуется, когда хост хочет отправить пакет IPv4 на другой узел в той же сети, но пока не знает MAC-адрес этого узла. Хост рассылает запрос ARP, содержащий IP-адрес узла, а узел с соответствующим IP-адресом возвращает ответ ARP, содержащий его MAC-адрес.

ARP был реализован с использованием множества комбинаций сетевых и канальных технологий, таких как IPv4 , Chaosnet , DECnet и Xerox PARC Universal Packet (PUP) с использованием стандартов IEEE 802 , FDDI , X.25 , Frame Relay и асинхронного режима передачи (ATM).

В сетях IPv6 функциональность ARP обеспечивается протоколом обнаружения соседей (NDP).

Операционная сфера

Протокол разрешения адресов — это протокол типа «запрос-ответ» . Его сообщения напрямую инкапсулируются протоколом канального уровня. Он передается в пределах одной подсети и никогда не маршрутизируется .

Структура пакета

Протокол разрешения адресов использует простой формат сообщения, содержащий один запрос или ответ на разрешение адресов. Пакеты переносятся на уровне канала передачи данных базовой сети как сырая полезная нагрузка. В случае Ethernet для идентификации кадров ARP используется значение 0x0806 EtherType .

Размер сообщения ARP зависит от размеров адресов канального и сетевого уровней. Заголовок сообщения определяет типы сетей, используемых на каждом уровне, а также размер адресов каждого из них. Заголовок сообщения дополняется кодом операции для запроса (1) и ответа (2). Полезная нагрузка пакета состоит из четырех адресов, аппаратного и протокольного адреса хостов отправителя и получателя.

Основная структура пакетов ARP показана в следующей таблице, которая иллюстрирует случай сетей IPv4, работающих на Ethernet. В этом сценарии пакет имеет 48-битные поля для аппаратного адреса отправителя (SHA) и целевого аппаратного адреса (THA), а также 32-битные поля для соответствующих адресов протоколов отправителя и цели (SPA и TPA). Размер пакета ARP в этом случае составляет 28 байт.

Тип оборудования  (HTYPE): 16 бит
В этом поле указывается тип протокола сетевого соединения. [2] В этом примере значение 1 указывает Ethernet .
Тип протокола  (PTYPE): 16 бит
Это поле определяет межсетевой протокол, для которого предназначен запрос ARP. Для IPv4 это имеет значение 0x0800 . Разрешенные значения PTYPE разделяют пространство нумерации с значениями для EtherType . [2] [3]
Длина оборудования  (HLEN): 8 бит
Длина (в октетах ) аппаратного адреса. Для Ethernet длина адреса составляет 6 .
Длина протокола  (PLEN): 8 бит
Длина (в октетах) межсетевых адресов. Межсетевой протокол указан в PTYPE. В этом примере: длина адреса IPv4 равна 4 .
Операция  (OPER): 16 бит
Указывает операцию, которую выполняет отправитель: 1 для запроса, 2 для ответа.
Аппаратный адрес отправителя  (SHA): 48 бит
Медиа-адрес отправителя. В запросе ARP это поле используется для указания адреса хоста, отправляющего запрос. В ответе ARP это поле используется для указания адреса хоста, который искал запрос.
Адрес протокола отправителя  (SPA): 32 бита
Межсетевой адрес отправителя.
Целевой аппаратный адрес  (THA): 48 бит
Медиа-адрес предполагаемого получателя. В запросе ARP это поле игнорируется. В ответе ARP это поле используется для указания адреса хоста, который инициировал запрос ARP.
Адрес целевого протокола  (TPA): 32 бита
Межсетевой адрес предполагаемого получателя.

Значения параметров протокола ARP стандартизированы и поддерживаются Администрацией по распределению адресов в Интернете (IANA). [2]

EtherType для ARP — 0x0806 . Он появляется в заголовке кадра Ethernet, когда полезная нагрузка представляет собой пакет ARP, и его не следует путать с PTYPE, который появляется в этом инкапсулированном пакете ARP .

Наслаивание

Размещение ARP в наборе протоколов Интернета и модели OSI может быть предметом путаницы или даже спора. RFC  826 помещает его на уровень канала связи и характеризует его как инструмент для запроса информации о «уровне более высокого уровня», таком как уровень Интернета. [4] RFC  1122 также обсуждает ARP в разделе уровня канала связи. [5] Ричард Стивенс помещает ARP на уровень канала связи OSI [6], в то время как более новые издания связывают его с сетевым уровнем или вводят промежуточный уровень OSI 2.5. [7]

Пример

Два компьютера в офисе ( Компьютер 1 и Компьютер 2 ) соединены друг с другом в локальной сети с помощью кабелей Ethernet и сетевых коммутаторов без промежуточных шлюзов или маршрутизаторов . Компьютер 1 должен отправить пакет на Компьютер 2. Через DNS он определяет, что Компьютер 2 имеет IP-адрес 192.168.0.55 .

Для отправки сообщения ему также требуется MAC -адрес компьютера 2. Во-первых, компьютер 1 использует кэшированную таблицу ARP для поиска 192.168.0.55 для любых существующих записей MAC-адреса компьютера 2 ( 00:EB:24:B2:05:AC ). Если MAC-адрес найден, он отправляет кадр Ethernet , содержащий IP-пакет, по каналу с адресом назначения 00:EB:24:B2:05:AC . Если кэш не выдал результата для 192.168.0.55 , компьютер 1 должен отправить широковещательное сообщение-запрос ARP (MAC-адрес назначения FF:FF:FF:FF:FF:FF ), которое принимается всеми компьютерами в локальной сети, запрашивая ответ для 192.168.0.55 .

Компьютер 2 отвечает сообщением ARP-ответа, содержащим его MAC- и IP-адреса. В рамках обработки запроса Компьютер 2 может вставить запись для Компьютера 1 в свою таблицу ARP для будущего использования.

Компьютер 1 получает и кэширует информацию об ответе в своей таблице ARP и теперь может отправить пакет. [8]

ARP-зонд

ARP -проба в IPv4 — это ARP-запрос, созданный с помощью SHA хоста-пробника, SPA из всех нулей, THA из всех нулей и TPA, установленного на IPv4-адрес, который проверяется. Если какой-либо хост в сети считает IPv4-адрес (в TPA) своим собственным, он ответит на пробу (через SHA хоста-пробника), тем самым сообщив хосту-пробнику о конфликте адресов. Если вместо этого нет хоста, который считает IPv4-адрес своим собственным, то ответа не будет. Когда было отправлено несколько таких проб с небольшими задержками, и ни одна не получила ответа, можно обоснованно ожидать, что конфликта не существует. Поскольку исходный пакет пробы не содержит ни действительной пары SHA/SPA, ни действительной пары THA/TPA, нет риска, что какой-либо хост будет использовать пакет для обновления своего кэша проблемными данными. Прежде чем начать использовать адрес IPv4 (полученный с помощью ручной настройки, DHCP или каким-либо другим способом), хост, реализующий эту спецификацию, должен проверить, используется ли уже этот адрес, с помощью широковещательной рассылки пакетов ARP-проб. [9] [10]

ARP-объявления

ARP также может использоваться как простой протокол объявлений. Это полезно для обновления сопоставлений аппаратного адреса других хостов при изменении IP-адреса или MAC-адреса отправителя. Такое объявление, также называемое сообщением gratuitous ARP (GARP), обычно транслируется как запрос ARP, содержащий SPA в целевом поле (TPA=SPA), с THA, установленным в ноль. Альтернативный способ — транслировать ответ ARP с SHA и SPA отправителя, дублированными в целевых полях (TPA=SPA, THA=SHA).

Объявления ARP-запроса и ARP-ответа являются стандартными методами, [11] : §4.6,  но метод запроса ARP является предпочтительным. [12] : §3  Некоторые устройства могут быть настроены для использования любого из этих двух типов объявлений. [13]

Объявление ARP не предназначено для запроса ответа; вместо этого оно обновляет любые кэшированные записи в таблицах ARP других хостов, которые получают пакет. Код операции в объявлении может быть либо запросом, либо ответом; стандарт ARP определяет, что код операции обрабатывается только после обновления таблицы ARP из полей адреса. [14] [11] : §4.6  [15] : §4.4.1 

Многие операционные системы выдают объявление ARP во время запуска. Это помогает решить проблемы, которые в противном случае возникли бы, например, если бы сетевая карта была недавно заменена (изменилась привязка IP-адреса к MAC-адресу), а другие хосты все еще имеют старое привязку в своих кэшах ARP.

ARP-объявления также используются некоторыми сетевыми интерфейсами для обеспечения балансировки нагрузки для входящего трафика. В группе сетевых карт он используется для объявления другого MAC-адреса в группе, который должен получать входящие пакеты.

Объявления ARP могут использоваться в протоколе Zeroconf для автоматического назначения локального адреса ссылки интерфейсу, где недоступна никакая другая конфигурация IP-адреса. Объявления используются для обеспечения того, чтобы выбранный хостом адрес не использовался другими хостами в сетевом соединении. [16]

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

посредничество ARP

Посредничество ARP относится к процессу разрешения адресов уровня 2 через виртуальную частную проводную службу (VPWS), когда на подключенных цепях используются разные протоколы разрешения, например, Ethernet на одном конце и Frame Relay на другом. В IPv4 каждое периферийное устройство провайдера (PE) обнаруживает IP-адрес локально подключенного периферийного устройства клиента (CE) и распределяет этот IP-адрес на соответствующее удаленное устройство PE. Затем каждое устройство PE отвечает на локальные запросы ARP, используя IP-адрес удаленного устройства CE и аппаратный адрес локального устройства PE. В IPv6 каждое устройство PE обнаруживает IP-адрес как локальных, так и удаленных устройств CE, а затем перехватывает локальные пакеты Neighbor Discovery (ND) и Inverse Neighbor Discovery (IND) и пересылает их на удаленное устройство PE. [17]

Обратный ARP и обратный ARP

Протокол обратного разрешения адресов ( Inverse ARP или InARP ) используется для получения адресов сетевого уровня (например, IP-адресов ) других узлов из адресов канального уровня (уровня 2). Поскольку ARP транслирует адреса уровня 3 в адреса уровня 2, InARP можно описать как его обратный. Кроме того, InARP реализован как расширение протокола ARP: он использует тот же формат пакета, что и ARP, но другие коды операций.

InARP в основном используется в сетях Frame Relay ( DLCI ) и ATM, в которых адреса уровня 2 виртуальных каналов иногда получаются из сигнализации уровня 2, а соответствующие адреса уровня 3 должны быть доступны до того, как эти виртуальные каналы можно будет использовать. [18]

Протокол обратного разрешения адресов (Reverse ARP или RARP), как и InARP, преобразует адреса уровня 2 в адреса уровня 3. Однако в InARP запрашивающая станция запрашивает адрес уровня 3 другого узла, тогда как RARP используется для получения адреса уровня 3 самой запрашивающей станции для целей настройки адреса. RARP устарел; он был заменен на BOOTP , который позже был заменен протоколом динамической конфигурации хоста (DHCP). [19]

ARP-спуфинг и прокси-ARP

Успешная атака с подменой ARP позволяет злоумышленнику выполнить атаку «человек посередине» .

Поскольку ARP не предоставляет методов аутентификации ответов ARP в сети, ответы ARP могут поступать от систем, отличных от той, у которой есть требуемый адрес уровня 2. Прокси-сервер ARP — это система, которая отвечает на запрос ARP от имени другой системы, для которой он будет пересылать трафик, обычно как часть дизайна сети, например, для коммутируемого интернет-сервиса. Напротив, при подмене ARP отвечающая система, или спуфер , отвечает на запрос адреса другой системы с целью перехвата данных, связанных с этой системой. Злонамеренный пользователь может использовать подмену ARP для выполнения атаки « человек посередине» или атаки типа «отказ в обслуживании» на других пользователей в сети. Существует различное программное обеспечение как для обнаружения, так и для выполнения атак подмены ARP, хотя сам ARP не предоставляет никаких методов защиты от таких атак. [20]

Альтернативы

IPv6 использует протокол Neighbor Discovery Protocol и его расширения, такие как Secure Neighbor Discovery , а не ARP.

Компьютеры могут поддерживать списки известных адресов, а не использовать активный протокол. В этой модели каждый компьютер поддерживает базу данных сопоставления адресов уровня 3 (например, IP-адресов ) с адресами уровня 2 (например, MAC-адресами Ethernet ). Эти данные поддерживаются в основном путем интерпретации пакетов ARP из локальной сетевой ссылки. Таким образом, его часто называют кэшем ARP . Начиная по крайней мере с 1980-х годов [21] сетевые компьютеры имеют утилиту под названием arp для опроса или манипулирования этой базой данных. [22] [23] [24]

Исторически для поддержания соответствия между адресами использовались другие методы, такие как статические файлы конфигурации [25] или централизованно поддерживаемые списки.

ARP-заполнение

Встроенные системы, такие как сетевые камеры [26] и сетевые устройства распределения питания [27] , не имеющие пользовательского интерфейса, могут использовать так называемую подстановку ARP для создания начального сетевого соединения, хотя это название неверно, поскольку ARP не задействован.

Заполнение ARP выполняется следующим образом:

  1. В адресную таблицу компьютера пользователя вручную вводится IP-адрес (обычно с помощью команды arp , а MAC-адрес берется с этикетки на устройстве).
  2. Компьютер отправляет на устройство специальные пакеты, обычно это ping -пакеты с размером, отличным от размера по умолчанию.
  3. Затем устройство принимает этот IP-адрес.
  4. Затем пользователь связывается с ним по протоколу telnet или веб -протоколу для завершения настройки.

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

Стандартные документы

Смотрите также

Ссылки

  1. ^ Дэвид К. Пламмер (ноябрь 1982 г.). «RFC 826, протокол разрешения адресов Ethernet — или преобразование адресов сетевых протоколов в 48-битный адрес Ethernet для передачи на оборудовании Ethernet». Internet Engineering Task Force, Network Working Group.
  2. ^ abc "Параметры протокола разрешения адресов (ARP)". www.iana.org . Получено 16.10.2018 .
  3. ^ D. Eastlake III; J. Abley; Y. Li (апрель 2024 г.). IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters. Internet Engineering Task Force . doi : 10.17487/RFC9542 . ISSN  2070-1721. BCP 141. RFC 9542. Лучшая текущая практика 141. Отменяет RFC 7042.
  4. ^ Дэвид К. Пламмер (ноябрь 1982 г.). Протокол разрешения адресов Ethernet. Сетевая рабочая группа. doi : 10.17487/RFC0826 . STD 37. RFC 826. Стандарт Интернета 37. сек. Мониторинг и отладка сети. Обновлено RFC 5227 и 5494.
  5. ^ R. Braden , ed. (октябрь 1989). Требования к интернет-хостам — коммуникационные уровни. Сетевая рабочая группа. doi : 10.17487/RFC1122 . STD 3. RFC 1122. Интернет-стандарт 3. Обновлен RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 и 9293.
  6. ^ У. Ричард Стивенс, TCP/IP Illustrated, Том 1: Протоколы , Эддисон Уэсли, 1994, ISBN 0-201-63346-9.
  7. ^ W. Richard Stevens, TCP/IP Illustrated, Том 1: Протоколы , Addison Wesley, 2011, ISBN 0-321-33631-3, стр. 14
  8. ^ Chappell, Laura A.; Tittel, Ed (2007). Руководство по TCP/IP (третье изд.). Thomson Course Technology. стр. 115–116. ISBN 9781418837556.
  9. ^ Чешир, С. (июль 2008 г.). Обнаружение конфликта адресов IPv4. Internet Engineering Task Force. doi : 10.17487/RFC5227 . RFC 5227.
  10. ^ Harmoush, Ed. "ARP Probe and ARP Announcement". Practical Networking . PracticalNetworking .net . Получено 3 августа 2022 г. .
  11. ^ ab C. Perkins, ed. (ноябрь 2010 г.). Поддержка мобильности IP для IPv4, пересмотренная версия. Internet Engineering Task Force . doi : 10.17487/RFC5944 . ISSN  2070-1721. RFC 5944. Предложенный стандарт. Отменяет RFC 3344.
  12. ^ S. Cheshire (июль 2008 г.). Обнаружение конфликта адресов IPv4. Сетевая рабочая группа. doi : 10.17487/RFC5227 . RFC 5227. Предлагаемый стандарт. Обновления RFC 826. Почему объявления ARP выполняются с использованием пакетов запросов ARP, а не пакетов ответов ARP?
  13. ^ "FAQ: брандмауэр не обновляет таблицу протоколов разрешения адресов". Citrix . 2015-01-16. [...] garpReply включен [...] генерирует пакеты ARP, которые [...] имеют тип OPCODE REPLY, а не REQUEST.
  14. ^ "Gratuitous ARP in DHCP vs. IPv4 ACD Draft". Архивировано из оригинала 12 октября 2007 г.
  15. ^ Р. Дромс (март 1997 г.). Протокол динамической конфигурации хоста. Сетевая рабочая группа. doi : 10.17487/RFC2131 . RFC 2131. Проект стандарта. Отменяет RFC 1541. Обновлен RFC 3396, 4361, 5494 и 6842.
  16. ^ S. Cheshire ; B. Aboba; E. Guttman (май 2005 г.). Динамическая конфигурация локальных адресов IPv4. Сетевая рабочая группа. doi : 10.17487/RFC3927 . RFC 3927. Предлагаемый стандарт.
  17. ^ Шах, Х. и др. (июнь 2012 г.). Посредничество протокола разрешения адресов (ARP) для взаимодействия IP-сетей VPN уровня 2. Internet Engineering Task Force. doi : 10.17487/RFC6575 . RFC 6575.
  18. ^ T. Bradley; C. Brown; A. Malis (сентябрь 1998 г.). Протокол обратного разрешения адресов. Сетевая рабочая группа. doi : 10.17487/RFC2390 . RFC 2390. Проект стандарта. Устаревший RFC 1293.
  19. ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (июнь 1984 г.). Протокол обратного разрешения адресов. Сетевая рабочая группа. doi : 10.17487/RFC0903 . STD 38. RFC 903. Стандарт Интернета 38.
  20. ^ Стив Гибсон (11 декабря 2005 г.). «Отравление кэша ARP». GRC .
  21. ^ Калифорнийский университет, Беркли. "Страница руководства BSD для команды arp(8C)" . Получено 28.09.2011 .
  22. ^ Canonical. "Страница руководства Ubuntu для команды arp(8)". Архивировано из оригинала 2012-03-16 . Получено 2011-09-28 .
  23. ^ Apple Computer. "Страница руководства Mac OS X для команды arp(8)" . Получено 28.09.2011 .
  24. ^ Microsoft. "Справка Windows по команде arp" . Получено 28.09.2011 .
  25. ^ Sun Microsystems. "Страница руководства SunOS для файла ethers(5)" . Получено 28.09.2011 .
  26. ^ Axis Communication. "Руководство по установке сетевых камер серии Axis P13" (PDF) . Получено 28.09.2011 .
  27. ^ American Power Corporation. "Switched Rack Power Distribution Unit Installation and Quick Start Manual" (PDF) . Архивировано из оригинала (PDF) 2011-11-25 . Получено 2011-09-28 .

Внешние ссылки

В Викиверситете есть обучающие ресурсы по протоколу разрешения адресов