«Flag day», изменивший власть: управление после перехода на TCP/IP

Кратко

• Переход в январе 1983 года был значительным, но неравномерным: февральские измерения находили сотни работающих TCP-сервисов, однако результаты различались по сервисам, совокупности адресов, дате теста и сетевому пути и не описывали единую совокупность систем, переключившихся в полночь.
• Рычаги спонсора и оператора проявлялись через отклонение NCP-трафика на уровне IMP, решения об исключениях в DDN-PMO и активацию хостов и портов; операционная зависимость от записей SRI-NIC и координации номеров в USC/ISI возросла, но нет доказательств, что переключение наделило эти офисы новой дискреционной властью.
• Процедура исключений была реальной, но частичной, а не независимой: администраторы могли подавать рекламации (reclama), в публичном списке фиксировались сроки временного включения NCP, а ретрансляции TAC и UDEL сохраняли ограниченную доступность, однако опубликованные причины, полные файлы решений и пересмотр вне DDN-PMO отсутствовали.

1 февраля 1983 года, через месяц после намеченного срока перевода ARPANET с NCP на TCP/IP, тест с ISI-VAXA попытался соединиться с каждым адресом из свежей таблицы хостов Network Information Center. Результат оказался не сетью, аккуратно разделённой на прошлое и будущее, а отчётом фиксированной ширины, полным принятых соединений, отказов, недостижимых адресов, мёртвых систем и пустых полей результатов.

Список хостов был взят из таблицы NIC от 28 января. Тестирование проводилось с ISI-VAXA 1 и 2 февраля; мёртвые, недостижимые и отказавшие записи повторно проверялись 3 февраля. Обследование охватывало три TCP-сервиса: Telnet, FTP и SMTP. Оно не проверяло программное обеспечение, не тестировало все функции TCP и IP, не доказывало постоянную доступность хоста и не перечисляло каждый компьютер, подключённый к участвовавшим сетям. Оно фиксировало, что происходило, когда один источник обращался к конкретным сервисным портам в определённые периоды.

Знаменателем вRFC 842, «Who Talks TCP?», были 328 строк адресов. Из них 200 начинались с номера сети 10 — адресного пространства ARPANET, а 128 относились к другим сетям. Строка не обязательно означала уникальный физический компьютер, организацию, абонента DDN или учреждение. Одна именованная система могла встречаться по нескольким адресам; в таблице могли быть и шлюзы, и другие эксплуатационные записи. Напротив, незарегистрированная, отключённая, закрытая или пропущенная система находилась за пределами измеренной совокупности.

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

Эти категории описывают наблюдения, а не объяснения. Запись «мёртв» могла означать полностью рабочее TCP-ПО на выключенной машине. Недостижимый адрес мог указывать на проблему шлюза, маршрутизации, адресации или измерения. Отказ означал, что пакеты дошли до TCP-конечной точки, но приложение не приняло запрошенный сеанс. Пустой результат не показывает, где была причина: в хосте, пути, сервисе или таблице. Принятие соединения на одном порту доказывает меньше, чем полное соответствие TCP, IP, ICMP, маршрутизации, обработке имён и основным приложениям.

Таблица хостов не была и переписью выполнения январского целевого показателя спонсора. Её 128 строк вне сети 10 включали системы в независимо управляемых, исследовательских, локальных, зарубежных, пакетно-радиосетях, спутниковых и других сетях. Их присутствие демонстрировало участие в расширяющейся интернет-среде. Оно не показывало, что Агентство оборонной связи (Defense Communications Agency) могло приказать всем их операторам перейти на новый протокол.

«Flag day» из заголовка — поэтому ретроспективный ярлык, а не обычный язык оперативных записей. Современные событиям уведомления говорили о переключении (cutover), конвертации или эксперименте только с TCP. В 1997 году история Общества интернета (Internet Society), написанная несколькими ведущими участниками тех событий, описала переход каксмену в стиле «flag day». Этот более поздний рассказ передал координирующую силу крайнего срока, но сжал неравномерность внедрения, которую сохранили февральские таблицы.

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

1–18 февраля 1983 года: меняющиеся наблюдения — это не кривая внедрения

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

RFC 843использовала таблицу хостов NIC от 3 февраля; тесты проводились с ISI-VAXA 8 и 9 февраля. Совокупность выросла с 328 до 329 строк. Общее число принятых соединений составило 187 для Telnet, 174 для FTP и 170 для SMTP против 183, 170 и 169 в более раннем отчёте. Но группы «сеть 10» и «вне сети 10» двигались в противоположных направлениях.

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

Десять дней спустяRFC 844задала другой вопрос. Из неё были отобраны 187 записей, принявших Telnet в RFC 843, и предпринята попытка достучаться до них с терминального концентратора в сети класса C 192.1.2 в BBN. Успех требовал большего, чем работающий Telnet-сервис на прежнем пути: пакеты и ответы должны были проходить через маршрутизацию шлюзов, адресацию класса C и соответствующее поведение ICMP.

Соединения вводились вручную по адресам в точечно-десятичной записи, и было сделано только три прохода. Хост, недоступный во время этих проходов, мог быть пропущен. Тем не менее результаты показали, насколько сильно видимый успех TCP зависел от источника теста и сетевого пути.

Сводный результат 127 из 187 не позволяет утверждать, что внешние сети отставали от ARPANET. Группа не класса A показала самый высокий наблюдаемый результат — 30 из 32. Тест также не доказывает, что каждой неуспешной записи не хватало поддержки класса C или ICMP; вопросы временной доступности и состояния путей остались нерешёнными.

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

Это первая граница управления. Измерения сделали внедрение видимым, но измерения не решали, почему хост не сработал и каким должно быть исправление. Эти решения принадлежали администраторам хостов, разработчикам, операторам шлюзов и коммутации, NIC, Офису управления программами DDN (DDN Program Management Office), исследовательским спонсорам и — за пределами контролируемой спонсором совокупности — автономным сетевым операторам.

Ноябрь 1981 года: план был задуман, чтобы покончить с посредничеством

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

RFC 801, опубликованная в ноябре 1981 года, установила 1 января 1983 года как срок полного перевода ARPANET с NCP на IP и TCP. Каждой хост-организации предписывалось начать внедрение IP/TCP к 1 января 1982 года; та же локальная ответственность назначалась за Telnet, передачу файлов и почту. Новые хосты ARPANET должны были начинать с TCP/IP, а не подключаться через NCP.

Вехи плана раскрывают его реальную конструкцию. Хосты, поддерживающие TCP и работающие только на TCP, уже существовали. Ретрансляционные службы должны были соединять несовместимые хосты. Последний перевод хоста, работавшего только на NCP, должен был начаться в январе 1982 года; к июлю большинство хостов ожидалось уже способными работать с TCP; финальная конвертация планировалась к ноябрю. Только после этого январь 1983 года должен был принести полностью TCP-сервис, удаление NCP и прекращение обычной ретрансляционной поддержки.

Внедрение оставалось распределённым. Хост-организации ARPANET управляли машинами с разными процессорами, операционными системами, кадрами, источниками ПО и локальными требованиями к сервисам. Спонсор мог объявить срок и финансировать внедрение, но не мог исправить дефектную процедуру контрольной суммы указом. Хост мог иметь IP и TCP, но не иметь SMTP. Система, работавшая через один шлюз, могла неверно обрабатывать другой маршрут, опции, фрагментацию или ICMP.

Сама RFC 801 предупреждала о реализациях, которые пропускали контрольные суммы, не собирали фрагменты, полагались на ограниченные данные маршрутизации, игнорировали опции, неправильно переупорядочивали TCP-данные или держали статические таблицы имён.

Целевой срок менял цену задержки. Хост-организация могла оставить NCP-ПО на своём компьютере, но не могла заставить оператора ARPANET бессрочно пропускать NCP-трафик. Как только коммутируемая сеть начала отклонять старый трафик, а обычные ретрансляции прекратились, незавершённое локальное внедрение превратилось в проблему доступности для самого хоста и его пользователей.

RFC 801 объясняла, почему длительное сосуществование непривлекательно. Конечные точки только на NCP и только на TCP не могли общаться напрямую, поэтому двухпротокольные ретрансляционные хосты должны были опосредовать Telnet, FTP и почту. Telnet требовал промежуточной учётной записи и второго входа. FTP мог требовать переноса файла на хранилище ретранслятора и затем повторной передачи. Почта требовала логики пересылки и адресации с учётом протокола. Каждая ретрансляция добавляла ещё одну машину, которая должна была быть доступна, и ещё один сервис, требующий ёмкости, контроля доступа, документации и поддержки.

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

Сам по себе план не доказывает, что такой перенос произошёл. Запись об исполнении находится в другом источнике — оперативных бюллетенях, которые NIC распространяла для DCA и её Офиса управления программами DDN.

Октябрь–декабрь 1982 года: принуждение переместилось в IMP

1 октября 1982 года с полудня до 16:00 по восточному времени ARPANET провела эксперимент только с TCP. В течение этих четырёх часов процессорам Interface Message Processors было предписано отклонять сообщения хостов, использующие линк 0, — линк, связанный с межхостовым NCP-трафиком. IMP возвращал статус типа 7, подтипа 3, указывающий, что связь с получателем «административно запрещена».

Этот механизм, описанный вARPANET News № 14, — самое ясное свидетельство оперативного принуждения при переходе. NCP не просто устарел в документе. Инфраструктура пакетной коммутации отклоняла соответствующий трафик. Хосты только на NCP не могли пользоваться ARPANET во время теста. Двухпротокольные системы с общим состоянием удалённого хоста также могли столкнуться с проблемами, если администраторы не отключали свою NCP-реализацию на этот период.

Точка принуждения важна. Это не SRI-NIC, удалявшая имя, и не USC/ISI, отказывавшая в номере. Отклонение выполняли IMP по инструкциям управления сетью, а за операционную среду отвечали Network Operations Center и руководство, связанное с DCA. Возвращаемый статус был спроектирован так, чтобы административный характер отклонения был виден отправляющему хосту.

Бюллетень № 16 напомнил администраторам о тесте 1 октября и попросил участников сообщать наблюдения Джону Постелу, в NOC и NIC. Он также призывал площадки внедрить SMTP и четырёхоктетную интернет-адресацию к январю. Здесь координация объединяла несколько функций: коммутируемая сеть создавала условия теста; разработчики и администраторы хостов наблюдали сбои; ISI получала технические отчёты; NOC следил за эксплуатацией; NIC распространяла инструкции и собирала сведения о внедрении.

За четырёхчасовым экспериментом последовали более длительные репетиции.Бюллетень № 17объявил 24-часовые периоды только с TCP 15 ноября и 13–14 декабря. Должен был применяться тот же метод отклонения на уровне IMP. В уведомлении прямо предупреждалось, что этот же механизм планируется использовать после целевого срока 1 января.

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

Тесты создавали и рычаг давления. Хост под контролем спонсора, не завершивший переход, не мог просто продолжать использовать старый протокол во время теста. Его пользователи ощущали последствия неперехода, а администраторы получали от сети конкретный статус. Это было принципиально иным, чем убеждение через RFC.

Однако этот рычаг был ограничен. Он напрямую действовал на NCP-трафик, поступавший через IMP ARPANET. Он не доставал до независимой локальной сети, эксплуатирующей NCP внутри себя, до внешней сети, не присоединившейся к ARPA Internet, и до каждого адреса вне сети 10, позднее перечисленного в RFC 842. Исследовательские партнёры, финансируемые DARPA, могли сталкиваться с контрактными ожиданиями или сильными стимулами к совместимости, но эти отношения не были тождественны контролю DCA над эксплуатацией ARPANET.

То же различие ограничивает утверждения о регистрации. Тесты доказывают, что оператор мог отключить протокол на коммутационном уровне. Они не доказывают, что переключение дало NIC новое усмотрение в отношении имён, а USC/ISI — новое усмотрение в отношении назначения номеров. Эти административные функции были важны для совместимости, но наблюдаемый акт принуждения происходил в другом месте.

Январь 1983 года: исключения были публичными, но лишь отчасти

Операционная политика не сводилась к крайнему сроку без возможности отсрочки.

Датированный 22 декабря 1982 годаARPANET News № 19объявил, что после 00:01 по восточному времени 1 января использование NCP не допускается без специального исключения от Офиса управления программами DDN. Запросу об исключении было дано название —reclama— и указано, как его подавать.

До января запрос можно было отправить сетевой почтой по адресам DDN-PMO с копией в NIC. После крайнего срока администратор, лишённый доступа к сети, мог отправить запрос обычной почтой США в штаб-квартиру DCA. Этот офлайн-путь был важен операционно: политика не исходила из того, что человек, добивающийся восстановления доступа NCP, по-прежнему имеет работающий сетевой доступ.

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

Бюллетень № 20, распространённый 13 января, затем опубликовал таблицу адресов с включённым NCP и запланированных дат перехода. Прямой подсчёт даёт 44 строки адресов или портов. Это не 44 независимые организации. У нескольких учреждений было несколько физических или логических адресов хостов; две строки были помечены как тестовые порты; ещё одна идентифицировала шлюз S1. В одной строке дата переключения была неизвестна. Датированные строки охватывали период с 16 января по 1 мая, хотя у 25 была назначена дата 1 февраля.

Старая сокращённая запись сети 10 подчёркивает, что представляла собой таблица: операционные записи адресов или портов в среде ARPANET. Это не был список уникальных юридических лиц, контрактов, площадок или людей, принимавших решения. Это не была и полная опись каждого компьютера, где-то использовавшего остаточный NCP в более широком DDN или Минобороны США.

Бюллетень № 20 сообщил, что исключения предоставлены площадкам, столкнувшимся с серьёзными сбоями сервиса, и подчеркнул, что каждый администратор хоста должен запрашивать включение NCP индивидуально. Там также говорилось, что сроки твёрдые. Таблица, таким образом, связывала административное решение с конкретным состоянием сети: сохранение NCP для указанного адреса до указанной даты.

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

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

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

Такое сочетание больше подходило управляемой оборонной сети, чем публичной конституционной системе. DDN-PMO решал, как долго устаревший протокол может оставаться активным в среде, за которую он нёс операционную ответственность. Заявителями были администраторы хостов, добивавшиеся продолжения сервиса, а не граждане, отстаивавшие общее право использовать любой протокол. Позднейшее управленческое значение возникает потому, что техническая среда и её общие записи расширились за пределы совокупности, которой управляли эти исходные отношения.

Январь–февраль 1983 года: TAC и UDEL поддерживали стык

Переключение не устранило всё посредничество 1 января. Оно сосредоточило его в конкретных временных средствах.

Бюллетень № 20 объявил, что контроллеры терминального доступа ARPANET (Terminal Access Controllers, TAC) продолжат поддерживать NCP до конца января. Пользователь терминала мог подключиться через TAC и ввести дополнительную команду, чтобы достичь NCP-хоста. С 1 февраля TAC должны были перейти только на TCP/IP.

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

Университет Делавэра предоставил ещё один реальный мост. UDEL согласилась эксплуатировать почтовую пересылочную ретрансляцию между пользователями TCP и NCP. TCP-отправитель, адресующий письмо получателю NCP, использовал форму UDEL-RELAY, содержащую учётную запись получателя и имя NCP-хоста. NCP-отправитель, адресующий письмо получателю TCP, использовал UDEL-TCP. Ретрансляция могла выполнить и транзакцию в рамках одного протокола, когда текущий статус получателя был неясен.

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

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

Эта схема также показывает, почему точные записи стали более значимы операционно. Устаревшая запись о возможностях могла направить почту по неверной процедуре. Хост, ошибочно показанный как перешедший, мог быть больше недостижим по обычным NCP-путям, а перешедший хост, считающийся NCP-only, мог привлекать ненужную ретрансляцию. Инструкции UDEL делали протокол источника решающим; таблица исключений помогала находить остаточных получателей; график TAC сообщал пользователям, когда исчезнет терминальный путь.

Эта зависимость не делала NIC источником каждого решения. Исключения по NCP предоставлял DDN-PMO. Сетевые операторы реализовывали включение в коммутационной среде. UDEL управляла почтовой ретрансляцией. Операторы TAC обеспечивали терминальную совместимость. NIC распространяла бюллетень и таблицу. Каждое учреждение контролировало своё звено.

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

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

Записи вошли в операционный контур, не став единой властью

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

Слой таблицы хостов предшествовал январскому переходу.RFC 810, выпущенная в марте 1982 года, заменила старый формат таблицы, ориентированный на ARPANET, форматом, предназначенным для межсетевого взаимодействия Минобороны США (DoD). Новый формат описывал сети, шлюзы, хосты, интернет-адреса, операционные системы и протокольные возможности. Строка могла отличать TCP/Telnet от NCP/Telnet или фиксировать наличие SMTP.

Таблицу можно было загрузить какHOSTS.TXTс SRI-NIC или получить через сервер Hostnames. Локальные копии снижали зависимость от живого запроса для каждого соединения, но создавали знакомую проблему согласованности: старая копия могла сохранять ушедший адрес или устаревшее заявление о протоколе. Переход повысил частоту, с которой такие расхождения имели значение, поскольку пользователям и приложениям нужно было знать не только имя и адрес, но и то, какую среду связи поддерживает получатель.

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

Этот текст устанавливает требование регистрации. Он не устанавливает документированный случай, когда NIC отклонила спорное имя, исключила в остальном функциональную внешнюю сеть или получила новую политическую дискрецию из-за срока перехода на TCP/IP. Требование уже было частью спецификации таблицы хостов 1982 года. Переход сделал точность и охват записи важнее; доказательства не показывают, что он создал это правило.

RFC 811описывала сервер имён NIC (Hostnames Server) как сервис, доступный по NCP и TCP и эксплуатируемый в SRI от имени DCA. Программы могли запросить запись по имени, запросить её по адресу или получить всю таблицу. Протокол определял возможные ответы на ненайденное имя или адрес, недопустимую команду или временный системный сбой.

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

Более прямой административный барьер появился в операционных уведомлениях вокруг планируемого разделения ARPANET/MILNET. Бюллетень № 18 от 17 декабря 1982 года говорил, что точная запись хостов и портов IMP необходима, чтобы при разделении не лишить сервиса не того пользователя. BBN было поручено отключать неиспользуемые порты и активировать их только после одобрения DDN-PMO. Новые хосты и изменения портов должны были согласовываться заранее.

Бюллетень № 21 позднее уточнил процедуру. Запросы на одобрение нового хоста, активацию порта или изменение хоста на активном порту направлялись на почтовый ящик в SRI-NIC. Требуемая информация включала имя и адрес хоста, местоположение, аппаратное обеспечение, операционную систему, спонсора, протоколы и контакты технического взаимодействия.

Здесь точность данных и операционная активация были напрямую соединены. Но причина, названная в бюллетене № 18, — разделение сетей и управление портами, а не только переход NCP/TCP. Решающим органом был DDN-PMO; BBN по инструкции контролировала состояние портов; NIC получала, вела и распространяла информацию. Называть все три структуры «реестром» означало бы скрыть, где на самом деле находилась власть.

Назначенные номера образовывали ещё один отдельный слой.RFC 820, выпущенная в январе 1983 года, фиксировала значения, используемые для номеров сетей, номеров протоколов, портов, сокетов и других полей реализации. Она направляла заявителей к Джону Постелу в USC/ISI и сообщала, что назначения выполняются по соглашению между Офисом техники обработки информации DARPA и DDN-PMO.

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

Различие между этими механизмами — причинное ядро истории:

• Отклонение на уровне IMP делало NCP непригодным в управляемой сети, кроме случаев, где он был включён.
• DDN-PMO принимал решения о временных исключениях NCP и одобрял активацию хостов и портов.
• Хост-организации внедряли и эксплуатировали собственное протокольное ПО.
• SRI-NIC регистрировала и распространяла имена, адреса, возможности, контакты и уведомления.
• USC/ISI координировала назначенные номера протоколов и сетей.
• Операторы шлюзов и ретрансляций определяли, может ли трафик пересекать конкретные технические границы.
• Внешние операторы принимали TCP/IP в рамках финансовых договорённостей, исследовательского сотрудничества, правил закупок или стимулов к совместимости, которые не все были командами DCA.

Переключение усилило зависимость по всей этой цепочке. Оно не свело цепочку в один офис.

1972–1985: институциональная граница смещалась под сетью

Даже базовая хронология предостерегает от описания единой непрерывной центральной власти.

Официальнаяхронология DARPAотносит переименование ARPA в Агентство передовых исследовательских проектов Министерства обороны (Defense Advanced Research Projects Agency) к 1972 году, а не к 1973-му. DARPA оставалась исследовательским спонсором ключевых протокольных и внедренческих работ с существенным рычагом влияния на своих подрядчиков и финансируемых партнёров.

Дата, когда DCA приняла на себя операционную ответственность за ARPANET, менее опрятна.Путеводитель 2011 года по архивам SRI ARC/NICговорит, что эксплуатация была передана DCA в 1973 году. Современная событиям публикация DCA называет более позднюю формальную дату:информационный бюллетень агентства ARPANET Information Brochure 1978 годаговорит, что ответственность за управление была передана 1 июля 1975 года.

Без исходных записей о поэтапной передаче эти утверждения не следует насильно превращать в ложную определённость. Более поздний архивный путеводитель может описывать более раннюю операционную передачу, тогда как собственный бюллетень DCA называет формальную передачу ответственности за управление. В отношении формальной даты современный отчёт DCA весомее. К 1982 году сами оперативные уведомления не оставляют неоднозначности в иерархии: их распространяла NIC для Офиса управления программами DDN при DCA, и инструкции по управлению сетью исходили из этой структуры.

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

Совокупность сети 10 ARPANET была прямым предметом плана NCP/TCP из RFC 801 и тестов только с TCP на уровне IMP. Операционный контроль DCA и решения об исключениях DDN-PMO действовали здесь с наибольшей силой.

MILNET и другие абоненты DDN относились к более широкой оборонной среде, которая ещё только собиралась и дифференцировалась. Их протокольные обязательства не сводились к каждой строке плана ARPANET. Отчёт Национального исследовательского совета 1985 года, воспроизведённый какRFC 942, говорил, что магистраль MILNET сама по себе не требовала TCP, хотя абоненты, как правило, обязаны были его использовать.

Другие сети DoD шли разными техническими и закупочными путями. RFC 942 описывала сети, уже использующие TCP, сети, планировавшие более поздний переход, и системы на других протоколах. «Интернет DoD» поэтому не был единой совокупностью, совершившей одно универсальное январское событие.

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

Независимые и более поздние внешние пользователи были ещё меньше подвержены командам DCA. Они могли выбирать TCP/IP потому, что были доступны реализации, потому что его использовали ценные корреспонденты или потому что несовместимые протоколы создавали растущие альтернативные издержки. Такое давление сетевого эффекта могло быть мощным, не создавая юрисдикции DCA над их внутренними системами.

RFC 942 особенно полезна тем, что сохраняет эти различия и одновременно фиксирует операционные последствия перехода. Работа Национального исследовательского совета поддерживалась контрактом DCA и была опубликована в 1985 году, так что это ретроспективная оценка, отчасти сформированная оборонной дискуссией о стандартах, а не нейтральная январская перепись.

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

Там также зафиксировано, что NIC не была готова поддерживать новые протоколы, из-за чего возникли проблемы с распространением таблицы хостов, а сервисные хосты потребовали существенного анализа производительности и настройки параметров, поскольку ранее не выдерживали полную пользовательскую нагрузку в течение длительного периода.

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

Тот же отчёт усложняет триумфальный рассказ. В нём говорилось, что ARPANET в целом использует TCP, в то время как некоторые пользователи продолжали использовать NCP. Это утверждение, сделанное через два года после целевого срока, не называет вовлечённые хосты или пути. Оно опровергает любое буквальное утверждение, что всё остаточное использование исчезло повсеместно в полночь. Политический переход, нормальная работа сети, хост-ПО, локальное использование и временная или исключительная достижимость были разными состояниями.

Внешнее внедрение: где кончалась команда и начиналась совместимость

Более широкий успех TCP/IP зависел от выхода за пределы совокупности, которой могла управлять DCA.

RFC 801 описывала ARPA Internet, соединяющую ARPANET с пакетно-радиосетями, спутниковыми, локальными и другими сетями. RFC 842 и RFC 843 включали адреса вне сети 10. RFC 844 продемонстрировала, что тестовый путь не класса A может успешно достичь многих записей. Эти источники показывают среду межсетевого взаимодействия, пересекавшую технические и институциональные границы уже к началу 1983 года.

Они не устанавливают единый правовой или административный режим во всей этой среде.

Для хоста в сети 10 отклонение NCP на IMP было немедленным операционным фактом. Для отдельно управляемой сети решающими факторами могли быть доступ к реализации TCP, отношения со шлюзом, исследовательский контракт, желание получить доступ к сервисам ARPANET или растущее число совместимых корреспондентов. Сеть могла использовать TCP/IP внутри и вовне, не принимая власть DDN-PMO над каждым локальным хостом или портом.

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

Однако сама по себе зависимость не доказывает право управлять. Хранитель записей может стать важным потому, что участникам нужна совместимая информация, но при этом не иметь власти над их финансированием, внутренними системами или процедурами принятия решений. Спонсор может обладать прямой властью над собственной сетью, но влиять на внешних пользователей только через стимулы к совместимости. Расширение TCP/IP поэтому расширило область координации, не сделав эту область конституционно единообразной.

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

Более медленный переход был возможен, но не бесплатен

Реальные схемы TAC и UDEL позволяют смоделировать исторически правдоподобную альтернативу, не перенося более поздние технологии в 1983 год.

Предположим, DCA сохранила бы NCP как обычный сервис ARPANET после января и позволила хост-организациям переходить добровольно. Двухпротокольные TAC могли остаться доступными. UDEL или дополнительные хосты могли продолжить пересылку почты. Учётные записи ретрансляции Telnet и FTP могли соединять пользователей с несовместимыми сервисными хостами. Площадки могли загружать датированные копииHOSTS.TXTи использовать поля протокольных возможностей для выбора прямого или ретранслируемого пути.

Это снизило бы немедленное давление на сложные системы. Хост, зависящий от незавершённого порта вендора, мог бы подождать. Администраторы могли бы планировать переход с учётом местных кадров и обслуживания. Сервисные хосты могли бы пройти более длительные нагрузочные тесты до прихода всех пользователей. NIC могла бы улучшить распределение на основе TCP, пока площадки сохраняли старый путь.

Ценой была бы постоянная переходная служба.

Двухпротокольные TAC требовали постоянной поддержки ПО и тестирования. Ретрансляции — учётных записей, хранилища, операторов, документации и ёмкости. Двухэтапная передача файлов занимала дисковое пространство и требовала обслуживания. Пересылка почты требовала очередей, адресации с учётом протокола, актуальных сведений о получателях и персонала, способного проследить сбои в двух средах. Пользователи терминалов должны были понимать дополнительные команды и различать прямой и опосредованный доступ.

Устранение неполадок стало бы менее локальным. Сбойный сеанс мог затрагивать любую из конечных точек, любой протокольный стек, учётную запись ретрансляции, шлюз, устаревшую копию таблицы хостов или неверное поле возможностей. Персоналу поддержки пришлось бы сохранять экспертизу в обеих протокольных средах. Тесты пришлось бы продолжать, потому что NCP-путь мог оставаться работоспособным, пока соответствующий TCP-сервис незаметно деградировал, и наоборот.

Спонсор также продолжал бы платить за несхождение. Хост-организации, способные пользоваться ретрансляцией, могли откладывать сложную работу по переходу, потому что часть издержек перекладывалась на оператора ретрансляции. Чем полезнее становился сервис совместимости, тем легче было бы выживать унаследованным островам. Сетевые эффекты могли в итоге сделать NCP непривлекательным, но сроки остались бы неопределёнными, а операционный стык мог сохраняться годами.

Добровольный переход не обязательно был бы более децентрализованным. Он снизил бы драматизм одной даты, навязанной оператором, но усилил бы зависимость от администраторов ретрансляций, TAC, записей о возможностях и двухпротокольных сервисных хостов. Власть стала бы менее заметной, но не исчезла бы.

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

Реальный переход выбрал иное распределение издержек. Временное посредничество оставалось доступным, но его даты истечения заставили хост-организации взять на себя работу по внедрению. DCA и DDN-PMO использовали контроль над сетевым сервисом, чтобы сделать это распределение убедительным. Внешние сети, вне этого контроля, продолжали принимать TCP/IP по собственным графикам.

Как могла бы выглядеть более подотчётная координация в 1983 году

Более прозрачный переход не требовал современных систем аутентификации, автоматизированной глобальной репликации или допущений об изобилии вычислительных ресурсов.

Тот период уже имел строительные блоки для скромного улучшения: рассылаемые уведомления, поименованные операционные контакты, обследования статуса хостов, локальные копииHOSTS.TXT, процедура заявок, опубликованная таблица исключений, назначенные дни тестов, телефонная поддержка, ретрансляции и ручное сравнение записей.

Бюллетень № 19 можно было расширить до полного публичного формата решений для нечувствительных случаев. Каждая строка исключения могла содержать краткую категорию причины, дату подачи заявки, дату решения, утвердивший офис, условия включения NCP и сведения о том, была ли соблюдена заявленная дата перехода. Чувствительные детали могли оставаться закрытыми, не устраняя существование и статус решения.

Запрос о пересмотре мог бы направляться спонсору или операционному офицеру, не принимавшему первоначальное решение. Такая процедура не лишила бы DDN-PMO контроля над сетью. Она отделила бы первичное администрирование от пересмотра и создала бы запись о том, получали ли сходные операционные проблемы сходное решение.

Публикации о статусе могли бы также разделять совокупности. Таблица соответствия по сети 10, таблица абонентов DDN и информационный список внешних интернет-записей не дали бы смешанной таблице хостов выглядеть единым управляемым сообществом. Результаты могли бы различать зарегистрированную возможность, принятое прикладное соединение, успешный маршрутизируемый тест из другого класса адресов, одобренное исключение NCP, временную недоступность и необъяснённый исход.

Устойчивость распространения была возможна в ограниченной форме. Более одного read-only хоста могли бы обслуживать датированные копии таблицы хостов. Операторы могли сравнивать даты версий и выполнять ручные проверки согласованности с копией NIC. Это снизило бы зависимость от одной машины распространения во время сбоя. Это не децентрализовало бы право обновления: если каждое зеркало воспроизводит одну и ту же ошибочную мастер-запись, ошибка остаётся авторитетной.

Такие меры стоили бы времени персонала, хранилища, телефонной координации и дополнительной сверки. Записи могли расходиться. Публикация могла отставать от срочных операционных изменений. Часть оборонной информации нельзя было раскрывать. Повторный пересмотр мог задержать решение, необходимое для быстрого восстановления или защиты сервиса.

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

Запись о переходе подсказывает, что такое различие было бы полезно. RFC 842 могла показать, что адрес не принял сервис, но не почему. Бюллетень № 20 мог показать, что адрес сохранил NCP, но не полную причину. NIC могла публиковать заявление о протоколе, но не гарантировать наблюдаемую работу. DDN-PMO мог одобрить порт, но одобрение не могло исправить дефектную реализацию. Лучшая запись не схлопывала бы эти состояния; она держала бы их раздельно.

Изменившаяся власть была ограничена сетью

Январский переход достиг своей главной операционной цели. TCP/IP стал обычной средой связи ARPANET, основные сервисы перешли на него, а гетерогенные сети смогли участвовать через общий межсетевой уровень. Февральские обследования показывают сотни принимающих сервисных конечных точек, хотя одновременно демонстрируют неполную и зависящую от пути работу.

Сила перехода исходила из конкретной институциональной структуры. DARPA финансировала исследования и влияла на подрядчиков. DCA управляла ARPANET формально с середины 1970-х. DDN-PMO задавал операционную политику, решал исключения NCP и одобрял хосты и порты. IMP и сетевые операторы обеспечивали отключение протокола. Хост-организации контролировали внедрение на своих компьютерах. SRI-NIC регистрировала и распространяла операционную информацию. USC/ISI координировала назначенные номера. Операторы TAC и ретрансляций сохраняли временную достижимость.

Это разделение не позволяет принять самую сильную версию тезиса о централизации. Доказательства не показывают, что само переключение дало SRI-NIC новую власть решать, кто заслуживает имя, или дало USC/ISI новую власть исключать внешние сети через назначение номеров. Они показывают, что точные имена, адреса, протокольные возможности, значения номеров и сервисы распространения стали операционно важнее по мере того, как всё больше коммуникаций сходилось на TCP/IP.

Использованный рычаг лежал в другом месте. Отклонение NCP на уровне IMP сделало власть спонсора и оператора конкретной. Индивидуальные даты включения и истечения сделали усмотрение DDN-PMO значимым для затронутых адресов сети 10. Одобрение хостов и портов связало административные данные с активацией в сети во время разделения ARPANET/MILNET. Более поздние проблемы NIC с распространением таблицы хостов продемонстрировали зависимость от общего информационного сервиса, а не отказ политики. Координация назначенных номеров сохраняла уникальность, но изученная запись не содержит отказа или апелляции, связанных с переключением.

За пределами управляемой совокупности стимулы к совместимости заменили прямую команду. Внешние операторы принимали TCP/IP, потому что взаимодействие с растущим сообществом было полезно, потому что его поддерживали спонсоры или закупочные программы или потому что появились реализации. Их техническая зависимость от общих идентификаторов не делала их сети собственностью DCA, DARPA, SRI или ISI.

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

1 января имело значение, потому что оно положило конец бессрочному сосуществованию как политике ARPANET по умолчанию. Октябрьский, ноябрьский и декабрьский эксперименты продемонстрировали, как эта политика будет проводиться в жизнь. Январский реестр исключений показал, что принуждение было избирательным и временным, а не абсолютным. TAC и UDEL сохранили важнейшие стыки. Февральские обследования показали, что формальный переход, зафиксированная возможность, ответ приложения и маршрутизируемая достижимость остаются разными фактами.

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