0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mapping Nonce (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internal Port | Suggested External Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Suggested External IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Peer Port | Reserved (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Remote Peer IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: PEER Opcode Request These fields are described below: Requested Lifetime (in common header): Requested lifetime of this mapping, in seconds. Note that it is not possible to reduce the lifetime of a mapping (or delete it, with requested lifetime=0) using PEER. Mapping Nonce: Random value chosen by the PCP client. See Section 12.2, "Generating a PEER Request". Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).
Protocol: Upper-layer protocol associated with this Opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the Opcode is describing a TCP mapping. This field contains 17 (UDP) if the Opcode is describing a UDP mapping. Protocol MUST NOT be zero. Reserved: 24 reserved bits, MUST be set to 0 on transmission and MUST be ignored on reception. Internal Port: Internal port for the mapping. Internal port MUST NOT be zero. Suggested External Port: Suggested external port for the mapping. If the PCP client does not know the external port, or does not have a preference, it MUST use 0. Suggested External IP Address: Suggested external IP address for the mapping. If the PCP client does not know the external address, or does not have a preference, it MUST use the address-family- specific all-zeros address (see Section 5). Remote Peer Port: Remote peer's port for the mapping. Remote peer port MUST NOT be zero. Reserved: 16 reserved bits, MUST be set to 0 on transmission and MUST be ignored on reception. Remote Peer IP Address: Remote peer's IP address. This is from the perspective of the PCP client, so that the PCP client does not need to concern itself with NAT64 or NAT46 (which both cause the client's idea of the remote peer's IP address to differ from the remote peer's actual IP address). This field allows the PCP client and PCP server to disambiguate multiple connections from the same port on the internal host to different servers. An IPv6 address is represented directly, and an IPv4 address is represented using the IPv4-mapped address syntax (Section 5). When attempting to re-create a lost mapping, the suggested external IP address and port are set to the External IP Address and Port fields received in a previous PEER response from the PCP server. On an initial PEER request, the external IP address and port are set to zero. Note that semantics similar to the PREFER_FAILURE option are automatically implied by PEER requests. If the Suggested External IP Address or Suggested External Port fields are non-zero, and the PCP server is unable to honor the suggested external IP address, protocol, or port, then the PCP server MUST return a
CANNOT_PROVIDE_EXTERNAL error response. The PREFER_FAILURE option is neither required nor allowed in PEER requests, and if a PCP server receives a PEER request containing the PREFER_FAILURE option it MUST return a MALFORMED_REQUEST error response. The following diagram shows the Opcode response for the PEER Opcode: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mapping Nonce (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internal Port | Assigned External Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Assigned External IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Peer Port | Reserved (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Remote Peer IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: PEER Opcode Response Lifetime (in common header): On a success response, this indicates the lifetime for this mapping, in seconds. On an error response, this indicates how long clients should assume they'll get the same error response from the PCP server if they repeat the same request. Mapping Nonce: Copied from the request. Protocol: Copied from the request. Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST be ignored on reception.
Internal Port: Copied from request. Assigned External Port: On a success response, this is the assigned external port for the mapping. On an error response, the suggested external port is copied from the request. Assigned External IP Address: On a success response, this is the assigned external IPv4 or IPv6 address for the mapping. On an error response, the suggested external IP address is copied from the request. Remote Peer Port: Copied from request. Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST be ignored on reception. Remote Peer IP Address: Copied from the request. Section 10.3). PEER requests are also useful for restoring mappings after a NAT has lost its mapping state (e.g., due to a crash). The Mapping Nonce value is randomly chosen by the PCP client, following accepted practices for generating unguessable random numbers [RFC4086], and is used as part of the validation of PCP responses (see below) by the PCP client, and validation for mapping refreshes by the PCP server. The client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. The client MAY use a different mapping nonce for every mapping.
The PEER Opcode contains a Remote Peer Address field, which is always from the perspective of the PCP client. Note that when the PCP-controlled device is performing address family translation (NAT46 or NAT64), the remote peer address from the perspective of the PCP client is different from the remote peer address on the other side of the address family translation device. Section 16.3.1, "Recreating Mappings"). Thereafter, this PEER- created mapping is treated as if it was an implicit dynamic outbound mapping (e.g., as if the PCP client sent a TCP SYN) and a lifetime appropriate to such a mapping is returned (note: on many NATs and firewalls, such mapping lifetimes are very short until bidirectional traffic is seen by the NAT or firewall). If no matching mapping is found, and the suggested external address and port cannot be honored, then no new state is created, and the error CANNOT_PROVIDE_EXTERNAL is returned.
If a matching mapping is found, and no previous PEER Opcode was successfully processed for this mapping, then the Suggested External Address and Port values in the request are ignored, the lifetime of that mapping is adjusted as described below, and information about the existing mapping is returned. This allows a client to explicitly extend the lifetime of an existing mapping and/or to learn an existing mapping's external address, port, and lifetime. The mapping nonce is remembered for this mapping. If operating in the Simple Threat Model (Section 18.1), and the internal port, protocol, and internal address match a mapping that already exists, but the mapping nonce does not match (that is, a previous PEER request was processed), the request MUST be rejected with a NOT_AUTHORIZED error with the lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each mapping. This specification makes no statement about mapping nonce with the Advanced Threat Model. Processing the Lifetime value of the PEER Opcode is described in Section 15, "Mapping Lifetime and Deletion". Sending a PEER request with a very short requested lifetime can be used to query the lifetime of an existing mapping. So that PCP clients can reduce the frequency of their NAT and firewall keepalive messages, it is RECOMMENDED that lifetimes of mappings created or lengthened with PEER be longer than the lifetimes of implicitly created mappings. If all of the preceding operations were successful (did not generate an error response), then a SUCCESS response is generated, with the Lifetime field containing the lifetime of the mapping. If a PEER-created or PEER-managed mapping is not renewed using PEER, then it reverts to the NAT's usual behavior for implicit mappings. For example, continued outbound traffic keeps the mapping alive, as per the NAT or firewall device's existing policy. A PEER-created or PEER-managed mapping may be terminated at any time by action of the TCP client or server (e.g., due to TCP FIN or TCP RST), as per the NAT or firewall device's existing policy.
protocol, the internal port, the remote peer address, the remote peer port, and the mapping nonce. Other fields are not compared, because the PCP server sets those fields to provide information about the mapping created by the Opcode. The PCP server will send a Mapping Update (Section 14.2) if the mapping changes (e.g., due to IP renumbering). If the result code is NO_RESOURCES and the request was for the creation or renewal of a mapping, then the PCP client SHOULD NOT send further requests for any new mappings to that PCP server for the (limited) value of the lifetime. On a successful response, the application can use the assigned Lifetime value to reduce its frequency of application keepalives for that particular NAT mapping. Of course, there may be other reasons, specific to the application, to use more frequent application keepalives. For example, the PCP assigned lifetime could be one hour but the application may want to maintain state on its server (e.g., "busy" / "away") more frequently than once an hour. If the response indicates an unexpected IP address or port (e.g., due to IP renumbering), the PCP client will want to re-establish its connection to its remote server. If the PCP client wishes to keep this mapping alive beyond the indicated lifetime, it MAY rely on continued inside-to-outside traffic to ensure that the mapping will continue to exist, or it MAY issue a new PCP request prior to the expiration. The recommended timings for renewing PEER mappings are the same as for MAP mappings, as described in Section 11.2.1. Note: Implementations need to expect the PEER response may contain an external IP address with a different family than the remote peer IP address, e.g., when NAT64 or NAT46 are being used.
messages are to be sent is fully trusted. For example, if access control lists (ACLs) are installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications from a trusted PCP client to the PCP server. A management device would use this option to control a PCP server on behalf of users. For example, a management device located in a network operations center, which presents a user interface to end users or to network operations staff, and issues PCP requests with the THIRD_PARTY option to the appropriate PCP server. The THIRD_PARTY option is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code=1 | Reserved | Option Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Internal IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: THIRD_PARTY Option The fields are described below: Internal IP Address: Internal IP address for this mapping. Option Name: THIRD_PARTY Number: 1 Purpose: Indicates the MAP or PEER request is for a host other than the host sending the PCP option. Valid for Opcodes: MAP, PEER Length: 16 octets May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1 A THIRD_PARTY option MUST NOT contain the same address as the source address of the packet. This is because many PCP servers may not implement the THIRD_PARTY option at all, and with those servers a client redundantly using the THIRD_PARTY option to specify its own IP address would cause such mapping requests to fail where they would otherwise have succeeded. A PCP server receiving a THIRD_PARTY option specifying the same address as the source address of the packet MUST return a MALFORMED_REQUEST result code.
A PCP server MAY be configured to permit or to prohibit the use of the THIRD_PARTY option. If this option is permitted, properly authorized clients may perform these operations on behalf of other hosts. If this option is prohibited, and a PCP server receives a PCP MAP request with a THIRD_PARTY option, it MUST generate a UNSUPP_OPTION response. It is RECOMMENDED that customer premises equipment implementing a PCP server be configured to prohibit third-party mappings by default. With this default, if a user wants to create a third-party mapping, the user needs to interact out-of-band with their customer premises router (e.g., using its HTTP administrative interface). It is RECOMMENDED that service provider NAT and firewall devices implementing a PCP server be configured to permit the THIRD_PARTY option, when sent by a properly authorized host. If the packet arrives from an unauthorized host, the PCP server MUST generate an UNSUPP_OPTION error. Note that the THIRD_PARTY option is not needed for today's common scenario of an ISP offering a single IP address to a customer who is using NAT to share that address locally, since in this scenario all the customer's hosts appear, from the point of view of the ISP, to be a single host. When a PCP client is using the THIRD_PARTY option to make and maintain mappings on behalf of some other device, it may be beneficial if, where possible, the PCP client verifies that the other device is actually present and active on the network. Otherwise, the PCP client risks maintaining those mappings forever, long after the device that required them has gone. This would defeat the purpose of PCP mappings having a finite lifetime so that they can be automatically deleted after they are no longer needed. PNP-IGD-PCP], where the semantics of UPnP IGDv1
only allow the UPnP IGDv1 client to dictate mapping a specific port), or separate port allocation systems that allocate ports to a subscriber (e.g., a subscriber-accessed web portal operated by the same ISP that operates the PCP server). A PCP server MAY support this option, if its designers wish to support such downstream devices or separate port allocation systems. PCP servers that are not intended to interface with such systems are not required to support this option. PCP clients other than UPnP IGDv1 interworking clients or other than a separate port allocation system SHOULD NOT use this option because it results in inefficient operation, and they cannot safely assume that all PCP servers will implement it. It is anticipated that this option will be deprecated in the future as more clients adopt PCP natively and the need for this option declines. The PREFER_FAILURE option is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code=2 | Reserved | Option Length=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: PREFER_FAILURE Option Option Name: PREFER_FAILURE Number: 2 Purpose: indicates that the PCP server should not create an alternative mapping if the suggested external port and address cannot be mapped. Valid for Opcodes: MAP Length: 0 May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1 The result code CANNOT_PROVIDE_EXTERNAL is returned if the suggested external address, protocol, and port cannot be mapped. This can occur because the external port is already mapped to another host's outbound dynamic mapping, an inbound dynamic mapping, a static mapping, or the same internal address, protocol, and port already have an outbound dynamic mapping that is mapped to a different external port than suggested. This can also occur because the external address is no longer available (e.g., due to renumbering). The server MAY set the lifetime in the response to the remaining lifetime of the conflicting mapping + TIME_WAIT [RFC0793], rounded up to the next larger integer number of seconds.
If a PCP request contains the PREFER_FAILURE option and has zero in the Suggested External Port field, then it is invalid. The PCP server MUST reject such a message with the MALFORMED_OPTION error code. PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE requests, to protect themselves from a rapid flurry of 65535 consecutive PREFER_FAILURE requests from clients probing to discover which external ports are available. There can exist a race condition between the MAP Opcode using the PREFER_FAILURE option and Mapping Update (Section 14.2). For example, a previous host on the local network could have previously had the same internal address, with a mapping for the same internal port. At about the same moment that the current host sends a MAP Request using the PREFER_FAILURE option, the PCP server could send a spontaneous Mapping Update for the old mapping due to an external configuration change, which could appear to be a reply to the new mapping request. Because of this, the PCP client MUST validate that the external IP address, protocol, port, and nonce in a success response match the associated suggested values from the request. If they do not match, it is because the Mapping Update was sent before the MAP request was processed.
traffic to a specific source address or group of source addresses, such software already needs to check the source address of incoming traffic and reject unwanted traffic. However, the FILTER option is a particularly useful performance optimization for battery powered wireless devices, because it can enable them to conserve battery power by not having to wake up just to reject unwanted traffic. The FILTER option is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code=3 | Reserved | Option Length=20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Prefix Length | Remote Peer Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Remote Peer IP address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: FILTER Option Layout These fields are described below: Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored when received. Prefix Length: indicates how many bits of the IPv4 or IPv6 address are relevant for this filter. The value 0 indicates "no filter", and will remove all previous filters. See below for detail. Remote Peer Port: the port number of the remote peer. The value 0 indicates "all ports". Remote Peer IP address: The IP address of the remote peer. Option Name: FILTER Number: 3 Purpose: specifies a filter for incoming packets Valid for Opcodes: MAP Length: 20 octets May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: as many as fit within maximum PCP message size
The Prefix Length indicates how many bits of the address are used for the filter. For IPv4 addresses (which are encoded using the IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix lengths are between 96 and 128 bits, inclusive. That is, add 96 to the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are between 0 and 128 bits, inclusive. Values outside those ranges cause the PCP server to return the MALFORMED_OPTION result code. If multiple occurrences of the FILTER option exist in the same MAP request, they are processed in the order received (as per normal PCP option processing), and they MAY overlap the filtering requested. If there is an existing mapping (with or without a filter) and the server receives a MAP request with FILTER, the filters indicated in the new request are added to any existing filters. If a MAP request has a lifetime of 0 and contains the FILTER option, the error MALFORMED_OPTION is returned. If any occurrences of the FILTER option in a request packet are not successfully processed then an error is returned (e.g., MALFORMED_OPTION if one of the options was malformed) and as with other PCP errors, returning an error causes no state to be changed in the PCP server or in the PCP-controlled device. To remove all existing filters, the Prefix Length 0 is used. There is no mechanism to remove a specific filter. To change an existing filter, the PCP client sends a MAP request containing two FILTER options, the first option containing a prefix length of 0 (to delete all existing filters) and the second containing the new remote peer's IP address, protocol, and port. Other FILTER options in that PCP request, if any, add more allowed remote peers. The PCP server or the PCP-controlled device is expected to have a limit on the number of remote peers it can support. This limit might be as small as one. If a MAP request would exceed this limit, the entire MAP request is rejected with the result code EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. All PCP servers MUST support at least one filter per MAP mapping.
gateway has its external IP address changed so that its current mapping state becomes invalid. The PCP rapid recovery feature enables users to, for example, connect to remote machines using ssh, and then reboot their NAT or firewall device (or even replace it with completely new hardware) without losing their established ssh connections. Use of PCP rapid recovery is a performance optimization to PCP's routine self-healing. Without rapid recovery, PCP clients will still recreate their correct state when they next renew their mappings, but this routine self-healing process may take hours rather than seconds, and will probably not happen fast enough to prevent active TCP connections from timing out. There are two mechanisms to perform rapid recovery, described below. Failing to implement and deploy a rapid recovery mechanism will encourage application developers to feel the need to refresh their PCP state more frequently than necessary, causing more network traffic. Therefore, a PCP server that can lose state (e.g., due to reboot) or might have a mapping change (e.g., due to IP renumbering) MUST implement either the Announce Opcode or the Mapping Update mechanism and SHOULD implement both mechanisms.
This functionality allows a PCP client to determine a server's Epoch, or to determine if a PCP server is running, without changing the server's state. Section 8.3 will accept the message). This message is most typically multicast, but can also be unicast. Multicast PCP restart announcements are sent to 220.127.116.11:5350 and/or [ff02::1]:5350, as described below. Sending PCP restart announcements via unicast requires that the PCP server know the IP address(es) and port(s) of its listening clients, which means that sending PCP restart announcements via unicast is only applicable to PCP servers that retain knowledge of the IP address(es) and port(s) of their clients even after they otherwise lose the rest of their state. When a PCP server device that implements this functionality reboots, restarts its NAT engine, or otherwise enters a state where it may have lost some or all of its previous mapping state (or enters a state where it doesn't even know whether it may have had prior state that it lost), it MUST inform PCP clients of this fact by unicasting or multicasting a gratuitous PCP ANNOUNCE Opcode response packet, as shown below, via paths over which it accepts PCP requests. If sending a multicast ANNOUNCE message, a PCP server device that accepts PCP requests over IPv4 sends the Restart Announcement to the IPv4 multicast address 18.104.22.168:5350 (22.214.171.124 is the All Hosts multicast group address), and a PCP server device that accepts PCP requests over IPv6 sends the Restart Announcement to the IPv6 multicast address [ff02::1]:5350 (ff02::1 is for all nodes on the local segment). A PCP server device that accepts PCP requests over both IPv4 and IPv6 sends a pair of Restart Announcements, one to each multicast address. If sending a unicast ANNOUNCE messages, it sends ANNOUNCE response message to the IP address(es) and port(s) of its PCP clients. To accommodate packet loss, the PCP server device MAY transmit such packets (or packet pairs) up to ten times (with an appropriate Epoch Time value in each to reflect the passage of time between transmissions) provided that the interval between the first two notifications is at least 250 ms, and the interval between subsequent notification at least doubles. A PCP client that sends PCP requests to a PCP server via a multicast- capable path, and implements the Restart Announcement feature, and wishes to receive these announcements, MUST listen to receive these PCP Restart Announcements (gratuitous PCP ANNOUNCE Opcode response
packets) on the appropriate multicast-capable interfaces on which it sends PCP requests, and MAY also listen for unicast announcements from the server too, (using the UDP port it already uses to issue unicast PCP requests to, and receive unicast PCP responses from, that server). A PCP client device that sends PCP requests using IPv4 listens for packets sent to the IPv4 multicast address 126.96.36.199:5350. A PCP client device that sends PCP requests using IPv6 listens for packets sent to the IPv6 multicast address [ff02::1]:5350. A PCP client device that sends PCP requests using both IPv4 and IPv6 listens for both types of Restart Announcement. The SO_REUSEPORT socket option or equivalent should be used for the multicast UDP port, if required by the host OS to permit multiple independent listeners on the same multicast UDP port. Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode response packet, a PCP client MUST (as it does with all received PCP response packets) inspect the announcement's source IP address, and if the Epoch Time value is outside the expected range for that server, it MUST wait a random amount of time between 0 and 5 seconds (to prevent synchronization of all PCP clients), then for all PCP mappings it made at that server address the client issues new PCP requests to recreate any lost mapping state. The use of the Suggested External IP Address and Suggested External Port fields in the client's renewal requests allows the client to remind the restarted PCP server device of what mappings the client had previously been given, so that in many cases the prior state can be recreated. For PCP server devices that reboot relatively quickly it is usually possible to reconstruct lost mapping state fast enough that existing TCP connections and UDP communications do not time out, and continue without failure. As for all PCP response messages, if the Epoch Time value is within the expected range for that server, the PCP client does not recreate its mappings. As for all PCP response messages, after receiving and validating the ANNOUNCE message, the client updates its own Epoch time for that server, as described in Section 8.5.
If a PCP server device has not forgotten its mapping state, but for some other reason has determined that some or all of its mappings have become unusable (e.g., when a home gateway is assigned a different external IPv4 address by the upstream DHCP server), then the PCP server device automatically repairs its mappings and notifies its clients by following the procedure described below. For PCP-managed mappings, for each one the PCP server device should update the external IP address and external port to appropriate available values, and then send unicast PCP MAP or PEER responses (as appropriate for the mapping) to inform the PCP client of the new external IP address and external port. Such unsolicited responses are identical to the MAP or PEER responses normally returned in response to client MAP or PEER requests, containing newly updated External IP Address and External Port values, and are sent to the same client IP address and port that the PCP server used to send the prior response for that mapping. If the earlier associated request contained the THIRD_PARTY option, the THIRD_PARTY option MUST also appear in the Mapping Update as it is necessary for the PCP client to disambiguate the response. If the earlier associated request contained the PREFER_FAILURE option, and the same external IP address, protocol, and port cannot be provided, the error CANNOT_PROVIDE_EXTERNAL SHOULD be sent. If the earlier associated request contained the FILTER option, the filters are moved to the new mapping and the FILTER option is sent in the Mapping Update response. Non-mandatory options SHOULD NOT be sent in the Mapping Update response. Discussion: It could have been possible to design this so that the PCP server (1) sent an ANNOUNCE Opcode to the PCP client, the PCP client reacted by (2) sending a new MAP request and (3) receiving a MAP response. Instead, the server can create a shortcut for that design by simply sending the message it would have sent in (3). To accommodate packet loss, the PCP server device SHOULD transmit such packets three times, with an appropriate Epoch Time value in each to reflect the passage of time between transmissions. The interval between the first two notifications MUST be at least 250 ms, and the third packet after a 500-ms interval. Once the PCP server has received a refreshed state for that mapping, the PCP server SHOULD cease those retransmissions for that mapping, as it serves no further purpose to continue sending messages regarding that mapping. Upon receipt of such an updated MAP or PEER response, a PCP client uses the information in the response to adjust rendezvous servers or reconnect to servers, respectively. For MAP, this would mean updating the DNS entries or other address and port information
recorded with some kind of application-specific rendezvous server. For PEER responses giving a CANNOT_PROVIDE_EXTERNAL error, this would typically mean establishing new connections to servers. Anytime the external address or port changes, existing TCP and UDP connections will be lost; PCP can't avoid that, but does provide immediate notification of the event to lessen the impact.
mappings. If there is a port mapping quota for the internal host, frequent restarts such as this may exhaust the quota. To help clean PCP state, when the PCP-controlled device is collocated with the address assignment (DHCP) server, such as in a typical residential CPE, it is RECOMMENDED that when an IP address becomes invalid (e.g., the DHCP lease expires, or the DHCP client sends an explicit DHCP RELEASE) the PCP-controlled device SHOULD also discard any dynamic mapping state relating to that expired IP address. When using NAT, the same external port may be assigned for use by different internal hosts at different times. For example, if an internal host using an external port ceases sending traffic using that port, then its mapping may expire, and then later the same external port may be assigned to a new internal host. The new internal host could then receive incoming traffic that was intended for the previous internal host. This generally happens inadvertently, and this reassignment of the external port only happens after the current holder of the external port has ceased using it for some period of time. It would be unacceptable if an attacker could use PCP to intentionally speed up this reassignment of the external port in order to deliberately steal traffic intended for the current holder, by (i) spoofing PCP requests using the current holder's source IP address and mapping nonce to fraudulently delete the mapping or shorten its lifetime, and then (ii) subsequently claiming the external port for itself. Therefore, in the simple security model, to protect against this attack, PCP MUST NOT allow a PCP request (even a PCP request that appears to come from the current holder of the mapping) to cause a mapping to expire sooner than it would naturally have expired otherwise by virtue of outbound traffic keeping the mapping active. A PCP server MUST set the lifetime of a mapping to no less than the remaining time before the mapping would expire if no further outbound traffic is seen for that mapping. This means a MAP or PEER request with lifetime of 0 will only set the assigned lifetime to 0 (i.e., delete the mapping) if the internal host had not sent a packet using that mapping for the idle-timeout time, otherwise the assigned lifetime will be the remaining idle-timeout time. Finally, to reduce unwanted traffic and data corruption for both TCP and UDP, the assigned external port created by the MAP Opcode or PEER Opcode SHOULD NOT be reused for an interval equal to the reuse time limit enforced by the NAT for its implicit dynamic mappings (typically, the maximum TCP segment lifetime of 2 minutes [RFC0793]). Furthermore, to reduce port stealing attacks, the assigned external port also SHOULD NOT be reused for an interval equal to the time the PCP- controlled device would normally maintain an idle (no traffic)
implicit dynamic mapping (e.g., 2 minutes for UDP [RFC4787] and 124 minutes for TCP [RFC5382]). However, within these time windows, the PCP server SHOULD allow an external port to be reclaimed by the same client, where "same client" means "same internal IP address, internal port, and mapping nonce". Section 13.1), if authorized, can also delete PCP-created MAP mappings.
Section 16 provides non-normative guidance that may be useful to implementers. RFC4787][RFC5382]. In EDM NAT devices, the same external port may be used by an outbound dynamic mapping and an inbound dynamic mapping (from the same internal host or from a different internal host). This complicates the interaction with the MAP Opcode. With such NAT devices, there are two ways envisioned to implement the MAP Opcode: 1. Have outbound mappings use a different set of external ports than inbound mappings (e.g., those created with MAP), thus reducing the interaction problem between them; or 2. On arrival of a packet (inbound from the Internet or outbound from an internal host), first attempt to use a dynamic outbound mapping to process that packet. If none match, attempt to use an inbound mapping to process that packet. This effectively 'prioritizes' outbound mappings above inbound mappings.
service provider environment (due to redundant power, disk drives for storage, etc.). Of course, due to outright failure of service provider equipment (e.g., software malfunction), state may still be lost. The Epoch time allows a client to deduce when a PCP server may have lost its state. When the Epoch Time value is observed to be outside the expected range, the PCP client can attempt to recreate the mappings following the procedures described in this section. Further analysis of PCP failure scenarios is planned for a future document [PCP-FAIL]. Section 8.5), indicating that a reboot or similar loss of state has occurred, the client can renew its port mappings sooner, without waiting for the normal routine renewal time.
If the PCP client has several mappings, the Epoch Time value only needs to be retrieved for one of them to determine whether or not it appears the PCP server may have suffered a catastrophic loss of state. If the client wishes to check the PCP server's Epoch time, it sends a PCP request for any one of the client's mappings. This will return the current Epoch Time value. In that request, the PCP client could extend the mapping lifetime (by asking for more time) or maintain the current lifetime (by asking for the same number of seconds that it knows are remaining of the lifetime). If a PCP client changes its internal IP address (e.g., because the internal host has moved to a new network), and the PCP client wishes to still receive incoming traffic, it needs create new mappings on that new network. New mappings will typically also require an update to the application-specific rendezvous server if the external address or port is different from the previous values (see Sections 10.1 and 11.5). SCTPNAT]. Outbound dynamic SCTP mappings use the verification tag of the association instead of the local and remote peer port numbers. As with TCP, explicit outbound mappings can be made to reduce keepalive intervals, and explicit inbound mappings can be made by passive listeners expecting to receive new associations at the external port. Because an SCTP-aware NAT does not (currently) rewrite SCTP port numbers, it will not be able to assign an external port that is different from the client's internal port. A PCP client making a MAP request for SCTP should be aware of this restriction. The PCP client SHOULD make its SCTP MAP request just as it would for a TCP MAP request: in its initial PCP MAP request it SHOULD specify zero for the external address and port, and then in subsequent renewals it SHOULD echo the assigned external address and port. However, since a current SCTP-aware NAT can only assign an external port that is the same as the internal port, it may not be able to do that if the external port is already assigned to a different PCP client. This is likely if there is more than one instance of a given SCTP service on the local network, since both instances are likely to listen on the same well-known SCTP port for that service on their respective hosts, but they can't both have the same external port on the NAT gateway's external address. A particular external port may not be assignable for other reasons, such as when it is already in use by the NAT device itself, or otherwise prohibited by policy, as described in Section 11.3, "Processing a MAP Request". In the event that the
external port matching the internal port cannot be assigned (and the SCTP-aware NAT does not perform SCTP port rewriting), the SCTP-aware NAT MUST return a CANNOT_PROVIDE_EXTERNAL error to the requesting PCP client. Note that this restriction places an extra burden on the SCTP server whose MAP request failed, because it then has to tear down its exiting listening socket and try again with a different internal port, repeatedly until it is successful in finding an external port it can use. The SCTP complications described above occur because of address sharing. The SCTP complications are avoided when address sharing is avoided (e.g., 1:1 NAT, firewall).
CLOSE_MSG or (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY +-------------->| |<------------+ | |NO_ENTRY | | | +-----------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | |PEER request | | MAP request| | | V | | V | +---------+ | | +---------+ +-->| "P", | | | M-R | "M", |<--+ P-R | | PEER |-----------|--|-------->| MAP | | M-R or +---| mapping| | | | mapping|---+ P-R or +---------+ | | +---------+ CLOSE_MSGS | ^ | | ^ | | |PEER request | | MAP request| | | | | | | | | | | | | | | | | | | | | | | | outbound | | | | | | TRAFFIC | | | | | V | | | | +---------+ | | | +-----------| "I", |---------+ | | | implicit| | +-------------->| mapping |<------------+ TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY Figure 16: PCP State Diagram The meanings of the states and events are: NO_ENTRY: Invalid state represents Entry does not exist. This is the only possible start state. M-R: MAP request P-R: PEER request
M: Mapping entry when created by MAP request P: Mapping entry when created/managed by PEER request I: Implicit mapping created by an outgoing packet from the client (e.g., TCP SYN), and also the state when a PCP-created mapping's lifetime expires while there is still active traffic. EXPIRY: PEER or MAP lifetime expired TRAFFIC: Traffic seen by PCP-controlled device using this entry within the expiry time for that entry. This traffic may be inbound or outbound. NO_TRAFFIC: Indicates that there is no TRAFFIC. CLOSE_MSG: Protocol messages from the client or server to close the session (e.g., TCP FIN or TCP RST), as per the NAT or firewall device's handling of such protocol messages. Notes on the diagram: 1. The 'and' clause indicates the events on either side of 'and' are required for the state-transition. The 'or' clause indicates either one of the events are enough for the state-transition. 2. Transition from state M to state I is implementation dependent.