ipv6协议.htm

internet协议集

      width=482></P>
      <P align=justify>不可分片部分包括IPv6首部，以及那些必须由路由中的节点处理的扩展首部。也就是以下三种情况: 
      所有路由首部以前(含路由首部)的首部(如果存在的话),或者是 Hop-by-Hop 
      选项首部(如果存在的话)，或者没有扩展首部。包中其余的部分为可分片部分，也就是只需由包的最终目的节点处理的扩展首部，以及上层协议首部和数据。原包中可分片部分被划分成若干分片，除去最后("最右")一个分片，每个分片都为8 
      个八位组的整数倍长。这些分片由相互独立的"分片包"来传送，如下例所示:</P>
      <P align=justify>原包:</P>
      <P align=center><IMG height=67 alt=原包 src="IPv6协议.files/IPv6-11.gif" 
      width=483></P>
      <P align=justify>分片包:</P>
      <P align=center><IMG height=269 alt=分片包 src="IPv6协议.files/IPv6-12.gif" 
      width=320></P>
      <P align=justify>每个分片包由下述几部分构成:</P>
      <P align=justify>(1) 原包中的不可分片部分。其中原来IPv6首部中有效数据长度值只应包含本分片包的长度 
      (不包含IPv6首部自身的长度)。不可分片部分中最后一个首部的"下一个首部"字段值改为 44。</P>
      <P align=justify>(2) 分片首部。其中包括:其"下一个首部"值标识原包中可分片部分的第一个首部。其分片偏移量字段 包含以 8 
      个八位组为单位的，本分片相对于原包中可分片部分开始位置处的偏移量。第一个("最左")分片的分片偏移量为 0。其 M 标志位为 0 
      表示这是最后("最右")一个分片，否则 M 标志位为 1。其标识值依原包产生。</P>
      <P align=justify>(3) 分片自身</P>
      <P align=justify>分片的长度应使分片包的大小适于去往目的节点的路径 
      MTU。在目的节点，分片包重组为原来未分片的形式，如下例所示:</P>
      <P align=justify>重组的原包:</P>
      <P align=center><IMG height=73 alt=重组的原包 src="IPv6协议.files/IPv6-14.gif" 
      width=494></P>
      <P align=justify>重组应遵循如下原则:</P>
      <P 
      align=justify>原包只能由具有相同源地址，目的地址和分片标识的分片包重组。重组后的包中的不可分片部分由第一个分片包(也就是分片偏移量为 
      0 
      的那个包)中分片首部前面所有的首部(不含分片首部)组成，并作如下两处修改:从第一个分片的分片首部中的"下一个首部"字段得到不可分片部分最后一个首部中的"下一个首部"字段值。由不可分片部分的长度及最后一个分片的长度和偏移量计算出重组包的有效数据长度。计算重组包的有效数据长度的公式为:</P>
      <P align=justify>PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + 
      FL.last</P>
      <P align=justify>PL.orig = 重组包的有效数据长度字段。<BR>PL.first = 
      第一个分片包的有效数据长度字段。<BR>FL.first = 第一个分片包中分片首部后面的分片长度。<BR>FO.last = 
      最后一个分片包中分片首部的分片偏移量字段。<BR>FL.last = 最后一个分片包中分片首部后面的分片长度。</P>
      <P 
      align=justify>重组包的可分片部分由各分片包中分片首部后面的分片组成。各分片的长度可由分片包的有效数据长度减去此包中IPv6首部与分片之间所有首部的长度计算得到。各分片在可分片部分中的相对位置由其分片偏移量值计算得到。最终重组后的包不含分片首部。包的重组过程可能出现下列错误情形：</P>
      <UL>
        <LI>如果收到包的第一个(到达的)分片之后 60 
        秒内没有收到全部分片以完成重组,那么必须终止这次重组，抛弃所有已收到的包。如果收到了第一个分片 
        (也就是分片偏移量为零的那个分片)，应给分片的源节点发送一个 ICMP "超时 -- 分片重组超时"报文。 </LI></UL>
      <UL>
        <LI>如果由分片包的有效数据长度字段得到的分片长度不是 8 个八位组的整数倍,而且分片的 M 标志位被置为 
        1，那么必须抛弃这个分片，并且给分片的源节点发送一个 ICMP "参数存在问题"，编码 0 的报文，指针指向分片包的有效数据长度字段。 
      </LI></UL>
      <UL>
        <LI>如果分片的长度和偏移量使得重组后的包的有效数据长度超过了 65,535 个八位组，那么必须抛弃这个分片，并且向分片的源节点发送一个 
        ICMP "参数存在问题"，编码 0 的报文，指针指向分片包的分片偏移量字段。 </LI></UL>
      <P align=justify>不希望出现下述情形，但不将它们视为错误:</P>
      <UL>
        <LI>同一个原包的不同分片中，分片首部前面的首部在数量和内容上都可能不同。 </LI></UL>
      <UL>
        <LI>当每个分片包到达时，无论分片首部前面的首部是什么，都应在进入分片重组队列之前进行处理。只有分片偏移量为零的那个包中的首部才保留在重组后的包中。 
        </LI></UL>
      <UL>
        <LI>同一个原包的不同分片中，分片首部中"下一个首部"值可能不同。只有分片偏移量为零的那个包中的值才可用于重组。 </LI></UL>
      <P align=justify>4.6 目的地址选项首部</P>
      <P align=justify>目的地址选项首部用于携带只需由包的目的节点检测的可选信息。前面的首部中"下一个首部"字段中的值为 60 
      表示下一个首部为目的地址选项首部。目的地址选项首部具有如下格式:</P></FONT>
      <P align=center><IMG height=124 alt=目的地址选项首部 
      src="IPv6协议.files/IPv6-15.gif" width=463></P>
      <TABLE cellSpacing=1 width="100%" border=1>
        <TBODY>
        <TR>
          <TD vAlign=top width="13%"><FONT face=宋体 size=3>
            <P align=justify>下一个首部</FONT></P></TD>
          <TD vAlign=top width="87%">
            <BLOCKQUOTE><FONT face=宋体 size=3>
              <P align=justify>8 位选择器。标识紧跟在目的地址选项首部后面的首部的类型。使用与 IPv4 
              协议字段相同的数值。</P></FONT></BLOCKQUOTE></TD></TR>
        <TR>
          <TD vAlign=top width="13%"><FONT face=宋体 size=3>
            <P align=justify>首部扩展长度</FONT></P></TD>
          <TD vAlign=top width="87%">
            <BLOCKQUOTE><FONT face=宋体 size=3>
              <P align=justify>8 位无符号整数。以 8 个八位组为单位的目的地址选项首部的长度，不包括开始的 8 
              个八位组。</P></FONT></BLOCKQUOTE></TD></TR>
        <TR>
          <TD vAlign=top width="13%"><FONT face=宋体 size=3>
            <P align=justify>选项</FONT></P></TD>
          <TD vAlign=top width="87%">
            <BLOCKQUOTE><FONT face=宋体 size=3>
              <P align=justify>可变长度字段，其长度须使整个目的地址选项首部的长度为 8 个八位组的整数倍。包含一个或多个 TLV 
              编码的选项，如第 4.2 章中所述。</P></FONT></BLOCKQUOTE></TD></TR></TBODY></TABLE><FONT 
      face=宋体 size=3>
      <P align=justify>在本文中定义的仅有的目的地址选项是填充1 及填充N 选项，如第 4.2 
      章中所述。需要注意的是，有两种途径来编码目的地址的可选信息: 
      或者作为目的地址选项首部中的一个选项，或者作为一个独立的扩展首部。分片首部和认证首部就是后者的典型例子。使用哪种方法取决于目的节点无法识别这一可选信息时，希望采取的措施:</P>
      <P align=justify>o 如果希望节点抛弃这个包，并且当包的目的地址不是组播地址时，给包的源地址发送一个 ICMP 
      "类型无法识别"报文，可以将这一信息编码成独立的扩展首部或者目的地址选项首部中的一个选项，其选项类型的最高两位为 
      11。最终的选择可以根据其他的因素而定，比如哪一个可以使用更少的八位组,哪一个能生成更好的对齐或者具有更高的处理效率。</P>
      <P align=justify>o 如果希望采取其他的措施，那么这一信息必须作为目的地址选项首部的一个选项进行编码。其选项类型的最高两位为 
      00，01 或 10，指定所需采取的措施。</P>
      <P align=justify>4.7 "无下一个首部"</P>
      <P align=justify>IPv6首部或者扩展首部中"下一个首部"的值为 59 
      表示这个首部后面没有其他的首部了。如果IPv6首部中的有效数据字段表明最后一个首部 ("下一个首部"字段为 59 的那个首部) 
      后面还有其他的八位组，那么这些八位组将被忽略，并且在传输过程中保持不变。</P>
      <P align=justify>5. 包的大小问题</P>
      <P align=justify>IPv6要求互联网上的每条链路具有 1280 或更多个八位组的 MTU。无法在一片之内传送 1280 
      个八位组的链路必须根据链路的情况在IPv6下层的协议中提供分片和重组机制。具有可配置 MTU 的链路 (比如 PPP 链路 [RFC-1661]) 
      必须配置为具有至少 1280个八位组的 MTU；建议配置成具有 1500 或更多个八位组的 MTU，这样可以容纳可能的封装 (也就是"通道") 
      而不至于在IPv6协议层分片。与链路直接连接的节点必须能够接收链路 MTU 大小的包。建议IPv6节点使用 "路径 MTU 发现" 技术 
      [RFC-1981]，以发现比 1280 个八位组更大的路径 MTU，并发挥其优点。但是，一个最小的IPv6实现 (比如，在启动 ROM 里) 
      可以简单的限制自己只发送小于 1280 个八位组的包，从而忽略 "路径 MTU 发现" 技术。要发送大于路径 MTU 
      的包，节点可以使用IPv6分片首部，在源节点将包分片，并在目的节点将包重组。但是，如果应用程序能够调整包的大小来适合标准的路径MTU，那么最好不要使用分片。节点必须能够接收重组后大小为 
      1500 个八位组的分片包。同时，允许节点接收重组后大于 1500 个八位组的分片包。基于IPv6分片来发送大于路径 MTU 
      的包的上层协议或应用程序不应发送大于 1500 个八位组的包，除非它确信目的节点能够重组这样大的包。</P>
      <P align=justify>作为发往 IPv4 目的节点的IPv6包 (也就是从IPv6转换成 IPv4 的包) 的响应, 
      IPv6的初始节点可能收到 ICMP "包太大"报文，报告下一跳 MTU 小于 1280。在这种情况下,IPv6节点不必将后续的包的大小减小到 
      1280 以下，但必须在这些包中包含一个分片首部，使得负责从IPv6到 IPv4 之间转换的路由器能够得到一个适当的标识值，用来生成 IPv4 
      分片。需要注意的是，这就意味着有效数据将减小到 1232 个八位组 ( 1280 减去IPv6首部的 40 和分片首部的 
      8)，如果还有其他的扩展首部，有效数据将变得更小。</P>
      <P align=justify>6。数据流标签</P>
      <P align=justify>IPv6首部中 20 
      位的数据流标签字段用于源节点标识那些需要IPv6路由器特殊处理的包的序列，比如非缺省质量的服务或者"实时"服务。本文产生之时，IPv6在这方面尚处于实验阶段，并且随着因特网上支持数据流的要求变得越来越清楚，它还可能有所改变。不支持数据流标签字段功能的主机和路由器应在初始化数据包的时候将此字段设为零，传输包的时候保持不变，接收包的时候忽略。</P>
      <P align=justify>7。传输类别</P>
      <P align=justify>IPv6首部中 8 
      位的传输类别字段可用于初始节点和/或转寄路由器标识和区分不同IPv6包的类别或优先级。撰写本规范的时候，已经总结了在使用 IPv4 
      服务类型和/或优先级位 (用来为 IP 包提供不同形式的"区别服务"，不同于显式的建立数据流) 的过程中的若干经验. 
      IPv6首部中的传输类别字段在IPv6中提供了相似的功能。希望这些经验能够使得人们在哪种传输分类对 IP 
      包最为有用的问题上达成一致意见。对IPv6传输类别中全部或部分数据位的结构和语义的详细定义，或者是实验性的，或者是最终的标准，都将在另外的文章中提供。</P>
      <P align=justify>下面是传输类别字段所应满足的总的要求:</P>
      <P align=justify>o 节点中IPv6服务的服务接口必须为上层协议规定一种给初始包提供传输类别数据位的值的方法。</P>
      <P align=justify>o 支持部分或全部传输类别数据位的某一特定 (实验性的或最终标准) 
      用法的节点可以根据其用法修改它们所生成的，传输的或者收到的包中的这些位的值。如果节点不支持这一用法，应忽略这些位，并保持其值不变。</P>
      <P align=justify>o 上层协议不应假定所收到的包中传输类别数据位的值与源节点发送此包时的值相同。</P>
      <P align=justify>8. 上层协议的问题</P>
      <P align=justify>8.1 上层协议校验和</P>
      <P align=justify>在计算校验和时包含 IP 首部中地址的传输层或其他上层协议必须为通过IPv6进</P>
      <P align=justify>行传输加以相应的改进，将 32 位的 IPv4 地址改为 128 位的IPv6地址。特别</P>
      <P align=justify>地，下面的例子展示了 TCP 和 UDP 的IPv6"伪首部":</P>
      <P align=center><IMG height=233 alt=UDP伪首部 src="IPv6协议.files/IPv6-16.gif" 
      width=465></P>
      <P align=justify>o 
      如果IPv6包包含路由首部，伪首部使用的目的地址就是最终的目的地址。在初始节点，这一地址就是路由首部的最后一个元素；在接收者一方，这一地址在IPv6首部的目的地址字段。</P>
      <P align=justify>o 伪首部中"下一个首部"字段值标识了上层协议的类型 (比如 6 为 TCP，17为 
      UDP)。如果IPv6首部和上层协议首部之间还存在扩展首部，那么伪首部中"下一个首部"字段的值可能与IPv6首部中的值有所不同。</P>
      <P align=justify>o 伪首部中上层协议包的长度是指上层协议的首部和数据 (比如，TCP 首部加上 TCP 
      数据)。一些上层协议携带了自己的长度信息 (比如，UDP 首部中的长度字段)；对于这样的协议，这些信息就是伪首部使用的长度信息。其他协议 (比如 
      TCP) 
      不携带自己的长度信息，在这种情况下，伪首部使用的长度就是IPv6首部中的有效数据长度字段值减去IPv6首部与上层协议首部之间扩展首部的长度。</P>
      <P align=justify>o 与 IPv4 不同的是，当IPv6节点生成 UDP 包时，UDP 校验和不是可选的。也就是说，只要生成 UDP 
      包,IPv6节点必须计算数据包和伪首部的 UDP 校验和。而且，如果计算结果为 0，必须将其改为十六进制的 FFFF，放入 UDP首部. 
      IPv6接收节点必须抛弃包含零校验和的 UDP 包，并记录这一错误。</P>
      <P align=justify>IPv6版本的 ICMP在计算校验和时包含上述的伪首部；这是一个与 IPv4的版本不同的地方 -- IPv4 
      的版本在校验和中不包含伪首部。改变的原因是防止ICMP 发生不正确的传送，以及IPv6首部中的这些字段发生讹误 -- 
      它们没有受到网络层校验和的保护。ICMP 的伪首部中"下一个首部"字段的值为 58，标识IPv6版本的 ICMP。</P>
      <P align=justify>8.2 包的最大生存期</P>
      <P align=justify>与 IPv4 不同的是,IPv6节点不必强制规定一个包的最大生存期。这就是 IPv4 
      中的"生存期"字段在IPv6中改名为"跳数限制"的原因。在实际中，IPv4 
      实现很少强制要求限制包的生存期，所以这一点实际上并没有改变。任何依赖网络层协议 (IPv4 或 IPv6) 
      来限制包的生存期的上层协议必须进行升级，自己提供检测和抛弃过期的数据包的机制。</P>
      <P align=justify>8.3 上层协议的最大有效数据大小</P>
      <P align=justify>当计算可提供给上层协议数据的最大有效数据大小的时候，上层协议必须考虑到IPv6首部比 IPv4 首部大。例如，在 
      IPv4 里，TCP 的 MSS 选项是包的最大尺寸 (缺省值或者由路径 MTU 发现技术提供的值) 减去 40 个八位组 (IPv4 
      首部的最小长度 20 和 TCP 首部的最小长度 20)。当通过IPv6使用 TCP 时，MSS 必须改为包的最大大小减去 60 
      个八位组，这是因为IPv6首部的最小长度 (也就是没有任何扩展首部的IPv6首部) 比 IPv4 首部的最小长度长 20 个八位组。</P>
      <P align=justify>8.4 对携带路由首部的包的响应</P>
      <P 
      align=justify>当上层协议发送一个或多个包，作为包含路由首部的包的响应时，响应包中不能包含由所收到的路由首部"反向"而自动得到的路由首部。除非收到的源地址和路由首部的完整性和可靠性已得到验证 
      (比如通过使用收到的包中的认证首部)。换句话说，只有下面几类包可以响应由路由首部定向的包:</P>
      <P align=justify>o 不携带路由首部的响应包。</P>
      <P align=justify>o 携带路由首部的响应包，但其携带的路由首部不是由所收到的包中的路由首部反向得到的 
      (例如，由本地配置信息提供的路由首部)</P>
      <P align=justify>o 
      携带路由首部的响应包，其路由首部是由所收到的包中的路由首部反向而得到的。但所收到的包中的源地址和路由首部的完整性和可靠性必须经过响应者验证。</P>
      <P align=justify><FONT color=#ff0000>附录 A. 数据流标签字段的语义和用法</FONT></P>
      <P align=justify>数据流是指从某特定的源节点向某特定的 (单播或组播) 
      目的节点发送的数据包的序列。当源节点希望中间的路由器对数据包进行一些特殊处理时，可以使用数据流。这一特殊处理的种类可以由某一控制协议，如资源预约协议，或者由数据流中的包自身中的信息，如在 
      hop-by-hop 
      选项首部里的选项，传达给路由器。关于这样的控制协议或者选项的详细资料已经超出了本文的范围。从源节点到目的节点之间可能有数条活动的数据流，还可能有同任何数据流都无关的业务量。一个数据流由一个源地址和一个非零的数据流标签唯一地标识。不属于任何一个数据流的包具有零值的数据流标签。由数据流的源节点为数据流分配数据流标签。新的数据流标签必须从 
      1 到 FFFF(十六进制) 
      之间伪随机地选出来。随机分配数据流标签的目的是使得路由器能够使用数据流标签字段中的任意一组位作为哈希关键字，用来查询与数据流相关的状态。属于同一数据流的包必须具有相同的源地址，目的地址和数据流标签。如果其中的一些包包含 
      Hop-by-Hop 选项首部，那么它们都必须具有相同内容的 Hop-by-Hop选项首部 (除了 Hop-by-Hop 
      选项首部中的"下一个首部"字段)。如果其中的一些包包含路由首部，那么它们在路由首部之前 (含路由首部) 的所有扩展首部的内容都必须相同 
      (除了路由