Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6887

Port Control Protocol (PCP)

Pages: 88
Proposed Standard
Errata
Updated by:  748876527843
Part 3 of 4 – Pages 50 to 77
First   Prev   Next

Top   ToC   RFC6887 - Page 50   prevText

12. PEER Opcode

This section defines an Opcode for controlling dynamic outbound mappings. PEER: Create a new dynamic outbound mapping to a remote peer's IP address and port, or extend the lifetime of an existing outbound mapping. The use of this Opcodes is described in this section. PCP servers SHOULD provide a configuration option to allow administrators to disable PEER support if they wish. Because a mapping created or managed by PEER behaves almost exactly like an implicit dynamic outbound mapping created as a side effect of a packet (e.g., TCP SYN) sent by the host, mappings created or managed using PCP PEER requests may be endpoint-independent mapping (EIM) or endpoint-dependent mapping (EDM), with endpoint-independent filtering (EIF) or endpoint-dependent filtering (EDF), consistent with the existing behavior of the NAT gateway or firewall in question for implicit outbound mappings it creates automatically as a result of observing outgoing traffic from internal hosts.
Top   ToC   RFC6887 - Page 51

12.1. PEER Operation Packet Formats

The PEER Opcode allows a PCP client to create a new explicit dynamic outbound mapping (which functions similarly to an outbound mapping created implicitly when a host sends an outbound TCP SYN) or to extend the lifetime of an existing outbound mapping. The following diagram shows the Opcode layout for the PEER Opcode. The formats for the PEER request and response packets are aligned so that related fields fall at the same offsets in the packet. 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).
Top   ToC   RFC6887 - Page 52
   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
Top   ToC   RFC6887 - Page 53
   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.
Top   ToC   RFC6887 - Page 54
   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.

12.2. Generating a PEER Request

This section describes the operation of a client when generating a message with the PEER Opcode. The PEER Opcode MAY be sent before or after establishing bidirectional communication with the remote peer. If sent before, this is considered a PEER-created mapping that creates a new dynamic outbound mapping in the PCP-controlled device. If sent after, this allows the PCP client to learn the IP address, port, and lifetime of the assigned external address and port for the existing implicit dynamic outbound mapping, and potentially to extend this lifetime (for reducing NAT or firewall keepalive messages, as described in 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.
Top   ToC   RFC6887 - Page 55
   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.

12.3. Processing a PEER Request

This section describes the operation of a server when receiving a request with the PEER Opcode. Processing SHOULD be performed in the order of the following paragraphs. The following fields from a PEER request are copied into the response: Protocol, Internal Port, Remote Peer IP Address, Remote Peer Port, and Mapping Nonce. When an implicit dynamic mapping is created, some NATs and firewalls validate destination addresses and will not create an implicit dynamic mapping if the destination address is invalid (e.g., 127.0.0.1). If a PCP-controlled device does such validation for implicit dynamic mappings, it SHOULD also do a similar validation of the remote peer IP address, protocol, and port for PEER-created explicit dynamic mappings. If the validation determines the remote peer IP address of a PEER request is invalid, then no mapping is created, and a MALFORMED_REQUEST error result is returned. On receiving the PEER Opcode, the PCP server examines the mapping table for a matching five-tuple { Protocol, Internal Address, Internal Port, Remote Peer Address, Remote Peer Port }. If no matching mapping is found, and the suggested external address and port are either zero or can be honored for the specified Protocol, a new mapping is created. By having the PEER create such a mapping, we avoid a race condition between the PEER request and the initial outgoing packet arriving at the NAT or firewall device first, and allow PEER to be used to recreate a lost outbound dynamic mapping (see 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.
Top   ToC   RFC6887 - Page 56
   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.

12.4. Processing a PEER Response

This section describes the operation of a client when processing a response with the PEER Opcode. After performing common PCP response processing, the response is further matched with an outstanding PEER request by comparing the internal IP address (the destination IP address of the PCP response, or other IP address specified via the THIRD_PARTY option), the
Top   ToC   RFC6887 - Page 57
   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.

13. Options for MAP and PEER Opcodes

This section describes options for the MAP and PEER Opcodes. These options MUST NOT appear with other Opcodes, unless permitted by those other Opcodes.

13.1. THIRD_PARTY Option for MAP and PEER Opcodes

This option is used when a PCP client wants to control a mapping to an internal host other than itself. This is used with both MAP and PEER Opcodes. Due to security concerns with the THIRD_PARTY option, this option MUST NOT be implemented or used unless the network on which the PCP
Top   ToC   RFC6887 - Page 58
   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.
Top   ToC   RFC6887 - Page 59
   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.

13.2. PREFER_FAILURE Option for MAP Opcode

This option is only used with the MAP Opcode. This option indicates that if the PCP server is unable to map both the suggested external port and suggested external address, the PCP server should not create a mapping. This differs from the behavior without this option, which is to create a mapping. PREFER_FAILURE is never necessary for a PCP client to manage mappings for itself, and its use causes additional work in the PCP client and in the PCP server. This option exists for interworking with non-PCP mapping protocols that have different semantics than PCP (e.g., UPnP IGDv1 interworking [PNP-IGD-PCP], where the semantics of UPnP IGDv1
Top   ToC   RFC6887 - Page 60
   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.
Top   ToC   RFC6887 - Page 61
   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.

13.3. FILTER Option for MAP Opcode

This option is only used with the MAP Opcode. This option indicates that filtering incoming packets is desired. The protocol being filtered is indicated by the Protocol field in the MAP Request, and the remote peer IP address and remote peer port of the FILTER option indicate the permitted remote peer's source IP address and source port for packets from the Internet; other traffic from other addresses is blocked. The remote peer prefix length indicates the length of the remote peer's IP address that is significant; this allows a single option to permit an entire subnet. After processing this MAP request containing the FILTER option and generating a successful response, the PCP-controlled device will drop packets received on its public-facing interface that don't match the filter fields. After dropping the packet, if its security policy allows, the PCP-controlled device MAY also generate an ICMP error in response to the dropped packet. The use of the FILTER option can be seen as a performance optimization. Since all software using PCP to receive incoming connections also has to deal with the case where it may be directly connected to the Internet and receive unrestricted incoming TCP connections and UDP packets, if it wishes to restrict incoming
Top   ToC   RFC6887 - Page 62
   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
Top   ToC   RFC6887 - Page 63
   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.

14. Rapid Recovery

PCP includes a rapid recovery feature, which allows PCP clients to repair failed mappings within seconds, rather than the minutes or hours it might take if they relied solely on waiting for the next routine renewal of the mapping. Mapping failures may occur when a NAT gateway is rebooted and loses its mapping state, or when a NAT
Top   ToC   RFC6887 - Page 64
   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.

14.1. ANNOUNCE Opcode

This rapid recovery mechanism uses the ANNOUNCE Opcode. When the PCP server loses its state (e.g., it lost its state when rebooted), it resets its Epoch time to its initial starting value (usually zero) and sends the ANNOUNCE response to the link-scoped multicast address (specific address explained below) if a multicast network exists on its local interface, or, if configured with the IP address(es) and port(s) of PCP client(s), it sends unicast ANNOUNCE responses to those address(es) and port(s). This means ANNOUNCE may not be available on all networks (such as networks without a multicast link between the PCP server and its PCP clients). Additionally, an ANNOUNCE request can be sent (unicast) by a PCP client that elicits a unicast ANNOUNCE response like any other Opcode. Upon receiving PCP response packets with an anomalous Epoch time, clients deduce that the PCP server lost state and recreate their lost mappings.
Top   ToC   RFC6887 - Page 65

14.1.1. ANNOUNCE Operation

The PCP ANNOUNCE Opcode requests and responses have no Opcode-specific payload (that is, the length of the Opcode-specific data is zero). The Requested Lifetime field of requests and Lifetime field of responses are both set to 0 on transmission and ignored on reception. If a PCP server receives an ANNOUNCE request, it first parses it and generates a SUCCESS if parsing and processing of ANNOUNCE is successful. An error is generated if the client's IP Address field does not match the packet source address, or the request packet is otherwise malformed, such as packet length less than 24 octets. Note that, in the future, options MAY be sent with the PCP ANNOUNCE Opcode; PCP clients and servers need to be prepared to receive options with the ANNOUNCE Opcode. Discussion: Client-to-server request messages are sent, from any client source port, to listening UDP port 5351 on the server; server-to-client multicast notifications are sent from the server's UDP port (5351) to listening UDP port 5350 on the client. The reason the same listening UDP port is not used for both purposes is that a single device may have multiple roles. For example, a multi-function home gateway that provides NAT service (PCP server) may also provide printer sharing (which wants a PCP client), or a home computer (PCP client) may also provide "Internet Sharing" (NAT) functionality (which needs to offer PCP service). Such devices need to act as both a PCP server and a PCP client at the same time, and the software that implements the PCP server on the device may not be the same software component that implements the PCP client. The software that implements the PCP server needs to listen for unicast client requests, whereas the software that implements the PCP client needs to listen for multicast restart announcements. In many networking APIs it is difficult or impossible to have two independent clients listening for both unicasts and multicasts on the same port at the same time. For this reason, two ports are used.

14.1.2. Generating and Processing a Solicited ANNOUNCE Message

The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client. The Requested Lifetime value MUST be set to zero. When the PCP server receives the ANNOUNCE Opcode and successfully parses and processes it, it generates SUCCESS response with an assigned lifetime of zero.
Top   ToC   RFC6887 - Page 66
   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.

14.1.3. Generating and Processing an Unsolicited ANNOUNCE Message

When sending unsolicited responses, the ANNOUNCE Opcode MUST have result code equal to zero (SUCCESS), and the packet MUST be sent from the unicast IP address and UDP port number on which PCP requests are received (so that the PCP response processing described in 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 224.0.0.1: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 224.0.0.1:5350 (224.0.0.1 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
Top   ToC   RFC6887 - Page 67
   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
   224.0.0.1: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.

14.2. PCP Mapping Update

This rapid recovery mechanism is used when the PCP server remembers its state and determines its existing mappings are invalid (e.g., IP renumbering changes the external IP address of a PCP-controlled NAT). It is anticipated that servers that are routinely reconfigured by an administrator or have their WAN address changed frequently will implement this feature (e.g., residential CPE routers). It is anticipated that servers that are not routinely reconfigured will not implement this feature (e.g., service provider-operated CGN).
Top   ToC   RFC6887 - Page 68
   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
Top   ToC   RFC6887 - Page 69
   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.

15. Mapping Lifetime and Deletion

The PCP client requests a certain lifetime, and the PCP server responds with the assigned lifetime. The PCP server MAY grant a lifetime smaller or larger than the requested lifetime. The PCP server SHOULD be configurable for permitted minimum and maximum lifetime, and the minimum value SHOULD be 120 seconds. The maximum value SHOULD be the remaining lifetime of the IP address assigned to the PCP client if that information is available (e.g., from the DHCP server), or half the lifetime of IP address assignments on that network if the remaining lifetime is not available, or 24 hours. Excessively long lifetimes can cause consumption of ports even if the internal host is no longer interested in receiving the traffic or is no longer connected to the network. These recommendations are not strict, and deployments should evaluate the trade-offs to determine their own minimum and maximum Lifetime values. Once a PCP server has responded positively to a MAP request for a certain lifetime, the port mapping is active for the duration of the lifetime unless the lifetime is reduced by the PCP client (to a shorter lifetime or to zero) or until the PCP server loses its state (e.g., crashes). Mappings created by PCP MAP requests are not special or different from mappings created in other ways. In particular, it is implementation-dependent if outgoing traffic extends the lifetime of such mappings beyond the PCP-assigned lifetime. PCP clients MUST NOT depend on this behavior to keep mappings active, and MUST explicitly renew their mappings as required by the Lifetime field in PCP response messages. Upon receipt of a PCP response with an absurdly long assigned lifetime, the PCP client SHOULD behave as if it received a more sane value (e.g., 24 hours), and renew the mapping accordingly, to ensure that if the static mapping is removed, the client will continue to maintain the mapping it desires. An application that forgets its PCP-assigned mappings (e.g., the application or OS crashes) will request new PCP mappings. This may consume port mappings, if the application binds to a different internal port every time it runs. The application will also likely initiate new outbound TCP connections, which create implicit dynamic outbound mappings without using PCP, which will also consume port
Top   ToC   RFC6887 - Page 70
   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)
Top   ToC   RFC6887 - Page 71
   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".

15.1. Lifetime Processing for the MAP Opcode

If the requested lifetime is zero then: o If both the protocol and internal port are non-zero, it indicates a request to delete the indicated mapping immediately. o If the protocol is non-zero and the internal port is zero, it indicates a request to delete a previous 'wildcard' (all-ports) mapping for that protocol. The nonce MUST match the nonce used to create the 'wildcard' mapping. o If both the protocol and internal port are zero, it indicates a request to delete a previous 'DMZ host' (all incoming traffic for all protocols) mapping. The nonce MUST match the nonce used to create the 'DMZ host' mapping. o If the protocol is zero and the internal port is non-zero, then the request is invalid and the PCP server MUST return a MALFORMED_REQUEST error to the client. In requests where the requested Lifetime is 0, the Suggested External Address and Suggested External Port fields MUST be set to zero on transmission and MUST be ignored on reception, and these fields MUST be copied into the assigned external IP address and assigned external port of the response. PCP MAP requests can only delete or shorten lifetimes of MAP-created mappings. If the PCP client attempts to delete a static mapping (i.e., a mapping created outside of PCP itself), or an outbound (implicit or PEER-created) mapping, the PCP server MUST return NOT_AUTHORIZED. If the PCP client attempts to delete a mapping that does not exist, the SUCCESS result code is returned (this is necessary for PCP to return the same response for retransmissions or duplications of the same request). If the deletion request was properly formatted and successfully processed, a SUCCESS response is generated with the protocol and internal port number copied from the request, and the response lifetime set to zero. An inbound mapping (i.e., static mapping or MAP-created dynamic mapping) MUST NOT have its lifetime reduced by transport protocol messages (e.g., TCP RST, TCP FIN). Note the THIRD_PARTY option (Section 13.1), if authorized, can also delete PCP-created MAP mappings.
Top   ToC   RFC6887 - Page 72

16. Implementation Considerations

Section 16 provides non-normative guidance that may be useful to implementers.

16.1. Implementing MAP with EDM Port-Mapping NAT

For implicit dynamic outbound mappings, some existing NAT devices have endpoint-independent mapping (EIM) behavior while other NAT devices have endpoint-dependent mapping (EDM) behavior. NATs that have EIM behavior do not suffer from the problem described in this section. The IETF strongly encourages EIM behavior [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.

16.2. Lifetime of Explicit and Implicit Dynamic Mappings

No matter if a NAT is EIM or EDM, it is possible that one (or more) outbound mappings, using the same internal port on the internal host, might be created before or after a MAP request. When this occurs, it is important that the NAT honor the lifetime returned in the MAP response. Specifically, if an inbound mapping was created with the MAP Opcode, the implementation needs to ensure that termination of an outbound mapping (e.g., via a TCP FIN handshake) does not prematurely destroy the MAP-created inbound mapping.

16.3. PCP Failure Recovery

If an event occurs that causes the PCP server to lose dynamic mapping state (such as a crash or power outage), the mappings created by PCP are lost. Occasional loss of state may be unavoidable in a residential NAT device that does not write transient information to non-volatile memory. Loss of state is expected to be rare in a
Top   ToC   RFC6887 - Page 73
   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].

16.3.1. Recreating Mappings

A mapping renewal packet is formatted identically to an original mapping request; from the point of view of the client, it is a renewal of an existing mapping; however, from the point of view of a newly rebooted PCP server, it appears as a new mapping request. In the normal process of routinely renewing its mappings before they expire, a PCP client will automatically recreate all its lost mappings. When the PCP server loses state and begins processing new PCP messages, its Epoch time is reset and begins counting again. As the result of receiving a packet where the Epoch Time field is outside the expected range (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.

16.3.2. Maintaining Mappings

A PCP client refreshes a mapping by sending a new PCP request containing information learned from the earlier PCP response. The PCP server will respond indicating the new lifetime. It is possible, due to reconfiguration or failure of the PCP server, that the external IP address and/or external port, or the PCP server itself, has changed (due to a new route to a different PCP server). Such events are rare, but not an error. The PCP server will simply return a new external address and/or external port to the client, and the client should record this new external address and port with its rendezvous service. To detect such events more quickly, a server that requires extremely high availability may find it beneficial to use shorter lifetimes in its PCP mappings requests, so that it communicates with the PCP server more often. This is an engineering trade-off based on (i) the acceptable downtime for the service in question, (ii) the expected likelihood of NAT or firewall state loss, and (iii) the amount of PCP maintenance traffic that is acceptable.
Top   ToC   RFC6887 - Page 74
   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).

16.3.3. SCTP

Although SCTP has port numbers like TCP and UDP, SCTP works differently when behind an address-sharing NAT, in that SCTP port numbers are not changed [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
Top   ToC   RFC6887 - Page 75
   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).

16.4. Source Address Replicated in PCP Header

All PCP requests include the PCP client's IP address replicated in the PCP header. This is used to detect unexpected address rewriting (NAT) on the path between the PCP client and its PCP server. On operating systems that support the sockets API, the following steps are RECOMMENDED for a PCP client to insert the correct source address in the PCP header: 1. Create a UDP socket. 2. Call "connect" on this UDP socket using the address and port of the desired PCP server. 3. Call the getsockname() function to retrieve a sockaddr containing the source address the kernel will use for UDP packets sent through this socket. 4. If the IP address is an IPv4 address, encode the address into an IPv4-mapped IPv6 address. Place the IPv4-mapped IPv6 address or the native IPv6 address into the PCP Client's IP Address field in the PCP header. 5. Send PCP requests using this connected UDP socket.
Top   ToC   RFC6887 - Page 76

16.5. State Diagram

Each mapping entry of the PCP-controlled device would go through the state machine shown below. This state diagram is non-normative. 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
Top   ToC   RFC6887 - Page 77
      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.



(page 77 continued on part 4)

Next Section