摘要

  • TUBA提议让TCP、UDP和许多互联网应用继续工作，但把网络层从IPv4换成CLNP，并采用结构更丰富的NSAP地址。
  • 迁移不止是让路由器支持CLNP：主机、DNS、把IPv4地址写进报文的应用、路由聚合方式，以及谁有权维护CLNP标准都很关键。

保留下来的部分与被替换的部分

1992年6月，Ross Callon在RFC 1347中提出TUBA，即“TCP and UDP with Bigger Addresses”。当时互联网面对两项彼此关联的压力：32位IPv4地址日渐紧张，骨干网路由信息也迅速膨胀。TUBA并不是扩大IPv4字段，而是改用另一种网络层协议：TCP或UDP运行在ISO的无连接网络协议CLNP之上，再用NSAP地址替代IP地址。

这个名称强调应用和传输层可能保持熟悉，却没有说明网络层无需变化。浏览器、邮件或文件传输程序只要不在自身协议里依赖32位地址，就可能继续使用TCP或UDP。路由器实际转发的分组格式和寻址体系却要改变。Callon认为，CLNP已经提供无连接数据报服务，并且出现在一些互联网骨干和区域网络里；复用它，或许能少造一些新部件。

TUBA不要求互联网整体转向OSI。它只提出以CLNP取代IP，并保留TCP、UDP和相当一部分互联网应用。1993年12月发布的RFC 1561属于实验性备忘录，为TUBA环境定义CLNP配置。它同时承认，CLNP与IP提供的服务相近，却并不完全相同；需要明确怎样保留互联网协议所依赖的信息语义。

DNS和主机同样是迁移路径的一部分

RFC 1347设想新旧主机并行存在。新主机通过DNS查询对端，若得到IPv4地址，就走原有的IP路径；若得到较长的NSAP地址，就将TCP或UDP数据封装在CLNP分组中。DNS因此需要一种新的“long-address”记录。路由器则要分别转发IP与CLNP，可以用多协议设备，也可以用不同设备承担两套转发。设计依赖名称解析返回的地址来选择网络层，而非让每个分组在IP与CLNP之间转换或隧道封装。

这种分阶段安排让升级可以逐步发生，但并未消除彼此的依赖。支持TUBA的主机可能仍连接在只运行IP的网络里。FTP或NFS的一些用法会在应用交换中携带IPv4地址，因此即使TCP保留，相关应用也必须调整。主机软件、DNS运营和网络转发都要协调。地址变长也不会自动形成高效路由：NSAP分配必须与网络拓扑相符，路由才可能聚合。

TUBA的部署理由之一，是互联网上已经有支持CLNP的路由器。1995年1月的RFC 1752记录了一个重要区别：评审者认为这类路由器已有相当部署，但对CLNP主机和真正运行CLNP的网络规模看法不一。设备具备转发能力是有价值的基础设施；它本身不能证明应用之间已经有端到端连接。

复用协议也意味着依赖其维护机制

RFC 1752评审还提到CLNP报文头字段对齐、源路由、错误消息，以及NSAP地址如何支持路由聚合等问题。修复其中一些问题可能需要修改协议或配置文件。TUBA社区对此存在分歧：IETF能否修改ISO的CLNP标准，还是必须遵循ISO的标准流程？这不是单纯的组织手续。标准由谁维护，会影响故障修复速度，也决定依赖这层协议的运营者能否推动必要更改。

最后的IPng建议没有抹掉TUBA的贡献。经过讨论，RFC 1752建议以修订版SIPP作为IPng基础。它也说明，这是多个工作汇合的结果：SIPP提供了大部分基础协议，TUBA影响了自动配置和迁移机制，其他工作则影响地址结构和路由首部。CLNP最终没有成为互联网的新网络层，但TUBA并非一个毫无后续影响的“落败方案”。

Heng Lu后来写的Note:64可作为回看设计的视角，却不是1990年代史实的证据：互通必须共享哪些规则，哪些选择可以留给实施者，以及怎样证明系统已经被采用？TUBA提醒我们，复用既有协议可以减少重新发明，却不会自动回答谁维护它、哪些主机实现它、哪些网络真正转发它。

来源