ipv6 什么是IPv6结构 IPv6结构介绍【详解】

　　IPv6结构,什么是IPv6结构

　　本文将阐述IPv6 报头的结构并将其与IPv4 报头相比较。此外还将讨论Extension(扩展)报头，这是IPv6 所新加的内容。

　　在RFC 2460 中定义了IPv6 数据包的报头结构。该报头固定为40 字节长。源和目的地址各占16 字节(128 位)，因此，只有8 字节是用于普通报头信息的。

　　普通报头结构

　　在IPv6 中，IPv4 报头中的下面五个字段被去除了：

　　● Header Length(报头长度)

　　● Identification(标识)

　　● Flags(标志)

　　● Fragment Offset(段偏移量)

　　● Header Checksum(报头校验和)

　　除去Header Length(报头长度)字段是因为对于固定长度的报头，它是不起作用的。在IPv4 中，报头最短长度为20 字节，但是如果添加一些选项，则会以4字节长度递增，最长可达60 字节。因此，对于IPv4 来说，报头的总长度信息是很重要的。在IPv6 中，选项由扩展报头定义(将在本章后面部分作介绍)。

　　Identification(标识)字段、Flags(标志)字段和Fragment Offset(段偏移量)字段处理IPv4报头中的数据包分段。如果要在只支持小数据包的网络中发送大数据包，就需要进行分段。在这种情况下，IPv4路由器把数据包分割成更小的片段，并转发多个数据包。目的主机收集数据包并进行重新组合。即便只有一个数据包丢失或出错，都需要重新进行传输，因此效率很低。在IPv6 中，主机通过一个叫做路径MTU 发现(Path MTU Discovery)的过程来了解路径最大传输单元(Maximum Transmission Unit，MTU)的大小。如果IPv6 的发送主机想要对数据包进行分段，就需要使用扩展报头来实现。数据包传输路径上的IPv6路由器不像在IPv4 中那样进行数据分段。因此，在IPv6 中去除了Identification、Flags 和Fragment Offset字段并将会按需插入一个扩展报头。扩展报头将在本章后面进行介绍。

　　去除Header Checksum(报头校验和)字段是为了提高处理速度。如果路由器无需检验并更新校验和，则处理会变得更快。校验和的计算也是在介质访问层完成的，这样未检测到的错误和错误路由的数据包所引起的风险最小。传输层(UDP和TCP)中有一个校验和字段。IP 是一种“尽力而为”的传输协议，保证数据完整性的责任属于其上层协议。

　　Type of Service(服务类型)字段由Traffic Class(流量类别)字段代替。IPv6处理参数的机制与IPv4 不同。请参考第六章来了解更多的信息。Protocol Type(协议类型)和Time-to-Live(TTL，生存期)字段被重新命名，且稍稍做了些修改。IPv6 报头中还添加了一个Flow Label(流标签)字段。

　　IPv6 报头中的字段

　　对IPv6 报头中各个字段越熟悉，你对IPv6 的工作方式越理解。

　　图2-1 是IPv6 报头的概述。将在下面的段落中详细讨论各个字段。

　　图2-1 说明，即使IPv6 报头的总长度是默认的IPv4 报头的两倍长，达到了40 字节，但它实际上是被简化了的，因为报头的绝大部分被两个16 字节的IPv6 地址占据。这样，只剩8 个字节可供其他报头信息使用。

　　Version(版本，4 位)这是一个4 位长的字段，其中包含了协议的版本。在IPv6 中，该数目为6。不能使用版本号5，因为5 早已被分配给一个实验性的流协议(ST2，RFC 1819)。

　　Traffic Class(流量类别，1 字节)该字段代替了IPv4 中的Type of Service 字段，它有助于处理实时数据以及任何需要特别处理的数据。发送节点和转发路由器可以使用该字段来识别和分辨IPv6数据包的类别和优先级。

　　RFC 2474“Definition of the Differentiated Services Field (DS Field) in the IPv4and IPv6 Headers”(IPv4 和IPv6 报头中差分服务(DS)字段的定义)文档中解释了如何使用IPv6 中的Traffic Class 字段。RFC 2474 使用术语DS 来指代IPv4报头的Type of Service 字段和IPv6 报头中的Traffic Class 字段。

　　Flow Label(流标签，20 位)

　　该字段区分需要相同处理的数据包，以此来促进实时性流量的处理。发送主机能够用一组选项标记数据包的顺序。路由器跟踪数据流并更有效地处理属于相同数据流的数据包，因为他们无须重新处理每个数据包的报头。数据流由流标签和源节点的地址惟一标识。不支持Flow Label字段功能的节点需要在转发数据包时不加改变地传递该字段，并在接收数据包时忽略该字段。属于同一数据流的所有数据包必须具有相同的源IP 地址和目的IP 地址。

　　Payload Length(有效载荷长度，2 字节)

　　该字段指定了有效载荷，也就是在IP 报头后携带的数据长度。IPv6 中的计算与IPv4 不同。IPv4 中的Length 字段包括IPv4 报头的长度，而IPv6 中的PayloadLength(有效载荷长度)字段仅包含IPv6 报头后的数据。扩展报头被认为是有效载荷的一部分，因此被包括在计算之内。

　　由于Payload Length(有效载荷长度)字段只有2 个字节，因此数据包的有效载荷最大为64KB。IPv6 有一个Jumbogram Extension 报头，如果有需要，它可以支持更大的数据包。只有当I P v 6 节点连接到MTU 大于6 4 K B 的链路时，Jumbogram 才起作用。RFC 2675 中详细说明了Jumbogram。

　　Next Header(下一报头，1 字节)

　　在IPv4 中，该字段为Protocol Type(协议类型)字段。在IPv6 中则被重新命名，以反映出重新组织的IP数据包。如果下一个报头是UDP或TCP，该字段将和IPv4中包含的协议号相同，例如，TCP 的协议号为6;UDP 为17。但是，如果使用了IPv6 扩展报头，该字段就包含了下一扩展报头的类型，它位于IP 报头和TCP 或UDP 报头之间。表2-1 列举了Next Header 字段中可能的值：

　　注意：报头类型和协议类型数字的范围是相同的，因此不应有冲突。

　　Hop Limit(跳数限制，1 字节)

　　该字段和IPv4 的TTL 字段类似。TTL 字段包含一个秒数，指示数据包在销毁之前在网络中逗留的时间。绝大多数路由器只是简单地在数据包经过每一跳时将该值减1。该字段在IPv6 中被重命名为Hop Limit。现在用字段中的值标识跳数，而不是秒数。每个转发节点对此数目减1。

　　Source Address(源地址，16 字节)

　　该字段包含数据包发送者的IP 地址。

　　Destination Address(目的地址，16 字节)

　　该字段包含数据包目的接收者的IP地址。对于IPv4，该字段总是包含数据包的最终目的地的地址。对于IPv6，如果提供了Routing(路由)报头，则该字段包含的未必是最终地址。

　　图2-2 为跟踪文件中的IPv6 报头。

　　跟踪文件显示了前面讨论过的所有报头字段，及其在跟踪文件中的表示方式。其中，Version 字段值为IPv6 相应地设为6。该数据包没有使用Priority 字段和Flow Label 字段，因此都被设为0。Payload Length 字段设为40，而Next Header 字段的值被设为58，以表示ICMPv6。Hop Limit 设为128，Source address 和Destination address 包含了我的IPv6 节点的链路本地地址。

　　扩展报头

　　IPv4 报头的长度可以从最小的20 字节扩展为60 字节，以便指定选项，如安全选项(Security Option)、源路由(Source Routing)或时间戳(Timestamping)。这项功能很少使用，因为会降低性能。例如，IPv4 硬件转发实现必须把包含选项的数据包传递给主处理程序(软件处理)。

　　数据包的报头越简单，处理过程就越快。IPv6 采用一种新方法来处理选项，显著地改善了处理速度。它在附加的扩展报头中对这些选项进行处理。

　　当前的IPv6 规范(RFC 2460)定义了六个扩展报头：

　　● Hop-by-Hop Options 报头

　　● Routing 报头

　　● Fragment 报头

　　● Destination Options 报头

　　● Authentication 报头

　　● Encrypted Security Payload 报头

　　在IPv6 报头和上层协议报头之间可以有一个或多个扩展报头，也可以没有。每个扩展报头由前面报头的Next Header 字段标识。扩展报头只被IPv6 报头的Destination Address字段所标识的节点进行检查或处理。如果Destination Address字段中的地址是多播地址，则扩展报头可被属于该多播组的所有节点检查或处理。扩展报头必须严格按照在数据包报头中出现的顺序进行处理。

　　上面所述的规则有个例外：只有目的节点才会处理扩展报头。如果扩展报头是Hop-by-Hop Options报头，则其承载的信息必须被数据包经过路径上的每个节点检查和处理。如果有Hop-by-Hop Options 报头，则必须紧接在IPv6 报头之后。IPv6 报头的Next Header 字段中用0 来表示Hop-by-Hop Options 报头(参见本章前面的表2-1)。

　　注意： 前四个扩展报头在RFC 2460 文档中描述。Authentication 报头在RFC 2402 中描述， Encrypted Security Payload 报头在RFC 2406 中描述。

　　图2-3 演示了扩展报头的使用方式。

　　每个扩展报头的字节长为8 的整数倍。因此，后面的报头总是可以对齐。如果节点需要处理Next Header 字段，但不能识别该字段的值，那么就需要丢弃该数据包，并向数据包的发送源返回一条“ICMPv6 Parameter Problem”消息。第四章将详细介绍ICMPv6 消息的有关细节。

　　如果在单个数据包中使用了多个扩展报头，则应该使用如下的报头顺序(RFC 2460)：

　　1. IPv6 报头

　　2. Hop-by-Hop Options 报头

　　3. Destination Options报头(用于由IPv6 目的地址字段中第一个出现的目的地

　　址以及随后在Routing 报头中列举的目的地址进行处理的选项)。

　　4. Routing 报头

　　5. Fragment 报头

　　6. Authentication 报头

　　7. Encapsulating Security Payload 报头

　　8. Destination Options 报头(用于只由数据包最终目的地址进行处理的选项)。

　　9. Upper-Layer 报头

　　若IPv6 被封装在IPv4 中，则Upper-Layer 报头可以是另一个IPv6 报头，并且可以包含符合相同规则的扩展报头。

　　Hop-by-Hop Options 报头

　　Hop-by-Hop Options扩展报头携带着必须由数据包经过路径上的每个节点进行检查的可选信息。它必须紧跟在IPv6 报头后，并由Next Header 值0 表示。例如，Router Alert(RFC 2711)把Hop-by-Hop Options 报头应用于资源预留协议(Resource Reservation Protocol，RSVP)或多播侦听者发现(Multicast ListenerDiscovery，MLD)消息。在IPv4 中，路由器判断是否需要检查数据报的惟一方法是解析所有数据报中的上层数据，至少是部分解析。这极大地降低了路由处理速度。在IPv6 中，如果没有Hop-by-Hop Options 扩展报头，则路由器知道无须处理路由器相关的信息，因此可以立即把数据包路由到最终目的地。若存在Hopby-Hop Options 扩展报头，则路由器只需检查报头，而无须深入查看数据包。

　　Hop-by-Hop Options 报头的格式如图2-4 所示。

　　下面对每个字段进行解释：

　　Next Header(下一报头，1 字节)

　　Next Header 字段标识了跟在Hop-by-Hop Options 报头之后的报头的类型。

　　Next Header 字段使用表2-1(在本章前面部分)中所列举的值。

　　Header Extension Length(报头扩展长度，1 字节)

　　该字段标识Hop-by-Hop Options 报头的长度，以8 字节为单位。长度的计算不包括第一个8 字节。

　　Options(选项，长度不定)这可能是一个或多个选项。该选项的长度是不定的，由Header Extension Length 字段决定。

　　Option Type(选项类型)字段是Options 字段的第一个字节，包含了在执行处理的节点不能识别该选项时如何处理选项的信息。该值的前两位值指定了要执行的操作。

　　● 值00：跳过并继续处理。

　　● 值01：丢弃数据包。

　　● 值10：丢弃数据包并向数据包的源地址发送“ICMP Parameter Problem,Code 2”消息，指出不能识别的选项类型。

　　● 值11：丢弃数据包，并且在目的不是多播地址时向数据包的源地址发送“ICMP Parameter Problem, Code 2”消息。

　　选项类型字段的第三位指定选项信息是否能够在传送途中改变(值01)或不改变(值00)。

　　Routing 报头

　　Routing报头用来给出一个或多个数据包在到达目的地的路径上应该经过的中间节点。在IPv4 中，这叫做Loose Source 和Record Route 选项。Routing 报头由其前一个报头的Next Header 值43 标识。图2-5 说明了Routing 报头的格式。

　　下面对每个字段进行解释：

　　Next Header(下一报头，1 字节)

　　Next Header 字段标识了Routing 报头后的报头的类型。它使用与IPv4 协议类型字段相同的值(参见本章前面的表2-1)。

　　Header Extension Length(报头扩展长度，1 字节)

　　该字段标识了Routing 报头的长度，以8 字节为单位。长度计算不包括第一个8 字节。

　　Routing Type(路由类型，1 字节)

　　该字段标识了Routing 报头的类型。RFC 2460 说明了Routing Type 0。

　　Segments Left(剩余段，1 字节)

　　该字段标识了在数据包到达最终目的地之前还需经过多少节点。

　　Type-Specific Data(类型相关数据，长度不定)

　　该字段长取决于路由类型。该长度总是保证完整的报头为8 字节的倍数。

　　如果处理Routing 报头的节点不能识别Routing Type 值，则采取的措施取决于Segments Left 字段的内容。如果Segments Left 字段不包含任何要经过的节点，则节点必须忽略Routing报头并处理数据包中的下一个报头，这由Next Header字段的值决定。如果Segments Left 字段不为0，则节点必须丢弃数据包并向数据包的源地址发送“ICMP Parameter Problem, Code 0”消息，指出未识别出的路由类型。如果转发节点因为下一链接的MTU 太小而不能处理数据包，它将丢弃数据包并向数据包的发送源发送“ICMP Packet Too Big”消息。

　　RFC 2460 中惟一描述的Routing Type 是Type Zero Routing 报头。处理Routing报头的第一个节点由IPv6 报头中的Destination address 字段指定。该节点对Segments Left 字段减1，并把IPv6 报头的Routing 报头内的下一个地址字段插入到IPv6 的Destination address 字段。然后数据包被转发到下一跳，按前面描述的方法处理Routing报头，直到到达最终目的地。最终目的地是Routing Header Data字段的最后一个地址。例如，Mobile IPv6 使用Routing 报头。任何向移动节点发送数据包的节点都将把数据包发送到该移动节点的转交地址(care-of-address)。

　　它包括Routing 报头，其中包含一条该移动节点的家庭地址。移动节点把IPv6 报头中的目的地址和Routing 报头中的条目进行交换，然后用家庭地址作为源地址进行应答，就如同它接收到了本地网络的数据包一样。要更深入讨论Mobile IPv6并了解相关术语的定义，请参考第七章。图2-6 为跟踪文件中的Routing 报头。

　　IPv6 报头中的Next Header 字段值为43 则表示是Routing 报头。Source address和Destination address 的前缀为“2002:”，这意味着6to4 站点。Routing 报头包含本节先前讨论的字段。Next Header 为ICMPv6，值58。Header Length 是两个8 字节长的单元，即共16 字节长。Segments Left 字段值为1，因为在Options 字段中有一个地址条目。最后，Options 字段列举要经过的地址。在本例中，只有一个地址条目。如果在此列举了一些主机，则每个转发节点(也就是IPv6 报头中的目的IP 地址)要从该主机列表中取出下一个条目，用作IPv6 报头中的新的目的IP 地址，对Segments Left 字段减1，并转发数据包。重复此过程，直到到达列表中的最后一台主机。RFC 2460 中演示了一个例子。

　　某源节点S 使用Routing 报头通过中间节点I1、I2 和I3，将一个数据包发送到目的节点D。Routing 报头的变化如表2-2 所示。

　　Fragment 报头

　　要把数据包发送到IPv6目的地的IPv6主机使用路径MTU发现来判断在通往目的地的路径上能使用的最大数据包大小。如果要发送的数据包大于所支持的MTU，源主机将对数据包进行分段处理。与IPv4不同，IPv6中的数据包不会由传输路径上的路由器分段。分段只会在发送数据包的源主机上进行。目的主机则进行重新组装。Fragment 报头由前一报头的Next Header 标识为值44。Fragment 报头的格式如图2-7 所示。

　　下面描述各个字段：

　　Next Header(下一报头，1 字节)

　　Next Header字段标识了紧跟在Fragment报头后的报头的类型。它与IPv4 协议类型字段的值相同(参见表2-1)。

　　Reserved(保留，1 字节)

　　未使用，设为0。

　　Fragment Offset(段偏移量，13 位)

　　数据包中的数据相对于原始数据包中数据的开始的偏移量，以8 字节为单位。

　　Reserved(保留，2 位)

　　未使用，设为0。

　　M-Flag(M- 标志，1 位)

　　值为1 表示还有更多分段;值为0 表示最后一个分段。

　　Identification(标识，4 字节)由源主机生成，用于识别属于原始数据包的所有数据包。该字段通常由计数器实现，每当有一个需要源主机进行分段的数据包，计数器就加1。

　　初始的未分段数据包称为原始数据包，其中有个不可分段的部分，包含了IPv6 报头，以及任何必须由通往目的地的路径上的节点进行处理的扩展报头(如Hopby-Hop Options 报头)。原始数据包中的可分段部分包括任何只能由最终目的主机处理的扩展报头，以及Upper-Layer 报头和任何数据。图2-8(RFC 2460)演示了分段过程。

　　每个分段中都有原始数据包的不可分段部分，后面紧跟着Fragment报头，然后是可分段数据。原始数据包的IPv6 报头必须稍做修改。长度字段表示分段的长度(不包括IPv6 报头)，而不是原始数据包的长度。

　　目的节点收集所有分段并进行重新组合。这些分段必须有相同的源地址和目的地址以及相同的标识值，才能进行组合。如果在第一个分段到达60 秒后，分段没有全部到达目的地，目的主机将丢弃所有数据包。如果目的方接收到了第一个分段(偏移为0)，它将向源地址返回一条“ICMPv6 Fragment Reassembly TimeExceeded”消息。

　　图2-9 展示了一个Fragment 报头。

　　我们通过发起一个从Marvin主机向Ford主机(分别是Windows 2000系统和Linux系统)的特大ping(译注1)命令来创建此Fragment 报头。整个分段集包括两个数据包第一个如图2-9 所示。在IPv6 报头中，Payload Length 字段值为1456，即Fragment报头和一个分段的长度，而不是整个原始数据包的长度。Next Header字段指定为值44，即Fragment 报头的值。该字段后紧跟着Hop Limit 字段和源IP 地址和目的IP 地址。Fragment 报头中的第一个字段是Next Header 字段。因为运行的是ping 命令，因此其中包含了值58(意味着ICMPv6)。并且，由于这是分段集当中的第一个数据包，因此偏移字段中的值为0;而M-Flag 则设为1，表示还有其他分段。Identification 字段设为1，且必须和属于此分段集的所有数据包相同。图2-10 展示了分段集当中的第二个数据包。

　　该分段集的第二个也是最后一个数据包的偏移值为0x05A8(十进制值为1448)，即第一个分段的长度。M-Flag 被设为0，表示这是最后的数据包，并通知接收主机进行分段的重组合。这两个数据包中的Identification 字段都设为1。

　　Destination Options 报头

　　Destination Options 报头携带着只由目的节点检查的可选信息。标识此类报头的Next Header 值为60。图2-11 展示了Destination Options 报头的格式。

　　下面对每个字段进行解释:

　　Next Header(下一报头，1 字节)

　　Next Header 字段标识了紧跟在Destination Options 报头后的报头类型。它使用本章前面表2-1 列出的值。

　　Header Extension Length(报头扩展长度，1 字节)该字段以8 字节为单位标识了Destination Options 报头的长度。前8 个字节的长度不计算在内。

　　Options(选项，长度不定)

　　可以有一个或多个选项。该选项的长度是不定的，由Header Extension Length 字段决定。

　　Options 字段的使用方式与Hop-by-Hop Options 报头的使用方式相同。使用了Destination Options 报头的一个例子就是Mobile IPv6。和外部网络相连接的移动IPv6 节点发送数据包时，把转交地址作为源地址，把本地网络地址作为本地地址目的选项。根据当前的Mobile IPv6 草案，正确处理Destination Option 中本地地址的能力是所有IPv6 节点都需要的。