Re: Is Fragmentation at IP layer even needed ?

[Masataka Ohta <[e-mail]>]

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