PCP            PCP        PCP
  Client         Aware     Unaware      __________
+-----------+   +------+   +------+    /          \   +-----------+
|Application|___| NAT/ |___| FW   |____| Internet |___|   STUN    |    
|  Client   |   | FW   |   |      |    |          |   |   Server  | 
+-----------+   +------+   +------+    \__________/   +-----------+    

      <--------------------------------------------------->
            STUN 

      <------------>
            PCP 
                              X<---------------------------
                 STUN based detection
               

        

Figure 5: PCP unaware firewall

This procedure can be adopted by other protocols to detect PCP unaware firewalls.

3.4. Keepalive Optimization

If the application determines that all NATs and firewalls on its path to the Internet support PCP, it can start using PCP instead of its default keepalives to maintain the NAT/FW state. It can use PCP PEER Request with the Requested Lifetime set to an appropriate value. The application may still send some application-specific heartbeat messages end-to-end to refresh state on the application server, which typically requires keepalives far less frequently than NATs /FWs do.

Processing the lifetime value of the PEER Opcode is described in Sections 10.3 and 15 of [RFC6887]. Sending a PEER request with a very short Requested Lifetime can be used to query the lifetime of an existing mapping. PCP recommends that lifetimes of mapping created or lengthened with PEER be longer than the lifetimes of implicitly-created NAT and firewall mappings. Thus PCP can be used to reduce power consumption by making PCP PEER message interval longer than what the application would normally use to the keep the middle box state alive, and strictly shorter than the server state refresh interval.

An example of savings with PCP is described in Appendix B.

4. Keepalive Interval Determination Procedure when PCP unaware Firewall or NAT is detected

If a PCP unaware NAT/firewall is detected, then a client can use the following heuristics method to determine the keepalive interval:

1. The client sends a STUN Binding request to the STUN server. This connection is called the Primary Channel. STUN server will return its alternate IP address and alternate port in OTHER-ADDRESS in the Binding response [RFC5780].
2. The client then sends a STUN Binding request to the STUN server using alternate IP address and alternate port. This connection is called the Secondary Channel.
3. The Client will initially set the default keepalive interval for NAT/FW mappings to 60 seconds (FWa).
4. After FWa seconds the Client will send a Binding request to the STUN server using the Primary Channel with the CHANGE-REQUEST attribute set to change-port and change-IP. This will cause the STUN server to send its response from the Secondary channel.
5. If the client receives response from the server then it will increase the keepalive interval value FWa = (old FWa) + (old FWa)/2. This indicates that NAT/FW mappings are alive.
6. Steps 4 and 5 will be repeated until there is no response from the STUN server. If there is no response from the STUN server then the client will use the old FWa value as Keepalive interval to refresh FW/NAT mappings.

The above procedure will be done separately for each transport protocol. For connectionless transport protocols such as UDP, if 2 seconds elapse without a response from the STUN server then the client will repeat step 4 at most three times to handle packet loss.

This procedure can be adopted by other protocols to use Primary and Secondary channels, so that the client can determine the keepalive interval to refresh FW/NAT mapping. This procedure only serves as a guideline and if applications already use some other heuristic to determine the keepalive interval, they can continue with the existing logic. For example Teredo determines the Refresh interval using the procedure in "Optional Refresh Interval Determination Procedure" (Section 5.2.7 of [RFC4380]).

Note: The keepalive interval learnt using the above method can be inaccurate if a firewall is configured with an application-specific inactivity timeout.

To improve reliability, applications SHOULD continue to use PCP to lengthen the FW/NAT mappings even if the above mechanism is used to a detect PCP unaware NAT/firewall. This ensures that PCP aware FW/NATs do not close old mappings with no packet exchange when there is a resource-scarcity situation.

5. Application-Specific Operation

This section describes how PCP is used with specific application protocols.

5.1. SIP

For connection-less transports the User Agent (UA) sends a STUN Binding request over the SIP flow as described in section 4.4.2 of [RFC5626]. The UA then learns the External IP Address and Port using a PCP PEER request/response. If the XOR-MAPPED-ADDRESS in the STUN Binding response matches the external address and port provided by PCP PEER response then the UA optimizes the keepalive traffic as described in Section 3.4. There is no further need to send STUN Binding requests over the SIP flow to keep the NAT Binding alive.

If the XOR-MAPPED-ADDRESS in the STUN Binding response does not match the external address and port provided by the PCP PEER response then PCP will not be used to keep the NAT bindings alive for the flow that is being used for the SIP traffic. This means that multiple layers of NAT are involved and intermediate NATs are not PCP aware. In this case the UA will continue to use the technique in section 4.4.2 of [RFC5626].

For connection-oriented transports, the UA sends a STUN Binding request multiplexed with SIP over the TCP connection. STUN multiplexed with other data over a TCP or TLS-over-TCP connection is explained in section 7.2.2 of [RFC5389]. The UA then learns the External IP address and port using a PCP PEER request/response. If the XOR-MAPPED-ADDRESS in the STUN Binding response matches the external address and port provided by the PCP PEER response, then the UA optimizes the keepalive traffic as described in Section 3.4.

If the XOR-MAPPED-ADDRESS in the STUN Binding response does not match the external address and port provided by the PCP PEER response, then PCP will not be used to keep the NAT bindings alive. In this case the UA performs a keepalive check by sending a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong") using the technique in section 4.4.1 of [RFC5626].

5.2. HTTP

Web Applications that require persistent connections use techniques such as HTTP long polling and Websockets for session keep alive as explained in section 3.1 of [I-D.isomaki-rtcweb-mobile]. In such scenarios, after the client establishes a connection with the HTTP server, it can execute server side scripts such as PHP residing on the server to provide the transport address and port of the HTTP client seen at the HTTP server. In addition, the HTTP client also learns the external IP Address and port using a PCP PEER request/response.

If the IP address and port learned from the server matches the external address and port provided by the PCP PEER response then the HTTP client optimizes keepalive traffic as described in Section 3.4.

If the IP address and port do not match, then PCP will not be used to keep the NAT bindings alive for the flow that is being used for the HTTP traffic. This means that there are NATs or HTTP proxies between the PCP server and the HTTP server. The HTTP client will have to resort to use existing techniques for keep alive. Please see Appendix A for an example server side PHP script to obtain the client source IP address.

The HTTP protocol allows intermediaries such as transparent proxies to be involved and there is no way for the client to know that a request/response is relayed through a proxy.

5.3. Media and data channels with ICE

The ICE agent learns the External IP Addresses and Ports using the PCP MAP opcode. If server reflexive candidates learnt using STUN [RFC5389] and external IP addresses learnt using PCP are different then candidates learnt through both STUN and PCP are encoded in the ICE offer and answer . When using the Recommended Formula explained in section 4.1.2.1 of [RFC5245] to compute priority for the candidate learnt through PCP, the ICE agent MUST use a preference value greater than the server reflexive candidate and hence tested before the server reflexive candidate. The recommended type preference value is 105 for candidates discovered using PCP and is explained in section 4.2 of [RFC6544].

The ICE agent, in addition to the ICE connectivity checks, performs the following:

1. The ICE agent checks if the XOR-MAPPED-ADDRESS from the STUN Binding response received as part of ICE connectivity check matches the External IP address and Port provided by PCP MAP response.
2. If the match is successful then PCP will be used to keep the NAT bindings alive. The ICE agent optimizes keepalive traffic by refreshing the mapping via a new PCP MAP request containing information from the earlier PCP response.
3. If the match is not successful then PCP will not be used for keep NAT binding alive. The ICE agent will use the technique in section 4.4 of [RFC6263] to keep NAT bindings alive. This means that multiple layers of NAT are involved and intermediate NATs are not PCP- aware.

Some network operators deploying a PCP Server may allow PEER but not MAP. In such cases the ICE agent learns the external IP address and port using a STUN Binding request/response during ICE connectivity checks. The ICE agent also learns the external IP Address and port using a PCP PEER request/response. If the IP address and port learned from the STUN Binding response matches the external address and port provided by the PCP PEER response then the ICE agent optimizes keepalive traffic as described in Section 3.4.

5.4. Detecting Flow Failure

Using the Rapid Recovery technique in section 14 of [RFC6887] upon receiving a PCP ANNOUNCE from a PCP server, a PCP client becomes aware that the PCP server has rebooted or lost its mapping state. The PCP client issues new PCP requests to recreate any lost mapping state and thus reconstructs lost mappings fast enough that existing media, HTTP and SIP flows do not break. If the NAT state cannot be recovered the endpoint will find the new external address and port as part of the Rapid Recovery technique in PCP itself and reestablish a connection with the peer.

5.5. Firewalls

PCP allows applications to communicate with firewall devices with PCP functionality to create mappings for incoming connections. In such cases PCP can be used by the endpoint to create an explicit mapping on firewall in order to permit inbound traffic. The endpoint can further use PCP to send keepalives to keep the firewall mappings alive.

5.5.1. IPv6 Network with Firewalls

For scenarios where the client uses the ICE Lite implementation explained in section 2.7 of [RFC5245], the ICE Lite endpoint will not generate its own ICE connectivity checks, by definition. As part of the call setup, the ICE Lite endpoint would gather its host candidates and relayed candidate from a TURN server and send the candidates in the offer to the peer endpoint. On receiving the answer from the peer endpoint, the ICE Lite endpoint sends a PCP MAP request with FILTER opcode to create a dynamic mapping in the firewall to permit ICE connectivity checks and subsequent media traffic from the remote peer. This way, the ICE Lite endpoint and its network are protected from unsolicited incoming UDP traffic, and can still operate using ICE Lite (rather than full ICE).

5.5.2. Mobile Network with Firewalls

Some mobile networks are also making use of a firewall to protect their customers from various attacks like downloading malicious content. The firewall is usually configured to block all unknown inbound connections as explained in section 2.1 of [I-D.chen-pcp-mobile-deployment]. As described in Section 3.4, in such cases, PCP can be used by mobile devices to create an explicit mapping on the firewall to permit inbound traffic and optimize the keepalive traffic. This would result in saving of radio and power consumption of the mobile device while protecting it from attacks.

6. IANA Considerations

This document has no actions for IANA.

7. Security Considerations

The security considerations in [RFC5245] and [RFC6887] apply to this use.

8. Acknowledgements

Authors would like to thank Dave Thaler, Basavaraj Patil, Anca Zamfir, Reinaldo Penno, Suresh Kumar, Dilipan Janarthanan and Mohamed Boucadair for their valuable inputs.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Example PHP script

<html>
Connected to <?PHP echo gethostname(); ?> on port <?PHP echo
getenv(SERVER_PORT)?> on <?PHP echo date("d-M-Y H:i:s");?> 
Pacific Time
<p>
Your IP address is: <?PHP echo getenv(REMOTE_ADDR); ?>,
port <?PHP echo getenv(REMOTE_PORT); ?>
</p>;
</html>

Appendix B. Savings with PCP

The following example illustrates the savings in keepalive messages with PCP.

             

     PCP               PCP        
    Client            Server         __________
+-----------+        +------+       /          \   +-----------+
|Application|________| NAT/ |_______| Internet |___|Application|    
|  Client   |        |  FW  |       |          |   |   Server  | 
+-----------+        +------+       \__________/   +-----------+    

With Application Heartbeat (without PCP):

      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
             ....
             ....
             ....
             ....

With PCP:
      <------------------>
        PCP PEER request 
     (Max Lifetime = 3600 seconds)
             ....
             ....              
      <------------------>
        PCP PEER request 
     (Max Lifetime = 3600 seconds)
    

        PCP                PCP              PCP
       Client             Proxy/           Server
                          Server                     __________
   +-----------+         +------+         +------+  /          \   +-----------+
   |Application|_________| NAT/ |_________| NAT/ |__| Internet |___|Application|
   |  Client   |         |  FW  |         |  FW  |  |          |
   +-----------+         +------+         +------+  \__________/   +-----------+
                           <-multiple NAT/FW->

      <------------------>  <------------------>
        PCP PEER request      PCP PEER request