Introduction.

Every IPv6 packet carries 28 bits of flow information. RFC2460 splits these bits to two fields: 8 bits of traffic class (or DS field, if you prefer this term) and 20 bits of flow label. Currently there exist no well-defined API to manage IPv6 flow information. In this document I describe an attempt to design the API for Linux-2.2 IPv6 stack.

The API must solve the following tasks:

1. To allow user to set traffic class bits.

2. To allow user to read traffic class bits of received packets. This feature is not so useful as the first one, however it will be necessary f.e. to implement ECN [RFC2481] for datagram oriented services or to implement receiver side of SRP or another end-to-end protocol using traffic class bits.

3. To assign flow labels to packets sent by user.

4. To get flow labels of received packets. I do not know any applications of this feature, but it is possible that receiver will want to use flow labels to distinguish sub-flows.

5. To allocate flow labels in the way, compliant to RFC2460. Namely:
   • Flow labels must be uniformly distributed (pseudo-)random numbers, so that any subset of 20 bits can be used as hash key.

   • Flows with coinciding source address and flow label must have identical destination address and not-fragmentable extensions headers (i.e. hop by hop options and all the headers up to and including routing header, if it is present.)

     1cm NB. There is a hole in specs: some hop-by-hop options can be defined only on per-packet base (f.e. jumbo payload option). Essentially, it means that such options cannot present in packets with flow labels.

     1cm NB. NB notes here and below reflect only my personal opinion, they should be read with smile or should not be read at all :-).

   • Flow labels have finite lifetime and source is not allowed to reuse flow label for another flow within the maximal lifetime has expired, so that intermediate nodes will be able to invalidate flow state before the label is taken over by another flow. Flow state, including lifetime, is propagated along datagram path by some application specific methods (f.e. in RSVP PATH messages or in some hop-by-hop option).