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

"Prashanth Patil (praspati)" <> Tue, 11 February 2014 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91F751A0631 for <>; Tue, 11 Feb 2014 09:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WgmmRKG5q3Mv for <>; Tue, 11 Feb 2014 09:40:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 783CE1A05CD for <>; Tue, 11 Feb 2014 09:40:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2462; q=dns/txt; s=iport; t=1392140438; x=1393350038; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=A7RZWxf8fh3iyL4Zsqeh534fe4szK6Qa9YstFObGoo0=; b=myNY208Prioz5Ivy0Jq6xcuC2zB3dfmnom+nSNvZjX7C+GYgnNtw4yMV zKKfSYlwfz/bOJTfJZAxnVWrt6t20IPzFJ4Qxmhv831q4Q1bK4MgadqiI U4RA5W0lJVQZfDc41sSsRT3Q3QaxS2QkIvOAr90jCXXirWZXvztoEP+zC Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="19618925"
Received: from ([]) by with ESMTP; 11 Feb 2014 17:40:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1BHeaUj009293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 17:40:36 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 11:40:36 -0600
From: "Prashanth Patil (praspati)" <>
To: Simon Perreault <>, "" <>
Thread-Topic: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt
Thread-Index: AQHPJujlhhkvHnd6iEyVomMYFG2jpw==
Date: Tue, 11 Feb 2014 17:40:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 17:40:40 -0000

Hi Simon,

On 2/11/14 7:47 PM, "Simon Perreault" <> wrote:

>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

For WPAD, my understanding is that some browsers use DHCP Inform to
request and obtain information from a DHCP server for use in their local
WPAD is a viable option, given that it's used quite a bit. I suppose we
could suggest it as an option in the draft, but WPAD is not standardized.

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

Good point, will update.

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

Yep. However, do we really need it in the context of discovery? If a
client can discover a server using UDP, the client can choose to
subsequently contact the same server over 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               -->
>tram mailing list