idnits 2.17.00 (12 Aug 2021) /tmp/idnits61578/draft-boucadair-pcp-sip-ipv6-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 26, 2015) is 2361 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-pcp-port-set has been published as RFC 7753 == Outdated reference: draft-ietf-tsvwg-rtcweb-qos has been published as RFC 8837 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Informational R. Parthasarathi 5 Expires: May 29, 2016 Nokia Networks 6 November 26, 2015 8 Port Control Protocol (PCP) for SIP Deployments in Managed Networks 9 draft-boucadair-pcp-sip-ipv6-07 11 Abstract 13 This document discusses how PCP (Port Control Protocol) can be used 14 in SIP deployments in managed networks. This document applies for 15 both IPv4 and IPv6. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 29, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. PCP Features . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Learn External IP Address and Port Number . . . . . . . . 4 54 2.2. Learn and Set the Lifetime of Mapping Entries . . . . . . 6 55 2.3. Allow Unidirectional Media Flows . . . . . . . . . . . . 6 56 2.4. Preserve Port Parity . . . . . . . . . . . . . . . . . . 7 57 2.5. Preserve Port Contiguity . . . . . . . . . . . . . . . . 7 58 2.6. Learn PREFIX64 . . . . . . . . . . . . . . . . . . . . . 8 59 2.7. Compliant with "a=rtcp" Attribute . . . . . . . . . . . . 10 60 2.8. DSCP Marking Policy . . . . . . . . . . . . . . . . . . . 10 61 3. Avoid Crossing CGNs . . . . . . . . . . . . . . . . . . . . . 11 62 3.1. Avoid NAT64 . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.2. Avoid Crossing DS-Lite AFTR . . . . . . . . . . . . . . . 12 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 7.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 72 1. Introduction 74 The base Port Control Protocol (PCP, [RFC6887]) specification allows 75 to retrieve the external IP address and external port to be conveyed 76 in the SIP signaling messages [RFC3261]. Therefore, SIP Proxy 77 Servers do not need to support means to ease the NAT traversal of SIP 78 messages (e.g., [RFC5626], [RFC6223], etc.). Another advantage of 79 using the external IP address and port is this provides a hint to the 80 proxy server there is no need to return a small expire timer (e.g., 81 60s). In addition, the outbound proxy does not need any further 82 feature to be supported in order to assist the remote endpoint to 83 successfully establish media sessions. In particular, ALGs are not 84 required in the NAT for this purpose and no dedicated functions at 85 the media gateway are needed. 87 This document discusses how PCP can be used in SIP deployments 88 (including IPv6 considerations). 90 The benefits of using PCP for SIP deployments are listed below: 92 o Avoid embedding an ALG in the middleboxes. Note, ALGs are not 93 recommended since the evolution of the service would depend on the 94 ALG maintenance. 96 o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to 97 be embedded in the SIP server. Intermediate NATs and firewalls 98 are transparent to the SIP service platform. 100 o Avoid overloading the network with keepalive message to maintain 101 the mapping in intermediate middleboxes. 103 Note, mechanisms such as STUN do not allow to discover the 104 lifetime assigned by the middleboxes; frequent keepalive messages 105 are therefore generated to maintain binding entries on those 106 middleboxes. PCP is superior to those mechanisms as it allows to 107 retrieve the assigned lifetime, and to provide hints to the 108 middleboxes in order to decide which lifetime value is to be 109 assigned for that particular flow. 111 o Work without requiring symmetric RTP/RTCP [RFC4961]. 113 o Not require symmetric SIP to work (i.e., rport [RFC3581]). 115 o Easily support unidirectional sessions. 117 o Does not encounter issues with early media. 119 o The combination of PCP and ALTC [RFC6947] allows to optimize 120 IPv4-IPv6 interworking function resources. 122 o Because there is no need for connectivity checks, session 123 establishment delay is not impacted (pairs of ports can be pre- 124 reserved). 126 o The binding entries maintained by a flow-aware device (NAT/ 127 Firewall) can be associated with a textual description 128 ([RFC7220]). 130 Experimentation results, including SIP flow examples, are documented 131 in [I-D.boucadair-pcp-nat64-experiments]. 133 In deployments where ICE [RFC5245] is required, PCP can be of great 134 help as discussed in [I-D.penno-rtcweb-pcp] for the WebRTC case. ICE 135 can be used in the context of SIP over WebSocket [RFC7118] and WebRTC 136 when deployed within managed networks. Because TURN suffers from 137 limitations in traversing NAT and firewalls over UDP, PCP is a 138 promising solution that can complement ICE in those deployment 139 contexts to soften the experienced high failure rate [ICEFailure]. 141 The document targets SIP deployments in managed networks. It can 142 also be used as part of SIP-based services delivery in the context of 143 network-located residential gateway effort [WT-317]. Typical 144 deployment scenarios are shown in Figure 1. 146 (a) SIP UA behind a NAT/FW communicating with a Proxy Server 147 __________ 148 +----------+ +----------+ / \ +------------+ 149 | SIP UA |___| NAT/FW |____| Network |___| SIP Proxy | 150 |PCP Client| |PCP Server| | | | Server | 151 +----------+ +----------+ \__________/ +------------+ 153 (b) SIP UA behind a NAT/FW communicating with a remote SIP UA 154 __________ 155 +----------+ +----------+ / \ +------------+ 156 | SIP UA |___| NAT/FW |____| Network |___| SIP UA | 157 |PCP Client| |PCP Server| | | | | 158 +----------+ +----------+ \__________/ +------------+ 160 (c) SIP UAs behind a NATs/FWs 161 __________ 162 +----------+ +----------+ / \ +----------+ +----------+ 163 | SIP UA |__| NAT/FW |__| Network |__| NAT/FW |__| SIP UA | 164 |PCP Client| |PCP Server| | | |PCP Server| |PCP Client| 165 +----------+ +----------+ \__________/ +----------+ +----------+ 167 (d) SIP UA behind a CPE: PCP Proxy 169 +----------+ +---------+ +----------+ 170 | SIP UA |____| CPE |__________| CGN/FW | 171 |PCP Client| |PCP Proxy| |PCP Server| 172 +----------+ +---------+ +----------+ 174 Figure 1: Typical deployment scenarios 176 The PCP server can be provisioned using a variety of means (e.g., 177 [RFC7291]) or rely on the discovery method specified in [RFC6887]. 179 This document does not make any assumption whether the PCP client is 180 implemented as an OS service or whether it is integrated in the SIP 181 User Agent (UA). Those considerations are implementation-service. 183 2. PCP Features 185 2.1. Learn External IP Address and Port Number 187 The PCP base specification allows to create mappings in PCP- 188 controlled devices and therefore prepare for receiving incoming 189 packets. A SIP UA can use PCP to create one mapping for SIP 190 signalling messages and other mappings for media session purposes. 192 The SIP UA uses the external IP address and port number to build SIP 193 headers. In particular, this information is used to build the VIA 194 and CONTACT headers. 196 Figure 2 shows an example of the flow exchange that occurs to 197 retrieve the external IP address and an external IP address assigned 198 by the NAT, while Figure 2 provides an excerpt of the SIP REGISTER 199 message issued by the SIP UA; only the assigned IP address and port 200 number are present in the SIP headers. 202 +---------+ +-------+ +------------+ 203 | SIP UA | | NAT | | IPv4 SIP | 204 | PCP | |+ PCP | |Proxy Server| 205 | Client | |Server | | "Mysip.fr" | 206 +---------+ +-------+ +------------+ 207 | (a) PCP MAP | | 208 |Suggested External IP@ | | 209 | ::ffff:0.0.0.0| | 210 |Suggested External Port| | 211 | 5060| | 212 |======================>| | 213 | (b) PCP MAP | | 214 |Suggested External IP@ | | 215 | ::ffff:192.0.2.1| | 216 |Suggested External Port| | 217 | 3938| | 218 |<======================| | 219 | (1)SIP REGISTER |(2)SIP REGISTER | 220 |======================>|===============>| 221 | (4) SIP 200 OK | (3) SIP 200 OK | 222 |<======================|<===============| 223 | | | 225 Figure 2: SIP REGISTER Call Flow 227 SIP Message: 228 REGISTER sip:mysip.fr SIP/2.0 229 Via: SIP/2.0/UDP 192.0.2.1:3938;branch=z9hG4bK1572043597 230 From: ;tag=893886783 231 To: 232 Call-ID: 1271173454 233 CSeq: 2 REGISTER 234 Contact: 235 Authorization: Digest username="client4", realm="asterisk", 236 nonce="09f75e47", uri="sip:mysip.fr", 237 response="826fcff4c6e84ee45fbfa52c351e6316", algorithm=MD5 238 Max-Forwards: 70 239 User-Agent: Linphone/3.4.0 (eXosip2/unknown) 240 Expires: 3600 242 Figure 3: Example of REGISTER messager 244 The external IP address and port(s) instantiated for media streams, 245 are used to build the SDP offer/answer. In particular, the "c" line 246 and "m" lines. 248 2.2. Learn and Set the Lifetime of Mapping Entries 250 PCP allows to discover and to set the lifetime of mapping 251 instantiated in intermediate middleboxes. 253 The discovery of the lifetime of a mapping avoids overloading the 254 network and SIP servers with frequent messages. This is in 255 particular important for cellular devices. According to [Power], the 256 consumption of a cellular device with a keep-alive interval equal to 257 20 seconds (that is the default value in [RFC3948] for example) is 29 258 mA (2G)/34 mA (3G). This consumption is reduced to 16 mA (2G)/24 mA 259 (3G) when the interval is increased to 40 seconds, to 9.1 mA (2G)/16 260 mA (3G) if the interval is equal to 150 seconds, and to 7.3 mA 261 (2G)/14 mA (3G) if the interval is equal to 180 seconds. When no 262 keep-alive is issued, the consumption would be 5.2 mA (2G)/6.1 mA 263 (3G). The impact of keepalive messages would be more severe if 264 multiple applications are issuing those messages (e.g., SIP, IPsec, 265 etc.). 267 2.3. Allow Unidirectional Media Flows 269 As a consequence of instantiating mappings for media/session flows, 270 incoming packets can be successfully forwarded to the appropriate SIP 271 UA. Particularly, unidirectional media flows (e.g., announcement 272 server) will be forwarded accordingly. 274 2.4. Preserve Port Parity 276 For deployments relying on classic RTP/RTCP odd/even port numbers 277 assignment scheme, PORT_SET option [I-D.ietf-pcp-port-set] can be 278 used by a SIP UA to request port parity be preserved by the PCP 279 server. 281 An example is depicted in Figure 4. 283 2.5. Preserve Port Contiguity 285 For deployments assuming RTCP port number can be deduced from the RTP 286 port number, PORT_SET option [I-D.ietf-pcp-port-set] can be used by a 287 SIP UA to retrieve a pair of contiguous ports from the PCP server. 289 A flow example is shown in Figure 4. 291 +---------+ +-------+ +------------+ 292 | SIP UA | | NAT | | IPv4 SIP | 293 | PCP | |+ PCP | |Proxy Server| 294 | Client | |Server | | "Mysip.fr" | 295 +---------+ +-------+ +------------+ 296 | (a) PCP MAP | | 297 |Suggested External IP@ | | 298 | ::ffff:192.0.2.1| | 299 |Suggested External Port| | 300 | 6000| | 301 | PORT_SET: | | 302 | "P" bit set to 1 | | 303 | Port Set Size=2 | | 304 |======================>| | 305 | (b) PCP MAP | | 306 |Assigned External IP@ | | 307 | ::ffff:192.0.2.1| | 308 |Assigned External Port | | 309 | 7076| | 310 | PORT_SET: | | 311 | "P" bit set to 1 | | 312 | Port Set Size=2 | | 313 |<======================| | 314 | | | 316 Figure 4: Retrieve a pair of ports that preserves port parity 318 2.6. Learn PREFIX64 320 If the SIP UA is located behind a NAT64 device [RFC6146], the option 321 defined in [RFC7225] can be used to retrieve the PREFIX64 used by 322 that NAT64 device. 324 The retrieved prefix will be used to locally build an IPv6-converted 325 IPv4 address ([RFC6052]) corresponding to the IPv4 address included 326 in the SDP message received from a remote IPv4-enabled SIP UA; the 327 SDP message can be an SDP offer or an answer. 329 +---------+ +-----+ +------------+ +---------+ 330 |IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only| 331 | SIP UA | | | |Proxy Server| | SIP UA | 332 +---------+ +-----+ +------------+ +---------+ 333 | (a) PCP MAP Request | | | 334 |Suggested External IP@ | | | 335 | ::ffff:192.0.2.1| | | 336 |Suggested External Port| | | 337 | 6000| | | 338 | PORT_SET | | | 339 | PREFIX64 | | | 340 |======================>| | | 341 | (b) PCP MAP Response | | | 342 |Assigned External IP@ | | | 343 | ::ffff:192.0.2.1| | | 344 |Assigned External Port | | | 345 | 7076| | | 346 | PORT_SET | | | 347 | PREFIX64: | | | 348 | 2001:db8:122::/48 | | | 349 |<======================| | | 350 | (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE | 351 |======================>|===============>|================>| 352 | (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK | 353 |<======================|<===============|<================| 354 | (7) SIP ACK | (8) SIP ACK | (9) SIP ACK | 355 |======================>|===============>|================>| 356 | | | | 357 |src port: dst port:|src port: dst port:| 358 |6000 port_B|7076 port_B| 359 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 360 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 361 |src port: dst port:|src port: dst port:| 362 |6001 port_B+1|7077 port_B+1| 363 | | | 365 Figure 5: Example of IPv6 to IPv4 SIP-Initiated Session 367 Figure 6 shows the content of the SIP INVITE message sent by the 368 IPv6-only SIP UA. This message uses the retrieved external IP 369 address and external port numbers in SIP headers and SDP lines. This 370 message is translated by the NAT64 without altering the SIP/SDP 371 content. 373 INVITE sip:13@mysip.fr:5070 SIP/2.0 374 Via: SIP/2.0/UDP 192.0.2.1:56252;branch=z9hG4bK1876803184 375 From: ;tag=631384602 376 To: Call-ID: 1377792765 CSeq: 21 INVITE 377 Contact: 378 Authorization: Digest username="client4", realm="asterisk", 379 nonce="3358d80b", uri="sip:13@mysip.fr:5070", 380 response="41442e94f6610e6f383a355a1bdf3e48", algorithm=MD5 381 Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, 382 BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO 383 Max-Forwards: 70 384 User-Agent: Linphone/3.4.0 (eXosip2/unknown) 385 Subject: Phone call Content-Length: 443 387 v=0 388 o=client4 2487 2487 IN IP4 192.0.2.1 389 s=Talk c=IN IP4 192.0.2.1 390 b=AS:256 391 t=0 0 392 m=audio 7076 RTP/AVP 111 110 3 101 393 a=rtpmap:111 speex/16000 394 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 395 a=fmtp:110 vbr=on a=rtpmap:3 GSM/8000 396 a=rtpmap:101 telephone-event/8000 397 a=fmtp:101 0-11 398 m=video 9076 RTP/AVP 102 99 399 a=rtpmap:102 H264/90000 400 a=fmtp:102 profile-level-id=428014 401 a=rtpmap:99 MP4V-ES/90000 402 a=fmtp:99 403 profile-level-id=3 405 Figure 6: Content of the INVITE message 407 2.7. Compliant with "a=rtcp" Attribute 409 The base PCP specification can be used to retrieve the port number to 410 be singled if "a=rtcp" attribute is in use [RFC3550]. 412 2.8. DSCP Marking Policy 414 PCP can be used to discover the DSCP value to be used when sending 415 real-time flows or to create a mapping that matches a DSCP marking. 416 This can be achieved using the DSCP option defined in 417 [I-D.boucadair-pcp-extensions]. DSCP setting value is configured by 418 the network and not the SIP UA. 420 This feature can be used as an input for DSCP marking in some 421 deployments such as [I-D.ietf-tsvwg-rtcweb-qos]. 423 3. Avoid Crossing CGNs 425 3.1. Avoid NAT64 427 Because an IPv6-only SIP UA is not aware of the connectivity 428 capabilities of the remote UA, the IPv6-only SIP UA uses the ALTC 429 attribute [RFC6947] to signal the assigned IPv6 address and the IPv4 430 address learned via PCP. 432 If the remote SIP UA is IPv6-enabled, IPv6 transfer capabilities will 433 be used to place the session. If the remote SIP UA is IPv4-only, 434 IPv4 transfer capabilities will be used. NAT64 devices will be 435 crossed only if the remote UA is IPv4-only. 437 Figure 7 provides an except of a SIP INVITE message that encloses 438 both the local IPv6 address and the IPv4 address/port number assigned 439 by a NAT64 device. 441 INVITE sip:13@mysip.fr:5070 SIP/2.0 442 Via: SIP/2.0/UDP 192.0.2.1:35011;branch=z9hG4bK702695557 443 From: ;tag=641336337 444 To: 445 Call-ID: 1532307201 446 CSeq: 20 INVITE 447 Contact: 448 Content-Type: application/sdp 449 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, 450 MESSAGE, SUBSCRIBE, INFO 451 Max-Forwards: 70 452 User-Agent: Linphone/3.4.0 (eXosip2/unknown) 453 Subject: Phone call 454 Content-Length: 538 456 v=0 457 o=client4 3867 3867 IN IP4 192.0.2.1 458 s=Talk 459 c=IN IP4 192.0.2.1 460 b=AS:256 461 t=0 0 462 m=audio 7056 RTP/AVP 111 110 3 101 463 a=altc:1 IP6 2001:db8:1f94:3000:6c73:ea54:cef:2730 45678 464 a=altc:2 IP4 192.0.2.1 7056 466 Figure 7: Content of the INVITE message (with ALTC Attribute) 468 3.2. Avoid Crossing DS-Lite AFTR 470 SIP UAs co-located with the B4 [RFC6333] or located behind the CPE 471 can behave as dual-stack UAs: 473 o Native IPv6 address is assigned locally. 475 o The external IPv4 address and port is retrieved using PCP. 477 To avoid unnecessary invocation of AFTR resources, ALTC attribute is 478 used to signal both IPv4 and IPv6 addresses. If the remote SIP UA is 479 IPv6-enabled, IPv6 transfer capabilities will be used to place the 480 session (i.e., the flows will avoid crossing the DS-Lite AFTR 481 device). If the remote SIP UA is IPv4-only, IPv4 transfer 482 capabilities will be used. AFTR devices will be crossed only if the 483 remote UA is IPv4-only. 485 4. Security Considerations 487 PCP-related security considerations are discussed in [RFC6887]. 489 Security considerations related to the discovery of PREFIX64 are 490 discussed in Section 7 of [RFC7225] and those related to retrieving a 491 set of ports are discussed in Section 7 of [I-D.ietf-pcp-port-set]. 493 An attacker that wants to intercept media flows, without requiring 494 intercepting SIP signalling message, can insert a fake PCP server 495 that will influence the content of SIP messages so that an 496 illegitimate node is inserted in the media path. Such behavior is 497 not desirable. Means to prevent the PCP client from discovering 498 illegitimate PCP servers must be enforced. Within the context of 499 this document, the network on which the PCP messages are to be sent 500 is fully trusted. For example, access control lists (ACLs) can be 501 installed on the PCP client, PCP server, and the network between 502 them, so those ACLs allow only communications from a trusted PCP 503 client to the PCP server. 505 5. IANA Considerations 507 This document does not require any action from IANA. 509 6. Acknowledgements 511 Many thanks for T. Reddy and S. Kiesel for their review. 513 7. References 515 7.1. Normative References 517 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 518 A., Peterson, J., Sparks, R., Handley, M., and E. 519 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 520 DOI 10.17487/RFC3261, June 2002, 521 . 523 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 524 Session Initiation Protocol (SIP) for Symmetric Response 525 Routing", RFC 3581, DOI 10.17487/RFC3581, August 2003, 526 . 528 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 529 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 530 DOI 10.17487/RFC6887, April 2013, 531 . 533 7.2. Informative References 535 [I-D.boucadair-pcp-extensions] 536 Boucadair, M., Penno, R., and D. Wing, "Some Extensions to 537 Port Control Protocol (PCP)", draft-boucadair-pcp- 538 extensions-03 (work in progress), April 2012. 540 [I-D.boucadair-pcp-nat64-experiments] 541 Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. 542 Queiroz, "PCP NAT64 Experiments", draft-boucadair-pcp- 543 nat64-experiments-00 (work in progress), September 2012. 545 [I-D.ietf-pcp-port-set] 546 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 547 T., and S. Perreault, "Port Control Protocol (PCP) 548 Extension for Port Set Allocation", draft-ietf-pcp-port- 549 set-13 (work in progress), October 2015. 551 [I-D.ietf-tsvwg-rtcweb-qos] 552 Dhesikan, S., Jennings, C., Druta, D., and P. Jones, "DSCP 553 and other packet markings for WebRTC QoS", draft-ietf- 554 tsvwg-rtcweb-qos-05 (work in progress), October 2015. 556 [I-D.penno-rtcweb-pcp] 557 Penno, R., Reddy, T., Wing, D., and M. Boucadair, "PCP 558 Considerations for WebRTC Usage", draft-penno-rtcweb- 559 pcp-00 (work in progress), May 2013. 561 [ICEFailure] 562 Telemetry Dashboard, "WEBRTC_ICE_SUCCESS_RATE", March 563 2015, . 568 [Power] Haverinen, H., Siren, J., and P. Eronen, "Energy 569 Consumption of Always-On Applications in WCDMA Networks", 570 April 2007, . 573 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 574 Jacobson, "RTP: A Transport Protocol for Real-Time 575 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 576 July 2003, . 578 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 579 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 580 RFC 3948, DOI 10.17487/RFC3948, January 2005, 581 . 583 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 584 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 585 . 587 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 588 (ICE): A Protocol for Network Address Translator (NAT) 589 Traversal for Offer/Answer Protocols", RFC 5245, 590 DOI 10.17487/RFC5245, April 2010, 591 . 593 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 594 "Managing Client-Initiated Connections in the Session 595 Initiation Protocol (SIP)", RFC 5626, 596 DOI 10.17487/RFC5626, October 2009, 597 . 599 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 600 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 601 DOI 10.17487/RFC6052, October 2010, 602 . 604 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 605 NAT64: Network Address and Protocol Translation from IPv6 606 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 607 April 2011, . 609 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 610 RFC 6223, DOI 10.17487/RFC6223, April 2011, 611 . 613 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 614 Stack Lite Broadband Deployments Following IPv4 615 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 616 . 618 [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. 619 Veikkolainen, "The Session Description Protocol (SDP) 620 Alternate Connectivity (ALTC) Attribute", RFC 6947, 621 DOI 10.17487/RFC6947, May 2013, 622 . 624 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 625 "The WebSocket Protocol as a Transport for the Session 626 Initiation Protocol (SIP)", RFC 7118, 627 DOI 10.17487/RFC7118, January 2014, 628 . 630 [RFC7220] Boucadair, M., Penno, R., and D. Wing, "Description Option 631 for the Port Control Protocol (PCP)", RFC 7220, 632 DOI 10.17487/RFC7220, May 2014, 633 . 635 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 636 Port Control Protocol (PCP)", RFC 7225, 637 DOI 10.17487/RFC7225, May 2014, 638 . 640 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 641 the Port Control Protocol (PCP)", RFC 7291, 642 DOI 10.17487/RFC7291, July 2014, 643 . 645 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 646 Traversal (HNT) for Media in Real-Time Communication", 647 RFC 7362, DOI 10.17487/RFC7362, September 2014, 648 . 650 [WT-317] Broadband Forum, "Network Enhanced Residential Gateway 651 (NERG)", 2015, . 654 Authors' Addresses 656 Mohamed Boucadair 657 France Telecom 658 Rennes 35000 659 France 661 Email: mohamed.boucadair@orange.com 663 Parthasarathi Ravindran 664 Nokia Networks 665 Manyata Embassy Business park 666 Bangalore, Karnataka 560045 667 India 669 Email: partha@parthasarathi.co.in