QoS for IPv6

QoS for IPv6 works almost identically to IPv4. The IPv6 header has a Traffic Class field which is identical to the IPv4 DiffServ Field.

Below, the DSCP value in the IPv6 packet has been set to EF. The IPv6 Traffic Class field is 8 bits in length. The first six bits are used for the DSCP value, and the last two bits are used for ECN.

This is identical to the IPv4 Differentiated Services Field, shown below for reference:

MPLS EXP Mapping

Just like IPv4 traffic, when an MPLS label stack is imposed on an IPv6 packet, the IPP (first three bits of the DSCP value) are mapped to the EXP value by default. You can think of the MPLS EXP interaction with IPv6 as identical to how IPv4 works.

Matching/Marking IPv6 Traffic Class

The classification and marking commands for IPv6 are the exact same as the commands you use for IPv4.

The classification command for matching IPP or DSCP works for both IPv4 and IPv6 traffic.

R1(config)#class-map example
R1(config-cmap)#match ?
  <snip>
  dscp                 Match DSCP in IPv4 and IPv6 packets
  <snip>
  precedence           Match Precedence in IPv4 and IPv6 packets

Likewise, marking the IPP or DSCP value of an IPv6 packet uses the same command as for IPv4 packets.

R1(config)#policy-map example
R1(config-pmap)#class class-default
R1(config-pmap-c)#set ?
  dscp           Set DSCP in IP(v4) and IPv6 packets
  precedence     Set precedence in IP(v4) and IPv6 packets

IPv6 Flow Label

The only difference between IPv4 and IPv6, in terms of QoS, is that IPv6 has a flow label field. This is 20 bits and is placed directly after the Traffic Class field.

As far as I can tell, this is not intended to be used for QoS these days. Therefore it is a little strange that this field is listed on the SPCOR blueprint in section 1.4.e under Describe QoS Architecture.

Originally, this field does appear to have been intended for QoS. RFC2460, publicished in 1998, says this about the Flow label:

   The 20-bit Flow Label field in the IPv6 header may be used by a
   source to label sequences of packets for which it requests special
   handling by the IPv6 routers, such as non-default quality of service
   or "real-time" service.  This aspect of IPv6 is, at the time of
   writing, still experimental and subject to change as the requirements
   for flow support in the Internet become clearer.

However, the flow label was never really implemented for QoS. We have more than enough DSCP values to use for traffic that requires special QoS treatment.

RFC6437, published in 2011, is specifically about the IPv6 Flow Label. In this RFC, the purpose of the Flow label is defined as the following:

   The usage of the Flow Label field enables efficient IPv6 flow
   classification based only on IPv6 main header fields in fixed
   positions.

This makes much more sense. A flow label can simply identify a flow, instead of a router needing to match flows based on identical layer 3 and layer 4 information. The router can more efficiently hash flows for ECMP by only reading the flow label. In fact, RFC6437 makes no mention of QoS at all!

Additionally, the flow label cannot be matched or marked using the MQC on IOS. So it is pretty clear that the flow label is not a QoS mechanism, and instead it is used as an ECMP mechanism to ease the burden of flow classification on routers.

Further Reading

https://www.rfc-editor.org/rfc/rfc6437

https://ccie-or-null.net/tag/ipv6-flow-label/

https://www.youtube.com/watch?v=b0CRjOpnT7w&ab_channel=NANOG