Кратко

  • RFC 1293, документ Standards Track от января 1992 года, добавляет к ARP Inverse Address Resolution Protocol: станция с известным аппаратным адресом запрашивает соответствующий протокольный адрес. В примере Frame Relay известен DLCI установленного PVC, но не известен адрес протокола удалённой станции.
  • InARP не использует broadcast, потому что аппаратный адрес цели уже известен. Получатель может ответить либо проигнорировать запрос, если не может или не хочет отвечать; запросившая сторона может заполнить локальную ARP-запись, а полученная информация может устареть или быть инвалидирована.

В RFC 1293 важно сохранять порядок записей. Сначала сеть может объявить виртуальную цепь и её Data Link Connection Identifier. DLCI определяет одно виртуальное соединение через WAN и в Frame Relay соответствует аппаратному адресу. Затем локальная станция понимает, что у неё нет протокольного адреса противоположной стороны. Она формирует InARP-запрос. Лишь потом возможны ответ, локальная запись кэша и отдельная история передачи данных.

Если эти записи слить, возникает ложный сосед. Объявленный канал не доказывает отправку запроса. Отправленный запрос не доказывает ответ. Ответ, из которого заполнена ARP-таблица, не доказывает маршрут, разрешение, доставку или результат для приложения. RFC описывает способ сузить именно одну неизвестность, а не способ объявить всю последовательность завершённой.

DLCI обозначал путь, а не протокольную личность

Через сигнализацию сеть может объявить новый виртуальный канал вместе с DLCI. Однако адрес протокола в таком объявлении не содержится. Без новой конфигурации или механизма обнаружения станция не может адресовать другой конец через этот канал. Слово unusable в RFC относится к этой задаче адресации; оно не утверждает, что канал не существует, что он неисправен или что удалённый узел ненадёжен.

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

Нулевое поле сохраняло неизвестность в самом пакете

Обычный ARP рассылает запрос, поскольку не знает аппаратного адреса назначения. InARP не рассылает: этот адрес уже известен. Запросчик помещает в пакет свои аппаратный и протокольный адреса, известный аппаратный адрес цели, заполняет нулём поле целевого протокольного адреса, инкапсулирует пакет для конкретной сети и посылает его прямо цели.

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

Обратный вопрос не делал RARP тем же протоколом

InARP начинает с аппаратного адреса и просит протокольный; коды операций — 8 для request и 9 для reply. RARP рассматривался, но не подошёл: его ответ сообщает адрес самого запрашивающего, тогда как нужен адрес станции, принимающей запрос на другом конце канала. Направление информации важнее сходства слов в названии.

RFC также не ограничился средствами только для IP, поскольку хотел разрешать адреса нескольких протоколов. Следовательно, InARP — не реестр владельцев IP, не источник маршрутизационной власти и не сертификат соседства. Это ограниченная процедура получения отсутствующего соответствия.

Ответ или молчание оставались у получателя

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

Молчание не следует заменять вымышленным успехом. Журнал запроса показывает отправку, но не объясняет отсутствие ответа и не доказывает конфигурацию, политику, доступность или идентичность удалённой стороны. При получении reply запросчик может дополнить локальную запись и использовать предоставленный адрес. Это свидетельство о локально полученном ответе, а не независимое подтверждение правильности, авторизации, безопасности или будущей доставки.

Несколько адресов требовали ответа по контексту запросчика

Хост с несколькими протокольными адресами на одном интерфейсе должен смотреть на протокольный адрес запросчика и выбрать адрес, соответствующий его сети. В IP-примере он не должен отвечать, если не имеет адреса интерфейса в запрошенной подсети. Многоадресный хост может отправить запрос для каждого адреса интерфейса; принимающая сторона может ответить на некоторые или ни на один в зависимости от конфигурации.

Поэтому ответ не является самостоятельным свойством удалённого хоста. Фраза «у него есть адреса» не указывает, какая строка допустима в этой локальной ARP-таблице. Нужны запросчик, сетевой контекст, конфигурация и фактический ответ.

Кэш был временной записью, а не бессрочной властью

RFC прямо говорит, что сведения, полученные через InARP, могут стареть или инвалидироваться. Для проверяемого маппинга следует сохранять DLCI или аппаратную цель, сам запрос, ответ либо молчание, время, адрес в кэше, старение и отмену. Кэш отражает локальное решение хранить наблюдение, а не вечное утверждение о топологии или о личности соседа.

Отдельно необходимы данные о последующем трафике: маршрут, права, время, операция и ответ. Разрешение адреса не содержит этих наблюдений. Security Considerations RFC 1293 говорит, что вопросы безопасности не рассматриваются; reply не доказывает аутентификацию, целостность, авторизацию или устойчивость к атаке.

Источник и пределы доказательств

В статье используется RFC 1293 — Inverse Address Resolution Protocol. Источник подтверждает статус и дату, мотивацию DLCI/PVC, отсутствие удалённого протокольного адреса, отказ от RARP и IP-only решений, формат и коды InARP, прямой неброадкастный запрос, ответ или игнорирование, кэш, старение или инвалидацию, выбор при нескольких адресах и отсутствие разбора безопасности.

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