[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Flow Label
On 2008-05-07 06:35, Philip Matthews wrote:
> 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?
>
> 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.
I'm disturbed by the idea of copying the label. The rules
were designed in such a way that the 3tuple {DA, SA, flow label}
is bound to be unique, without any signaling, so that flows can
always be identified by any router they happen to go through.
So I think that any relay device that is not a simple packet
forwarder should assign a new flow label, to guarantee that
uniqueness.
>
> 2) Always set the outgoing flow label to 0.
This is a subset of "assign a new flow label". Zero is always
allowed.
The rules in RFC3697 were intended to make the flow label's
semantics robust even when there are different use cases
operating simultaneously. It could be the case (I'm making
this up) that the originating host wants to use flow labels
to support load-spreading, and the TURN relay wants to use
flow labels to support some future QOS mechanism. "Assign
a new flow label" works well in that case.
So, I'd say that the default behavior for a relayed packet
should be "Assign 0", and "Assign a new flow label according to
RFC3697" should be optional (just as the whole of RFC3697 is optional).
And this is entirely independent of whether or not the incoming
packet has a non-zero flow label.
(The same is not true of the DSCP. There's every reason that should
be copied as-is. But I expect you know that.)
Brian
>
> (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
>
>
>