摘要

  • RFC 3147 补上混合管理网缺少的方向：IPv4 或 IPv6 先进入 GRE，完整 GRE 报文再成为 CLNP 的用户数据，使新式 IP 网元能够穿过既有 CLNS 内部网络。
  • 建议使用的 N-SEL 十进制 47 只让 CLNS 端点把载荷交给 GRE；内层协议由 GRE Protocol Type 说明。任何一个编号都不能证明管理命令已被设备执行。
  • 这项设计把迁移还原为依赖管理：在可达性、报文尺寸、安全与设备结果分别得到验证以前，旧网络可能仍是新网络的运行条件。

被替代者仍握着通路

SONET 与 SDH 网元的管理网在 2001 年已经不是一张白纸。Bellcore GR-253-CORE 与 ITU-T G.784 曾要求这一管理环境使用 CLNS，于是运营者手里形成了规模可观的既有网络。设备厂商随后把新网元转向 IP 管理，端点的协议变了，端点之间的地理与传输依赖却没有跟着消失。

过渡因此产生两种相反的孤岛。一种是旧 CLNS 网元隔在新 IP 网络之后，可以把 CLNP PDU 用 GRE 封装进 IP。另一种恰好倒过来：新的 IP 网元位于仍在工作的 CLNS 网络另一侧。第一条隧道不能反向回答第二个问题，因为这次需要过境的载荷是 IP，能够提供路由的内部网络却是 CLNS。

RFC 3147 给出的办法很窄：把 IPv4 或 IPv6 报文放进 GRE，再把整个 GRE 报文置于 CLNP Data Type PDU 的数据部分。CLNS 把 PDU 转发到隧道出口，出口剥掉 CLNP 与 GRE，才把内层 IP 报文送向网元。

CLNS 并没有因此变成 IP 网络，旧网元也没有突然学会新协议。规范只在两个隧道端点之间搭了一条限定用途的路。若把“有路”写成“已经替换”，迁移记录便从第一行开始失真。

三层报文是三份不同收据

内层 IP 头描述一段 IP 通信；GRE 头用 Protocol Type 说明载荷应按哪一种网络层协议解释；外层 CLNP 头则提供实际穿越 CLNS 域所需的地址与转发语义。三层嵌套不是重复包装，而是三个分别成立、也可能分别失败的动作。

CLNP PDU 到达隧道出口，只证明承载层把这一 PDU 送到了那里。GRE 头合法，只证明出口知道如何解释里面的字节。IPv6 报文完成解封装，也只证明出口交付了这些字节。它们都不能单独证明某台网元接受了命令、返回了应答或改变了配置。

标识也不能混在一起。NSAP 指向 CLNS 端点；IP 地址指向 IP 层接口或目的地；设备的运营身份还可能依赖资产清单、机架位置、证书或序列号。迁移脚本若把三者写进一个 device_address，地址一变，历史因果就会随之被覆盖。

更稳健的证据链从管理意图开始，依次保留内层 IP、GRE 封装、CLNP 承载、CLNS 转发、隧道解封装、应用应答与设备实况。后一环失败，不应抹掉前一环成功；前一环成功，也不应替后一环发证明。

数字 47 只负责开门

CLNS 用 NSAP 最后一个八位组 N-selector（N-SEL）区分不同的 Network Service 用户。隧道出口需要一个共同约定，知道某个 CLNP 用户数据从 GRE 头开始。RFC 3147 建议使用十进制 47，恰好与当时 IP 协议号空间里的 GRE 编号相同。

这个复用方便记忆，却不赋予数字额外权威。N-SEL 47 让 CLNS 端点选择 GRE 处理程序；它不说明 GRE 里面最终是 IPv4 还是 IPv6。真正的内层协议仍由 GRE Protocol Type 决定。监控系统若把所有 N-SEL 47 流量直接记作“IPv4 管理”，就把一层信息删掉了。

“建议”二字也不能丢。多厂商互通要求两端对 N-SEL 取得一致，47 是一个公共约定。它出现在 RFC 与编号表中，能证明规范含义，不能证明所有厂商实现一致，更不能证明某家运营者实际部署成功。

一份可审计收据至少要同时记录源与目的 NSAP、N-SEL、GRE 版本与标志、GRE Protocol Type、内层地址、报文指纹和观察时刻。“隧道正常”不足以解释究竟哪一扇门为哪一种流量打开。

小报文能通过，不等于路径可用

封装会增加报文长度，而旧网络内部链路的限制，新的 IP 端点未必能够看见。CLNP 有 Segmentation Permitted 标志。RFC 3147 建议将其置位。如果不允许分段，而某个 CLNP PDU 超过内部链路可承载的最大尺寸，CLNS 可以直接丢弃；内层 IP 源端甚至可能收不到有用解释。

这种故障对管理流量尤其危险。一个很短的查询或 ping 能够通过，体积较大的配置事务却在同一路径消失。运维人员可能在小包测试后宣布通道可用，随后把大包失败错误归因于设备或应用。真实条件是：可达性取决于长度、封装开销与分段策略。

隧道入口还要处理 IPv4 Path MTU Discovery。若过大的内层 IPv4 报文没有设置 Don't Fragment，入口可以先分片再封装；若设置了 DF，就要丢弃并返回适当的 ICMP fragmentation-needed。连这条 ICMP 也需要一条可工作的回程路径。

因此证据不能只有“成功/失败”。应保存原始长度、DF、GRE 与 CLNP 开销、CLNP 分段位、限制链路的 PDU 尺寸、分片、ICMP 与观察点。缺少这些坐标，尺寸黑洞会伪装成时好时坏的网元。

封装不是安全机制

RFC 3147 明确指出，CLNS 与 GRE 在此用法中都不提供安全。如果管理流量需要保护，应在进入 GRE over CLNS 之前用其他方法保护载荷。规范没有把隧道包装成认证、加密或授权系统。

一个报文可以在三层网络头上都完全正确，却仍是一条未获授权的管理命令。出口可以原样解封装，而管理应用仍可拒绝它。反过来，没有独立设备身份与信道保护时，一个看似成功的应答也可能被伪造或绑定到错误对象。

后来出现的 GRE 扩展和今天常用的安全工具可以改善实际部署，却不能倒填进 2001 年 7 月的文档。历史判断要写明实际观察到哪项机制，而不是因为现代读者熟悉它，就把现代属性赠给旧封装。

过渡让旧网络获得新的杠杆

一旦新的 IP 网元依赖 GRE over CLNS 才可达，CLNS 就不再只是等待清理的遗留成本。它成了新设备运行路径的一部分。过早拆除它，可能首先隔离那些本来用来证明“现代化”的设备。

这不是说 CLNS 永远不能退出，而是说退出需要另一套证明：每个依赖网元都有经验证的新路径；不同尺寸的事务均可工作；安全控制已经随路径迁移；回滚经过演练；设备结果而不只是隧道计数在切换后保持正确。

控制 CLNS 路由与 NSAP 规划的一方，在过渡期掌握一片运行表面；控制 IP 端点的一方掌握另一片；厂商掌握设备的管理行为；业务负责人承担中断后果并授权切换。标准可以让接口互通，不能把这些权力与激励合并成一个“网络所有者”。

所以迁移图除了协议云，还应标出所有权与证据边：谁能改 N-SEL，谁看得到内部丢包，谁能核实设备状态，谁有权拆除回退路径。技术上的桥只能在这张制度拓扑里真正工作。

共存不是失败，而是诚实架构

互联网史常被写成一条胜负序列：新协议胜出，旧协议退出，新栈取代旧栈。RFC 3147 保留了不够整齐、却更真实的一段。为了让旧 CLNS 网元隔着 IP 继续工作，需要 CLNP over IP；为了让新 IP 网元隔着 CLNS 可达，又需要 IP over CLNS。两种过渡依赖迎面穿过彼此。

这份 RFC 的克制反而构成价值。它只说明 GRE 放在哪里、CLNS 端点怎样分流、报文尺寸如何处理，没有发明通用管理应用、全能安全制度或统一退网计划。这是最小初始规范：先把可互操作的接缝说清，把未来选择留给本地运行者。

运行代码则保留上诉权。若报文穿过所有封装，设备状态却没改变，管理动作仍然失败；若小包成功、大包消失，路径就不能被概括为“可用”；若旧 CLNS 路由仍是唯一回退，替代就没有完成。“IP 管理”与“现代化”可以组织计划，不能推翻这些事实。

RFC 3147 留下的历史判断很朴素：继任架构最初往往只是被前任架构承载的一类流量。隧道可以让运营者在修建下一条路时保持连续性，却无权宣布过渡已经结束。

来源