《IPv6技术精要》一第2章 IPv6协议2.1 IPv4报头

本节书摘来自异步社区《IPv6技术精要》一书中的第1章，第1.1节，作者【美】Rick Graziani，更多章节内容可以访问云栖社区“异步社区”公众号查看

第2章 IPv6协议

IPv6技术精要
本章将详细描述IPv6协议的相关内容。首先分析IPv4和IPv6报头的各个字段，并分析两者的异同点，然后解释为什么IPv6所提供的不仅仅是更大的地址空间，而是一种更灵活、更有效的新协议。

有关IPv6报头结构的信息定义在RFC 2460“Internet Protocol, Version 6 (IPv6) Specification”中。本章除了介绍IPv6的基本报头之外，还将介绍IPv6的扩展报头，并在本章小结中归纳了IPv4与IPv6报头的之间差异。

2.1 IPv4报头

IPv6技术精要
为了更好地理解IPv6报头，首先回顾一下IPv4报头，这样既能复习一下IPv4报头的信息，又能加深对IPv4报头的理解。无论哪种情况，都将有助于理清与IPv6报头的差异。图2-1给出了RFC 791“Internet Protocol, DARPA Internet Program, Protocol Specification”中定义的IPv4报头结构。IPv6报头的结构如图2-2所示。快速对比这两种报头结构可以看出，IPv6报头是一种更为简单的协议——字段较少，这无疑会有助于简化协议并实现更高效的处理。

注：

有关IPv4报头中各个字段的详细介绍将放到下一节，本节的主要目的是为需要IPv4知识的读者提供参考和回顾。这方面的信息对于后面将要分析的IPv4与IPv6报头差异非常有用。
IPv4报头中的各个字段如下。

版本（Version，4比特）：该字段包含IP报头的版本号。对IPv4来说，该字段的值始终为4。

IHL（4比特）：IHL（Internet Header Length，互联网报头长度）字段指示IP报头长度（包括所有选项字段），以32比特字为单位。事实上，该字段指出了IP报头的结束位置以及数据或净荷的开始位置，最小值为5（5×32比特字=160比特或20个八位组[字节]），等于IPv4报头的最小长度（不包含任何选项和填充比特）。
ToS（8比特）：ToS（Type of Service，服务类型）字段指示了该数据包将受到路由器的何种处理方式。利用不同的优先级，ToS信息可以提供QoS（Quality of Service，服务质量）功能。当多个数据包都在排队从同一个接口向外发送时，可以利用ToS值来确定发送顺序。由于ToS字段并没有得到设计之初的广泛应用，因此IETF于1998年在RFC 2747中使用DS（Differentiated Service，差分服务）技术进行了重新定义。虽然本章将在后面进一步介绍DSCP（Differentiated Services Code Point，差分服务代码点）的详细信息，但有关ToS和DS的内容已经超出了本书范围。
数据包总长（Total Length，16比特）：该字段表示IP包（包括IP报头和数据）的长度，以八位组（字节）为单位。由于该字段为16比特，因而IPv4数据包最大为65 535字节。大多数IPv4包都远小于该数值。
接下来的三个字段用于数据包的分段与重组。IP的设计初衷是可以适应各种传输链路，但大多数传输链路都有被称为MTU（Maximum Transmission Unit）的最大包长限制。当传输路径上的MTU小于发送端的MTU时，由于允许路由器对IP包进行分段，因而能够适应不同的MTU差异。如果路由器收到一个大于其出接口MTU的IPv4包，就可以通过IPv4报头中的选项对数据包进行分段。有时数据包在源端就会被分段成多个数据包，最后的IP包目的地址负责将分段后的数据包重组成原始的全尺寸IP包。

标识符（Identifier，16比特）：大多数经网络传送的消息都包含多个数据包，消息中的每个数据包都通过16比特标识符字段分配一个唯一值。当某个数据包需要被分段成两个或多个数据包时，所有被分段后的数据包的标识符字段都相同，这样就能帮助接收端重组这些分段。
标志（Flag，3比特）：该字段的第一个比特为0，表示被保留或未使用。第二个比特称为DF（Don’t Fragment，不分段）比特，DF比特为1表示该数据包不应该被分段，但很多协议并不关心分段进程，因而将该比特置0，意思是可以根据需要对数据包进行分段。第三个比特是更多分段标志（More Fragments Flag），表示该分段是最后一个分段（比特为0）或者后面还有更多的分段（比特为1）。如果数据包未被分段，那么就只有一个分段（也就是整个数据包），该标志比特就被置为0。
注：

DF比特在测试源端与目的端路径上的MTU时非常有用，如果DF为1，那么数据包就不应该被分段，对路径上的任意路由器来说，如果其MTU小于数据包，那么就丢弃该数据包并向源端返回一条ICMP（Internet Control Message Protocol，因特网控制消息协议）消息“目的地不可达”，该ICMP消息将包含该路由器出接口的MTU。有关IPv4的路径MTU发现（Path MTU Discovery）的相关内容已经超出了本书范围，如果感兴趣，可以进一步参考RFC 1191“Path MTU Discovery”。本章稍后将讨论IPv6的路径MTU发现。
分段偏移（Fragment Offset，13比特）：数据包被分段后，该字段将指示该数据包的偏移量或者在原始数据中的位置，以8个八位组（64字节）为单位，从本质上来看，分段偏移字段为接收端指示了该被分段数据包与其他被分段数据包之间的关系，第一个分段的偏移值为0，如果数据包未被分段，那么该字段值为0。
TTL（8比特）：TTL（Time to Live，生存时间）字段可以确保发生路由环路时数据包不会无止境的在网络中生存下去，每经过一台路由器，数据包的TTL值就递减1，当该字段值达到0时，该数据包就会被丢弃并向该数据包的源端发送一条ICMPv4超时（类型11）消息。
注：

TTL最初的设计意图是希望表示允许数据包在网络中传送的最大实际时间，而不必是路由器的跳数，RFC 791中提到“即使本地没有关于实际花费时间的相关信息，该字段仍然必须被递减1，时间度量单位为秒（也就是说，值1表示1秒），因而，生存时间的最大值为255秒或4.25分钟。”由于路由器并不计算时间量，而仅仅对TTL执行递减1操作，因而使得该字段在事实上成为跳数。
协议（Protocol，8比特）：该字段表示IP包中数据部分所承载的协议类型，RFC 1700（Assigned Numbers）指定了不同协议的取值，大家可以通过IANA负责维护的在线数据库www.iana.org/assignments/protocol-numbers/protocol-numbers.xml查看已分配的协议号，常见值有ICMP为1、TCP为6、UDP为17。
注：

有时该字段也被称为承载的上层协议，由于IP包所承载的数据或净荷可能是其他三层协议（如ICMP，甚至是IP），因而这可能会让人产生误解。
报头校验和（Header Checksum，16比特）：IP报头中的校验和可以为数据包传输过程中的损害提供保护机制，该字段并不是以太网中使用的复杂的CRC（Cyclic Redundancy Check，循环冗余校验），而是较为简单的针对IP报头的16比特校验和，路径上的每台路由器都会验证并重新计算该字段，如果校验和检查失败，路由器就会丢弃该数据包。
源地址（Source Address，32比特）：源地址字段是数据包发起方的32比特IP地址。
目的地址（Destination Address，32比特）：目的地址字段是最终目的地或数据包接收方的32比特IP地址，路由器利用该字段将数据包沿路径转发到最终目的地。
注：

NAT可以将源地址或目的地址更改为转换网关的某个地址，通常是RFC 1918的私有IP地址。有关NAT的内容已超出了本书范围，大家可参考RFC 4787。
选项（Options，可变长度）：选项字段为可选字段，因而可以出现在IP包中，也可以不出现在IP包中，该字段长度可变，大多数数据包都没有该字段，常见选项有记录路由选项、时间戳选项以及用来增强traceroute程序的跟踪路由选项，这些都定义在RFC 1393（Traceroute Using an IP Option）中。
填充（Padding，可变长度）：如果使用了一个或多个选项，并且IP报头的大小不再是32比特的整数倍，那么就会在报头填充比特0直至32比特边界。
数据（可变长度）：是在IP包中进行传输并通过协议字段进行标识的数据，数据可以是其他三层协议（如ICMP），也可以是TCP或UDP等高层协议。