[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 Flow Label


On Tue, 6-May-08, at 00:27 , Hesham Soliman 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.
=> I completely agree. Philip, it might help if you explain why this need 
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