IPV6介绍
下面这个介绍肯定是我从哪里看来的，然后做了些修改，具体从哪看来的真记不住了，所以我无法写出引用自哪的，非常抱歉。
看ipv6实现前一定要先看此篇内容，ipv6的原理介绍。
定义 IPv6是Internet Protocol Version 6的缩写，其中Internet Protocol译为“互联网协议”。 IPv6是IETF（互联网工程任务组，Internet Engineering Task Force）设计的用于替代现行版本IP协议（IPv4）的下一代IP协议。 目前的全球因特网所采用的协议族是TCP/IP协议族。IP是TCP/IP协议族中网络层的协议，是TCP/IP协议族的核心协议。 目前IP协议的版本号是4（简称为IPv4），它的下一个版本就是IPv6。IPv6正处在不断发展和完善的过程中，它在不久的将来将取代目前被广泛使用的IPv4。 概述 目前我们使用的第二代互联网IPv4技术，核心技术属于美国。它的最大问题是网络地址资源有限，从理论上讲，编址1600万个网络、40亿台主机。但采用A、B、C三类编址方式后，可用的网络地址和主机地址的数目大打折扣，以至目前的IP地址近乎枯竭。其中北美占有3/4，约30亿个，而人口最多的亚洲只有不到4亿个，中国只有3千多万个，只相当于美国麻省理工学院的数量。地址不足，严重地制约了我国及其他国家互联网的应用和发展。 一方面是地址资源数量的限制，另一方面是随着电子技术及网络技术的 发展，计算机网络将进入人们的日常生活，可能身边的每一样东西都需要连入全球因特网。在这样的环境下，IPv6应运而生。单从数字上来说，IPv6所拥有 的地址容量是IPv4的约8×10^28倍，达到2^128-1个。这不但解决了网络地址资源数量的问题，同时也为除电脑外的设备连入互联网在数量限制上 扫清了障碍。 但是与IPv4一样，IPv6一样会造成大量的 IP地址浪费。准确的说，使用IPv6的网络并没有2^128-1个能充分利用的地址。首先，要实现IP地址的自动配置，局域网所使用的子网的前缀必须等 于64，但是很少有一个局域网能容纳2^64个网络终端；其次，由于IPv6的地址分配必须遵循聚类的原则，地址的浪费在所难免。 但是，如果说IPv4实现的只是人机对话，而IPv6则扩展到任意事物之间的对话，它不仅可以为人类服务，还将服务于众多硬件设备，如家用电器、传感器、远程照相机、汽车等，它将是无时不在，无处不在的深入社会每个角落的真正的宽带网。而且它所带来的经济效益将非常巨大。 当然，IPv6并非十全十美、一劳永逸，不可能解决所有问题。IPv6只能在发展中不断完善，也不可能在一夜之间发生，过渡需要时间和成本，但从长远看，IPv6有利于互联网的持续和长久发展。 目前，国际互联网组织已经决定成立两个专门工作组，制定相应的国际标准。 优势 与IPV4相比，IPV6具有以下几个优势： 一，IPv6具有更大的地址空间。IPv4中规定IP地址长度为32，即有2^32-1（符号^表示升幂，下同）个地址；而IPv6中IP地址的长度为128，即有2^128-1个地址。 二，IPv6使用更小的路由表。IPv6的地址分配一开始就遵循聚类（Aggregation）的原则，这使得路由器能在路由表中用一条记录（Entry）表示一片子网，大大减小了路由器中路由表的长度，提高了路由器转发数据包的速度。 三，IPv6增加了增强的组播（Multicast）支持以及对流的支持（Flow Control），这使得网络上的多媒体应用有了长足发展的机会，为服务质量（QoS，Quality of Service）控制提供了良好的网络平台。 四，IPv6加入了对自动配置（Auto Configuration）的支持。这是对DHCP协议的改进和扩展，使得网络（尤其是局域网）的管理更加方便和快捷。 五，IPv6具有更高的安全性。在使用IPv6网络中用户可以对网络层的数据进行加密并对IP报文进行校验，极大的增强了网络的安全性。 技术信息概述 IPv6包由IPv6包头（40字节固定长度）、扩展包头和上层协议数据单元三部分组成。 IPv6包扩展包头中的分段包头中指名了IPv6包的分段情况。其中不可分段部分包括：IPv6包头、Hop-by-Hop选项包头、目的地选项包头（适用于中转路由器）和路由包头；可分段部分包括：认证包头、ESP协议包头、目的地 选项包头（适用于最终目的地）和上层协议数据单元。但是需要注意的是，在IPv6中，只有源节点才能对负载进行分段，并且IPv6超大包不能使用该项服务。 IPv6数据包：包头 IPv6包头长度固定为40字节，去掉了IPv4中一切可选项，只包括8个必要的字段，因此尽管IPv6地址长度为IPv4的四倍，IPv6包头长度仅为IPv4包头长度的两倍。 其中的各个字段分别为： code extract from linux-2.6.24 struct ipv6hdr { //Version：4位，IP协议版本号，值= 6。 //Traffice Class（通信类别）：8位，指示IPv6数据流通信类别或优先级。功能类似于IPv4的服务类型（TOS）字段。 #if defined(__LITTLE_ENDIAN_BITFIELD) __u8 priority:4, version:4; #elif defined(__BIG_ENDIAN_BITFIELD) __u8 version:4, priority:4; #else #error "Please fix <asm/byteorder.h>" #endif //Flow Label（流标记）：20位，IPv6新增字段，标记需要IPv6路由器特殊处理的数据流。该字段用于某些对连接的服务质量有特殊要求的通信， //诸如音频或视频等实时数据传输。在IPv6中，同一信源和信宿之间可以有多种不同的数据流，彼此之间以非“0”流标记区分。 //如果不要求路由器做特殊处理，则该字段值置为“0”。 __u8 flow_lbl[3]; //Payload Length（负载长度）：16位负载长度。负载长度包括扩展头和上层PDU，16位最多可表示65535字节负载长度。 //超过这一字节数的负载，该字段值置为“0”，使用扩展头逐个跳段（Hop-by-Hop）选项中的巨量负载（Jumbo Payload）选项。 __be16 payload_len; //Next Header（下一包头）：8位，识别紧跟IPv6头后的包头类型，如扩展头（有的话）或某个传输层协议头（诸如TCP，UDP或着ICMPv6）。 __u8 nexthdr; //Hop Limit（跳段数限制）：8位，类似于IPv4的TTL（生命期）字段。 //与IPv4用时间来限定包的生命期不同，IPv6用包在路由器之间的转发次数来限定包的生命期。包每经过一次转发，该字段减1，减到0时就把这个包丢弃。 __u8 hop_limit; //Source Address（源地址）：128位，发送方主机地址。 struct in6_addr saddr; //Destination Address（目的地址）：128位，在大多数情况下，目的地址即信宿地址。 //但如果存在路由扩展头的话，目的地址可能是发送方路由表中下一个路由器接口。 struct in6_addr daddr; }; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 版本 | 传输类别 | 数据流标签 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有效载荷长度 | 下一个首部 | 跳数限制 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 源 地 址 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 目 的 地 址 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6数据包：扩展首部 IPv6包头设计中对原IPv4包头所做的一项重要改进就是将所有可选字段移出IPv6包头，置于扩展头中。由于除Hop-by-Hop选项扩展头外，其他扩展头不受中转路由器检查或处理，这样就能提高路由器处理包含选项的IPv6分组的性能。 通常，一个典型的IPv6包，没有扩展首部。仅当需要路由器或目的节点做某些特殊处理时，才由发送方添加一个或多个扩展首部。与IPv4不同，IPv6扩展头长度任意，不受40字节限制，以便于日后扩充新增选项，这一特征加上选项的处理方式使得IPv6选项能得以真正的利用。 但是为了提高处理选项头和传输层协议的性能，扩展首部总是8字节长度的整数倍。 在 IPv6 里, 可选的网络层信息在一个独立的首部编码, 放在包中 IPv6 首部与层协议首部之间. 有这样几个为数不多的扩展首部, 每个首部由不同的"下一个首部"的值来标识. 一个 IPv6 首部可以携带零个, 一个或者更多的扩展首部, 每个扩展首部由前一个首部中的"下一个首部"字段标识. 如下例所示: +---------------+------------------------ | IPv6 首部 | TCP 首部 + 数据 | | | 下一个首部 = | | TCP | +---------------+------------------------ | IPv6 首部 | 路由首部 | TCP 首部 + 数据 | | | | 下一个首部 = | 下一个首部 = | | 路由首部 | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 首部 | 路由首部 | 分片首部 | TCP 首部 + 数据 | | | | 的分片 | 下一个首部 = | 下一个首部 = | 下一个首部 = | | 路由首部 | 分片首部 | TCP | +---------------+----------------+-----------------+----------------- 除了一个特例, 扩展首部不在包的传送路径中的任何节点检测和处理, 直到这个到达目的地址字段标识的那个节点 (或者在组播的情况下, 一组节点中的每一个). 这个特例是指 Hop-by-Hop 选项首部. 它携带了包的传送路径中的每个节点都必须检测和处理的信息, 包括源节点和目的节点. Hop-by-Hop 选项首部如果存在, 就必须紧跟在 IPv6 首部后面. IPv6 首部中"下一个首部"字段的值为零表示存在这个首部. 当前已定义的扩展首部中的两个 -- Hop-by-Hop 选项首部和目的地址选项首部 -- 携带不定数量的, 以类型-长度-值(TLV)格式进行编码的选项, 其格式如下： +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 选项类型 | 选项数据长度 | 选项数据 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 选项类型 : 8 比特标识符, 标识选项的类型. 选项数据长度 : 8 比特无符号整数. 以八位组为单位的选项数据字段的长度. 选项数据 : 可变长度字段. 依选项类型而不同的数据. 选项类型标识符以如下规则编码: 其最高两比特指定了当 IPv6 节点无法识别这一选项类型时所必须的反应: 00 - 跳过这一选项, 继续处理首部. 01 - 抛弃这个包 10 - 抛弃这个包, 并且不管包的目的地址是不是组播地址, 都给包的源地址发送一个 ICMP "参数存在问题", 编码 2 的报文, 指针指向无法识别的选项类型. 11 - 抛弃这个包, 并且只有当包的目的地址不是组播地址时, 才给包的源地址发送一个 ICMP "参数存在问题", 编码 2 的报文, 指针指向无法识别的选项类型. 选项类型标识符的第三位指明了选项数据是否可以改变到最终目的地址的选路. 若存在认证首部, 在包计算或校验认证值时, 可改变选路的选项的整个数据字段都必须当作全零的八位组来处理. 0 - 选项数据不会改变选路 1 - 选项数据可能改变选路 注意：上述的前三位应作为选项类型的一部分, 而不能独立于选项类型之外. 这就是说, 某一特定的选项是由全部 8 比特的选项类型标识符标识的, 而并不只是选项类型中的后面 5 位. 目前，RFC 2460中定义了以下6个IPv6扩展首部：Hop-by-Hop（逐个跳段）选项包头、目的地选项包头、路由包头、分段包头、认证包头和ESP协议包头： （一）Hop-by-Hop选项首部 包含分组传送过程中，每个路由器都必须检查和处理的特殊参数选项。其中的选项描述一个分组的某些特性或用于提供填充。这些选项有： Pad1选项（选项类型为0），填充单字节。 该选项是一种特殊情况 -- 它没有长度字段和数值字段 +-+-+- | 0 | +-+-+- PadN选项（选项类型为1），填充2个以上字节。 填充N 选项 (对齐要求: 无) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | 选项数据长度 | 选项数据 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 填充N 选项用于在首部的选项区填充两个或两个以上的八位组. 对于 N 个八位组的填充, 选项数据长度字段应包含值 N-2, 选项数据由 N-2 个零值八位组组成. Jumbo Payload选项（选项类型为194），用于传送超大分组。使用Jumbo Payload选项，分组有效载荷长度最大可达4,294,967,295字节。负载长度超过65,535字节的IPv6包称为“超大包”。 这个选项应紧接在ipv6头后面，对齐要求是 4n + 2 （看上面对齐选项），格式如下： +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Jumbo Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 选项类型 8-bit value C2 (hexadecimal). 选项数据长度 Len 8-bit value 4. 负载长度 32-bit unsigned integer. 字节表示完整的负载长度，不包含ipv6头，主要包括 hop-by-hop 选项头和任何其他扩展头长度和数据长度，长度必须是大于65535. 路由器警告选项（选项类型为5），提醒路由器分组内容需要做特殊处理。路由器警告选项用于组播收听者发现和RSVP（资源预定）协议。 路由器警告选项具有如下格式： +--------+--------+--------+--------+ |10010100|00000100| 2 octet value | +--------+--------+--------+--------+ 类型： 拷贝标志：1（所有段都必须携带此选项） 选项种类：0（控制） 选项号：20（十进制） 长度：4 值：具有如下值的两个八位码： 0—路由器将检查包 1－65535—保留 Hop-by-Hop 选项首部用于传送必须由包的传送路径中的每个节点检测的可选信息. Hop-by-Hop 选项首部由 IPv6 首部中"下一个首部"字段值为 0 来标识, 并且具有 如下的格式: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 下一个首部 | 首部扩展长度 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . 选 项 . (Pad1, PadN) . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 下一个首部 8 比特选择器. 标识紧跟在 Hop-by-Hop 选项首部后面首部的类型. 使用与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值. 首部扩展长度 8 比特无符号整数. 以 8 个八位组为单位的 Hop-by-Hop 选项首部的长度, 不包括开始的 8 个八位组. 选项 可变长度字段, 其长度须使整个 Hop-by-Hop 选项首部的长度为 8 个八位组的整数倍. 包含一个或多个 TLV 编码的选项. （二）目的地选项首部 指名需要被中间或最终目的地检查的信息。有两种用法： 如果存在路由扩展头，则每一个中转路由器都要处理这些选项。 如果没有路由扩展头，则只有最终目的节点需要处理这些选项。 目的地址选项首部用于携带只需由包的目的节点检测的可选信息. 前面的首部中"下一个首部"字段中的值为 60 表示下一个首部为目的地址选项首部. 目的地址选项首部具有如下格式: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 下一个首部 | 首部扩展长度 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . 选 项 . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 下一个首部 8 比特选择器. 标识紧跟在目的地址选项首部后面的首部的类型. 使用与 IPv4 协议字段 [RFC-1700 及后续协议]相同的数值. 首部扩展长度 8 比特无符号整数. 以 8 个八位组为单位的目的地址选项首部的长度, 不包括开始的 8 个八位组. 选项 可变长度字段, 其长度须使整个目的地址选项首部的长度为 8 个八位组的整数倍. 包含一个或多个 TLV 编码的选项. （三）路由首部 类似于IPv4的松散源路由。IPv6的源节点可以利用路由扩展包头指定一个松散源路由，即分组从信源到信宿需要经过的中转路由器列表。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 下一个首部 | 首部扩展长度 | 路由类型 | 分段剩余 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 特定类型数据. . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 下一个首部 8 比特选择器. 标识紧跟在路由首部后面的首部的类型. 使用与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值. 首部扩展长度 8 比特无符号整数. 以 8 个八位组为单位的路由首部的长度, 不包括开始的 8 个八位组. 路由类型 8 比特的某种特定路由首部变量的标识符. 分段剩余 8 比特无符号整数. 剩余的路由分段的数量. 也就是在到达最终的目的节点之前仍然应当访问的, 明确列出的中间节点的数量. 特定类型的数据 可变长度字段. 其格式由路由类型决定, 其长度须使整个路由首部的长度为 8 个八位组的整数倍. 如果节点在处理收到的包的过程中遇到了含有无法识别的路由类型值的路由首部, 节点应根据分段剩余字段中的值进行处理, 如下所述: 如果分段剩余值是零, 节点必须忽略路由首部, 继续处理包中的下一个首部, 其类型由路由首部中的"下一个首部"字段中的值来标识. 如果分段剩余值非零, 节点必须抛弃这个包, 并且给包的源地址发送一个 ICMP "参数存在问题", 编码 0 的报文, 指针指向无法识别的路由类型. 如果中间节点在处理路由首部之后, 确定应将包传送到一个链路 MTU 小于此包的尺寸的链路中去, 那么中间节点必须抛弃此包, 并且给包的源地址发送一个 ICMP "包太大"的报文. 类型 0 的路由首部具有如下格式: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 下一个首部 | 首部扩展长度 | 路由类型 = 0 | 分段剩余 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 保 留 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 地 址 [1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 地 址 [2] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...... 保留 32 比特保留字段. 传输时初始化为零; 接收时忽略. 地址[1..n] 128 比特地址向量, 从 1 到 n 编号. 不允许组播地址出现在类型 0 的路由首部中, 也不允许出现在携带类型 0 路由首部的包中的 IPv6 目的地址字段中. 直到包到达 IPv6 首部中的目的地址字段所标识的那个节点才对路由首部进行检测和处理. 在这个节点调用路由首部处理模块, 并且对于路由类型 0, 执行下面的 算法: if 分段剩余 = 0 { 继续处理包中的下一个首部, 其类型由路由首部中"下一个首部"字段所标识 } else if 首部扩展长度为奇数 { 给源地址发送ICMP "参数存在问题", 编码 0 的报文, 指针指向首部扩展长度字段, 并且抛弃此包 } else { 计算出n, 也就是路由首部中的地址数量. 方法是首部扩展长度除以 2 if 分段剩余比 n 大 { 给源地址发送一个 ICMP "参数存在问题", 编码 0 的报文, 指针指向分段 剩余字段, 并且抛弃此包 } else { 分段剩余减一; 计算 i, 也就是地址向量(地址列表)中要"访问"的下一个地址, 方法是 n 减分段剩余 if 地址[i] 或者 IPv6 目的地址是组播地址 { 抛弃此包 } else { 交换 IPv6 目的地址和地址[i] if IPv6 跳数限制小于等于 1 { 给源地址发送一个 ICMP "超时 – 传输超过跳数限制" 的报文, 并且 抛弃此包 } else { 跳数限制减一; 向 IPv6 模块重新提交此包, 传给新的目的节点 } } } } （四）分段首部 提供分段和重装服务。当分组大于链路最大传输单元（MTU）时，源节点负责对分组进行分段，并在分段扩展包头中提供重装信息。 在 IPv6 里, 只有包的源节点才能进行分片, 传输路径中的路由器不能进行分片，在前面的首部中"下一个首部"字段中的值为 44 表示下一个首部为分片首部. 分片首部具有如下格式: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 下一个首部 | 保 留 | 分片偏移量 | Res | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 标 识 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 下一个首部 8 比特选择器. 标识原包(后面有定义)中可分片部分的初始首部的类型. 使用与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值. 保留 8 比特保留字段. 传输时初始化为零; 接收时忽略. 分片偏移量 13 比特无符号整数. 以 8 个八位组为单位的, 首部后面的数据相对于原包中可分片部分的开始位置处的偏移量. Res (保留) 2 比特保留字段. 传输时初始化为零; 接收时忽略. M 标志位 1 = 还有分片; 0 = 最后一个分片. 标识 32 比特. 参见下面的详细说明. 要发送大于去往目的节点的路径 MTU 的包, 源节点可以将包分成若干分片, 每个分片单独发送, 并且在接收者处进行重组. 源节点应为每个要分片的包规定一个标识值. 这个标识值必须不同于近期之内*同一对源节点和目的节点之间其他的分片包的标识值. 如果存在路由首部, 那么目的节点是指最终目的节点. * "近期之内" 是指包可能的最大生存期. 其中包括从源节点到目的节点的传输时间, 以及等待与同一包的其他分片重组所花费的时间. 尽管如此, 源节点并没有必要知道包的最大生存期. 它只需将标识字段值作为一个简单的 32 比特循环计数器, 每次将包分片时计数器增加一个增量即可. 具体的实现可以自己选择是维护一个计数器还是多个计数器, 还可以选择是为每个节点可能的源地址维护一个计数器, 还是为每个活动的 (源地址, 目的地址) 对维护一个计数器. 最初的, 未分片的大数据包称为"原包". 原包可以看作是由两部分组成的, 如下： 原包: +------------------+----------------------//-----------------------+ | 不可分片 | 可分片 | | 部分 | 部分 | +------------------+----------------------//-----------------------+ 不可分片部分包括 IPv6 首部, 以及那些必须由路由中的节点处理的扩展首部. 也就是以下三种情况: 所有路由首部以前(含路由首部)的首部(如果存在的话), 或者是 Hop-by-Hop 选项首部(如果存在的话), 或者没有扩展首部. 包中其余的部分为可分片部分, 也就是只需由包的最终目的节点处理的扩展首部, 以及上层协议首部和数据. 原包中可分片部分被划分成若干分片, 除去最后("最右")一个分片, 每个分片都为 8 个八位组的整数倍长. 这些分片由相互独立的"分片包"来传送, 如下例所示: 原包: +------------------+--------------+--------------+--//--+----------+ | 不可分片 | 第一个 | 第二个 | | 最后一个 | | 部分 | 分片 | 分片 | .... | 分片 | +------------------+--------------+--------------+--//--+----------+ 分片包: +------------------+--------+--------------+ | 不可分片 | 分片 | 第一个 | | 部分 | 首部 | 分片 | +------------------+--------+--------------+ +------------------+--------+--------------+ | 不可分片 | 分片 | 第二个 | | 部分 | 首部 | 分片 | +------------------+--------+--------------+ o o o +------------------+--------+--------------+ | 不可分片 | 分片 | 最后一个 | | 部分 | 首部 | 分片 | +------------------+--------+--------------+ 每个分片包由下述几部分构成: (1) 原包中的不可分片部分. 其中原来 IPv6 首部中有效载荷长度值只应包含本分片包的长度 (不包含 IPv6 首部自身的长度). 不可分片部分中最后一个首部的"下一个首部"字段值改为 44. (2) 分片首部. 其中包括: 其"下一个首部"值标识原包中可分片部分的第一个首部. 其分片偏移量字段 包含以 8 个八位组为单位的, 本分片相对于原包中可分片部分开始位置处的偏移量. 第一个("最左")分片的分片偏移量为 0. 其 M 标志位为 0 表示这是最后("最右")一个分片, 否则 M 标志位为 1. 其标识值依原包产生. (3) 分片自身 分片的长度应使分片包的尺寸适于去往目的节点的路径 MTU. 在目的节点, 分片包重组为原来未分片的形式. 重组应遵循如下原则: 原包只能由具有相同源地址, 目的地址和分片标识的分片包重组. 重组后的包中的不可分片部分，由第一个分片包(也就是分片偏移量为 0 的那个包)中分片首部前面所有的首部(不含分片首部)组成, 并作如下两处修改: 从第一个分片的分片首部中的"下一个首部"字段得到最终重组后不可分片部分首部中的"下一个首部"字段值. 由不可分片部分的长度及最后一个分片的长度和偏移量计算出重组包的有效载荷长度. 计算重组包的有效载荷长度的公式为: PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last 公式中 PL.orig = 重组包的有效载荷长度字段. PL.first = 第一个分片包的有效载荷长度字段. FL.first = 第一个分片包中分片首部后面的分片长度. FO.last = 最后一个分片包中分片首部的分片偏移量字段. FL.last = 最后一个分片包中分片首部后面的分片长度. 重组包的可分片部分由各分片包中分片首部后面的分片组成. 各分片的长度可由分片包的有效载荷长度减去此包中 IPv6 首部与分片首部的长度计算得到. 各分片在可分片部分中的相对位置由其分片偏移量值计算得到. 最终重组后的包不含分片首部. 包的重组过程可能出现下列错误情形： 如果收到包的第一个(到达的)分片之后 60 秒内没有收到全部分片以完成重组, 那么必须终止这次重组, 抛弃所有已收到的包. 如果收到了第一个分片 (也就是分片偏移量为零的那个分片), 应给分片的源节点发送一个 ICMP "超时 -- 分 片重组超时"报文. 如果由分片包的有效载荷长度字段得到的分片长度不是 8 个八位组的整数倍, 而且分片的 M 标志位被置为 1, 那么必须抛弃这个分片, 并且给分片的源节点发送一个 ICMP "参数存在问题", 编码 0 的报文, 指针指向分片包的有效载荷长度字段. 如果分片的长度和偏移量使得重组后的包的有效载荷长度超过了 65,535 个八位组, 那么必须抛弃这个分片, 并且向分片的源节点发送一个 ICMP "参数存在问题", 编码 0 的报文, 指针指向分片包的分片偏移量字段. 不希望出现下述情形, 但不将它们视为错误: 同一个原包的不同分片中, 分片首部前面的首部在数量和内容上都可能不同. 当每个分片包到达时, 无论分片首部前面的首部是什么, 都应在进入分片重组队列之前进行处理. 只有分片偏移量为零的那个包中的首部才保留在重组后的包中. 同一个原包的不同分片中, 分片首部中"下一个首部"值可能不同. 只有分片偏移量为零的那个包中的值才可用于重组. （五）认证首部 提供数据源认证、数据完整性检查和反重播保护。认证包头不提供数据加密服务，需要加密服务的数据包，可以结合使用ESP协议。 （六）ESP协议首部 提供加密服务。 其他 ： "无下一个首部" IPv6 首部或者扩展首部中"下一个首部"的值为 59 表示这个首部后面没有其他的首部了. 如果 IPv6 首部中的有效载荷字段表明最后一个首部 ("下一个首部"字段为 59 的那个首部) 后面还有其他的八位组, 那么这些八位组将被忽略, 并且在传输过程中保持不变. IPv6数据包：上层协议数据单元 上层数据单元即PDU，全称为Protocol Data Unit。 PDU由传输头及其负载（如ICMPv6消息、或UDP消息等）组成。而IPv6包有效负载则包括IPv6扩展头和PDU，通常所能允许的最大字节数为65535字节，大于该字节数的负载可通过使用扩展头中的Jumbo Payload（见上文）选项进行发送。 在计算校验和时包含 IP 首部中地址的传输层或其他上层协议必须为通过 IPv6 进行传输加以相应的改进, 将 32 位的 IPv4 地址改为 128 位的 IPv6 地址. 特别地, 下面的例子展示了 TCP 和 UDP 的 IPv6 "伪首部": +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 源 地 址 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 目 的 地 址 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 零 | 下一个首部 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 如果 IPv6 包包含路由首部, 伪首部使用的目的地址就是最终的目的地址. 在初始节点, 这一地址就是路由首部的最后一个元素; 在接收者一方, 这一地址在 IPv6 首部的目的地址字段. o 伪首部中"下一个首部"字段值标识了上层协议的类型 (比如 6 为 TCP, 17 为 UDP). 如果 IPv6 首部和上层协议首部之间还存在扩展首部, 那么伪首部中"下一个首部"字段的值可能与 IPv6 首部中的值有所不同. o 伪首部中上层协议包的长度是指上层协议的首部和数据 (比如, TCP 首部加上 TCP 数据). 一些上层协议携带了自己的长度信息 (比如, UDP 首部中的长度字段); 对于这样的协议, 这些信息就是伪首部使用的长度信息. 其他协议 (比如 TCP) 不携带自己的长度信息, 在这种情况下, 伪首部使用的长度就是 IPv6 首部中的有效载荷长度字段值减去 IPv6 首部和上层协议首部之间扩展首部的长度. o 与 IPv4 不同的是, 当 IPv6 节点生成 UDP 包时, UDP 校验和不是可选的. 也就是说, 只要生成 UDP 包, IPv6 节点必须计算数据包和伪首部的 UDP 校验和. 而且, 如果计算结果为 0, 必须将其改为十六进制的 FFFF, 放入 UDP 首部. IPv6 接收节点必须抛弃包含零校验和的 UDP 包, 并记录这一错误. IPv6 版本的 ICMP [ICMPv6] 在计算校验和时包含上述的伪首部; 这是一个与 IPv4 的版本不同的地方 -- IPv4 的版本在校验和中不包含伪首部. 改变的原因是防止 ICMP 发生不正确的传送, 以及 IPv6 首部中的这些字段发生讹误 -- 它们没有受到网络层校验和的保护. ICMP 的伪首部中"下一个首部"字段的值为 58, 标识IPv6 版本的 ICMP. IPv6寻址 在 Internet 协议版本 6 (IPv6) 中，地址的长度是 128 位。地址空间如此大的一个原因是将可用地址细分为反映 Internet 的拓扑的路由域的层次结构。另一个原因是映射将设备连接到网络的网络适配器（或接口）的地址。IPv6 提供了内在的功能，可以在其最低层（在网络接口层）解析地址，并且还具有自动配置功能。 文本表示形式 以下是用来将 IPv6 地址表示为文本字符串的三种常规形式： （一）冒号十六进制形式。 这是首选形式 n:n:n:n:n:n:n:n。每个 n 都表示八个 16 位地址元素之一的十六进制值。例如： 3FFE:FFFF:7654:FEDA:1245:BA98:3210:4562. （二）压缩形式。 由于地址长度要求，地址包含由零组成的长字符串的情况十分常见。为了简化对这些地址的写入，可以使用压缩形式，在这一压缩形式中，多个 0 块的单个连续序列由双冒号符号 (::) 表示。此符号只能在地址中出现一次。例如，多路广播地址 FFED:0:0:0:0:BA98:3210:4562 的压缩形式为 FFED::BA98:3210:4562。单播地址 3FFE:FFFF:0:0:8:800:20C4:0 的压缩形式为 3FFE:FFFF::8:800:20C4:0。环回地址 0:0:0:0:0:0:0:1 的压缩形式为 ::1。未指定的地址 0:0:0:0:0:0:0:0 的压缩形式为 ::。 （三）混合形式。 此形式组合 IPv4 和 IPv6 地址。在此情况下，地址格式为 n:n:n:n:n:n:d.d.d.d，其中每个 n 都表示六个 IPv6 高序位 16 位地址元素之一的十六进制值，每个 d 都表示 IPv4 地址的十进制值。 地址类型 地址中的前导位定义特定的 IPv6 地址类型。包含这些前导位的变长字段称作格式前缀 (FP)。 IPv6 单播地址被划分为两部分。第一部分包含地址前缀，第二部分包含接口标识符。表示 IPv6 地址/前缀组合的简明方式如下所示：ipv6 地址/前缀长度。 以下是具有 64 位前缀的地址的示例。 3FFE:FFFF:0:CD30:0:0:0:0/64. 此示例中的前缀是 3FFE:FFFF:0:CD30。该地址还可以以压缩形式写入，如 3FFE:FFFF:0:CD30::/64。 IPv6 定义以下地址类型： 单播地址。用于单个接口的标识符。发送到此地址的数据包被传递给标识的接口。通过高序位八位字节的值来将单播地址与多路广播地址区分开来。多路广播地址的高序列八位字节具有十六进制值 FF。此八位字节的任何其他值都标识单播地址。 以下是不同类型的单播地址： 链路-本地地址。这些地址用于单个链路并且具有以下形式：FE80::InterfaceID。链路-本地地址用在链路上的各节点之间，用于自动地址配置、邻居发现或未提供路由器的情况。链路-本地地址主要用于启动时以及系统尚未获取较大范围的地址之时。 站点-本地地址。这些地址用于单个站点并具有以下格式：FEC0::SubnetID:InterfaceID。站点-本地地址用于不需要全局前缀的站点内的寻址。 全局 IPv6 单播地址。这些地址可用在 Internet 上并具有以下格式：010（FP，3 位）TLA ID（13 位）Reserved（8 位）NLA ID（24 位）SLA ID（16 位）InterfaceID（64 位）。 多路广播地址。一组接口的标识符（通常属于不同的节点）。发送到此地址的数据包被传递给该地址标识的所有接口。多路广播地址类型代替 IPv4 广播地址。 任一广播地址。一组接口的标识符（通常属于不同的节点）。发送到此地址的数据包被传递给该地址标识的唯一一个接口。这是按路由标准标识的最近的接口。任一广播地址取自单播地址空间，而且在语法上不能与其他地址区别开来。寻址的接口依据其配置确定单播和任一广播地址之间的差别。 通常，节点始终具有链路-本地地址。它可以具有站点-本地地址和一个或多个全局地址。 IPv6路由 IPv6 的优点之一就是提供灵活的路由机制。由于分配 IPv4 网络 ID 所用的方式，要求位于 Internet 中枢上的路由器维护大型路由表。这些路由器必须知道所有的路由，以便转发可能定向到 Internet 上的任何节点的数据包。通过其聚合地址能力，IPv6 支持灵活的寻址方式，大大减小了路由表的规模。在这一新的寻址结构中，中间路由器必须只跟踪其网络的本地部分，以便适当地转发消息。 邻居发现 邻居发现提供以下一些功能： 路由器发现。这允许主机标识本地路由器。 地址解析。这允许节点为相应的下一跃点地址，解析链路层地址（替代地址解析协议 [ARP]）。 地址自动配置。这允许主机自动配置站点-本地地址和全局地址。 邻居发现将 Internet 控制消息协议用于 IPv6 (ICMPv6) 消息，这些消息包括： 路由器广告。在伪定期的基础上或响应路由器请求由路由器发送。IPv6 路由器使用路由器广告来公布其可用性、地址前缀和其他参数。 路由器请求。由主机发送，用于请求链路上的路由器立即发送路由器广告。 邻居请求。由节点发送，以用于地址解析、重复地址检测，或用于确认邻居是否仍可访问。 邻居广告。由节点发送，以响应邻居请求或通知邻居链路层地址中发生了更改。 重定向。由路由器发送，从而为某一发送节点指示指向特定目标的更好的下一跃点地址。 IPv6自动配置 IPv6 的一个重要目标是支持节点即插即用。也就是说，应该能够将节点插入 IPv6 网络并且不需要任何人为干预即可自动配置它。 自动配置的类型 IPv6 支持以下类型的自动配置： 全状态自动配置。此类型的配置需要某种程度的人为干预，因为它需要动态主机配置协议来用于 IPv6 (DHCPv6) 服务器，以便用于节点的安装和管理。DHCPv6 服务器保留它为之提供配置信息的节点的列表。它还维护状态信息，以便服务器知道每个在使用中的地址的使用时间长度以及该地址何时可供重新分配。 无状态自动配置。此类型配置适合于小型组织和个体。在此情况下，每一主机根据接收的路由器广告的内容确定其地址。通过使用 IEEE EUI-64 标准来定义地址的网络 ID 部分，可以合理假定该主机地址在链路上是唯一的。 不管地址是采用何种方式确定的，节点都必须确认其可能地址对于本地链路是唯一的。这是通过将邻居请求消息发送到可能的地址来实现的。如果节点接收到任何响应，它就知道该地址已在使用中并且必须确定其他地址。 IPv6 移动性 移动设备的迅速普及带来了一项新的要求：设备必须能够在 IPv6 Internet 上随意更改位置但仍维持现有连接。为提供此功能，需要给移动节点分配一个本地地址，通过此地址总可以访问到它。在移动节点位于本地时，它连接到本地链路并使用其本地地址。在移动节点远离本地时，本地代理（通常是路由器）在该移动节点和正与其进行通信的节点之间传递消息。 IPv4到IPv6的过渡技术 由于Internet的规模以及目前网络中数量庞大的IPv4用户和设备，IPv4到v6的过渡不可能一次性实现。而且，目前许多企业和用户的日常工作越 来越依赖于Internet，它们无法容忍在协议过渡过程中出现的问题。所以IPv4到v6的过渡必须是一个循序渐进的过程，在体验IPv6带来的好处的 同时仍能与网络中其余的IPv4用户通信。能否顺利地实现从IPv4到IPv6的过渡也是IPv6能否取得成功的一个重要因素。 实际上，IPv6在设计的过程中就已经考虑到了IPv4到IPv6的过渡问题，并提供了一些特性使过渡过程简化。例如，IPv6地址可以使用IPv4兼容地址，自动由IPv4地址产生；也可以在IPv4的网络上构建隧道，连接IPv6孤岛。目前针对IPv4-v6过渡问题已经提出了许多机制，它们的实现原理和应用环境各有侧重，这一部分里将对IPv4-v6过渡的基本策略和机制做一个系统性的介绍。 在IPv4-v6过渡的过程中，必须遵循如下的原则和目标： 保证IPv4和IPv6主机之间的互通； 在更新过程中避免设备之间的依赖性（即某个设备的更新不依赖于其它设备的更新）； 对于网络管理者和终端用户来说，过渡过程易于理解和实现； 过渡可以逐个进行； 用户、运营商可以自己决定何时过渡以及如何过渡。 主要分三个方面：IP层的过渡策略与技术、链路层对IPv6的支持、IPv6对上层的影响 对于IPV4向IPV6技术的演进策略，业界提出了许多解决方案。特别是IETF组织专门成立了一个研究此演变的研究小组NGTRANS，已提交了各种演进策略草案，并力图使之成为标准。纵观各种演进策略，主流技术大致可分如下几类： 双栈策略 实现IPv6结点与IPv4结点互通的最直接的方式是在IPv6结点中加入IPv4协议栈。具有双协议栈的结点称作“IPv6/v4结点”，这些结点既可以收发IPv4分组，也可以收发IPv6分组。它们可以使用IPv4与IPv4结点互通，也可以直接使用IPv6与IPv6结点互通。双栈技术不需要构造隧道，但后文介绍的隧道技术中要用到双栈。 IPv6/v4结点可以只支持手工配置隧道，也可以既支持手工配置也支持自动隧道。 隧道技术 在IPV6发展初期，必然有许多局部的纯IPV6网络，这些IPV6网络被IPV4骨干网络隔离开来，为了使这些孤立的“IPV6岛”互通，就采取隧道技术的方式来解决。利用穿越现存IPV4因特网的隧道技术将许多个“IPV6孤岛”连接起来，逐步扩大IPV6的实现范围，这就是目前国际IPV6试验床6Bone的计划。 工作机理：在IPV6网络与IPV4网络间的隧道入口处，路由器将IPV6的数据分组封装入IPV4中，IPV4分组的源地址和目的地址分别是隧道入口和出口的IPV4地址。在隧道的出口处再将IPV6分组取出转发给目的节点。 隧道技术在实践中有四种具体形式：构造隧道、自动配置隧道、组播隧道以及6to4。 TB（Tunnel Broker，隧道代理） 对于独立的v6用户，要通过现有的IPv4网络连接IPv6网络上，必须使用隧道技术。但是手工配置隧道的扩展性很差，TB的主要目的就是简化隧道的配置，提供自动的配置手段。对于已经建立起IPv6的ISP来说，使用TB技术为网络用户的扩展提供了一个方便的手段。从这个意义上说，TB可以看作是一个虚拟的IPv6 ISP，它为已经连接到IPv4网络上的用户提供连接到IPv6网络的手段，而连接到IPv4网络上的用户就是TB的客户。 双栈转换机制（DSTM） DSTM的目标是实现新的IPv6网络与现有的IPv4网络之间的互通。使用DSTM，IPv6网络中的双栈结点与一个IPv4网络中的IPv4主机可以互相通信。DSTM的基本组成部分包括： DHCPv6服务器，为IPv6网络中的双栈主机分配一个临时的IPv4全网唯一地址，同时保留这个临时分配的IPv4地址与主机IPv6永久地址之间的映射关系，此外提供IPv6隧道的隧道末端（TEP）信息； 动态隧道端口DTI：每个DSTM主机上都有一个IPv4端口，用于将IPv4报文打包到IPv6报文里； DSTM Deamon：与DHCPv6客户端协同工作，实现IPv6地址与IPv4地址之间的解析。 协议转换技术 其主要思想是在V6节点与V4节点的通信时需借助于中间的协议转换服务器，此协议转换服务器的主要功能是把网络层协议头进行V6/V4间的转换，以适应对端的协议类型。 优点：能有效解决V4节点与V6节点互通的问题。 缺点：不能支持所有的应用。这些应用层程序包括：① 应用层协议中如果包含有IP地址、端口等信息的应用程序，如果不将高层报文中的IP地址进行变换，则这些应用程序就无法工作，如FTP、STMP等。② 含有在应用层进行认证、加密的应用程序无法在此协议转换中工作。 SOCKS64 一个是在客户端里引入SOCKS库，这个过程称为“socks化”（socksifying），它处在应用层和socket之间，对应用层的socket API和DNS名字解析API进行替换； 另一个是SOCKS网关，它安装在IPv6/v4双栈结点上，是一个增强型的SOCKS服务 器，能实现客户端C和目的端D之间任何协议组合的中继。当C上的SOCKS库发起一个请求后，由网关产生一个相应的线程负责对连接进行中继。SOCKS库与网关之间通过SOCKS（SOCKSv5）协议通信，因此它们之间的连接是“SOCKS化”的连接，不仅包括业务数据也包括控制信息；而G和D之间的连接未作改动，属于正常连接。D上的应用程序并不知道C的存在，它认为通信对端是G。 传输层中继（Transport Relay） 与SOCKS64的工作机理相似，只不过是在传输层中继器进行传输层的“协议翻译”，而 SOCKS64是在网络层进行协议翻译。它相对于SOCKS64，可以避免“IP分组分片”和“ICMP报文转换”带来的问题，因为每个连接都是真正的 IPV4或IPV6连接。但同样无法解决网络应用程序数据中含有网络地址信息所带来的地址无法转换的问题。 应用层代理网关（ALG） ALG是Application Level Gateway的简称，与SOCKS64、传输层中继等技术一样，都是在V4与V6间提供一个双栈网关，提供“协议翻译”的功能，只不过ALG是在应用层 级进行协议翻译。这样可以有效解决应用程序中带有网络地址的问题，但ALG必须针对每个业务编写单独的ALG代理，同时还需要客户端应用也在不同程序上支 持ALG代理，灵活性很差。显然，此技术必须与其它过渡技术综合使用，才有推广意义。 过渡策略总结 双栈、隧道是主流 所有的过渡技术都是基于双栈实现的 不同的过渡策略各有优劣、应用环境不同 网络的演进过程中将是多种过渡技术的综合 根据运营商具体的网络情况进行分析 由不同的组织或个人提出的IPV4向IPV6平滑过渡策略技术很多，它们都各有自己的优势和缺陷。因此，最好的解决方案是综合其中的几种过渡技术，取长补短，同时，兼顾各运营商具体的网络设施情况，并考虑成本的因素，为运营商设计一套适合于他自己发展的平滑过渡解决方案。