Re: IPv6 Flow Label

[Hesham Soliman <hesham@elevatemobile.com>]

Philip, 

> I would prefer that this thread not dissolve into a debate on whether
> or not there will be NATs in IPv6 networks. I would also prefer that
> this thread not discuss scenarios in which TURN might or might not be
> used in IPv6 scenarios.  If you wish, let's discuss these on other
> threads.
> 
> In this thread, I would like to start with the assumption that TURN
> _is_ being used to relay IPv6 to IPv6.  IF this is done, then what is
> the appropriate treatment for the flow label field?

=> I think it is perfectly valid to question the scenario since you're
asking us about what needs to be done in that scenario. Bottom line, if
you're overwriting IPv6 addresses, it doesn't matter what you do with the
flow label because you already broke it.

> 
> Right now, I see two alternatives:
> 
> 1) Copy the flow label from the incoming packet to the outgoing packet
> if possible. If not possible (because the appropriate APIs do not
> exist on the OS on which the TURN server runs to allow the incoming
> flow label to be read), then treat each (client, peer) combination as
> defining a flow and assign unique flow labels correspondingly.
> 
> 2) Always set the outgoing flow label to 0.

=> If the addresses are being overwritten then 1) makes no sense and 2)
implies breaking the glow label use anyway.

Hesham


> 
> (See previous messages in this thread for more details).
> 
> If it helps the discussion, think about replacing the TURN server with
> any middleware box that modifies addresses (for example, an SIP
> Session Border Controller). I think the question is the same.
> 
> I would greatly appreciate help for folks familiar with the IPv6 flow
> label in making a decision between the two alternatives.
> 
> - Philip
> 
>