Subject: Re: [BEHAVE] IPv6 Flow Label

From: Hesham Soliman <[email-masked]>
Date: Tue, 06 May 2008 23:20:18 +1000

On 6/05/08 11:16 PM, "Rémi Denis-Courmont" <[email-masked]>
wrote:

> Le Tuesday 06 May 2008 15:52:49 ext Hesham Soliman, vous avez écrit :
>> => I don't know why we're talking about NATs and IPv6. It sounds like a
>> flawed assumption from the beginning.
>> There are two situations I can think of that you might be referring to (I
>> haven't read TURN since 2004)
>> 1. Two connections, node - TURN relay and TURN relay - another node. I have
>> a feeling this is not the case you have in mind.
>> 2. Node - intermediate strange relay that overwrites headers - end node
>> 
>> There is no need for scenario 2 in IPv6.
>> 
>> If this is in effort to do something for Ipv6 NATs I think it's a waste of
>> time and adds confusion for the Internet as a whole.
> 
> You are assuming that scenario 2 implies NAT.
> 
> I believe SOCKS (RFC1928) supports IPv6-IPv6 gatewaying, pretty much the same
> as TURN would. One obvious reason is firewalls. Last time I checked the V6CPE
> discussion, it did not seem like IPv6 would deprecate firewalls.

=> Again, this implies having two different connections and there should not
be an issue with flow labels.

> 
> One can nevertheless question the usefulness of IPv6-IPv6 gateways. Afterall
> SOCKS is quite old. And the main driver for TURN is NAT traversal, which is
> not an issue in IPv6-IPv6. Assuming that IPv6 firewalls are well BEHAVE'd,
> then TURN will never be needed in pure IPv6 cases. That seems like an
> optimistic assumption to me, but fine with me.
> 
> 
> Then TURN should only support, IPv4-IPv4, IPv6-IPv4 and IPv4-IPv6 cases. And
> then, the issue of flow infos preservation is moot, as flow infos don't exist
> in IPv4. Also then, we're back to my point on that TURN should provide an
> IPv4 mapped address to _IPv6_ TURN clients by default.

=> Right. I don't know about your point for mapped addresses, but I agree
with the rest. 

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 07 May 2008 09:22:26 +1000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 May 2008 13:41:51 +1200

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

> any middleware box that modifies addresses (for example, an SIP Session
> Border Controller). I think the question is the same.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 May 2008 15:50:01 +1200

In line..

On 2008-05-07 15:34, Philip Matthews wrote:
> 
> On Tue, 6-May-08, at 21:41 , Brian E Carpenter wrote:
> I have no technical problem with doing with you suggest.
> 
> My only question is: if many devices adopt this approach, then won't
> this mean that the flow label will often be zero, and thus useless for
> things like load-balancing in equal-cost multi-path scenarios?

That is today's situation - there was no consensus for assuming
that load-balancing is the primary use case, so no consensus for
making setting the label a SHOULD. I don't think that TURN is special
in this regard.

> The proposed DSCP text says that the DSCP should be copied unless the
> relay believes, through unspecified means, that another value for the
> outgoing DSCP is appropriate. However, if the incoming value cannot be
> read, then set the outgoing value to Best Effort (again, unless the
> relay believes another value is more appropriate).

OK, although I would be a bit more specific: unless the relay
includes a diffserv classifier (and associated policy). That's
how it obtains such a 'belief' in the diffserv model.

> Believe me, the v4 cases have had much discussion (including the
> involvement of three current ADs).

I don't doubt it ;-)

   Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 07 May 2008 08:46:27 +0200

Brian E Carpenter wrote :
> 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.

This is IMU the right behavior

I had essentially the same conclusion (see for example
http://www.ietf.org/mail-archive/web/behave/current/msg03789.html).

A slightly different wording could however, IMO, be preferable.
"Assign 0" and "RFC3697" should be placed on an equal footing, no one
being more "default" than the other: a source may have either behavior;
a destination or an intermediate node may not assume any of the two
behaviors in particular.

Rémi