Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt

"Reinaldo Penno (repenno)" <> Tue, 12 March 2013 02:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5968D21F8A9B for <>; Mon, 11 Mar 2013 19:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.468
X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EcIn3rluMCBo for <>; Mon, 11 Mar 2013 19:46:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 300AA21F87B1 for <>; Mon, 11 Mar 2013 19:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4239; q=dns/txt; s=iport; t=1363056406; x=1364266006; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7klgJvW/ARrAmdN6EZvteSViYgB9HIvvibWZu4QpMeA=; b=buhtDZharZdtdoxSWdaPSvOhGI6BRDyLnoJF2WHyCjOCUHwQVO3JZu06 YJlKgQYCL6gdsnZKG/diwWJks8sTq/4UsBwIoiphw01EpFCosT4pUtOD0 fHl9zw8A7M3rJFt2GN9BH//g5s8nhNNgjNJifqU86dQWY5gu2F5WwJZdm k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186355855"
Received: from ([]) by with ESMTP; 12 Mar 2013 02:46:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r2C2kjfs018033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 02:46:45 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 21:46:45 -0500
From: "Reinaldo Penno (repenno)" <>
To: Cameron Byrne <>, "" <>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihPEwA//+PMoCAANDogIAABC0A///K0gA=
Date: Tue, 12 Mar 2013 02:46:43 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Mar 2013 02:46:47 -0000

Agree with you on e2e IPv6 would be ideal. PCP is well suited to control
IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE
requirements RFC. Unless you think with IPv6 there will no IPv6 firewalls.

On 3/11/13 9:57 PM, "Cameron Byrne" <> wrote:

>On Mon, Mar 11, 2013 at 6:42 PM,  <> wrote:
>> Hi,
>> ICE/STUN/TURN and PCP are not really competitors or alternatives to
>>each other.
>> A browser or any other client will anyway need to implement
>>ICE/STUN/TURN to work its way through non-PCP supporting NATs, which
>>will be the majority for a long time even if PCP became succesfull. The
>>benefit of the ICE/STUN/TURN approach is that every organization or
>>individual who deploys NATs or firewalls will not need to deploy STUN
>>and TURN servers, but they can be deployed independently e.g. by the
>>WebRTC service provider.
>> However, PCP, even gradually deployed, would still be useful as well.
>>As Reinaldo is saying, it would improve robustness it produces explict
>>NAT mappings with explicit durations. Also, it can serve as an
>>alternative to STUN/TURN in case the browser happens to be behind a
>>PCP-capable NAT/FW. So, PCP can be seen as an optimization and should be
>>used when it is available. PCP can also help clients behind NAT/FW to
>>reduce their keep-alive rate which is applicable to WebRTC as well.
>>However, as depicted in [1], knowing when a client can entirely rely on
>>PCP is not always so easy to detect.
>> I hope we will see PCP deployment especially in the mobile/cellular
>>access, but as many people have pointed out, the success rate of this
>>type of protocols has been quite low. So it will be a nice surprise
>>rather than something I would count on if it happens.
>> [1] 
>> Markus
>I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
>reaching critical mass. This more because i am on bullish on v6 than
>bearish on PCP.  That said, the more interesting use-case is v4 to v6
>via TURN, but i believe that is already covered well ... another
>reason ICE is a good fit.
>>>-----Original Message-----
>>>From: [] On Behalf
>>>Of ext Reinaldo Penno (repenno)
>>>Sent: 11 March, 2013 22:14
>>>To: Hutton, Andrew; Harald Alvestrand;
>>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>>><> wrote:
>>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>>> in ISP networks either.
>>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
>>>>server is much more likely to be deployed by the web application
>>>>provider which will instruct the browser to use it when accessing its
>>>The line between Application providers and ISPs is very blurry today.
>>>Application provider can be over the top or it can be the ISP itself.
>>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
>>>>> PCP as an additional technique. Maybe you misunderstood what I was
>>>>> proposing.
>>>>Understood but would need to understand what the benefits of doing so
>>>>would be.
>>>Yes, certainly.
>>>A protocol that allows a host to explicit control FW/NAT
>>>(both for incoming and outgoing connections IPv4/IPv6), including
>>>knowing when such device restart/reboot, is more deterministic.
>>>Client is always free to use STUN/TURN.
>>>rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list