tech-invite   World Map     

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

RFC 6887

 Errata 
Proposed STD
Pages: 88
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: PCP

Port Control Protocol (PCP)

Part 1 of 4, p. 1 to 20
None       Next RFC Part

Updated by:    7488    7652    7843


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      D. Wing, Ed.
Request for Comments: 6887                                         Cisco
Category: Standards Track                                    S. Cheshire
ISSN: 2070-1721                                                    Apple
                                                            M. Boucadair
                                                          France Telecom
                                                                R. Penno
                                                                   Cisco
                                                              P. Selkirk
                                                                     ISC
                                                              April 2013


                      Port Control Protocol (PCP)

Abstract

   The Port Control Protocol allows an IPv6 or IPv4 host to control how
   incoming IPv6 or IPv4 packets are translated and forwarded by a
   Network Address Translator (NAT) or simple firewall, and also allows
   a host to optimize its outgoing NAT keepalive messages.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6887.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Page 2 
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Deployment Scenarios . . . . . . . . . . . . . . . . . . .  5
     2.2.  Supported Protocols  . . . . . . . . . . . . . . . . . . .  5
     2.3.  Single-Homed Customer Premises Network . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Relationship between PCP Server and Its PCP-Controlled
       Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Note on Fixed-Size Addresses . . . . . . . . . . . . . . . . . 10
   6.  Protocol Design Note . . . . . . . . . . . . . . . . . . . . . 11
   7.  Common Request and Response Header Format  . . . . . . . . . . 13
     7.1.  Request Header . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.  Response Header  . . . . . . . . . . . . . . . . . . . . . 15
     7.3.  Options  . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.4.  Result Codes . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  General PCP Operation  . . . . . . . . . . . . . . . . . . . . 20
     8.1.  General PCP Client: Generating a Request . . . . . . . . . 21
       8.1.1.  PCP Client Retransmission  . . . . . . . . . . . . . . 22
     8.2.  General PCP Server: Processing a Request . . . . . . . . . 24
     8.3.  General PCP Client: Processing a Response  . . . . . . . . 25
     8.4.  Multi-Interface Issues . . . . . . . . . . . . . . . . . . 27
     8.5.  Epoch  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  Version Negotiation  . . . . . . . . . . . . . . . . . . . . . 29
   10. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . . 30
     10.1. For Operating a Server . . . . . . . . . . . . . . . . . . 33
     10.2. For Operating a Symmetric Client/Server  . . . . . . . . . 35
     10.3. For Reducing NAT or Firewall Keepalive Messages  . . . . . 37
     10.4. For Restoring Lost Implicit TCP Dynamic Mapping State  . . 38
   11. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 39
     11.1. MAP Operation Packet Formats . . . . . . . . . . . . . . . 40
     11.2. Generating a MAP Request . . . . . . . . . . . . . . . . . 43
       11.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . . 44
     11.3. Processing a MAP Request . . . . . . . . . . . . . . . . . 44
     11.4. Processing a MAP Response  . . . . . . . . . . . . . . . . 48
     11.5. Address Change Events  . . . . . . . . . . . . . . . . . . 49
     11.6. Learning the External IP Address Alone . . . . . . . . . . 50
   12. PEER Opcode  . . . . . . . . . . . . . . . . . . . . . . . . . 50
     12.1. PEER Operation Packet Formats  . . . . . . . . . . . . . . 51
     12.2. Generating a PEER Request  . . . . . . . . . . . . . . . . 54
     12.3. Processing a PEER Request  . . . . . . . . . . . . . . . . 55
     12.4. Processing a PEER Response . . . . . . . . . . . . . . . . 56

Top      ToC       Page 3 
   13. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . . 57
     13.1. THIRD_PARTY Option for MAP and PEER Opcodes  . . . . . . . 57
     13.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . . 59
     13.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . . 61
   14. Rapid Recovery . . . . . . . . . . . . . . . . . . . . . . . . 63
     14.1. ANNOUNCE Opcode  . . . . . . . . . . . . . . . . . . . . . 64
       14.1.1. ANNOUNCE Operation . . . . . . . . . . . . . . . . . . 65
       14.1.2. Generating and Processing a Solicited ANNOUNCE
               Message  . . . . . . . . . . . . . . . . . . . . . . . 65
       14.1.3. Generating and Processing an Unsolicited ANNOUNCE
               Message  . . . . . . . . . . . . . . . . . . . . . . . 66
     14.2. PCP Mapping Update . . . . . . . . . . . . . . . . . . . . 67
   15. Mapping Lifetime and Deletion  . . . . . . . . . . . . . . . . 69
     15.1. Lifetime Processing for the MAP Opcode . . . . . . . . . . 71
   16. Implementation Considerations  . . . . . . . . . . . . . . . . 72
     16.1. Implementing MAP with EDM Port-Mapping NAT . . . . . . . . 72
     16.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . . 72
     16.3. PCP Failure Recovery . . . . . . . . . . . . . . . . . . . 72
       16.3.1. Recreating Mappings  . . . . . . . . . . . . . . . . . 73
       16.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 73
       16.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 74
     16.4. Source Address Replicated in PCP Header  . . . . . . . . . 75
     16.5. State Diagram  . . . . . . . . . . . . . . . . . . . . . . 76
   17. Deployment Considerations  . . . . . . . . . . . . . . . . . . 77
     17.1. Ingress Filtering  . . . . . . . . . . . . . . . . . . . . 77
     17.2. Mapping Quota  . . . . . . . . . . . . . . . . . . . . . . 77
   18. Security Considerations  . . . . . . . . . . . . . . . . . . . 78
     18.1. Simple Threat Model  . . . . . . . . . . . . . . . . . . . 78
       18.1.1. Attacks Considered . . . . . . . . . . . . . . . . . . 79
       18.1.2. Deployment Examples Supporting the Simple Threat
               Model  . . . . . . . . . . . . . . . . . . . . . . . . 79
     18.2. Advanced Threat Model  . . . . . . . . . . . . . . . . . . 80
     18.3. Residual Threats . . . . . . . . . . . . . . . . . . . . . 80
       18.3.1. Denial of Service  . . . . . . . . . . . . . . . . . . 80
       18.3.2. Ingress Filtering  . . . . . . . . . . . . . . . . . . 81
       18.3.3. Mapping Theft  . . . . . . . . . . . . . . . . . . . . 81
       18.3.4. Attacks against Server Discovery . . . . . . . . . . . 81
   19. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 82
     19.1. Port Number  . . . . . . . . . . . . . . . . . . . . . . . 82
     19.2. Opcodes  . . . . . . . . . . . . . . . . . . . . . . . . . 82
     19.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 82
     19.4. Options  . . . . . . . . . . . . . . . . . . . . . . . . . 82
   20. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 83
   21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
     21.1. Normative References . . . . . . . . . . . . . . . . . . . 84
     21.2. Informative References . . . . . . . . . . . . . . . . . . 84
   Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . . 87

Top      ToC       Page 4 
1.  Introduction

   The Port Control Protocol (PCP) provides a mechanism to control how
   incoming packets are forwarded by upstream devices such as Network
   Address Translator IPv6/IPv4 (NAT64), Network Address Translator
   IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices, and a
   mechanism to reduce application keepalive traffic.  PCP is designed
   to be implemented in the context of Carrier-Grade NATs (CGNs) and
   small NATs (e.g., residential NATs), as well as with dual-stack and
   IPv6-only Customer Premises Equipment (CPE) routers, and all of the
   currently known transition scenarios towards IPv6-only CPE routers.
   PCP allows hosts to operate servers for a long time (e.g., a network-
   attached home security camera) or a short time (e.g., while playing a
   game or on a phone call) when behind a NAT device, including when
   behind a CGN operated by their Internet service provider or an IPv6
   firewall integrated in their CPE router.

   PCP allows applications to create mappings from an external IP
   address, protocol, and port to an internal IP address, protocol, and
   port.  These mappings are required for successful inbound
   communications destined to machines located behind a NAT or a
   firewall.

   After creating a mapping for incoming connections, it is necessary to
   inform remote computers about the IP address, protocol, and port for
   the incoming connection.  This is usually done in an application-
   specific manner.  For example, a computer game might use a rendezvous
   server specific to that game (or specific to that game developer), a
   SIP phone would use a SIP proxy, and a client using DNS-Based Service
   Discovery [RFC6763] would use DNS Update [RFC2136] [RFC3007].  PCP
   does not provide this rendezvous function.  The rendezvous function
   may support IPv4, IPv6, or both.  Depending on that support and the
   application's support of IPv4 or IPv6, the PCP client may need an
   IPv4 mapping, an IPv6 mapping, or both.

   Many NAT-friendly applications send frequent application-level
   messages to ensure that their session will not be timed out by a NAT.
   These are commonly called "NAT keepalive" messages, even though they
   are not sent to the NAT itself (rather, they are sent 'through' the
   NAT).  These applications can reduce the frequency of such NAT
   keepalive messages by using PCP to learn (and influence) the NAT
   mapping lifetime.  This helps reduce bandwidth on the subscriber's
   access network, traffic to the server, and battery consumption on
   mobile devices.

   Many NATs and firewalls include Application Layer Gateways (ALGs) to
   create mappings for applications that establish additional streams or
   accept incoming connections.  ALGs incorporated into NATs may also

Top      ToC       Page 5 
   modify the application payload.  Industry experience has shown that
   these ALGs are detrimental to protocol evolution.  PCP allows an
   application to create its own mappings in NATs and firewalls,
   reducing the incentive to deploy ALGs in NATs and firewalls.

2.  Scope

2.1.  Deployment Scenarios

   PCP can be used in various deployment scenarios, including:

   o  Basic NAT [RFC3022]

   o  Network Address and Port Translation [RFC3022], such as commonly
      deployed in residential NAT devices

   o  Carrier-Grade NAT [RFC6888]

   o  Dual-Stack Lite (DS-Lite) [RFC6333]

   o  NAT that is Layer-2 Aware [L2NAT]

   o  Dual-Stack Extra Lite [RFC6619]

   o  NAT64, both Stateless [RFC6145] and Stateful [RFC6146]

   o  IPv4 and IPv6 simple firewall control [RFC6092]

   o  IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]

2.2.  Supported Protocols

   The PCP Opcodes defined in this document are designed to support
   transport-layer protocols that use a 16-bit port number (e.g., TCP,
   UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], and
   Datagram Congestion Control Protocol (DCCP) [RFC4340]).  Protocols
   that do not use a port number (e.g., Resource Reservation Protocol
   (RSVP), IP Encapsulating Security Payload (ESP) [RFC4303], ICMP, and
   ICMPv6) are supported for IPv4 firewall, IPv6 firewall, and NPTv6
   functions, but are out of scope for any NAT functions.

2.3.  Single-Homed Customer Premises Network

   PCP assumes a single-homed IP address model.  That is, for a given IP
   address of a host, only one default route exists to reach other hosts
   on the Internet from that source IP address.  This is important
   because after a PCP mapping is created and an inbound packet (e.g.,
   TCP SYN) is rewritten and delivered to a host, the outbound response

Top      ToC       Page 6 
   (e.g., TCP SYNACK) has to go through the same (reverse) path so it
   passes through the same NAT to have the necessary inverse rewrite
   performed.  This restriction exists because otherwise there would
   need to be a PCP-enabled NAT for every egress (because the host could
   not reliably determine which egress path packets would take), and the
   client would need to be able to reliably make the same internal/
   external mapping in every NAT gateway, which in general is not
   possible (because the other NATs might already have the necessary
   external port mapped to another host).

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

   Internal Host:
      A host served by a NAT gateway, or protected by a firewall.  This
      is the host that will receive incoming traffic resulting from a
      PCP mapping request, or the host that initiated an implicit
      dynamic outbound mapping (e.g., by sending a TCP SYN) across a
      firewall or a NAT.

   Remote Peer Host:
      A host with which an internal host is communicating.  This can
      include another internal host (or even the same internal host); if
      a NAT is involved, the NAT would need to hairpin the traffic
      [RFC4787].

   Internal Address:
      The address of an internal host served by a NAT gateway or
      protected by a firewall.

   External Address:
      The address of an internal host as seen by other remote peers on
      the Internet with which the internal host is communicating, after
      translation by any NAT gateways on the path.  An external address
      is generally a public routable (i.e., non-private) address.  In
      the case of an internal host protected by a pure firewall, with no
      address translation on the path, its external address is the same
      as its internal address.

   Endpoint-Dependent Mapping (EDM):  A term applied to NAT operation
      where an implicit mapping created by outgoing traffic (e.g., TCP
      SYN) from a single internal address, protocol, and port to
      different remote peers and ports may be assigned different
      external ports, and a subsequent PCP mapping request for that

Top      ToC       Page 7 
      internal address, protocol, and port may be assigned yet another
      different external port.  This term encompasses both Address-
      Dependent Mapping and Address and Port-Dependent Mapping
      [RFC4787].

   Endpoint-Independent Mapping (EIM):  A term applied to NAT operation
      where all mappings from a single internal address, protocol, and
      port to different remote peers and ports are all assigned the same
      external address and port.

   Remote Peer Address:
      The address of a remote peer, as seen by the internal host.  A
      remote address is generally a publicly routable address.  In the
      case of a remote peer that is itself served by a NAT gateway, the
      remote address may in fact be the remote peer's external address,
      but since this remote translation is generally invisible to
      software running on the internal host, the distinction can safely
      be ignored for the purposes of this document.

   Third Party:
      In the common case, an internal host manages its own mappings
      using PCP requests, and the internal address of those mappings is
      the same as the source IP address of the PCP request packet.

      In the case where one device is managing mappings on behalf of
      some other device that does not implement PCP, the presence of the
      THIRD_PARTY option in the MAP request signifies that the specified
      address, rather than the source IP address of the PCP request
      packet, should be used as the internal address for the mapping.

   Mapping, Port Mapping, Port Forwarding:
      A NAT mapping creates a relationship between an internal IP
      address, protocol, and port, and an external IP address, protocol,
      and port.  More specifically, it creates a translation rule where
      packets destined *to* the external IP address, protocol, and port
      have their destination address and port translated to the internal
      address and port, and conversely, packets *from* the internal IP
      address, protocol, and port have their source address and port
      translated to the external address and port.  In the case of a
      pure firewall, the "mapping" is the identity function, translating
      an internal IP address, protocol, and port number to the same
      external IP address, protocol, and port number.  Firewall
      filtering, applied in addition to that identity mapping function,
      is separate from the mapping itself.

Top      ToC       Page 8 
   Mapping Types:
      There are three dimensions to classifying mapping types: how they
      are created (implicitly/explicitly), their primary purpose
      (outbound/inbound), and how they are deleted (dynamic/static).
      Implicit mappings are created as a side effect of some other
      operation; explicit mappings are created by a mechanism explicitly
      dealing with mappings.  Outbound mappings exist primarily to
      facilitate outbound communication; inbound mappings exist
      primarily to facilitate inbound communication.  Dynamic mappings
      are deleted when their lifetime expires, or through other protocol
      action; static mappings are permanent until the user chooses to
      delete them.

      *  Implicit dynamic mappings are created implicitly as a side
         effect of traffic such as an outgoing TCP SYN or outgoing UDP
         packet.  Such packets were not originally designed explicitly
         for creating NAT (or firewall) state, but they can have that
         effect when they pass through a NAT (or firewall) device.
         Implicit dynamic mappings usually have a finite lifetime,
         though this lifetime is generally not known to the client using
         them.

      *  Explicit dynamic mappings are created as a result of explicit
         PCP MAP and PEER requests.  Like a DHCP address lease, explicit
         dynamic mappings have a finite lifetime, and this lifetime is
         communicated to the client.  As with a DHCP address lease, if
         the client wants a mapping to persist the client must prove
         that it is still present by periodically renewing the mapping
         to prevent it from expiring.  If a PCP client goes away, then
         any mappings it created will be automatically cleaned up when
         they expire.

      *  Explicit static mappings are created by manual configuration
         (e.g., via command-line interface or other user interface) and
         persist until the user changes that manual configuration.

      Both implicit and explicit dynamic mappings are dynamic in the
      sense that they are created on demand, as requested (implicitly or
      explicitly) by the internal host, and have a lifetime.  After the
      lifetime, the mapping is deleted unless the lifetime is extended
      by action by the internal host (e.g., sending more traffic or
      sending another PCP request).

      Static mappings are, by their nature, always explicit.  Static
      mappings differ from explicit dynamic mappings in that their
      lifetime is effectively infinite (they exist until manually
      removed), but otherwise they behave exactly the same as explicit
      MAP mappings.

Top      ToC       Page 9 
      While all mappings are, by necessity, bidirectional (most Internet
      communication requires information to flow in both directions for
      successful operation), when talking about mappings, it can be
      helpful to identify them loosely according to their 'primary'
      purpose.

      *  Outbound mappings exist primarily to enable outbound
         communication.  For example, when a host calls connect() to
         make an outbound connection, a NAT gateway will create an
         implicit dynamic outbound mapping to facilitate that outbound
         communication.

      *  Inbound mappings exist primarily to enable listening servers to
         receive inbound connections.  Generally, when a client calls
         listen() to listen for inbound connections, a NAT gateway will
         not implicitly create any mapping to facilitate that inbound
         communication.  A PCP MAP request can be used explicitly to
         create a dynamic inbound mapping to enable the desired inbound
         communication.

      Explicit static (manual) mappings and explicit dynamic (MAP)
      mappings both allow internal hosts to receive inbound traffic that
      is not in direct response to any immediately preceding outbound
      communication (i.e., to allow internal hosts to operate a "server"
      that is accessible to other hosts on the Internet).

   PCP Client:
      A PCP software instance responsible for issuing PCP requests to a
      PCP server.  Several independent PCP clients can exist on the same
      host.  Several PCP clients can be located in the same local
      network.  A PCP client can issue PCP requests on behalf of a
      third-party device for which it is authorized to do so.  An
      interworking function from Universal Plug and Play Internet
      Gateway Device (UPnP IGDv1 [IGDv1]) to PCP is another example of a
      PCP client.  A PCP server in a NAT gateway that is itself a client
      of another NAT gateway (nested NAT) may itself act as a PCP client
      to the upstream NAT.

   PCP-Controlled Device:
      A NAT or firewall that controls or rewrites packet flows between
      internal hosts and remote peer hosts.  PCP manages the mappings on
      this device.

   PCP Server:
      A PCP software instance that resides on the PCP-Controlled Device
      that receives PCP requests from the PCP client and creates
      appropriate state in response to that request.

Top      ToC       Page 10 
   Subscriber:
      The unit of billing for a commercial ISP.  A subscriber may have a
      single IP address from the commercial ISP (which can be shared
      among multiple hosts using a NAT gateway, thereby making them
      appear to be a single host to the ISP) or may have multiple IP
      addresses provided by the commercial ISP.  In either case, the IP
      address or addresses provided by the ISP may themselves be further
      translated by a Carrier-Grade NAT (CGN) operated by the ISP.

4.  Relationship between PCP Server and Its PCP-Controlled Device

   The PCP server receives and responds to PCP requests.  The PCP server
   functionality is typically a capability of a NAT or firewall device,
   as shown in Figure 1.  It is also possible for the PCP functionality
   to be provided by some other device, which communicates with the
   actual NAT(s) or firewall(s) via some other proprietary mechanism, as
   long as from the PCP client's perspective such split operation is
   indistinguishable from the integrated case.

                                  +-----------------+
         +------------+           | NAT or firewall |
         | PCP client |-<network>-+      with       +---<Internet>
         +------------+           |    PCP server   |
                                  +-----------------+

                   Figure 1: PCP-Enabled NAT or Firewall

   A NAT or firewall device, between the PCP client and the Internet,
   might implement simple or advanced firewall functionality.  This may
   be a side effect of the technology implemented by the device (e.g., a
   network address and port translator, by virtue of its port rewriting,
   normally requires connections to be initiated from an inside host
   towards the Internet), or this might be an explicit firewall policy
   to deny unsolicited traffic from the Internet.  Some firewall devices
   deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to
   most ports) but allow certain other unsolicited traffic from the
   Internet (e.g., UDP port 500 and IP ESP) [RFC6092].  Such default
   filtering (or lack thereof) is out of scope of PCP itself.  If a
   client device wants to receive traffic and supports PCP, and does not
   possess prior knowledge of such default filtering policy, it SHOULD
   use PCP to request the necessary mappings to receive the desired
   traffic.

5.  Note on Fixed-Size Addresses

   For simplicity in building and parsing request and response packets,
   PCP always uses fixed-size 128-bit IP address fields for both IPv6
   addresses and IPv4 addresses.

Top      ToC       Page 11 
   When the address field holds an IPv6 address, the fixed-size 128-bit
   IP address field holds the IPv6 address stored as is.

   When the address field holds an IPv4 address, an IPv4-mapped IPv6
   address [RFC4291] is used (::ffff:0:0/96).  This has the first 80
   bits set to zero and the next 16 set to one, while its last 32 bits
   are filled with the IPv4 address.  This is unambiguously
   distinguishable from a native IPv6 address, because an IPv4-mapped
   IPv6 address [RFC4291] would not be valid for a mapping.

   When checking for an IPv4-mapped IPv6 address, all of the first 96
   bits MUST be checked for the pattern -- it is not sufficient to check
   for ones in bits 81-96.

   The all-zeros IPv6 address MUST be expressed by filling the
   fixed-size 128-bit IP address field with all zeros (::).

   The all-zeros IPv4 address MUST be expressed by 80 bits of zeros,
   16 bits of ones, and 32 bits of zeros (::ffff:0:0).

6.  Protocol Design Note

   PCP can be viewed as a request/response protocol, much like many
   other UDP-based request/response protocols, and can be implemented
   perfectly well as such.  It can also be viewed as what might be
   called a hint/notification protocol, and this observation can help
   simplify implementations.

   Rather than viewing the message streams between PCP client and PCP
   server as following a strict request/response pattern, where every
   response is associated with exactly one request, the message flows
   can be viewed as two somewhat independent streams carrying
   information in opposite directions:

   o  A stream of hints flowing from PCP client to PCP server, where the
      client indicates to the server what it would like the state of its
      mappings to be, and

   o  A stream of notifications flowing from PCP server to PCP client,
      where the server informs the clients what the state of its
      mappings actually is.

   To an extent, some of this approach is required anyway in a UDP-based
   request/response protocol, since UDP packets can be lost, duplicated,
   or reordered.

Top      ToC       Page 12 
   In this view of the protocol, the client transmits hints to the
   server at various intervals signaling its desires, and the server
   transmits notifications to the client signaling the actual state of
   its mappings.  These two message flows are loosely correlated in that
   a client request (hint) usually elicits a server response
   (notification), but only loosely, in that a client request may result
   in no server response (in the case of packet loss), and a server
   response may be generated gratuitously without an immediately
   preceding client request (in the case where server configuration
   change, e.g., change of external IP address on a NAT gateway, results
   in a change of mapping state).

   The exact times that client requests are sent are influenced by a
   client timing state machine taking into account whether (i) the
   client has not yet received a response from the server for a prior
   request (retransmission), or (ii) the client has previously received
   a response from the server saying how long the indicated mapping
   would remain active (renewal).  This design philosophy is the reason
   why PCP's retransmissions and renewals are exactly the same packet on
   the wire.  Typically, retransmissions are sent with exponentially
   increasing intervals as the client waits for the server to respond,
   whereas renewals are sent with exponentially decreasing intervals as
   the expiry time approaches, but, from the server's point of view,
   both packets are identical, and both signal the client's desire that
   the stated mapping exist or continue to exist.

   A PCP server usually sends responses as a direct result of client
   requests, but not always.  For example, if a server is too overloaded
   to respond, it is allowed to silently ignore a request message and
   let the client retransmit.  Also, if external factors cause a NAT
   gateway or firewall's configuration to change, then the PCP server
   can send unsolicited responses to clients informing them of the new
   state of their mappings.  Such reconfigurations are expected to be
   rare, because of the disruption they can cause to clients, but should
   they happen, PCP provides a way for servers to communicate the new
   state to clients promptly, without having to wait for the next
   periodic renewal request.

   This design goal helps explain why PCP request and response messages
   have no transaction ID, because such a transaction ID is unnecessary,
   and would unnecessarily limit the protocol and unnecessarily
   complicate implementations.  A PCP server response (i.e.,
   notification) is self-describing and complete.  It communicates the
   internal and external addresses, protocol, and ports for a mapping,
   and its remaining lifetime.  If the client does in fact currently
   want such a mapping to exist, then it can identify the mapping in
   question from the internal address, protocol, and port, and update
   its state to reflect the current external address and port, and

Top      ToC       Page 13 
   remaining lifetime.  If a client does not currently want such a
   mapping to exist, then it can safely ignore the message.  No client
   action is required for unexpected mapping notifications.  In today's
   world, a NAT gateway can have a static mapping, and the client device
   has no explicit knowledge of this, and no way to change the fact.
   Also, in today's world, a client device can be connected directly to
   the public Internet, with a globally routable IP address, and, in
   this case, it effectively has "mappings" for all of its listening
   ports.  Such a device has to be responsible for its own security and
   cannot rely on assuming that some other network device will be
   blocking all incoming packets.

7.  Common Request and Response Header Format

   All PCP messages are sent over UDP, with a maximum UDP payload length
   of 1100 octets.  The PCP messages contain a request or response
   header containing an Opcode, any relevant Opcode-specific
   information, and zero or more options.  All numeric quantities larger
   than a single octet (e.g., result codes, lifetimes, Epoch times,
   etc.) are represented in conventional IETF network order, i.e., most
   significant octet first.  Non-numeric quantities are represented as
   is on all platforms, with no byte swapping (e.g., IP addresses and
   ports are placed in PCP messages using the same representation as
   when placed in IP or TCP headers).

   The packet layout for the common header, and operation of the PCP
   client and PCP server, are described in the following sections.  The
   information in this section applies to all Opcodes.  Behavior of the
   Opcodes defined in this document is described in Sections 10, 11, and
   12.

Top      ToC       Page 14 
7.1.  Request Header

   All requests have the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 2  |R|   Opcode    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Requested Lifetime (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP Address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) Opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Common Request Packet Format

   These fields are described below:

   Version:  This document specifies protocol version 2.  PCP clients
      and servers compliant with this document use the value 2.  This
      field is used for version negotiation as described in Section 9.

   R: Indicates Request (0) or Response (1).

   Opcode:  A 7-bit value specifying the operation to be performed.  MAP
      and PEER Opcodes are defined in Sections 11 and 12.

   Reserved:  16 reserved bits.  MUST be zero on transmission and MUST
      be ignored on reception.

   Requested Lifetime:  An unsigned 32-bit integer, in seconds, ranging
      from 0 to 2^32-1 seconds.  This is used by the MAP and PEER
      Opcodes defined in this document for their requested lifetime.

Top      ToC       Page 15 
   PCP Client's IP Address:  The source IPv4 or IPv6 address in the IP
      header used by the PCP client when sending this PCP request.  An
      IPv4 address is represented using an IPv4-mapped IPv6 address.
      The PCP Client IP Address in the PCP message header is used to
      detect an unexpected NAT on the path between the PCP client and
      the PCP-controlled NAT or firewall device.  See Section 8.1.

   Opcode-specific information:  Payload data for this Opcode.  The
      length of this data is determined by the Opcode definition.

   PCP Options:  Zero, one, or more options that are legal for both a
      PCP request and for this Opcode.  See Section 7.3.

7.2.  Response Header

   All responses have the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 2  |R|   Opcode    |   Reserved    |  Result Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Lifetime (32 bits)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Epoch Time (32 bits)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                      Reserved (96 bits)                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) Opcode-specific response data          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Options                                :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: Common Response Packet Format

   These fields are described below:

   Version:  Responses from servers compliant with this specification
      MUST use version 2.  This is set by the server.

   R: Indicates Request (0) or Response (1).  All Responses MUST use 1.
      This is set by the server.

Top      ToC       Page 16 
   Opcode:  The 7-bit Opcode value.  The server copies this value from
      the request.

   Reserved:  8 reserved bits, MUST be sent as 0, MUST be ignored when
      received.  This is set by the server.

   Result Code:  The result code for this response.  See Section 7.4 for
      values.  This is set by the server.

   Lifetime:  An unsigned 32-bit integer, in seconds, ranging from 0 to
      2^32-1 seconds.  On an error response, this indicates how long
      clients should assume they'll get the same error response from
      that PCP server if they repeat the same request.  On a success
      response for the PCP Opcodes that create a mapping (MAP and PEER),
      the Lifetime field indicates the lifetime for this mapping.  This
      is set by the server.

   Epoch Time:  The server's Epoch Time value.  See Section 8.5 for
      discussion.  This value is set by the server, in both success and
      error responses.

   Reserved:  96 reserved bits.  For requests that were successfully
      parsed, this MUST be sent as 0, MUST be ignored when received.
      This is set by the server.  For requests that were not
      successfully parsed, the server copies the last 96 bits of the PCP
      Client's IP Address field from the request message into this
      corresponding 96-bit field of the response.

   Opcode-specific information:  Payload data for this Opcode.  The
      length of this data is determined by the Opcode definition.

   PCP Options:  Zero, one, or more options that are legal for both a
      PCP response and for this Opcode.  See Section 7.3.

7.3.  Options

   A PCP Opcode can be extended with one or more options.  Options can
   be used in requests and responses.  The design decisions in this
   specification about whether to include a given piece of information
   in the base Opcode format or in an option were an engineering trade-
   off between packet size and code complexity.  For information that is
   usually (or always) required, placing it in the fixed Opcode data
   results in simpler code to generate and parse the packet, because the
   information is a fixed location in the Opcode data, but wastes space
   in the packet in the event that field is all zeros because the
   information is not needed or not relevant.  For information that is
   required less often, placing it in an option results in slightly more
   complicated code to generate and parse packets containing that

Top      ToC       Page 17 
   option, but saves space in the packet when that information is not
   needed.  Placing information in an option also means that an
   implementation that never uses that information doesn't even need to
   implement code to generate and parse it.  For example, a client that
   never requests mappings on behalf of some other device doesn't need
   to implement code to generate the THIRD_PARTY option, and a PCP
   server that doesn't implement the necessary security measures to
   create third-party mappings safely doesn't need to implement code to
   parse the THIRD_PARTY option.

   Options use the following Type-Length-Value format:

      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  |  Reserved     |       Option Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                       (optional) Data                         :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: Options Header

   The description of the fields is as follows:

   Option Code:  8 bits.  Its most significant bit indicates if this
      option is mandatory (0) or optional (1) to process.

   Reserved:  8 bits.  MUST be set to 0 on transmission and MUST be
      ignored on reception.

   Option Length:  16 bits.  Indicates the length of the enclosed data,
      in octets.  Options with length of 0 are allowed.  Options that
      are not a multiple of 4 octets long are followed by one, two, or
      three 0 octets to pad their effective length in the packet to be a
      multiple of 4 octets.  The Option Length reflects the semantic
      length of the option, not including any padding octets.

   Data:  Option data.

   If several options are included in a PCP request, they MAY be encoded
   in any order by the PCP client, but MUST be processed by the PCP
   server in the order in which they appear.  It is the responsibility
   of the PCP client to ensure that the server has sufficient room to
   reply without exceeding the 1100-octet size limit; if its reply would
   exceed that size, the server generates an error.

Top      ToC       Page 18 
   If, while processing a PCP request, including its options, an error
   is encountered that causes a PCP error response to be generated, the
   PCP request MUST cause no state change in the PCP server or the
   PCP-controlled device (i.e., it rolls back any tentative changes it
   might have made while processing the request).  Such an error
   response MUST consist of a complete copy of the request packet with
   the error code and other appropriate fields set in the header.

   An option MAY appear more than once in a request or in a response, if
   permitted by the definition of the option.  If the option's
   definition allows the option to appear only once but it appears more
   than once in a request, and the option is understood by the PCP
   server, the PCP server MUST respond with the MALFORMED_OPTION result
   code.  If the PCP server encounters an invalid option (e.g., PCP
   option length is longer than the UDP packet length), the error
   MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST),
   as that helps the client better understand how the packet was
   malformed.  If a PCP response would have exceeded the maximum PCP
   message size, the PCP server SHOULD respond with MALFORMED_REQUEST.

   If the overall option structure of a request cannot successfully be
   parsed (e.g., a nonsensical option length), the PCP server MUST
   generate an error response with code MALFORMED_OPTION.

   If the overall option structure of a request is valid, then how each
   individual option is handled is determined by the most significant
   bit in the option code.  If the most significant bit is set, handling
   this option is optional, and a PCP server MAY process or ignore this
   option, entirely at its discretion.  If the most significant bit is
   clear, handling this option is mandatory, and a PCP server MUST
   return the error MALFORMED_OPTION if the option contents are
   malformed, or UNSUPP_OPTION if the option is unrecognized,
   unimplemented, or disabled, or if the client is not authorized to use
   the option.  In error responses, all options are returned.  In
   success responses, all processed options are included and unprocessed
   options are not included.

   Because the PCP client cannot reject a response containing an Option,
   PCP clients MUST ignore Options that they do not understand that
   appear in responses, including Options in the mandatory-to-process
   range.  Naturally, if a client explicitly requests an Option where
   correct execution of that Option requires processing the Option data
   in the response, that client SHOULD implement code to do that.

Top      ToC       Page 19 
   Different options are valid for different Opcodes.  For example:

   o  The THIRD_PARTY option is valid for both MAP and PEER Opcodes.

   o  The FILTER option is valid only for the MAP Opcode (for the PEER
      Opcode it would have no meaning).

   o  The PREFER_FAILURE option is valid only for the MAP Opcode (for
      the PEER Opcode, similar semantics are automatically implied).

7.4.  Result Codes

   The following result codes may be returned as a result of any Opcode
   received by the PCP server.  The only success result code is 0; other
   values indicate an error.  If a PCP server encounters multiple errors
   during processing of a request, it SHOULD use the most specific error
   message.  Each error code below is classified as either a 'long
   lifetime' error or a 'short lifetime' error, which provides guidance
   to PCP server developers for the value of the Lifetime field for
   these errors.  It is RECOMMENDED that short lifetime errors use a
   30-second lifetime and long lifetime errors use a 30-minute lifetime.

   0  SUCCESS: Success.

   1  UNSUPP_VERSION: The version number at the start of the PCP Request
      header is not recognized by this PCP server.  This is a long
      lifetime error.  This document describes PCP version 2.

   2  NOT_AUTHORIZED: The requested operation is disabled for this PCP
      client, or the PCP client requested an operation that cannot be
      fulfilled by the PCP server's security policy.  This is a long
      lifetime error.

   3  MALFORMED_REQUEST: The request could not be successfully parsed.
      This is a long lifetime error.

   4  UNSUPP_OPCODE: Unsupported Opcode.  This is a long lifetime error.

   5  UNSUPP_OPTION: Unsupported option.  This error only occurs if the
      option is in the mandatory-to-process range.  This is a long
      lifetime error.

   6  MALFORMED_OPTION: Malformed option (e.g., appears too many times,
      invalid length).  This is a long lifetime error.

   7  NETWORK_FAILURE: The PCP server or the device it controls is
      experiencing a network failure of some sort (e.g., has not yet
      obtained an external IP address).  This is a short lifetime error.

Top      ToC       Page 20 
   8  NO_RESOURCES: Request is well-formed and valid, but the server has
      insufficient resources to complete the requested operation at this
      time.  For example, the NAT device cannot create more mappings at
      this time, is short of CPU cycles or memory, or is unable to
      handle the request due to some other temporary condition.  The
      same request may succeed in the future.  This is a system-wide
      error, different from USER_EX_QUOTA.  This can be used as a catch-
      all error, should no other error message be suitable.  This is a
      short lifetime error.

   9  UNSUPP_PROTOCOL: Unsupported transport protocol, e.g., SCTP in a
      NAT that handles only UDP and TCP.  This is a long lifetime error.

   10 USER_EX_QUOTA: This attempt to create a new mapping would exceed
      this subscriber's port quota.  This is a short lifetime error.

   11 CANNOT_PROVIDE_EXTERNAL: The suggested external port and/or
      external address cannot be provided.  This error MUST only be
      returned for:
      *  MAP requests that included the PREFER_FAILURE option
         (normal MAP requests will return an available external port)
      *  MAP requests for the SCTP protocol (PREFER_FAILURE is implied)
      *  PEER requests

      See Section 13.2 for details of the PREFER_FAILURE Option.  The
      error lifetime depends on the reason for the failure.

   12 ADDRESS_MISMATCH: The source IP address of the request packet does
      not match the contents of the PCP Client's IP Address field, due
      to an unexpected NAT on the path between the PCP client and the
      PCP-controlled NAT or firewall.  This is a long lifetime error.

   13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the
      filters in this request.  This result code MUST only be returned
      if the MAP request contained the FILTER option.  See Section 13.3
      for details of the FILTER Option.  This is a long lifetime error.



(page 20 continued on part 2)

Next RFC Part