【H3C技术】IPV6 相关概念浅谈

　　IPV6 相关概念浅谈

　　1 开篇

　　随着Internet的日益膨胀，现有的IPv4地址已经十分紧缺，虽然使用分配临时IPv4地址或网络地址翻译(NAT)等地址使用技术，在一定程度上缓解了IPv4地址不足的状况，但同时也增加了地址解析和处理方面的开销，导致某些高层应用失效，而且仍然无法回避IPv4地址即将被分配殆尽这个问题。采用长度为128 b IP地址的IPv6协议，彻底解决了IPv4地址不足的难题，并且在地址容量、安全性、网络管理、移动性以及服务质量等方面有明显的改进，是下一代互联网络协议采用的核心标准之一。IPv6与IPv4不兼容，但他同所有其他的TCP/IP协议族中的协议兼容，即IPv6完全可以取代IPv4.

　　在开始介绍协议之前需要说明两个概念：

　　l 报文(Packet)：指IPV6头加上载荷;

　　l 链路MTU(link MTU)：最大传输单元，也就是能被放在一个链路上一起传送的最大报文尺寸(maximum packet size in octets, that can be conveyed in one piece over a link)，这里是说的报文尺寸，而不是帧尺寸。

　　当IPV6节点有大量数据要送往其它节点的时候，这些数据会被封装为一系列的IPV6报文。为了尽量充分使用带宽，理论上说这些报文被封装在一个报文中是效率最高的，但是受到MTU的限制，我们需要将报文分开封装，报文的长度尽量长，前提是要保证成功到达目的地。这个尽量长的长度就被称之为路径MTU，也就是PMTU。它等于到达目的地过程中所有链路MTU的最小值。

　　如果IPV6节点想使用比最小链路MTU(在RFC1883中定义了最小链路MTU为576 octets)更大一些的PMTU的话，以便充分利用网络带宽，那么就应该应用PMTU发现(Path MTU Discovery)机制。自然，仅仅使用最小链路MTU的系统可以不采用这种机制。

　　不使用Path MTU Discovery的节点使用最小链路MTU作为最大的报文尺寸。大多数情况下会造成使用的实际报文长度比允许的MTU更小，这是因为大多数链路的MTU都比最小链路MTU要大。相应的，节点发送的报文比路径MTU所允许的要小很多的话，就会浪费带宽，进而达不到最理想的吞吐量。

　　Path MTU Discovery机制其基本思想是从源节点假设PMTU为路径上第一跳的MTU，如果沿途有节点认为超过了自己的MTU而不能转发的话，那么该节点就会将报文丢弃，同时向源节点返回Packet Too Big消息(ICMPV6，参考RFC1885)。源节点收到Packet Too Big消息后，会根据消息的内容降低其PMTU假设值。当节点的PMTU估计值小于等于实际的PMTU时，就意味着一轮Path MTU Discovery机制的结束。需要指出的是，在Path MTU Discovery结束之前，可能会有很多轮的packet-sent/Packet-Too-Big-Message-received过程，这是由于沿途总有更小的MTU出现。

　　相应的，节点也可以选择停止发送比最小链路MTU更大的报文来终止Path MTU Discovery过程，这就意味着它采用了最小链路MTU做为PMTU。

　　随着路由拓扑的变化，某条路径的PMTU会发生变化。探测PMTU的减小是很简单的，通过Packet Too Big消息可以做到。而为了探测到PMTU的增大，节点需要周期性地提高它所假设的PMTU，这样的话，总会造成报文的丢弃和Packet Too Big消息的产生。由于大多数情况下PMTU将不会改变，所以不应该频繁地去探测PMTU的增大。

　　Path MTU发现机制也支持组播目的地址，在这种情况下，一个报文的拷贝会穿过许多不同的路径到达不同的节点，每条路径都有不同的PMTU，而且一个组播报文可能会产生大量的Packet Too Big消息，每个消息都会报告一个下一跳MTU。穿过这一系列路径的最小PMTU值决定了接下来发送到组播地址报文的尺寸。

　　需要指出的是，即使节点认为某个目的地址和自己是一个链路上的，它也需要使用Path MTU发现机制，这是由于当邻居路由器充当某个目的地址的代理时，那么目的地址看上去是直接连在节点的链路上，但实际上可能在一跳以外的地方。

　　2 要求

　　像前面所描述的，IPV6节点并没有被强行要求应用Path MTU发现机制(他们可以使用最小链路MTU)。下面描述的协议要求仅仅应用于那些使用Path MTU发现机制的节点。

　　当节点收到Packet Too Big消息时，它必须基于消息中的MTU字段降低相应路径的PMTU估计。之后节点动作的细节行为不会被限定，这是因为不同的应用有不同的需求，不同的应用架构也会选择不同的策略。

　　收到Packet Too Big消息的节点必须试图避免最近一段时间内不产生更多的消息，节点必须降低该路径的报文尺寸。可能会出现一种情况，就是只要使用比IPV6最小链路MTU更大的值时，就一直产生Packet Too Big消息，而这些消息会消耗网络资源(同时也伴随着报文丢弃)，节点必须强制停止Path MTU发现进程(通过停止发送比最小链路MTU要长的报文)。

　　使用Path MTU发现机制的节点必须尽可能快地探测到PMTU的减小。同样，节点也可能发现PMTU的提高，但是由于探测PMTU提高需要发送比目前估计PMTU更大的报文，而且PMTU真正提高的可能性不大，因此这样的过程不应该频繁进行。一个探测PMTU增加的过程(通过发送一个比目前估计值要大的报文)必须在收到相应路径的Packet Too Big消息以后5分钟以上才能启动，一般这个定时器推荐为最小值的两倍，也就是10分钟。

　　节点不允许将PMTU的估计值减小到IPV6最小链路MTU以下。

　　需要注意的是，当节点收到的Packet Too Big消息中带有比IPV6最小链路MTU还要小的MTU时，节点不需要将接下来发送的报文尺寸减小到IPV6最小链路MTU以下，但需要在这些报文里面加入分片头(也就是将报文分片，参考RFC1883)。

　　节点不允许根据Packet Too Big消息中的内容提高它的PMTU估计值。一个宣称PMTU提高的消息可能是漂游于网络上的垃圾报文。这可能是由denial-of-service攻击，或者到同一个目的不同路径而造成的。

　　3 应用中的问题

　　下面主要讨论与应用Path MTU发现机制相关的问题，主要包括：

　　l 由哪个层来应用PMTU发现?

　　l 如何缓存PMTU信息?

　　l 如何删除无用的PMTU信息?

　　l 传输层和更高层必须做什么?

　　3.1 分层

　　在IP架构里面，发送什么样尺寸的报文是由IP层以上的协议决定的，可以称它们为报文化协议(packetization protocol)。报文化协议通常是传输层协议，但也有可能是更高层的协议(比如建立在UDP上的协议)。在报文化层(packetization layer)应用Path MTU发现机制可以简化许多层间的问题，但同时也带来一些弊端：每一个报文化协议不得不重复应用PMTU发现机制，不同的报文化层之间很难共享PMTU信息，由一些报文化层保留的面向对象的状态基不容易扩展以长时间保留PMTU信息。

　　因此建议在IP层保留PMTU信息，ICMP层处理接收到的Packet Too Big消息。报文化层次必须响应PMTU的变化，改变他们发送的尺寸。为了支持这种分层，报文化层需要一种方法来学习到MMS_S(maximum send transport-message size)。MMS_S的值等于Path MTU减去IPV6头部与附加头部分的和。

　　有时候也许报文化层不能改变消息的大小，那么这就可能造成报文大小超过了Path MTU。为了适应这种特殊情况，就需要将报文的载荷payload进行分片(参考RFC1883)。然而，报文化层尽量避免使用分片。

　　3.2 存储PMTU信息

　　理想的情况下，PMTU应该和特定的路径相关的，然而，通常没有足够的信息去完整且精确地区分这些路径。进而，节点就需要使用某个本地特性来区分路径。在组播目的地址的情况下，报文的拷贝会在许多路径上穿越，到达不同的节点。选择组播路径的本地特性需要代表所有一系列组播路径。

　　最简单化的情况下，应用者可能保留一个PMTU的值，用于发送所有的报文。这个PMTU为所有学习的PMTU中最小的一个。使用这样的解决方法可能造成许多路径上的报文大小都比实际可以应用的MTU要小。

　　有些应用者可能会使用目的地址作为本地特性来识别路径(也就是一个目的地址代表一条路径)，由某个目的地址决定的PMTU是到达该目的地址的所有路径集中最小的PMTU。我们希望这个路径集是一个小范围的(路径集太大仍然会造成发送的报文过小，浪费网络带宽)，在大多数情况下最好是由单一的路径组成。这种方法可以在每个目的地址基础上形成优化的报文尺寸，也很好地与邻居发现协议(参考RFC2461)中的主机概念模型相结合：每个PMTU的值对应于目的地缓存中的一个条目。

　　如果使用flows(参考RFC1883)的话，那么应用者可能使用flow id作为路径的本地特性。去往相同的目的地址而带有不同flow id的报文会走不同的路径，相应的有不同的PMTU。这种方法可以在每个flow id基础上形成优化的报文尺寸，可以提供比基于目的地址更加精细的尺寸颗粒。

　　对于源路由报文而言，源路由信息可以进一步限制路径的本地特性。这里有一种比较特殊的情况，当一个报文包含type 0的路由头，其中所有的Strict/Loose Bit Map都是1时，该报文包含了一个完整的路径细节，那么应用者可以使用源路由信息作为本地特性来区分路径。

　　需要指出的是，有些路径可以通过不同的安全级别进一步区分，但是这部分的细节应该在安全级别相关协议中定义。

　　一开始的时候，某路径PMTU值应该假设为第一跳链路的MTU。当收到一个Packet Too Big消息的时候，节点确定该消息应该应用于哪条路径。例如，如果基于目的地址来确定路径的话，那么原始报文中的目的地址将用于确定消息生效的路径。需要注意的是，如果原始报文中包含路由头，那么路由头应该用于确定原始报文的目的地址。如果Segment Left等于0的话，那么目的地址就在IPV6头的目的地址字段内;如果Segment Left大于0，目的地址就是路由头中的最后一个地址。

　　节点使用Packet Too Big消息中的MTU字段作为试探性MTU(tentative MTU)，将它和目前的PMTU做比较，如果试探性MTU比目前的小，就用试探性MTU替代目前的PMTU。

　　当PMTU减小时，必须通知报文化层。如果PMTU减小了，任何报文化层的实例(例如TCP连接)只要它们还使用该路径，就必须被通知到。需要注意的是，即使Packet Too Big消息包含的原始源报文头中指出报文为UDP报文，也应该通知使用该路径的TCP层。

　　引起Packet Too Big消息的报文发送进程也应该被通知到：它的报文被丢弃了。甚至如果PMTU并没有因为Packet Too Big消息而发生变化，也需要通知发报文进程。因此它需要重传丢弃的数据。此处需要注意的是，应用者可以避免使用这样的异步通知方式，它只需要将通知推迟到下一次发送超过PMTU大小的报文的时候。这样的话，当试图发送一个超过PMTU的报文，发送函数就会失败并且返回一个适当的错误指示。这种方法适合于无连接报文化层(例如使用UDP的应用)，在某些应用中它很难从ICMP层得到通知。这种情况下，正常的超时重传机制将被用于恢复被丢弃的报文。

　　3.3 清除无效的PMTU信息

　　Internet的拓扑结构是动态的，路由也是随着时间变化的，然而路径的本地代表特性(例如目的地址)是不会发生变化的，实际使用的路径却发生了变化。因此，节点缓存的PMTU信息也就变得无效了。

　　当网络发生变化时，如果当前旧的PMTU相对于网络变化后的新PMTU太大时，一旦发送一个足够大(介于旧的PMTU和新的PMTU之间)的报文，那么就会立刻发现PMTU的变化(变小了)。然而，并没有一种机制，用于发现旧的PMTU相对于当前网络状态偏小的机制。因此，应用者应该采用老化缓存的PMTU值，来达到定期清除旧PMTU的目的。当某个PMTU值持续了一段时间(10分钟量级)没有被减小过，就将PMTU的估计值设置为第一跳的MTU值，而且这种变化应该通知到报文化层。这样会引起新一轮的Path MTU发现过程。需要注意的是，应用者应该提供更改超时间隔的方式(包括设置为无限大，当节点认为不可能发现比本地MTU更小的PMTU时，超时间隔就可以设置为无限大)。

　　上层不允许因为PMTU增加而重传数据，因为这类增加PMTU并不意味着丢弃了报文。

　　应用PMTU老化机制的一种方法就是联系PMTU值对应的时间戳字段(timestamp field)。这个字段初始化为保留值，表示PMTU等于第一跳链路MTU。无论什么时候由于Packet Too Big报文引起PMTU减少，timestamp都会被设置为当时的时间。

　　应用者给所有的缓存PMTU值启动定时器驱动的过程，一旦某个时间戳不是保留值而且通过时间戳计算出的保留时间比超时时间间隔要大的话，就需要：

　　l 将PMTU的值设置为第一跳链路MTU;

　　l 将时间戳设置为保留值;

　　l 通知那些使用该路径的报文化层。

　　3.4 TCP层

　　TCP层必须跟随其连接所使用的路径的PMTU变化，它不应该发送过大的报文段(segments)，造成报文(packets)超过PMTU。简单的情况下，可以在每次创建报文段的时候向IP层询问PMTU值，但这样的效率很低。对于许多TCP应用者而言，它们采用慢启动拥塞防止算法(slow start congestion-avoidance algorithm，参考Van Jacobson. Congestion Avoidance and Control. Proc SIGCOMM’88 Symposium on Communications Architectures and Protocols, pages 314-329. Stanford, CA, August, 1988)，还需要计算和缓存许多从PMTU而来的值。这样的话，当PMTU改变时，使用异步通知的方式要更简单一些。

　　TCP应用者必须存储MSS值(从对端获得)，无论PMTU是多少，都不准发送任何超过MSS的报文段。

　　在TCP MSS选项中的值是独立于PMTU的，这个MSS选项值被TCP连接的对端使用(参考RFC 1883)。

　　当接收到Packet Too Big消息时，那就暗示着报文被发送ICMP消息的节点丢弃了。此时，只需要像其它丢弃的报文一样处理这个丢弃的报文就已经足够了：等到重传定时器超时后重新发送报文段。如果PMTU发现过程需要许多步骤来完成全路径检测的话，那么就会将连接延迟几个往返的时间段(指接收到Packet Too Big，然后更改PMTU发送，如此反复多次)。

　　另外，当接收到PMTU变化的通知时，也可以立刻进行重传。但是这种机制仅仅允许在Packet Too Big消息指定的连接上使用。用于重传的报文大小不应该超过新的PMTU。值得注意的是，报文化层不允许响应每个Packet Too Big消息而重传报文段，因为许多超大报文段会引起大量的Packet Too Big消息，如果大家都响应的话就需要重传许多相同的数据。如果新的估计PMTU仍然错误的话，那么过程又重复，多余的报文会以指数形式上涨。这就意味着TCP层必须能够识别出Packet Too Big消息所指示的确实降低的某个PMTU，而该PMTU已经用于在特定连接上发送数据，除此之外，TCP层应该忽略任何其它通知。

　　许多TCP应用结合了拥塞避免和慢启动算法来提高性能，由Packet Too Big消息造成的重传不应该改变拥塞窗口，这与TCP重传定时器超时造成的重传不同。而且，它应该触发慢启动机制(也就是说在双方再次达成共识之前，仅仅有一个报文段需要重传)。

　　众所周知，如果发送者的最大窗口尺寸(这里不是拥塞窗口尺寸，拥塞窗口尺寸总是报文段的整数倍)不是报文段尺寸的整数倍，就会降低TCP性能。在许多系统中(例如那些来源于4.2BSD的系统)，报文段尺寸经常设置为1024octets，最大窗口尺寸通常是1024octets的整数倍，这就缺省的保证了整数倍的关系。如果使用PMTU发现机制的话，报文段尺寸可能就不是最大窗口尺寸的因子了(也就是最大窗口尺寸不是报文段尺寸的整数倍)，这就意味着，TCP层需要根据PMTU变化而改变传输窗口尺寸。最大窗口尺寸应该设置为报文段尺寸的最大倍数，前提是小于等于发送者的缓冲空间大小。

　　3.5 管理接口

　　建议应用者提供一些途径，完成下面的功能：

　　l 指定某条路径不执行PMTU发现;

　　l 改变某路径的PMTU值;

　　l 改变PMTU信息超时定时器的值。

　　4 安全考虑

　　PMTU发现机制使得系统会遭受两种denial-of-service攻击，这两种攻击都是基于发送假的Packet Too Big消息给某个节点来完成：

　　l 假的消息显示有一个比实际更小的PMTU：这种攻击不会完全停止数据流的发送，因为节点不会将PMTU降低到IPV6最小链路MTU以下，只是把性能降到了非理想的状态;

　　l 假的消息显示PMTU比实际的更大：如果这种消息被节点相信的话，可能造成临时的数据中断，这是因为大报文被中间路由器丢弃了。但是在一个来回之后，中间的路由器丢弃报文后发送Packet Too Big消息，那么节点会发现自己的错误。如果频繁攻击的话，就会出现大量报文丢弃。不过这种攻击对于严格采用PMTU发现机制的系统来说并不起作用，因为PMTU发现机制要求节点不准根据Packet Too Big消息中的MTU增加PMTU的值。

　　当然，如果能够阻止节点接收合法的Packet Too Big消息的话，也能对接点进行攻击。