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

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 2 May 2008 15:04:26 +0300

Le Thursday 24 April 2008 23:17:13 ext Philip Matthews, vous avez écrit :
> > IMHO, I think TURN-07 is wrong and TURN-IPv6 is right.
> >
> > The relay cannot know if there was a protocol translator in the
> > middle, so that would be the only way to obtain sane defaults.
> >
> > So either the client must always explicitly specify the address
> > family, or the default should be independent of the relay-reflexive
> > address of the client.
>
> Sorry to be slow in replying here.
>
> I would really prefer to stick with the current turn-07 proposal and
> fix turn-ipv6 to match.
>
> If we went with the turn0-ipv6 proposal, then the base TURN
> specification would have to specify how to relay between IPv6 and
> IPv4.

In either case, IPv6 support is currently somewhat broken in TURN-07. 
Especially, the handling IPv6 flow information field is left unspecified, 
which is certainly wrong.

From a more general perspective, having the application-layer semantics depend 
on the IP protocol version of the client looks like very bad engineering to 
me. Imagine DNS servers would return different results depending if you query 
them over v4 or v6!?!

Looking at TURN-07:

No issue for DSCP, ECN and TTL.
The DF bit text does simply not apply to IPv6. So no issue either.
No show-stopper with the current Path MTU text. The MTU would become always 
576, even in IPv6 case.

> This would happen if the server's transport address was IPv6, 
> since the base specification would always allocate a v4 relayed-
> transport-address. In particular, the base spec would have to go into
> the details of how to translate the IP headers when doing "fully-
> compliant relaying" (as described at the last meeting in Philly). This
> I would really like to avoid.

It is difficult to respond to such comments out of the blue. I cannot seem to 
find the relevant part of the spec at the moment.

> So instead, a TURN client much check the address family of the relayed-
> transport-address it gets back, just like it much check the address
> family of the mapped-address (these two families will always be the
> same under the current base spec proposal). If the client cannot
> handle this family, then it must delete the allocation.

This is IMHO broken. If the TURN server is dual-stack, IPv6 clients will only 
be able to use IPv6 with it, and IPv4 clients will only be able to use IPv4.

Since turn-ipv6 is not a mandatory extension, a well-designed TURN client 
implementation cannot assume the server supports it.

> If the WG feels this is not acceptable, then I will propose that we
> remove all handling of IPv6 from the base spec, and let draft-ietf-
> behave-turn-ipv6 cover these cases.
-- 
Rémi Denis-Courmont
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Fri, 2 May 2008 15:16:02 -0400

> which is certainly wrong.

This is being fixed.
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.

> me. Imagine DNS servers would return different results depending if  

Don't forget that you get exactly this behavior with a STUN server. If  
you access the STUN server over IPv6, then the mapped-address you get  
back is IPv6. If you access the same server over IPv4, you get back a  
IPv4 mapped-address.

In my view, if one thinks of a TURN server as a relay, then it makes  
sense that if one sends it v6 packets, they come out as v6 packets on  
the other end.

> No show-stopper with the current Path MTU text. The MTU would become  

All the text in section 11 has been totally rewritten as part of  
adding the concept of Preserving vs. Non-Preserving allocations. I  
have asked a couple of people to look it over, and then I expect to  
post it. In the mean time, you can look at my presentation in Philly  
for a high-level description.

> find the relevant part of the spec at the moment.

See above.

> implementation cannot assume the server supports it.

What if the base spec included the REQUESTED-ADDRESS-TYPE attribute  
with the restriction that the address type given in the REQUESTED- 
ADDRESS-TYPE attribute MUST match the address type in the 5-tuple or  
the Allocate request is rejected ?
TURN-IPv6 would then lift this restriction.

Would this make things better?

- Philip

---

From: Simon Perreault <[email-masked]>
Date: Fri, 2 May 2008 15:35:21 -0400

> Would this make things better?

Hehehe, that would be the shortest RFC ever.

===================

Abstract

This memo lifts a restriction concerning mixed address types in RFCXXXX.

1. Lifting a Restriction

The restriction to the effect that the address family contained in the 
REQUESTED-ADDRESS-TYPE attribute must match that of the server address is 
hereby lifted.

2. IANA Considerations

None.

3. Security Considerations

None.

Acknowledgements

I wish to dedicate this work to my parents, to God, etc. This is my lifetime 
achievement.

References

[RFCXXXX] TURN.

====================

Just don't put the restriction in TURN in the first place! ;)
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 5 May 2008 09:23:50 +0300

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

> > From a more general perspective, having the application-layer
> > semantics depend on the IP protocol version of the client looks
> > like very bad engineering to me. Imagine DNS servers would return
> > different results depending if you query them over v4 or v6!?!
>
> Don't forget that you get exactly this behavior with a STUN server.

Or with any service that gives you your IP address from the perspective of the 
server. This seems quite specific, and not very relevant here.

(...)
> Would this make things better?

I think so, yeah.

---

From: <[email-masked]>
Date: Mon, 5 May 2008 17:10:54 +0530

need a small clarification..
How many times do I need to send the data indication from TURN client?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 5 May 2008 14:47:20 +0300

> How many times do I need to send the data indication from TURN client?

Why would you need to send it more or less than once??

---

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

> 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: <[email-masked]>
Date: Mon, 5 May 2008 18:08:38 +0530

I was talking of retransmission. As we will be using UDP, so is retransmission required? 

Thanks & Regards
Tamal Tanu Biswas

Arise! Awake! and stop not till the goal is reached.
                                               -Swami Vivekananda

---

From: Simon Perreault <[email-masked]>
Date: Mon, 5 May 2008 08:46:48 -0400

> I was talking of retransmission. As we will be using UDP, so is

An indication is never acknowledged. Any retransmission is futile.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 5 May 2008 15:48:16 +0300

> I was talking of retransmission. As we will be using UDP, so is

How could there be retransmission at a layer that does not have an 
acknowledgement mechanism?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 5 May 2008 15:55:16 +0300

Le Monday 05 May 2008 15:48:17 ext [email-masked], vous avez écrit :
> That is exactly what I am asking...
> Then how can I be sure that data has reached to my peer??

Obviously, you can't. UDP is not a reliable protocol, with nor without TURN.

---

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: Rémi Després <[email-masked]>
Date: Mon, 05 May 2008 17:07:05 +0200

> Are you saying that this does not describe approved behavior?

I certainely should not say it this way.
But it is till unclear to me whether there is a real USE of it?

If there is one (with running code etc...), my comment is just inadequate.

Taking this opportunity, here is a proposal:

- Limit the RFC3697 use of flow labels (FLs) to a subset of all their 
possible values.
- The goal is that other future uses are not precluded (or at least are 
not made significantly more difficult).
- For example, have the first bit set to 1, or the first 4 bits set to 
1111, or the first octet different from OxFF.

Regards.

Rémi

---

From: <[email-masked]>
Date: Mon, 5 May 2008 17:12:34 +0300

Philip Matthews wrote:
>>>> 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.
>>> I myself am not sure what the "proper" handling of the flow infos is. 

As per RFC 3697, the flow label is interpreted only in the context of the source and destination addresses. This means that the flow "identity" changes when relayed trough a TURN-relay, as the IP addresses change. This is also true for NATs to begin with.

Nevertheless, I'd say the flow label should be copied over, if possible, so that any possible future use would be minimally harmed.

Regards,

	Jarno Rajahalme

---

From: Philip Matthews <[email-masked]>
Date: Mon, 5 May 2008 12:30:59 -0400

Folks:

This discussion is prompted by discussions right now in v6OPS around  
devices to translate between IPv6 and IPv4. So, for example, a client  
might send an Allocate request over IPv6, but the request might arrive  
at the TURN server over IPv4 (or vica-versa).

At present (in TURN-07), the TURN server allocates a relayed-transport- 
address in the same address family (IPv4 or IPv6) as the family over  
which the Allocate request arrived. Rémi Denis-Courmont dislikes the  
fact that the client might get back an address family different from  
the one it "expected".

So I am looking for comments on one of two options going forward:

1) [Currently in TURN-07] The address family (IPv4 vs IPv6) of a  
relayed-transport-address is the same as the address family over which  
the Allocate request arrived.

2) [Proposal] TURN-08 will define the REQUESTED-ADDRESS-TYPE attribute  
(which is currently defined in draft-ietf-behave-turn-ipv6) which  
allows the client to request a particular address family for the  
relayed-transport-address. However, TURN-08 will reject the Allocate  
request if the requested address family is not the same as the address  
family over which the Allocate request arrived.

Under either option, TURN-08 will still require that two address  
families match. That is, TURN-08 will NOT specify IPv4 to IPv6  
relaying (because the details for doing this are non-trivial). An  
extension for relaying between address families will be left for draft- 
ietf-behave-turn-ipv6.

So the difference is that, when in cases where option (1) would cause  
the client to get back an address family different than the one it  
"expected", option (2) will cause the Allocate request to be rejected.

I am quite happy with option (2).

Comments?

- Philip

On Mon, 5-May-08, at 02:23 , Rémi Denis-Courmont wrote:
>> this
> is. If

---

From: Simon Perreault <[email-masked]>
Date: Mon, 5 May 2008 13:33:03 -0400

On Monday 05 May 2008 12:30:59 Philip Matthews wrote:
> TURN-08 will NOT specify IPv4 to IPv6
> relaying (because the details for doing this are non-trivial).

What details do you have in mind?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 5 May 2008 16:45:41 -0400

> What details do you have in mind?

v4 to v6 relaying adds details to how relaying of IP header fields and  
ICMP messages are done. This is a feature coming in TURN-08 (as  
discussed in the last BEHAVE meeting in Philly). Moreover, the WG has  
already chartered draft-ietf-behave-turn-ipv6 for this, and I am  
really trying to finish the base TURN, not add new features.

- Philip

---

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

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

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?

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 5 May 2008 22:17:37 -0400

Resending message as I got a delivery error ...

Comments?

- Philip

---

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

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

Hesham

>    Brian

---

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

> 1111, or the first octet different from OxFF.

=> Something very similar to what you propose was discussed when the IPv6 WG
was producing RFC 3697 and the concensus was not to do that.
The use of the flow label was discussed for many years in the IPv6 WG so I
don't think it would be easy to change this now. In any case, these
proposals are best discussed in 6man.

Hesham

---

From: Rémi Després <[email-masked]>
Date: Tue, 06 May 2008 09:31:52 +0200

> was producing RFC 3697 and the concensus was not to do that.
Unfortunate IMHO.
> don't think it would be easy to change this now.
Agreed, at least as long as no really useful use of flow lebels is 
identified.
> In any case, these
Right.

Rémi

---

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]

---

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

On Tue, 6-May-08, at 00:27 , Hesham Soliman wrote:
>>> destination

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 6 May 2008 09:00:31 -0400

> flawed assumption from the beginning.

I thought the use case for TURNv6 was to allow interoperability between 
v4-only and v6-only devices, but now I'm not so sure we're all on the same 
wavelength.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 6 May 2008 16:16:15 +0300

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

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.

---

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

> v4-only and v6-only devices, but now I'm not so sure we're all on the same

=> Well, in that case the flow label is a moot point. Also, there are
requirements and solutions being worked on in v6ops to do this using NAT-PT.

Hesham

---

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

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

> 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: Brian E Carpenter <[email-masked]>
Date: Tue, 06 May 2008 09:23:56 +1200

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

    Brian

---

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

Brian

---

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: Philip Matthews <[email-masked]>
Date: Tue, 6 May 2008 14:35:39 -0400

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.

2) Always set the outgoing flow label to 0.

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

---

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

Philip, 

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

> 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

---

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: Philip Matthews <[email-masked]>
Date: Tue, 6 May 2008 23:13:28 -0400

> flow label because you already broke it.

Hesham:

If I understand you correctly, you are arguing that we should not  
consider this question, because TURN should never be used with IPv6.

My take on this is as follows. It may be that TURN will never get used  
as an IPv6-to-IPv6 relay.  If so, then this discussion is  
unnecessary.  However, v6OPS is currently discussing the possibility  
of NATing between IPv4 and IPv6, so there is the chance that TURN  
might be useful in a v6 context. Furthermore, the IESG requires that  
all protocols consider IPv6, so it is easier and faster for me (as  
TURN editor) to simply add the small extra text to cover the v6 case  
than to fight for a special exception to the rule.

Does this make sense? Do I correctly understand your position?

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 6 May 2008 23:34:22 -0400

On Tue, 6-May-08, at 21:41 , Brian E Carpenter wrote:
>> _is_
>> exist

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?

> be copied as-is. But I expect you know that.)

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

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

- Philip

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 07 May 2008 13:40:43 +1000

> consider this question, because TURN should never be used with IPv6.

=> No I was only referring to the IPv6-IPv6 relay scenario.

> might be useful in a v6 context.

=> That's fine with me. In that scenario the question of the flow label
would not come up though.

 Furthermore, the IESG requires that
> than to fight for a special exception to the rule.

=> I think you could think of analogous situations where the requirement
would not apply and therefore the IESG would not hold you responsible. For
instance, suppose we're updating the NAT RFC or RFC 1918. I'm pretty sure
the IESG would not require you to reserve a block of IPv6 addresses for
IPv6-IPv6 NATs. This is a similar case.

> Does this make sense? Do I correctly understand your position?

=> I was only referring to IPv6-IPv6 scenarios, clearly there is merit in
the IPv4-IPv6 cases.

Hesham

---

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

In line..

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

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

> involvement of three current ADs).

I don't doubt it ;-)

   Brian

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 7 May 2008 08:57:22 +0300

> in order to have a local application receive them.

That's "destination" NAT, i.e. translating the passive-side address of the 
network flow. AFAIK, this is only done when it's "known to work", usually in 
front of a plain TCP connection-based service (HTTP, SMTP, you-name-it...).

That's quite different from the more common "source" NAT. In any case, TURN is 
meant to address the non-BEHAVE-compliant "source" NATs. Time will tell, but 
these will hopefully not be very common in IPv6.

---

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 07 May 2008 11:08:22 +0300

Hi Philip,

once we agree on how to divide the text between both specs, we can 
copy/paste between both specs until we get the structure and the 
contents in both specs right.

Regarding your question (option 1 vs. option 2), we need to think of 
which implementations will only implement the base TURN spec (as opposed 
to implementing both the base TURN spec and TURN-ipv6). An IPv4-only 
TURN server does not need to worry about address families. So, it should 
be enough for that server to implement base TURN without worrying about 
REQUESTED-ADDRESS-TYPE attributes. On the other hand, an IPv4-IPv6 TURN 
server would need to implement both specs.

So, I guess this argues for keeping the definition of the 
REQUESTED-ADDRESS-TYPE in the TURN-ipv6 spec and moving the text on 
IP4-IPv6 relaying from base TURN to TURN-ipv6. I would leave the 
IPv6-IPv6 stuff, if we finally decide to keep it, on the base TURN spec. 
This way, the base TURN spec would deal with relaying within a single 
address family while TURN-ipv6 would deal with IPv4-IPv6 relaying.

Cheers,

Gonzalo

---

From: Philip Matthews <[email-masked]>
Date: Wed, 7 May 2008 15:26:02 -0400

> contents in both specs right.
Yes.

> which implementations will only implement the base TURN spec (as  
> opposed to implementing both the base TURN spec and TURN-ipv6). An  
> IPv4-only TURN server does not need to worry about address families.  
> So, it should be enough for that server to implement base TURN  
> without worrying about REQUESTED-ADDRESS-TYPE attributes.

If the base TURN spec does not include the REQUESTED-ADDRESS-TYPE  
attribute, then we have to go with option (1). However, Remi prefers  
option (2).

> On the other hand, an IPv4-IPv6 TURN server would need to implement  
> both specs.

Yes.

>
>
> So, I guess this argues for keeping the definition of the REQUESTED- 
> ADDRESS-TYPE in the TURN-ipv6 spec and moving the text on IP4-IPv6  
> relaying from base TURN to TURN-ipv6.

There is no text of IPv4-IPv6 relaying in the base TURN spec, and I am  
trying hard not to add any.

> I would leave the IPv6-IPv6 stuff, if we finally decide to keep it,  
> on the base TURN spec.

Yes.

> This way, the base TURN spec would deal with relaying within a  
> single address family while TURN-ipv6 would deal with IPv4-IPv6  
> relaying.

Yes. This is the way things are now, I am am trying hard to stick with  
this.

>
>
> Cheers,
>
> Gonzalo
>
>
> Philip Matthews wrote:
>> Folks:
>> This discussion is prompted by discussions right now in v6OPS  
>> around  devices to translate between IPv6 and IPv4. So, for  
>> example, a client  might send an Allocate request over IPv6, but  
>> the request might arrive  at the TURN server over IPv4 (or vica- 
>> versa).
>> At present (in TURN-07), the TURN server allocates a relayed- 
>> transport- address in the same address family (IPv4 or IPv6) as the  
>> family over  which the Allocate request arrived. Rémi Denis- 
>> Courmont dislikes the  fact that the client might get back an  
>> address family different from  the one it "expected".
>> relayed-transport-address is the same as the address family over  
>> which  the Allocate request arrived.
>> 2) [Proposal] TURN-08 will define the REQUESTED-ADDRESS-TYPE  
>> attribute  (which is currently defined in draft-ietf-behave-turn- 
>> ipv6) which  allows the client to request a particular address  
>> family for the  relayed-transport-address. However, TURN-08 will  
>> reject the Allocate  request if the requested address family is not  
>> the same as the address  family over which the Allocate request  
>> arrived.
>> extension for relaying between address families will be left for  
>> draft- ietf-behave-turn-ipv6.
>> So the difference is that, when in cases where option (1) would  
>> cause  the client to get back an address family different than the  
>> one it  "expected", option (2) will cause the Allocate request to  
>> be rejected.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 07 May 2008 22:44:39 +0300

Hi,

> attribute, then we have to go with option (1). However, Remi prefers 

but... what is the advantage of going with option 2?

Cheers,

Gonzalo

---

From: Philip Matthews <[email-masked]>
Date: Wed, 7 May 2008 16:15:39 -0400

On Wed, 7-May-08, at 15:44 , Gonzalo Camarillo wrote:
>> attribute, then we have to go with option (1). However, Remi  
>> prefers option (2).
>

Under option (1), a client sending an Allocate request over IPv4 might  
get back an IPv6 relayed-transport-address, if the Allocate request  
passed through a v4-to-v6 translator (as is currently being considered  
in v6OPS). If the client is unable to handle this, it must delete the  
allocation.

Under option (2), a client sending an Allocation request over IPv4 can  
explicitly say that it wants an IPv4 relayed-transport-address. Thus,  
if the Allocate request passes through a v4-to-v6 translator, the  
server will detect that the request arrived over v6 but was for a v4  
relayed-transport-address, and thus reject the request.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 7 May 2008 16:23:18 -0400

> a destination or an intermediate node may not assume any of the two

If no one has any objections, I will adopt this behavior.

- Philip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 08 May 2008 06:55:42 +0300

Hi,

I think we all agree this should be the behavior for clients and 
servers. However, if we move all the meat from TURN-IPv6 to base TURN 
(we already moved the address family definition a while ago), it may 
make sense to merge both specs. Specifying the IPv4-IPv6 mapping may not 
be trivial, but it's not a big deal either.

The bottom line is that we are discussing an issue related to document 
structure. We seem to agree on the actual protocol behavior.

Cheers,

Gonzalo

Philip Matthews wrote:
> explicitly say that it wants an IPv4 relayed-transport-address. Thus, if 
> the Allocate request passes through a v4-to-v6 translator, the server 
> will detect that the request arrived over v6 but was for a v4

---

From: Philip Matthews <[email-masked]>
Date: Thu, 8 May 2008 17:13:34 -0400

I really haven't spent any time thinking about it, but I am assuming  
that the details of IPv4-to-IPv6 relaying will take a few pages to  
specify, and there will be some design decisions to discuss, which  
will take time. Because of this assumption, I am trying to push it out  
of the base TURN spec. But perhaps I am wrong. Perhaps you would take  
a look and let me know?

- Philip

On Wed, 7-May-08, at 23:55 , Gonzalo Camarillo wrote:
> servers. However, if we move all the meat from TURN-IPv6 to base  
> TURN (we already moved the address family definition a while ago),  
> it may make sense to merge both specs. Specifying the IPv4-IPv6  
> mapping may not be trivial, but it's not a big deal either.
>
> The bottom line is that we are discussing an issue related to  
> document structure. We seem to agree on the actual protocol behavior.
>
> Cheers,
>
> Gonzalo
>
>
> Philip Matthews wrote:
>> Under option (1), a client sending an Allocate request over IPv4  
>> might get back an IPv6 relayed-transport-address, if the Allocate  
>> request passed through a v4-to-v6 translator (as is currently being  
>> considered in v6OPS). If the client is unable to handle this, it  
>> must delete the allocation.
>> Under option (2), a client sending an Allocation request over IPv4  
>> can explicitly say that it wants an IPv4 relayed-transport-address.  
>> Thus, if the Allocate request passes through a v4-to-v6 translator,  
>> the server will detect that the request arrived over v6 but was for  
>> a v4 relayed-transport-address, and thus reject the request.
>> - Philip
>
>