Subject: Re: [BEHAVE] IPv4/IPv6 relayed address allocation

From: Rémi Després <[email-masked]>
Date: Mon, 05 May 2008 14:33:10 +0200

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.

Rémi

---

From: Philip Matthews <[email-masked]>
Date: Mon, 5 May 2008 09:21:21 -0400

On Mon, 5-May-08, at 08:33 , Rémi Després wrote:
>> 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...
>
> 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?

- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 May 2008 09:23:56 +1200

On 2008-05-06 01:21, Philip Matthews wrote:
>>> 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...
>>

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.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 May 2008 15:20:53 +1200

On 2008-05-06 13:20, Philip Matthews wrote:
> 
> On Mon, 5-May-08, at 17:23 , Brian E Carpenter wrote:
> 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

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 06 May 2008 14:27:30 +1000

> 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

---

From: Rémi Després <[email-masked]>
Date: Tue, 06 May 2008 10:38:21 +0200

Brian E Carpenter wrote :

> So the rule is really only that the flow label
> default setting is zero).
Right.
However, between source and destination hosts *of IPv6 packets*.
On an A-TURN-B path, the *destination host* of a packet from A is TURN 
(not B).

> TURN has to obey that rule like any other
TURN is in this respect like any other function that operates with 
different 5-tuples on its upstream and donwstream interfaces (above the 
IP layer).

Following the discusion, this is IMHO the right logic:

TURN nodes may freely support or not support RFC 3697 flow labels, as 
sources on their outgoing interfaces,.
Independently, they may freely ignore received flow labels, or process 
them to optimize their transport flow recognition, on thir incoming 
interfaces.

If RFC 3697 flow labels are implemented by the two end nodes and by an 
intermediate TURN node, then packet classification can take advantage of 
flow labels in all traversed routers, be it with changed flow label 
values across the TURN node.

Rémi

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 06 May 2008 19:14:05 +1000

> default setting is zero).
Right.
However, between source and destination hosts
> *of IPv6 packets*.
On an A-TURN-B path, the *destination host* of a packet
> from A is TURN 
(not B).

> TURN has to obey that rule like any other
TURN is in this respect like any other function that
> operates with 
different 5-tuples on its upstream and donwstream interfaces
> (above the 
IP layer).

  Following the discusion, this is IMHO the right
> logic:

sources on their outgoing interfaces,.
Independently, they may freely ignore
> received flow labels, or process 
them to optimize their transport flow
> recognition, on thir incoming 
interfaces.

If RFC 3697 flow labels are
> implemented by the two end nodes and by an 
intermediate TURN node, then
> packet classification can take advantage of 
flow labels in all traversed
> routers, be it with changed flow label 
values across the TURN
> node.

=> I don't understand two points:
- Why is the IPv6 address/header being re-written?
- If there is a good answer for the above question then why would you ignore
the flow label and not copy it across?

It is one thing to terminate the connection and restart it with the remote
node, but I don't see any reason for re-writing a header _and_ ignoring the
original content of that header.

Hesham

Rémi

_______________________________________________
Behave mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Tue, 06 May 2008 14:37:51 +0200

>>  sources on their outgoing interfaces,. Independently, they may
>> freely ignore received flow labels, or process them to optimize their
>> transport flow recognition, on thir incoming interfaces.

> => I don't understand two points: - Why is the IPv6 address/header
> being re-written? - If there is a good answer for the above question
> then why would you ignore the flow label and not copy it across?

The destination address of a packet received by a TURN relay is the 
address of the relay. That of the packet it forwards, with the same data 
  field, is the address of the next IP layer destination node (the 
destination host or an itermediate NAT).

RFC 3697 has a rule that non zero flow labels that leave a node MUST be 
all different for current flows having the same source-destination pair.

If flow labels received by a TURN relay from two different sources 
happen to be the same while the next IP destination happens to be the 
same NAT, copying flow labels will infringe the rule.

Therefore, IMU, flow labels *MUST NOT* be copied from upstream flows to 
downstream flows.

Rémi

---

From: Philip Matthews <[email-masked]>
Date: Tue, 6 May 2008 08:46:36 -0400

> arises for IPv6. What is the scenario?

TURN is a protocol that allows a client to "engage" the services of a  
relay (= TURN server). The driving motivation for developing TURN is  
to allow a client located behind a non-BEHAVE-compliant NAT to talk  
with other nodes. However, there are other less-common v4 NAT (and  
firewall?) scenarios where TURN is useful.  TURN is an integral part  
of the ICE/STUN/TURN suite of protocols for NAT traversal.

I realize that the question of NATs in the IPv6 world is a touchy  
subject. If there are no NATs in the v6 world, then TURN may never be  
needed. Perhaps the best answer is to wait and see what develops.  
However, like all other IETF protocols, the IESG requires us to  
consider IPv6 support when developing TURN. In same way, ICE and STUN  
also include IPv6 support. So I am trying to specify something that  
seems right for IPv6 with TURN.

For the other fields in the IPv4 and IPv6 headers, TURN copies the  
field from the incoming packet to the outgoing packet except when it  
needs to do something else for relay purposes. That was my motivation  
for suggesting that the flow label also be copied (if possible). But  
from Brian's message, perhaps the more appropriate behavior would be  
to set the outgoing flow label to 0?

- Philip

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 06 May 2008 22:52:49 +1000

> address of the relay.

=> This suggests to me that you have to distinct connections:
Node - relay
Relay - someone else

   That of the packet it forwards, with the same data
> destination host or an itermediate NAT).

=> Did you mean NAT? I thought we're talking about IPv6.

> same NAT, copying flow labels will infringe the rule.

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

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 06 May 2008 22:58:51 +1000

Thanks for the detail Philip, I haven't read TURN for a long time.

> seems right for IPv6 with TURN.

=> I think that a perfectly useful answer to the IESG is to say that since
there is no _need_ for NATs in IPv6, we don't have to consider it. There are
many NAT traversal mechanisms that don't consider IPv6. There are a few that
do consider IPv6 in the context of allowing IPv4-encapsulated IPv6 traffic
to traverse NATs. But in those scenarios, I don't think the question of the
flow label or the IPv6 header in general needs to be addressed.

> to set the outgoing flow label to 0?

=> Personally, I think the appropriate behaviour is not to do anything for
IPv6 and NATs.

Hesham

> Behave mailing list

---

From: David Conrad <[email-masked]>
Date: Tue, 6 May 2008 07:13:42 -0700

Hesham,

On May 6, 2008, at 5:58 AM, Hesham Soliman wrote:
> I think that a perfectly useful answer to the IESG is to say that  
> since
> there is no _need_ for NATs in IPv6, we don't have to consider it.

The fact that IPv6 has the same routing technology as IPv4 guarantees  
there will be a market for NATv6 (assuming IPv6 gets deployed), if for  
no other reason than people not wanting to be tied to their ISP.

> Personally, I think the appropriate behaviour is not to do anything  
> for
> IPv6 and NATs.

It would be sad if the IETF did not learn from past mistakes.

Regards,
-drc

---

From: Sebastien Roy <[email-masked]>
Date: Tue, 06 May 2008 10:24:41 -0400

Hesham,

> there is no _need_ for NATs in IPv6, we don't have to consider it.

This is intended merely as a data-point, and not to fuel any NAT-related
fires:

I'm aware of IPv4 deployments using NAT in order to easily implement
transparent proxies.  Specifically, they use a NAT to transparently
redirect packets to a local address and port, and a user-space proxy
receives those packets, processes them, and retransmits them.  The use
of NAT here has nothing to do with preserving address space, but as a
hack to transparently redirect all packets to a local address and port
in order to have a local application receive them.

I'm also aware of deployments implementing this same hack for IPv6, so
to issue a blanket statement that there is no need for NATs with IPv6
may be ignoring some weird use cases like the one above.

That said, I don't know whether this particular use of NAT needs to be
considered here, I'm merely stating that there is IPv6 NAT out there
(much to my chagrin) that might need to be considered.

-Seb

---

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

> may be ignoring some weird use cases like the one above.

=> As you acknowledge, those are hacks and weird cases. The above doesn't
imply a _technical need_. We don't develop standards for everyone who comes
along with  the hack of the day. If we did that, we'd be in trouble IMHO.

Hesham