Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt

Simon Perreault <> Tue, 11 February 2014 14:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 844CE1A0381 for <>; Tue, 11 Feb 2014 06:17:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JN8wtx8IrUuL for <>; Tue, 11 Feb 2014 06:17:38 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 08D281A032D for <>; Tue, 11 Feb 2014 06:17:37 -0800 (PST)
Received: from ( [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by (Postfix) with ESMTPSA id 290D240447 for <>; Tue, 11 Feb 2014 09:17:37 -0500 (EST)
Message-ID: <>
Date: Tue, 11 Feb 2014 09:17:36 -0500
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2014 14:17:39 -0000

Le 2014-02-11 00:26, Tirumaleswar Reddy (tireddy) a écrit :
> This document describes two mechanisms to auto discover TURN server. Please review and provide your valuable comments.

Nice. A few comments/questions...

1. Does WPAD play any role in this? Why/why not? (DHCP options are often
inaccessible/very hard to get to from end-user applications, namely

2. About the anycast mechanism:

   When a client requires TURN services, it sends a TURN allocate
   request to the assigned anycast address.  The responding TURN anycast
   server puts its own unicast address as the source address in the
   reply message.

That won't work because it won't get through most firewalls and many
NATs. The response's 5-tuple has to be the same as the request's.

I suggest you look into the 300 (Try Alternate) response mechanism. The
response would contain the unicast address in an ALTERNATE-SERVER
attribute. See also RFC 5766 section 2.9.

3. It would be nice to make anycast work with TCP.

4. In the IANA Considerations section, it seems you are requesting a
single IPv4 address and a single IPv6 address. If we want anycast to
work across AS boundaries, we need to request a /24 and a /48,
respectively. I think we want that, so that TURN service can easily be
provided by a third party. (On the other hand, single addresses are
interesting security-wise in that they won't travel very far in BGP.)

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->