глава 4 arp: протокол определения адреса

проблема, которую мы будем обсуждать в этой главе, заключается в том, что ip адреса имеют какое-либо значение только в семействе протоколов tcp/ip. канальные уровни, такие как ethernet или token ring, имеют собственную схему адресации (в основном 48-битные адреса); сетевые уровни, в свою очередь, используют эти канальные уровни. сеть ethernet, может быть использована различными сетевыми уровнями в одно и то же время. компьютеры использующие разные сетевые протоколы могут находиться на одном и том же физическом кабеле.

когда фрейм ethernet отправляется от одного хоста по локальной сети к другому, по его 48-битному ethernet адресу определяется, к какому интерфейсу он должен быть доставлен. драйвер сетевой платы никогда не смотрит на ip адрес назначения в ip датаграмме.

другими словами возникает необходимость установить соответствие между двумя различными формами адресов: 32-битными ip адресами и каким-либо типом адресов канального уровня. rfc 826 [plummer 1982] - официальная спецификация arp.

на рисунке 4.1 показаны два протокола, которые мы рассмотрим в этой и следующей главах: протокол определения адреса (arp - address resolution protocol) и обратный протокол определения адреса (rarp - reverse address resolution protocol).

рисунок 4.1 протоколы определения адреса: arp и rarp.

arp предоставляет динамическое сопоставление ip адресов и соответствующих аппаратных адресов. мы используем термин динамическое, так как это происходит автоматически и обычно не зависит от используемых прикладных программ или воли системного администратора.

rarp, в основном, используется системами без жестких дисков (бездисковые рабочие станции или x терминалы), однако здесь требуется ручная конфигурация с участием системного администратора. мы рассмотрим rarp в главе 5.

если мы введем команду

будет выполнена следующая последовательность действий. (см. рисунок 4.2.)

фундаментальная концепция, заложенная в arp, заключается в следующем. сетевой интерфейс имеет аппаратный адрес (48-битное значение для ethernet или token ring). фреймы, которыми обмениваются на аппаратном уровне, должны адресоваться к корректному интерфейсу. однако tcp/ip испоьзует собственную схему адрессации: 32-битные ip адреса. знание ip адреса хоста не позволяет ядру послать датаграмму этому хосту. драйвер ethernet должен знать аппаратный адрес пункта назначения, чтобы послать туда данные. в задачу arp входит обеспечение динамического соответствия между 32-битными ip адресами и аппаратными адресами, используемыми различными сетевыми технологиями.

каналы точка-точка не используют arp. когда эти каналы конфигурируются (обычно во время загрузки), ядру необходимо сказать ip адрес для каждого конца канала. аппаратные адреса, такие как ethernet адреса, в данном случае не используются.

эффективность функционирования arp во многом зависит от arp кэша (arp cache), который присутствует на каждом хосте. в кэше содержатся internet адреса и соответствующие им аппаратные адреса. стандартное время жизни каждой записи в кэше составляет 20 минут с момента создания записи.

содержимое arp кэша можно увидеть с использованием команды arp(8). опция -a показывает все записи, содержащиеся в кэше:

48-битные ethernet адреса приведены в виде шести шестнадцатиричных чисел, разделенных двоеточиями. дополнительные функции команды arp обсуждаются в разделе "команда arp" главы 4.

на рисунке 4.3 показан формат arp запроса и формат arp отклика, в случае использования ethernet и ip адресов. (arp можно использовать в других сетей, при этом он способен устанавливать соответствие не только для ip адресов. первые четыре поля, следующие за полем типа фрейма, указывают на типы и размеры заключительных четырех полей.)

рисунок 4.3 формат arp запроса или отклика при работе с ethernet.

два первых поля в ethernet заголовке - поля источника и назначения ethernet. специальный адрес назначения ethernet, состоящий из всех единиц, означает широковещательный адрес. фреймы с таким адресом будут получены всеми ethernet интерфейсами на кабеле.

двухбайтовый тип фрейма (frame type) ethernet указывает, данные какого типа, пойдут следом. для arp запроса или arp отклика это поле содержит 0x0806.

выражения аппаратный (hardware) и протокол (protocol) используются для описания полей в пакетах arp. например, arp запрос запрашивает аппаратный адрес (в данном случае ethernet адрес) соответствующий адресу протокола (в данном случае ip адрес).

поле hard type указывает на тип аппаратного адреса. для ethernet это значение равно единице. prot type указывает тип адреса протокола, к которому будет приведено соответствие. для ip адресов используется значение 0x0800. по своему целевому назначению это значение соответствует полю типа во фрейме ethernet, который содержит ip датаграмму. (см. рисунок 2.1.)

два следующих однобайтных поля, hard size и prot size, указывают на размеры в байтах аппаратного адреса и адреса протокола. в arp запросах и откликах они составляют 6 для ethernet и 4 для ip адреса.

поле op указывает на тип операции: arp запрос (значение устанавливается в 1), arp отклик (2), rarp запрос (3) и rarp отклик (4). (мы поговорим о rarp в главе 5.) это поле необходимо, так как поля типа фрейма (frame type) одинаковы для arp запроса и arp отклика.

следующие четыре поля: аппаратный адрес отправителя (ethernet адрес в данном примере), адрес протокола (ip адрес), аппаратный адрес назначения и адрес протокола назначения. обратите внимание, что в данном случае происходит некоторое дублирование информации: аппаратный адрес отправителя может быть получен как из ethernet заголовка, так и из arp запроса.

для arp запроса все поля заполнены, за исключением аппаратного адреса назначения. когда система получает arp запрос, который предназначается ей, она вставляет свой аппаратный адрес, меняет местами адреса источника и назначения, устанавливает поле op в значение 2 и отправляет отклик.

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

чтобы посмотреть как функционирует arp, мы запустим команду telnet, чтобы подсоединиться к discard (discard server - сервер, не предоставляющий пользователю никаких услуг) серверу.

bsdi% arp -a                  проверяем, что arp кэш пуст
bsdi% telnet svr4 discard     подсоединяемся к серверу
trying 140.252.13.34 ...
connected to svr4.
escape character is '^]' .
^]                            нажимаем control и правую квадратную скобку,
telnet> quit                  чтобы получить приглашение telnet и закрыть сессию
connection closed.

пока осуществляются эти действия, мы запускаем команду tcpdump с опцией -e на другом хосте (sun). это позволит нам посмотреть аппаратные адреса (48-битные адреса ethernet).

1 0.0                 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
                     arp who-has svr4 tell bsdi
2 0.002174 (0.0022)  0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 arp 60:
                     arp reply svr4 is-at 0:0:c0:c2:9b:26
3 0.002831 (0.0007)  0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
                     bsdi.1030>svr4.discard: s 596459521:596459521 (0)
                     win 4096 <mss 1024> [tos 0x10]
4 0.007834 (0.0050)  0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 ip 60:
                     svr4.discard>bsdi.1030: s 3562228252:3562228252 (0)
                     ack 596459522 win 4096 <mss 1024>
5 0.009615 (0.0018)  0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
                     bsdi.1030>svr4.discard: . ack 1 win 4096 [tos 0x10]

рисунок 4.4 arp запрос и arp отклик, сгенерированные при запросе на telnet соединение.

на рисунке а.3 в приложении а показан реальный вывод команды tcpdump, которую мы запустили на рисунке 4.4. так как это первый пример вывода tcpdump в тексте, вам стоит посмотреть приложение, чтобы увидеть как мы преобразовали вывод, чтобы он стал более красивым и читаемым.

мы удалили 4 заключительные строки из вывода tcpdump, которые соответствуют разрыву соединения (более подробно рассматривается в главе 18), так как они не имеют отношения к нашему обсуждению.

в строке 1 приводится аппаратный адрес источника (bsdi), в данном случае - 0:0:c0:6f:2d:40. аппаратный адрес назначения ff:ff:ff:ff:ff:ff, являющийся широковещательным адресом ethernet. каждый ethernet интерфейс на кабеле получит фрейм и обработает его, как показано на рисунке 4.2.

следующее поле вывода в строке 1, arp, означает, что тип фрейма (frame type) установлен в 0x0806, что означает либо arp запрос, либо arp отклик.

значение 60, напечатанное после слов arp и ip, в каждой из 5 строк означает длину фрейма ethernet. так как размер arp запроса и arp отклика составляет 42 байта (28 байт - arp сообщение, 14 байт - ethernet заголовок), каждый фрейм дополняется до минимума ethernet: 60 байт.

если обратиться к рисунку 1.7, то можно увидеть, что минимальный размер (60 байт) включает в себя 14-байтный ethernet заголовок, однако не включает 4-байтный ethernet завершитель. в некоторых книгах минимум приводится как 64 байта, что включает в себя и ethernet завершитель. мы целенаправленно не включили 14 байт заголовка ethernet в минимум из 46 байт, показанных на рисунке 1.7. максимальный размер составляет 1500 байт. обычно эта величина называется максимальный блок передачи (mtu - maximum transmission unit) (см. рисунок 2.5). мы часто используем понятие mtu, потому что оно ограничивает размер ip датаграммы, однако оно никак не связано с минимальным размером. большинство драйверов устройств или интерфейсных плат автоматически дополняют ethernet фреймы до минимального размера. ip датаграммы в строках 3, 4 и 5 (содержащие tcp сегменты) меньше чем минимум и также будут дополнены до 60 байт.

следующее поле в строке 1, "arp кто имеет" (arp who-has), идентифицирует фрейм как arp запрос с ip адресом svr4 в качестве адреса назначения и ip адресом bsdi в качестве адреса отправителя. tcpdump по умолчанию приводит имена хостов соответствующие ip адресам. (в разделе "беспричинный arp" мы воспользуемся опцией -n, чтобы посмотреть реальные ip адреса в arp запросе.)

в строке 2 мы видим, что arp запрос распространяется как широковещательный, тогда как адрес назначения arp отклика это адрес bsdi (0:0:c0:6f:2d:40). arp отклик посылается непосредственно запрашивающему хосту; он не является широковещательным.

tcpdump печатает для этого фрейма arp reply вместе с именем хоста и аппаратным адресом отвечающего.

в строке 3 отправляется первый tcp сегмент, содержащий требование об установлении соединения. аппаратный адрес назначения это адрес хоста назначения (svr4). мы рассмотрим этот сегмент более подробно в главе 18.

число, которое печатается в каждой строке, после номера строки - это время (в секундах) когда пакет был принят программой tcpdump. в каждой строке после первой содержится разница во времени (в секундах) с предыдущей строкой. это значение приводится в скобках. как видно из рисунка, время между отправкой arp запроса и получением arp отклика составляет 2,2 мс. первый tcp сегмент послан через 0,7 мс после этого. таким образом, для динамического определения адреса с использованием arp, в данном примере, потребовалось менее чем 3 мс.

и последнее на что следует обратить внимание в выводе tcpdump: мы не увидим arp запрос от svr4, когда он посылает свой первый tcp сегмент (строка 4). дело в том, что svr4 уже имеет данные о bsdi в своем arp кэше, так как, когда система получает arp запрос, помимо того что она посылает arp отклик, она также сохраняет аппаратный адрес и ip адрес запросившего в своем arp кэше. это логично, так как если запросивший собирается послать ip датаграмму, то получившему скорее всего придется отправить ответ на эту датаграмму.

что произойдет, если запрашиваемый хост выключен или не существует вообще? попробуем указать несуществующий internet адрес - идентификатор сети и идентификатор подсети будет от нашего локального ethernet, однако указанного идентификатора хоста не существует. на рисунке 3.10 мы видели, что идентификаторов хостов с 36-го по 62-ой не существуют (идентификатор хоста 63 - широковещательный адрес). в данном примере мы будем использовать идентификатор хоста 36.

в этот раз telnet на ip адрес, а не на имя хоста (hostname)
bsdi % date ; telnet 140.252.13.36 ; date
sat jan 30 06:46:33 mst 1993
trying 140.252.13.36 ...
telnet: unable to connect to remote host : connection timed out
sat jan 30 06:47:49 mst 1993             прошло 76 секунд

bsdi % arp -a                           проверяем arp кэш
? (140.252.13.36) at (incomplete)

на рисунке 4.5 мы видим вывод tcpdump.

1  0.0                  arp who-has 140.252.13.36 tell bsdi
2  5.509069 ( 5.5091)  arp who-has 140.252.13.36 tell bsdi
3 29.509745 (24.0007)  arp who-has 140.252.13.36 tell bsdi

рисунок 4.5 arp запрос на несуществующий хост.

сейчас мы не указываем опцию -e, так как мы уже знаем, что arp запрос широковещательный.

здесь интересно посмотреть, с какой частотой рассылаются arp запросы: 5,5 секунд после первого запроса и снова через 24 секунды. (мы рассмотрим тайм-ауты tcp и алгоритм повторных передач более подробно в главе 21.) полное время, показанное в выводе tcpdump, составляет 29,5 секунды. однако вывод от команды date перед и после команды telnet показывает, что запрос на соединение от telnet клиента длился в течении 75 секунд. и действительно, мы увидим позже, что большинство bsd реализаций устанавливают ограничение в 75 секунд для завершения запроса на установление tcp соединения.

в главе 18, при рассмотрении последовательности tcp сегментов, которые посылаются в процессе установления соединения, мы увидим, что моменты отправки arp запросов полностью совпадают с отправкой сегментов tcp syn.

требования к хостам host requirements rfc говорит, что запись должна удаляться по тайм-ауту, даже если данная запись используется, однако большинство реализаций, произошедших от berkeley, не делают этого - они перестартовывают тайм-аут каждый раз, когда происходит обращение к записи.

уполномоченный агент arp позволяет маршрутизатору отвечать на arp запросы в одну сеть, в то время как запрашиваемый хост находится в другой сети. с помощью этого средства происходит обман отправителя, который отправил arp запрос, после чего он думает, что маршрутизатор является хостом назначения, тогда как в действительности хост назначения находится "на другой стороне" маршрутизатора. маршрутизатор выступает в роли уполномоченного агента хоста назначения, перекладывая пакеты от другого хоста.

для того чтобы лучше описать работу уполномоченных агентов arp, мы рассмотрим пример. из рисунка 3.10 видно, что система sun подключена к двум сетям ethernet. однако в действительности это не так, в чем можно убедиться, если сравнить этот рисунок с рисунком, который приведен на внутренней стороне обложки. между sun и подсетью 140.252.1 находится маршрутизатор, который выступает в роли уполномоченного агента arp, при этом все выглядело так, как будто sun находится в подсети 140.252.1. на рисунке 4.6 показано, что telebit netblazer, названный netb, находится между подсетью и хостом sun.

рисунок 4.6 пример уполномоченного arp.

если мы запустим команду arp на хосте gemini после общения с хостом sun, то увидим, что оба эти адреса принадлежат подсети 140.252.1 (netb и sun) и что им соответствует один аппаратный адрес. как правило, это основная причина, по которой используется уполномоченный агент arp.

gemini % arp -a
появится много строк про хосты из подсети 140.252.1
netb (140.252.1.183) at 0:80:ad:3:6a:80
sun (140.252.1.29) at 0:80:ad:3:6a:80

еще одна деталь на рисунке 4.6, которую необходимо объяснить, это отсутствие ip адреса под квадратиком, который обозначает маршрутизатор netb (slip канал). почему на обоих концах slip канала нет ip адреса, как между bsdi и slip? в разделе "команда ifconfig" главы 3, из вывода команды ifconfig, мы заметили, что адрес назначения slip канала 140.252.1.183. netblazer не требует наличия ip адресов на каждом конце slip канала. (это позволяет сэкономить несколько столь ценных в настоящее время ip адресов.) он определяет какой хост посылает пакет в зависимости от того по какому последовательному интерфейсу прибыл пакет, поэтому нет необходимости каждому хосту на slip канале использовать уникальный ip адрес для своего канала с маршрутизатором. все dialup хосты используют адрес 140.252.1.183 в качестве адреса назначения для своих slip каналов.

уполномоченный агент arp обеспечивает доставку датаграмм к маршрутизатору sun, однако как это делают другие хосты из подсети 140.252.13? для направления датаграмм в другие хосты должна использоваться маршрутизация. где-либо в сети 140.252 должны быть сделаны записи в таблице маршрутизации, поэтому все датаграммы, направляющиеся в подсеть 140.252.13 или в указанные хосты этой подсети, будут направляться на маршрутизатор netb. этот маршрутизатор знает, как доставить датаграммы в их конечный пункт назначения, отправляя их через маршрутизатор sun.

уполномоченный агент arp также называется смешанным (promiscuous arp) или расщепленным (arp hack). эти имена появились благодаря другому использованию уполномоченных агентов arp: они применялись для того, чтобы спрятать друг от друга две физические сети между которыми находился маршрутизатор. в этом случае обе физические сети использовали один и тот же идентификатор сети, так как маршрутизатор, находящийся между ними, был сконфигурирован как уполномоченный arp агент, чтобы отвечать на arp запросы из одной сети к хостам в другой сети. эта техника использовалась в прошлом, чтобы спрятать группу хостов с более старой версией tcp/ip на отдельном физическом кабеле. две причины, по которым приходилось отделять эти "устаревшие" хосты, заключались в том, что, во-первых, они не могли поддерживать разделение на подсети и, во-вторых, использовали старые широковещательные адреса (идентификатор хоста состоял из всех нулевых бит вместо современного стандарта, при котором идентификатор хоста состоит из единичных битов).

другая характеристика arp, которую стоит рассмотреть - "беспричинный" arp (gratuitous arp). он проявляется, когда хост посылает arp запрос, основываясь на собственном ip адресе. обычно это делается, когда интерфейс конфигурируется во время загрузки.

если мы запустим tcpdump на хосте sun при загрузке хоста bsdi, то увидим пакет, показанный на рисунке 4.7.

1  0.0                 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
                      arp who-has 140.252.13.35 tell 140.252.13.35

рисунок 4.7 пример "беспричинного" arp.

(мы использовали флаг -n программы tcpdump, чтобы напечатать адреса в цифровом десятичном виде вместо имен хостов.) в терминах полей arp запроса, адрес протокола отправителя и адрес протокола назначения идентичны: 140.252.13.35 (что соответствует хосту bsdi). адрес источника в заголовке ethernet, 0:0:c0:6f:2d:40 как показано программой tcpdump, эквивалентен аппаратному адресу отправителя (из рисунка 4.4).

"беспричинный" arp предоставляет две характеристики.

1. он позволяет хосту определить, существует ли другой хост с тем же самым ip адресом. хост bsdi не ожидает отклика на свой запрос, однако если отклик принят, на консоли возникает сообщение об ошибке "обнаружен дублирующий ip адрес с ethernet адресом: a:b:c:d:e:f". это предупреждение системному администратору о том, что одна из систем неправильно сконфигурирована.
2. если хост, посылающий "беспричинный" arp, только что изменил свой аппаратный адрес (может быть потому, что хост был выключен, удалена интерфейсная плата и затем хост был перезагружен), этот пакет заставляет другой хост на кабеле, который имеет запись в своем кэше для старого аппаратного адреса, обновить arp кэш соответствующим образом. малоизвестный факт о протоколе arp [plummer 1982] заключается в том, что если хост получает arp запрос для ip адреса, который он уже имеет в кэше, содержимое кэша обновляется аппаратным адресом отправителя (ethernet адресом) из запроса arp. это делается для любого запроса arp, полученного хостом. (повторим, что arp запросы широковещательные, поэтому такие действия осуществляются всеми хостами в сети каждый раз при появлении arp запроса.) [bhide, elnozahy, and morgan 1991] описывает приложения, которые используют эту характеристику arp. она позволяет запасному (backup) файл-серверу занять место вышедшего из строя сервера с использованием "беспричинного" arp запроса с запасным аппаратным адресом, однако с тем же ip адресом, который имел вышедший из строя хост. при этом все пакеты, направляемые серверу, вышедшему из строя, будут посланы на запасной сервер, а пользовательские приложения не будут знать о том, что основной сервер вышел из строя.

к сожалению, авторы затем отказались от этого подхода, так как он зависит от корректности реализации arp на всех типах клиентов. существуют различные типы arp, которые не поддерживают эту спецификацию.

мы использовали эту команду с флагом -a, чтобы отобразить все записи arp кэша. существуют и другие опции.

суперпользователь может использовать опцию -d, чтобы удалить запись из arp кэша. (это было сделано перед запуском некоторых примеров, чтобы показать изменения arp.)

записи могут быть добавлены с использованием опции -s. при использовании этой опции необходимо указать имя хоста и ethernet адрес, ip адрес, соответствующий имени хоста, и ethernet адрес добавляются в кэш. подобная запись делается на постоянной основе (она не будет удалена из кэша по тайм-ауту), если только в конце командной строки не будет использовано ключевое слово temp.

arp это основной протокол, который используется практически во всех реализациях tcp/ip. обычно его функционирование не зависит от используемых приложений или воли системного администратора. arp кэш является фундаментом этой работы. мы использовали команду arp, чтобы просмотреть или модифицировать кэш. каждая запись в кэше имеет таймер, который используется для удаления незавершенных или завершенных записей. команда arp отображает модифицированные записи в arp кэше.

мы посмотрели обычное функционирование arp и специализированные версии: уполномоченный агент arp (когда маршрутизатор отвечает на arp запросы для хостов, находящихся на другом интерфейсе маршрутизатора) и "беспричинный" arp (посылающий arp запросы для своего собственного ip адреса, обычно во время загрузки).