idnits 2.17.1 draft-penno-rtcweb-pcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2013) is 3988 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.boucadair-mmusic-altc' is defined on line 568, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-01 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-02 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-06 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Downref: Normative reference to an Informational RFC: RFC 6092 ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) == Outdated reference: A later version (-03) exists of draft-hutton-rtcweb-nat-firewall-considerations-00 == Outdated reference: A later version (-06) exists of draft-ietf-pcp-nat64-prefix64-02 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-01 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-10 == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-03 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB R. Penno 3 Internet-Draft T. Reddy 4 Intended status: Standards Track D. Wing 5 Expires: November 26, 2013 Cisco 6 M. Boucadair 7 France Telecom 8 May 25, 2013 10 PCP Considerations for WebRTC Usage 11 draft-penno-rtcweb-pcp-00 13 Abstract 15 This document describes the motivations for WebRTC applications to be 16 PCP-aware and the benefits provided by PCP-capable NATs and 17 Firewalls. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 26, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 55 3. Advantages of using PCP with WebRTC . . . . . . . . . . . . . 3 56 3.1. Firewalls Blocking UDP . . . . . . . . . . . . . . . . . 3 57 3.2. Firewalls permit specific WebRTC servers . . . . . . . . 5 58 3.3. ICE Lite . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Reducing Call Set-Up Time . . . . . . . . . . . . . . . . 6 60 3.4.1. ICE Speedup . . . . . . . . . . . . . . . . . . . . . 6 61 3.4.2. Pre-allocating ports to speed call setup time . . . . 6 62 3.5. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.6. Optimizing NAT and Firewall Keepalives . . . . . . . . . 7 64 3.7. Faster Flow Failure Detection . . . . . . . . . . . . . . 8 65 3.8. 3GPP Selective IP Traffic Offload (SIPTO) . . . . . . . . 8 66 3.9. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.10. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4. Usage of PCP with STUN and TURN . . . . . . . . . . . . . . . 10 69 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 8.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 Port Control Protocol (PCP, [RFC6887]) provides a mechanism to 82 describe a flow to the network. The primary driver for PCP has been 83 creating port mappings on NAT and firewall devices. When doing this, 84 PCP pushes flow information from the host into the network 85 (specifically to the network's NAT or firewall device), and receives 86 information back from the network (from the NAT or firewall device). 88 The Web Real-Time communication (WebRTC) framework 89 [I-D.ietf-rtcweb-overview] provides the protocol building blocks to 90 support direct, interactive, real-time communication using audio, 91 video, collaboration, games, etc., between peer web-browsers. WebRTC 92 application use Interactive Connectivity Establishment (ICE) protocol 93 [RFC5245] for gathering candidates, prioritizing them, choosing 94 default ones, exchanging them with the remote party, pairing them and 95 ordering them into check lists. Once all of the above steps have 96 been completed the participating ICE agents can begin a phase of 97 connectivity checks and eventually select a pair of candidates that 98 will be used for real-time communication. 100 This specification describes the reasons for WebRTC applications to 101 be PCP-aware and use PCP along side with STUN and TURN. It also 102 explains the benefits for a network that deploy PCP-controlled NATs 103 and Firewalls. 105 2. Notational Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 This document uses terms defined in [RFC5389] and [RFC5766]. 113 eNodeB: The eNodeB is a base station entity that supports the Long- 114 Term Evolution (LTE) air interface [RFC6459]. 116 3. Advantages of using PCP with WebRTC 118 The below sections explain the problems with NAT and Firewall, 119 current techniques used to solved them and the PCP solution in these 120 scenarios. 122 3.1. Firewalls Blocking UDP 124 Enterprise networks may deploy firewalls with restrictive policies 125 configured to block UDP traffic. These firewalls may be configured 126 to permit TCP or HTTP(s) traffic only. One of the reasons for 127 blocking UDP could be that there is no way for the firewall to 128 determine when the endpoints have terminated the call, in which case 129 the firewall has to close the dynamic mapping based on firewall UDP 130 mapping timer value. [RFC4787] mandates that the UDP mapping timer 131 for NAT must not expire in less than 2 minutes and recommends a 132 default value of five minutes or more. Firewalls are likely to 133 follow the same recommendation for their UDP mapping timer, which 134 would be applicable to both IPv4 and IPv6 firewalls. The behavioural 135 requirements for IPv6 firewalls is explained in section 3.2.3 of 137 [RFC6092]. [I-D.hutton-rtcweb-nat-firewall-considerations] gives 138 details of other organization e.g. a public service agency or 139 university that deploy firewall which may have restrictive firewall 140 policy to block UDP traffic. 142 Modern firewalls may also have application-layer gateways (ALGs) 143 perform policy enforcement to permit peer-to-peer UDP media session. 144 Using the ALG, a firewall can determine when the call is terminated 145 and close any dynamic mappings created for the media session. But 146 the problem is the session signaling between the WebRTC application 147 running in the browser and the web server could be using TLS, in 148 which case the ALG no longer has access to the signaling. Moreover, 149 WebRTC does not enforce a particular session signaling protocol to be 150 used, so firewalls using ALGs would fail to inspect the signaling to 151 identify the 5-tuple used for each media stream. Furthermore, the 152 session signaling and the peer-to-peer media may traverse different 153 Firewalls. 155 Using TURN for all such communication to by-pass firewall causes the 156 following problems: 158 o TURN server could increase media latency as explained in section 159 4.1.2.2 of [RFC5245]. Using a reliable and ordered protocol like 160 TCP instead of UDP to transfer real-time media is problematic as 161 delays would be directly noticeable and may be unacceptable to the 162 user. 164 o High-end TURN server would be needed (For example when TLS-over- 165 TCP transport is used between the client and the server) to cater 166 to all such calls. 168 o TURN server could either be located in the DMZ of the enterprise 169 network or located in the public Internet. If the TURN server is 170 located in the public Internet it comes at a high cost to the 171 provider of the TURN server, since the server typically needs a 172 high-bandwidth connection to the Internet as explained in the 173 Introduction of [RFC5766]. As a consequence, it is best to use a 174 TURN server only when a direct communication path cannot be found. 175 When the client and a peer use ICE to determine the communication 176 path, ICE will use hole punching techniques to search for a direct 177 path first and only use a TURN server when a direct path cannot be 178 found. 180 o Some of the other limitations of TURN explained in section 2.6 of 181 [RFC5766] are, the value of the Diffserv field may not be 182 preserved, the Explicit Congestion Notification (ECN) field may be 183 reset etc. 185 PCP resolves the above problems by restricting firewall traversal to 186 authorized PCP clients and communicating mapping lifetimes and call 187 termination between the PCP client and the PCP-controlled firewall. 188 A PCP Server can also enforce per-host quotas for mappings. 190 3.2. Firewalls permit specific WebRTC servers 192 When an enterprise uses a trusted WebRTC server deployed in a 3rd 193 party network for communication, the enterprise firewall could have 194 granular policies to permit peer-to-peer UDP media session only when 195 the call is initiated using the selected WebRTC server (Dr. Good) it 196 trusts and block others (Dr. Evil). Firewall policy has a white- 197 list of permitted outside applications/sites and can blacklist 198 HTTP(S) connections via various forms of detections (destination DNS 199 lookup, HTTP URL Filtering, DPI proxy that at least performs HTTPS 200 inspection of URL in certificate, Subject Name of TLS exchange and 201 validates SSL records etc). Firewall in this configuration would 202 also block TCP connection to arbitrary TURN servers in the Internet. 203 3GPP networks may also have a similar configuration where IMS 204 services of certain other operators are permitted and others are 205 blocked [[TR33.830]. 207 With PCP, this problem is solved by associating the media session 208 with the signaling session. This is done by sending a cryptographic 209 token in the signaling which authorizes the firewall mapping for the 210 media session. 212 3.3. ICE Lite 214 For scenarios where the client is connected to the public Internet 215 and has public IP address at which it can receive packets from the 216 remote peer and uses ICE LITE implementation explained in section 2.7 217 of [RFC5245], the ICE Lite endpoint will not generate its own ICE 218 connectivity checks, by definition. Thus, if an ICE Lite endpoint is 219 behind a firewall that blocks unsolicited incoming traffic then ICE 220 Lite will fail. 222 This workaround for solving the problem is by using full ICE or by 223 changing the filtering policy on the firewall to permit unsolicited 224 incoming UDP traffic which would effectively disable the purpose of 225 firewall. Full ICE will take more time to be adapted especially with 226 legacy VoIP equipment which will initially start with ICE-Lite 227 implementation as discussed in section 6 of [I-D.cbran-rtcweb-nat]. 229 With PCP, a firewall can filter incoming UDP traffic and PCP client 230 can communicate exceptions to the firewall to permit specific 231 mappings when a call is active. In this way, the ICE Lite endpoint 232 and its network are protected from unsolicited incoming UDP traffic, 233 and can still operate using ICE Lite (rather than full ICE). 235 3.4. Reducing Call Set-Up Time 237 There are initiatives to speedup ICE processing in order to reduce 238 call setup time using techniques such as Trickle ICE 239 [I-D.rescorla-mmusic-ice-trickle] and RTP multiplexing Section 4.4 of 240 [I-D.ietf-rtcweb-rtp-usage]. Trickle ICE can begin connectivity 241 checks while the endpoint is still gathering candidates and can 242 considerably shorten the time necessary for ICE processing to 243 complete. RTP multiplexing suggests to bind interactive audio and 244 interactive video to the same 5-tuple {dest addr, source addr, 245 protocol, dest port, source port} to optimize NAT resource usage and 246 shorten the call setup time. 248 PCP can help reduce call set-up time by speeding up ICE and, if 249 appropriate, at the same time allowing each media for flow over a 250 different 5-tuple. 252 3.4.1. ICE Speedup 254 ICE requires time to perform its setup operations. This time grows 255 in proportion to the number of transport sessions which must be 256 opened in order to support the call. If using a different IP 257 addresses and/or ports for audio versus video streams, call setup 258 time will increase. The precise amount of this increase depends on 259 the type of NAT and other factors like packet loss. The use of RTP 260 Multiplexing technique introduces some QoS challenges in many 261 networks, e.g., In Mobile Networks the QoS considerations are 262 explained in Section 4.1 of [I-D.reddy-rtcweb-mobile]. 264 Fast call setup time and QoS can both be retained by using PCP. 265 External IP addresses and ports can be learnt faster using PCP than 266 other techniques because the PCP client is communicating only with 267 PCP servers in the Home and Service Provider network. In contrast, 268 STUN and TURN servers may be located halfway around the world from 269 the endpoint adding delay to learn server-reflexive and relayed 270 candidates. Trickle ICE can begin connectivity checks using the 271 candidates learnt from PCP, while the endpoint is still gathering 272 other candidate types and thus can considerably shorten the time 273 necessary for ICE processing to complete. 275 3.4.2. Pre-allocating ports to speed call setup time 276 The external IP:port allocated through PCP belong to the client for 277 duration of the lifetime of the mapping. This means that 278 connectivity checks for a new call can begin immediately using the 279 already allocated external IP:port and if necessary the client can 280 extend the lifetime of the mapping. TURN allocations can also be 281 extended using Refresh transaction to update the time-to-expiry of 282 existing allocation and thus can be used for a new call immediately. 283 Server Reflexive candidates learnt using STUN can also be maintained 284 for a new call but requires the endpoint to send frequent keepalives 285 to prevent the NAT and firewall mappings from expiring. 287 The PCP client for fast call setup can also use PORT_SET option 288 [I-D.ietf-pcp-port-set] requesting the PCP server to pre-allocate 289 contiguous ports with port parity preservation. 291 3.5. NAT 293 Direct peer-to-peer communication is not possible if both NATs are of 294 a certain type that changes the outside port number when connecting 295 to new hosts (NAT behaviour "address-dependent mapping" or "address 296 and-port-dependent mapping" as described in [RFC4787]). 298 When such NAT devices are encountered, communication can be 299 established using a media relay (TURN) server. But using TURN 300 servers is expensive as explained in section 4.1.1.2 of [RFC5245] and 301 other challenges of using TURN are discussed in Section 3.1 . Relayed 302 candidates should only be used as last-resort when connectivity 303 checks using other candidate types are not successful. 305 PCP improves this situation by creating explicit bindings on PCP- 306 controlled NATs and can adjust their mapping and filtering behavior 307 so that connections can be successfully created. PCP can also 308 recursively communicate with multiple layers of NATs using 309 [I-D.ietf-pcp-proxy]. Usage of STUN and PCP for learning candidates, 310 prioritization, encoding them in offer or answer is explained in 311 Section 4.1. 313 3.6. Optimizing NAT and Firewall Keepalives 315 Applications like WebRTC need to keep their Network Address 316 Translator (NAT) and firewall mappings alive for long periods of 317 time, even when they are otherwise not sending or receiving any 318 traffic. The signaling protocol used for WebRTC would want to keep 319 the client-server connection alive for as long as the application is 320 running. When the WebRTC application has otherwise no traffic to 321 send, specific keep-alive messages are sent periodically to ensure 322 that the NAT/Firewall state in the middle does not expire. The 323 endpoint would also have to send keepalives for the media session to 324 keep NAT/Firewall bindings alive. As NAT/firewall mapping timers may 325 be short and unknown to the endpoint, the keepalive messages are sent 326 frequently. 328 In cellular mobile networks, frequent keepalive messages make the 329 radio transition between active and power-save states causing 330 signaling congestion. The excessive time spent on the active state 331 due to keepalives also greatly reduces the battery life of the 332 cellular connected devices such as smartphones or tablets. 334 PCP is useful to reduce NAT and firewall keepalive messages (e.g., 335 Section 3.4 of [I-D.reddy-pcp-optimize-keepalives]) for both 336 signaling protocol and media session. 338 3.7. Faster Flow Failure Detection 340 If a NAT device has rebooted, lost its mappings or has its external 341 IP address changed then it may take few minutes before the endpoint 342 realizes that the connectivity is lost, that would result in 343 disruption of signaling and media traffic. Application can find that 344 the signaling session is broken by using TCP keepalive probes, the 345 time taken to detect that the connection is broken depends on the 346 frequency of keepalive probes. If the endpoint is using sendonly 347 media streams, it may take few minutes based on RTCP reports to 348 realize that the connectivity is lost. WebRTC client will then have 349 to re-establish connection with the WebRTC server and initiate ICE 350 restart. 352 Using the Rapid Recovery procedure explained in Section 14 of 353 [RFC6887], the PCP client upon receiving a PCP ANNOUNCE from a PCP 354 server, becomes aware that the PCP server has rebooted or lost its 355 mapping state. The PCP client issues new PCP requests to recreate 356 any lost mapping state and thus reconstructs lost mappings fast 357 enough that existing media streams do not break and re-establish 358 connectivity with its WebRTC server. 360 If for some reason PCP server determines that some or all of its 361 mappings have become unusable (e.g., when a home gateway is assigned 362 a different external IPv4 address by the upstream DHCP server) then 363 the PCP server automatically repairs its mappings and notifies its 364 clients about the new External IP address and port as part of the 365 Rapid Recovery techniques explained in Section 14.2 of [RFC6887]. 366 The client based on this notification can use MICE 367 [I-D.wing-mmusic-ice-mobility] or ICE Restart to achieve RTP 368 Mobility. 370 3.8. 3GPP Selective IP Traffic Offload (SIPTO) 371 Given the exponential growth in the mobile data traffic, Mobile 372 Operators are looking for ways to offload some of the IP traffic 373 flows at the nearest access edge that has an Internet peering point. 374 This approach results in efficient usage of the mobile packet core 375 and helps lower the transport cost. Since Release 10, 3GPP starts 376 supporting of Selected IP Traffic Offload (SIPTO) function defined in 377 [TS23.060][TS23.060], [TS23.401]. The SIPTO function allows an 378 operator to offload certain types of traffic at a network node close 379 to the UE's point of attachment to the access network. Limited 380 Mobility support available with SIPTO is explained in section 2.3.3 381 of [I-D.zuniga-dmm-gap-analysis]. 383 If SIPTO is carried out in a Traffic offload Function (TOF) entity in 384 the path between the Radio stations and the Mobile Gateway (MGW) as 385 explained in [I-D.reddy-rtcweb-mobile] and the Mobile Node (MN) roams 386 from one eNodeB and changes its point of attachment to a new eNodeB 387 NAT changes. In this case host candidates for the MN will not change 388 but MN will be behind a new NAT after roaming. It may take few 389 minutes before the MN realizes that the connectivity is lost, 390 resulting in disruption of signalling and media traffic. Application 391 can find that the signaling session is broken by using TCP keepalive 392 probes, the time taken to detect that connection is broken depends on 393 the frequency of the keepalive probes. If the endpoint is using 394 sendonly media streams, it may take few minutes based on RTCP reports 395 to realize that the connectivity is lost. WebRTC client will then 396 have to re-establish connection with the WebRTC server and initiate 397 ICE restart. 399 The problem can be mitigated by the following mechanism using PCP: 401 When TOF receives the SIPTO rules for the MN, the PCP-controlled NAT 402 at TOF sends unicast PCP ANNOUNCE response to the MN informing it 403 that the NAT has changed. WebRTC application using PCP can verify 404 that external IP addresses and ports have changed for the media 405 streams and proceed accordingly (e.g., MICE 406 [I-D.wing-mmusic-ice-mobility] or ICE Restart to achieve RTP 407 Mobility). 409 3.9. Auditing 411 On certain networks, it is necessary to audit communications across 412 the network firewall and attribute those communications to certain 413 users or users running certain applications. The use case for 414 auditing is also explained in Section 4.2.5.1 of 415 [I-D.ietf-rtcweb-use-cases-and-requirements]. 417 Today, this is done by tracking IP address assignment on the network 418 and auditing lots of mappings created by firewalls. 420 PCP improves that auditing by PCP Authentication 421 [I-D.ietf-pcp-authentication]. A PCP server can audit all traffic 422 including media sessions from inside an enterprise premises to any 423 external peer. An enterprise that uses an WebRTC based web 424 application for communication and desires to audit all WebRTC based 425 application sessions used from inside the company towards any 426 external peer can deploy a PCP-controlled firewall and enforce a 427 policy on the PCP-controlled firewall to mandate PCP client 428 authentication. Only after successful authentication, PCP client 429 will be permitted to create dynamic mappings on the firewalls and 430 NATs. 432 3.10. NAT64 434 For the IPv6-only WebRTC client to establish media session with 435 IPv4-only WebRTC client it must learn prefix64(s). 437 The workaround for solving the problem is by using heuristics is 438 explained in [I-D.ietf-behave-nat64-discovery-heuristic]. Various 439 other solutions including STUN for discovery based on heuristics are 440 discussed in [I-D.ietf-behave-nat64-learn-analysis]. 442 PCP allows to learn PREFIX64 when a NAT64 is in the path 443 [I-D.ietf-pcp-nat64-prefix64]. PCP client can directly communicate 444 with PCP-controlled NAT64 device to learn the Prefix64(s). This 445 feature is useful to help establishing successful media session 446 between an IPv6-only WebRTC client and an IPv6-only WebRTC client. 447 The other advantages of using PCP is that endpoint will be notified 448 whenever the Network Specific Prefix (NSP) is changed and endpoint 449 will also learn multiple NSPs configured in the network. 451 Experimental results related to the use of this feature for SIP-based 452 applications in general are provided in Section 4.2 of 453 [I-D.boucadair-pcp-nat64-experiments]. 455 4. Usage of PCP with STUN and TURN 457 4.1. STUN 459 This section explains the procedure to use STUN and PCP with ICE 460 [RFC5245]: 462 The ICE agent learns external IP addresses and ports using the PCP 463 MAP opcode. If server reflexive candidates and external IP addresses 464 learnt using PCP are different than the candidates learnt through 465 STUN, the PCP discovered candidates are encoded in the ICE offer and 466 answer just like the server reflexive candidates learnt using STUN 467 [RFC5389]. When using the recommended formula explained in 468 Section 4.1.2.1 of [RFC5245] to compute priority for the candidate 469 learnt through PCP, the ICE agent should use a preference value 470 greater than the server reflexive candidate and hence they are tested 471 before the server reflexive candidates. 473 The recommended type preference value is 105 for candidates 474 discovered using PCP and is explained in section 4.2 of [RFC6544]. 476 During connectivity checks the ICE agent SHOULD check if the XOR- 477 MAPPED-ADDRESS from the STUN Binding response matches the external 478 address and port provided by PCP MAP response. 480 o If the match is successful, then it indicates that only PCP-aware 481 NATs exist between the peers. PCP can further be used to keep the 482 NAT bindings alive and close the mappings. 484 o If the match is not successful then it indicates PCP unaware NATs 485 exist between the peers. 487 4.2. TURN 489 TURN server may be used for the following reasons even if PCP capable 490 Firewalls and NATs exist: 492 o Users of WebRTC based web application may choose to use TURN so as 493 to not expose the host candidate addresses to the remote peer for 494 privacy reasons. 496 o IPv6 support in TURN includes IPv4-to-IPv6 and IPv6-to-IPv4 497 relaying [RFC6156]. 499 o ICE connectivity checks using the candidates provided by STUN and 500 PCP could fail because the endpoint is behind PCP-unaware NAT that 501 performs address-dependent mapping and thus only relayed candidate 502 allocated from the TURN server gets selected for media. 504 o TURN server could also be used for RTP Mobility 505 [I-D.wing-mmusic-ice-mobility], etc. 507 5. Security Considerations 509 Security considerations discussed in [RFC6887] are to be taken into 510 account. PCP authentication [I-D.ietf-pcp-authentication] MAY also 511 be used. 513 6. IANA Considerations 515 This document does not require any action from IANA. 517 7. Acknowledgments 519 The authors would like to thank Charles Eckel for review and 520 comments. 522 8. References 524 8.1. Normative References 526 [I-D.ietf-pcp-authentication] 527 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 528 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 529 authentication-01 (work in progress), October 2012. 531 [I-D.ietf-pcp-proxy] 532 Boucadair, M., Penno, R., and D. Wing, "Port Control 533 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02 534 (work in progress), February 2013. 536 [I-D.ietf-rtcweb-rtp-usage] 537 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 538 Communication (WebRTC): Media Transport and Use of RTP", 539 draft-ietf-rtcweb-rtp-usage-06 (work in progress), 540 February 2013. 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 546 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 547 October 2008. 549 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 550 Relays around NAT (TURN): Relay Extensions to Session 551 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 553 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 554 Customer Premises Equipment (CPE) for Providing 555 Residential IPv6 Internet Service", RFC 6092, January 556 2011. 558 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 559 Using Relays around NAT (TURN) Extension for IPv6", RFC 560 6156, April 2011. 562 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 563 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 564 2013. 566 8.2. Informative References 568 [I-D.boucadair-mmusic-altc] 569 Boucadair, M., Kaplan, H., Gilman, R., and S. 570 Veikkolainen, "Session Description Protocol (SDP) 571 Alternate Connectivity (ALTC) Attribute", draft-boucadair- 572 mmusic-altc-09 (work in progress), January 2013. 574 [I-D.boucadair-pcp-nat64-experiments] 575 Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. 576 Queiroz, "PCP NAT64 Experiments", draft-boucadair-pcp- 577 nat64-experiments-00 (work in progress), September 2012. 579 [I-D.cbran-rtcweb-nat] 580 Bran, C., Kaufman, M., Jennings, C., and J. Rosenberg, 581 "WebRTC Network Address Translation", draft-cbran-rtcweb- 582 nat-02 (work in progress), October 2011. 584 [I-D.hutton-rtcweb-nat-firewall-considerations] 585 Stach, T., Hutton, A., and J. Uberti, "RTCWEB 586 Considerations for NATs, Firewalls and HTTP proxies", 587 draft-hutton-rtcweb-nat-firewall-considerations-00 (work 588 in progress), March 2013. 590 [I-D.ietf-behave-nat64-discovery-heuristic] 591 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 592 the IPv6 Prefix Used for IPv6 Address Synthesis", draft- 593 ietf-behave-nat64-discovery-heuristic-17 (work in 594 progress), April 2013. 596 [I-D.ietf-behave-nat64-learn-analysis] 597 Korhonen, J. and T. Savolainen, "Analysis of solution 598 proposals for hosts to learn NAT64 prefix", draft-ietf- 599 behave-nat64-learn-analysis-03 (work in progress), March 600 2012. 602 [I-D.ietf-pcp-nat64-prefix64] 603 Boucadair, M., "Learn NAT64 PREFIX64s using PCP", draft- 604 ietf-pcp-nat64-prefix64-02 (work in progress), May 2013. 606 [I-D.ietf-pcp-port-set] 607 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 608 and S. Perreault, "Port Control Protocol (PCP) Extension 609 for Port Set Allocation", draft-ietf-pcp-port-set-01 (work 610 in progress), May 2013. 612 [I-D.ietf-rtcweb-overview] 613 Alvestrand, H., "Overview: Real Time Protocols for Brower- 614 based Applications", draft-ietf-rtcweb-overview-06 (work 615 in progress), February 2013. 617 [I-D.ietf-rtcweb-use-cases-and-requirements] 618 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 619 Time Communication Use-cases and Requirements", draft- 620 ietf-rtcweb-use-cases-and-requirements-10 (work in 621 progress), December 2012. 623 [I-D.reddy-pcp-optimize-keepalives] 624 Reddy, T., Isomaki, M., Wing, D., and P. Patil, 625 "Optimizing NAT and Firewall Keepalives Using Port Control 626 Protocol (PCP)", draft-reddy-pcp-optimize-keepalives-01 627 (work in progress), January 2013. 629 [I-D.reddy-rtcweb-mobile] 630 Reddy, T., Kaippallimalil, J., R, R., and R. Ejzak, 631 "Considerations with WebRTC in Mobile Networks", draft- 632 reddy-rtcweb-mobile-03 (work in progress), May 2013. 634 [I-D.rescorla-mmusic-ice-trickle] 635 Rescorla, E., Uberti, J., and E. Ivov, "Trickle ICE: 636 Incremental Provisioning of Candidates for the Interactive 637 Connectivity Establishment (ICE) Protocol", draft- 638 rescorla-mmusic-ice-trickle-01 (work in progress), October 639 2012. 641 [I-D.wing-mmusic-ice-mobility] 642 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 643 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 644 mobility-03 (work in progress), January 2013. 646 [I-D.zuniga-dmm-gap-analysis] 647 Zuniga, J., Bernardos, C., Melia, T., and C. Perkins, 648 "Mobility Practices and DMM Gap Analysis", draft-zuniga- 649 dmm-gap-analysis-03 (work in progress), December 2012. 651 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 652 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 653 RFC 4787, January 2007. 655 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 656 (ICE): A Protocol for Network Address Translator (NAT) 657 Traversal for Offer/Answer Protocols", RFC 5245, April 658 2010. 660 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 661 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 662 Partnership Project (3GPP) Evolved Packet System (EPS)", 663 RFC 6459, January 2012. 665 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B. 666 Roach, "TCP Candidates with Interactive Connectivity 667 Establishment (ICE)", RFC 6544, March 2012. 669 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B. 670 Roach, "TCP Candidates with Interactive Connectivity 671 Establishment (ICE)", RFC 6544, March 2012. 673 [TR33.830] 674 3GPP, , "3rd Generation Partnership Project; Technical 675 Specification Group Services and System Aspects; 676 Feasibility study on IMS firewall traversal (Release 677 12).", September 2012. 679 [TS23.060] 680 3GPP, , ""General Packet Radio Service (GPRS); Service 681 description; Stage 2", June 2012.", September 2012. 683 [TS23.401] 684 3GPP, , "General Packet Radio Service (GPRS) enhancements 685 for Evolved Universal Terrestrial Radio Access Network (E- 686 UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 687 06).", September 2012. 689 Authors' Addresses 691 Reinaldo Penno 692 Cisco Systems, Inc. 693 170 West Tasman Drive 694 San Jose 95134 695 USA 697 Email: repenno@cisco.com 699 Tirumaleswar Reddy 700 Cisco Systems, Inc. 701 Cessna Business Park, Varthur Hobli 702 Sarjapur Marathalli Outer Ring Road 703 Bangalore, Karnataka 560103 704 India 706 Email: tireddy@cisco.com 707 Dan Wing 708 Cisco Systems, Inc. 709 170 West Tasman Drive 710 San Jose, California 95134 711 USA 713 Email: dwing@cisco.com 715 Mohamed Boucadair 716 France Telecom 717 Rennes 35000 718 France 720 Email: mohamed.boucadair@orange.com