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

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cameron Byrne
Sent: Tuesday, March 12, 2013 8:22 AM
To: Reinaldo Penno (repenno)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt

On Mar 11, 2013 7:46 PM, "Reinaldo Penno (repenno)" <repenno@cisco.com<mailto:repenno@cisco.com>> wrote:
>
> 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.
>

That is my plan. Ipv6 e2e ftw.

[TR] Even with IPv6, there is no guarantee that NPTv6 will not be deployed. So PCP/STUN is still required to gather server-reflexive candidates. Even without NPTv6, Firewalls would block UDP flows -  PCP would address that problem. TURN should be only used as last resort if all other techniques fail because it could result in media latency, single point of failure etc.

--Tiru.

CB

> On 3/11/13 9:57 PM, "Cameron Byrne" <cb.list6@gmail.com<mailto:cb.list6@gmail.com>> wrote:
>
> >On Mon, Mar 11, 2013 at 6:42 PM,  <Markus.Isomaki@nokia.com<mailto: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> [mailto: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<mailto: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<mailto: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<mailto:rtcweb@ietf.org>
> >>>https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/rtcweb
>