Summary

  • В 1985 году BOOTP позволял бездисковому клиенту запросить адрес и сведения о файле загрузки до того, как он мог отправить серверу обычный IP-запрос. Ретранслятор мог вынести обмен за пределы локальной сети.
  • giaddr описывал путь ретрансляции самого BOOTP. Позднее RFC 1542 уточнил: это не универсальный IP-маршрутизатор клиента и не его маршрут по умолчанию.

Компьютеру нужна помощь, прежде чем он сможет её запросить

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

RFC 951, опубликованный в сентябре 1985 года, описывал BOOTP как первый этап: определение адреса и выбор загрузочного файла. Клиент отправлял BOOTREQUEST со своим аппаратным адресом и, если знал его, IP-адресом. Если ciaddr равнялся нулю, сервер мог найти аппаратный адрес в собственной базе и вернуть адрес клиента в yiaddr. Другие поля указывали сервер и файл. Запросы и ответы передавались через UDP-порты 67 и 68.

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

Локальное широковещание и ретрансляция к удалённой службе

От ещё не настроенного клиента не требовалось находить удалённый сервер через DNS или заранее иметь маршрут к нему. Он мог передать запрос широковещательно в локальном сегменте. Если сервер находился в другой сети, шлюз или агент пересылки мог доставить туда BOOTP-запрос, а затем вернуть ответ. RFC 951 оставлял межсетевую пересылку необязательной: для неё требовался дополнительный код на шлюзах и серверах, но не особые действия клиента.

В пакете было поле giaddr, названное в 1985 году IP-адресом шлюза. При пересылке первый шлюз мог заполнить его своим адресом, если поле было нулевым, и увеличить hops. Если giaddr был ненулевым, сервер мог отправить BOOTP-ответ на этот адрес через серверный порт, чтобы ретранслятор доставил его в сеть клиента. Так поле соединяло загружающееся устройство со службой в другом месте.

Этот путь не был маршрутом, которым компьютер пользовался позднее. Первоначальная формулировка RFC 951 оставляла место для путаницы: один фрагмент предлагал пересылать пакеты через giaddr, чтобы «добраться до сервера». Но передача загрузочного файла и обычная IP-маршрутизация клиента — разные задачи. Одно лишь слово «шлюз» в названии поля не превращало их в одну функцию.

Уточнение 1993 года

RFC 1542 непосредственно разобрал эту неоднозначность. Предыдущая спецификация недостаточно чётко задавала поведение агента пересылки, поэтому новый документ ввёл термин «агент ретрансляции», отделив эту задачу от обычной IP-пересылки. BOOTP-ретранслятор принимает сообщение как конечный адресат и формирует новое сообщение BOOTP; он не просто пропускает неизменённую IP-дейтаграмму. Ретранслятор удобно размещать на соединяющем сети маршрутизаторе, но такую функцию мог выполнять и хост, непосредственно подключённый к сети клиента.

Согласно RFC 1542, giaddr нужен для передачи BOOTREQUEST через агентов ретрансляции к серверам в других сетях и для возврата BOOTREPLY тем же путём. Поле не обозначает универсальный IP-маршрутизатор клиента, и клиент не должен трактовать его так. Для связи с удалённым TFTP-сервером хосту по-прежнему нужен адрес первого маршрутизатора, полученный отдельно — из другой настройки или механизма обнаружения.

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

Что давала централизованная загрузка и от чего она не избавляла

Ретранслятор позволял разместить сервер загрузки, таблицы соответствия аппаратных и IP-адресов и файлы вне локального кабеля. Это могло избавить от необходимости держать отдельный сервер в каждом сегменте и дать оператору единое место для обслуживания записей и файлов. Это архитектурное следствие описанного механизма, а не оценка реального распространения или затрат.

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

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

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

Источники