Re: IPv6 Flow Label

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-05-06 13:20, Philip Matthews wrote:
> 
> On Mon, 5-May-08, at 17:23 , Brian E Carpenter wrote:
>> On 2008-05-06 01:21, Philip Matthews wrote:
>>>
>>> On Mon, 5-May-08, at 08:33 , Rémi Després wrote:
>>>> Rémi Denis-Courmont a écrit :
>>>>> Le Friday 02 May 2008 22:16:02 ext Philip Matthews, vous avez écrit :
>>>>
>>>>>> TURN-08 will say that a server should copy the flow label, and if
>>>>>> this
>>>>>> cannot be done, then treat the packets to/from each peer as a
>>>>>> separate
>>>>>> flow with separate labels. This is all part of the new concept of a
>>>>>> Preserving allocation (what I called a "Fully-Compliant
>>>>>> allocation" in
>>>>>> Philly) that I am in the process of adding right now.
>>>>> I myself am not sure what the "proper" handling of the flow infos is.
>>>>> If anyone knows, that would be some 6man and/or v6ops people (not
>>>>> including me). Flow infos is not just like DSCP. Reflecting this, the
>>>>> Linux(-specific) API for flow infos is completely different from that
>>>>> of DSCP and TTL...
>>>>
>>>> Pending any approved use of flow labels, there is IMU only one
>>>> consistent behavior, everywhere: the flow label field MUST be ignored
>>>> when received, and MUST be set to 0 when created .
>>>>
>>>> If and when some use is approved, it will be time to decide whether,
>>>> in TURN in particular, another behavior is more appropriate.
>>>
>>>
>>> What about RFC 3697 ??
>>> Are you saying that this does not describe approved behavior?
>>
>> It does, of course. So the rule is really only that the flow label
>> must be delivered *exactly* as it was set by the source host (and the
>> default setting is zero).  TURN has to obey that rule like any other
>> device that forwards packets.
>>
> 
> For the folks in V6OPS, let me describe the situation more precisely. A
> TURN server receives packets from a TURN client and relays them toward a
> TURN peer. In the process, the server changes both the source and
> destination address. Packets can also flow in the reverse direction.
> 
> For the IPv6 flow label, the best solution as far as I can see, is to
> copy the flow label from the incoming packet to the outgoing packet.
> This seems the right thing to do, even though the source and destination
> addresses change. Since the addresses change, it is possible that two
> logically distinct flows that originally had distinct 3-tuples (source
> IP, dest IP, flow label) before reaching the server get assigned the
> same 3-tuple after relaying. However, as far as I can see, having the
> same 3-tuple does not means the packets ARE part of the same flow, but
> just that they MAY be part of the same flow.
> 
> Copying the flow label and other fields in the IP header requires
> special privileges on most modern OSes (e.g. RAW sockets or kernel
> access). So TURN also allows a mode where fields in the IP header are
> not copied, but are set as best as possible using unprivileged user-land
> APIs. I am not sure what the situation is for the flow label, but for
> many other IP header fields, it is easy to set these fields on outgoing
> packets, but impossible to read them on incoming packets. So a somewhat
> less desirable but acceptable solution when relaying the flow label, as
> I can see, is to assume all the packets coming from a given client and
> going to a given peer constitute a distinct flow and thus assign them a
> unique flow label after relaying the packets. And similarly in the
> opposite direction.
> 
> Comments?

My comment is that there's never a valid reason to rewrite IPv6 addresses
on the fly, so I don't see why the problem arises. I don't understand
the context in which TURN would face this problem, therefore. If you
terminate one IPv6 packet flow and originate another one carrying the
same application data, that makes two independent flows and they should
have independent flow labels.

   Brian