Кратко

  • RFC 2322 описала физический способ выдавать адреса во временной сети мероприятия: одна деревянная прищепка обозначала один IP-номер, а невыданные прищепки образовывали видимый пул.
  • Метка показывала состояние выдачи, но человек по-прежнему передавал её и переписывал адрес с общими настройками в компьютер. В собственном полевом отчёте RFC сказано, что участник принял адрес маршрутизатора по умолчанию за свой и на время нарушил работу сети.

RFC 2322 — не стандарт DHCP. Опубликованный 1 апреля 1998 года информационный документ описывает «peg-DHCP» для временных сетей и небольших мероприятий без чётко определённой административной организации. Его рассказ начинается с Hacking In Progress — трёхдневной встречи в Нидерландах в 1997 году. Организаторы ожидали компьютеры разных типов и хотели создать LAN TCP/IP с выходом в Интернет. Их беспокоили повторяющиеся или пропущенные номера и вероятность того, что программный сервер не сработает со всеми разными IP-стеками. RFC фиксирует это как мотив; она не доказывает, что обычный DHCP не работал.

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

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

Жизненный цикл также оставался локальным. Когда адрес больше не требовался, участник мог вернуть прищепку в пул. Если пункт выдачи оставался без присмотра, возвращать её должен был сам участник. Конец мероприятия мог служить приблизительным сроком действия: после него адреса считались недействительными. Это не то же самое, что обмен аренды в DHCP, где клиент и сервер сообщениями обрабатывают выдачу, продление, повторную привязку и истечение аренды. Смысл сравнения не в том, что «ручной способ плох, автоматический хорош», а в различии между видимым хранением и человеческим решением, с одной стороны, и состоянием протокола с обменом сообщениями — с другой.

Раздел RFC о безопасности ясно очерчивает границы: прищепку можно потерять, и кто-то другой сможет воспользоваться записанным на ней адресом; и прищепка, и общая бумажная информация были открыты для чтения. Документ советует не передавать таким способом личные сведения. Прищепка обозначала выделение адреса, но не подтверждала личность человека и не удостоверяла его право пользоваться адресом. Идея доставлять её с помощью пернатого носителя прямо названа экспериментальной, а не свидетельством внедрения.

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

Источники