【IPV6技术】IPV6 相关概念浅谈-开篇

bjjqsj

开篇　　随着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发现机制，这是由于当邻居路由器充当某个目的地址的代理时，那么目的地址看上去是直接连在节点的链路上，但实际上可能在一跳以外的地方。

luckychao

  好东西啊

luckychao

  支持一下