双栈环境下IP城域网MTU研究

颜永明

（中国电信股份有限公司上海分公司 上海200030）

1 引言

中国电信股份有限公司上海分公司（以下简称上海电信）IP城域网在全国同类网络中规模最大，网络结构最为复杂。网络分为A平面“城域网通道”和B平面“城域网优化通道”两大部分。A平面主要承载互联网上网业务，B平面主要承载IPTV、软交换、VPN、IPRAN等业务。上海电信在中国电信集团公司下一代互联网示范商用首批试点项目中，主要采用IPv6/IPv4公网双栈过渡技术，于2013年实施了城域网A平面的IPv6改造，首批实现了数十万IPv6公客PPPoE拨号用户的双栈接入。在实践中发现，因不同网络和设备的MTU（max transfer unit，最大传输单元）配置存在差异，IPv6和IPv4在分段和MTU处理机制上有着各自特点，可能会造成用户在有些情况下上网业务的使用出现问题。本文就双栈环境下分段和MTU技术原理、部署中需注意的问题和解决方案进行讨论。

2 数据分组分段相关技术

2.1 MTU相关定义和解析

MTU指某一通信协议层面上所能通过的最大数据分组字节数大小，在IP城域网环境下通常将IP网络层的MTU简称为MTU。当网络设备转发数据分组时，会检查其数据域大小是否小于等于出接口的MTU设置值。以EthernetⅡ帧为例，如图1所示，数据域的大小=帧长－DMAC（目的MAC）-SMAC（源MAC）-type（类型字段）－CRC（检验字段），计算所得通常称为数据分组大小。

图1 EthernetⅡ帧结构

一个IP数据分组从源主机到达目的主机所经路径上的各段链路MTU值不尽相同，要完成端到端的传送，IP网络层数据分组尺寸必须小于由各段链路构成的整条路径上的最小MTU。路径上每一段链路所能传送的最大IP分组尺寸，称为link MTU（链路MTU），源主机到目的主机整条路径上的最小MTU则称为path MTU（路径MTU），其大小等于数据分组途经所有链路MTU的最小值。MTU值可在网络设备的接口上配置，用来确保从该接口发出的数据分组尺寸小于或等于该值。如果源主机发送的IP网络层数据分组尺寸大于路径MTU，该数据分组会被分段或丢弃。

2.2 MRU定义及解析

PPP（point-to-point protocol，点对点协议）定义了LCP（link control protocol，链路控制协议）配置选项，该选项用于协商修改PPP点对点链路的默认特性，其中包含称为MRU（maximum receive unit,最大接收单元）的字段，发送给PPP对端设备以告知本地设备能接收更大的数据分组，或者通知对端发送更小的数据分组。上海电信公客拨号用户采用PPPoE拨号认证方式，PPPoE基于PPP，同样定义了MRU字段，协商建立PPPoE拨号会话时，拨号客户端设备会将拨号接口所配MTU值作为PPPoE MRU字段发给拨号服务器（城域网中为BRAS），拨号服务器将收到的MRU值与自身接口配置的MTU值相比较，选取两者中的较小值作为其后续发送数据分组的最大尺寸。

2.3 MSS定义及解析

MSS（maximum segment size，最大分段尺寸）用于TCP报文，规定了每个TCP报文中数据域的最大长度。MSS定义的数据域不包含TCP头部。MSS与MTU的关系为：MSS=MTU-IP头部-TCP头部。当建立TCP连接3次握手时，协商的双方会互相通告MSS大小。通过设定合适的MSS值可确保数据域被TCP、IP头部封装后，尺寸小于或等于path MTU，避免TCP报文在传送过程中被分段。MSS只定义于TCP，在UDP及其他传输层协议中无定义。

2.4 数据分组分段原理解析

IPv4数据分组头部包含DF(don’t fragment，不分段)位，路由器据此判断能否对数据分组分段。若IPv4数据分组大小超过出接口MTU且设置了DF位，则被丢弃。若未设置DF位则由路由器分段后转发。

IPv6头部与IPv4协议不同，包含如下基本字段：版本、业务流类别、流标签、净荷长度、下一分组头、跳数限制、源地址、目的地址，共40 byte。除基本分组头外，还定义了多种可选IPv6扩展分组头，fragment（分段）分组头就属于其中的一种，用于源节点对长度超过其和目的节点间路径MTU的分组实施分段。根据RFC规定，除了hop-by-hop（逐跳）扩展分组头外，其他扩展分组头都不会被传送路径上的节点检查或处理，只有当数据分组到达了目的地址标识的节点时这些扩展分组头才被处理，且必须严格按照它们在数据分组内出现的顺序依次进行。因此，对IPv6数据分组而言，分段动作只能在源节点实施，不能被分组转发路径上的路由器执行。当IPv6数据分组大小超过路径MTU时，会出现分组丢失现象。

3 双栈环境下IP城域网MTU研究

上海电信公客拨号用户上网路径可划分为3个段落，如图2所示：第一段落为城域网接入侧，包含用户终端、家庭网关、EPON、汇聚交换机和BRAS下联接口；第二段落为城域网络侧，包含BRAS上联接口和上海电信城域网路由器；第三段落为Internet侧，包括骨干网、异地/异网运营商、ICP内网及应用服务器。公客拨号用户终端通过家庭网关上联EPON，接入IP城域网BRAS、路由器等设备，最终实现Internet访问。

因城域网、互联网、异地/异网运营商、ISP、ICP网络情况纷繁复杂，MTU的配置存在差异，开放的网络环境中数据分组经过的路径又存在不确定性，这些都可能导致数据分组因MTU问题无法顺利到达目的端。尤其对于IPv6数据分组，因其分组头比IPv4长20 byte，若有设备和网络沿用了IPv4的MTU配置参数值，很可能会引发分组丢失和性能下降等问题。如何避免和解决MTU问题，业界提出了很多方案，结合城域网双栈环境，具体分析如下。

Wenjie Guo, PhD, Associate Professor from School of Life Science, Nanjing University.

3.1 中间设备分段方案

以上海电信城域网为例，BRAS负责终结PPPoE拨号请求，家庭网关可配置成桥接模式或路由模式。桥接模式下PPPoE由用户终端发起，路由模式下则由家庭网关发起。考虑到PPPoE封装需额外增加6 byte PPPoE和2 byte PPP头部开销，上海电信BRAS PPPoE拨号接口配置的MTU值为1 492 byte（在标准的1 500 byte基础上减去6 byte PPPoE头部和2 byte PPP头部计算所得），因此BRAS用于PPPoE协商的MRU值也为1 492 byte。而绝大多数用户终端的IPv4和IPv6协议栈MTU值默认设为1 500 byte。若家庭网关采用桥接模式，PPPoE拨号在用户终端和BRAS之间完成，经协商后，用户终端和BRAS均会选用彼此MRU/MTU中较小值1 492 byte来发送数据分组，IPv4和IPv6数据分组都不会引起中间设备对其分段。但如果家庭网关采用路由模式，PPPoE拨号在家庭网关WAN口和BRAS之间完成，经协商后，它们之间也会选用MRU/MTU中较小的值1 492 byte来发送数据分组，而此时的用户终端并不知道PPPoE协议的存在，最大仍会使用1 500 byte发送数据分组，在纯IPv4环境下，这些大于1 492 byte的数据分组从用户终端发送到家庭网关WAN接口时，由于IPv4支持中间设备对分组进行分段，所以没有设置DF位的IPv4数据分组会被家庭网关分段成两个数据分组后发送，数据分组的重组则由目的端负责，这就是中间设备分段方案，最终可实现IPv4分组的成功收发。

图2 上海电信公客拨号用户上网路径示意

然而，此方案存在两点不足。

·家庭网关对大量IPv4数据分组的分段操作会影响性能，而目的端对分组重组同样会消耗自身存储、计算资源，进而可能造成时延和分组丢失等问题。

·从第2.4节分析可知，IPv6并不支持中间设备对分组进行分段操作，因而该方案无法解决IPv6数据分组遇到的MTU问题。由此可知，在城域网环境中并不适合采用本方案。

3.2 path MTU discover（路径MTU发现）方案

path MTU discover是指当数据分组大小超过某中间设备出接口设置的MTU时，该设备将丢弃超长数据分组并发送ICMP packet too big消息给发起此超长分组的主机，ICMP消息中包括了分组丢失设备的MTU值。源主机收到此ICMP消息后，将重发分组的尺寸设为ICMP消息中要求的MTU值，如此反复，直到分组的尺寸不大于端到端路径上所有设备出接口的MTU值，并顺利达到通信对端主机或服务器为止。path MTU由数据分组发送方向上途径的各设备出接口MTU配置决定，所以该机制是单向的，在来去两个方向上的路径MTU发现结果可能会不一致（例如来去方向上途经的路径不对称或者同一设备不同接口上的MTU配置值不同）。IPv4和IPv6都支持此方案，但在具体实现上有差异。对IPv4数据分组而说，该机制只对设置了DF位的数据分组有效。而IPv6协议没有定义DF字段，但天然地支持了path MTU discover机制。

本方案有如下限制和安全问题。

·路径MTU发现机制依赖于ICMP packet too big消息的传递，若有中间设备被禁止产生该消息或传送路径上有中间设备拒绝该ICMP消息通过，会使源主机无法侦测路径上的最小MTU值，最终导致发现机制失效并产生大量分组丢失。一旦出现此问题，因互联网的复杂性，各种因素互相交织，排障将变得非常困难。

·中间设备产生并回复ICMP packet too big消息一般需由其CPU处理，若大量用户触发该类消息或存在恶意攻击行为，设备性能遭受重大影响。

·若有攻击者利用大量“肉鸡”假冒源主机地址发送大分组至网络，将有大量ICMP packet too big数据分组返回攻垮无辜的源主机。虽然很多厂商设备能对ICMP分组的产生进行限速，但不区分对错的限速会影响到正常使用的MTU发现机制，因此多数主流设备厂商并不建议在城域网实际部署中开启该功能。鉴于以上安全问题对于城域网而言可能带来毁灭性的后果，因此本方案在城域网中的可实施性并不强。

3.3 router advertisement messages（路由器通告消息）方案

IPv6在RFC2461中定义了neighbor discovery（邻居发现）协议，该协议包含5种ICMP分组类型，分别是重定向消息、成对使用的路由器请求和路由器通告消息、成对使用的邻居请求和邻居通告消息。其中，路由器通告消息中含有MTU选项，可以实现在同一链路段上的所有节点使用相同的MTU值。基于该协议，通过对家庭网关（受电信管控）进行开发，可实现向连接在家庭网关LAN口上的用户终端通告运营商所希望的MTU值大小，用户终端接受网关通告并修改MTU后，可避免其使用默认却又不合适的MTU配置发出数据分组，进而在城域网和互联网上遭遇path MTU问题。

此方案的限制在于：

·因MTU选项是IPv6 neighbor discover协议中新定义的，IPv4中无此选项，因而该方案只适用于IPv6，无法用于IPv4协议栈；

·因位于Internet上的应用服务器端网关一般由用户自行部署，其MTU设置并不受运营商控制，本方案只能影响公客拨号用户去往服务器数据分组的MTU大小，无法解决返回数据分组的MTU问题。

若采用此方案，并结合用户服务器端发出的MTU大小符合城域网要求，就有可能解决IPv6的MTU问题。因此，建议在有条件的情况下实施该方案。

3.4 TCP MSS调整方案

根据第2.3节描述，若能确保以MSS大小发送的TCP类型数据分组的数据域在封装TCP、IP分组头后的尺寸小于path MTU，则可避免数据分组在传送过程中被分段。MSS大小可由建立TCP连接的两端设备直接进行协商（例如PC和Web服务器直接协商），也可以由中间路由设备参与协商，中间设备参与协商的一个复杂场景流程如图3所示。由图可知中间的路由设备可在两个方向上分别控制MSS的大小。因TCP两端的会话协商过程不受控，很难依靠用户自身协商来确保TCP数据分组的MSS大小符合path MTU的要求，此时配置中间设备参与MSS的协商成为运营商的一种可选方案。

基于以上思路，上海电信在使用路由模式的家庭网关上开启了类似ip tcp adjust-mss、ipv6 tcp adjust-mss的命令，可实现对TCP应用客户端和服务器端的IPv4和IPv6 MSS大小控制。考虑到上海电信城域网上最小MTU为1 492 byte（PPPoE封装段），IPv4MSS=pathMTU（1 492 byte）-TCP报头（20 byte）-IPv4报头（20 byte）=1 452 byte，所以应将IPv4 tcp adjust-mss值设置小于或等于1 452 byte；IPv6 MSS=path MTU（1 492 byte）-TCP报头（20 byte）-IPv6报头（40 byte）=1 432 byte，应当将IPv6的tcp adjust-mss值设置小于或等于1 432 byte。若考虑到用户有自建额外隧道的配置需求，需将adjust-mss值设置得更小，为额外封装分组头保留余量。

虽然此方案的不足之处在于只对IPv4和IPv6的TCP数据分组有效，而对互联网应用广泛使用的UDP等其他传输层协议不起作用，但在实际应用中，设计基于UDP的应用时，编程者通常会有意识地将UDP数据分组的大小设定为较小值，以适应复杂的网络环境，而在真实环境中能否成功调控TCP数据分组大小更具有现实意义，因此，在城域网中应优先应用本方案。

4 结束语

图3 中间路由设备参与MSS协商流程

IPv6技术虽已发展多年，但在大型城域网内规模部署的案例仍然不多。双栈环境下遇到的MTU和分段问题较为复杂，需通盘考虑IPv4和IPv6的协议特点，运营商、互联网内容提供商专业人员若囿于IPv4配置经验，往往会引起IPv6的MTU问题。根据本文分析，因存在一定技术和应用限制，单纯依靠现有的某个方案并不能彻底解决问题。就城域网运营商而言，现阶段可在综合考虑网络设备功能、性能、安全因素的前提下，结合多种方案，多管齐下，尽可能避免因MTU问题导致分组丢失和网络转发性能下降问题。在一个城域网内可考虑适当放大相关设备的MTU设置值，优先确保本地网络不会成为MTU瓶颈。从长远来看，标准化组织、研发机构和相关厂商应考虑对相关MTU处理机制作进一步开发完善，理想中的MTU处理机制应该同时满足以下要求：

·应能同时解决IPv4、IPv6的MTU问题；

·应能同时作用于TCP和UDP等各类协议数据分组；

·不应采用分段方式增加路由器的处理负担；

·解决MTU问题不能引发新的不可控的安全问题。

就第3.2节的方案来看，当特定ICMP数据分组能顺利穿越整个网络的情况下，若能彻底解决引发的各类安全问题，也许改良后的路径MTU发现方案就能成为一种较为理想的方案。另一方面，ICP、操作系统、终端、应用软件厂商应充分考量双栈环境下MTU问题的复杂性，在彼此负责的段落内为IPv4和IPv6设置更为合理的MTU值，既减少问题出现的几率又确保数据分组的转发效率。

1 RFC2460.Internet Protocol,Version 6(IPv6)Specification，19982RFC4459.MTU and Fragmentation Issues with in-the-Network Tunnel，2006

2 RFC4459. MTU and Fragmentation Issues with in-the-NetworkTunnel，2006

3 RFC4638.Accommodating a Maximum Transit Unit/Maximum Receive，2006

4 RFC2461.Neighbor Discovery for IP Version 6(IPv6)，1998