《IPv6精髓(第2版)》——6.2 IPv6协议中的QoS-阿里云开发者社区

开发者社区> 安全> 正文
登录阅读全文

《IPv6精髓(第2版)》——6.2 IPv6协议中的QoS

简介:

本节书摘来自异步社区《IPv6精髓(第2版)》一书中的第6章,第6.2节,作者: 【美】Silvia Hagen 更多章节内容可以访问云栖社区“异步社区”公众号查看。

6.2 IPv6协议中的QoS

IPv6的设计者并没有将注意力放在制定特殊的QoS机制上,而是放在了如何尽可能灵活地支持各种QoS机制上。本节将描述IPv6报头以及扩展报头中与QoS服务相关的内容。
**
6.2.1 IPv6报头**
IPv6报头中有两个字段用于提供QoS服务:流量类别(Traffic Class)字段和流标签(Flow Label)字段。

1.流量类别
1字节流量类别字段的使用规范定义在RFC 2474中。如前所述,该RFC为流量类别字段引入了术语“DS字段”。该规范的目标是让DiffServ路由器有一组已知的DS样例,这些样例由DS字段值来确定,可以根据性能或者类别将这些DSCP值映射到PHB。DS字段的格式如图6-1所示。


<a href=https://yqfile.alicdn.com/9bfd134ae29fdc5f3548aa0be0f9b20d096b62ed.png" >

DS字段中的DSCP字段(是DS字段中6个最高有效比特)被用作代码点,这些代码点规定了PHB。DSCP字段可以规定64个不同的代码点。该代码点池被分为三部分以控制PHB的分配。表6-1列出了DSCP池的划分情况。


9ebd7efd2ecbe4433d16d6602a1ea2f3224db22a

32个建议代码点池(池1)通过正式标准进行分配;其次的16个代码点池(池2)被保留给实验使用或本地使用;最后的16个代码点池(池3)最初归实验使用或本地使用,但是在未来池1用完后,它(池3)将作为溢出池使用。

PHB规定了数据包的转发方式。所有DS路由器都必须支持默认PHB(由全0的DS代码点来表示)。默认PHB描述的是目前路由器上最常见的尽力而为型转发行为。转发这类数据包时无需遵循任何优先级策略,也就是说,网络将根据现有的资源(如内存或处理能力)状况,尽快尽可能多得传送这些数据包。如果收到的数据包携带的是未定义的代码点,那么也将按照默认行为来转发这些数据包。

DS字段并不规定PHB,而只是规定代码点。代码点的数量被限定为64个,而PHB的数量并没有任何限制。代码点与PHB之间有推荐的映射关系。也可以在管理域内单独定义这些映射关系,使得PHB的不受任何数量的限制。RFC 3140“Per Hop Behavior Identification Codes”定义了PHB ID的编码规则。RFC 2597定义了一组被称为AF(Assured Forwarding,确保转发)的PHB。RFC 3246则定义了一个被称为EF(Expedited Forwarding,快速转发)的PHB。

图6-2显示了追踪文件中的DS字段信息。


f56c2dbfab23fb5d1da9f8413853d29f85aa6e07

这是来自Cisco路由器的RIPng(RIP Next Generation,下一代RIP)响应消息。该消息发送给RIP路由器多播地址FF02::9,其中的DS字段被设置0xE0(即十进制224,二进制1110 0000),这是由优先转发的Sniffer解码得到的。

根据RFC 2474,DS字段的剩余两个比特没有使用,后来由RFC 3168“The Addition of Explicit Congestion Notification (ECN) to IP”对这两个比特做了规定。它们可以为拥塞指示(Congestion Notification)提供4种可能的代码点(00~11)。通常我们通过路由器的丢包情况来判断路由器是否过载。有了拥塞指示代码点之后,路由器就可以在丢包之前发出过载指示。该方法类似于帧中继的BECN(Backwards Explicit Congestion Notification,后向显式拥塞指示)和FECN(Forwards Explicit Congestion Notification,前向显式拥塞指示)。

  • 这两个比特的使用情况如下。
  • 00:数据包未使用ECN;
  • 01/10:发送端和接收端开启了ECN功能;
  • 11:路由器发出拥塞指示。

2.流标签
源端可以利用IPv6报头中的20比特流标签字段来标记数据包,以请求IPv6路由器对数据包进行特殊处理,如非默认的QoS或实时业务。由流的源节点负责将流标签分配给流。发送端与接收端之间可能并行存在多个有效流,并相互交换一些无QoS需求的数据包。新的流标签必须从00001~FFFFF之间进行随机选择,随机分配的目的是确保流标签字段中的任意比特组合都能被路由器用作散列密钥,以查找与特定流相关联的状态。

对于不支持流标签字段功能的主机和路由器来说(目前的大多数应用都不需要修改以使用流标签,或者根本就不需要QoS处理),在发送数据包时需要将该字段设置为全0,在转发数据包时需要保持该字段不变,在收到数据包后直接忽略该字段的内容。

属于同一个流的所有数据包都必须以相同的IP源地址和IP目的地址、相同的源端口和目的端口以及非零的流标签进行发送。如果其中的某些数据包携带了逐跳选项报头,那么就必须让所有的数据包都携带相同内容的逐跳选项报头(逐跳选项报头中的下一报头字段除外,因为该字段可以不一样)。如果其中的某些数据包携带了路由选项报头,那么就必须让所有的数据包都携带相同内容的路由扩展报头以及路由扩展报头之前的所有其他扩展报头(同样,路由扩展报头中的下一报头字段除外)。允许路由器或接收端验证是否满足这些条件,如果发现与这些一致性规则相冲突,那么就会返回相应的差错消息,指出与规则不一致的确切位置。

路由器可以有效地处理流标签,在使用IPSec的时候,由于ESP不会加密IPv6报头,AH(工作于传输模式下)也不会认证IPv6报头,因而流标签始终可用。但这也意味着DS字段中的信息的完整性将得不到IPSec的安全保障。

RFC 3697“IPv6 Flow Label Specification”是一个新的流标签规范,其中的流(flow)被定义为由发送端发送给指定单播地址、任播地址或多播地址的一串数据包,由发送端将其标记为一个流。流不需要与传输连接相关联。对于与其他主机运行多个会话的主机来说,应该能够为每个会话分配不同的流标签。最初的规范基于五元组来定义流,而新规范则基于三元组(源地址、目的地址和流标签)来定义流。这样做的原因是路由器始终都能检查这三个字段,而源端口号和目的端口号会被ESP隐藏起来。

6.2.2 IPv6扩展报头
如前所述,IPv6定义了两种扩展报头来满足QoS需求。

路由扩展报头通过指示一系列需要使用的节点来请求指定路由(也就是IPv4中的松散源路由)。但是在使用路由扩展报头时,要求请求方必须知道首选路由(即网络拓扑以及与QoS相关的参数,如可能的吞吐量)。为了防范针对路由系统的攻击行为,在收到包含路由报头的数据包之后,除非能够验证所接收到的源IP地址和路由报头的完整性和真实性(如通过所接收到的数据包中的认证扩展报头),否则在发送的响应包中不必包含路由报头。其中,该路由报头是通过“反转”所接收到的路由报头(就像IPv4松散源路由中常常实施的那样)得到的。

逐跳选项报头可以将路由器告警信令消息(每个IP包最多一条,RFC 2711)传送到QoS敏感型流量承载路径上的每一台路由器,要求每一台路由器都必须对该IP包实施特殊处理。使用逐跳选项报头时,由于不需要分析高层协议报头,因而路由器能够快速处理该扩展报头。对于无法识别路由器告警选项的路由器来说,必须忽略该选项并继续处理该报头。此外,数据包在传送过程中,不允许路由器更改该选项。目前已定义的路由器告警类型如表6-2所示。


<a href=https://yqfile.alicdn.com/96fec0eb54b83a0d4696d63799116f3cec94de3f.png" >

6.2.3 6LSA
6LSA(IPv6 Label Switch Architecture,IPv6标签交换体系架构)是一种新的流标签字段使用建议,提出了新的流标签字段使用方法,描述了6LSA体系架构,并讨论了数据包与FEC(Forwarding Equivalence Classes,转发等价类)的绑定方法。

6LSA架构在很多方面都与MPLS(Multiprotocol Label Switching,多协议标签交换)类似。6LSA将标签分配给IPv6包,然后利用标签为数据包在6LSA域内提供QoS服务,不过,6LSA使用流标签字段来携带标签信息,而不是shim(垫层)字段,因而可以避免分段操作和某些性能问题,并且可以为QoS提供端到端的三层标签。

6LSA架构是一个非常新的概念,在最终定案之前还需要经过IETF的同行审查。最终能否被接受并得到部署目前还是一个未知数,不过6LSA的制定工作是一个非常好的指示信号,表示IPv6的QoS团体仍在研究更好的QoS模型。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: