Re: IPv6 Flow Label

[Hesham Soliman <hesham@elevatemobile.com>]

>> 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.

=> I completely agree. Philip, it might help if you explain why this need
arises for IPv6. What is the scenario?

Hesham

> 
>    Brian
> 
>