Кратко

  • RFC 1868 разбирал сбой Proxy ARP: удалённый хост возвращался через второй сервер связи раньше, чем соседи LAN успевали удалить из кэша аппаратный адрес первого.
  • UNARP был незапрошенным ARP Reply с нулевой длиной аппаратного адреса. Поддерживающий расширение узел должен был удалить запись для исходного IP, а незнакомая с форматом реализация — отвергнуть сокращённый пакет.
  • Передача широковещательного кадра, его приём конкретным узлом, принятие синтаксиса, локальное удаление, новое разрешение и успешная доставка были отдельными событиями. Сообщение не подтверждало последующие ступени.

Новый сеанс унаследовал старый адрес

Удалённый пользователь подключается к общему модемному пулу через CS1. Для Host A его IP выглядит локальным, хотя компьютер находится за сервером связи. Когда Host A посылает ARP Request, CS1 отвечает от имени удалённого узла и указывает собственный аппаратный адрес. Host A сохраняет соответствие и направляет дальнейшие кадры серверу CS1.

Такую технику совместимости описал RFC 1027. Proxy ARP скрывал подсеть и маршрут от машин, которым не нужно было понимать новую топологию. Посредник брал сложность на себя, а Host A сводил путь к локальной паре: этот IP достигается через этот аппаратный адрес.

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

Таблица была локальной, а не общей

RFC 826 определил ARP как способ распространять соответствия между протокольными и аппаратными адресами. Request задаёт вопрос. Reply сообщает отображение отправителя, которое получатель может внести в свою таблицу и использовать позже.

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

RFC 1122 поэтому потребовал механизм признания устаревших записей недействительными. Документ перечислил тайм-аут, односторонний опрос, подсказку канального уровня и сигнал сверху после проблемы доставки. Механизмы могли дополнять друг друга, однако свидетельствовали о разном. Таймер описывает срок местного доверия, молчание при опросе — отсутствие ответа, канальный сигнал — близкую неисправность, а верхний уровень — замеченное им последствие. Ни один сам по себе не сообщает, что удалённый хост теперь находится за CS2.

Нулевая длина означала отрицательное утверждение

Опубликованный в ноябре 1995 года как Experimental RFC 1868 предложил узкое дополнение. UNARP использовал opcode 2 обычного ARP Reply, тип протокола IPv4 и длину протокольного адреса четыре, но устанавливал длину аппаратного адреса в ноль. Исходным протокольным адресом был IP ушедшего хоста, целевым — 255.255.255.255. Без аппаратных полей отправителя и цели сообщение занимало шестнадцать байт перед заголовком канала.

Понимающий RFC 1868 получатель должен был удалить кэшированное соответствие для исходного IP. Серверу не требовалось даже помнить, посылал ли он прежде Proxy ARP Reply за этот хост. UNARP разрешалось отправлять при каждом отключении. Аккуратно покидающий LAN хост также мог сделать это от собственного имени.

Выбор отражал неравенство затрат. Лишнее удаление вызывало новое разрешение. Сохранение ошибочной записи продолжало направлять трафик посреднику, утратившему путь. Лучше вернуть вопрос, чем удерживать ложный ответ.

Но удаление не называло новый адрес. После UNARP Host A ещё должен был спросить, получить ответ, выучить адрес CS2 и проверить его данными. Отсутствие старого отображения не было присутствием нового пути.

Совместимость оставляла несколько причин молчать

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

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

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

Три передачи повысили шанс, но не дали трёх подтверждений

RFC 2176 в 1997 году определил родственный UNARP для IPv4 поверх MAPOS. У него был отдельный код операции и настоящие аппаратные поля. Вышедший в рабочее состояние узел отправлял три широковещательных сообщения с интервалом тридцать секунд. Получатель удалял IP-соответствие только тогда, когда сообщённый аппаратный адрес отличался от кэшированного.

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

RFC 3790 позднее отнёс RFC 1868 к зависящим от IPv4 расширениям для удаления записей ARP. Классификация подтверждает назначение документа, но не его внедрение и не результат.

Положительное объявление тоже не было итогом

RFC 5227 позже разделил две роли ARP Request. Поля отправителя утверждают соответствие, поля цели спрашивают о другом. Probe интересуется, занят ли адрес, и одновременно показывает намерение его использовать. Announcement заявляет, что отправитель теперь использует адрес.

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

Исторический вывод не требует центрального судьи для ARP. Он требует узких названий для фактов. «Сообщение об уходе отправлено», «кадр замечен здесь», «эта машина удалила запись», «новое соответствие изучено» и «первый пакет прошёл» доступны отдельной проверке. Фраза «сеть забыла» шире наблюдения передатчика.

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

RFC 826, 1027 и 1122 дают основы ARP, Proxy ARP и очистки кэша. RFC 1868 определяет экспериментальное сообщение; RFC 2176 показывает последующий вариант для иной линии; RFC 3790 классифицирует зависимость от IPv4; RFC 5227 объясняет Probe и Announcement. Первичные источники подтверждают формат, предписанное поведение и записанные ожидания. Они не подтверждают современное применение, универсальную поддержку, соответствие конкретного продукта, реальный инцидент или атаку и успешную доставку в какой-либо сети.