摘要

  • 大尺寸 LCP Echo 请求没有得到回应，1492 字节的请求却得到回应，触发的是本次会话的发送限制，并不能直接指出哪台中间设备有问题。
  • PPPoE 最初从以太网载荷中扣除六字节封装和两字节 PPP 协议标识，留下 1492 字节。扩展并没有取消这八字节开销。
  • 2006 年的方案将发现阶段的能力声明、LCP 的接收尺寸协商与实际尺寸测试分开。家庭网关成为会话端点以后，维护这些边界的责任也随之移动。

有回应，反而要缩小

设想一条已经打开的 PPPoE 会话。双方已同意使用大于 1492 字节的最大接收单元，发送方发出相应尺寸的 LCP Echo 请求，却没有收到回应。随后，它改用 1492 字节请求，这一次收到回应。

这是一个解释协议规则的情境，不是一宗据称发生过的故障。它的关键不在于“终于通了”，而在于两个尺寸的表现不同。RFC 4638 在 2006 年 9 月规定：如果选择进行这种比较，小尺寸请求得到回应，那么发送方在这次会话中不得再发送超过 1492 字节的报文。

限制落在“这次会话”，不是宣布某一品牌设备永远只能接收小包，也不是要求用户立即重启路由器。小请求成功证明的范围很窄。它给大请求的失败增加了一个尺寸相关的对照，却没有提供每一段以太网的检查报告。

两种尺寸都无回应，不能套用同一个结论；大请求没有回应，也不自动等于中间某台交换机拒绝大帧。丢失、设备状态和观察位置都可能影响记录。这条规则的价值，是在有限证据下限定本次发送行为，而不是把有限证据包装成完整诊断。

八字节从哪里来

1999 年 2 月的 RFC 2516 把 PPP 会话放到以太网上。它先用发现阶段找到对端，再进入 PPP 会话阶段。PADI 广播寻找接入集中器，PADO 提供回应；客户端选择后发送 PADR，服务器以 PADS 确认。相关以太网地址和会话标识让后续交换有了归属。

找到对端不是完成所有工作。PPP 的链路控制、可能的认证以及网络层配置仍各有程序。更重要的是，发现报文能够穿过一条路径，不代表较大的会话报文也能穿过。

原始尺寸计算很直接：以太网最大载荷为 1500 字节，PPPoE 头占六字节，PPP Protocol-ID 占两字节，余下的 PPP 载荷上限是 1492。这里的 1500 指以太网载荷，不是从线上计入以太网头、校验、前导码乃至额外标签后的完整帧长度。

这一区分不只是术语考据。把载荷长度拿去与设备显示的整帧长度比较，会制造一个本来不存在的差额。反过来，看到设备宣称支持某种“大帧”，也不能不问它究竟把哪些字段计入那个数字。

会话搬家，限制换了主人

RFC 4638 描述的变化发生在接入结构中。早期由个人电脑发起 PPPoE，会话端点自己面对 1492 字节限制，通常能够接受。后来，家庭网关在局域网侧接收普通 IPoE 流量，在接入侧发起 PPPoE。局域网一侧可以交给它 1500 字节的 IP 报文，另一侧却只剩 1492 字节。

封装没有突然变厚；变化的是尺寸边界所在的位置。电脑不再直接参加受限链路的 PPP 协商。网关因此接管了两个不同承载约束之间的衔接。

同一文献还讨论从 PPPoA 转向 PPPoE 的环境，以及当时已有部分 PPPoA 用户端设备不能支持 1492 字节设置的情况。这是作者对 2006 年部署背景的描述，不是对今天所有设备的统计，更不能推出每个 1500 字节报文必然被分片。

1998 年的 RFC 2364 已经说明，PPP over AAL5 的 MRU 不能超过相应方向虚连接流量契约允许的最大 CPCS-SDU。换一种承载方式，不意味着 PPP 获得无限容量；每种封装都有自己的下层约束。迁移的难处，恰在于过去成立的尺寸假设不能自动带到新链路。

能力不是命令

RFC 1661 在 1994 年定义的 MRU，是最大接收单元。它计算 Information 和 Padding，不把 PPP 协议字段及外层成帧开销算进去。普通 PPP 的默认值为 1500，但 PPPoE 原有的特定限制不能被这个通用默认值抹掉。

MRU 告诉对方自己愿意接收多大的内容，不是命令对方每次都填满。两端的收发方向、协商结果以及下层接口能力，仍要分别看待。显示一个较大的上限，既不是流量已经达到那个尺寸的证据，也不是性能改善的测量值。

RFC 4638 借助能够承载更大载荷的以太网系统，为 PPPoE 容纳原来的 1500 字节 PPP 载荷创造条件。在六加二的计算范围内，下层以太网载荷至少要容纳 1508 字节。八字节仍在；被改变的是下层容器，而不是开销本身。

1508 也不是一条通用设备配置指令。不同接口对帧长和标签开销的记账方式可能不同，文献中的算术不能代替针对实际链路的核对。

先表态，再协商

扩展在发现阶段加入 PPP-Max-Payload 标签。标签类型是 0x0120，十进制 288；标签值占两字节，表示客户端收发两个方向都支持的最大 PPP 载荷。类型编号 288 不是允许的报文尺寸，那两字节标签值也不是每个会话报文新增的常驻开销。

希望超过 1492 的客户端必须在 PADI 和 PADR 中都带上这个标签。理解并支持扩展的服务器收到后，要在 PADO 和 PADS 中回显客户端标签。双方由此确认存在扩展能力，随后才依照普通 PPP 规则协商实际 MRU。

回显不是服务器把标签改写为自己的最终上限。RFC 的逻辑先以 1492 为默认限制；当标签存在且大于 1492 时，新的协商上限取标签值和本地接口 MTU 减八之间的较小值。服务器的本地条件通过后续 LCP 约束发挥作用。

如果双方没有在发现阶段表示支持，就保留 1492。未知标签可以被旧实现忽略，不能把这种沉默解释成接受大报文。即使标签写了大于 1500 的值，在扩展条件成立但没有进行相应 MRU 协商时，普通 PPP 默认值仍是 1500；一个较高的能力天花板不会自行变成实际选择。

中间设备没有参加签字

发现阶段和 LCP 都发生在端点之间。中间桥接设备可能转发了所有较小的控制报文，却没有因此声明自己能承载更大的会话报文。这是尺寸测试存在的理由，也是端点协商不能独自完成的事情。

RFC 4638 的措辞保留了操作余地：在会话打开并协商了较大 MRU 后，发送方应具备发送一个或多个 MRU 尺寸 LCP Echo 请求的选项；没有回应时，可以再试 1492 字节。这种能力应默认启用并可配置，有充分网络知识时也可以关闭。不能把它改写为每个会话必须执行固定次数、固定间隔的强制探测。

RFC 1661 要求 Echo 交换处于 LCP Opened 状态，并规定相应 Identifier 的关联方式。但不能据此声称回应一定与请求等长。一次成功交换也不是两个方向永远都能通过最大尺寸的证明。记录应保留实际发送与接收尺寸，而不只是一个“测试成功”标签。

这与 RFC 1191 在 1990 年提出的 IPv4 路径 MTU 发现不是同一层问题。后者利用禁止分片标志及路由器返回的“需要分片”ICMP 信息，让源端调整对 Internet 路径的估计。PPPoE 会话内的尺寸比较不能替远端路径签发通行证；设置 DF 的过大报文也不是必然被沿途分片。

编号可以统一，链路仍要承担

2006 年的 RFC 4638 是 Informational 文档，不是 Internet Standard。其 IESG 说明对当时超过 1500 字节的以太网使用提出谨慎要求。这是当年的标准背景，不能当成 2026 年的现状陈述。

2007 年 6 月，RFC 4937 建立了 PPPoE 标签类型的 IANA 注册安排，列入十进制 288 的 PPP-Max-Payload。如今捕获的 IANA PPPoE 参数表 仍记录这一对应关系。注册统一了代码点的含义，不证明某条接入链路已经升级，也不能把标签的登记倒推到 1999 年。

这段历史真正留下的不是一个更大的数字，而是三份不能互相替代的证据：发现阶段表明双方理解扩展，LCP 确定会话可用的接收尺寸，尺寸相关的运行观察约束实际发送。八字节仍由真实链路承担，协议只把谁该说明什么、何时应退回哪里说得更清楚。