摘要

  • 十月二十八日的个人互联网草案提出 NEXT_HOP_MTU：一个可选、不可传递的 BGP 路径属性，用四字节记录 IPv4/IPv6 单播路由某个明确网络边界能接受的 IP 包长。它不是目的地全路径的最小 MTU。
  • 附加属性的路由器以本地边界接口 MTU 为基准；若采信邻居的有效数值，只能取两者较小者，本地策略还可以再降。只有通往目的地的每条转发路径都有有效数值，设备才能安装该目的地的承诺转发 MTU。

谁量的门，就让谁签字

一台边界路由器从外部学到一条路由，知道自己的出入口能放过多大的 IP 包。按照草案，它可以把这个数值附在路由上，告诉内部设备这个入口的能力。问题是，目的地前面可能还有别的门。草案明确说，这不是路径 MTU，也不能单独改变 BGP 的选路。把某个边界的量尺当成全程保票，只会等后面的窄口用丢包纠正它。

计算规则只允许向下修正。设本地边界接口的 IP MTU 是 L，邻居送来并被本地策略采信的有效值是 R，新值就是 min(L,R)；不采信 R，便从 L 起算。本地策略还可以降低，不能提高。路由器不得拿无关的内部接口冒充实际跨越的边界。多跳外部会话也不能凭空指定某个无关接口；手工配置的承诺不得大于朝下一跳转发的接口 MTU。数字随路由走，出处却不能被洗掉。

草案同样尊重“没有数据”。每个邻居、每个地址族都必须能分别开关附加与接受属性，两项默认均无须启用。属性缺席就表示没有承诺。下一跳不变时，内部路由反射器应原样转发；到了另一个外部边界，就得与新边界的数值再取最小。聚合路由只有在所有组成路由都有有效值时才能附值。目的地转发 MTU 只有在所有可用转发路径都有有效值时才能写入，且只能取最低值。一条没有证据的路径，就足以否决一个看似漂亮的共同数字。

属性格式出错时，按照 RFC 7606 的处理思路丢弃属性，BGP 会话继续，路由也不因此撤销。边界 MTU 一旦变化，附加属性的路由器必须发替换通告。草案中的路径属性类型码仍是 TBD；实际分配要看 IANA 注册表。数值报大可能造成丢包，报小则浪费容量，是否接受外部邻居的值也是具体的信任决定。

全程最低值仍靠IPv6 路径 MTU 发现等机制处理。IETF 跟踪页所列的是个人草案，没有部署轨迹或已测得的效率增益。若有多边界测试，把每段接口、收到的值、策略减量和最终转发选择串成一条记录，才能检验数字是否守住了自己的权限。

来源：草案原文；IETF 状态；IANA 表；RFC 7606；RFC 8201。