keepalive messages to be exchanged between hosts and servers for the purpose of preserving the mapping. As a result, network usage and power consumption are reduced, and application-level keepalive logic no longer needs to be implemented at client and server sides. The PCP mapping response provides the application with associated externally visible parameters (IP address, protocol and port) that can then be announced to other clients in application-specific ways so incoming connections can be established. Additionally, PCP can inform applications when the external IP address is changed while a mapping is already established. Various types of NAT can be handled by PCP, providing support for NAT64, NAT66, and NAT44; inclusion of PCP into IPv4 and IPv6 firewall devices is also supported. PCP is designed to be used on both large-scale aggregation points (for example, as part of carrier-grade NATs), and inside less expensive consumer-grade devices. Both long-term (for an IP camera or a temperature sensor acting as a server, for example) and short-term mappings (while playing an online computer game, for example) are supported. PCP supports transport layer protocols that use 16-bit port numbers (for example, TCP, UDP, Stream Control Transmission Protocol (SCTP) or Datagram Congestion Control Protocol (DCCP). Protocols that do not use port numbers (for example, Resource Reservation Protocol (RSVP), Encapsulating Security Payload (ESP), ICMP or ICMPv6) are supported for IPv4 firewall, IPv6 firewall and NPTv6 (IPv6 prefix translation) functions, but cannot be supported by more than one client per external IP address in the case of NAT. The PCP specification does not define a mechanism for dealing with multi-homed networks (which have multiple network gateways or default routes). It is nonetheless possible to implement PCP in such networks using a coordination mechanism such as conntrackd. However, if the different networks each have their own external IP address(es), a given PCP mapping can only use one or the other because the protocol requires one specific external IP address to be provided to the client. If that network should then become unavailable the PCP mapping would have to be updated to use an external IP address from the other network. The PCP specification does not define a mechanism for dealing how to inform remote computers about the IP address, protocol, and port for the incoming connection. RFC6887 states, that PCP does not provide any rendezvous function and this has to been done in an application-specific manner, like using external