Re: draft-wang-6man-flow-label-reflection

[Brian E Carpenter <[e-mail]>]

On 15/11/2014 10:01, Jeroen Massar wrote:
> On 2014-11-14 20:01, Brian E Carpenter wrote:
>> On 15/11/2014 07:33, joel jaeggli wrote:
>>> On 11/14/14 7:52 AM, Sheng Jiang wrote:
>>>> Hi, Jeroen,
>>>>
>>>> We can certainly add some consideration in the future version
>>>> regarding to ICMPv6 and "Packet too big". However, could you be more
>>>> specific what your concern is regarding to ICMPv6 and flow label
>>>> reflection?
>>>>
>>>> BTW, the v6ops draft you mentioned does not have any discussion
>>>> regarding to flow label.
>>> 20 bits alone isn't enough to identify a flow, certainly not when the
>>> source has changed. I have more flows then that on a single path.
>> For load balancing, that doesn't really matter too much, but if you
>> were really trying to identify flows individually, you have to use
>> {src-addr, flow-label} just by the definition of the flow label. With
>> a reflected label that isn't safe, because the rule that the source
>> must ensure that {src-addr, flow-label} is unique cannot be guaranteed
>> by the reflector.
> 
> And also note that any router on the path is allowed (they "MAY") per
> the RFC to overwrite the label if they see fit.

Once the label is set, that is not true (but there is an exception for
paranoid firewalls). In reality the field can be forged, but so can
anything in the IPv6 header.

> The primary use of the Flow Label seems to be Load Balancing, but load
> balancing does not work as doing that based on src/flow-label or just
> flow-label breaks ICMPv6 PTBs.

That case is broken with or without the flow label.

> As such, the primary use case of Flow Labels is broken. Thus making that
> field useless.

No, it's stateless load balancing with fragmentation that's broken.

   Brian