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

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 11 Mar 2013 16:56:50 +0000

FYI - We submitted this draft today it relates to the requirements in the use case draft for rtcweb to work in the presence of firewalls and http proxies etc.

Look forward to feedback and hope that this can be considered for adoption by the working group.

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 11 March 2013 06:01
To: [email-masked]
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP proxies
	Author(s)       : Thomas Stach
                          Andrew Hutton
                          Justin Uberti
	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-00.txt
	Pages           : 8
	Date            : 2013-03-11

Abstract:
   This document describes mechanism to enable media stream
   establishment in the presence of NATs, firewalls and HTTP proxies.
   HTTP proxy and firewall policies applied in many private network
   domains introduce obstacles to the successful establishment of media
   stream via RTCWEB.  This document examines some of these policies and
   develops requirements on the web browsers designed to provide the
   best possible chance of media connectivity between RTCWEB peers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considerations

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Mar 2013 17:04:17 +0000

Hello,

Why not use Port Control Protocol (PCP) to control Firewalls and NATs
explicitly? 

Thanks,

On 3/11/13 9:56 AM, "Hutton, Andrew"
<[email-masked]> wrote:

>FYI - We submitted this draft today it relates to the requirements in the
>use case draft for rtcweb to work in the presence of firewalls and http
>proxies etc.
>
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of
>[email-masked]
>Subject: I-D Action:
>draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>
>
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 11 Mar 2013 18:29:17 +0100

> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
We can switch to that as soon as 100% of firewalls support it - until 
then, we have to be able to rely on other techniques.

That's the deployment problem in a nutshell... I don't understand how 
the first firewall gets an advantage from having PCP, given that none of 
the apps support it, and I don't understand how the first app gets an 
advantage from having PCP, given that no firewalls support it.

If PCP succeeds despite my misgivings, we can certainly revisit the issue.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Mar 2013 18:02:57 +0000

Hello,

>then, we have to be able to rely on other techniques.

I'm sure STUN and TURN servers are not universally deployed ('100%') in
ISP networks either.

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.

>If PCP succeeds despite my misgivings, we can certainly revisit the issue.

I believe it should be considered as a viable option now since it is a
specific protocol to control NATs/Firewalls and Flow-aware devices
required Pv6 CPE requirements document, Broadband Forum and 3GPP specs.

>>> 	Filename        :
>>>https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consid
>>>er
>>> ations
>>>
>>>http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideratio
>>>ns
>>> -00
>>>
>>>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 11:07:26 -0700

On Mon, Mar 11, 2013 at 10:29 AM, Harald Alvestrand
<[email-masked]> wrote:
> We can switch to that as soon as 100% of firewalls support it - until then,
> we have to be able to rely on other techniques.
>
> That's the deployment problem in a nutshell... I don't understand how the
> first firewall gets an advantage from having PCP, given that none of the
> apps support it, and I don't understand how the first app gets an advantage
> from having PCP, given that no firewalls support it.
>

I am also pessimistic on PCP being deployed and would rather not
confuse the WebRTC community into thinking PCP is requirement for
WebRTC.  I believe TURN is much better solution.  As mobile network
operator, i feel much more comfortable offering TURN as a solution to
customers than PCP.

CB

>>>         Title           : RTCWEB Considerations for NATs, Firewalls and
>>> HTTP
>>> proxies
>>>         Author(s)       : Thomas Stach
>>>                           Andrew Hutton
>>>                           Justin Uberti
>>>         Filename        :

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 11 Mar 2013 15:34:25 -0400

> I'm sure STUN and TURN servers are not universally deployed ('100%') in

STUN and TURN don't require any support from ISPs. Both protocols are used today. 
Your co-worker Jonathan Rosenberg worked on these mechanisms and Cisco also supports them ;-)

Ciao
Hannes

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Mar 2013 19:52:41 +0000

On 3/11/13 12:34 PM, "Hannes Tschofenig" <[email-masked]> wrote:

>STUN and TURN don't require any support from ISPs.

If ISPs want to provide RTCweb like services don't they need STUN and TURN
Servers so that ICE can gather candidates?

>Both protocols are used today.

Yes, today. But that did not stop design decisions to include these
protocols in ICE at a they time were not deployed at all.

>Your co-worker Jonathan Rosenberg worked on these mechanisms and Cisco

Certainly.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Mar 2013 15:57:32 -0400

> Servers so that ICE can gather candidates?

An example of freely-accessible non-ISP STUN/TURN service: 
http://numb.viagenie.ca

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 11 Mar 2013 19:58:08 +0000

> I'm sure STUN and TURN servers are not universally deployed ('100%') in

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.

> an additional technique. Maybe you misunderstood what I was proposing.

Understood but would need to understand what the benefits of doing so would be.

Regards
Andy

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Mar 2013 20:01:44 +0000

I meant an ISP provided service, not a "hoping over the ISP" scenario.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 11 Mar 2013 21:04:13 +0100

> Servers so that ICE can gather candidates?

ISPs may want to offer services. But that's independent of their role as 
ISPs.
Anyone can offer a STUN or TURN server, and they can be anywhere on the 
Internet.

PCP, on the other hand, has to be available on the specific firewall or 
NAT box you intend to traverse. If it isn't there, it won't work.
> protocols in ICE at a they time were not deployed at all.

Sorry, I can't parse that.

ICE was deployed to support applications that needed ICE; there was no 
need to deploy more than 1 STUN/TURN server in order to start using STUN 
and TURN.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Mar 2013 20:11:35 +0000

>NAT box you intend to traverse. If it isn't there, it won't work.

Yes, but on the other hand you deterministically get an IP address:port or
pinhole (both for incoming and outgoing connections) for a specific
lifetime instead of relying on outbound connections, keep-alives, and
external server. 

The point is that if the FW/NAT supports PCP, the solution is certainly
cleaner. Client is always free to fallback to STUN/TURN/indirect ways.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Mar 2013 20:14:24 +0000

On 3/11/13 12:58 PM, "Hutton, Andrew"
<[email-masked]> wrote:

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

>Understood but would need to understand what the benefits of doing so

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.

---

From: <[email-masked]>
Date: Tue, 12 Mar 2013 01:42:05 +0000

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/?include_text=1.

Markus

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Reinaldo Penno (repenno)
>Sent: 11 March, 2013 22:14
>To: Hutton, Andrew; Harald Alvestrand; [email-masked]
>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>considerations-00.txt
>
>
>
>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>> in ISP networks either.
>>
>>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.
>
>>> 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.
>>>
>>
>(both for incoming and outgoing connections IPv4/IPv6), including lifetime,
>knowing when such device restart/reboot, is more deterministic.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 18:57:02 -0700

> [1] http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?include_text=1.

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 12 Mar 2013 02:32:48 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hutton, Andrew
> Sent: Monday, March 11, 2013 10:27 PM
> To: [email-masked]
> Subject: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> considerations-00.txt
> 
> FYI - We submitted this draft today it relates to the requirements in the use
> case draft for rtcweb to work in the presence of firewalls and http proxies
> etc.
> 

we submitted a individual draft that addresses the problem of Firewalls to permit UDP.
http://tools.ietf.org/html/draft-reddy-mmusic-stun-auth-fw-traversal-00

This draft proposes extensions to ICE connectivity checks that can be examined by the firewall to permit outgoing UDP flows across the firewall.

--Tiru.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 12 Mar 2013 02:46:43 +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" <[email-masked]> wrote:

>> 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
>>
>
>>>lifetime,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 12 Mar 2013 02:48:46 +0000

> [email-masked]
> Sent: Tuesday, March 12, 2013 7:12 AM
> To: Reinaldo Penno (repenno); [email-masked];
> [email-masked]; [email-masked]

Good point. http://tools.ietf.org/html/rfc6544#section-5.3 explains to gather candidates also using PCP in addition to using STUN/TURN. ICE connectivity checks
will reveal if PCP Unaware NAT exists or not. 

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

Enterprise use cases would be different. http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09 explains some of the reasons to deploy TURN server in the campus itself. 

--Tiru.

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

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 19:51:31 -0700

> requirements RFC. Unless you think with IPv6 there will no IPv6 firewalls.

That is my plan. Ipv6 e2e ftw.

CB

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 12 Mar 2013 03:05:19 +0000

I think another advantage of PCP is to reduce call setup time in RTCweb.
If a NAT/FW/Middlebox tells us that you have a mapping for 1 hour, during
that hour you can reuse that external IP:port across calls over and over,
or least reuse as your prime ICE candidate.

On 3/11/13 9:42 PM, "[email-masked]" <[email-masked]>
wrote:

>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. 
>
>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.
>
>http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?inclu
>de_text=1.
>
>Markus
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 12 Mar 2013 03:18:41 +0000

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

[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" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >On Mon, Mar 11, 2013 at 6:42 PM,  <[email-masked]<mailto:[email-masked]>> wrote:
> >> Hi,
> >>
> >>>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> >>>To: Hutton, Andrew; Harald Alvestrand; [email-masked]<mailto:[email-masked]>
> >>><[email-masked]<mailto:[email-masked]>> wrote:
> >>>
> >>>[email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 12 Mar 2013 03:57:55 +0000

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

Right, and the application provider could be also an enterprise hosting a TURN server for a number of reasons in addition to NAT/firewall traversal -- media anchoring, monitoring, recording etc. I think TURN servers aren't going away, especially with WebRTC where the session signaling protocol between the browser and the web server could be proprietary (and encrypted), making ALG techniques in NATs/Firewalls/SBCs fail miserably.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
|Sent: Tuesday, March 12, 2013 1:28 AM
|To: Reinaldo Penno (repenno); Harald Alvestrand; [email-masked]
|Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
|
|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.
|
|>
|> 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.
|
|Regards
|Andy
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 12 Mar 2013 14:38:33 +0100

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

I absolutely agree with this summary about the usefulness and status of PCP.

My concern with RTCWEB at the moment is getting things out the door with 
all the features we really need to have, and as few additional features 
as possible.

That's why I don't want to add PCP into the mix at this time - once 
we're finished with the basic stuff, we can discuss adding support for 
new features at our leisure, but making the specs more complex than they 
currently are really should be done only when it's a really important 
feature that needs adding.

            Harald

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:45:39 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Folks:

I also agree with Harald on his proposal that PCP would be considered later.
In addition, I like to add the following:

1. Let PCP becomes an RFC.
2. Let there be some use cases/call-flows (as a PCP call-flow IETF draft is
there) using PCP for FW/NAT crossing by RTCWEB, SIP (audio/video)
conferencing, and related real-time applications.

Once above two items are completed, a separate draft using PCP for FW/NAT
crossing by RTCWEB applications can be written as soon as possible including
co-existing with ICE/STUN/TURN complementing each other capabilities.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Alvestrand
Sent: Tuesday, March 12, 2013 9:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] FW: I-D Action:
draft-hutton-rtcweb-nat-firewall-considerations-00.txt

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

My concern with RTCWEB at the moment is getting things out the door with all
the features we really need to have, and as few additional features as
possible.

That's why I don't want to add PCP into the mix at this time - once we're
finished with the basic stuff, we can discuss adding support for new
features at our leisure, but making the specs more complex than they
currently are really should be done only when it's a really important
feature that needs adding.

            Harald

Classification: UNCLASSIFIED
Caveats: NONE

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 12 Mar 2013 19:37:38 +0000

On Mar 11, 2013, at 1:29 PM, Harald Alvestrand <[email-masked]> wrote:

> We can switch to that as soon as 100% of firewalls support it - until then, we have to be able to rely on other techniques.

Not to contradict with your point, but to pile on it...
Even if 100% of the Firewalls were to support PCP, you'd still want to do STUN/TURN/ICE methinks, because 

1) you never know that your local Firewall is the *only* Firewall-ish thing between you and the public Internet or some network reachable by both parties.  This problem already happens with UPnP and NAT-PMP today, and has been noted before in BEHAVE or MMUSIC, I think. 

2) There's a big difference between 100% of Firewalls implementing PCP, and it being actually enabled/turned-on in 100% of them.

3) you don't know if the IP path across the Internet works for a given address family - this has been given as the reason STUN/ICE needs to be required for v4/v6 dual-stack implementations, to test reachability across the IPv6 Internet before trying to use it; regardless of NATs/Firewalls.

-hadriel