Кратко

  • RFC 1931 допускал несколько серверов Dynamic RARP ради отказоустойчивости, но требовал, чтобы все серверы сегмента обращались к одному логическому центру полномочий по адресам.
  • Согласованный реестр мог отстать от действительности: перед выдачей адреса, отмеченного свободным, рекомендовалось проверить сеть средствами ARP или ICMP.
  • Документ опубликован в апреле 1996 года как Informational и теперь отнесён к Legacy. Он фиксировал механизм некоторых платформ Sun, применявшийся с 1988 года, но не устанавливал стандарт и не доказывает причинное влияние на DHCP.

Молчание оставляло клиент без диагноза

RARP из RFC 903 предназначался для загружающегося узла, который знал аппаратный адрес, но не знал протокольный. Таблицу соответствий могли держать несколько серверов. Отрицательного пакета не было: незнание одного сервера не означало, что нужной записи нет у другого.

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

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

RFC 1931 описал Dynamic RARP как добавление к существующей схеме. Формат пакета сохранился, появились запрос, временный ответ и явная ошибка. При постоянной привязке сервер возвращал обычный REVARP_REPLY; иначе создавал временный DRARP_REPLY или сообщал DRARP_ERROR: запрет политики, исчерпание пула, временную недоступность центра, перемещение в другой сегмент либо необъяснённый сбой.

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

Карточка RFC Editor указывает статус Informational и поток Legacy; никакого стандарта Интернета документ не определяет. В тексте сказано, что отдельные платформы Sun Microsystems использовали DRARP с 1988 года. К публикации в апреле 1996 года они уже не продавались, а DHCP частично решил ту же задачу. Перед нами архив инженерного опыта, а не заявка на нормативное первенство.

Резервирование касалось ответа, не права на отдельное решение

Если один запрос слышали несколько DRARP-серверов, их ответы должны были совпасть во всём, кроме полей отправляющего сервера. Иное расхождение считалось ошибкой протокола. Так несколько процессов представляли один логический сервис.

Сервер на каждом кабельном сегменте уменьшал ущерб от разделения; дополнительные серверы защищали от отказа машины или участка сети. Но все они обязаны были связываться с одной адресной властью. В описанной реализации ею служили NIS и централизованный RPC-протокол IPalloc; менять данные могли авторизованные администраторы и DRARP-серверы. RFC не стандартизировал ни этот протокол, ни его защиту.

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

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

Живая сеть имела право опровергнуть базу

RFC 1931 предупреждал: административная база может считать адрес свободным, когда работающий узел уже его использует. Перед назначением следовало проверить сеть; реализация применяла ARP и ICMP Echo.

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

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

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

Срок хранения не означал успешную установку

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

Позднейший DHCP оформил другие стадии. RFC 1541 описал несколько предложений, явный выбор клиента, идентификатор сервера и конечный срок аренды. RFC 2131 уточнил процесс и разрешил клиенту отказаться от предложения, если локальная проверка выявила занятость. Это архитектурное сопоставление, а не утверждение, будто DRARP стал причиной DHCP.

Локальный случай получил иной механизм. RFC 3927 позволяет узлу выбрать, проверить, объявить и иногда защищать IPv4 link-local адрес. Он не маршрутизируется и не является долговечной идентичностью. RFC 5227 обобщил выявление конфликтов через ARP Probe и Announcement. Свидетельство остаётся местным и ограниченным временем; разделения и злонамеренные ответы сохраняют неопределённость.

Минимальное общее правило между символом и действием

Идея Heng Lu о первичности работающего кода объясняет роль проверки. Реестр символически координирует, но уже работающие пакеты способны ему возразить. Это не отмена администрирования, а проверка административного утверждения перед превращением в исполнимую конфигурацию.

Minimum Initial Specification помогает выделить малое общее ядро: ответы согласованы, ошибки различимы, временное состояние живёт до сходимости зависимостей. Конкретные NIS, RPC, срок и локальные разрешения остаются заменяемыми.

Через слои реальности видно три вида силы: реестр согласует, ответ настраивает, зонд опровергает. RFC 1931 не принял несколько машин за несколько властей — и не принял одну согласованную власть за всю действительность.

Источники

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — текущая карточка RFC 1931
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile