摘要

  • 门户架构允许把同一终端的多个地址分别处理，也允许合并成一个订户视图。“一台终端、一个会话”需要明确的实施选择，不能靠设备外形来保证。
  • 标识只需在特定门户和特定时间范围内唯一。地址或接入对象改变时，旧映射必须被删除、更新或失效处理，而不是随熟悉的号码继续生效。
  • 为保持业务连续而保留的内部稳定映射，可能把不断变化的外部标识重新关联起来。可识别性有运营价值，也有需要单独管理的隐私成本。

采购文件里那句没有展开的话

设想一份访客网络的采购需求，其中写着“一台终端只需办理一次接入，会话状态保持一致”。这句话看似直观：桌上只有一台手机，用户也只打开了一个门户页面。但进入网络之后，手机可能通过 IPv4 和 IPv6 通信，也可能在同一链路上使用多个地址。页面所理解的对象、状态接口查询的对象，以及实际控制数据包通行的对象，未必天然相同。

这是一个假设的采购场景，不是对某家酒店、机场或网络产品的测试结论。它揭示的问题是，设备数量很容易看见，服务对象的边界却要由系统定义。若项目只验收“页面能打开”和“点击后能联网”，这项定义可能始终没有进入共同的验收范围。

RFC 8952 对此保留了实施空间。对于拥有多个 IP 地址的终端，门户系统可以把各地址视为不同的用户设备实例，也可以将它们归入一个订户视图。两种方式都在架构允许的范围内。文件并没有因为硬件只有一台，就要求所有组件自动形成同一种归并关系。

选择不同，服务承诺的含义就可能不同。一个团队若按合并后的对象延长会话，另一个团队却按地址分别维护限制，用户面对的就不是一项统一规则。这是由选择不一致推导出的风险，并不意味着所有双栈门户都会产生错误计量。需要确认的是本系统选择了哪一种处理方式，以及相关组件是否真正执行同一种选择。

身份不是一个字段，而是一组共同维护的关系

RFC 8952 于 2020 年 11 月发布，属于信息性架构文件，并非互联网标准轨规范。它把门户系统拆成几个职责不同的部分：配置服务告诉终端去哪里查询；状态 API 返回当前接入状态；用户门户承接必要交互；执行设备根据条件限制或放行流量。

在这些部分之间，终端是共同的参照对象。接口必须知道请求属于哪个设备实例，执行设备必须把数据包映射到自己的设备概念，各组件彼此交流时还必须能对齐这个对象。给请求增加一个字段，并不能独自完成这件事。字段的来源、可见范围和变化时机，都属于关系本身。

这里的“身份”也不等于自然人的身份。一项映射可能足以让系统回答某个终端是否处于受限状态，却不足以证明某个人使用过它。把服务中的设备归属直接提升为人的责任归属，增加的是一个新的主张，不是对原有字段换一种叫法。

从管理角度看，重要的不是选出一个听起来最可靠的号码，而是说明号码在何处有区分能力，谁能看到它，以及哪些变化会使原来的对应关系失效。没有这些条件，“按终端管理”无法成为可核验的承诺。

唯一，不意味着永远唯一

架构对唯一性的要求有清楚边界：标识必须区分当时与同一门户交互的设备。它允许某个取值在以后被分配给另一台设备，也允许不同门户分别使用相同取值。

这种安排并不是等待修补的缺陷。它让本地网络属性可以承担识别作用，不要求为每个接入对象发放一个永久全球号码。临时服务可以使用临时关系，有限的标识空间也可以循环利用。

但循环利用要求系统处理交接。设想设备离开后，其地址被正常分配给新设备。地址分配本身可以完全正确；如果状态服务仍保存旧设备的会话，而执行设备已经按新设备处理数据包，两边的记录也可能各自没有格式错误。问题出在它们不再谈论同一个对象。

因此，“当前没有两个设备同时使用这个地址”与“所有旧关联都已结束”是两项不同证据。前者不能代替后者。地址重新出现，不意味着原来的服务对象重新出现。

RFC 8952 第 3.4.2 节明确要求：IP 地址到设备的映射发生变化时，相关组件必须删除或更新映射。这不是单纯的存储整理。映射是否及时交接，影响之后的状态答复、通行判断，以及附着在该关系上的其他业务处理。

接口放在哪里，会改变它能认出谁

一种标识能否使用，与组件在网络中的位置有关。靠近接入点的设备，可能直接知道数据包来自哪个物理接口。远端状态服务即使能稳定接收请求，也未必掌握同样的信息。

物理接口就是一个有边界的例子。若该接口只连接一个设备实例，它可以提供明确区分，而且不容易由另一台终端在交互中冒充。但如果多台终端共用同一接入接口，这个属性就不能独自区分它们。执行设备需要直接知道接口，或者通过网络携带的上下文获取它；状态 API 也需要相应的信息渠道。

架构还专门规定，物理接口上的设备改变时，API 和执行设备都必须使相关旧状态失效。一个插口仍然存在，不等于插口后面仍是原来的对象。由谁识别变化、怎样让另一端停止沿用旧状态，是实施方案要交代的事情。

地址转换带来另一种位置差异。经过 NAT 后，某些组件看到的地址可能已经无法单独区分各台终端。RFC 8952 指出，若组件掌握端口映射，在一些情况下仍有可能识别具体设备。这里的条件是“知道映射”，不是“共享公网地址本身就足够”。

RFC 8908 是 2020 年 9 月发布的标准轨门户 API 规范。它明确指出：系统若使用客户端的 IP 地址进行识别，就需要确保状态 API 和执行设备能看到同样的地址。把 API 迁往另一处托管环境，因而可能改变识别条件，即使返回的 JSON 格式和 HTTPS 地址都没有改变。

不能只把这种迁移理解为运维成本调整。需要重新确认的是，原先由接入位置提供的区分信息，是否仍能抵达需要使用它的组件。服务可达、证书有效与设备对应正确，并不是同一个验收项。

多个地址如何归并，需要有人承担决定

回到采购要求。系统可以将多个地址归并为一个服务对象，但归并并不是没有代价的方便选项。它要求各组件维护一致的关联，也要求说明地址变化后哪些关系继续有效，哪些必须解除。

分别处理也不是天然更安全或更简单。如果用户购买或获得的是按终端理解的服务，而系统实际按多个地址分别管理，就需要让业务规则与技术边界相容。否则，支持人员最终可能只能靠临时解释和人工例外，把两种对象拼成一项看似完整的服务。

RFC 8952 提到，在 IPv6 场景中可以考虑依据子网进行识别。不能据此把任意一个 /64 都认定为单一订户的边界。文件说明的是一种可能的识别方式，其是否适合，仍取决于组件能力、接入关系和实际服务范围。

它也列出 MAC 地址作为可能的标识，但没有展开为通用部署方案。本文的结论不要求关闭地址隐私功能，更不主张把永久硬件标识当作解决所有关联问题的捷径。把长期稳定性加到标识上，只改变了问题的一部分，还可能扩大另外一部分成本。

链接还有效，不代表上下文还相同

状态 API 有时从请求上下文识别客户端，并向所有设备提供相同的 URI。这种设计可以在预期路径内工作；当终端改用另一个网络接口，或者分离 DNS 根据查询来源返回不同结果时，原先隐含的识别条件就可能改变。

RFC 8952 区分了两层问题：API 访问可以依赖上下文，而 API 提供给设备的 URI 则应该对设备具有唯一性，不依赖外部上下文才能正确工作。RFC 8908 同样建议，在接口无法从其他信息辨认设备时，通过配置过程提供按客户端区分的 URI。这种 URI 也可能随同一设备的不同会话而变化。

这并不是让运营方把未经认证的设备编号直接塞入所有链接。架构明确提醒，这样的做法可能引入冒充或重放风险。链接能脱离原路径指向正确对象，与调用者是否应当拥有对应操作权限，仍需要分别处理。

即使一个 URI 在别的网络上仍能解析，某些功能也可以受接入路径限制。架构举出支付界面的例子：系统可能需要提醒用户，这笔操作并不是为当前使用的连接购买接入。这里关注的是业务对象是否准确，而不是要求所有门户操作都能跨网络无条件执行。

TLS 也不能替代这些对应关系。RFC 8908 的服务器验证检查的是配置过程给出的主机名，不能据此证明配置机制安全，或证明用户应该信任该网络。它保护交换的一部分，却不会自动修正服务器内部认错设备的记录。

为了连续而留下的关联，也需要期限

外部标识改变后，内部系统仍可能通过稳定映射把多个取值关联起来。这能帮助服务维持连续，也能让排障人员理解同一个会话为什么出现在不同地址下。但它意味着，对外看起来不断变化的标识，在内部仍然可以构成连续记录。

RFC 8952 的隐私部分直接讨论了这种情况。可变、匿名的标识有助于减少长期跟踪；为了处理变化而保留的长期稳定映射，则仍是敏感信息。加密传输保护的是它经过网络时的机密性，不会替系统回答谁能查询历史、为何保留，以及何时终止关联。

于是，运营需求与隐私保护不是“全部删除”或“永久保存”的二选一。一次关联争议可能需要有限的交接记录才能解释；这不意味着所有终端的长期活动都必须被连接起来。需要定义的是能够支撑具体服务目的的最小持续关系，以及访问这层关系所需的权限。

Lu Heng 关于代理问题的讨论 提供了一种提问方式：谁可以改变规则，谁承担规则失配的后果。用于本题时，这意味着追问映射、交接和保留期限的决定权，不能把其针对注册机构的批评直接移植为对门户运营方的指控。

他对 BTW 定位的说明 强调描述现实机制，而非替某个角色宣传。在这里，连续识别确实有用，过度延长识别关系也确实可能增加暴露面。把两者都说清楚，比把稳定标识或匿名标识中的任何一方描绘成万能答案更接近实际决策。

采购文件里的“一台终端”，最终需要变成一组可以回答的问题：哪些地址被归入同一对象，哪些组件知道这项归并，设备或接入点改变后旧关系怎样结束，内部又保留了什么。服务的一致性，不在这句话本身，而在它背后有人维护的生命周期里。

资料来源