Кратко

  • RFC 1433 добавляла к маршруту ARP Helper Address, чтобы узел мог попытаться разрешить следующий переход из другой IP-сети на общей канальной службе.
  • Помощник должен был разрешаться локально и без рекурсии Directed ARP; маршрут, физический интерфейс и фильтры от flood и loop ограничивали запрос.
  • Полученный канальный адрес не гарантировал путь: нетранзитивные или асимметричные фильтры оставляли сторонний переход разрешённым, но непригодным.

Адрес, близкий только в таблице

RFC 1433 рассматривала несколько независимо управляемых IP-сетей поверх одной канальной сети, например SMDS. Маршрутизатор с адресами в двух IP-сетях видел их общий нижний транспорт и мог объявить более прямой следующий переход, чтобы пакет не делал лишний заход через него.

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

Поэтому корректная и дешёвая строка маршрута могла быть неисполнимой. Routing выбирал IP следующего перехода; отдельная система должна была превратить его в канальный адрес. Directed ARP не сливал эти решения, а создавал ограниченный путь для вопроса.

Помощник как происхождение маршрута

Пустой ARP Helper означал, что узел умеет разрешить адрес локально. Непустой указывал маршрутизатор, сообщивший, что чужой следующий переход расположен на той же канальной сети. Вместе с выбором сохранялась зависимость, делающая его исполнимым.

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

Самого помощника нельзя было искать через Directed ARP. Запрет рекурсии не позволял строке маршрута скрывать цепь A→B→C или цикл. Первый помощник обязан был находиться в уже разрешаемой локальной области.

В distance-vector обновлении помощником обычно становился объявивший маршрутизатор. Для ICMP Redirect эту роль мог получить отправитель. Источник рекомендации оставался связан с обязанностью помочь исполнению.

Переслать вопрос или ответить за другого

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

Если целевая сеть применяла ARP, запрос пересылался на её request address. Если она использовала иной механизм, маршрутизатор мог получить соответствие локально и ответить посредством «published ARP» от имени цели.

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

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

Вопрос, который мог стать потоком

Пересылка обнаружения создавала усиление. RFC 1433 требовала фильтровать Directed ARP, чтобы ограничить flood от неисправных узлов и завершить loop, вызванный нестабильной маршрутизацией или ошибочной ручной настройкой.

Предлагалось ограничивать одинаковые пары источник-цель за интервал, не отправлять запрос к тому же канальному назначению, на которое пришёл кадр, и не пересылать запросы, полученные как канальный broadcast. Эти меры ограничивали повторение, отражение и область распространения.

Они не подтверждали соответствие адресов. Они решали, сколько общего ресурса может занять вопрос без ответа. Первый запрос мог потеряться, поэтому числа N и T оставались административным выбором. Слишком строгий порог превращал потерю в молчание; слишком мягкий поддерживал цикл.

Журнал должен хранить пару адресов, интерфейс, класс канального назначения, broadcast-флаг, счётчик, окно, решение фильтра и последующий ответ.

Неисполняемый маршрут следовало удалить

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

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

Одинаковое значение становилось маршрутом для одного получателя и неисполняемой строкой для другого. Обновление routing не переносило автоматически нижний механизм.

Общий сосед не создавал транзитивность

Сторонний next hop мог вывести объявителя из пути данных. Сведения о собственном пути маршрутизатор обычно может наблюдать и отозвать. Рекомендуя прямую связь двух других узлов, он мог не увидеть её отказ.

В примере SMDS фильтры разрешали R1–R2 и R2–R3, но блокировали R1–R3. R2 действительно знал R3, однако предлагал R1 прямой переход, запрещённый нижней политикой. Две истинные связи не образовывали третью.

Фильтры могли быть асимметричны: R3 отправлял R1, а обратное направление не работало. Кадр или ответ в одну сторону не доказывал возврат. «Одна канальная сеть» означала общий сервис, а не полную матрицу разрешений.

Тест не должен обходить проверяемую связь

RFC предлагала ICMP echo прямо на канальный адрес следующего перехода до установки или первого использования маршрута. Обычный echo на IP мог пойти другим маршрутом и успешно вернуться, не испытав спорную локальную связь.

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

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

Источники и границы

RFC 1433 задаёт эксперимент; RFC 826 — ARP; RFC 1209 — SMDS; RFC 1267 и RFC 1247 — контекст BGP-3 и OSPF; RFC 1122 и RFC 792 — требования к хостам и ICMP.

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

Источники