Network Working Group                                     T. Bradley
Request for Comments: 1293                                  C. Brown
                                      Wellfleet Communications, Inc.
                                                        January 1992

Протокол обратного преобразования адресов (InARP)

Inverse Address Resolution Protocol

PDF

1. Статус документа

В этом RFC содержится проект стандартного протокола IAB для сообщества Internet и запрос обсуждения и предложений в целях развития протокола. Состояние стандартизации протокола можно узнать из документа IAB Official Protocol Standards.

Документ может распространяться свободно.

2. Аннотация

В этом документе описано дополнение к протоколу ARP, которое позволит станциям запрашивать протокольные адреса до указанному аппаратному адресу. В частности, это применимо к станциям Frame Relay, имеющим идентификатор DLCI¹, который для Frame Relay является эквивалентом аппаратного адреса и связан с организованным PVC², но неизвестен станции на другой стороне соединения. Применимо это и к другим сетям с похожим устройством.

3. Соглашения

В этом документе используется ряд соглашений в части уровня требований:

• Must (требуется), Will, Shall (должно) или Mandatory (обязательно) — элемент является абсолютно необходимым для данной спецификации;
• Should (следует) или Recommended (рекомендуется) — в общем случае следует выполнять требование, но могут существовать обстоятельства, оправдывающие отказ от него;
• May (возможно) или Optional (необязательно) — исполнение требования или отказ от такового определяется разработчиком самостоятельно.

4. Введение

Этот документ в значительной мере опирается на Frame Relay, как пример использования протокола InARP³. Это не означает однако, что протокол InARP будет применяться только в сетях Frame Relay. Применение InARP оправдано в любых сетях, где предоставляются аппаратные адреса получателей без индикации соответствующих протокольных адресов.

5. Мотивация

Мотивом разработки протокола Inverse ARP послужило желание выполнять динамическое преобразование адресов Frame Relay быстро и эффективно. Постоянные (PVC), а, в конечном счете, и виртуальные соединения (SVC) идентифицируются значениями DLCI. Эти значения определяют виртуальное соединение через WAN⁴ и являются для сетей Frame Relay эквивалентом аппаратных адресов. Периодически за счет обмена сигнальными сообщениями сеть может анонсировать новые виртуальные устройства с соответствующими им DLCI. К сожалению в такие анонсы не включаются протокольные адреса. Получившая такую индикацию станция узнает о новом соединении, но не будет знать адреса другой стороны. Без нового протокола или механизма обнаружения протокольного адреса другой стороны использовать новое виртуальное соединение она не сможет.

Для решения проблемы преобразования предлагались и другие методы, которые были отвергнуты. Например, протокол Reverse ARP [4] представляется хорошим способом решения задачи, но откликом на запрос является протокольный адрес запрашивающей станции, а не станции, получившей запрос (чей адрес хочется узнать). Специфические механизмы IP были отвергнуты по причине ограничений, вносимых их желанием обеспечить преобразование адресов для многих протоколов. В результате был расширен протокол ARP.

InARP будет позволять станциям Frame Relay определять протокольный адрес станции, связанной с виртуальным соединением. Такое решение более эффективно, нежели имитация широковещания с множеством копий одного и того же сообщения и более эффективно, чем решения на основе статических конфигураций.

6. Формат пакетов

InARP является расширением существующего протокола ARP и использует такой же формат, как стандарт ARP.

ar$hrd 16 битов аппаратный тип
ar$pro 16 битов протокольный тип
ar$hln 8 битов размер аппаратного адреса в байтах (n)
ar$pln 8 битов размер протокольного адреса в байтах (m)
ar$op  16 битов код операции
ar$sha n байтов аппаратный адрес отправителя
ar$spa m байтов протокольный адрес отправителя
ar$tha n байтов аппаратный адрес получателя
ar$tpa m байтов протокольный адрес получателя

Возможные значения для протокольных и аппаратных типов совпадают со значениями для ARP и могут быть найдены в Assigned Numbers [2].

Размеры аппаратных и протокольных адресов зависят от среды, в которой используется InARP. Например, при использовании IP в сети Frame Relay размер аппаратного адреса составит от 2 до 4, а протокольного 4.

Код операции указывает тип сообщения (запрос или отклик).

Запрос InARP = 8
Отклик InARP = 9

Эти значения были выбраны с целью предотвращения конфликтов с другими расширениями ARP.

7. Работа протокола

В основном протокол InARP работает аналогично ARP, но InARP не использует широковещательных запросов. Это обусловлено тем, что аппаратный адрес станции-получателя уже известен. Запрашивающая станция просто форматирует запрос путем вставки своих аппаратного и протокольного адресов, а также известного аппаратного адреса получателя. После этого поле протокольного адреса получателя заполняется нулями. Далее пакет инкапсулируется в соответствии с требованиями сети и передается получателю напрямую.

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

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

7.1. Работа с многоадресными хостами

В контексте этого документа многоадресным хостом (Multi-Addressed host) будем называть хост, имеющий множество протокольных адресов на одном интерфейсе. Если такая станция получает запрос InARP, она должна выбрать для отклика один из множества адресов интерфейса. Для выбора станция сначала должна посмотреть протокольный адрес запрашивающей станции и после этого включить в отклик свой протокольный адрес из соответствующей сети. Например, если запрашивающую станцию интересует адрес IP, получившей такой запрос многоадресной станции следует включить в отклик IP-адрес из одной подсети с запрашивающей станцией. Если у станции нет подходящего адреса, ей не следует отвечать на запрос. Например, для случая IP станции не следует отвечать, если на интерфейсе нет адреса IP, относящегося к подсети запрашивающей стороны.

Многоадресных хост может выбрать передачу запроса InARP для каждого из адресов, определенных на интерфейсе. Однако следует отметить, что принявшая запросы сторона может ответить не на все такие запросы (в зависимости от ее конфигурации.

7.2. Работа протокола в сетях Frame Relay

Одним из случаев применения протокола InARP является получения сигнала о новом виртуальном соединении. Станция Frame Relay может сформировать запрос InARP для такого соединения. Если другая сторона поддерживает InARP, она может возвратить отклик с запрошенным протокольным адресом.

Запрос InARP имеет вид

ar$hrd - 0x000F — значение, выделенное для Frame Relay
ar$pro — тип протокола, для которого выполняется запрос (для IP = 0x0800)
ar$hln — 2,3 или 4 (размер адреса в байтах)
ar$pln — размер протокольного адреса в байтах (для IP = 4)
ar$op - 8; запрос InARP
ar$sha — адрес Q.922 запрашивающей станции
ar$spa — протокольный адрес запрашивающей станции
ar$tha — адрес Q.922, выделенный созданному недавно виртуальному соединению
ar$tpa - 0; искомое

Отклик InARP будет выглядеть похоже

ar$hrd - 0x000F — значение, выделенное для Frame Relay
ar$pro - тип протокола, для которого выполняется запрос (для IP = 0x0800)
ar$hln - 2,3 или 4 (размер адреса в байтах)
ar$pln - размер протокольного адреса в байтах (для IP = 4)
ar$op - 9; отклик InARP
ar$sha - адрес Q.922 отвечающей станции
ar$spa — запрошенный протокольный адрес
ar$tha - адрес Q.922 запрашивающей станции
ar$tpa - протокольный адрес запрашивающей станции

Отметим, что адреса Q.922 имеют сброшенные (0) биты C/R, FECN, BECN и DE.

Процедуры использования InARP в сетях Frame Relay идентичны процедурам применения протоколов ARP и RARP, описанным в разделе 10 документа Multiprotocol Interconnect over Frame Relay Networks [3].

8. Литература

[1] Plummer, David C., “An Ethernet Address Resolution Protocol”, RFC-826, November 1982.

[2] Reynolds, J. and Postel, J., “Assigned Numbers”, RFC-1060⁶, ISI, March 1990.

[3] Bradley, T., Brown, C., Malis, A., “Multiprotocol Interconnect over Frame Relay Networks”, RFC-1294, January 1992.

[4] Finlayson, Mann, Mogul, Theimer, “A Reverse Address Resolution Protocol”, RFC-903, Stanford University, June 1984.

9. Вопросы безопасности

Этот документ не имеет отношения к вопросам безопасности.

10. Адреса авторов

Terry Bradley

Wellfleet Communications, Inc.

15 Crosby Drive

Bedford, MA 01730

Phone: (617) 275-2400

Email: tbradley@wellfleet.com

Caralyn Brown

Wellfleet Communications, Inc.

15 Crosby Drive

Bedford, MA 01730

Phone: (617) 275-2400

Email: cbrown@wellfleet.com

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru