摘要

  • RFC 10030 把 NTP 客户端/服务器和对称模式报文装入单播 PTP 事件报文，使只能识别 PTP 的网卡也能给 NTP 提供硬件时间戳，并利用兼容的透明时钟修正。
  • 规范刻意保留了权力边界：PTP 修正不可认证，负值结果必须拒绝，根延迟不得随修正改变，NTP 的多源选择、NTS 和误差判断继续有效。

网卡只看见它认识的报文

很多网卡并不是不能记录到达时间，而是只能对有限类型的报文做这件事。若给每个高速帧都打硬件时间戳，接收能力很快会被耗尽。因此硬件过滤器常常只识别 PTP 事件报文，普通 UDP 123 端口上的 NTP 报文则在软件路径较后的位置才被记录。

RFC 10030 的做法不是让 PTP 取代 NTP，而是为 NTP 增加一个外层载体。客户端、服务器和对称模式的 NTP 报文放进新的组织专用 TLV，再由单播 PTP 事件报文承载。广播模式不在规范范围内。IANA 的组织标识 00-00-5E 下，子类型 0x1 被登记为 Network Time Protocol Message。

服务器从这条路径收到请求后，必须沿同一种 PTP 载体返回应答。应答不得长于请求，以限制放大；若预计应答更长，请求方可预先填充。用于同步的应答还应尽量与请求等长，避免在并非全程支持 PTP 的网络里由报文长度差引入非对称时延。

这是一组很薄却完整的共同规则。它规定如何借用已有硬件，却没有要求运营者放弃既有 NTP 算法、安全关联或本地时钟纪律。

319 端口不是免费的精度

采用 UDP 时，规范建议源端口和目的端口都使用 PTP 事件端口 319。这样网卡过滤器才能命中并给接收报文加上硬件时间戳。代价同样明确：如果客户端按照 RFC 9109 随机化 NTP 源端口，过滤器可能不再识别报文，硬件时间戳也会失去。

因此这不是“旧路径不安全、新路径更安全”的简单替换。部署方得到更靠近线路的测量，同时放弃一项端口随机化能力。RFC 8915 定义的 Network Time Security 仍可用于内层 NTP 交换，但 NTS 并不会顺带认证外层 PTP 头部。

PTP 2.1 的作用域也必须显式检查。参与者要核对预期的 domainNumber 与 sdoId。推荐默认值是域 123 和 sdoId 0；若与其他 PTP 配置冲突，域号可以调整，但彼此通信的所有参与者必须使用同一组值。

域号回答“这份报文属于哪一场协议对话”，不回答“远端时钟是否正确”。格式、端口和作用域都正确的报文，依然可能来自应该被 NTP 选择算法排除的时间源。

可修正的路径与不可签名的修正

单步端到端 PTP 透明时钟会把转发时延写入事件报文的 correction 字段。NTP 客户端若要修正一次往返测量，需要知道请求和应答两个方向的修正。应答自己的修正在 PTP 头部；请求方向的修正则由服务器通过新定义的 NTP Network Correction 扩展字段返回，其类型为 0x010A。

请求中的修正值不能成为服务器信任的输入。服务器必须忽略它，客户端发出请求时应将其设为零。拿到双向数据后，客户端可以修正对端时延与偏移，还要计入报文接收时长和透明时钟可能存在的频率误差。

真正重要的是拒绝条件。若修正后的时延、请求修正或应答修正中任何一个为负，结果不得用于同步。根延迟不得被修正，以保证根距离这个最大假定误差不依赖路径修正。测量可以更细，最坏情况的诚实表达不能因此被压短。

透明时钟给出的修正无法认证。路径上的攻击者可以改写 correction 字段。客户端只接受小于已测时延的修正，限制其影响；RFC 将剩余影响与延迟一份未被修改的 NTP 报文相比。这个边界是一道上限，不是一份签名。

时间源选择仍在客户端

NTP 的价值不只在四个时间戳，而在于客户端如何长期过滤样本、比较多个服务器、识别失效来源并约束本地振荡器。PTP 载体改变的是部分时间戳在哪里取得、路径时延能否由兼容设备提供证据。它没有把选择逻辑搬进交换机，也没有让某条更短的延迟曲线自动胜出。

主机甚至可以在一个 PTP 域中直接用 PTP 同步，又在另一个域中仅用 PTP 承载 NTP。NTP over PTP 不要求路径上一定存在其他 PTP 时钟；若存在单步端到端透明时钟，客户端可利用修正，若不存在，网卡硬件时间戳本身仍可能有价值。

这正是最小初始规范的意义：先定义可互操作的薄层，让拥有相应硬件和网络条件的运营者自愿采用，把后续选择留在本地。运行中的 NTP 不必为了接入一种更好的测量工具而承认新的制度性权威。

来源