tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6887

 
 
 

Port Control Protocol (PCP)

Part 3 of 4, p. 50 to 77
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 50 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part