改变权威的标志日：TCP/IP 切换后的治理

摘要

• 1983 年 1 月的切换规模不小但并不均衡：2 月的测量发现了数百个 TCP 服务端点，但结果因服务、地址群体、测试日期和网络路径而异，并且并未描述一个在午夜普遍切换的群体。
• 赞助方和运营方通过 IMP 层面拒绝 NCP 流量、DDN-PMO 例外决策以及主机或端口激活来行使杠杆作用；在操作上，对 SRI-NIC 记录和 USC/ISI 号码协调的依赖增加了，但未证明该切换赋予任一机构新的自由裁量权。
• 例外流程是真实的，但只是部分而非独立的：管理员可以提交例外申请（reclama），一份公开列表记录了临时 NCP 启用及到期日期，并且 TAC 和 UDEL 中继保持了有限的可达性，但公布的各项理由、完整的决策文件以及 DDN-PMO 之外的审查均付之阙如。

1983 年 2 月 1 日，在 ARPANET 从 NCP 向 TCP/IP 过渡的目标日期之后一个月，来自 ISI-VAXA 的一项测试尝试连接最近网络信息中心主机表中的每一个地址。结果并非一个被整齐划分为过去和未来的网络。而是一份充满已接受连接、拒绝、不可达地址、死系统和空白结果字段的等宽报告。

主机列表取自 1 月 28 日的 NIC 表。测试于 2 月 1 日和 2 日从 ISI-VAXA 运行，死机、不可达和拒绝条目于 2 月 3 日重试。该调查尝试了三种 TCP 服务：Telnet、FTP 和 SMTP。它不检查软件，不测试每个 TCP 或 IP 功能，不证明某台主机持续可用，也不枚举连接到参与网络的每台计算机。它记录了一个源端在特定时间段内尝试特定服务端口时发生的情况。

RFC 842，《谁在使用 TCP？》中的分母是 328 个地址行。其中，200 个以网络号 10 开头，即 ARPANET 地址空间，128 个属于其他网络。一行不一定对应唯一的物理计算机、机构、DDN 订户或组织。一个命名的系统可能出现在不止一个地址上；网关和其他操作条目也可能出现在表中。反之，未注册、已断开、保密或遗漏的系统则不在测量群体之内。

对 RFC 842 结果行的直接统计得出以下审计结果。FTP 的accepted+结果已纳入已接受项下。对于跨服务列的“死机”或“不可达”指示，按每种服务的该状态进行计数。

这些类别描述的是观测结果，而非解释。一个死机条目可能对应一台已关机但具有全功能 TCP 软件的计算机。一个不可达地址可能表明网关、路由、寻址或测量方面存在问题。拒绝可能意味着数据包到达了 TCP 端点，但应用程序不接受所请求的会话。空白结果并未揭示故障是出在主机、路径、服务还是表本身。在一个端口上的接受并不能证明完全符合 TCP、IP、ICMP、路由、名称处理以及主要应用的要求。

主机表也并非对赞助方 1 月目标合规性的普查。其 128 个非网络 10 行包括独立运营、研究、本地、外国、分组无线电、卫星链路及其他网络上的系统。它们的出现表明其参与了一个不断扩大的互联网环境。但这并未表明国防通信局能够命令其所有运营者进行过渡。

因此，标题中的“标志日”是一个回溯性标签，而非操作记录中的普通用语。当时通知中提及的是切换、转换或纯 TCP 实验。1997 年，由若干主要参与者撰写的一篇互联网协会历史文章将该事件描述为“标志日”式过渡。该后来的叙述抓住了截止日期的协调力，但压缩了 2 月表格所记录的不均衡实施情况。

不过，该切换仍然影响深远。这是一项由赞助方支持的决定，旨在停止将 NCP/TCP 共存视为 ARPANET 的正常未来。其意义不在于某个神话般的午夜转换，而在于使目标得以成立的机制：在交换网络中禁用 NCP 的测试、由运营方管理的例外流程、临时中继和终端支持、主机和端口审批，以及对准确共享记录日益增长的依赖。

1983 年 2 月 1 日至 18 日：变化的观测结果并非采纳曲线

第二项调查说明了为什么不能随意将总计转化为一个稳步采纳的故事。

RFC 843使用了 2 月 3 日的 NIC 主机表，并于 2 月 8 日和 9 日从 ISI-VAXA 进行测试。其群体从 328 行增至 329 行。已接受的总数分别为 Telnet 187、FTP 174、SMTP 170，而上份报告为 183、170 和 169。但网络 10 和非网络 10 组朝相反方向变动。

网络 10 的已接受数量在所有三种服务中均上升。其他网络的数量在所有三种服务中均下降。底层表格也变动了一行，且单台计算机可能在一项测试中运行，而在另一项测试中不可用。若不进行配对条目分析以控制新增、移除、临时故障和路径变化，两项调查显示的是变化的观测结果，而非衡量出的采纳速率。

十天后，RFC 844提出了一个不同的问题。它选取了在 RFC 843 中接受 Telnet 的 187 个条目，并尝试从 BBN 的 C 类网络 192.1.2 上的一个终端集中器访问它们。成功不仅需要沿着先前路径有一个接受 Telnet 的服务，还需要数据包和回复能通过网关路由、C 类寻址以及相关的 ICMP 行为正常工作。

连接是通过点分地址手动输入的，并且只进行了三次尝试。在此期间不可用的主机可能被遗漏。然而，结果揭示了表面上的 TCP 成功在多大程度上依赖于测试源点和网络路径。

187 个中的 127 个这一总数无法支持外部网络落后于 ARPANET 的简单说法。非 A 类组具有最高的观测成功率，32 个中成功 30 个。该测试亦未确定每个不成功的条目均缺乏 C 类或 ICMP 支持；临时可用性和路径条件仍未解析。

综合来看，这三份报告确立了一个较窄但重要的事实。目标日期一个月后，数百个表格行接受了主要的 TCP 服务，而记录的能力、应用可用性以及来自不同源端的可达性仍然不均衡。该切换催生了大量操作，而非即时统一。

这是第一道治理边界。测量使得实施情况可见，但测量并不决定主机为何失败或应采取何种补救措施。这些决策属于主机管理员、实现者、网关和交换运营商、NIC、DDN 项目办公室、研究赞助方，以及赞助方控制群体之外的自主网络运营商。

1981 年 11 月：该计划旨在结束中介

该操作目标最初是一个分阶段计划，而非声称数百台机器可一次性改变。

1981 年 11 月发布的RFC 801将 1983 年 1 月 1 日定为 ARPANET 从 NCP 完全转向 IP 和 TCP 的目标。它要求各主机组织在 1982 年 1 月 1 日前开始实施 IP/TCP，并对 Telnet、文件传输和邮件承担同样的本地责任。新的 ARPANET 主机预计将以 TCP/IP 开始，而非通过 NCP 接入。

该计划的里程碑揭示了其实际设计。具备 TCP 能力和纯 TCP 主机业已存在。中继服务有望桥接不兼容的主机。最后的纯 NCP 转换拟于 1982 年 1 月开始；多数主机预计在 7 月前具备 TCP 能力；最终转换计划于 11 月完成。只有到那时，1983 年 1 月才会带来完整的 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 年 10 月至 12 月：执行转移到 IMP

1982 年 10 月 1 日，东部时间中午 12 点至下午 4 点，ARPANET 进行了一次纯 TCP 实验。在这四个小时内，接口消息处理器（IMP）被指示拒绝使用链路 0 的主机消息，该链路与 NCP 主机间流量相关。IMP 返回一个类型 7、子类型 3 的状态，表明与目的地的通信“被行政禁止”。

该机制在ARPANET 新闻第 14 号中有所描述，是切换中操作强制性的最清晰证据。NCP 并非仅在一份文件中被弃用。分组交换基础设施拒绝了相关流量。纯 NCP 主机在测试期间无法使用 ARPANET。具有共享远程主机状态的双协议系统也可能遇到问题，除非管理员在该时段禁用其 NCP 实现。

执行点很重要。不是 SRI-NIC 删除一个名称，也不是 USC/ISI 拒绝一个号码。IMP 在网络管理指令下执行拒绝，网络操作中心以及与 DCA 相连的管理层负责运行环境。返回的状态旨在让提交主机看到拒绝的行政性质。

第 16 号新闻提醒管理员 10 月 1 日的测试，并要求参与者向 Jon Postel、NOC 和 NIC 报告观测情况。它还敦促各站点在 1 月前实现 SMTP 和四字节互联网寻址。在此，协调结合了多项功能：交换网络创建测试条件；实现者和主机管理员观测故障；ISI 接收技术报告；NOC 监视运行；NIC 分发指令并收集实施信息。

四小时实验之后是更长的演练。第 17 号新闻宣布 11 月 15 日和 12 月 13 日至 14 日为 24 小时纯 TCP 时段。将使用相同的 IMP 级别拒绝方法。该通知明确警告，这也是 1 月 1 日目标日期之后拟用的机制。

这些测试提供了主机表声明无法提供的信息。一个站点可能报告它具备 TCP，但在禁用 NCP 的日子里却发现某个生产服务、邮件程序、终端路径、网关或本地操作程序仍依赖 NCP。一台主机可能通过实验室测试，但在全运营期的流量和用户行为下却失败。重复实验增加了在持续性网络策略改变前发现依赖性的机会。

测试还创造了杠杆作用。一台受赞助方控制但尚未转换的主机无法在整个测试期间简单地继续使用旧协议。其用户体会到未转换的后果，其管理员从网络接收到特定的状态。这与通过 RFC 进行说服有实质性不同。

然而，这种杠杆作用是有限度的。它直接适用于通过 ARPANET IMP 提交的 NCP 流量。它无法触及内部运行 NCP 的独立本地网络、未加入 ARPA 互联网的外部网络，或后来在 RFC 842 中列出的每个非网络 10 地址。受 DARPA 资助的研究伙伴可能面临合同预期或强大的互操作性激励，但这些关系与 DCA 对 ARPANET 运营的控制并不相同。

同样的区别限制了关于注册的主张。测试证明运营商可在交换层禁用一项协议。它们并未证明该切换赋予了 NIC 对名称的新裁量权，或赋予了 USC/ISI 对号码分配的新裁量权。这些管理职能对互操作性很重要，但观察到的强制行为发生在别处。

1983 年 1 月：例外是公开的，但仅是部分公开

操作政策并非一个没有延迟途径的截止日期。

1982 年 12 月 22 日的ARPANET 新闻第 19 号声明，在 1 月 1 日东部时间 00:01 之后，未经 DDN 项目办公室特别例外，将不允许使用 NCP。它将例外请求命名为reclama，并说明了如何提交。

1 月之前，请求可通过网络邮件发送至 DDN-PMO 地址，并抄送 NIC。截止日期后，无法使用网络的管理员可通过美国邮政将请求发送至 DCA 总部。这条离线途径在操作上很重要：该政策并未假设寻求恢复 NCP 访问的人仍拥有功能正常的网络访问。

申请人必须提供详细的理由、转换时间表、已知的预期 TCP/IP 实现来源，以及需要互操作性的主机列表。提供了指定的 DDN-PMO 联系人以便获取更多信息。这是一项有文件记录的申请流程，具有明确的决策机构和规定的信息要求。

1 月 13 日分发的第 20 号新闻随后发布了一张包含已启用 NCP 地址和计划转换日期的表格。直接计数有 44 个地址或端口行。它们并非 44 个独立的组织。若干机构拥有多个物理或逻辑主机地址；有两行被标记为测试端口；另一行标识了 S1 网关。有一行的切换日期未知。标注日期的行范围从 1 月 16 日至 5 月 1 日，不过有 25 行被分配为 2 月 1 日。

旧的缩写网络 10 表示法强化了该表格所代表的内容：ARPANET 环境内的操作地址或端口条目。它并非唯一法律实体、合同、站点或人类决策者的列表。亦非在更广的 DDN 或 DoD 中仍使用残留 NCP 的每台计算机的完整清单。

第 20 号新闻称，已对面临严重服务中断的站点授予豁免，并强调每名主机管理员必须单独请求 NCP 启用。它还表示截止日期是严格的。因此，该表格将一项行政决策与具体的网络条件联系起来：为指定地址继续启用 NCP，直至指定日期。

这比推断缺乏治理更有说服力。存在一份部分公开的例外登记册。社区可看到哪些列出的地址保留了 NCP，以及大多数预计何时转换。申请通知披露了决策者和申请人必须提交的材料。发布这些行还有助邮件用户判断何时可能需要中继。

该登记册在其他方面是不完整的。它未在每个地址旁给出理由。它未再现申请、支持证据、条件、拒绝情况或各个截止日期背后的分析。经审查的通知未确定独立的审查机构或针对 DDN-PMO 决定的上诉机制。它们未揭示类似案件是否得到一致处理，或每次临时启用是否均出现在表中。

因此，准确的制度结论是有限定的。该切换并非缺乏例外程序或任何公开状态报告。具有一个中央操作决策者、个别申请、临时启用、公开的地址行以及到期日期。其公开记录中缺乏的是完整的决策文件、逐案推理，以及独立于网络政策管理当局的审查。

这种组合比公共宪政体系更适合一个受管理的国防网络。DDN-PMO 在决定一项过时协议可在其承担运营责任的环境中保持活跃多久。申请人是寻求持续服务的主机管理员，而非主张普遍使用权使用任何协议的公民。后来的治理意义之所以产生，是因为技术环境及其共享记录扩展到了受原始关系治理的群体之外。

1983 年 1 月至 2 月：TAC 和 UDEL 维持接缝

该切换并未在 1 月 1 日消除所有中介。它将中介集中在特定的临时设施中。

第 20 号新闻宣布，ARPANET 终端访问控制器（TAC）将在 1 月期间继续支持 NCP。终端用户可通过 TAC 连接，并输入额外命令以访问 NCP 主机。2 月 1 日，TAC 计划变为仅支持 TCP/IP。

这种延续很重要，因为终端访问是进入服务主机的常见途径。用户自己的终端并不像连接的计算机那样实现完整的主机协议栈。TAC 为终端对主机的访问充当中介。在那里保持双重支持，为那些目标系统或支持系统尚未完成转换的人保留了一条操作路径。

特拉华大学提供了另一座实际的桥梁。UDEL 同意在 TCP 和 NCP 用户之间运行一个邮件转发中继。向 NCP 目的地发送邮件的 TCP 发件人使用包含收件人账户和 NCP 主机名的 UDEL-RELAY 格式。向 TCP 收件人发送邮件的 NCP 发件人使用 UDEL-TCP。当目的地的当前状态不确定时，该中继也可完成同一协议的事务。

这并非隐式转换。用户必须知道发件人的协议，并相应地构建地址。错误的寻址可能导致消息被退回。该中继需要正常工作的邮件软件、可达的主机、工作人员联系、队列和磁盘容量，以及对目的地协议状态的当前了解。公开的例外列表旨在使最后一项依赖更易管理。

这些调节揭示了切换的实际质构。执行与援助并非对立。运营商可拒绝普通的 NCP 流量，同时保留选定的 NCP 地址、延长 TAC 支持并安排邮件中继。临时兼容性减少了中断，但未放弃截止日期。

该安排还说明了为何准确的记录在操作上变得更加重要。一条过时的能力条目可能将邮件导向错误的程序。错误显示为已转换的主机可能无法再通过普通的 NCP 路径访问，而将已转换主机视为仅支持 NCP 则可能吸引不必要的中继使用。UDEL 的说明使源协议成为决定性因素；例外表格有助于识别残留的目的地；TAC 时间表告知用户终端路径何时消失。

这种依赖并未使 NIC 成为每项决策的来源。DDN-PMO 批准了 NCP 例外。网络运营商在交换环境中实现了启用。UDEL 运行邮件中继。TAC 运营商提供终端兼容性。NIC 分发新闻通讯和表格。每个机构控制着不同的环节。

中继也对反事实主张施加了约束。技术上较慢的转换是可能的，因为双协议 TAC 服务和 UDEL 转发在运行中存在，而不仅停留在纸面上。但维护它们需要人员、主机容量、用户说明、访问控制、存储、地址知识、故障排除和持续测试。延长共存期会延长这些成本。

无需虚构安全事件来确立负担。中间账户、存储的文件或消息以及额外的服务计算机无论是否发生入侵都需要管理。现存资料并未证实过渡中继导致了此类事件。它们确实证实中继的可靠性、负载、账户控制和临时存储是公认的操作问题。

记录进入操作路径却未成为单一权威

协议转换、主机注册、端口审批、号码分配和信息分发是相互关联的，但它们并非由单一机构行使的一种权力。

主机表层在 1 月转换之前就已存在。1982 年 3 月发布的RFC 810用专为 DoD 互联网络设计的格式取代了旧的面向 ARPANET 的表格格式。新格式描述了网络、网关、主机、互联网地址、操作系统和协议能力。一行能够区分 TCP/Telnet 与 NCP/Telnet，或记录 SMTP 是否可用。

该表可以HOSTS.TXT文件形式从 SRI-NIC 下载，或通过主机名服务器获取。本地副本减少了对每个连接进行实时查询的依赖，但它们造成了一个熟悉的致性问题：旧副本可能保留已弃用的地址或过时的协议声明。转换增加了这种差异产生影响的频率，因为用户和应用程序不仅需要知道名称和地址，还需要知道目的地支持哪种通信环境。

RFC 810 还在其声明的范围内强制实施了一条正式规则。DoD 网络、网关和主机的名称与地址须在使用前以及 DoD 主机传送其流量前与 NIC 协商并注册。在过渡期内，NIC 将尝试在运营商提供时为非 DoD 网络保留可比信息。

该文本确立了一项注册要求。它并未确立一个有文件记录的案例，表明 NIC 因 TCP/IP 截止日期而拒绝了有争议的名称、排除了原本可正常运作的外部网络，或获得了新的政策裁量权。该要求已是 1982 年主机表规范的一部分。转换使记录的准确性和覆盖范围变得更加重要；证据未显示它创造了该规则。

RFC 811将 NIC 主机名服务器描述为在 SRI 代表 DCA 运行的一项可通过 NCP 和 TCP 访问的服务。程序可按名称请求记录、按地址请求记录，或检索整个表。该协议定义了可能的回复，适用于名称或地址未找到、非法命令或临时系统故障等情况。

这些响应代码展示了消费软件须准备处理的情况。它们并未显示此类故障发生的频率，也未识别出因此实际失去服务的用户。缺失记录可能导致基于名称的查找失败，而直接数字通信仍可能。临时服务器故障可通过本地表缓解，尽管该副本可能过时。该 RFC 将单一全局数据库呈现为通往分布式名称到地址服务途中的过渡安排。

在围绕计划中的 ARPANET/MILNET 分离的操作通知中，出现了一个更直接的行政关口。1982 年 12 月 17 日的第 18 号新闻称，准确记录主机和 IMP 端口对于在分离期间避免拒绝错误用户的服务是必要的。BBN 被指示禁用未使用的端口，并仅在 DDN-PMO 批准后激活。新主机和端口变更需提前协调。

第 21 号新闻后来修订了该程序。新主机审批、端口激活或有源端口上的主机变更请求发送至 SRI-NIC 的一个邮箱。所需信息包括主机名称和地址、位置、硬件、操作系统、赞助方、协议和技术联络详情。

在此，数据准确性与操作激活直接结合在一起。但第 18 号新闻中所述的理由是网络分离和端口管理，而不仅仅是 NCP/TCP 转换。决策机构是 DDN-PMO；BBN 根据指示控制端口状态；NIC 接收、维护和传播信息。将这三者视为“注册机构”会掩盖权力实际所在。

分配号码构成了另一个独立层面。1983 年 1 月发布的RFC 820记录了用于网络号、协议号、端口、套接字及其他实现字段的值。它指示申请人联系 USC/ISI 的 Jon Postel，并称分配根据 DARPA 信息处理技术办公室与 DDN-PMO 之间的协议处理。

唯一号码对于防止实现冲突和模糊的数据包解释是必要的。这种必要性促使了对协调分配的依赖。此处审查的现存材料未显示与切换相关的拒绝、对分配决定的上诉或 Postel 正式裁量权的前后变化。RFC 820 记载了一项协调职能及其制度环境；它本身不能证明 1 月事件扩大了该职能的权限。

这些机制之间的区别是整件事的因果核心：

• 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 记录指南称运营于 1973 年移交给 DCA。一份同时期的 DCA 出版物给出了一个较晚的正式日期：该局 1978 年的ARPANET 信息手册称管理责任于 1975 年 7 月 1 日移交。

在没有底层分阶段移交记录的情况下，这些陈述不应被强行赋予虚假的确定性。后来那份查询指南或许描述的是较早的运营交接，而 DCA 自己的手册则指出了管理责任的正式移交。就正式日期而言，同时期的 DCA 叙述更具说服力。到 1982 年，实时通知本身已对运营层级毫无歧义：它们由 NIC 为 DCA 的 DDN 项目办公室分发，网络管理指令即出自该结构。

到 1983 年 1 月，至少须将五个群体区分开来。

ARPANET 网络 10 群体是 RFC 801 NCP/TCP 计划和 IMP 级别纯 TCP 测试的直接对象。DCA 的运营控制和 DDN-PMO 的例外决策在此具有最清晰的效力。

MILNET 和其他 DDN 订户属于一个仍在组建和分化中的更大国防环境。它们的协议义务不可简化为 ARPANET 计划中的每一行。被再现为RFC 942的 1985 年国家研究委员会报告称，MILNET 骨干网本身并不要求使用 TCP，尽管订户通常被要求使用它。

其他 DoD 网络遵循不同的技术和采购路径。RFC 942 描述了已使用 TCP 的网络、计划稍后转换的网络，以及使用其他协议的系统。因此，“DoD 互联网”并非一个完成了某个统一 1 月事件的单一群体。

受 DARPA 资助的外部研究伙伴可能面临赞助方期望，并深度融入实验性互联网工作。UCL、卫星网络参与者、分组无线电研究人员和承包商属于具有不同运营控制程度的合作安排。它们在协议文件或主机表中的出现并未使每台机器都成为 DCA 的订户。

独立的和后来外部采纳者受 DCA 命令的约束更弱。它们选择 TCP/IP 可能因为实现可用、有价值的通信对象使用它，或因为不兼容的协议带来了日益增长的机会成本。这种网络效应压力可能很强大，却并未产生 DCA 对它们内部系统的管辖权。

RFC 942 尤具价值，因为它保留了这些区分，同时也记录了切换的操作后果。国家研究委员会的工作通过 DCA 合同获得支持，并于 1985 年出版，因此它是一份在一定程度上受国防标准辩论影响而形成的回顾性评估，而非一份中立的 1 月普查。

该报告称，在切换前的六个月里，大约有 30 台纯 TCP 主机加入了已有的双协议群体。它认为广泛的测试维护了运营能力，并表示在几个月内就达到了正常的服务水平。它还记载，NIC 尚未准备好支持新协议，导致了主机表分发问题，并且服务主机由于此前未长时间承载完整的用户负载，需要进行大量的性能分析和参数调优。

这些都是集中式依赖的有文件记载的后果。表格分发是一项运营依赖，而非仅仅是行政象征。在有限测试中运行正常的服务软件，在持续需求下仍可能步履蹒跚。一个能够对齐实施的截止日期，同时也将负载集中到了通用服务上。

同一份报告使一个胜利叙事变得复杂。它称 ARPANET 普遍使用 TCP，而一些用户继续使用 NCP。该目标日期两年后的声明未识别所涉及的主机或路径。它确实驳斥了任何声称每种残留使用均在午夜普遍消失的字面说法。政策转换、正常网络服务、主机软件、本地使用以及临时或例外的可达性属于不同状态。

外部采用：命令终止之处，兼容性开启之时

TCP/IP 更广泛的成功取决于扩展到 DCA 能够管理的群体之外。

RFC 801 描述了一个连接 ARPANET 与分组无线电、卫星、本地及其他网络的 ARPA 互联网。RFC 842 和 RFC 843 包含了网络 10 之外的地址。RFC 844 证明了一条非 A 类测试路径可以成功抵达许多条目。这些资料展示了一个到 1983 年初已跨越技术和制度边界的互联网络环境。

它们并未确立一个横跨该环境的法律或行政制度。

对于网络 10 的主机，IMP 对 NCP 的拒绝是一个直接的操作事实。对于单独管理的网络，决定性因素可能是获得 TCP 实现、网关关系、研究合同、访问 ARPANET 服务的意愿，或不断增长的兼容通信对象数量。一个网络可以在内部和外部使用 TCP/IP，而不必接受 DDN-PMO 对每个本地主机或端口的权威。

这一差异解释了共享记录如何变得比原始赞助方的管辖权更具后果。一个独立运营的网络在与更广泛的互联网通信时需要唯一寻址和协议值。其用户受益于准确的名称信息和可达的网关。对共同协调的依赖可能延伸至最初支持该协调服务的合同权限之外。

然而，仅依赖并不证明有治理权。记录保管人可能因参与者需要兼容信息而变得重要，同时却缺乏对其资金、内部系统或决策程序的权威。赞助方可能对自身网络拥有直接权威，但仅能通过互操作性激励影响外部采用者。因此，TCP/IP 的扩展拓宽了协调领域，却未使该领域在宪制上变得统一。

这也正是为何不能将后来所有的注册权力归功于该切换。中央主机表、分配号码协调和 DoD 注册规则早已存在。改变的是，一个更大的兼容性环境在操作上暴露于错误、过时能力数据、号码冲突、网关故障和分发薄弱环节。后果的增加与全新创设的裁量权并不等同。

较慢的转换是可能的，但并非没成本

基于实际的 TAC 和 UDEL 安排，有可能模拟出一个历史上合理的替代方案，而无需将后来的技术引入 1983 年。

假设 DCA 在 1 月之后将 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 例外、临时不可用以及无法解释的结果。

分发弹性可能以有限形式实现。多台只读主机本可提供带有日期的主机表副本。操作员可以比对版本日期，并与 NIC 副本进行人工一致性检查。这将减少中断期间对单台分发机器的依赖。但它不会分散更新权限：若每个镜像都复制同一份错误的主记录，该错误仍具权威性。

这些措施会耗费员工时间、存储、电话协调和额外的核对工作。记录可能不一致。发布可能滞后于紧急的运营变更。某些防务信息无法披露。第二次审查可能延迟为恢复或保护服务而需迅速做出的决定。

这些成本恰恰说明，问责不可被视为技术协调的免费附加项。相关的比较在于，维护更清晰记录的成本与当操作员无法确定故障是技术性、行政性、临时性还是蓄意性时所引发的成本之间。

转换记录表明，这种区分本会是有用的。RFC 842 可显示一个地址未接受某项服务，但无法显示原因。第 20 号新闻可显示一个地址保留了 NCP，但无法显示完整理由。NIC 可发布一项协议声明，但无法保证观测到的运行。DDN-PMO 可批准一个端口，但批准无法修复存在缺陷的实现。更好的记录不会将这些状态混为一谈；它会将它们区分开来。

被改变的权威受网络限制

1 月的转换达成了其主要操作目标。TCP/IP 成为 ARPANET 的正常通信环境，主要服务迁移至其上，异构网络能够通过一个共同的互联网络层参与。2 月的调查显示有数百个接受服务的端点，尽管它们也显示出不完整且依赖路径的运行。

该切换的力量源于特定的制度结构。DARPA 资助研究并影响承包商。到 1970 年代中期，DCA 正式管理 ARPANET。DDN-PMO 制定运营政策、决定 NCP 例外并批准主机或端口。IMP 和网络运营商强制执行协议禁用。主机组织控制其计算机上的实施。SRI-NIC 注册并分发运营信息。USC/ISI 协调分配的号码。TAC 和中继运营商维持临时可达性。

这种分工否定了最强版本的集中化主张。证据并未显示，该切换本身赋予了 SRI-NIC 决定谁配获得某个名称的新权力，或赋予了 USC/ISI 通过号码分配排除外部网络的新权力。它表明，随着更多通信汇聚于 TCP/IP，准确的名称、地址、协议能力、号码值和分发服务在操作上变得更为重要。

实际施加的杠杆在别处。IMP 层面对 NCP 的拒绝使赞助方和运营商的权威具体化。个别的启用和到期日期使 DDN-PMO 的裁量对受影响的网络 10 地址具有后果。主机和端口审批在 ARPANET/MILNET 分离期间将行政数据与网络激活挂钩。NIC 后来的主机表分发问题表明了对共享信息服务的依赖，而非政策拒绝。分配号码的协调保留了唯一性，但审查的记录未提供与切换相关的拒绝或上诉。

在受管理群体之外，兼容性激励取代了直接命令。外部运营商采纳 TCP/IP，因为与一个不断增长的共同体互操作是有用的，因为赞助方或采购计划支持它，或因为实现变得可用。它们在技术上对共享标识符的依赖，并未使其网络成为 DCA、DARPA、SRI 或 ISI 的财产。

因此，制度成就与合法性问题有所区别。成就是跨异构系统的协调互操作性。合法性问题在于，不断扩大的运营依赖可能超越那些为较小赞助方控制环境而设立的机构的决策记录、审查程序和连续性安排。

1 月 1 日之所以重要，是因为它终结了作为 ARPANET 默认政策的无限期共存。10 月、11 月和 12 月的实验展示了该政策将如何被执行。1 月的例外登记册表明，执行是有选择性和临时性的，而非绝对的。TAC 和 UDEL 保留了必要的接缝。2 月的调查表明，形式上的转换、记录的能力、应用的响应以及经路由的可达性仍是不同的事实。

该切换通过使某些现有权力在操作上变得决定性而改变了权威：禁用一项协议、批准临时续用、激活端口、分发一份共享记录或维护一个中继的权力。它还增强了对这些权力触及范围之外的协调依赖。这比声称单一权威切换了互联网更为精确——也比那个完美午夜的传奇更具深远影响。