摘要

  • RFC 2516 将 PPPoE 的 PPP MTU 限为 1492 字节：1500 字节的以太网负载中，六字节给 PPPoE 头部，两字节给 PPP Protocol ID。
  • RFC 4638 把更大的 MTU/MRU 变成可选协商能力。客户端、接入集中器、本地接口设置和中间以太网链路都必须支持，连接才能真正多传那八个字节。

上限来自一道减法题

1500 字节的以太网负载，听起来正好能装一个 1500 字节的互联网报文。PPPoE 先占走八个字节：六个放自己的头部，两个放 PPP 协议标识符。1999 年 2 月发布的 RFC 2516 因此把标准以太网段上的 PPP MTU 定在 1492 字节。

减法并不复杂。真正的取舍是：当用户侧接入设备已经使用以太网，宽带服务商为什么还要保留 PPP？

宽带要的是以太网，也要每个用户一条会话

RFC 2516 给出的理由很实际。以太网可以低成本连接用户家中的多个主机；PPP 则保留逐用户的访问控制、计费和服务会话。家中共享一段本地网络，服务商仍然能为每位用户维护一条独立的 PPP 会话。

这笔交易在每个报文上都收八个字节。服务商保住了会话边界，用户的 IP 报文在标准 1500 字节以太网负载里少了八个字节。RFC 2516 明确写出这条界线，没有让设备猜测下一段链路是不是还有空余。

当路径一端期待 1500 字节的 PPP 单元，另一端却只协商到 1492 时，这个差额就会出现。RFC 4638 在 2006 年的引言称，这类宽带路径可能产生大量分片。它提出扩展，目标是在新一代宽带网络中减少这类分片。

八个字节变成了能力协商

RFC 4638 并未让每条 PPPoE 会话都超过 1492 字节。对文件描述的下一代宽带网络设计，它要求作为 PPPoE 服务器的 BRAS 必须支持高于该值的协商；可选的 PPP-Max-Payload 标签决定具体客户端和服务器能否使用更大负载。标签中的两字节数值表示客户端在收发两个方向均可支持的最大 PPP 负载。客户端请求超过 1492 字节时，会在 PADI 和 PADR 中带上标签；能够支持该请求的服务器则在 PADO 和 PADS 中回送标签。

服务器仍受自己的设置约束。RFC 4638 允许服务器按本地配置和客户端申报的上限协商更大的 MRU；最终值不得超过标签数值与服务器接口 MTU 减八两者中的较小值。标签能打开协商，不能扩大物理接口，也不能改写中间链路的设置。

于是，一个数字变成一串逐段决定：客户端可以提出请求，集中器只能回应自己支持的范围，本地接口必须留出封装空间，路径上的每段以太网都得传得动最终报文。用户界面上显示 1500 字节，并不代表家中到集中器之间的每台交换设备都认可这个数值。

路径也有机会说不

RFC 4638 还规定了会话建立后的测试。发送端可以发出一个 MRU 大小的 Echo-Request，经过接收端和中间以太网设备。如果较大的探测没有收到 Echo-Reply，而 1492 字节的探测有回复，发送端就不得在该会话中继续发送更大的报文。

这个回退机制很关键。没有交换标签，或者任一端没有更大的设置，RFC 2516 的 1492 字节上限仍然有效。路径上的大包探测失败，连接也可以回到较小上限。旧约定继续充当可用底线，兼容的路径则能向上协商。

写进 RFC，不等于以太网标准变大

RFC 4638 是一份信息类 RFC。它附带的 IESG 说明指出，文件发布时并没有现行 IEEE 标准支持超过 1500 字节 MTU 的巨型帧，并提醒非标准扩展的互操作性和可靠性无法保证。PPPoE 对端可以提出更大数值；每个以太网端口仍必须实际接受它。

所以这不是一条“1492 自动变成 1500”的升级时间线。RFC 4638 保留旧路径需要的上限，命名双方的能力交换，还给实现者一个测试大包的方法。协议可以写出提议，参与设备和实际路径决定提议能否成立。

两份 RFC 记录了设计和减少分片的目标，却没有列出哪些接入网络启用了这个标签；要确认某个网络的部署，需要带日期的集中器配置或一份实际发现阶段报文抓取。

来源