流标签规范定义了流以及与流标签有关的一些基本规范，同时提出了不少建议草案。这里摘要简单介绍。

流是从某一源节点发往某一单播、任播或组播地址的目的节点的一系列包。源节点用流标签标识一个流。一个具体的传输连接或媒体流中的所有包都属于一个流。当然，并非一个流必须和一个传输连接 1:1对应。

流标签在高效处理方面具有特别的优势。和五元组相比，IPv6的源地址、目的地址以及流标签都出现在基本报头中。而五元组则由于或者是报文的分段，或者是加密，或者是协议在多个扩展的报头之后才可以取得，因此在处理的效率上要差一些。

当然，由于流标签处在一个非常暴露的位置，在抵抗服务盗用以及DoS(拒绝服务)攻击方面比较脆弱，需要一定的措施来保护。一般需要一个比较信任的环境，或者启用入境(ingress)过滤等防范措施。

现在，流标签规范还只是一个框架，并没有对流标签的使用做出明确的定义，只规定了一些非常原则的内容，主要包括：(1)IPv6流支持的最低要求是标记流(给流打标签)。流标签应该由流的发起者信源节点赋予一个流。流标签是一个1-FFFFF的伪随机数。对那些不支持流标签处理的节点和应用应将FL置成0，或者不对该字段进行处理。(2)源节点应该能够为流选择没有用过的流标签值。当新建流时，源节点必须保证它不会无意识地重用当前正用或是最近刚用过的流标签值。也就是说，新建同一源地址和目的地址之间的流，不能用之前120s之内用过的流标签值。对于各自不同的流，源节点应该能够提供方法，为应用和传输协议指定留验期长于120s。(3)为了避免由于系统每次重新启动而意外地重用流标签值，初始值应该能够从存储在非易失性存储器里的上一次流标签值导出，如果这些历史数据也丢失了，则用一个好的随机数算法产生一个随机初始值。(4)流状态的建立方式必须满足的最低要求是，提供具体流处理功能的IPv6节点具有清理流状态的手段;当请求的流状态节点不能支持时，流状态建立方法必须能够恢复，从而保证不同的方法可以被使用。

当然，对流标签的定义和使用还提出了不少草案。例如，将20位进一步细分为3+17位，前3位可以定义为支持诸如Diff-Serv、Int-Serv等几种类别，后17位则根据前面定义的类别再定义相应的功能或者应用。这里不详细介绍。

IPv6 QoS信令扩展

QoS信令是目前研究的热点之一，也是支持端到端QoS技术的一个重要方面。从技术的角度看，可以支持带内或者带外的信令。RSVP和802.1p分别是一个示例。但如前所述，RSVP可能并不适合在Internet这种大规模的网络中使用。

IPv6可以比较方便地支持QoS信令的实现，具体的做法是，根据IPv6的Hop by Hop扩展头对信令进行定义。由于每个IPv6节点都必须处理Hop by Hop扩展头，这样就可以实现QoS信令。即通过在数据流的第一个数据包中携带有关信息，在经过逐跳处理和预留以后到达接收端，接收端根据情况将有关信息回传发送方，这样就可以进行有QoS保证的数据发送了。

QoS信令的定义还处于探讨阶段，具体的内容包括可用带宽、保证带宽、优先级以及与报文处理有关的一些定义字段等。

IPv6 QoS实现方案

IPv6 QoS的实现可以在不同层面进行。例如网络应用，可以通过流量类别字段和/或流标签字段提出QoS要求，也可以在用户接入的服务提供商(SP)网络边缘节点对用户业务进行标识。当然，这里涉及服务提供商和用户之间的QoS/SLA协商，以及据此制定的服务策略。最关键之处还在于网络设备，必须可以根据这些业务要求完成相应的处理并保证QoS。需要说明的是，在IPv6 QoS信令实现比较成熟的情况下，网络应用还可以通过信令和网络进行协商，实现动态的QoS处理。

图2简单示意了IPv6 QoS的实现方案，实际的网络可能更复杂一些。处于服务提供商网络边缘的支持QoS的节点与最终客户之间，可能有一个宽带接入网络，其QoS也是问题的一个部分，但可以通过一定的带宽集中方式获得保证。这里不讨论。

图2示出了对网络应用进行QoS处理的两种情况：支持QoS的标记和在服务提供商网络边缘对不同的应用流重新进行标记。但从网络运营的角度看，在网络边缘进行标记处理更加合理。这一方面有利于用户和服务提供商之间的协商;另一方面有利于服务提供商验证用户的标记是否与其SLA相一致，以阻断用户私自提高服务等级等情况的发生。而在网络的核心，通过和边缘配合的方法实现具体的QoS处理。