YD/T 2169-2010
基本信息
标准号： YD/T 2169-2010
中文名称：IPv6 技术要求 —— IPv6 路径最大传输单元发现协议
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：511424
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2169-2010.Technique requirement of IPv6: Path MTU discovery for IPv6.
1范围
YD/T 2169规定了用于IPv6的路径最大传输单元(PMTU)发现协议，主要包括协议概述、协议的要求以及协议实现过程等方面的内容。
YD/T 2169适用于支持IPv6协议的网络设备。
2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
YD/T 1341-2005 IPv6基本协议一-IPv6 协议(IETF RFC2460:1998，MOD)
YD/T 1343-2005 IPv6邻居发现协议一基于 IPv6 的邻居发现协议(IETF RFC2461:1998,MOD)
IETF RFC905 (1984) ISO传输协议说明ISODP8073
3术语、 定义和缩略语
3.1术语和定义
下列术语和定义适用于本标准。
3.1.1
链路MTU link MTU
最大的传输单元，也就是，可以在链路上传递的无需分片的最大包字节尺寸。
3.1.2
路径Path
在一个源节点以及一个目的节点之间，- -个包穿越的链路组。
3.1.3
路径MTU PMTU
在一个源节点和-一个目的节点之间，一条路径中所有链路的最小链路MTU.
3.1.4
路径MTU 发现Path MTU Discovery
一个节点用来学习一条路径PMTU的过程。
1范围
YD/T 2169规定了用于IPv6的路径最大传输单元(PMTU)发现协议，主要包括协议概述、协议的要求以及协议实现过程等方面的内容。
YD/T 2169适用于支持IPv6协议的网络设备。
2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
YD/T 1341-2005 IPv6基本协议一-IPv6 协议(IETF RFC2460:1998，MOD)
YD/T 1343-2005 IPv6邻居发现协议一基于 IPv6 的邻居发现协议(IETF RFC2461:1998,MOD)
IETF RFC905 (1984) ISO传输协议说明ISODP8073
3术语、 定义和缩略语
3.1术语和定义
下列术语和定义适用于本标准。
3.1.1
链路MTU link MTU
最大的传输单元，也就是，可以在链路上传递的无需分片的最大包字节尺寸。
3.1.2
路径Path
在一个源节点以及一个目的节点之间，- -个包穿越的链路组。
3.1.3
路径MTU PMTU
在一个源节点和-一个目的节点之间，一条路径中所有链路的最小链路MTU.
3.1.4
路径MTU 发现Path MTU Discovery
一个节点用来学习一条路径PMTU的过程。
标准图片预览
标准内容
ICS 33.04D.40
中华人民共和国通信行业标准
YD/T 2169-2010
IPV6技术要求
-IPV6路径最大传输单元发现协议Technique requirement of IPv6: Path MTU discovery for IPv6(IETF RFC 1981: 1996, Path MTU Discovery for IPv6, NEQ)2010-12-29 发布
2011-01-01实施
中华人民共和国工业和信息化部发布前
范围·
规范性引用文件
术语、定义和缩略语
3.1术语和定义
3.2缩略语
概述·
协议的要求
协议实现·
分层-
存储PMTU信息··
清除过期的PMTU信息-
TCP层的行为
其他传输协议的问题
管理接口
安全问题
附录A（资料性附录）IETFRFC1981与IETFRFC1191的对比-TYKNIKACa
YD/T2169-2010
本标准是“Pv6协议”系列标准之一。该系列标准预计的结构及名称如下：1.YD/T1341-2005
2. YD/T 1915-2009
3.YD/T 2168-2010
4.YD/T 2169-2010
5.YD/T 2170-2010
6. IPv6 技术要求
7. IPv6 技术要求
8.YD/T 1442-2006
9.YD/T 1343-2005
YD/T 2169-2010
IPv6基本协议——IPv6协议（IETFRFC2460:1998，MOD）IPv6 技术要求-—移动Pv6 快速切换IPv6技术要求一—IPv6反向邻居发现协议（IETFRFC3122:2001，NEQ）Pv6技术要求——LPv6路径最大传输单元发现协议(ETFRFC1981:1996.NEQ）IPv6技术要求-—IPv6路由器重编号协议（IETFRFC2984:2000，NEQ）-IPv6动态主机配置协议
支持计算机移动部分
IPv6网络技术要求———地址、过渡及服务质量IPv6 邻居发现协议—基于IPv6的邻居发现协议(正TF RFC2461:1998.M0D)10.IPv6邻居发现安全性技术要求11. YD/T 1344-2005
12. YD/T 1612-2007
13.YD/T 2029-2009
14. YD/T 1635-2007
15. YD/T 1656-2007
互联（4over6）技术要求
IPv6地址结构协议-—LPv6无状态地址自动配置IPv4网络问Pv6网络过渡中的互联互通技术要求基于软线技术的互联网Pv6过渡技术框架IPv6网络技术要求一一面向网络地址翻译（NAT）用户的IPv6隧道技术采用边界网关协议多协议扩展（BGP-MP）的基于IPv6骨干网的IPv4网络本标准对应于IETFRFC1981（1996年英文版）Pv6路径MTU发现协议》。本标准与IETFRFC1981（1996年英文版）的一致性程度为非等效。主要差异如下：——一根据GB/T1系列要求和汉语习惯进行了结构和格式的修改；一一本标准的第4章、第5章、第 6章、第 7章、附录A分别与 IETF RFC1981（1996）的第3章、第4章、第5章、第6章、附录A保持致。本标准的附录 A 为资料性附录。本标准由中国通信标准化协会提出并归口。本标准起草单位：工业和信息化部电信研究院、华为技术有限公司、杭州华三通信技术有限公司。本标主要起草人：毕立波、卜哲、陈国义、万晓兰。Ⅱ
1范围
YD/T 2169-2010免费标准bzxz.net
IPV6技术要求一一IPv6路径最大传输单元发现协议本标准规定了用于IPY6的路径最大传输单元（PMTU）发现协议，上要包括协议概述、协议的要求以及协议实现过程等方面的内容。本标准适用于支持IPv6协议的网络设备。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘识的内穿）或修订版均不适用于本标推。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。YD/T 1341-2005
YD/T1343-2005
IPv6 基本协议——IPv6 协议 (IETF RFC2460:1998，MOD)IPv6邻居发现协议一一基于IPv6的邻居发现协议（IETFRFC2461:19，MOD)
IETFRFC905（1984）ISO传输协议说明ISODP80733术语，定义和缩略语
3.1术语和定义
下列术语和1定义适用于本标。
链路MTU link MTU
最大的传输单元，也就是，可以在链路上传递的无需分片的最大包字节尺寸。3.1.2
路径Path
在一个源节点以及一个目的节点之间，一个包穿越的链路组。3.1.3
路径MTUPMTU
在一个源节点和一个目的节点之间，一条路径中所有链路的最小链路MTU。3.1.4
路径MTU发现PathMTUDiscovery
个节点用来学习一条路径PMTU 的过程。3.1.5
流 ld Flow Id
源地址和一个非零流标签的组合。3.2缩略语
TYKANIKAca-
YD/T2169-2010
下列缩略语适用于本标准。
4．概述
Don't Fragment
Denial of Service
Fiber Distributed Data InterfaceIntermet Cantrol Messagc ProtocolIntermet Protocol Version 6
Maximum Send Transport-Message SizeMaximum Transmission Unit
Sun Network File System
Path Maximum Transmission UnitRead-Only Memory
Remote Procedure Call
Transmission Control FrotocolUser Datagram Protocol
不分片
拒绝服务
光纤分布式数据接口
Internet控制消息协议
互联网协议第6版本
最大能发送的传送消息大小
最大传输单元
Sun 网络文件系统
路径最大传输单元
只读内存
远程过程调用
传输控制协议
用户数据报协议
本标推规定了一个动态发现PMTU的协议，具体方法是：一个源节点最初假定一条路径的 PMTU是这条路径上已知的第一跳的MTU，如果在这条路径上传递的一个分组的长度大于其中某条链路的MTU,那么与这条链路有关的节点就无法转发这个分组，同时这个节点会丢弃这些分组并且返回PacketTooBig类型的ICMPv6消息，接收到这个PacketTooBig消息后，源节点会根据消息通告的瓶颈链路的MTU，降低事先假定的整条路轻PTMU数值。当源节点估计PMTU小于或者等于实际PMTU的时候，结束PMTU发现过程。注意在结束路径MTU发现程序之前，会反复出现调整发送分组PMTU、接收到PacketTooBig消息类型情况，因为整条路径中有可能存在离源节点距离更远并且具有更小MTU值的瓶颈链路。节点能够可选通过终止发送大于IPv6最小链路MTU 的分组方式来结束发现过程。若路由拓扑发生变化，一条路径的PMTU可能会发生变化。PacketTooBig消息会检测到PMTU的减小。为了检测到一条路径 PMTU 的增如，一个源节点会周期性地增大目前的 PMTU数值。通常这样会导致分组被丢弃并且产生PacketTooBig消息报文，因为在大部分情况下，路径的PMTU都不会变化。因此，不能频繁检测一条路径PMTU的增加。PMTU发现同样可应用在组播环境中：在组播地址情况下，一个分组的副本可能会通过不同的路径到达不同的节点。每条路径都可能具有一个不同的PMTU，而且一个组播分组可能会导致接收到网络中不同路径的多个节点产生的PacketTooBig消息类型报文，而且每个PacketTooBig消息都可能会报告不同大小的MTU 值，其中最小的MTU 值就是组播PMTU值。需要注意的是动态发现路径PMTUI的使用要求目的节点与中间节点必须具有相同方式的连接。在某些情况下，如一个邻居节点为多个目的节点代理时，表面上目的节点是以直连的方式出现，但实际上并不是这样，到目的节点的距离可能会大于一跳。IPv6 节点应执行PMTU 发现，从而发现并且利用具有高下IPv6最小链路 MTU 的PMTU 的路径，但一个最简单功能的IPv6实现（例如在启动ROM中）可以不执行PMTU发现。不执行PMTU发现的IPv62
YD/T2169-2010
节点可以利用在YD/T1341-2005中定义的IPv6最小链路MTU作为IPv6报文的最大长度。在大多数情况下，没有必要采用这种方式，因为大部分路径都具有一个大于IPv6最小链路MTU的PMTU。如果不支持 PMTU 发现而来用将 IPv6 最小链路 MTU 作为 IPv6 报文的最大长度的方法，不仅浪费网络资源而且可能无法达到最优的吞吐量。
5协设的要求
本标准不要求IPv6节点必须支持PMTU发现协议，本章所规定的协议只适用那些支持本协议的TPv6节点。
当一个节点接收到一个PacketTooBig消息报文时，它必须根据该消息通告的瓶颈链路MTU值来降低相关路径PMTU值。本标准不规定在这种情况下节点的详细行为，因为不同的应用可能有不同的需求而且不同的实现结构的侧重点不同。在接收到PacketTaoBiICMPv6消息后，一个节点必须试图避免在近一段时间内引发更多的这个消息。节点必须降低它在路径上发送的分组的长度。采用一个可能大于IPv6最小链路MTU的PMTU也可能会持续引发PacketTooBig消息。由于被丢弃的超出瓶颈链路MTU的报文以及由此产生的ICMPv6消息报文会消耗网络的资源，因此节点必须强制结束PMTU发现程序。采用PMTU发现的节点必须尽可能快地检测到PMTU的减少。节点可以检测到PMTU的增加，但是会要求节点发送大于当前估值的PMTU，同时PMTU可能没有增加，因此，不能在较短的间隔内颊袭地检测路径PMTU的增加。在已经接收到某条路径上的PacketTooBg消息情况下，至少5min后，节点才能去检测-个可能增加的PMTU值，该计时器的建议设置为10min，即是最小间隔5min的两倍。一个节点不能把相关PMTU 估值降低到IPv6 最低链路 MTU 以下。诺要注意的是：一个节点可能会接收到一个PacketTooBig消息，通告一个低于IPv6最小链路MTU的下一跳MTU。在这种情况下，不要求这个节点把发送到该路径上的后续分组长度降低到所通告的MTU上，但是必须在这些分组中包括一个Fragmentheader字段，该字段在YD/T1341-2005中规定。一个节点一定不能根据接收到的PacketTooBig消息而去加大PMTU的数值。通告瓶颈链路MTU数值大于目前路径 PMTU值的 PacketTaoBig 消息，可能是网络中无序传输的的失效报文，也可能是 DOs攻击的伪造报文，还可能是到目的节点存在多条路径，每条路径的PMTU不同造成的。注：本标准与 IETF RFC19B1 的一致性程度为非等效，而 正TF RFCI981 王要来白于 正TF RFC1I91，两者之间的区别参见附录A。
6协议实现
本章规定的是PMTU发现协设实现时所涉及到的一些细节，内容包活：a）涉及到执行PMTU发现的协议层：b）存储PMTU信息的方法：
c）删除失效的 PMTU信息的方法d）传输或面向应用的协议层（在TCP/IP分层模型中传输层以的协议层即应用层，在OSI/RM模型中传输层以上的协议层，包括会话层、表示层、应用层）的行为。6.1分层
在P结构中，选择发送什么长度的分组由IP协议层之上的协议来完成。本标准把这样的一个协议称作是“分组协议\。分组协议通带是传输协议（例如，TCP），也可以是面向应用的协议层协议。3
TTYKAONIKAca
YD/T 2169-2010
在分组协议上执行PMTU发现简化了一些涉及到跨层的问题，但是有几个缺陷：需要在不同的每个分组协议上重复实现：不同的分组协议之间共享PMTU信息较为困难：一些分组协议维护的面问连接的状态可能不易扩展从而来较长时问保存PMTU信息。因此要求IP层存储PMTU信息，ICMP层处理接收到的PacketTooBig通告消息。基丁分组的协议层可以根据变化后的PMTU值来改变该层协议报文的长度。为了支持这种功能，基于分组的协议层需要通过一种方式来学习可能变化的MMSS数值。MMS_S值可以是PMTU值减去IPv6协议报文长度以及可能存在的P层预留字段的长度。
一个分组协议如内核外UDP应用，可能无法改变它发送消息的长度，这可能导致分组长度大于PMTU为了解决这个问题，IPv6规定了一个机制，该机制允许把较大的净荷进行分片，每个分片都通过一个分组来发送。YD/T1341-2005中对此机制进行了规定。尽管如此，在实现中应该尽可能避免分组协议发送需要分片的消息。
6.2存储PMTU信息
理想情况下，一个PMTU值应该和一条特定的、在源和目的节点之间进行分组交换的路径相关联。但是，在大部分情况下，一个节点可能不具务足够的信息来完全准确地标识路径。因此，一个节点必须把一个PMTU值和一条路径的某些本地标识特征相关联。在节点实现时就需要根据情况确定一种基于本地特征的路径标识方法。
在组播目的地址的环境下，一个分组的副本可能会穿越不同的路径到达多个不同的节点。因此要求需要确定的基于本地特征的路径标识方法应该能够表示一个元素数量巨大的路径集合。最低限度：一个实现本协议的节点能够为与该节点相关的所有路径仅仅维护一个PMTU。这个PMTU就是PMTU集合中最小的PMTU。这种方式可能导致所采用的PMTU值小于多数路径的PMTU值。一种实现方式是把日的地址作为一条路径的本地表示法。一个日的节点相关的PMTU值可能是在到达那个目的节点所有可能路径上的最小PMTU值。可能的路径数量一般较少，大部分情况下只有一条。这中基于目的节点的方法可以针对每个目的节点采用最优长度的分组。这种方式和在YD/T1343-2005 中定义的一个主机的概念模型可以很好地结合：--个PMTU值与对应的出口存储在目的缓存中。如果采用YD/T1341-2005中规定的流的概态，一种实现方法是来用流ID作为一条路径的本地表示法。发送到特定目的地但是属于不同流的分组可以采用不同的蹄径，根据流ID来选择路径。用流来标识路径比用目的地址来标识路径更为精确。对于源路由的分组（包括一个YD/T1341-2005定义的IPv6路出头的分组），源路由信息可以被用来进一步标识一条路径，因此一种实现方法就是利用源路由信息作为本地表示法。需要注意的是，有些路径可能通过不同的安全类别来进行进一步的区分。这些类别的详细情况不在本标准的规定范围内。
最初，假定一条路径的 PMIU值是第一跳链路的 MTU（已知）。在接收到一个PacketTooBig消息的时候，节点根据消息的内容来决定把消息应用到哪条路径。例如！如果把日的地址用作一条路径的本地表示法，那么利用米自最初分组的目的地址来决定把消息应用到哪条路径上。
注：如果原始的分组包含一个RoutingHeader路由头字段，应该利用路由头来决定这个分组内的目的地址位置。如果Segments Lcft字段为 O，那么目的地址是 IPv6 头中包含的 Destination Address 字段地址：如采剩余分段 Segments Left字段大于0，那么日的地址是路由义中最后的地址：YD/T 2169-2010
于是，节点把PackctTooBig消息的MTU字段1的值作为临时PMTU值，并且把临时PMTU值和现使用的PMTU 值进行比较，若前者小于后者，则覆盖后者。节点必须把修改后减少的PMTU情况通告给分组层。如果PMTU值降低了，那么任何正在利用该条路径的分组层协议（例如，一个TCP连接）都必须得到通知。即使PacketTooBig消息中包含的原始报文是UDP的，使用该路径的TCP也应该收到这个消息。节点还应该通知触发PacketTooBig消息的消息发送实例，它的分组已经被丢弃，以便于它可以重新传输已丢弃的数据
一个执行可以通过推迟通知直到下一次试图发送一个大于PMTU估值的分组的方式来避免使用通告降低PMTU的异步机制。在这种方式下，当试图发送一个大于PMTU估值的分组时，发送功能应该失效而且返回一个适当的差错指示。这个方式更适合于一个无连接的分组层协议（例如使用UDP的分组层协议），因为这时很难从ICMP层（在某些执行情况下）得到通告。在这种情况下，可以利用常用的超时重传机制来重传被丢弃的分组。
应该注意区分通过感知PMTU改变而在分组层协议上产生的通告和报文丢弃而产生的通告。前者可以推迟到分组层协议发送者要构造一个新报文的时候再通告，而后者必须立即通告给发送者，便于发送者立即重传被丢弃的报文。前者重新传送的报文则是通过处理接收PacketTooBig消息的方式，来确认已被丢弃需要重新发送的分组。
6.3清除过期的PMTU信息
网络的拓扑是动态的，路由随时会发生变化。因此可能出现一条路径的本地表示法保持不变，而实际使用的路径已经发生变化的情况。因此，由一个节点存储的PMTU信息就会过期。如果已过期的PMTU值过大，一旦在路径上发送一个分组，那么它立刻就可以被发现。日前还没有检测PMTU足够小的机制，因此实现时应该“老化”存储的PMTU值。当一个PMTU值在给定的时间内稳定（给定时间可以是1Omin的整数倍），应将PMTU估值重新设置为第一跳链路的MTU，并通知分组层相关协议这个变化。这会导致再饮运行完整的PMTU发现程序。当提供这种更新机制的同时，应该提供给用户配置这个有效期时间的方法，并且用户也可以将这个有效期设置为无限长。
上层分组层协议一定不能根据PMTU的增加而重新发送数据，因为这个增加永远不会是对分组丢弃事件的响应。
实现这个超时机制的一种方法就是将PMTU值附带一个时问戳。最初的PMTU（即下一跳链路的MTU）对应的时间戳是一个特殊的保留值。之后如果出于PacketTooBig消息导致该PMTU被更新，那么就将其对应的时间戳置为当前的实际时间。每隔1min检查一次所有缓存的PMTU信息，对于那些时问戳不是保留值的PMTU，判断其时间是否己经超过设置的时问。如果超时，则执行下列操作：a）将该PMTU设为初始的下一跳链路MTU6）将其对应的时问戳设为保留值：c）通告上层PMTU已经发生了变化。6.4TCP 层的行为
TCP层必须跟踪一个TCP连接所使用的路径的PMTU：它不应该发送可能会导致分组大于PMTU的数据段。一个实现方法就是在TCP层每次生成数据段时向IP层询问PMTU，但这样做的效率比较低。而YKAONIKAca
YD/T2169-2010
且，TCP使用了慢启动”（Slow-start）的拥塞避免算法特别计算、绥存有关PMTU的数值。当PMTU改变时，根据接收到的异步通知，也能够更新PMTU一个TCP实现也必须保存来自邻居的MSS值.两端发送的数据段长度不能超过MSS值。基于4.xBSD的实现中，种方式可能需要为TCP状态记录增加一个附加的字段。TCPMSS值与PMTU无关。这个MSS值被TCP连接的对端使用，它可以是与PMTU没有关系的一个数值。关于确定TCPMSS选项数值在YD/T1341-2005的分组尺寸（PacketSizessues）以及最大上层净荷长度（Maximum Upper-Layer Payload Size）部分中有规定。接收到一个PacketTooBg消息表明发送该消息的节点丢弃了一个报文。发送者也应按照其他丢弃数据段的情况来处理，即直到超时后重新发送该数据段。如果PMTU发现过程需要几饮才能发现整个路径的PMTU，这时可能会造成TCP连接的建立延迟数个TCP往返时间。此外可以立即进行响应PMTU变化，重传丢弃报文，但是这只适用于采用PacketTooBig消息机制的特定连接。在重传中采用的分组尺寸不应该大于更新后的PMTU。分组层协议不能响应每个接收到PacketTooBig消息而重传报文：因为几个超长数据段的突发会引发几个这样的消息，从而会多次重传同样的数据段。如果史新后的PMTU值然不难确，复执行实现会造成重复发送的片段数量呈指数增长。这意味着，TCP层必须要能识别那些能够降低目前有效被使用PMTU值的ICMPv6消息，能够忽略其他消息。
许多 TCP 使用\拥塞避免”和“慢启动（slow-start)”算法以此提高性能。与 TCP 重传超时引起的重传机制不同，巾PacketTooBig通告消息引起的重传不应改变拥塞窗口，同时应触发慢启动（slow-start）机制，即只重传一个报文，直到收到了相应的确认消息为止。当TCP发送方的最大窗口大小不是数据段长度的整倍数时，将会引起TCP性能的下降。因此一般的实现都是使用了数据段长度的倍数值作为最大窗口大小。这里的最大窗口不是拥塞窗口，拥塞窗口的大小通常是数据段长度的倍数。在很多系统里，通常把片段尺寸设置为1024byte，最大窗口长度（send space）通常是1024byte的倍数，因此缺省的情况下保持者正确的关系。如果采用PMTU发现，数据段长度有可能不是发送空间的因数，同时在连接中数据段长度还可能变化，这就意味TCP需要根据采用路径MTU发现协议而改变的PMTU值，改变发送窗1.1大小。发送窗口长度应该被设置为在保证小于发送方缓存条件下数据段长度的最大整数倍。6.5其他传输协设的问题
有些传输协议（例如IETFRFC905定义的ISOTP4）在进行重传的时候，不允许重新打包。也就是说，一旦确定传输特定尺寸的数据段，不能把数据段内容分成更小的数据段用于重传。在重传的时候，可以通过IP层把最初的数据段逆行分片处理。剩下的数据段在第一次传输的时候就不能超出PMTU。NFS利用一个RPC（远程过程调用，RemoteProcedureCall）协议，当RPC在UDP上使用的时候，多数情况下，它会生成必须进行分片处理的净荷，即使是用丁第一跳链路的净荷。某些情况下这样做会提高性能，但同时会在可靠性和性能方面存在问题，尤其是客广机和服务器之间存在路由器设备时。因此在使用NFS的情况下，当路径必须经过路由器时，应该使用PMTU发现机制。大部分NFS的实现支持在挂载时问（mount-time）时改变RPC数据报文长度（通过改变有效的文件系统块长度来间接实现），但是后期可能需要通过修改来实现。因为单一的NFS操作无法通过几个UDP数据报文分开，特定的操作（士要是文件名和目录的操作）6
YD/T2169-2010
要求最小的净荷长度，这个最小的净荷长度如果由一个单独的报文发送，也会超出PMTU。NFS实现中不能将净荷大小设置为小于这个最小净荷长度。在这种情况下，IP层会对净荷进行分片处理。6.6管理接口
实现时可以通过系统工具提供下列功能a）规定在一个给定的路径上不使能PMTU发现；b）改变某条指定路径的PMTU值。前一条可以通过标识给定路径方法实现。当在这条已标识的路径上发送报文时，IP层不会发送大于IPv6最小链路MTU的分组。
上述功能可以应用到异常的网络环境中，或者被一个能得到PMTU值的路由协议使用。实现还应该能够设置，改变PMTU老化时问。7安全问题
PMTU发现机制将可能导致两种拒绝服务（Denial of Service）攻击。这些攻击都是基于发送虚假的PacketTooBig消息的方法。
第一种情况，就是发送一些PacketTooBig消息，并且通告的瓶颈链路MTU值远小于实际的 PMTU值。这种攻击方式不会终止正常流量，因为IPv6规定不能将MTU设置为小于最小MTU的值，但这样会导致网络性能下降。
第二种情况与第一种相反，即 PacketTooBig消,息通告的瓶颈链路 MTU 值大于实际 PMTU 值。这种攻击方式将导致节点发出的超长报文被路由器丢弃。因此可能会造成暂时的阻塞。在一个往返时问内，节点会发现它的错误（从路由器按收到PacketTooBig消息），但是频繁受到这种类型的攻击会导致大量的分组被丢弃。但是节点不会因为接收ICMPv6 消,息而提高 FMTU 的数值，因此对此类攻击并不敏感。如果恶意攻击者阻止一个正常节点接收到合法的PacketTooBig消息，这样也会导致拒绝服务。但是在过种情况下，可能有更为简单的攻击方式。YKAONIKAca
YD/T 2169-2010
附录A
（资料性附录）
IETFRFC1981 与IETFRFC1191的对比本标准与ETFRFC1981的致性程度为非等效，而IETFRFC1981主要来自丁LETFRFC1191，LETFRFC1191规定了IPv4协议的PMTU发现。IETFRFC1191的如下部分内容在本标准中并不需要路出器行为规范—IETFRFC1885规定了FacketTooBig类型的ICMPv6消息以及相应的路由器行为。
DF 比特-
在IPv6 不存在 DF比特。
TCPMSS讨论——在YD/T1341-2005中规定了如何确定TCPMSS选项的数值。old-style消息—所有的PacketTooBig消息报告瓶颈链路的MTU。·MTU稳定表项一不需要，因为本标准中没有oid-style消息。6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T 2169-2010
IPV6技术要求
-IPV6路径最大传输单元发现协议Technique requirement of IPv6: Path MTU discovery for IPv6(IETF RFC 1981: 1996, Path MTU Discovery for IPv6, NEQ)2010-12-29 发布
2011-01-01实施
中华人民共和国工业和信息化部发布前
范围·
规范性引用文件
术语、定义和缩略语
3.1术语和定义
3.2缩略语
概述·
协议的要求
协议实现·
分层-
存储PMTU信息··
清除过期的PMTU信息-
TCP层的行为
其他传输协议的问题
管理接口
安全问题
附录A（资料性附录）IETFRFC1981与IETFRFC1191的对比-TYKNIKACa
YD/T2169-2010
本标准是“Pv6协议”系列标准之一。该系列标准预计的结构及名称如下：1.YD/T1341-2005
2. YD/T 1915-2009
3.YD/T 2168-2010
4.YD/T 2169-2010
5.YD/T 2170-2010
6. IPv6 技术要求
7. IPv6 技术要求
8.YD/T 1442-2006
9.YD/T 1343-2005
YD/T 2169-2010
IPv6基本协议——IPv6协议（IETFRFC2460:1998，MOD）IPv6 技术要求-—移动Pv6 快速切换IPv6技术要求一—IPv6反向邻居发现协议（IETFRFC3122:2001，NEQ）Pv6技术要求——LPv6路径最大传输单元发现协议(ETFRFC1981:1996.NEQ）IPv6技术要求-—IPv6路由器重编号协议（IETFRFC2984:2000，NEQ）-IPv6动态主机配置协议
支持计算机移动部分
IPv6网络技术要求———地址、过渡及服务质量IPv6 邻居发现协议—基于IPv6的邻居发现协议(正TF RFC2461:1998.M0D)10.IPv6邻居发现安全性技术要求11. YD/T 1344-2005
12. YD/T 1612-2007
13.YD/T 2029-2009
14. YD/T 1635-2007
15. YD/T 1656-2007
互联（4over6）技术要求
IPv6地址结构协议-—LPv6无状态地址自动配置IPv4网络问Pv6网络过渡中的互联互通技术要求基于软线技术的互联网Pv6过渡技术框架IPv6网络技术要求一一面向网络地址翻译（NAT）用户的IPv6隧道技术采用边界网关协议多协议扩展（BGP-MP）的基于IPv6骨干网的IPv4网络本标准对应于IETFRFC1981（1996年英文版）Pv6路径MTU发现协议》。本标准与IETFRFC1981（1996年英文版）的一致性程度为非等效。主要差异如下：——一根据GB/T1系列要求和汉语习惯进行了结构和格式的修改；一一本标准的第4章、第5章、第 6章、第 7章、附录A分别与 IETF RFC1981（1996）的第3章、第4章、第5章、第6章、附录A保持致。本标准的附录 A 为资料性附录。本标准由中国通信标准化协会提出并归口。本标准起草单位：工业和信息化部电信研究院、华为技术有限公司、杭州华三通信技术有限公司。本标主要起草人：毕立波、卜哲、陈国义、万晓兰。Ⅱ
1范围
YD/T 2169-2010免费标准bzxz.net
IPV6技术要求一一IPv6路径最大传输单元发现协议本标准规定了用于IPY6的路径最大传输单元（PMTU）发现协议，上要包括协议概述、协议的要求以及协议实现过程等方面的内容。本标准适用于支持IPv6协议的网络设备。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘识的内穿）或修订版均不适用于本标推。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。YD/T 1341-2005
YD/T1343-2005
IPv6 基本协议——IPv6 协议 (IETF RFC2460:1998，MOD)IPv6邻居发现协议一一基于IPv6的邻居发现协议（IETFRFC2461:19，MOD)
IETFRFC905（1984）ISO传输协议说明ISODP80733术语，定义和缩略语
3.1术语和定义
下列术语和1定义适用于本标。
链路MTU link MTU
最大的传输单元，也就是，可以在链路上传递的无需分片的最大包字节尺寸。3.1.2
路径Path
在一个源节点以及一个目的节点之间，一个包穿越的链路组。3.1.3
路径MTUPMTU
在一个源节点和一个目的节点之间，一条路径中所有链路的最小链路MTU。3.1.4
路径MTU发现PathMTUDiscovery
个节点用来学习一条路径PMTU 的过程。3.1.5
流 ld Flow Id
源地址和一个非零流标签的组合。3.2缩略语
TYKANIKAca-
YD/T2169-2010
下列缩略语适用于本标准。
4．概述
Don't Fragment
Denial of Service
Fiber Distributed Data InterfaceIntermet Cantrol Messagc ProtocolIntermet Protocol Version 6
Maximum Send Transport-Message SizeMaximum Transmission Unit
Sun Network File System
Path Maximum Transmission UnitRead-Only Memory
Remote Procedure Call
Transmission Control FrotocolUser Datagram Protocol
不分片
拒绝服务
光纤分布式数据接口
Internet控制消息协议
互联网协议第6版本
最大能发送的传送消息大小
最大传输单元
Sun 网络文件系统
路径最大传输单元
只读内存
远程过程调用
传输控制协议
用户数据报协议
本标推规定了一个动态发现PMTU的协议，具体方法是：一个源节点最初假定一条路径的 PMTU是这条路径上已知的第一跳的MTU，如果在这条路径上传递的一个分组的长度大于其中某条链路的MTU,那么与这条链路有关的节点就无法转发这个分组，同时这个节点会丢弃这些分组并且返回PacketTooBig类型的ICMPv6消息，接收到这个PacketTooBig消息后，源节点会根据消息通告的瓶颈链路的MTU，降低事先假定的整条路轻PTMU数值。当源节点估计PMTU小于或者等于实际PMTU的时候，结束PMTU发现过程。注意在结束路径MTU发现程序之前，会反复出现调整发送分组PMTU、接收到PacketTooBig消息类型情况，因为整条路径中有可能存在离源节点距离更远并且具有更小MTU值的瓶颈链路。节点能够可选通过终止发送大于IPv6最小链路MTU 的分组方式来结束发现过程。若路由拓扑发生变化，一条路径的PMTU可能会发生变化。PacketTooBig消息会检测到PMTU的减小。为了检测到一条路径 PMTU 的增如，一个源节点会周期性地增大目前的 PMTU数值。通常这样会导致分组被丢弃并且产生PacketTooBig消息报文，因为在大部分情况下，路径的PMTU都不会变化。因此，不能频繁检测一条路径PMTU的增加。PMTU发现同样可应用在组播环境中：在组播地址情况下，一个分组的副本可能会通过不同的路径到达不同的节点。每条路径都可能具有一个不同的PMTU，而且一个组播分组可能会导致接收到网络中不同路径的多个节点产生的PacketTooBig消息类型报文，而且每个PacketTooBig消息都可能会报告不同大小的MTU 值，其中最小的MTU 值就是组播PMTU值。需要注意的是动态发现路径PMTUI的使用要求目的节点与中间节点必须具有相同方式的连接。在某些情况下，如一个邻居节点为多个目的节点代理时，表面上目的节点是以直连的方式出现，但实际上并不是这样，到目的节点的距离可能会大于一跳。IPv6 节点应执行PMTU 发现，从而发现并且利用具有高下IPv6最小链路 MTU 的PMTU 的路径，但一个最简单功能的IPv6实现（例如在启动ROM中）可以不执行PMTU发现。不执行PMTU发现的IPv62
YD/T2169-2010
节点可以利用在YD/T1341-2005中定义的IPv6最小链路MTU作为IPv6报文的最大长度。在大多数情况下，没有必要采用这种方式，因为大部分路径都具有一个大于IPv6最小链路MTU的PMTU。如果不支持 PMTU 发现而来用将 IPv6 最小链路 MTU 作为 IPv6 报文的最大长度的方法，不仅浪费网络资源而且可能无法达到最优的吞吐量。
5协设的要求
本标准不要求IPv6节点必须支持PMTU发现协议，本章所规定的协议只适用那些支持本协议的TPv6节点。
当一个节点接收到一个PacketTooBig消息报文时，它必须根据该消息通告的瓶颈链路MTU值来降低相关路径PMTU值。本标准不规定在这种情况下节点的详细行为，因为不同的应用可能有不同的需求而且不同的实现结构的侧重点不同。在接收到PacketTaoBiICMPv6消息后，一个节点必须试图避免在近一段时间内引发更多的这个消息。节点必须降低它在路径上发送的分组的长度。采用一个可能大于IPv6最小链路MTU的PMTU也可能会持续引发PacketTooBig消息。由于被丢弃的超出瓶颈链路MTU的报文以及由此产生的ICMPv6消息报文会消耗网络的资源，因此节点必须强制结束PMTU发现程序。采用PMTU发现的节点必须尽可能快地检测到PMTU的减少。节点可以检测到PMTU的增加，但是会要求节点发送大于当前估值的PMTU，同时PMTU可能没有增加，因此，不能在较短的间隔内颊袭地检测路径PMTU的增加。在已经接收到某条路径上的PacketTooBg消息情况下，至少5min后，节点才能去检测-个可能增加的PMTU值，该计时器的建议设置为10min，即是最小间隔5min的两倍。一个节点不能把相关PMTU 估值降低到IPv6 最低链路 MTU 以下。诺要注意的是：一个节点可能会接收到一个PacketTooBig消息，通告一个低于IPv6最小链路MTU的下一跳MTU。在这种情况下，不要求这个节点把发送到该路径上的后续分组长度降低到所通告的MTU上，但是必须在这些分组中包括一个Fragmentheader字段，该字段在YD/T1341-2005中规定。一个节点一定不能根据接收到的PacketTooBig消息而去加大PMTU的数值。通告瓶颈链路MTU数值大于目前路径 PMTU值的 PacketTaoBig 消息，可能是网络中无序传输的的失效报文，也可能是 DOs攻击的伪造报文，还可能是到目的节点存在多条路径，每条路径的PMTU不同造成的。注：本标准与 IETF RFC19B1 的一致性程度为非等效，而 正TF RFCI981 王要来白于 正TF RFC1I91，两者之间的区别参见附录A。
6协议实现
本章规定的是PMTU发现协设实现时所涉及到的一些细节，内容包活：a）涉及到执行PMTU发现的协议层：b）存储PMTU信息的方法：
c）删除失效的 PMTU信息的方法d）传输或面向应用的协议层（在TCP/IP分层模型中传输层以的协议层即应用层，在OSI/RM模型中传输层以上的协议层，包括会话层、表示层、应用层）的行为。6.1分层
在P结构中，选择发送什么长度的分组由IP协议层之上的协议来完成。本标准把这样的一个协议称作是“分组协议\。分组协议通带是传输协议（例如，TCP），也可以是面向应用的协议层协议。3
TTYKAONIKAca
YD/T 2169-2010
在分组协议上执行PMTU发现简化了一些涉及到跨层的问题，但是有几个缺陷：需要在不同的每个分组协议上重复实现：不同的分组协议之间共享PMTU信息较为困难：一些分组协议维护的面问连接的状态可能不易扩展从而来较长时问保存PMTU信息。因此要求IP层存储PMTU信息，ICMP层处理接收到的PacketTooBig通告消息。基丁分组的协议层可以根据变化后的PMTU值来改变该层协议报文的长度。为了支持这种功能，基于分组的协议层需要通过一种方式来学习可能变化的MMSS数值。MMS_S值可以是PMTU值减去IPv6协议报文长度以及可能存在的P层预留字段的长度。
一个分组协议如内核外UDP应用，可能无法改变它发送消息的长度，这可能导致分组长度大于PMTU为了解决这个问题，IPv6规定了一个机制，该机制允许把较大的净荷进行分片，每个分片都通过一个分组来发送。YD/T1341-2005中对此机制进行了规定。尽管如此，在实现中应该尽可能避免分组协议发送需要分片的消息。
6.2存储PMTU信息
理想情况下，一个PMTU值应该和一条特定的、在源和目的节点之间进行分组交换的路径相关联。但是，在大部分情况下，一个节点可能不具务足够的信息来完全准确地标识路径。因此，一个节点必须把一个PMTU值和一条路径的某些本地标识特征相关联。在节点实现时就需要根据情况确定一种基于本地特征的路径标识方法。
在组播目的地址的环境下，一个分组的副本可能会穿越不同的路径到达多个不同的节点。因此要求需要确定的基于本地特征的路径标识方法应该能够表示一个元素数量巨大的路径集合。最低限度：一个实现本协议的节点能够为与该节点相关的所有路径仅仅维护一个PMTU。这个PMTU就是PMTU集合中最小的PMTU。这种方式可能导致所采用的PMTU值小于多数路径的PMTU值。一种实现方式是把日的地址作为一条路径的本地表示法。一个日的节点相关的PMTU值可能是在到达那个目的节点所有可能路径上的最小PMTU值。可能的路径数量一般较少，大部分情况下只有一条。这中基于目的节点的方法可以针对每个目的节点采用最优长度的分组。这种方式和在YD/T1343-2005 中定义的一个主机的概念模型可以很好地结合：--个PMTU值与对应的出口存储在目的缓存中。如果采用YD/T1341-2005中规定的流的概态，一种实现方法是来用流ID作为一条路径的本地表示法。发送到特定目的地但是属于不同流的分组可以采用不同的蹄径，根据流ID来选择路径。用流来标识路径比用目的地址来标识路径更为精确。对于源路由的分组（包括一个YD/T1341-2005定义的IPv6路出头的分组），源路由信息可以被用来进一步标识一条路径，因此一种实现方法就是利用源路由信息作为本地表示法。需要注意的是，有些路径可能通过不同的安全类别来进行进一步的区分。这些类别的详细情况不在本标准的规定范围内。
最初，假定一条路径的 PMIU值是第一跳链路的 MTU（已知）。在接收到一个PacketTooBig消息的时候，节点根据消息的内容来决定把消息应用到哪条路径。例如！如果把日的地址用作一条路径的本地表示法，那么利用米自最初分组的目的地址来决定把消息应用到哪条路径上。
注：如果原始的分组包含一个RoutingHeader路由头字段，应该利用路由头来决定这个分组内的目的地址位置。如果Segments Lcft字段为 O，那么目的地址是 IPv6 头中包含的 Destination Address 字段地址：如采剩余分段 Segments Left字段大于0，那么日的地址是路由义中最后的地址：YD/T 2169-2010
于是，节点把PackctTooBig消息的MTU字段1的值作为临时PMTU值，并且把临时PMTU值和现使用的PMTU 值进行比较，若前者小于后者，则覆盖后者。节点必须把修改后减少的PMTU情况通告给分组层。如果PMTU值降低了，那么任何正在利用该条路径的分组层协议（例如，一个TCP连接）都必须得到通知。即使PacketTooBig消息中包含的原始报文是UDP的，使用该路径的TCP也应该收到这个消息。节点还应该通知触发PacketTooBig消息的消息发送实例，它的分组已经被丢弃，以便于它可以重新传输已丢弃的数据
一个执行可以通过推迟通知直到下一次试图发送一个大于PMTU估值的分组的方式来避免使用通告降低PMTU的异步机制。在这种方式下，当试图发送一个大于PMTU估值的分组时，发送功能应该失效而且返回一个适当的差错指示。这个方式更适合于一个无连接的分组层协议（例如使用UDP的分组层协议），因为这时很难从ICMP层（在某些执行情况下）得到通告。在这种情况下，可以利用常用的超时重传机制来重传被丢弃的分组。
应该注意区分通过感知PMTU改变而在分组层协议上产生的通告和报文丢弃而产生的通告。前者可以推迟到分组层协议发送者要构造一个新报文的时候再通告，而后者必须立即通告给发送者，便于发送者立即重传被丢弃的报文。前者重新传送的报文则是通过处理接收PacketTooBig消息的方式，来确认已被丢弃需要重新发送的分组。
6.3清除过期的PMTU信息
网络的拓扑是动态的，路由随时会发生变化。因此可能出现一条路径的本地表示法保持不变，而实际使用的路径已经发生变化的情况。因此，由一个节点存储的PMTU信息就会过期。如果已过期的PMTU值过大，一旦在路径上发送一个分组，那么它立刻就可以被发现。日前还没有检测PMTU足够小的机制，因此实现时应该“老化”存储的PMTU值。当一个PMTU值在给定的时间内稳定（给定时间可以是1Omin的整数倍），应将PMTU估值重新设置为第一跳链路的MTU，并通知分组层相关协议这个变化。这会导致再饮运行完整的PMTU发现程序。当提供这种更新机制的同时，应该提供给用户配置这个有效期时间的方法，并且用户也可以将这个有效期设置为无限长。
上层分组层协议一定不能根据PMTU的增加而重新发送数据，因为这个增加永远不会是对分组丢弃事件的响应。
实现这个超时机制的一种方法就是将PMTU值附带一个时问戳。最初的PMTU（即下一跳链路的MTU）对应的时间戳是一个特殊的保留值。之后如果出于PacketTooBig消息导致该PMTU被更新，那么就将其对应的时间戳置为当前的实际时间。每隔1min检查一次所有缓存的PMTU信息，对于那些时问戳不是保留值的PMTU，判断其时间是否己经超过设置的时问。如果超时，则执行下列操作：a）将该PMTU设为初始的下一跳链路MTU6）将其对应的时问戳设为保留值：c）通告上层PMTU已经发生了变化。6.4TCP 层的行为
TCP层必须跟踪一个TCP连接所使用的路径的PMTU：它不应该发送可能会导致分组大于PMTU的数据段。一个实现方法就是在TCP层每次生成数据段时向IP层询问PMTU，但这样做的效率比较低。而YKAONIKAca
YD/T2169-2010
且，TCP使用了慢启动”（Slow-start）的拥塞避免算法特别计算、绥存有关PMTU的数值。当PMTU改变时，根据接收到的异步通知，也能够更新PMTU一个TCP实现也必须保存来自邻居的MSS值.两端发送的数据段长度不能超过MSS值。基于4.xBSD的实现中，种方式可能需要为TCP状态记录增加一个附加的字段。TCPMSS值与PMTU无关。这个MSS值被TCP连接的对端使用，它可以是与PMTU没有关系的一个数值。关于确定TCPMSS选项数值在YD/T1341-2005的分组尺寸（PacketSizessues）以及最大上层净荷长度（Maximum Upper-Layer Payload Size）部分中有规定。接收到一个PacketTooBg消息表明发送该消息的节点丢弃了一个报文。发送者也应按照其他丢弃数据段的情况来处理，即直到超时后重新发送该数据段。如果PMTU发现过程需要几饮才能发现整个路径的PMTU，这时可能会造成TCP连接的建立延迟数个TCP往返时间。此外可以立即进行响应PMTU变化，重传丢弃报文，但是这只适用于采用PacketTooBig消息机制的特定连接。在重传中采用的分组尺寸不应该大于更新后的PMTU。分组层协议不能响应每个接收到PacketTooBig消息而重传报文：因为几个超长数据段的突发会引发几个这样的消息，从而会多次重传同样的数据段。如果史新后的PMTU值然不难确，复执行实现会造成重复发送的片段数量呈指数增长。这意味着，TCP层必须要能识别那些能够降低目前有效被使用PMTU值的ICMPv6消息，能够忽略其他消息。
许多 TCP 使用\拥塞避免”和“慢启动（slow-start)”算法以此提高性能。与 TCP 重传超时引起的重传机制不同，巾PacketTooBig通告消息引起的重传不应改变拥塞窗口，同时应触发慢启动（slow-start）机制，即只重传一个报文，直到收到了相应的确认消息为止。当TCP发送方的最大窗口大小不是数据段长度的整倍数时，将会引起TCP性能的下降。因此一般的实现都是使用了数据段长度的倍数值作为最大窗口大小。这里的最大窗口不是拥塞窗口，拥塞窗口的大小通常是数据段长度的倍数。在很多系统里，通常把片段尺寸设置为1024byte，最大窗口长度（send space）通常是1024byte的倍数，因此缺省的情况下保持者正确的关系。如果采用PMTU发现，数据段长度有可能不是发送空间的因数，同时在连接中数据段长度还可能变化，这就意味TCP需要根据采用路径MTU发现协议而改变的PMTU值，改变发送窗1.1大小。发送窗口长度应该被设置为在保证小于发送方缓存条件下数据段长度的最大整数倍。6.5其他传输协设的问题
有些传输协议（例如IETFRFC905定义的ISOTP4）在进行重传的时候，不允许重新打包。也就是说，一旦确定传输特定尺寸的数据段，不能把数据段内容分成更小的数据段用于重传。在重传的时候，可以通过IP层把最初的数据段逆行分片处理。剩下的数据段在第一次传输的时候就不能超出PMTU。NFS利用一个RPC（远程过程调用，RemoteProcedureCall）协议，当RPC在UDP上使用的时候，多数情况下，它会生成必须进行分片处理的净荷，即使是用丁第一跳链路的净荷。某些情况下这样做会提高性能，但同时会在可靠性和性能方面存在问题，尤其是客广机和服务器之间存在路由器设备时。因此在使用NFS的情况下，当路径必须经过路由器时，应该使用PMTU发现机制。大部分NFS的实现支持在挂载时问（mount-time）时改变RPC数据报文长度（通过改变有效的文件系统块长度来间接实现），但是后期可能需要通过修改来实现。因为单一的NFS操作无法通过几个UDP数据报文分开，特定的操作（士要是文件名和目录的操作）6
YD/T2169-2010
要求最小的净荷长度，这个最小的净荷长度如果由一个单独的报文发送，也会超出PMTU。NFS实现中不能将净荷大小设置为小于这个最小净荷长度。在这种情况下，IP层会对净荷进行分片处理。6.6管理接口
实现时可以通过系统工具提供下列功能a）规定在一个给定的路径上不使能PMTU发现；b）改变某条指定路径的PMTU值。前一条可以通过标识给定路径方法实现。当在这条已标识的路径上发送报文时，IP层不会发送大于IPv6最小链路MTU的分组。
上述功能可以应用到异常的网络环境中，或者被一个能得到PMTU值的路由协议使用。实现还应该能够设置，改变PMTU老化时问。7安全问题
PMTU发现机制将可能导致两种拒绝服务（Denial of Service）攻击。这些攻击都是基于发送虚假的PacketTooBig消息的方法。
第一种情况，就是发送一些PacketTooBig消息，并且通告的瓶颈链路MTU值远小于实际的 PMTU值。这种攻击方式不会终止正常流量，因为IPv6规定不能将MTU设置为小于最小MTU的值，但这样会导致网络性能下降。
第二种情况与第一种相反，即 PacketTooBig消,息通告的瓶颈链路 MTU 值大于实际 PMTU 值。这种攻击方式将导致节点发出的超长报文被路由器丢弃。因此可能会造成暂时的阻塞。在一个往返时问内，节点会发现它的错误（从路由器按收到PacketTooBig消息），但是频繁受到这种类型的攻击会导致大量的分组被丢弃。但是节点不会因为接收ICMPv6 消,息而提高 FMTU 的数值，因此对此类攻击并不敏感。如果恶意攻击者阻止一个正常节点接收到合法的PacketTooBig消息，这样也会导致拒绝服务。但是在过种情况下，可能有更为简单的攻击方式。YKAONIKAca
YD/T 2169-2010
附录A
（资料性附录）
IETFRFC1981 与IETFRFC1191的对比本标准与ETFRFC1981的致性程度为非等效，而IETFRFC1981主要来自丁LETFRFC1191，LETFRFC1191规定了IPv4协议的PMTU发现。IETFRFC1191的如下部分内容在本标准中并不需要路出器行为规范—IETFRFC1885规定了FacketTooBig类型的ICMPv6消息以及相应的路由器行为。
DF 比特-
在IPv6 不存在 DF比特。
TCPMSS讨论——在YD/T1341-2005中规定了如何确定TCPMSS选项的数值。old-style消息—所有的PacketTooBig消息报告瓶颈链路的MTU。·MTU稳定表项一不需要，因为本标准中没有oid-style消息。6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。