requests; at the same time, all previously described explicit mapping constraints still apply. Internals Internally, PCP works by exchanging control messages between hosts and PCP-enabled NAT devices or firewalls (referred to as servers), using User Datagram Protocol (UDP) as the underlying protocol. This communication consists of port mapping requests created by the hosts that result in responses once submitted to and processed by the servers. Following UDP's nature of unreliability, which means that UDP datagrams can be lost, duplicated or reordered, after submitting a request there is no guarantee for a response of any kind, thus host requests are also referred to as "hints". In addition to direct responses, servers also generate gratuitous notifications for example, unicast notifications to inform hosts of changes in the external IP address. Exchanged messages contain no means for determining either the transaction they belong to, or which stage of a "session" they represent. Such a simplified design is based on having all messages self-describing and complete, with no additional context required for each message to be successfully processed. Servers may decide to silently ignore host requests, in case they are unable to process them at the moment; in such cases, hosts need to retransmit the request. Also, hosts may safely decide to silently ignore any unwanted mapping responses. For the purpose of creating PCP requests, IP address of the server is either manually configured on the host, found as part of the host's DHCP lease, or set to the host's configured default gateway. Host request messages are sent from any source UDP port on a client to the server's UDP port 5351 that it listens to; unsolicited multicast server notifications (such as server restart announcements) are sent from the server's UDP port 5351 to the UDP port 5350 on hosts which they listen to. Maximum UDP payload length for all PCP messages is 1100 octets. Each PCP message consists of a request or response header containing an opcode that determines the associated operation, any relevant opcode-specific information (such as which ports are to be mapped), and zero or more options (such as the option described above). Result codes are returned as part of server responses; each result code has an associated lifetime, which tells the hosts when certain operations may be retried or should be repeated. For example, result lifetimes can specify how long a failure condition is expected to persist, or how long