Summary

  • IOTOPS 工作组 2026 年 11 月 1 日的第 03 版草案提出：设备更换 Manufacturer Usage Description（MUD）网址时，控制器应沿着已接受的根文件和签名身份判断继任文件。它仍是互联网草案。
  • 厂商搬迁主机时，可由旧位置的签名文件声明新的规范网址。草案要求控制器原则上不要仅凭跨主机名的 HTTP 301 跳转接受迁移。
  • 收购完成并不回答运营问题：哪些设备已升级固件，哪些控制器已拿到新文件，哪些防火墙真装上了新规则。

并购协议签完，仓库里的设备不会跟着改配置。RFC 8520规定了 MUD 机制：设备通告一个网址，网络控制器取得厂商提供的文件，再把设备预期的通信方式落实为本地访问规则。网址看起来像普通文件地址，实际上站在防火墙决策的上游。产品换了主人，它仍可能指向旧公司的服务器。

IETF 的新草案用假设的烤面包机、文件搬迁和公司收购讲这个难题。草案没有报告某起真实收购事故；它列出的是迁移时必须走过的技术关口。第一个关口甚至不在新域名，而在旧版本固件：如果厂商直接改写原网址的 MUD 文件，新固件所需的额外连接也会开放给未升级的旧设备；若删除旧连接，旧设备的正常流量又可能被当成异常。

厂商签了名，也可能签错设备的通行证

按固件版本换 MUD 网址可以分开规则，网址本身却能通过 DHCP 或 LLDP 由设备通告。恶意软件若控制通告，就可能让一台设备指向同一厂商为另一型号签署的文件。签名是真的，权限却属于别的产品。只验“这个厂商签过名”，不够。

草案让控制器先记住该设备已接受的根 MUD 文件，后续迁移由这份文件限定。小幅改动必须保留 URI 的基础部分和既有路径段，只换最后一段；新文件还须维持同一受信任 CA 下等价的终端签名身份和主体名。路径边界按 RFC 3986 的 URI 语法判断。控制器还应记录曾取回的网址；设备重新报出旧地址时，可能是在把已收紧的权限倒回去。这个方案以控制器已经启用签名验证为前提；基础 RFC 8520 并未强制所有部署这样做。

换主机，要让旧文件交出接力棒

真正搬到另一主机，不能只改最后一段路径。草案给出的办法是：先从原有可接受路径取到新文件；该文件经签名验证后，在 MUD-URL 属性中声明另一处规范地址。控制器此后以新地址作为迁移起点。旧文件里的声明是授权链，HTTP 重定向只是一条服务器指路牌。

草案对跨主机名的 301 写了 SHOULD NOT。收购方即使拥有新域名，也得让旧位置继续可访问，直到相关设备和控制器通过签名桥梁。缓存还会拖慢交接。旧文件必须能被重新获取；草案讨论的 HTTP 缓存行为可参见 RFC 9111。若厂商无法控制旧文件的刷新，草案举出先迁到原路径范围内的中转网址、再迁到最终地址的办法，可能需要两次固件更新。这是针对缓存障碍的办法，不是每次并购的固定次数。

签名者也不是随企业名称自动换人。草案允许用证书链完成 CA 更换，但示例保留终端签名者的主体名；它明说这条办法不支持主体名更换。法律上已经归属新老板的品牌，在控制器眼中仍要通过旧信任锚认可的身份。

要决定旧服务器何时下线，缺的不是一份更漂亮的迁移方案，而是一张实际设备表：型号与固件版本、通告的网址、控制器接受的文件和签名、刷新时刻、最后装入的访问规则。草案没有给出实际部署数量。这张表一旦齐全，收购方才能知道还有多少设备依赖旧地址，关闭日期才能有根据。

旧网址不是网站运营遗留的一行文字。它是已售设备进入网络权限系统的第一道门。先拆旧门，再去问设备有没有走完新门，付账的会是接手产品的运营方。

IOTOPS 草案 · RFC 8520 · RFC 3986 · RFC 9111