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

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" <cb.list6@gmail.com> wrote:

>On Mon, Mar 11, 2013 at 6:42 PM,  <Markus.Isomaki@nokia.com> 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] 
>>http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?incl
>>ude_text=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.
>
>CB
>>
>>>-----Original Message-----
>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>>>Of ext Reinaldo Penno (repenno)
>>>Sent: 11 March, 2013 22:14
>>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
>>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>>considerations-00.txt
>>>
>>>
>>>
>>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>>><andrew.hutton@siemens-enterprise.com> 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
>>>>service.
>>>
>>>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
>>>mappings/pinholes
>>>(both for incoming and outgoing connections IPv4/IPv6), including
>>>lifetime,
>>>knowing when such device restart/reboot, is more deterministic.
>>>Client is always free to use STUN/TURN.
>>>
>>>
>>>>
>>>>Regards
>>>>Andy
>>>
>>>_______________________________________________
>>>rtcweb mailing list
>>>rtcweb@ietf.org
>>>https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb