Brian E Carpenter wrote:
>> That must be why there are QoS indicators in the L4 header.
>>
>> Oh, wait - those are in L3 (RFC2474 and its successors).
>>
>> Yes, layering is a difficult concept.
>
> That's also why the IPv6 flow label is recommended to be a hash
> of layer 3 and layer 4 information
> (RFC 6437, yes, it took us some years to get that ~right).
Get that right? Or, is "~" a symbol of logical negation?
The RFC is a complete mess, in various ways. It says flow IDs are
good because it is random, but, at the same time, it says flow
IDs may not be random. It also says flow ID must not be changed
but may be changed.
The most obvious defect can be seen here:
As a general practice, packet flows should not be reordered,
which is subtly wrong (order of consecutive packets may sometimes
be exchanged without harming TCP performance), but badly
contradicts with:
* A forwarding node might use the 5-tuple to define a flow
whenever possible but use the 2-tuple when the complete 5-tuple
is not available. In this case, unfragmented and fragmented
packets belonging to the same transport session would receive
different flow label values, altering the effect of subsequent
load distribution based on the flow label
and, another option of:.
* A forwarding node might use the 2-tuple to define a flow in all
cases. In this case, subsequent load distribution would be
based only on IP addresses.
is not a efficient way of load balancing.
So, sane implementers of load distributors will ban packets with
extension headers and/or fragmentation to keep relying on 5-tuples.
Oh, and you are one of a editor of the mess. Thank you very much for
contributing to the collective stupidity to make simple things
unusably complex.
Masataka Ohta