idnits 2.17.1 draft-reddy-pcp-optimize-keepalives-01.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 (January 21, 2013) is 4106 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) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Experimental RFC: RFC 5780 == Outdated reference: A later version (-04) exists of draft-chen-pcp-mobile-deployment-02 -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP T. Reddy 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Isomaki 5 Expires: July 25, 2013 Nokia 6 D. Wing 7 P. Patil 8 Cisco 9 January 21, 2013 11 Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) 12 draft-reddy-pcp-optimize-keepalives-01 14 Abstract 16 This document describes how Port Control Protocol is useful to reduce 17 NAT and firewall keepalive messages for a variety of applications. 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 July 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 3 57 3.2. NAT and Firewall Topologies and Detection . . . . . . . . 5 58 3.3. Detect PCP Unaware Firewalls . . . . . . . . . . . . . . . 7 59 3.4. Keepalive Optimization . . . . . . . . . . . . . . . . . . 7 60 4. Keepalive Interval Determination Procedure when PCP 61 unaware Firewall or NAT is detected . . . . . . . . . . . . . 7 62 5. Application-Specific Operation . . . . . . . . . . . . . . . . 9 63 5.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. Media and data channels with ICE . . . . . . . . . . . . . 10 66 5.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 11 67 5.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5.1. IPv6 Network with Firewalls . . . . . . . . . . . . . 11 69 5.5.2. Mobile Network with Firewalls . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Changes from draft-reddy-pcp-optimize-keepalives-00 . . . 12 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Appendix A. Example PHP script . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Many types of applications need to keep their Network Address 84 Translator (NAT) and Firewall (FW) mappings alive for long periods of 85 time, even when they are otherwise not sending or receiving any 86 traffic. This is typically done by sending periodic keep-alive 87 messages just to prevent the mappings from expiring. As NAT/FW 88 mapping timers may be short and unknown to the endpoint, the 89 frequency of these keep-alives may be high. An IPv4 or IPv6 host can 90 use the Port Control Protocol (PCP)[I-D.ietf-pcp-base] to flexibly 91 manage the IP address and port mapping information on NATs and FWs to 92 facilitate communications with remote hosts. This document describes 93 how PCP can be used to reduce keep-alive messages for both client- 94 server and peer-to-peer type of communication. 96 The mechanism described in this document is especially useful in 97 cellular mobile networks, where frequent keep-alive messages make the 98 radio transition between active and power-save states causing 99 signaling congestion. The excessive time spent on the active state 100 due to keep-alives also greatly reduces the battery life of the 101 cellular connected devices such as smartphones or tablets. 102 Requirement #14 in [I-D.binet-v6ops-cellular-host-reqs-rfc3316update] 103 explains that cellular host SHOULD support of PCP as a driver to save 104 battery consumption exacerbated by keepalive messages. 106 2. Notational Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 This note uses terminology defined in [RFC5245] and 113 [I-D.ietf-pcp-base] . 115 3. Overview of Operation 117 3.1. Application Scenarios 119 PCP can help both client-server and peer-to-peer applications to 120 reduce their keep-alive rate. The relevant applications are the ones 121 that need to keep their NAT/FW mappings alive for long periods of 122 time, for instance to be able to send or receive application messages 123 in both directions at any time. 125 A typical client-server scenario is depicted in Figure 1. A client, 126 who may reside behind one or multiple layers of NATs/FWs, opens a 127 connection to a globally reachable server, and keeps it open to be 128 able to receive messages from the server at any time. The connection 129 may be a connection-oriented transport protocol such as TCP or SCTP 130 or connection-less transport protocol such as UDP. Protocols 131 operating in this manner include Session Initiation Protocol (SIP) 132 [RFC3261], Extensible Messaging and Presence Protocol (XMPP) 133 [RFC3921], Internet Mail Application Protocol (IMAP) [RFC2177] with 134 its IDLE command, the WebSocket protocol and the various HTTP long- 135 polling protocols. There are also a number of proprietary instant 136 messaging, Voice over IP, e-mail and notification delivery protocols 137 that belong in this category. All of these protocols aim to keep the 138 client-server connection alive for as long as the application is 139 running. When the application has otherwise no traffic to send, 140 specific keep-alive messages are sent periodically to ensure that the 141 NAT/FW state in the middle does not expire. The client can use PCP 142 to keep the required mapping at the NAT/FW and use application keep- 143 alives to keep the state on the Application Server/Peer as mentioned 144 in Section 3.4. 146 PCP PCP 147 Client Server __________ 148 +-----------+ +------+ / \ +-----------+ 149 |Application|___| NAT/ |____| Internet |___|Application| 150 | Client | | FW | | | | Server | 151 +-----------+ +------+ \__________/ +-----------+ 152 (multiple 153 layers) 155 ------------> PCP 157 -----------------------------------------> 158 Application keep-alive 160 Figure 1: PCP with Client-Server applications 162 There are also scenarios where the long-term communication 163 association is between two peers, both of whom may reside behind one 164 or more layers of NAT/FW. This is depicted in Figure 2. The 165 initiation of the association may have happened using mechanisms such 166 as Interactive Communications Establishment (ICE), perhaps first 167 triggered by a "signaling" protocol such as SIP or XMPP or RTCWeb. 168 Examples of the peer-to-peer protocols include RTP and RTCWeb data 169 channel. A number of proprietary VoIP or video call or streaming or 170 file transfer protocols also exist in this category. Typically the 171 communication is based on UDP, but TCP or SCTP may be used. Unless 172 there is no traffic flowing otherwise, the peers have to inject 173 periodic keep-alive packets to keep the NAT/FW mappings on both sides 174 of the communication active. Instead of application keep-alives, 175 both peers can use PCP to control the mappings on the NAT/FWs to 176 reduce the keep-alive frequency as explained in Section 3.4. 178 PCP PCP PCP PCP 179 Client Server __________ Server Client 180 +-----------+ +------+ / \ +------+ +-----------+ 181 |Application|___| NAT/ |____| Internet |___| NAT/ |___|Application| 182 | Peer | | FW | | | | FW | | Peer | 183 +-----------+ +------+ \__________/ +------+ +-----------+ 184 (multiple (multiple 185 layers) layers) 187 ------------> PCP PCP <------------ 189 <---------------------------------------------------> 190 Application keep-alive 192 Figure 2: PCP with Peer-to-Peer applications 194 3.2. NAT and Firewall Topologies and Detection 196 Before an application can reduce its keep-alive rate, it has to make 197 sure it has all of the NATs and Firewalls on its path under control. 198 This means it has to detect the presence of any PCP-unaware NATs and 199 Firewalls on its path. PCP itself is able to detect unexpected NATs 200 between the PCP client and server as depicted in Figure 3. The PCP 201 client includes its own IP address and UDP port within the PCP 202 request. The PCP server compares them to the source IP address and 203 UDP port it sees on the packet. If they differ, there are one or 204 more additional NATs between the PCP client and server, and the 205 server will return an error. Unless the application has some other 206 means to control these PCP unaware NATs, it has to fall back to its 207 default keep-alive mechanism. 209 PCP PCP PCP 210 Client Unaware Aware __________ 211 +-----------+ +------+ +------+ / \ +-----------+ 212 |Application|___| NAT |___| NAT/ |____| Internet |___|Application| 213 | Client | | | | FW | | | | Server | 214 +-----------+ +------+ +------+ \__________/ +-----------+ 216 <-----------///----------> 217 PCP based detection 219 Figure 3: PCP unaware NAT between PCP client and server 221 Figure 4 shows a topology where one or more PCP unaware NATs are 222 deployed on the exterior of the PCP capable NAT/FWs. To detect this, 223 the application must have the capability to request from its server 224 or peer what IP and transport address it sees. If those differ from 225 the IP and transport address given to the application by the out most 226 PCP aware NAT/FW, the application can detect that there is at least 227 one more PCP unaware NAT on the path. In this case, the application 228 has to fall back to its default keep-alive mechanism. 230 PCP PCP PCP 231 Client Aware Unaware __________ 232 +-----------+ +------+ +------+ / \ +-----------+ 233 |Application|___| NAT/ |___| NAT |____| Internet |___|Application| 234 | Client | | FW | | | | | | Server | 235 +-----------+ +------+ +------+ \__________/ +-----------+ 237 <------------> 238 PCP 240 <---------------------///---------------------------> 241 Application based detection 243 Figure 4: PCP unaware NAT external to the last PCP aware NAT 245 Section 5 describes how the detection works in a number of real 246 application protocols. 248 The caveat is that Firewalls can not be detected this way. The 249 client will have to use the alternative procedure explained in 250 Section 3.3 to detect PCP unaware Firewalls. 252 3.3. Detect PCP Unaware Firewalls 254 The client sends a STUN Binding Request to the STUN server. STUN 255 server will return its alternate IP address and alternate port in 256 OTHER-ADDRESS in the binding response [RFC5780]. The client then 257 sends MAP request with FILTER option to PCP server to permit STUN 258 server to reach the client using the STUN servers alternate IP 259 address and alternate port. The client then sends a binding request 260 to the primary address of the STUN server with the CHANGE-REQUEST 261 attribute set to change-port and change-IP. This will cause the 262 server to send its response from its alternate IP address and 263 alternate port. If the client receives a response then the client is 264 aware that on path Firewall devices are PCP aware. If the client 265 does not receive a response then the client is aware that could be 266 one or more on path PCP unaware Firewall devices. PCP client will 267 perform the tests separately for each transport protocol. If no 268 response is received, the client will then repeat the test atmost 269 three times for connectionless transport protocols. 271 If the STUN server does not support OTHER-ADDRESS then this test 272 cannot be run. This procedure can be adopted by other protocols to 273 detect PCP unaware Firewalls. 275 3.4. Keepalive Optimization 277 If the application determines that all NATs and Firewalls on its path 278 to the Internet support PCP, it can start using PCP instead of its 279 default keep-alives to maintain the NAT/FW state. It can use PCP 280 PEER Request with the Requested Lifetime set to an appropriate value. 281 The application may still send some application-specific heartbeat 282 messages end-to-end. 284 Processing the lifetime value of the PEER Opcode is described in 285 Section 15 of [I-D.ietf-pcp-base]. Sending a PEER request with a 286 very short Requested Lifetime can be used to query the lifetime of an 287 existing mapping. PCP recommends that lifetimes of mapping created 288 or lengthened with PEER be longer than the lifetimes of implicitly- 289 created NAT and Firewall mappings. Thus PCP can be used to save 290 battery consumption by making PCP PEER message interval longer than 291 what the application would normally use the keep middle box state 292 alive, and strictly shorter than the server state refresh interval. 294 4. Keepalive Interval Determination Procedure when PCP unaware Firewall 295 or NAT is detected 297 If PCP unaware NAT/Firewall is detected then a client can use the 298 following heuristics method to determine the keepalive interval : 300 1. The client sends a STUN Binding Request to the STUN server. This 301 connection is called the Primary Channel. STUN server will 302 return its alternate IP address and alternate port in OTHER- 303 ADDRESS in the binding response [RFC5780]. 305 2. The client then sends STUN Binding Request to the STUN server 306 using alternate IP address and alternate port. This connection 307 is called the Secondary Channel. 309 3. The Client will initially set the default keepalive interval for 310 NAT/FW mappings to 60 seconds (FWa). 312 4. After FWa seconds the Client will send a binding request to the 313 STUN server using the Primary Channel with the CHANGE-REQUEST 314 attribute set to change-port and change-IP. This will cause the 315 STUN server to send its response from the Secondary channel. 317 5. If the client receives response from the server then it will 318 increase the keepalive interval value FWa = (old FWa) + (old 319 FWa)/2. This indicates that NAT/FW mappings are alive. 321 6. Steps 4 and 5 will be repeated until there is no response from 322 the STUN server. If there is no response from the STUN server 323 then the client will use the FWa value as Keepalive interval to 324 refresh FW/NAT mappings. 326 The above procedure will be done separately for each transport 327 protocol. For connectionless transport protocols like UDP if timer 328 of 2 seconds elapses without response from the STUN server then the 329 client will repeat step 4 atmost three times to handle packet loss. 331 This procedure can be adopted by other protocols to use Primary and 332 Secondary channels, so that the client can determine the keepalive 333 interval to refresh FW/NAT mapping. This procedure only serves as a 334 guideline and if applications already use some other heuristics 335 method to determine keepalive, they can continue with the existing 336 logic. For example Teredo determines Refresh interval using the 337 procedure in "Optional Refresh Interval Determination Procedure" 338 (Section 5.2.7 of [RFC4380]). 340 To improve reliability, applications SHOULD continue to use PCP to 341 lengthen the FW/NAT mappings even if the above described mechanism is 342 used to detect PCP unaware NAT/Firewall. This ensures that PCP aware 343 FW/NAT do not close old mappings with no packet exchange when there 344 is a resource-crunch situation. 346 5. Application-Specific Operation 348 This section describes how PCP is used with specific application 349 protocols. 351 5.1. SIP 353 For connection-less transports the User Agent (UA) sends a STUN 354 Binding Request over the SIP flow as described in section 4.4.2 of 355 [RFC5626]. The UA then learns the External IP Address and Port using 356 a PEER request/response. If the XOR-MAPPED-ADDRESS in the STUN 357 Binding Response matches the external address and port provided by 358 PCP PEER response then the UA optimizes the keepalive traffic as 359 described in Section 3.4. There is no further need to send STUN 360 Binding Requests over the SIP flow to keep the NAT binding alive. 362 If the XOR-MAPPED-ADDRESS in the STUN Binding Response does not match 363 the external address and port provided by the PCP PEER response then 364 PCP will not be used to keep the NAT bindings alive for the flow that 365 is being used for the SIP traffic. This means that multiple layers 366 of NAT are involved and intermediate NATs are not PCP aware. In this 367 case the UA will continue to use the technique in section 4.4.2 of 368 [RFC5626]. 370 For connection-oriented transports, the UA sends a STUN Binding 371 Request multiplexed with SIP over the TCP connection. STUN 372 multiplexed with other data over a TCP or TLS-over-TCP connection is 373 explained in section 7.2.2 of [RFC5389]. The UA then learns the 374 External IP address and port using a PEER request/response. If the 375 XOR-MAPPED-ADDRESS in the STUN Binding Response matches the external 376 address and port provided by PCP PEER response then the UA optimizes 377 the keepalive traffic as described in Section 3.4. 379 If the XOR-MAPPED-ADDRESS in the STUN Binding Response does not match 380 the external address and port provided by PCP PEER response then PCP 381 will not be used to keep the NAT bindings alive. In this case the UA 382 performs a keep-alive check by sending a double-CRLF (the "ping") 383 then waits to receive a single CRLF (the "pong") using the technique 384 in section 4.4.1 of [RFC5626]. 386 5.2. HTTP 388 Web Applications that require persistent connections use techniques 389 such as HTTP long polling and Websockets for session keep alive as 390 explained in section 3.1 of [I-D.isomaki-rtcweb-mobile]. In such 391 scenarios, after the client establishes a connection with the HTTP 392 server, it can execute server side scripts such as PHP residing on 393 the server to provide the transport address and port of the HTTP 394 client seen at the HTTP server. In addition, the HTTP client also 395 learns the external IP Address and port using the PCP PEER request/ 396 response. 398 If the IP address and port learned from the server matches the 399 external address and port provided by PCP PEER response then the HTTP 400 client optimizes keepalive traffic as described in Section 3.4. 402 If the IP address and port do not match then PCP will not be used to 403 keep the NAT bindings alive for the flow that is being used for the 404 HTTP traffic. This means that there are NATs or HTTP proxies between 405 the PCP server and the HTTP server. The HTTP client will have to 406 resort to use existing techniques for keep alive. Please see 407 Appendix A for an example server side PHP script to obtain the client 408 source IP address. 410 HTTP protocol allows intermediaries like transparent proxies to be 411 involved and there is no way for the client to know that request/ 412 response is relayed through a proxy. 414 5.3. Media and data channels with ICE 416 The ICE agent learns the External IP Address and Port using a MAP 417 request/response. This candidate learnt through PCP is encoded in 418 the ICE offer and answer just like the server reflexive candidate, If 419 the server reflexive candidate and External IP address learnt using 420 PCP are different. When using the Recommended Formula in section 421 4.1.2.1 of [RFC5245] to compute priority for the candidates learnt 422 through PCP, the ICE agent can use a preference value greater than or 423 equal to the server reflexive candidates. 425 The ICE agent in addition to ICE connectivity checks and performs the 426 following : 428 The ICE agent checks if the XOR-MAPPED-ADDRESS from the STUN 429 [RFC5389] Binding response received as part of ICE connectivity check 430 matches the external address and port provided by PCP MAP response. 432 1. If the match is successful then PCP will be used to keep the NAT 433 bindings alive. The ICE agent optimizes keepalive traffic by 434 refreshing the mapping via a new PCP MAP request containing 435 information from the earlier PCP response. 437 2. If the match is not successful then PCP will not be used for keep 438 NAT binding alive. The ICE agent will use the technique in 439 section 4.4 of [RFC6263] to keep NAT bindings alive. This means 440 that multiple layers of NAT are involved and intermediate NATs 441 are not PCP aware. 443 Some network operators deploying a PCP Server may allow PEER but not 444 MAP. In such cases the ICE agent learns the external IP address and 445 port using a STUN binding request/response during ICE connectivity 446 checks. The ICE agent also learns the external IP Address and port 447 using a PCP PEER request/response. If the IP address and port 448 learned from the STUN binding response matches the external address 449 and port provided by the PCP PEER response then the ICE agent 450 optimizes keepalive traffic as described in Section 3.4. 452 5.4. Detecting Flow Failure 454 Using the Rapid Recovery technique in section 14 of 455 [I-D.ietf-pcp-base] PCP client upon receiving a PCP ANNOUNCE from a 456 PCP server becomes aware that PCP server has rebooted or lost its 457 mapping state. The PCP client issues new PCP requests to recreate 458 any lost mapping state and thus reconstructs lost mappings fast 459 enough that existing media, HTTP and SIP flows do not break. If the 460 NAT state cannot be recovered the endpoint will find the new external 461 address and port as part of the Rapid Recovery technique in PCP 462 itself and reestablish a connection with the peer. 464 In lieu of this mechanism if a PCP server reboots and loses its 465 mapping state or when a NAT gateway has its external IP address 466 changed so that its current mapping state becomes invalid, it may 467 take some time before the endpoints realize that the connectivity is 468 lost. 470 5.5. Firewalls 472 PCP allows applications to communicate with Firewall devices with PCP 473 functionality to create mappings for incoming connections. In such 474 cases PCP can be used by the endpoint to create an explicit mapping 475 on Firewall to permit inbound traffic and further use PCP to send 476 keep-alives to keep the Firewall mappings alive. 478 5.5.1. IPv6 Network with Firewalls 480 As part of the call setup, the endpoint would gather its host 481 candidates and relayed candidate from a TURN server, send the 482 candidates in the offer to the peer endpoint. On receiving the 483 answer from the peer endpoint, the PCP client sends a PCP MAP request 484 with FILTER opcode to create a dynamic mapping in Firewall to permit 485 ICE connectivity checks and subsequent media traffic from the remote 486 peer. 488 5.5.2. Mobile Network with Firewalls 490 Mobile Networks are also making use of a Firewall to protect their 491 customers from various attacks like downloading malicious content. 492 The Firewall is usually configured to block all unknown inbound 493 connections as explained in section 2.1 of 494 [I-D.chen-pcp-mobile-deployment]. In such cases PCP can be used by 495 Mobile devices to create an explicit mapping on the Firewall to 496 permit inbound traffic and optimize the keepalive traffic as 497 described in Section 3.4. This would result in saving of radio and 498 power consumption of the Mobile device while protecting it from 499 attacks. 501 6. IANA Considerations 503 None 505 7. Security Considerations 507 The security considerations in [RFC5245]and [I-D.ietf-pcp-base] apply 508 to this use. 510 8. Acknowledgements 512 Authors would like to thank Dave Thaler, Basavaraj Patil for valuable 513 inputs to the document. 515 9. Change History 517 [Note to RFC Editor: Please remove this section prior to 518 publication.] 520 9.1. Changes from draft-reddy-pcp-optimize-keepalives-00 522 o Added sections 3.3, 4 524 o Updated section 3 an 3.4 and Introduction 526 10. References 527 10.1. Normative References 529 [I-D.ietf-pcp-base] 530 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 531 Selkirk, "Port Control Protocol (PCP)", 532 draft-ietf-pcp-base-29 (work in progress), November 2012. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 538 (ICE): A Protocol for Network Address Translator (NAT) 539 Traversal for Offer/Answer Protocols", RFC 5245, 540 April 2010. 542 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 543 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 544 October 2008. 546 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 547 Initiated Connections in the Session Initiation Protocol 548 (SIP)", RFC 5626, October 2009. 550 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 551 Using Session Traversal Utilities for NAT (STUN)", 552 RFC 5780, May 2010. 554 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 555 Keeping Alive the NAT Mappings Associated with RTP / RTP 556 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 558 10.2. Informative References 560 [I-D.binet-v6ops-cellular-host-reqs-rfc3316update] 561 Binet, D., Boucadair, M., Ales, V., Byrne, C., and G. 562 Chen, "Internet Protocol Version 6 (IPv6) for Cellular 563 Hosts", 564 draft-binet-v6ops-cellular-host-reqs-rfc3316update-03 565 (work in progress), October 2012. 567 [I-D.chen-pcp-mobile-deployment] 568 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 569 Thiebaut, "Analysis of Port Control Protocol in Mobile 570 Network", draft-chen-pcp-mobile-deployment-02 (work in 571 progress), October 2012. 573 [I-D.isomaki-rtcweb-mobile] 574 Isomaki, M., "RTCweb Considerations for Mobile Devices", 575 draft-isomaki-rtcweb-mobile-00 (work in progress), 576 July 2012. 578 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 580 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 581 A., Peterson, J., Sparks, R., Handley, M., and E. 582 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 583 June 2002. 585 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 586 Protocol (XMPP): Instant Messaging and Presence", 587 RFC 3921, October 2004. 589 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 590 Network Address Translations (NATs)", RFC 4380, 591 February 2006. 593 Appendix A. Example PHP script 594 595 Connected to on port on Pacific Time 597

598 Your IP address is: , 599 port 600

; 601 603 Authors' Addresses 605 Tirumaleswar Reddy 606 Cisco Systems, Inc. 607 Cessna Business Park, Varthur Hobli 608 Sarjapur Marathalli Outer Ring Road 609 Bangalore, Karnataka 560103 610 India 612 Email: tireddy@cisco.com 613 Markus Isomaki 614 Nokia 615 Keilalahdentie 2-4 616 FI-02150 Espoo 617 Finland 619 Email: markus.isomaki@nokia.com 621 Dan Wing 622 Cisco Systems, Inc. 623 170 West Tasman Drive 624 San Jose, California 95134 625 USA 627 Email: dwing@cisco.com 629 Prashanth Patil 630 Cisco Systems, Inc. 631 Cessna Business Park, Varthur Hobli 632 Sarjapur Marthalli Outer Ring Road 633 Bangalore, Karnataka 560103 634 India 636 Email: praspati@cisco.com