Кратко

  • В примере RFC 2390 станция A отправляла по DLCI 50, а B принимала тот же виртуальный канал как DLCI 70: каждое число имело смысл только на своём интерфейсе.
  • Из-за замены метки аппаратные поля внутри InARP по прибытии были недействительны; приёмник переносил адрес Q.922 внешнего кадра во внутреннее поле источника.
  • Восстановленное значение доказывало локальную точку входа, но не личность партнёра, его полномочия, истинность объявленного протокольного адреса или итог сквозной операции.

Канал остался тем же, пространство имён сменилось

Основная задача Inverse ARP была описана ещё в RFC 1293: станция знает идентификатор существующего виртуального канала, но не знает протокольный адрес на его дальнем конце. RFC 2390, заменивший тот документ в сентябре 1998 года, не выдавал механизм за новое изобретение. Он перечислял более формальный нормативный язык, диаграмму пакета, подробный пример в разделе 7.2 и новый раздел безопасности.

Именно пример показал предел выражения «известный аппаратный адрес». RFC 2427 говорил, что виртуальный канал идентифицируется DLCI на каждом интерфейсе Frame Relay, причём обычно этот DLCI имеет строго локальное значение.

Для A соединение с B было DLCI 50. Сеть меняла заголовок в пути, и B видел то же соединение как DLCI 70. Ни одно число не было ошибочным. Это были координаты одной связи в двух локальных системах отсчёта.

Отправитель не мог заполнить поле получателя

Формат ARP содержит аппаратные и протокольные адреса источника и цели. В Ethernet отправитель обычно знает собственный аппаратный адрес. В Frame Relay станция знает номер, по которому посылает в сторону партнёра, но не номер, под которым удалённый интерфейс увидит входящий кадр.

В примере A отправляет запрос InARP через DLCI 50, оставляя ar$sha неизвестным. В поле аппаратной цели находится 0x0C21 — представление Q.922 известной A локальной метки. Когда кадр приходит к B, внешний заголовок показывает DLCI 70. При нулевых C/R, FECN, BECN и DE это даёт 0x1061.

RFC 2390 формулирует следствие жёстко: при достижении назначения все аппаратные адреса внутри InARP недействительны, зато адрес в заголовке кадра верен. Сеть правильно обновила координату доставки, а инкапсулированная структура сохранила старую точку зрения.

Ограниченное нарушение чистоты слоёв

B извлекает 0x1061 из внешнего заголовка и помещает его в поле аппаратного источника. Локальный обработчик InARP получает координату, осмысленную для B. В обратном направлении B тоже отправляет ответ с неизвестным источником; только A после приёма извлекает из своего кадра DLCI 50 и записывает 0x0C21.

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

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

Происхождение значения не равно аутентификации

После исправления поле выглядит полноценным. Однако оно утверждает только одно: этот кадр пришёл на данный интерфейс под данной локальной координатой Q.922.

Добавленный в RFC 2390 раздел безопасности проводит границу. В семействе ARP нет аутентификации, подмена узла известна как риск, а документ не вводит дополнительных защитных механизмов. Копирование адреса из заголовка не подписывает сообщение, не проверяет протокольный адрес партнёра и не выдаёт разрешение.

Поэтому нужны отдельные свидетельства. Внешний заголовок фиксирует прибытие. Ответ InARP содержит заявление партнёра о протокольном адресе. Локальная политика решает, помещать ли связь в кэш. Старение и сброс определяют срок действия. Последующий трафик показывает достижимость. Приложение отдельно подтверждает результат. Одна запись не может заменить всю последовательность.

Реестр чисел не создавал глобальной власти

В реестре IANA ARP Parameters аппаратный тип 15 отведён Frame Relay, а коды 8 и 9 — запросу и ответу InARP. Эти записи не дают общей синтаксической области распасться на коллизии. Они не доказывают внедрение, подлинность или успешный обмен и не превращают DLCI в глобальное имя.

Управление разделено. RFC задаёт преобразование. IANA поддерживает уникальность кодов. Сеть показывает локальную метку на каждой границе. Принимающий интерфейс выводит из неё поле источника. Партнёр выбирает, отвечать ли и какой протокольный адрес сообщить. Локальная система решает, как использовать это заявление.

Ошибки зеркальны. Доверие внутреннему полю до исправления делает удалённую перспективу локальной реальностью. Доверие исправленному полю как личности делает локальную перспективу глобальным авторитетом.

Зачем истории понадобилась эта диаграмма

Рисунок RFC 2390 разделил четыре записи: виртуальный канал как отношение, DLCI 50 у A, DLCI 70 у B и поле, которое B восстановил из реально увиденного входа. Они связаны, но не взаимозаменяемы.

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

RFC 2390 стандартизировал минимум: источник наблюдения, исправляемое поле и входящее направление. Идентичность, доверие и результат остались отдельным механизмам. Реально принятый кадр знал операционную правду лучше, чем аккуратно заполненное поле из чужого пространства имён.

Источники