Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header

From: Philip Matthews <[email-masked]>
Date: Fri, 1 Feb 2008 13:41:36 -0500

> On Fri, 1-Feb-08, at 05:55 , Stephane Bortzmeyer wrote:
>> On Mon, Jan 28, 2008 at 05:06:11PM -0500,
>>  Philip Matthews <[email-masked]> wrote
>>  a message of 125 lines which said:
>>
>>> *) Preserving bits in the IP header. When relaying packets, how
>>> should various IP header bits be set?
>>
>> My personal opinion, based on the tests I ran on various machines, is
>> that:
>>
>> TURN is a "last resort" solution, anyway, for the case where users  
>> are
>> stuck behind badly behaving NATs. We all know it is not the best
>> solution but its main feature is that it always works, whatever the
>> behaviour of the NATs. So, having more things (such as  
>> preservation of
>> IP options) is nice but should not be mandatory, it is most important
>> to have TURN servers available than to have them preserve every IP
>> option.
>>
>> So, I favor something like "TURN servers MAY preserve the options set
>> in the IP header".
>>

What if we come up with something that can be fairly easily done by a  
unprivileged user-land process?
Do you still think MAY is important?

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Feb 2008 22:51:01 +0100

On Mon, Feb 11, 2008 at 10:45:02PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 887 lines which said:

> Here is the documentation of the tool, I'll send the actual reports
> later.

(I forgot to say that the tool was tested only with UDP/IPv4.)

Linux (tested on two Debian machines, with kernels 2.4 and 2.6) :

Can set TOS/DSCP (including ECN) - raising precedence requires to be
root -, TTL and DF.

Can get TOS/DSCP (including ECN) and TTL.

FreeBSD (tested on 6.2) : 

Can set TOS/DSCP (including ECN) and TTL.

Can get TTL.

NetBSD (tested on 3.1) :

Can set TOS/DSCP (including ECN) and TTL.

Cannot get anything.

VMS :

Can set TOS/DSCP (including ECN) and TTL.

Cannot get anything.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Feb 2008 22:55:55 +0100

On Mon, Feb 11, 2008 at 10:51:01PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> (I forgot to say that the tool was tested only with UDP/IPv4.)

Tru64 / OSF1 :

Cannot get anything.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Feb 2008 22:53:45 +0100

On Fri, Feb 01, 2008 at 01:41:36PM -0500,
 Philip Matthews <[email-masked]> wrote 
 a message of 33 lines which said:

> What if we come up with something that can be fairly easily done by
> a unprivileged user-land process?

Even if it were the case (but I'm skeptical), I really cannot
understand why it is so important. TURN provides a last-resort
solution to the connectivity problem. The important things is that it
works, not that it is perfect. Frankly, who uses DSCP bits, anyway?

I understand only the need for DF manipulation (because of MTU issues)
but that's all. Enlightenment welcome.

A MAY is sufficient for me.
_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 11 Feb 2008 14:51:32 -0800

That's really great - thank you.

---

From: Philip Matthews <[email-masked]>
Date: Tue, 12 Feb 2008 06:22:18 -0500

> A MAY is sufficient for me.

I agree with you that TURN is the last-resort solution to the  
connectivity problem. For that reason, the current proposal says that  
the TURN server should try to preserve the DSCP bits IF IT CAN. It  
seems that a TURN server can do this on certain OSes, but not on others.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 12 Feb 2008 14:09:03 +0200

> seems that a TURN server can do this on certain OSes, but not on others.

One related issue I was wondering about is, how do NATs and firewalls interact 
(or preferably not interact) with the TOS bits.

It is well known that some deployed firewalls screw up with ECN, but I suppose 
it's an issue with the TCP flags, rather than the IP-layer flags, right?

On the other hand, RFC4380, which also tunnels specifically through NATs, does 
not say anything about preserving the TOS bits. I haven't checked ESP-in-UDP.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Feb 2008 10:25:33 -0800

> One related issue I was wondering about is, how do NATs and 
> firewalls interact (or preferably not interact) with the TOS 
> bits.

I am not aware of any tests.  You can do your own easily enough --
even Windows XP's built-in PING utility allows setting ToS bits 
using "-v".  However, even "-v 255" on my system only seems to
allow setting the ToS bits to 0x2, according to tcpdump.  My
IOS NAT and my Linksys WRT54G running Tomato both preserve
the ToS value to a host on the Internet.  For whatever that's
worth...

-d

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Feb 2008 11:50:14 -0800

On Feb 11, 2008, at 1:53 PM, Stephane Bortzmeyer wrote:

>  The important things is that it

Many voip deployments use DSCP. When you are running in an enterprise  
environment over a VPN with a DLS line, they can help make sure that  
downloading email does not trash a phone call.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Feb 2008 16:43:43 -0600

Correct. It is widely used. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Tuesday, February 12, 2008 11:50
> To: Stephane Bortzmeyer
> Cc: Behave WG; Philip Matthews
> Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header
> 
> 
> Many voip deployments use DSCP. When you are running in an 
> enterprise environment over a VPN with a DLS line, they can 
> help make sure that downloading email does not trash a phone call.
> 
> 
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2008 09:16:30 +0100

On Tue, Feb 12, 2008 at 04:43:43PM -0600,
 Francois Audet <[email-masked]> wrote 

> Correct. It is widely used. 

I was talking about its use on the public Internet (you do not need
TURN if you're entirely inside your own network).
_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2008 12:24:41 +0100

On Tue, Feb 12, 2008 at 10:25:33AM -0800,
 Dan Wing <[email-masked]> wrote 
 a message of 18 lines which said:

> You can do your own easily enough -- even Windows XP's built-in PING
> utility allows setting ToS bits using "-v".

It may be simpler to use the program I mentioned on that list which,
strangely, was not archived in
http://www.ietf.org/mail-archive/web/behave/. It should work on
Windows, too.

I attach the program again, to compensate for its non-archival.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 13 Feb 2008 07:37:47 -0800

> From: Stephane Bortzmeyer [mailto:[email-masked]] 
> Sent: Wednesday, February 13, 2008 3:25 AM
> To: Dan Wing
> Cc: 'Rémi Denis-Courmont'; [email-masked]; 'ext Philip Matthews'
> Subject: Re: TURN Issue: Preserving bits in the IP header
> 
> http://www.ietf.org/mail-archive/web/behave/.

There were some archival issues during the switchover of IETF
servers.  I hadn't realized BEHAVE was affected.  

> It should work on

Thanks.
-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 13 Feb 2008 09:59:07 -0600

That, I don't know. Probably need input from service providers. 

> Sent: Wednesday, February 13, 2008 00:17
> To: Audet, Francois (SC100:3055)
> Cc: Cullen Jennings; Stephane Bortzmeyer; Behave WG; Philip Matthews
> On Tue, Feb 12, 2008 at 04:43:43PM -0600,  Francois Audet 
> <[email-masked]> wrote  a message of 27 lines which said:
> 
> I was talking about its use on the public Internet (you do 
> not need TURN if you're entirely inside your own network).
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 13 Feb 2008 08:49:04 -0800

> TURN if you're entirely inside your own network).

See also RFC4504 section 2.12.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Feb 2008 12:19:36 -0800

> TURN if you're entirely inside your own network).

If I was inside my network and wanted to phone someone outside the  
network, I might need TURN.  There also are plenty of internal  
networks that would need TURN for phone calls purely inside the  
internal network.