Кратко

  • RFC 906 предложил использовать TFTP поверх IP для получения первого программного кода компьютером без диска. До этого разные механизмы производителей могли вынуждать организацию поддерживать несколько вариантов загрузочного сервера.
  • В описанном Ross Finlayson примере для рабочей станции Motorola 68000 с Ethernet ошибка ERROR от одного сервера не прекращала ожидание: первый корректный DATA определял участника передачи. Код в ПЗУ занимал менее 4 КБ без драйвера Ethernet; это свидетельство одной реализации, а не массового внедрения.

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

Опубликованный Ross Finlayson в июне 1984 года RFC 906 описывает практическое трение на этой границе. Производители применяли разные способы загрузки начальных файлов. Организации, поддерживавшей несколько видов компьютеров, могли понадобиться несколько реализаций загрузочных серверов, хотя после старта машины свободно взаимодействовали. RFC предложил общий протокол для первой передачи: TFTP поверх IP. Сам документ называет себя предложением для сообщества ARPA Internet и просит обсудить его и предложить улучшения. Он не утверждает, что этот подход уже стал повсеместным.

Выбор TFTP был намеренно скромным. Программа отправляла запрос на чтение с именем файла, затем получала пакеты DATA и возвращала подтверждения или ошибки. RFC считал приемлемой невысокую скорость первичной загрузки, поскольку следующий этап мог использовать более быстрый протокол. Клиент должен был принимать IP-датаграммы размером до 524 октетов без IP-заголовка: до 516 октетов в пакете TFTP DATA плюс 8 октетов заголовка UDP. Загружаемый компьютер не обязан был отвечать на входящие запросы TFTP на чтение или запись. Это был ограниченный клиент для получения кода, а не универсальный файловый сервер.

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

Описанная реализация делает эту границу наглядной. Finlayson сообщил о коде в ПЗУ для рабочей станции Motorola 68000 с Ethernet. Пользователь вводил имя файла и мог указать интернет-адрес рабочей станции и сервера. Если адрес сервера не задавался, запрос могли получить несколько TFTP-серверов. Поэтому важен был не только сам факт ответа, но и то, какой ответ менял состояние клиента.

Правило было точным. Получив TFTP ERROR от одного сервера, клиент не прекращал попытки: другой сервер еще мог прислать нужный файл. Первый корректный пакет DATA задавал интернет- и Ethernet-адреса, которым направлялись следующие ACK. Если позднее DATA присылал другой сервер, клиент отвечал ему пакетом ERROR. Запрос могли услышать разные серверы, но один корректный первый ответ становился партнером этой передачи.

Это правило легко принять за аутентификацию, но она здесь ни при чем. В RFC 783 о второй версии TFTP сказано, что протокол не предусматривает аутентификацию пользователя. Правило RFC 906 выбирает ответивший сервер, но не доказывает, что он был предусмотрен оператором, и само по себе не проверяет происхождение загрузочного файла. Источники не описывают ни атаку, ни инцидент внедрения. Они показывают, где предложение разместило решение: в обработке ответов клиентом и в локальной среде, определявшей, кто мог ответить.

Значение размера кода также ограничено. Описанная реализация занимала менее 4 КБ, если не считать драйвер Ethernet. Это показывает, что одному автору удалось поместить клиента в ограниченный объем ПЗУ. Это не оценка для других процессоров, не число установок и не доказательство исчезновения фирменных способов загрузки.

Более поздние документы помогают понять архитектуру, но не подтверждают прямую цепочку внедрения. RFC 951, опубликованный в 1985 году, описывает BOOTP как первый этап определения адреса и выбора загрузочного файла; передача файла обычно выполнялась затем по TFTP. RFC 1123 в 1989 году тоже описывает запуск бездискового компьютера в два этапа под управлением программы в ПЗУ: настроить IP, затем загрузить код системы. Эти документы яснее проводят границу между подготовкой и передачей. Они не превращают единственную реализацию из RFC 906 в показатель распространенности.

Историческая ценность RFC 906 — в этой границе, а не в объявленной победе. Небольшая программа в ПЗУ могла запросить следующий файл с помощью IP, тогда как запуск машины и часть выбора сервера оставались локальными. Первый корректный DATA задавал четкий момент, когда один ответивший становился участником передачи. Протокол оставался компактным, но оператору по-прежнему нужно было понимать, откуда придет код, ответивший первым.

Поздняя Note 65 Heng Lu дает здесь редакционную рамку, но не свидетельствует о намерениях Finlayson: опубликованное предложение и описанная реализация отличаются от фактического внедрения и использования. Доступные материалы подтверждают предложение и один пример. Они не показывают, сколько площадок его приняло и устранило ли оно упомянутые расходы на поддержку.

Источники