摘要

  • RFC 5203 分别定义 REG_INFO 通告、REG_REQUEST 请求、REG_RESPONSE 批准、REG_FAILED 失败与零寿命取消；它们不能合并成一个“服务正常”。
  • 注册是一份可刷新、可提前取消的软状态。批准的寿命约束注册本身，不是附属服务的可用性承诺。
  • 可信的运维判断必须连接请求方与注册器状态、服务侧确认、配置纪元、实际调用以及最终结果。

绿色状态究竟来自哪里

设想一个分支节点向 HIP 服务注册，收到寿命为 120 秒的 REG_RESPONSE。控制器验签成功，于是写入“已注册”，并把这条记录显示为绿色，直到本地计算出的到期时间。

三十秒后，注册器所连接的服务组件重载配置，服务侧状态被清空。注册器进程仍然在线，也尝试发送零寿命取消，但更新走上旧路径，没有到达请求方。请求方随后真正调用服务时被拒绝。界面依然绿色，因为它只看原响应的计时器。

这是一个构造场景，不指向任何产品、部署或真实事故。它说明的不是协议造假，而是证据被越权使用：原响应确实批准过注册，本地计时器也确实没有到期；这两件真事都不能证明另一组件仍有状态，更不能证明后续操作成功。

如果系统不能回答“绿色来自哪一层”，它就会把历史准入事实伪装成当前运行事实。

通用注册机制刻意没有包办服务执行

RFC 5203 于 2008 年以 Experimental RFC 发布，给 HIP 主机提供向服务注册的通用方法，服务可以是会合服务器，也可以是支持 HIP 的中间盒。文档明确不规定如何发现服务、如何找到注册器，也不规定注册完成后如何与具体服务交互。

这不是等待实现者随意补齐的空白，而是职责边界。通用层可以描述请求、认证、授权与有限期状态；具体服务怎样建立资源、怎样接受一次操作、怎样报告完成，应由服务类型规范和实现本身负责。

RFC 将注册定义为请求方与注册器保存的共享状态，它使请求方可以从一个或多个服务中受益。这里的“可以”表示条件已经具备一部分，并不表示利益已经发生。

更关键的一句是：成功处理 REG_REQUEST 会在注册器建立状态，并且可能在服务建立状态。“可能”意味着注册器记录与服务记录不能默认视为同一对象。一个 API 返回成功，也可能只覆盖了前者。

通告、请求、批准各有时间边界

注册器用 REG_INFO 表明当前能够并愿意提供哪些注册类型。若暂时无法提供服务，RFC 5203 建议发送空的 REG_INFO；以后恢复时，再通过 UPDATE 告知关联主机当前集合。

因此，通告是一个带时间的声明。它没有预留未来容量，也没有证明服务在下一次使用时仍然存在。请求方只能根据最后收到的相关通告提出 REG_REQUEST，但请求本身仍只是意图。

注册器从 I2 中的 Host Identity 认证请求方，再按本地策略判断它是否有权注册。REG_RESPONSE 列出获批类型和授予寿命，REG_FAILED 列出未获批或因其他原因失败的类型。RFC 5203 中，失败类型 0 表示还需要凭证，类型 1 表示注册类型不可用。

这四个对象分别回答：

  • 注册器当时声称能提供什么；
  • 请求方想要什么；
  • 注册器批准建立什么注册；
  • 哪些类型没有完成，以及可表达的原因。

它们都没有声称某个后续业务请求已经穿过服务并得到结果。把四个时点压成 available=true，只是丢掉了证据的出处。

授予寿命不是不可撤销的运行保证

REG_REQUEST 带有期望寿命，REG_RESPONSE 带有实际授予寿命。请求方不能假定两者相同，即使所请求的值位于通告的最小值和最大值之间。

寿命字段很有价值。它让两端知道注册软状态何时需要刷新或失效。但它不是服务级别承诺。零寿命用于取消；请求方可提前取消；注册器或附属服务在无法继续提供能力时也可提前取消，例如配置改变。安全讨论还指出，注册器可在攻击或资源压力下自行取消。

所以，一条准确记录至少要区分：状态创建时间、上次刷新时间、配置纪元、取消发出时间、取消收到时间与预计过期时间。若服务有独立状态，还要有独立标识、建立结果与删除原因。

“没有看到取消”也不能自动变成“仍然可用”。规范说注册器应发送零寿命响应，不代表消息一定生成、传输、到达并处理。观察不到事件，只能留下未知。

验签增强可信度，却不会扩大语义范围

把 REG_RESPONSE 说成弱证据同样不准确。HIP 保护这些参数，注册器已经认证请求方并执行本地授权策略。对于“该注册器是否批准了这些类型、给了多长寿命”这个问题，响应是强证据。

问题发生在复用阶段。签名保护陈述的来源与完整性，但不会替陈述增加宾语。注册器签署“批准类型 S、寿命 L”，并不会让另一个进程保留内存，也不会让后续分组自动到达。

基础设施常把密码学强度误当成语义广度。越是可靠的签名对象，越容易被拿去关闭告警、跳过探测或证明交付。正确做法是保留原对象及其限定：谁、在什么配置纪元、依据哪版策略、批准了什么、到何时。

服务随后提供服务侧收据，网络提供传输观察，应用提供结果。这样，强签名仍然有用，却不会冒充未观察到的事实。

RFC 8003 增加了失败细节，没有取消这条边界

2016 年发布的 RFC 8003 取代 RFC 5203，并进入 Standards Track。它更清楚地区分注册器针对特定请求方的意愿，扩展证书授权相关失败原因，并增加资源不足类型，要求请求方在这种情况下不要立即重试。

这些改动改善了准入失败的可解释性。运维人员可以更准确地区分缺少凭证、证书问题、类型不可用与资源不足。然而，REG_INFO、REG_REQUEST、REG_RESPONSE、REG_FAILED、有限寿命和取消仍然存在。

更详细的失败码仍然只覆盖注册决策。它没有把通用响应变成服务执行遥测。后者仍需要具体服务的证据。

同时，标准更新不等于部署更新。文档取代关系说明规范史；某个现场是否使用新版本，需要二进制、配置和报文共同证明。

服务类型必须完成自己的证据链

RFC 5203 允许注册类型要求通用请求与响应之外的 HIP 参数，其语义由具体类型规范定义。这体现了最小共同机制：共同层只做共同的事，局部能力由局部规范决定。

对于会合服务，后续证据可以包括 HIT 到 locator 绑定、后来收到 I1、转发动作以及对端独立响应。对于中间盒服务，证据可能是具体规则、匹配条件、策略所有者、寿命以及实际命中的分组。二者不能共用一个虚构的“服务成功”字段。

可以把链条写成：

已通告 → 已请求 → 已批准 → 注册器有状态 → 服务有状态 → 已使用 → 有结果。

任何一条箭头都需要新的观察。若服务没有提供确认接口，就写“服务状态未知”。未知不会破坏系统；把未知填成正常，才会破坏定位能力。

一份可以跨越重启的收据

所需记录并不复杂：

  • HIP 与扩展版本、实现构建和配置修订；
  • 请求方、注册器的 HIT；
  • REG_INFO 指纹、类型、寿命范围、时间与验签结果；
  • REG_REQUEST 指纹、类型和期望寿命；
  • 已认证身份、凭证链、策略版本和决策主体；
  • REG_RESPONSE 或 REG_FAILED 指纹、逐类型结果和授予寿命；
  • 两端状态标识、创建、刷新和过期；
  • 服务侧状态标识与明确确认；
  • 取消、驱逐、重启、配置变化和资源压力事件；
  • 服务专用请求、响应、路径观察与最终结果；
  • 观察盲区明确标为未知。

重启后，控制器不应让旧纪元的绿色状态直接继承。注册器可以重建自己的记录，服务应重新证明其状态，自动化再根据新的证据恢复判断。

RFC 5203 给出的并不是“注册不可信”，而是更严格的答案：注册只对注册负责。把这句话保留下来，准入、可用性和结果才能各自被正确验证。

来源