idnits 2.17.1 draft-ietf-pcp-base-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 28, 2011) is 4806 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-02) exists of draft-bpw-pcp-proxy-00 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP working group D. Wing, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Cheshire 5 Expires: September 1, 2011 Apple 6 M. Boucadair 7 France Telecom 8 R. Penno 9 Juniper Networks 10 F. Dupont 11 Internet Systems Consortium 12 February 28, 2011 14 Port Control Protocol (PCP) 15 draft-ietf-pcp-base-06 17 Abstract 19 Port Control Protocol allows a host to control how incoming IPv6 or 20 IPv4 packets are translated and forwarded by a network address 21 translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also 22 allows a host to optimize its NAT keepalive messages. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 1, 2011. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5 66 2.2. Supported Transport Protocols . . . . . . . . . . . . . . 5 67 2.3. Single-homed Customer Premises Network . . . . . . . . . . 5 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Relationship of PCP Server and its NAT . . . . . . . . . . . . 8 70 5. Common Request and Response Header Format . . . . . . . . . . 9 71 5.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 9 72 5.2. Response Header . . . . . . . . . . . . . . . . . . . . . 10 73 5.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 13 75 6. General PCP Operation . . . . . . . . . . . . . . . . . . . . 14 76 6.1. General PCP Client: Generating a Request . . . . . . . . . 14 77 6.2. General PCP Server: Processing a Request . . . . . . . . . 15 78 6.3. General PCP Client: Processing a Response . . . . . . . . 16 79 6.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . . 16 80 6.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.6. Version negotiation . . . . . . . . . . . . . . . . . . . 18 82 6.7. General PCP Options . . . . . . . . . . . . . . . . . . . 19 83 6.7.1. UNPROCESSED . . . . . . . . . . . . . . . . . . . . . 19 84 7. Introduction to MAP and PEER OpCodes . . . . . . . . . . . . . 20 85 7.1. For Operating a Server . . . . . . . . . . . . . . . . . . 20 86 7.2. For Reducing NAT Keepalive Messages . . . . . . . . . . . 21 87 7.3. For Operating a Symmetric Client/Server . . . . . . . . . 22 88 8. MAP OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 8.1. OpCode Packet Formats . . . . . . . . . . . . . . . . . . 23 90 8.2. OpCode-Specific Result Codes . . . . . . . . . . . . . . . 26 91 8.3. OpCode-Specific Client: Generating a Request . . . . . . . 27 92 8.4. OpCode-Specific Server: Processing a Request . . . . . . . 27 93 8.5. OpCode-Specific Client: Processing a Response . . . . . . 29 94 8.6. Mapping Lifetime and Deletion . . . . . . . . . . . . . . 30 95 8.7. Subscriber Renumbering . . . . . . . . . . . . . . . . . . 31 96 8.8. PCP Options for MAP OpCodes . . . . . . . . . . . . . . . 31 97 8.8.1. REMOTE_PEER_FILTER . . . . . . . . . . . . . . . . . . 31 98 8.8.2. PREFER_FAILURE . . . . . . . . . . . . . . . . . . . . 34 99 8.8.3. THIRD_PARTY . . . . . . . . . . . . . . . . . . . . . 35 100 8.9. PCP Mapping State Maintenance . . . . . . . . . . . . . . 35 101 8.9.1. Recreating Mappings . . . . . . . . . . . . . . . . . 35 102 8.9.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 36 103 9. PEER OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 9.1. OpCode Packet Formats . . . . . . . . . . . . . . . . . . 37 105 9.2. OpCode-Specific Result Codes . . . . . . . . . . . . . . . 40 106 9.3. OpCode-Specific Client: Generating a Request . . . . . . . 40 107 9.4. OpCode-Specific Server: Processing a Request . . . . . . . 41 108 9.5. OpCode-Specific Client: Processing a Response . . . . . . 41 109 9.6. PCP Options for PEER OpCodes . . . . . . . . . . . . . . . 42 110 9.6.1. THIRD_PARTY . . . . . . . . . . . . . . . . . . . . . 42 111 10. THIRD_PARTY Option for MAP and PEER OpCodes . . . . . . . . . 42 112 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 45 113 11.1. Maintaining Same External IP Address . . . . . . . . . . . 45 114 11.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 45 115 11.3. Per-Subscriber Port Forwarding Quota . . . . . . . . . . . 45 116 12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 46 117 12.1. Dual Stack-Lite . . . . . . . . . . . . . . . . . . . . . 46 118 12.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 46 119 12.2. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 47 120 12.3. NAT44 and NAT444 . . . . . . . . . . . . . . . . . . . . . 47 121 12.4. IPv6 Simple Firewall . . . . . . . . . . . . . . . . . . . 47 122 13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 123 13.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 48 124 13.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 48 125 13.3. Validating Target Address . . . . . . . . . . . . . . . . 48 126 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 127 14.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 48 128 14.2. OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 48 129 14.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 49 130 14.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 49 131 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 132 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 133 16.1. Normative References . . . . . . . . . . . . . . . . . . . 49 134 16.2. Informative References . . . . . . . . . . . . . . . . . . 50 135 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 52 136 A.1. Changes from draft-ietf-pcp-base-05 to -06 . . . . . . . . 52 137 A.2. Changes from draft-ietf-pcp-base-04 to -05 . . . . . . . . 53 138 A.3. Changes from draft-ietf-pcp-base-03 to -04 . . . . . . . . 54 139 A.4. Changes from draft-ietf-pcp-base-02 to -03 . . . . . . . . 54 140 A.5. Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . . 55 141 A.6. Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . . 55 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 144 1. Introduction 146 Port Control Protocol (PCP) provides a mechanism to control how 147 incoming packets are forwarded by upstream devices such as NAT64, 148 NAT44, and firewall devices, and a mechanism to reduce application 149 keepalive traffic. PCP is primarily designed to be implemented in 150 the context of both Carrier-Grade NATs (CGN) and small NATs (e.g., 151 residential NATs). PCP allows hosts to operate server for a long 152 time (e.g., a webcam) or a short time (e.g., while playing a game or 153 on a phone call) when behind a NAT device, including when behind a 154 CGN operated by their Internet service provider. 156 PCP allows applications to create mappings from an external IP 157 address and port to an internal (target) IP address and port. These 158 mappings are required for successful inbound communications destined 159 to machines located behind a NAT or a firewall. 161 After creating a mapping for incoming connections, it is necessary to 162 inform remote computers about the IP address and port for the 163 incoming connection. This is usually done in an application-specific 164 manner. For example, a computer game would use a rendezvous server 165 specific to that game (or specific to that game developer), and a SIP 166 phone would use a SIP proxy. PCP does not provide this rendezvous 167 function. The rendezvous function will support IPv4, IPv6, or both. 168 Depending on that support and the application's support of IPv4 or 169 IPv6, the PCP client will need an IPv4 mapping, an IPv6 mapping, or 170 both. 172 Many NAT-friendly applications send frequent application-level 173 messages to ensure their session will not be timed out by a NAT. 174 These are commonly called "NAT keepalive" messages, even though they 175 are not sent to the NAT itself (rather, they are sent 'through' the 176 NAT). These applications can reduce the frequency of those NAT 177 keepalive messages by using PCP to learn (or control) the NAT mapping 178 lifetime. This helps reduce bandwidth on the subscriber's access 179 network, traffic to the server, and battery consumption on mobile 180 devices. 182 Many NATs and firewalls have included application layer gateways 183 (ALGs) to create mappings for applications that establish additional 184 streams or accept incoming connections. ALGs incorporated into NATs 185 additionally modify the application payload. Industry experience has 186 shown that these ALGs are detrimental to protocol evolution. PCP 187 allows an application create its own mappings in NATs and firewalls, 188 removing the incentive to deploy ALGs in NATs and firewalls. 190 2. Scope 192 2.1. Deployment Scenarios 194 PCP can be used in various deployment scenarios, including: 196 o Dual Stack-Lite [I-D.ietf-softwire-dual-stack-lite], and; 198 o NAT64, both Stateful [I-D.ietf-behave-v6v4-xlate-stateful] and 199 Stateless [I-D.ietf-behave-v6v4-xlate], and; 201 o Carrier-Grade NAT [I-D.ietf-behave-lsn-requirements], and; 203 o Basic NAT [RFC3022], and; 205 o Network Address and Port Translation (NAPT) [RFC3022], such as 206 commonly deployed in residential NAT devices, and; 208 o Layer-2 aware NAT [I-D.miles-behave-l2nat] and Dual-Stack Extra 209 Lite [I-D.arkko-dual-stack-extra-lite], and; 211 o IPv6 firewall control [RFC6092]. 213 2.2. Supported Transport Protocols 215 The PCP OpCodes defined in this document are designed to support 216 transport protocols that use a 16-bit port number (e.g., TCP, UDP, 217 SCTP, DCCP). Transport protocols that do not use a port number 218 (e.g., IPsec ESP), and the ability to use PCP to forward all traffic 219 to a single default host (often nicknamed "DMZ"), are beyond the 220 scope of this document. 222 2.3. Single-homed Customer Premises Network 224 The PCP machinery assumes a single-homed host model. That is, for a 225 given IP version, only one default route exists to reach the 226 Internet. This is important because after a PCP mapping is created 227 and an inbound packet (e.g., TCP SYN) arrives at the host the 228 outbound response (e.g., TCP SYNACK) has to go through the same path 229 so the proper address rewriting takes place on that outbound response 230 packet. This restriction exists because otherwise there would need 231 to be one PCP server for each egress, because the host could not 232 reliably determine which egress path packets would take, so the 233 client would need to be able to reliably make the same internal/ 234 external mapping in every NAT gateway, which in general is not 235 possible. 237 3. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in RFC 2119 [RFC2119]. 243 Internal Host, Target Host: 244 A host served by a NAT gateway, or protected by a firewall. This 245 is the host that receives the incoming traffic created by a PCP 246 MAP request, or the host that initiated an implicit dynamic 247 mapping (e.g., TCP SYN) across a firewall or a NAT. 249 Remote Host: 250 A host with which an Internal Host is communicating. 252 Target Address, External Address, Remote Peer Address: 253 The address of an Internal Host served by a NAT gateway (typically 254 a private address [RFC1918]) or an Internal Host protected by a 255 firewall. 257 An External Address is the address of an Internal Host as seen by 258 other Remote Hosts on the Internet with which the Internal Host is 259 communicating, after translation by any NAT gateways on the path. 260 An External Address is generally a public routable (i.e., non- 261 private) address. In the case of an Internal Host protected by a 262 pure firewall, with no address translation on the path, its 263 External Address is the same as its Internal Address. 265 A Remote Peer Address is the address of a Remote Host, as seen by 266 the Internal Host. A Remote Address is generally a public 267 routable address. In the case of a Remote Host that is itself 268 served by a NAT gateway, the Remote Address my in fact be the 269 Remote Host's External Address, but since this remote translation 270 is generally invisible to software running on the Internal Host, 271 the distinction can safely be ignored for the purposes of this 272 document. 274 Third Party: 275 In the common case, an Internal Host manages its own Mappings 276 using PCP requests, and the Internal Address of those Mappings is 277 the same as the source IP address of the PCP request packet. 279 In the case where one device is managing Mappings on behalf of 280 some other device, the presence of the THIRD_PARTY option in the 281 MAP request signifies that the specified address, not the source 282 IP address of the PCP request packet, should be used as the 283 Internal Address for the Mapping. This can occur when PCP is 284 proxied (e.g., PCP to PCP proxy, UPnP IGD to PCP proxy) or if the 285 target host does not implement PCP. 287 Mapping: 288 A NAT mapping creates a relationship between an internal (target) 289 IP transport address and an external IP transport address. More 290 specifically, it creates a translation rule where packets destined 291 to the external IP and port are translated to the target IP and 292 port. In the case of a pure firewall, the "Mapping" is the 293 identity function, translating an internal port number to the same 294 external port number and vice versa, and this "Mapping" indicates 295 to the firewall that traffic to and from this internal port number 296 is permitted to pass. See also Port Forwarding. 298 Mapping Types: 299 There are three different ways to create mappings: implicit 300 dynamic mappings, explicit dynamic mappings, and static mappings. 301 Implicit dynamic mappings are created as a result of a TCP SYN or 302 outgoing UDP packet. Explicit dynamic mappings are created as a 303 result of PCP MAP requests. Both implicit and explicit dynamic 304 mappings are dynamic in the sense that they are created on demand, 305 as requested (implicitly or explicitly) by the Internal Host, and 306 have a lifetime, after which they are automatically deleted unless 307 the lifetime is extended by action by the Internal Host. Static 308 mappings are created by manual configuration (e.g., command 309 language interface or web page) and differ from dynamic mappings 310 in that their lifetime is typically infinite (they exist until 311 manually removed) but otherwise they behave exactly the same as 312 dynamic mappings. For example, a PCP MAP request to create a 313 mapping that already exists as a static mapping will return a 314 successful result, confirming that the requested mapping exists. 316 Port Forwarding, Port Mapping: 317 Port forwarding (or port mapping) allows a host to receive traffic 318 sent to a specific IP address and port. 320 In the context of a NAT or NAPT, the Internal Address and External 321 Address are different. In the context of a pure firewall, the 322 Internal Address and External Address are the same. In both 323 contexts, if an internal host is listening to connections on a 324 specific port (that is, operating as a server), the external IP 325 address and port number need to be port forwarded to the internal 326 IP address and port number, which may be the same, in the case of 327 a pure firewall. In the context of a NAPT, it is possible that 328 both the IP address and port are modified. For example with a 329 NAPT, a webcam might be listening on port 80 on its internal 330 address 192.168.1.1, while its publicly-accessible external 331 address is 192.0.2.1 and port is 12345. The NAT does 'port 332 forwarding' of one to the other. 334 PCP Client: 335 A PCP software instance responsible for issuing PCP requests to a 336 PCP server. One or several PCP Clients can be embedded in the 337 same host. Several PCP Clients can be located in the same local 338 network of a given subscriber. A PCP Client can issue PCP request 339 on behalf of a third party device of the same subscriber. An 340 interworking function, from UPnP IGD to PCP, or from NAT-PMP 341 [I-D.cheshire-nat-pmp] is another example of a PCP Client. A PCP 342 server in a NAT gateway that is itself a client of another NAT 343 gateway (nested NAT) may itself act as a PCP client to the 344 upstream NAT. 346 PCP Server: 347 A network element which receives and processes PCP requests from a 348 PCP client. See also Section 4. 350 Interworking Function: 351 a functional element responsible for interworking another protocol 352 with PCP. For example interworking between UPnP IGD [IGD] with 353 PCP or NAT-PMP [I-D.cheshire-nat-pmp] and PCP. 355 subscriber: 356 an entity provided access to the network. In the case of a 357 commercial ISP, this is typically a single home. 359 host: 360 a device which can have packets sent to it, as a result of PCP 361 operations. A host is not necessarily a PCP client. 363 5-tuple The 5 pieces of information that fully identify a flow: 364 source IP address, destination IP address, protocol, source port 365 number, destination port number. 367 4. Relationship of PCP Server and its NAT 369 The PCP server receives PCP requests. The PCP server might be 370 integrated within the NAT or firewall device (as shown in Figure 1) 371 which is expected to be a common deployment. 373 +-----------------+ 374 +------------+ | NAT or firewall | 375 | PCP client |--+ with +--- 376 +------------+ | PCP server | 377 +-----------------+ 379 Figure 1: NAT or Firewall with Embedded PCP Server 381 It is also possible to operate the PCP server in a separate device 382 from the NAT, so long as such operation is indistinguishable from the 383 PCP client's perspective. 385 5. Common Request and Response Header Format 387 All PCP messages contain a request (or response) header containing an 388 opcode, any relevant opcode-specific information, and zero or more 389 options. The packet layout for the common header, and operation of 390 the PCP client and PCP server are described in the following 391 sections. The information in this section applies to all OpCodes. 392 Behavior of the OpCodes defined in this document is described in 393 Section 8 and Section 9. 395 5.1. Request Header 397 All requests have the following format: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 |1| Version = 0 |R| OpCode | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 404 | Reserved (48 bits) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 : : 407 : (optional) opcode-specific information : 408 : : 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 : : 411 : (optional) PCP Options : 412 : : 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 2: Common Request Packet Format 417 These fields are described below: 419 1 A single bit set to 1. This allows DTLS and non-DTLS to be 420 multiplexed on same port, should a future update to this 421 specification add DTLS support. 423 Version: This document specifies protocol version 0. Should later 424 updates to this document specify different message formats with a 425 version number greater than zero, the first two bytes of those new 426 message formats will still contain the version number and opcode 427 as shown here, so that a PCP server receiving a message format 428 newer or older than the version(s) it understands can still parse 429 enough of the message to correctly identify the version number, 430 and determine whether the problem is that this server is too old 431 and needs to be updated to work with the PCP client, or whether 432 the PCP client is too old and needs to be updated to work with 433 this server. 435 R: Indicates Request (0) or Response (1). All Requests MUST use 0. 437 OpCode: Opcodes are defined in Section 8 and Section 9. 439 Reserved: 48 reserved bits, MUST be sent as 0 and MUST be ignored 440 when received. 442 5.2. Response Header 444 All responses have the following format: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |1| Version = 0 |R| OpCode | Reserved | Result Code | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Epoch | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 : : 454 : (optional) OpCode-specific response data : 455 : : 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 : (optional) Options : 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 3: Common Response Packet Format 462 These fields are described below: 464 1 A single bit set to 1. 466 Ver: This document specifies protocol version 0. Should later 467 updates to this document specify different message formats with a 468 version number greater than zero, the first four bytes of those 469 new message formats will still contain the version number, opcode, 470 and result code, as shown here, so that a PCP client receiving a 471 message format newer or older than the version(s) it understands 472 can still parse enough of the message to correctly identify the 473 version number, and determine whether the problem is that this 474 client is too old and needs to be updated to work with the PCP 475 server, or whether the PCP server is too old and needs to be 476 updated to work with this client. 478 R: Indicates Request (0) or Response (1). All Responses MUST use 1. 480 OpCode: The OpCode value, copied from the request. 482 Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when 483 received. This is set by the server. 485 Result Code: The result code for this response. See Section 5.4 for 486 values. This is set by the server. 488 Epoch: The server's Epoch value. See Section 6.5 for discussion. 489 This value is set both success and error responses. 491 5.3. Options 493 A PCP OpCode can be extended with an Option. Options can be used in 494 requests and responses. It is anticipated that Options will include 495 information which are associated with the normal function of an 496 OpCode. For example, an Option could indicate DSCP [RFC2474] 497 markings to apply to incoming or outgoing traffic associated with a 498 PCP mapping, or an Option could include descriptive text (e.g., "for 499 my webcam"). 501 Options use the following Type-Length-Value format: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Option Code | Reserved | Option-Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 : (optional) data : 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 4: Options Header 513 The description of the fields is as follows: 515 Option Code: Option code, 8 bits. The first bit of the option code 516 is the "O" (optional) bit. If clear, it indicates the option is 517 mandatory to process (that is, non-optional). If set, it 518 indicates the option is optional. 520 Reserved: MUST be set to 0 on transmission and MUST be ignored on 521 reception. 523 Option-Length: Indicates in units of 4 octets the length of the 524 enclosed data. Options with length of 0 are allowed. 526 data: Option data. The option data MUST end on a 32 bit boundary, 527 padded with 0's when necessary. 529 A given Option MAY be included in a request or a response, as 530 permitted by that Option. If a given Option was included in a 531 request, and understood and processed by the PCP server, it MUST be 532 included in the response. The handling of an Option by the PCP 533 client and PCP server MUST be specified in an appropriate document 534 and must include whether the PCP Option can appear (one or more 535 times) in a request, and indicate the contents of the Option in the 536 request and in the response. If several Options are included in a 537 PCP request or response, they MUST be encoded in numeric order by the 538 PCP client and are processed in the order received. The server MUST 539 reject requests that have mis-ordered options with the 540 MISORDERED_OPTIONS error, and this also includes checking optional- 541 to-process options. 543 If, while processing an option, an error is encountered that causes a 544 PCP error response to be generated, the PCP request causes no state 545 change in the PCP server or the PCP-controlled device (i.e., it rolls 546 back any changes it might have made while processing the request). 547 The response MUST encode the Options in the same order, but may omit 548 some PCP Options in the response, as is necessary to indicate the PCP 549 server does not understand that Option or that Option is not 550 permitted to be included in responses by the definition of the Option 551 itself. Additional Options included in the response (if any) MUST be 552 included at the end. A certain Option MAY appear more than once in a 553 request or in a response, if permitted by the definition of the 554 Option itself. If the Option's definition allows the Option to 555 appear once but it appears more than once in a request, the PCP 556 server MUST respond with the MALFORMED_OPTION result code; if this 557 occurs in a response, the PCP client processes the first occurrence 558 and ignores the other occurrences as if they were not present. 560 If the "O" bit in the OpCode is clear, 562 o the PCP server MUST only generate a positive PCP response if it 563 can successfully process the PCP request and this Option. 565 o if the PCP server does not implement this Option, or cannot 566 perform the function indicated by this Option (e.g., due to a 567 parsing error with the option), it MUST generate a failure 568 response with code UNSUPP_OPTION or MALFORMED_OPTION (as 569 appropriate) and include the UNPROCESSED option in the response 570 (Section 6.7.1). 572 If the "O" bit is set, the PCP server MAY process or ignore this 573 Option, entirely at its discretion. 575 To enhance interoperability, newly defined Options SHOULD NOT be 576 interdependent with each other. Option definitions MUST include the 577 information below: 579 This Option: 581 name: 583 number: 585 purpose: 587 is valid for OpCodes: 589 length: 591 may appear in: 593 maximum occurrences: 595 5.4. Result Codes 597 The following result codes may be returned as a result of any OpCode 598 received by the PCP server. The only success result code is 0, other 599 values indicate an error. If a PCP server has encountered multiple 600 errors during processing of a request, it SHOULD use the most 601 specific error message. 603 0 SUCCESS, success 605 1 MALFORMED_REQUEST, a general catch-all error. 607 2 UNSUPP_OPCODE, unsupported OpCode. 609 3 UNSUPP_OPTION, unsupported Option. This error only occurs if the 610 Option is in the mandatory-to-process range. 612 4 MALFORMED_OPTION, malformed Option (e.g., exists too many times, 613 invalid length). 615 5 UNSPECIFIED_ERROR, server encountered unspecified error. 617 6 UNSUPP_VERSION, unsupported version. 619 7 MISORDERED_OPTIONS, multiple options were in the request, but were 620 not in the required lower..higher order. 622 Additional result codes, specific to the OpCodes and Options defined 623 in this document, are listed in Section 8.2, Section 9.2, and 624 Section 10. 626 6. General PCP Operation 628 PCP messages MUST be sent over UDP, and the PCP server MUST listen 629 for PCP requests on the PCP port number, 44323. Every PCP request 630 generates a response, so PCP does not need to run over a reliable 631 transport protocol. 633 PCP is idempotent, so if the PCP client sends the same request 634 multiple times and the PCP server processes those requests, the same 635 result occurs. The order of operation is that a PCP client generates 636 and sends a request to the PCP server which processes the request and 637 generates a response back to the PCP client. 639 6.1. General PCP Client: Generating a Request 641 This section details operation specific to a PCP client, for any 642 OpCode. Procedures specific to the MAP OpCodes are described in 643 Section 8, and procedures specific to the PEER OpCodes are described 644 in Section 9. 646 Prior to sending its first PCP message, the PCP client determines 647 which servers to use. The PCP client performs the following steps to 648 determine its PCP server(s): 650 1. if a PCP server is configured (e.g., in a configuration file), 651 the address(es) of the PCP server(s) used as the list of PCP 652 server(s), else; 654 2. if DHCP indicates the PCP server(s), the address(es) of the 655 indicated PCP server(s) are used as the the list of PCP 656 server(s), else; 658 3. the address of the default router is used as the PCP server. 660 With that list of PCP servers, the PCP client formulates its PCP 661 request. The PCP request contains a PCP common header, PCP OpCode 662 and payload, and (possibly) Options. It initializes a retransmission 663 timer to 4 seconds. (As with all UDP or TCP clients on any operating 664 system, when several PCP clients are embedded in the same host, each 665 uses a distinct source port number to disambiguate their requests and 666 replies.) The PCP client sends a PCP message to each server in 667 sequence, waiting for a response until its timer expires. Once a PCP 668 client has successfully communicated with a PCP server, it continues 669 communicating with that PCP server until that PCP server has not 670 responded to 5 retransmissions, which causes the PCP client to 671 attempt to re-iterate the procedure starting with the first PCP 672 server on its list. If a hard ICMP error is received the PCP client 673 SHOULD immediately abort trying to contact that PCP server (see 674 Section 2 of [RFC5461] for discussion of ICMP and ICMPv6 hard 675 errors). If no response is received from any of those servers, it 676 doubles its retransmission timer and tries each server again. This 677 is repeated 4 times (for a total of 5 transmissions to each server). 678 If, after these transmissions, the PCP client has still not received 679 a response, the PCP client SHOULD abort the procedure. 681 Upon receiving a response (success or error), the PCP client does not 682 change to a different PCP server. That is, it does not "shop around" 683 trying to find a PCP server to service its (same) request. 685 6.2. General PCP Server: Processing a Request 687 This section details operation specific to a PCP server. 689 Upon receiving a PCP request message, the PCP server parses and 690 validates it. A valid request contains a valid PCP common header, 691 one valid PCP Opcode, and zero or more Options (which the server 692 might or might not comprehend). If an error is encountered during 693 processing, the server generates an error response which is sent back 694 to the PCP client. Processing an OpCode and the Options are specific 695 to each OpCode. 697 If the received message is shorter than 4 octets, has the R bit set, 698 or the first bit is clear, the request is simply dropped. If the 699 version number is not supported, a response is generated containing 700 the UNSUPP_VERSION response code and the protocol version which the 701 server does understand (if the server understands a range of protocol 702 versions then it returns the supported version closest to the version 703 in the request). 705 If the OpCode is not supported, a response is generated with the 706 UNSUPP_OPCODE response code. If the length of the request exceeds 707 1024 octets or is not a multiple of 4 octets, it is invalid. Invalid 708 requests are handled by copying up to 1024 octets of the request into 709 the response, setting the response code to MALFORMED_REQUEST, and 710 zero-padding the response to a multiple of 4 octets if necessary. 712 Error responses have the same packet layout as success responses, 713 with fields copied from the request copied into the response, and 714 other fields assigned by the PCP server MUST be cleared to 0. 716 6.3. General PCP Client: Processing a Response 718 The PCP client receives the response and verifies the source IP 719 address and port belong to the PCP server of an outstanding request. 720 It validates the version number and OpCode matches an outstanding 721 request. Responses shorter than 12 octets, longer than 1024 octets, 722 or not a multiple of 4 octets are invalid and ignored, likely causing 723 the request to be re-transmitted. The response is further matched by 724 comparing fields in the response OpCode-specific data to fields in 725 the request OpCode-specific data. After a successful match with an 726 outstanding request, the PCP client checks the Epoch field to 727 determine if it needs to restore its state to the PCP server (see 728 Section 6.5). 730 If the response code is 0, the PCP client knows the request was 731 successful. 733 If the response code is not 0, the request failed. If the response 734 code is UNSUPP_VERSION, processing continues as described in 735 Section 6.6. If the response code is SERVER_OVERLOADED, clients 736 SHOULD NOT send *any* further requests to that PCP server for the 737 time indicated by that OpCode's response, if present (e.g., the 738 lifetime field of a MAP response), or 30 seconds have elapsed. For 739 other error response codes, The PCP client SHOULD NOT resend the same 740 request for the time indicated by that OpCode's response, if present 741 (e.g., the lifetime field of a MAP response), or 30 seconds have 742 elapsed. 744 If the PCP client has discovered a new PCP server (e.g., connected to 745 a new network), the PCP client MAY immediately begin communicating 746 with this PCP server, without regard to hold times from communicating 747 with a previous PCP server. 749 6.4. Multi-Interface Issues 751 Hosts which desire a PCP mapping might be multi-interfaced (i.e., own 752 several logical/physical interfaces). Indeed, a host can be 753 configured with several IPv4 addresses (e.g., WiFi and Ethernet) or 754 dual-stacked. These IP addresses may have distinct reachability 755 scopes (e.g., if IPv6 they might have global reachability scope as 756 for GUA (Global Unicast Address) or limited scope such as ULA (Unique 757 Local Address, [RFC4193])). 759 IPv6 addresses with global reachability scope SHOULD be used as the 760 source interface when generating a PCP request. IPv6 addresses with 761 limited scope (e.g., ULA [RFC4193]), SHOULD NOT be used as the source 762 interface when generating a PCP request. If IPv6 privacy addresses 763 [RFC4941] are used for PCP mappings, a new PCP request will need to 764 be issued whenever the IPv6 privacy address is changed. This PCP 765 request SHOULD be sent from the IPv6 privacy address itself. It is 766 RECOMMENDED that mappings to the previous privacy address be deleted. 768 Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope 769 (e.g., [RFC1918]) MAY be used as the source interface when generating 770 a PCP request. 772 As mentioned in Section 2.3, only single-homed CP routers are in 773 scope. Therefore, there is no viable scenario where a host located 774 behind a CP router is assigned with two GUA addresses belonging to 775 the same global IPv6 prefix. 777 6.5. Epoch 779 Every PCP response sent by the PCP server includes an Epoch field. 780 This field increments by 1 every second, and indicates to the PCP 781 client if PCP state needs to be restored. If the PCP server resets 782 or loses the state of its explicit dynamic Mappings (that is, those 783 mappings created by PCP MAP requests), due to reboot, power failure, 784 or any other reason, it MUST reset its Epoch time to 0. Similarly, 785 if the public IP address(es) of the NAT (controlled by the PCP 786 server) changes, the Epoch MUST be reset to 0. A PCP server MAY 787 maintain one Epoch value for all PCP clients, or MAY maintain 788 distinct Epoch values for each PCP client; this choice is 789 implementation-dependent. 791 Whenever a client receives a PCP response, the client computes its 792 own conservative estimate of the expected Epoch value by taking the 793 Epoch value in the last packet it received from the gateway and 794 adding 7/8 (87.5%) of the time elapsed since that packet was 795 received. If the Epoch value in the newly received packet is less 796 than the client's conservative estimate by more than one second, then 797 the client concludes that the PCP server lost state, and the client 798 MUST immediately renew all its active port mapping leases as 799 described in Section 8.9.1. 801 When the PCP server reduces its Epoch value, the PCP clients will 802 send PCP requests to refresh their mappings. The PCP server needs to 803 be scaled appropriately to accomodate this traffic. Because PCP 804 lacks a mechanism to simultaneously inform all PCP clients of the 805 Epoch value, the PCP clients will not flood the PCP server 806 simultaneously when the PCP server reduces its Epoch value. 808 6.6. Version negotiation 810 A PCP client sends its requests using PCP version number 0. Should 811 later updates to this document specify different message formats with 812 a version number greater than zero it is expected that PCP servers 813 will still support version 0 in addition to the newer version(s). 814 However, in the event that a server returns a response with error 815 code UNSUPP_VERSION, the client MAY log an error message to inform 816 the user that it is too old to work with this server, and the client 817 SHOULD set a timer to retry its request in 30 minutes (in case this 818 was a temporary condition and the server configuration is changed to 819 rectify the situation). 821 If future PCP versions greater than zero are specified, version 822 negotiation is expected to proceed as follows: 824 1. If a client or server supports more than one version it SHOULD 825 support a contiguous range of versions -- i.e., a lowest version 826 and a highest version and all versions in between. 828 2. Client sends first request using highest (i.e., presumably 829 'best') version number it supports. 831 3. If server supports that version it responds normally. 833 4. If server does not support that version it replies giving a 834 response containing the error code UNSUPP_VERSION, and the 835 closest version number it does support (if the server supports a 836 range of versions higher than the client's requested version, the 837 server returns the lowest of that supported range; if the server 838 supports a range of versions lower than the client's requested 839 version, the server returns the highest of that supported range). 841 5. If the client receives an UNSUPP_VERSION response containing a 842 version it does support, it records this fact and proceeds to use 843 this message version for subsequent communication with this PCP 844 server (until a possible future UNSUPP_VERSION response if the 845 server is later updated, at which point the version negotiation 846 process repeats). 848 6. If the client receives an UNSUPP_VERSION response containing a 849 version it does not support then the client MAY log an error 850 message to inform the user that it is too old to work with this 851 server, and the client SHOULD set a timer to retry its request in 852 30 minutes. 854 6.7. General PCP Options 856 The following options can appear in certain PCP responses. 858 6.7.1. UNPROCESSED 860 If the PCP server cannot process a mandatory-to-process option, for 861 whatever reason, it includes the UNPROCESSED Option in the response, 862 shown in Figure 5. This helps with debugging interactions between 863 the PCP client and PCP server. For simplicity, no more than 4 864 options can be encoded. This option MUST NOT appear more than once 865 in a PCP response, no matter how many PCP options appeared in the 866 request and were unprocessed by the PCP server. If only one Option 867 code was unprocessed, that option code it is placed in option-code-1 868 (and the other three fields are set to zero), if two Option codes 869 were unprocessed, their option codes are placed in option-code-1 and 870 option-code-2, and so on. If a certain Option appeared more than 871 once in the PCP request, that Option value only appears once in the 872 option-code fields. The order of the Options in the PCP request has 873 no relationship with the order of the Option values in this 874 UNPROCESSED Option. This Option MUST NOT appear in a response unless 875 the associated request contained at least one mandatory-to-process 876 Option. This Option MUST NOT appear more than once. 878 The UNPROCESSED option is formatted as follows: 880 0 1 2 3 881 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 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | option-code-1 | option-code-2 | option-code-3 | option-code-4 | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | option-code-5 | option-code-6 | option-code-7 | option-code-8 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Figure 5: UNPROCESSED option 890 This Option: 892 name: UNPROCESSED 894 number: 1 896 purpose: indicates which PCP options in the request are not 897 supported by the PCP server 899 is valid for OpCodes: all 900 length: 1 902 may appear in: responses, and only if the response code is non- 903 zero. 905 maximum occurrences: 1 907 7. Introduction to MAP and PEER OpCodes 909 There are three uses for the MAP and PEER OpCodes defined in this 910 document: a host operating a server (and wanting an incoming 911 connection), a host operating a client (and wanting to optimize the 912 application keepalive traffic), and a host operating a client and 913 server on the same port. These are discussed in the following 914 sections. 916 When operating a server (Section 7.1 and Section 7.3) the PCP client 917 knows if it wants an IPv4 listener, IPv6 listener, or both on the 918 Internet. The PCP client also knows if it has an IPv4 interface on 919 itself or an IPv6 interface on itself. It takes the union of this 920 knowledge to decide to send a one or two MAP requests for each of its 921 interfaces. Applications that embed IP addresses in payloads (e.g., 922 FTP, SIP) will find it beneficial to avoid address family 923 translation, if possible. 925 7.1. For Operating a Server 927 A host operating a server (e.g., a web server) listens for traffic on 928 a port, but the server never initiates traffic from that port. For 929 this to work across a NAT or a firewall, the application needs to (a) 930 create a mapping from a public IP address and port to itself as 931 described in Section 8 and (b) publish that public IP address and 932 port via some sort of rendezvous server (e.g., DNS, a SIP message, a 933 proprietary protocol). Publishing the public IP address and port is 934 out of scope of this specification. To accomplish (a), the 935 application follows the procedures described in this section. 937 As normal, the application needs to begin listening to a port, and to 938 ensure that it can get exclusive use of that port it needs to choose 939 a port that is not in the operating system's ephemeral port range. 940 Then, the application constructs a PCP message with the appropriate 941 MAP OpCode depending on if it is listening on an IPv4 or IPv6 942 interface and if it wants a public IPv4 or IPv6 address. 944 The following pseudo-code shows how PCP can be reliably used to 945 operate a server: 947 /* start listening on the local server port */ 948 int s = socket(...); 949 internal_sockaddr = ...; 950 bind(s, &internal_sockaddr, ...); 951 listen(s, ...); 952 requested_external_sockaddr = 0; 953 pcp_send_map_request(internal_sockaddr, 954 requested_external_sockaddr, &assigned_external_sockaddr, 955 requested_lifetime, &assigned_lifetime); 956 update_rendezvous_server("Client 12345", assigned_external_sockaddr); 957 while (1) { 958 int c = accept(s, ...); 959 /* ... */ 960 } 962 Figure 6: Pseudo-code for using PCP to operate a server 964 7.2. For Reducing NAT Keepalive Messages 966 A host operating a client (e.g., XMPP client, SIP client) sends from 967 a port but never accepts incoming connections on this port. It wants 968 to ensure the flow to its server is not terminated (due to 969 inactivity) by an on-path NAT or firewall. To accomplish this, the 970 applications uses the procedure described in this section. 972 Middleboxes such as NATs or firewalls need to see occasional traffic 973 or will terminate their session state, causing application failures. 974 To avoid this, many applications routinely generate keepalive traffic 975 for the primary (or sole) purpose of maintaining state with such 976 middleboxes. Applications can reduce such application keepalive 977 traffic by using PCP. 979 Note: For reasons beyond NAT, an application may find it useful to 980 perform application-level keepalives, such as to detect a broken 981 path between the client and server, detect a crashed server, or 982 detect a powered-down client. These keepalives are not related to 983 maintaining middlebox state, and PCP cannot do anything useful to 984 reduce those keepalives. 986 To use PCP for this function, the applications first connects to its 987 server, as normal. Afterwards, it issues a PCP request with the 988 PEER4 or PEER6 OpCode as described in Section 9. The PEER4 OpCode is 989 used if the host is using IPv4 for its communication to its peer; 990 PEER6 if using IPv6. The same 5-tuple as used for the connection to 991 the server is placed into the PEER4 or PEER6 payload. 993 The following pseudo-code shows how PCP can be reliably used with a 994 dynamic socket, for the purposes of reducing application keepalive 995 messages: 997 int s = socket(...); 998 connect(s, &remote_peer, ...); 999 getsockname(s, &internal_address, ...); 1000 external_address = 0; 1001 pcp_send_peer_request(internal_address, 1002 requested_external_address, &assigned_external_address, 1003 remote_peer, requested_lifetime, &assigned_lifetime); 1005 Figure 7: Pseudo-code using PCP with a dynamic socket 1007 7.3. For Operating a Symmetric Client/Server 1009 A host operating a client and server on the same port (e.g., 1010 Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) 1011 [RFC3581]) first establishes a local listener, (usually) sends the 1012 local and public IP addresses and ports to a rendezvous service 1013 (which is out of scope of this document), and (usually) initiates 1014 outbound connections from that same source address. To accomplish 1015 this, the application uses the procedure described in this section. 1017 An application that is using the same port for outgoing connections 1018 as well as incoming connections MUST first signal its operation of a 1019 server using the PCP MAP OpCode, as described in Section 8, and 1020 receive a positive PCP response before it sends any packets from that 1021 port. 1023 Discussion: Although reversing those steps is tempting (to 1024 eliminate the PCP round trip before a packet can be sent from that 1025 port) and will work if the NAT has endpoint-independent mappings 1026 (EIM) behavior, reversing the steps will fail if the NAT does not 1027 have EIM behavior. With a non-EIM NAT, the implicit mapping 1028 created by an outgoing TCP SYN and the explicit mapping created 1029 using the MAP OpCode will cause different ports to be assigned 1030 (which is not desirable; after all, the application is using the 1031 same port for outgoing and incoming traffic on purpose) and they 1032 will generally also have different lifetimes. PCP does not 1033 attempt to change or dictate how a NAT creates its mappings 1034 (endpoint independent mapping, or otherwise) so there is no 1035 assurance that an implicit mapping will be EIM or non-EIM. Thus, 1036 it is necessary for applications to first signal its operation of 1037 a server using the PCP MAP OpCode. 1039 The following pseudo-code shows how PCP can be used to operate a 1040 symmetric client and server: 1042 /* start listening on the local server port */ 1043 int s = socket(...); 1044 internal_sockaddr = ...; 1045 bind(s, &internal_sockaddr, ...); 1046 listen(s, ...); 1047 requested_external_sockaddr = 0; 1048 pcp_send_map_request(internal_sockaddr, 1049 requested_external_sockaddr, &assigned_external_sockaddr, 1050 requested_lifetime, &assigned_lifetime); 1051 update_rendezvous_server("Client 12345", assigned_external_sockaddr); 1052 send_packet(s, "Hello World"); 1053 while (1) { 1054 int c = accept(s, ...); 1055 /* ... */ 1056 } 1058 Figure 8: Pseudo-code for using PCP to operate a symmetric client/ 1059 server 1061 8. MAP OpCodes 1063 This section defines four OpCodes which control forwarding from a NAT 1064 (or firewall) to an internal target host. They are: 1066 MAP4=0: create a mapping between an internal target address and 1067 external IPv4 address (e.g., NAT44, NAT64, or firewall) 1069 MAP6=1: create a mapping between an internal target address and 1070 external IPv6 address (e.g., NAT46, NAT66, or firewall) 1072 The internal target address is the source IP address of the PCP 1073 request message itself, unless the THIRD_PARTY option is used. 1075 The operation of these OpCodes is described in this section. 1077 8.1. OpCode Packet Formats 1079 The two MAP OpCodes (MAP4, MAP6) share a similar packet layout for 1080 both requests and responses. Because of this similarity, they are 1081 shown together. For both of the MAP OpCodes, if the assigned 1082 external IP address and assigned external port both match the 1083 request's source IP address and MAP OpCode's internal IP address, the 1084 functionality is purely a firewall; otherwise it pertains to a 1085 network address translator which might also perform firewall 1086 functions. 1088 The following diagram shows the request packet format for MAP4 and 1089 MAP6. This packet format is aligned with the response packet format: 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Protocol | Reserved (24 bits) | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 : : 1097 : Requested external IP address (32 or 128, depending on OpCode): 1098 : : 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Requested Lifetime | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | internal port | requested external port | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 9: MAP OpCode Request Packet Format 1107 These fields are described below: 1109 Protocol: indicates protocol associated with this OpCode. Values 1110 are taken from the IANA protocol registry [proto_numbers]. For 1111 example, this field contains 6 (TCP) if the opcode is intended to 1112 create a TCP mapping. The value 0 means "all protocols" 1113 (supported by the PCP server), which is useful to create mappings 1114 for all protocols with a Basic NAT [RFC3022] or a firewall, and 1115 used to delete mappings for all protocols. 1117 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1118 when received. 1120 Requested External IP Address: Requested external IP address. This 1121 is useful for refreshing a mapping, especially after the PCP 1122 server loses state. If the PCP server can fulfill the request, it 1123 will do so. If the PCP client does not know the external address, 1124 or does not have a preference, it MUST use 0. 1126 Requested lifetime: Requested lifetime of this mapping, in seconds. 1128 Internal port: Internal port for the mapping. The value 0 MUST NOT 1129 be sent. 1131 Requested external port: requested external port for the mapping. 1132 This is useful for refreshing a mapping, especially after the PCP 1133 server loses state. If the PCP server can fulfill the request, it 1134 will do so. If the PCP client does not know the external port, or 1135 does not have a preference, it uses 0. 1137 The following diagram shows the response packet format for MAP4 and 1138 MAP6 OpCodes: 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Protocol | Reserved (24 bits) | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 : : 1146 : Assigned external IP address (32 or 128, depending on OpCode) : 1147 : : 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 : Lifetime : 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | internal port | assigned external port | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 Figure 10: MAP OpCode Response Packet Format 1156 These fields are described below: 1158 Protocol: Copied from the request 1160 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1161 when received. 1163 Assigned external IP address: On success responses, this is the 1164 assigned external IPv4 or IPv6 address for the mapping; IPv4 or 1165 IPv6 address is indicated by the OpCode. On error responses, this 1166 MUST be 0. 1168 Lifetime: On a success response, this indicates the lifetime for 1169 this mapping, in seconds. On an error response, this indicates 1170 how long clients should assume they'll get the same error response 1171 from the that PCP server if they repeat the same request. 1173 Internal port: Internal port for the mapping, copied from request. 1175 Assigned external port: On success responses, this is the assigned 1176 external port for the mapping. IPv4 or IPv6 address is indicated 1177 by the OpCode. If the NAT gateway can allocate the requested 1178 external port it SHOULD do so. This is beneficial for re- 1179 establishing state lost when a NAT gateway fails or loses its 1180 state due to reboot. If the NAT gateway cannot allocate the 1181 requested external port but can allocate some other port, it MUST 1182 do so and return the allocated port in the response. Cases where 1183 a NAT gateway cannot allocate the requested external port include 1184 when the requested external port is prohibited by policy, already 1185 used by the NAT gateway for one of its own services (e.g., port 80 1186 for the NAT gateway's own configuration pages) already allocated 1187 to another explicit mapping (by static manual allocation or by a 1188 prior PCP request by a different Internal Host) or the rare case 1189 where the requested external port was already allocated to an 1190 implicit mapping which cannot be 'promoted' to an explicit mapping 1191 for this Internal Host (a different Internal Host already made a 1192 prior outbound connection for which the NAT gateway happened to 1193 assign the external port requested in this explicit PCP request). 1194 On error responses, this MUST be 0. 1196 8.2. OpCode-Specific Result Codes 1198 In addition to the general PCP result codes (Section 5.4), the 1199 following additional result codes may be returned as a result of the 1200 four MAP OpCodes received by the PCP server. These errors are 1201 considered 'long lifetime' or 'short lifetime', which provides 1202 guidance to PCP server developers for the value of the Lifetime field 1203 for these errors. It is RECOMMENDED that short lifetime errors use 1204 30 second lifetime and long lifetime errors use 30 minute lifetime. 1206 19 SERVER_OVERLOADED, server is processing too many MAP requests from 1207 this client or from other clients, and requests this client delay 1208 sending other requests. This is a short lifetime error. 1210 20 NETWORK_FAILURE, e.g., NAT device has not obtained a DHCP lease so 1211 cannot perform a MAP operation. This is a short lifetime error. 1213 21 NO_RESOURCES, e.g., NAT device cannot create more mappings at this 1214 time. This is a system-wide error, and different from 1215 USER_EX_QUOTA. This is a short lifetime error. 1217 22 UNSUPP_PROTOCOL, unsupported Protocol. This is a long lifetime 1218 error. 1220 23 NOT_AUTHORIZED, e.g., PCP server supports mapping, but the feature 1221 is disabled for this PCP client, or the PCP client requested a 1222 mapping that cannot be fulfilled by the PCP server's security 1223 policy. This is a long lifetime error. 1225 24 USER_EX_QUOTA, mapping would exceed user's port quota. This is a 1226 short lifetime error. 1228 25 CANNOT_PROVIDE_EXTERNAL_PORT, indicates the port is already in use 1229 or otherwise unavailable (e.g., special port that cannot be 1230 allocated by the server's policy). This error is only returned if 1231 the request included the Option PREFER_FAILURE. This is a short 1232 lifetime error. 1234 26 UNABLE_TO_DELETE_ALL, indicates the PCP server was not able to 1235 delete all mappings. This is a short lifetime error. 1237 Additional result codes may be returned if the THIRD_PARTY option is 1238 used, see Section 10. 1240 8.3. OpCode-Specific Client: Generating a Request 1242 This section describes the operation of a PCP client when sending 1243 requests with OpCodes MAP4 and MAP6. 1245 The request MAY contain values in the requested-external-ip-address 1246 and requested-external-port fields. This allows the PCP client to 1247 attempt to rebuild the PCP server's state, so that the PCP client 1248 could avoid having to change information maintained at the rendezvous 1249 server. Of course, due to other activity on the network (e.g., by 1250 other users or network renumbering), the PCP server may not be able 1251 to fulfill the request. 1253 An existing mapping can have its lifetime extended by the PCP client. 1254 To do this, the PCP client sends a new MAP request indicating the 1255 internal IP address and port(s). 1257 The PCP client SHOULD renew the mapping before its expiry time, 1258 otherwise it will be removed by the PCP server (see Section 8.6). In 1259 order to prevent excessive PCP chatter, it is RECOMMENDED to send a 1260 single renewal request packet when a mapping is halfway to expiration 1261 time, then, if no positive response is received, another single 1262 renewal request 3/4 of the way to expiration time, and then another 1263 at 7/8 of the way to expiration time, and so on, subject to the 1264 constraint that renewal requests MUST NOT be sent less than four 1265 seconds apart (a PCP client MUST NOT send an infinite number of ever- 1266 closer-together requests in the last few seconds before a mapping 1267 expires). 1269 8.4. OpCode-Specific Server: Processing a Request 1271 This section describes the operation of a PCP server when processing 1272 a request with the OpCodes MAP4 or MAP6. 1274 If the server is overloaded by requests (from a particular client or 1275 from all clients), it MAY simply discard requests, as the requests 1276 will be retried by PCP clients, or MAY generate the SERVER_OVERLOADED 1277 error response, or both. 1279 If the request contains internal-port=0, the server MUST generate a 1280 MALFORMED_REQUEST error. 1282 If the requested lifetime is 0, it indicates a request to delete the 1283 mapping immediately. On a deletion request, the requested external 1284 port field is ignored by the server. PCP MAP requests only control 1285 mappings created by MAP requests. So, if the PCP client attempts to 1286 delete a static mapping (i.e., a mapping created outside of PCP 1287 itself), the PCP server deletes all of the PCP-created mappings but 1288 MUST respond with UNABLE_TO_DELETE_ALL result code, with the other 1289 fields encoded as described above. If the PCP client attempts to 1290 delete a mapping that does not exist, the success response code is 1291 returned. If the PCP client is not authorized to delete this 1292 mapping, NOT_AUTHORIZED is returned. If the deletion request was 1293 properly formatted, a positive response is generated with lifetime of 1294 0 and the server copies the protocol and internal port number from 1295 the request into the response; this positive response is generated 1296 even if there is no mapping (because the mapping could have been 1297 already deleted by a previous PCP transaction). 1299 If the requested lifetime is not zero, it indicates a request to 1300 create a mapping or extend the lifetime of an existing mapping. 1302 Processing of the lifetime is described in Section 8.6. 1304 If the PCP-controlled device is stateless (that is, it does not 1305 establish any per-flow state, and simply rewrites the address and/or 1306 port in a purely algorithmic fashion), the PCP server simply returns 1307 an answer indicating the external IP address and port yielded by this 1308 stateless algorithmic translation. This allows the PCP client to 1309 learn its external IP address and port as seen by remote peers. 1310 Examples of stateless translators include stateless NAT64 and 1:1 1311 NAT44, both of which modify addresses but not port numbers. 1313 If an Option with value greater than 128 exists but that option does 1314 not make sense (e.g., the PREFER_FAILURE option is included in a 1315 request with lifetime=0), the request is invalid and generates a 1316 MALFORMED_OPTION error. 1318 By default, a PCP-controlled device MUST NOT create mappings for a 1319 protocol not indicated in the request. For example, if the request 1320 was for a TCP mapping, a UDP mapping MUST NOT be created. 1322 If the THIRD_PARTY option is not present in the request, the source 1323 IP address of the PCP packet is used when creating the mapping. If 1324 the THIRD_PARTY option is present, the PCP server validates the 1325 indicated target IP address belongs to the same subscriber. This 1326 validation depends on the PCP deployment scenario; see Section 13.3 1327 for the validation procedure. If the internal IP address in the PCP 1328 request does not belong to the subscriber, an error response MUST be 1329 generated with result code NOT_AUTHORIZED. 1331 Mappings typically consume state on the PCP-controlled device, and it 1332 is RECOMMENDED that a per-subscriber or per-host limit be enforced by 1333 the PCP server to prevent exhausting the mapping state. If this 1334 limit is exceeded, the response code USER_EX_QUOTA is returned. 1336 If all of the proceeding operations were successful (did not generate 1337 an error response), then the requested mappings are created as 1338 described in the request and a positive response is built. This 1339 positive result contains the same OpCode as the request, but with the 1340 "R" bit set. 1342 As a side-effect of creating a mapping, ICMP messages associated with 1343 the mapping MUST be forwarded (and also translated, if appropriate) 1344 for the duration of the mapping's lifetime. This is done to ensure 1345 that ICMP messages can still be used by hosts, without application 1346 programmers or PCP client implementations needing to signal PCP 1347 separately to create ICMP mappings for those flows. 1349 8.5. OpCode-Specific Client: Processing a Response 1351 This section describes the operation of the PCP client when it 1352 receives a PCP response for the OpCodes MAP4 or MAP6. 1354 A response is matched with a request by comparing the protocol, 1355 internal IP address, and internal port. Other fields are not 1356 compared, because the PCP server sets those fields. 1358 If a successful response, the PCP client can use the external IP 1359 address and port(s) as desired. Typically the PCP client will 1360 communicate the external IP address and port(s) to another host on 1361 the Internet using an application-specific rendezvous mechanism such 1362 as DNS SRV records. 1364 If the response code is IMPLICIT_MAPPING_EXISTS, it indicates the PCP 1365 client is attempting to use MAP when an implicit dynamic connection 1366 already exists for the same internal host and internal port. This 1367 can occur with certain types of NATs. When this is received, if the 1368 PCP client still wants to establish a mapping, the PCP client MUST 1369 choose a different internal port and send a new PCP request 1370 specifying that port. 1372 On an error response, clients SHOULD NOT repeat the same request to 1373 the same PCP server within the lifetime returned in the response. 1375 8.6. Mapping Lifetime and Deletion 1377 The PCP client requests a certain lifetime, and the PCP server 1378 responds with the assigned lifetime. The PCP server MAY grant a 1379 lifetime smaller or larger than the requested lifetime. The PCP 1380 server SHOULD be configurable for permitted minimum and maximum 1381 lifetime, and the RECOMMENDED values are 120 seconds for the minimum 1382 value and 24 hours for the maximum. It is NOT RECOMMENDED that the 1383 server allow lifetimes exceeding 24 hours, because they will consume 1384 ports even if the internal host is no longer interested in receiving 1385 the traffic or no longer connected to the network. 1387 Once a PCP server has responded positively to a mapping request for a 1388 certain lifetime, the port forwarding is active for the duration of 1389 the lifetime unless the lifetime is reduced by the PCP client (to a 1390 shorter lifetime or to zero) or until the PCP server loses its state 1391 (e.g., crashes). However, if the PCP lifetime has reached zero yet 1392 there is still active inside-to-outside traffic, the PCP server MAY, 1393 if it desires, keep the mapping active until the inside-to-outside 1394 traffic has stopped. 1396 An application that forgets its PCP-assigned mappings (e.g., the 1397 application or OS crashes) will request new PCP mappings. This will 1398 consume port mappings. The application will also likely initiate new 1399 implicit dynamic mappings (e.g., TCP connections) without using PCP, 1400 which will also consume port mappings. If there is a port mapping 1401 quota for the internal host, frequent restarts such as this may 1402 exhaust the quota. PCP provides no explicit protection against such 1403 port consumption. In such environments, it is RECOMMENDED that 1404 applications use shorter PCP lifetimes to reduce the impact of 1405 consuming the user's port quota. An operating system or framework 1406 that issues a mapping request to "delete all" (protocol=0, port=0, 1407 lifetime=0) on reboot protects itself against this resource 1408 exhaustion by voluntarily relinquishing all of its old mappings 1409 before beginning to request new ones. The PCP server MAY chose to 1410 allocate the same (recently relinquished) mappings when mappings are 1411 re-requested by the booting OS. Some port mapping APIs (such as the 1412 "DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on 1413 Mac OS X, iOS, Windows, Linux, etc.) automatically monitor for 1414 process exit (including application crashes) and automatically send 1415 port mapping deletion requests if the process that requested them 1416 goes away without explicitly relinquishing them. 1418 In order to reduce unwanted traffic and data corruption, a port that 1419 was mapped using the MAP OpCode SHOULD NOT be assigned to another 1420 internal target, or another subscriber, for 120 seconds (MSL, 1421 [RFC0793]). However, the PCP server MUST allow the same internal 1422 target to re-acquire the same port during that same interval. 1424 When a PCP client first acquires a new IP address, it may want to 1425 remove mappings that may have been instantiated for a previous host. 1426 To do this, the PCP client sends a MAP request with protocol, 1427 external port, internal port, and lifetime set to 0. 1429 8.7. Subscriber Renumbering 1431 The customer premises router might obtain a new IPv4 address or new 1432 IPv6 prefix. This can occur because of a variety of reasons 1433 including a reboot, power outage, DHCP lease expiry, or other action 1434 by the ISP. If this occurs, traffic forwarded to the subscriber 1435 might be delivered to another customer who now has that address. 1436 This affects both implicit dynamic mappings and explicit dynamic 1437 mappings. However, this same problem occurs today when a 1438 subscriber's IP address is re-assigned, without PCP and without an 1439 ISP-operated CGN. The solution is the same as today: the problems 1440 associated with subscriber renumbering are caused by subscriber 1441 renumbering and are eliminated if subscriber renumbering is avoided. 1442 PCP defined in this document does not provide machinery to reduce the 1443 subscriber renumbering problem. 1445 When a new Internal Address is assigned to a host embedding a PCP 1446 client, the NAT (or firewall) controlled by the PCP server will 1447 continue to send traffic to the old IP address. Assuming the PCP 1448 client wants to continue receiving traffic, it needs to install new 1449 mappings for its new IP address. The requested external port field 1450 will not be fulfilled by the PCP server, in all likelihood, because 1451 it is still being forwarded to the old IP address. Thus, a mapping 1452 is likely to be assigned a new external port number and/or public IP 1453 address. Note that this scenario is not expected to happen routinely 1454 on a regular basis for most hosts, since most hosts renew their DHCP 1455 leases before they expire (or re-request the same address after 1456 reboot) and most DHCP servers honor such requests and grant the host 1457 the same address it was previously using before the reboot. 1459 8.8. PCP Options for MAP OpCodes 1461 8.8.1. REMOTE_PEER_FILTER 1463 This Option indicates packet filtering is desired. The remote peer 1464 port and remote peer IP Address indicate the permitted remote peer's 1465 source IP address and port for packets from the Internet. The remote 1466 peer prefix length indicates the length of the remote peer's IP 1467 address that is significant; this allows a single Option to permit an 1468 entire subnet. After processing this MAP request and generating a 1469 successful response, the PCP-controlled device will simply drop 1470 packets with a source IP address, transport, or port that do not 1471 match the fields. 1473 The REMOTE_PEER_FILTER packet layout is described below: 1475 0 1 2 3 1476 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 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Reserved | prefix-length | Remote Peer Port | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 : : 1481 : Remote Peer IP address (32 bits if MAP4, : 1482 : 1 28 bits if MAP6) : 1483 : : 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 Figure 11: REMOTE_PEER_FILTER option layout 1488 These fields are described below: 1490 Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored 1491 when received. 1493 prefix-length: indicates how many bits of the IPv4 or IPv6 address 1494 are relevant for this filter. The value 0 indicates "no filter", 1495 and will remove all previous filters. See below for detail. 1497 Remote Peer Port: the port number of the remote peer. The value 0 1498 indicates "all ports" 1500 Remote Peer IP address: The IP address of the remote peer. 1502 This Option: 1504 name: REMOTE_PEER_FILTER 1506 number: 2 1508 is valid for OpCodes: MAP4, MAP6 1510 is included in responses: MUST, if it appeared in the request 1512 length: 2 if used with MAP4, 5 if used with MAP6 1513 may appear in: requests 1515 maximum occurrences: as many as fit within maximum PCP message 1516 size 1518 Because of interactions with dynamic ports this Option MUST only be 1519 used by a client that is operating a server (that is, using the MAP 1520 OpCode), as this ensures that no other application will be assigned 1521 the same ephemeral port for its outgoing connection. Other use by a 1522 PCP client is NOT RECOMMENDED and will cause some UNSAF NAT traversal 1523 mechanisms [RFC3424] to fail where they would have otherwise 1524 succeeded, breaking other applications running on this same host. 1526 The prefix-length indicates how many bits of the IPv6 address or IPv4 1527 address are used for the filter. For MAP4, a prefix-length of 32 1528 indicates the entire IPv4 address is used. For MAP6, a prefix-length 1529 of 128 indicates the entire IPv6 address is used. For MAP4 the 1530 minimum prefix-length value is 0 and the maximum value is 32. For 1531 MAP6 the minimum prefix-length value is 0 and the maximum value is 1532 128. Values outside those range cause an MALFORMED_OPTION response 1533 code. 1535 If multiple occurrences of REMOTE_PEER_FILTER exist in the same MAP 1536 request, they are processed in the same order received, and they MUST 1537 all be successfully processed or return an error (e.g., 1538 MALFORMED_OPTION if one of the options was malformed). As with other 1539 PCP errors, returning an error causes no state to be changed in the 1540 PCP server or in the PCP-controlled device. If an existing mapping 1541 exists (with or without a filter) and the server receives a MAP 1542 request with REMOTE_PEER_FILTER, the filters indicated in the new 1543 request are added to any existing filters. If a MAP request has a 1544 lifetime of 0 and contains the REMOTE_PEER_FILTER option, the error 1545 MALFORMED_OPTION is returned. 1547 To remove all existing filters, the prefix-length 0 is used. There 1548 is no mechanism to remove a specific filter. 1550 To change an existing filter, the PCP client sends a MAP request 1551 containing two REMOTE_PEER_FILTER options, the first option 1552 containing a prefix-length of 0 (to delete all existing filters) and 1553 the second containing the new remote peer's IP address and port. 1554 Other REMOTE_PEER_FILTER options in that PCP request, if any, add 1555 more allowed remote hosts. 1557 The PCP server or the PCP-controlled device is expected to have a 1558 limit on the number of remote peers it can support. This limit might 1559 be as small as one. If a MAP request would exceed this limit, the 1560 entire MAP request is rejected with the result code 1561 EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. 1563 If this option appears in a request, the following addition result 1564 code could be returned: 1566 27 EXCESSIVE_REMOTE_PEERS, indicates the PCP server was not able to 1567 create the filters in this request. This result code MUST only be 1568 returned if the MAP request contained the REMOTE_PEER_FILTER 1569 Option. This is a long lifetime error. 1571 8.8.2. PREFER_FAILURE 1573 This option indicates that if the PCP server is unable to allocate 1574 the requested port, then instead of returning an available port that 1575 it *can* allocate, the PCP server should instead allocate no port and 1576 return result code CANNOT_PROVIDE_EXTERNAL_PORT. 1578 This option is intended solely for use by UPnP IGD interworking 1579 [I-D.bpw-pcp-upnp-igd-interworking], where the semantics of IGD 1580 version 1 do not provide any way to indicate to an IGD client that 1581 any port is available other than the one it requested. A PCP server 1582 MAY support this option, if its designers wish to support downstream 1583 devices that perform IGD interworking. PCP servers MAY choose to 1584 rate-limit their handling of PREFER_FAILURE requests, to protect 1585 themselves from a rapid flurry of 65535 consecutive PREFER_FAILURE 1586 requests from clients probing to discover which external ports are 1587 available. PCP servers that are not intended to support downstream 1588 devices that perform IGD interworking are not required to support 1589 this option. PCP clients other than IGD interworking clients SHOULD 1590 NOT use this option because it results in inefficient operation, and 1591 they cannot safely assume that all PCP servers will implement it. 1592 The option is provided only because the semantics of IGD version 1 1593 offer no viable alternative way to implement an IGD interworking 1594 function. It is anticipated that this option will be deprecated in 1595 the future as more clients adopt PCP natively and the need for IGD 1596 interworking declines. 1598 This Option: 1600 name: PREFER_FAILURE 1602 number: 3 1604 is valid for OpCodes: MAP4, MAP6 1606 is included in responses: MUST 1607 length: 0 1609 may appear in: requests 1611 maximum occurrences: no 1613 8.8.3. THIRD_PARTY 1615 The THIRD_PARTY option is used by both the MAP OpCode and the PEER 1616 OpCode, and defined in Section 10. 1618 8.9. PCP Mapping State Maintenance 1620 If an event occurs that causes the PCP server to lose state (such as 1621 a crash or power outage), the mappings created by PCP are lost. Such 1622 loss of state is rare in a service provider environment (due to 1623 redundant power, disk drives for storage, etc.). But such loss of 1624 state is more common in a residential NAT device which does not write 1625 information to its non-volatile memory. 1627 The Epoch allows a client to deduce when a PCP server may have lost 1628 its state. If this occurs, the PCP client can attempt to recreate 1629 the mappings following the procedures described in this section. 1631 8.9.1. Recreating Mappings 1633 The PCP server SHOULD store mappings in persistent storage so when it 1634 is powered off or rebooted, it remembers the port mapping state of 1635 the network. Due to the physical architecture of some PCP servers, 1636 this is not always achievable (e.g., some non-volatile memory can 1637 withstand only a certain number of writes, so writing PCP mappings to 1638 such memory is generally avoided). 1640 However, maintaining this state is not essential for correct 1641 operation. When the PCP server loses state and begins processing new 1642 PCP messages, its Epoch is reset to zero (per the procedure of 1643 Section 6.5). 1645 A mapping renewal packet is formatted identically to an original 1646 mapping request; from the point of view of the client it is a renewal 1647 of an existing mapping, but from the point of view of the PCP server 1648 it appears as a new mapping request. 1650 As the result of receiving a packet where the Epoch field indicates 1651 that a reboot or similar loss of state has occurred, the client 1652 renews its port mappings. 1654 The discussion in this section focuses on recreating inbound port 1655 mappings after loss of PCP server state, because that is the more 1656 serious problem. Losing port mappings for outgoing connections 1657 destroys those currently active connections, but does not prevent 1658 clients from establishing new outgoing connections. In contrast, 1659 losing inbound port mappings not only destroys all existing inbound 1660 connections, but also prevents the reception of any new inbound 1661 connections until the port mapping is recreated. Accordingly, we 1662 consider recovery of inbound port mappings the more important 1663 priority. However, clients that want outgoing connections to survive 1664 a NAT gateway reboot can also achieve that using PCP. After 1665 initiating an outbound TCP connection (which will cause the NAT 1666 gateway to establish an implicit port mapping) the client should send 1667 the NAT gateway a port mapping request for the source port of its TCP 1668 connection, which will cause the NAT gateway to send a response 1669 giving the external port it allocated for that mapping. The client 1670 can then store this information, and use it later to recreate the 1671 mapping if it determines that the NAT gateway has lost its mapping 1672 state. 1674 8.9.2. Maintaining Mappings 1676 A PCP client can refresh a mapping by sending a new PCP request 1677 containing information from the earlier PCP response. The PCP server 1678 will respond indicating the new lifetime. It is possible, due to 1679 failure of the PCP server, that the public IP address and/or public 1680 port, or the PCP server itself, has changed (due to a new route to a 1681 different PCP server). To detect such events more quickly, the PCP 1682 client may find it beneficial to use shorter lifetimes (so that it 1683 communicates with the PCP server more often). If the PCP client has 1684 several mappings, the Epoch value only needs to be retrieved for one 1685 of them to verify the PCP server has not lost port forwarding state. 1687 If the client wishes to check the PCP server's Epoch, it sends a PCP 1688 request for any one of the client's mappings. This will return the 1689 current Epoch value. In that request the PCP client could extend the 1690 mapping lifetime (by asking for more time) or maintain the current 1691 lifetime (by asking for the same number of seconds that it knows are 1692 remaining of the lifetime). 1694 9. PEER OpCodes 1696 This section defines two OpCodes for controlling dynamic connections. 1697 They are: 1699 PEER4=2: Set or query lifetime for flow from IPv4 address to a 1700 remote peer's IPv4 address. 1702 PEER6=3: Set or query lifetime for flow from IPv6 address to a 1703 remote peer's IPv6 address. 1705 The operation of these OpCodes is described in this section. 1707 9.1. OpCode Packet Formats 1709 The PEER OpCodes provide a single function: the ability for the PCP 1710 client to query and (possibly) extend the lifetime of an existing 1711 mapping. 1713 The two PEER OpCodes (PEER4 and PEER6) share a similar packet layout 1714 for both requests and responses. Because of this similarity, they 1715 are shown together. 1717 The following diagram shows the request packet format for PEER4 and 1718 PEER6. This packet format is aligned with the response packet 1719 format: 1721 0 1 2 3 1722 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 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Protocol | Reserved (24 bits) | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 : : 1727 : Remote Peer IP address (32 bits if PEER4, 128 bits if PEER6) : 1728 : : 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 : : 1731 : Reserved (128 bits) : 1732 : : 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Requested lifetime | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | internal port | reserved (16 bits) | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | remote peer port | reserved (16 bits) | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 Figure 12: PEER OpCode Request Packet Format 1743 These fields are described below: 1745 Protocol: indicates protocol associated with this OpCode. Values 1746 are taken from the IANA protocol registry [proto_numbers]. For 1747 example, this field contains 6 (TCP) if the OpCode is describing a 1748 TCP peer. 1750 Reserved: 24 reserved bits, MUST be 0 on transmission and MUST be 1751 ignored on reception. 1753 Remote Peer IP Address: Remote peer's IP address, from the 1754 perspective of the PCP client. 1756 Reserved: 128 reserved bits, MUST be 0 on transmission and MUST be 1757 ignored on reception. 1759 Requested lifetime: Requested lifetime of this mapping, in seconds. 1760 Unlike the MAP OpCode, there is no special meaning of 0. 1762 internal port: Internal port for the of the 5-tuple. 1764 Reserved: 16 reserved bits, MUST be 0 on transmission and MUST be 1765 ignored on reception. 1767 Remote Peer Port: Remote peer's port of the 5-tuple. 1769 Reserved: 16 reserved bits, MUST be 0 on transmission and MUST be 1770 ignored on reception. 1772 The following diagram shows the response packet format for PEER4 and 1773 PEER6: 1775 0 1 2 3 1776 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 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Protocol | External_AF | Reserved (16 bits) | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 : : 1781 : Remote Peer IP address (32 bits if PEER4, 128 bits if PEER6) : 1782 : : 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 : : 1785 : External IP address (always 128 bits) : 1786 : : 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Assigned Lifetime | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | internal port | external port | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | remote peer port | reserved (16 bits) | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 Figure 13: PEER OpCode Response Packet Format 1797 Protocol: Copied from the request. 1799 External_AF For success responses, this contains the address family 1800 of the external IP address associated with this peer connection. 1801 Values are from IANA's address family numbers (IPv4 is 1, IPv6 is 1802 2). For error responses, the value MUST be 0. 1804 Reserved: 16 reserved bits, MUST be 0 on transmission, MUST be 1805 ignored on reception. 1807 remote Peer IP address Copied from the request. 1809 External IP Address For success responses, this contains the 1810 external IP address, assigned by the NAT (or firewall) to this 1811 mapping. If firewall, this will match the internal IP address. 1812 This field is always 128 bits long. If External_AF indicates 1813 IPv4, the IPv4 address is encoded in the first 32 bits of the 1814 External IP Address field and the remaining 96 bits are zero. For 1815 error responses, this MUST be 0. 1817 Assigned Lifetime: For success responses, this is the assigned 1818 lifetime, in seconds. For error responses, this is 0.s 1820 internal port: copied from request. 1822 external port: For success responses, this is the external port 1823 number, assigned by the NAT (or firewall) to this mapping. If 1824 firewall or 1:1 NAT, this will match the internal port. For error 1825 responses, this MUST be 0. 1827 remote peer port: Copied from request. 1829 Reserved: 16 reserved bits, MUST be 0 on transmission, MUST be 1830 ignored on reception. 1832 9.2. OpCode-Specific Result Codes 1834 In addition to the general PCP result codes (Section 5.4) the 1835 following additional result codes may be returned as a result of the 1836 two PEER OpCodes received by the PCP server. 1838 50 NONEXIST_PEER, the connection to that peer does not exist in the 1839 mapping table. 1841 Additional result codes may be returned if the THIRD_PARTY option is 1842 used, see Section 10. 1844 9.3. OpCode-Specific Client: Generating a Request 1846 This section describes the operation of a client when generating the 1847 OpCodes PEER4 or PEER6. 1849 The PEER4 or PEER6 OpCodes MUST NOT be sent until establishing bi- 1850 directional communication with the remote peer. For TCP, this means 1851 completing the TCP 3-way handshake. This is because the PCP- 1852 controlled device may not be able to extend the lifetime of a mapping 1853 until after bi-directional communications has been established. 1855 The PEER4 and PEER6 OpCodes contain a description of the socket, from 1856 the perspective of the PCP client. This is important when the PCP- 1857 controlled device is performing address family translation (NAT46 or 1858 NAT64), because the destination address from the perspective of the 1859 PCP client is different from the destination address on the other 1860 side of the address family translation device. 1862 9.4. OpCode-Specific Server: Processing a Request 1864 This section describes the operation of a server when receiving a 1865 request with the OpCodes PEER4 or PEER6. 1867 On receiving the PEER4 or PEER6 OpCode, the PCP server examines the 1868 mapping table. If a mapping does not exist, the NONEXIST_PEER error 1869 is returned. 1871 If the PCP-controlled device can extend the lifetime of a mapping, 1872 the PCP server uses the smaller of its configured maximum lifetime 1873 value and the requested lifetime from the PEER request, and sets the 1874 lifetime to that value. 1876 The PEER4 or PEER6 OpCodes MUST NOT reduce the lifetime of an 1877 existing mapping. If the mapping is terminated by the TCP client or 1878 server (e.g., TCP FIN or TCP RST), the mapping will eventually be 1879 destroyed normally; the earlier use of PEER does not extend the 1880 lifetime in that case. 1882 If all of the proceeding operations were successful (did not generate 1883 an error response), then a SUCCESS response is generated, with the 1884 assigned-lifetime containing the lifetime of the mapping. 1886 Note: it is implementation-specific if the PCP-controlled device 1887 destroys the mapping when the lifetime expires, or if 1888 inside->outside traffic keeps the mapping alive. 1890 9.5. OpCode-Specific Client: Processing a Response 1892 This section describes the operation of a client when processing a 1893 response with the OpCodes PEER4 or PEER6. 1895 A response is matched with a request by comparing the protocol, 1896 external AF, internal IP address, internal port, remote peer address 1897 and remote peer port. Other fields are not compared, because the PCP 1898 server changes those fields to provide information about the mapping 1899 created by the OpCode. 1901 If the error response NONEXIST_PEER, this could have occurred if the 1902 PCP client sent its PEER request before the PCP-controlled device had 1903 installed the mapping, or because the mapping has been destroyed 1904 (e.g., due to a TCP FIN). If the PCP client believes the mapping 1905 should exist, the PCP client SHOULD retry the request after a brief 1906 delay (e.g., 5 seconds). 1908 Other error responses SHOULD NOT be retried. 1910 If a successful response, the PCP client uses the assigned lifetime 1911 value to reduce its frequency of application keepalives for that 1912 particular NAT mapping. Of course, there may be other reasons, 1913 specific to the application, to use more frequent application 1914 keepalives. For example, the PCP assigned-lifetime could be one hour 1915 but the application may want to ensure the server is still accessible 1916 (e.g., has not crashed) more frequently than once an hour. 1918 If the PCP client wishes to keep this mapping alive beyond the 1919 indicated lifetime, it SHOULD issue a new PCP request prior to the 1920 expiration. That is, inside->outside traffic is not sufficient to 1921 ensure the mapping will continue to exist. It is RECOMMENDED to send 1922 a single renewal request packet when a mapping is halfway to 1923 expiration time, then, if no positive response is received, another 1924 single renewal request 3/4 of the way to expiration time, and then 1925 another at 7/8 of the way to expiration time, and so on, subject to 1926 the constraint that renewal requests MUST NOT be sent less than four 1927 seconds apart (a PCP client MUST NOT send an infinite number of ever- 1928 closer-together requests in the last few seconds before a mapping 1929 expires). 1931 9.6. PCP Options for PEER OpCodes 1933 9.6.1. THIRD_PARTY 1935 The THIRD_PARTY option is used by both the MAP OpCode and the PEER 1936 OpCode, and defined in Section 10. 1938 10. THIRD_PARTY Option for MAP and PEER OpCodes 1940 This Option is used when a PCP client wants to control a mapping to 1941 an internal target host other than itself. This is used with both 1942 MAP and PEER OpCodes. 1944 A PCP server will only process this option if sent by an authorized 1945 PCP client, otherwise will return an error. Determining which PCP 1946 clients are authorized to use the THIRD_PARTY option depends on the 1947 deployment scenario. For Dual-Stack Lite deployments, the PCP server 1948 only supports this option if the source IPv4 address is the B4's 1949 source IP address. For other scenarios, the subscriber has only one 1950 IPv4 address and this Option serves no purpose (and will only 1951 generate error messages from the server). If a subscriber has more 1952 than one IPv4 address, the ISP MUST determine its own policy for how 1953 to identify the trusted device within the subscriber's home. This 1954 might be, for example, the lowest- or highest-numbered host address 1955 for that user's IPv4 prefix. 1957 0 1 2 3 1958 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 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 : : 1961 : Target Internal IP address (32 bits of 128 bits, depending : 1962 : on Option length) : 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 The fields are described below: 1967 Mapping Internal IP Address: Internal IP address of the mapping. If 1968 the length of this Option is 1, this is a 32-bit IPv4 address. If 1969 the length of this Option is 4, this is a 128-bit IPv6 address. 1970 This can contain the special value "0" (all zeros), which 1971 indicates "all addresses associated with this subscriber" which is 1972 used to delete all pre-existing mappings with the MAP Opcode. 1974 This Option: 1976 name: THIRD_PARTY 1978 number: 4 1980 purpose: Indicate the MAP or PEER request is for a host other than 1981 the host sending the PCP option. 1983 is valid for OpCodes: MAP4, MAP6, PEER4, PEER6 1985 length: 1 if OpCode is MAP4 or PEER4, 4 if OpCode is MAP6 or PEER6 1987 may appear in: request. May appear in response only if it 1988 appeared in the associated request. 1990 maximum occurrences: 1 1992 The following additional result codes may be returned as a result of 1993 using this Option. 1995 51 UNAUTH_TARGET_ADDRESS, indicting the target IP address specified 1996 is not permitted (e.g., the address does not belong to this 1997 subscriber, or is otherwise prohibited.). If this is a MAP 1998 request, this is a long-term error. 2000 52 UNAUTH_SOURCE_ADDRESS, indicates the source address of this PCP 2001 message is not authorized by the PCP server to use the THIRD_PARTY 2002 option. 2004 A PCP server is configured to permit or to restrict the use of the 2005 THIRD_PARTY option. If this option is permitted, any host on a 2006 subscriber's network network can create, modify, or destroy mappings 2007 for another host on the network, which is generally undesirable. If 2008 third party mappings are restricted, only a certain host on the 2009 subscriber's network can perform these operations. If a PCP server 2010 is configured to restrict third party mappings, and receives a PCP 2011 MCP request with a Target Address that does not match the source IP 2012 address of that request, it MUST generate a UNAUTH_TARGET_ADDRESS 2013 response. 2015 It is RECOMMENDED that PCP servers embedded into customer premise 2016 equipment be configured to restrict third party mappings. With this 2017 configuration, if a user wants to create a third party mapping, the 2018 user needs to interact out-of-band with their customer premise router 2019 (e.g., using its HTTP administrative interface). 2021 It is RECOMMENDED that PCP servers embedded into service provider NAT 2022 and firewall devices be configured to permit the THIRD_PARTY option. 2023 With this configuration, if a user wants to create an explicit 2024 dynamic mapping or query an implicit dynamic mapping for another host 2025 within their network, the user needs to interact out-of-band with 2026 their customer premise router (e.g., using its HTTP administrative 2027 interface). This is because the service provider's PCP server only 2028 allows a PEER or MAP request containing the THIRD_PARTY option if it 2029 has the IP address of the subscriber's customer premise router. To 2030 do this, the PCP server needs certain knowledge about the network's 2031 subscribers. It needs to determine the IP address of the 2032 subscriber's customer premise router and to determine the IP subnet 2033 assigned to the subscriber. This knowledge might be dynamic (e.g., 2034 database query into the service provider's user database for every 2035 incoming PCP request), might be a table (e.g., subscribers with a 2036 certain IPv4 network prefix all have an IPv4 /24, other IPv4 prefixes 2037 have an IPv4 /32, certain IPv6 prefixes have an have an IPv6 /32, and 2038 so on), or might be very static (e.g., all subscribers have one IPv4 2039 address). In many common deployments, there is only one IPv4 address 2040 assigned to a subscriber, and thus the Target Address will always 2041 match the source address of the PCP message. If there are multiple 2042 IPv4 or multiple IPv6 addresses assigned to a subscriber, the PCP 2043 server allows the highest-numbered address to use the THIRD_PARTY 2044 option. Thus, on a network supporting PCP with multiple addresses 2045 assigned to a subscriber, the highest-numbered host SHOULD be the 2046 subscriber's customer premise router. Upon receiving a MAP or PEER 2047 request where the Target Address does not match the source IP address 2048 of the request, the PCP server determines if the source IP address of 2049 the request is the subscriber's highest numbered address, following 2050 the procedure above. If not, the PCP server MUST generate an 2051 UNAUTH_SOURCE_ADDRESS error. Then the PCP server determines if the 2052 Target Address belongs to the same subscriber as the source IP 2053 address of the PCP packet, using the procedure described above. If 2054 not, the PCP server MUST generate an UNAUTH_TARGET_ADDRESS error. 2056 If authorized to do so, a PCP client can delete all the PCP-created 2057 dynamic explicit mappings (i.e., those created by PCP) for all hosts 2058 belonging to the same subscriber. This is done by sending a PCP MAP 2059 request including the THIRD_PARTY option with its Target Address 2060 field set to 0. 2062 11. Deployment Considerations 2064 11.1. Maintaining Same External IP Address 2066 It is REQUIRED that the PCP-controlled device assign the same 2067 external IP address PCP-created explicit dynamic mappings and to 2068 implicit dynamic mappings. It is RECOMMENDED that static mappings 2069 (e.g., those created by a command language interface on the PCP 2070 server or PCP-controlled device) also be assigned to the same IP 2071 address. 2073 Once all internal hosts belonging to a given subscriber have no 2074 implicit dynamic mappings and have no explicit dynamic mappings in 2075 the PCP-controlled device, a subsequent PCP request for that internal 2076 host MAY be assigned to a different external IP address. Generally, 2077 this re-assignment would occur when a CGN device is load balancing 2078 newly-seen hosts to its public IPv4 address pool. 2080 11.2. Ingress Filtering 2082 To prevent spoofing of PCP requests, ingress filtering [RFC2827] MUST 2083 be performed by devices between the PCP clients and PCP server. For 2084 example, with a PCP server integrated into a customer premise router, 2085 the Ethernet switch needs to perform ingress filtering. As another 2086 example, with a PCP server deployed by a service provider, the 2087 service provider's aggregation router (the first device connecting to 2088 subscribers) needs to do ingress filtering. 2090 11.3. Per-Subscriber Port Forwarding Quota 2092 On PCP-controlled devices that create state when a mapping is created 2093 (e.g., NAPT), the PCP server SHOULD maintain a per-subscriber mapping 2094 quota for PCP-created mappings. It is implementation-specific if the 2095 PCP server has a separate or combined quota for both implicit dynamic 2096 mappings (e.g., TCP SYNs) and explicit dynamic mappings (PCP). 2098 12. Deployment Scenarios 2100 12.1. Dual Stack-Lite 2102 The interesting components in a Dual-Stack Lite deployment are the B4 2103 element (which is the customer premises router) and the AFTR (Address 2104 Family Transition Router) element. The AFTR element terminates the 2105 IPv6-over-IPv4 tunnel and also implements the Carrier-Grade NAT44 2106 function. The B4 element does not need to perform a NAT function 2107 (and usually does not perform a NAT function), but it does operate 2108 its own DHCP server and is the local network's default router. 2110 12.1.1. Overview 2112 Various PCP deployment scenarios can be considered to control the PCP 2113 server embedded in the AFTR element: 2115 1. UPnP IGD and NAT-PMP [I-D.cheshire-nat-pmp] are used in the LAN: 2116 an interworking function is required to be embedded in the B4 2117 element to ensure interworking between the protocol used in the 2118 LAN and PCP. UPnP IGD-PCP Interworking Function is described in 2119 [I-D.bpw-pcp-upnp-igd-interworking]. 2121 2. Hosts behind the B4 element will either include a PCP client or 2122 UPnP IGD client, or both. 2124 A. if a UPnP IGD client, the B4 element will need to include an 2125 interworking function from UPnP IGD to PCP. 2127 B. if a PCP client, the PCP client will communicate directly 2128 with the PCP server. 2130 3. The B4 element includes a PCP client which is invoked by an HTTP- 2131 based configuration (as is common today). The internal IP 2132 address field in the PCP payload would be the internal host used 2133 in the port forwarding configuration. 2135 In Dual Stack-Lite, the B4 element encapsulates its PCP messages into 2136 the IPv6 tunnel towards the AFTR element. It is expected the B4 2137 element will also perform as a proxy from PCP to PCP 2138 [I-D.bpw-pcp-proxy], and may also proxy from other protocols to PCP 2139 (e.g., [I-D.bpw-pcp-upnp-igd-interworking]. When proxying for other 2140 hosts, the B4 element will necessarily use the THIRD_PARTY option 2141 with the MAP and PEER OpCodes. 2143 12.2. NAT64 2145 Hosts behind a NAT64 device can make use of PCP in order to perform 2146 port reservation (to get a publicly routable IPv4 port). 2148 12.3. NAT44 and NAT444 2150 Residential subscribers in NAT44 (and NAT444) deployments are usually 2151 given one IPv4 address, but may also be given several IPv4 addresses. 2152 These addresses are not routable on the IPv4 Internet, but are 2153 routable between the subscriber's home and the ISP's CGN. To 2154 accommodate multiple hosts within a home, especially when provided 2155 insufficient IPv4 addresses for the number of devices in the home, 2156 subscribers operate a NAPT device. When this occurs in conjunction 2157 with an upstream NAT44, this is nicknamed "NAT444". 2159 12.4. IPv6 Simple Firewall 2161 Many IPv6 deployments will include a simple firewall [RFC6092], which 2162 permits outgoing packets to initiate bi-directional communication but 2163 blocks unsolicited incoming packets, which is similar to PCP's 2164 security model that allows a host to create a mapping to itself. In 2165 many situations, especially residential networks that lack an IT 2166 staff, the security provided by an IPv6 simple firewall and the 2167 security provided by PCP are compatible. In such situations, the 2168 IPv6 simple firewall and the IPv6 host can use the MAP6 OpCode to 2169 allow unsolicited incoming packets, so the host can operate a server. 2171 13. Security Considerations 2173 The PCP client's source port SHOULD be randomly generated [RFC6056]. 2174 The PCP server MUST only listen for requests from its internal 2175 interfaces, and MUST NOT listen for requests on its Internet-facing 2176 interfaces. 2178 This document defines Port Control Protocol and two types of OpCodes, 2179 PEER and MAP. The PEER OpCode allows querying and extending (if 2180 permitted) the lifetime of an existing implicit dynamic mapping, so a 2181 host can reduce its keepalive messages. The MAP OpCode allows 2182 creating a mapping so a host can receive incoming unsolicited 2183 connections from the Internet in order to run a server. 2185 The PEER OpCode does not introduce any new security considerations. 2187 On today's Internet, ISPs do not typically filter incoming traffic 2188 for their subscribers. However, when an ISP introduces stateful 2189 address sharing with a NAPT device, such filtering will occur as a 2190 side effect. Filtering will also occur with IPv6 CPE 2191 [I-D.ietf-v6ops-cpe-simple-security]. The MAP OpCode allows a PCP 2192 client to create a mapping so that a host can receive inbound traffic 2193 and operate a server. Security considerations for the MAP OpCode are 2194 described in the following sections. 2196 13.1. Denial of Service 2198 Because the state created in a NAPT or firewall, a per-subscriber 2199 quota will likely exist for both implicit dynamic mappings (e.g., 2200 outgoing TCP connections) and explicit dynamic mappings (PCP). A 2201 subscriber might make an excessive number of implicit or explicit 2202 dynamic mappings, consuming an inordinate number of ports, causing a 2203 denial of service to other subscribers. Thus, Section 11.3recommends 2204 that subscribers be limited to a reasonable number of explicit 2205 dynamic mappings. 2207 13.2. Ingress Filtering 2209 It is important to prevent a subscriber from creating a mapping for 2210 another subscriber, because this allows incoming packets from the 2211 Internet and consumes the other user's mapping quota. Both implicit 2212 dynamic mappings (e.g., outgoing TCP connections) and explicit 2213 dynamic mappings (PCP) need ingress filtering. Thus, PCP does not 2214 create a new requirement for ingress filtering. 2216 13.3. Validating Target Address 2218 The THIRD_PARTY Option contains a Target Address field, which allows 2219 a PCP client to create an explicit dynamic mapping for another host. 2220 Hosts within a subscriber's network cannot create, modify, or delete 2221 mappings of other hosts, except by using the administrative interface 2222 of the customer premise router (e.g., HTTP interface), as described 2223 in Section 10. 2225 14. IANA Considerations 2227 IANA is requested to perform the following actions: 2229 14.1. Port Number 2231 IANA has assigned UDP port 44323 for PCP. 2233 14.2. OpCodes 2235 IANA shall create a new protocol registry for PCP OpCodes, initially 2236 populated with the values in Section 8 and Section 9. 2238 New OpCodes in the range 1-95 can be created via Standards Action 2239 [RFC5226], and the range 96-128 is for Private Use [RFC5226]. 2241 14.3. Result Codes 2243 IANA shall create a new registry for PCP result codes, numbered 2244 0-255, initially populated with the result codes from Section 5.4, 2245 Section 8.2, Section 8.8.1, Section 9.2, and Section 10. 2247 Additional Result Codes can be defined via Specification Required 2248 [RFC5226]. 2250 14.4. Options 2252 IANA shall create a new registry for PCP Options, numbered 0-255 with 2253 an associated mnemonic. The values 0-128 are mandatory-to-process, 2254 and 128-255 are optional-to-process. The initial registry contains 2255 the options described in Section 8.8 and Section 10, and the option 2256 values 0 and 255 are reserved. 2258 New PCP option codes in the range 0-63 and 128-192 can be created via 2259 Standards Action [RFC5226], and the range 64-127 and 192-255 is for 2260 Private Use [RFC5226]. 2262 15. Acknowledgments 2264 Thanks to Alain Durand, Christian Jacquenet, Jacni Qin, and Simon 2265 Perreault for their comments and review. Thanks to Simon Perreault 2266 for highlighting the interaction of dynamic connections with PCP- 2267 created mappings. 2269 16. References 2271 16.1. Normative References 2273 [I-D.ietf-behave-v6v4-xlate] 2274 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 2275 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 2276 progress), September 2010. 2278 [I-D.ietf-behave-v6v4-xlate-stateful] 2279 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 2280 NAT64: Network Address and Protocol Translation from IPv6 2281 Clients to IPv4 Servers", 2282 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 2283 progress), July 2010. 2285 [I-D.ietf-softwire-dual-stack-lite] 2286 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2287 Stack Lite Broadband Deployments Following IPv4 2288 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 2289 in progress), August 2010. 2291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2292 Requirement Levels", BCP 14, RFC 2119, March 1997. 2294 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2295 Defeating Denial of Service Attacks which employ IP Source 2296 Address Spoofing", BCP 38, RFC 2827, May 2000. 2298 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2299 Addresses", RFC 4193, October 2005. 2301 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2302 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2303 May 2008. 2305 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2306 Protocol Port Randomization", BCP 156, RFC 6056, 2307 January 2011. 2309 [proto_numbers] 2310 IANA, "Protocol Numbers", 2010, . 2313 16.2. Informative References 2315 [I-D.arkko-dual-stack-extra-lite] 2316 Arkko, J., Eggert, L., and M. Townsley, "Scalable 2317 Operation of Address Translators with Per-Interface 2318 Bindings", draft-arkko-dual-stack-extra-lite-05 (work in 2319 progress), February 2011. 2321 [I-D.bpw-pcp-proxy] 2322 Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port 2323 Control Protocol (PCP) Proxy Function", 2324 draft-bpw-pcp-proxy-00 (work in progress), February 2011. 2326 [I-D.bpw-pcp-upnp-igd-interworking] 2327 Boucadair, M., Penno, R., Wing, D., and F. Dupont, 2328 "Universal Plug and Play (UPnP) Internet Gateway Device 2329 (IGD)-Port Control Protocol (PCP) Interworking Function", 2330 draft-bpw-pcp-upnp-igd-interworking-02 (work in progress), 2331 February 2011. 2333 [I-D.cheshire-nat-pmp] 2334 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 2335 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 2337 [I-D.ietf-behave-lsn-requirements] 2338 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 2339 "Common requirements for IP address sharing schemes", 2340 draft-ietf-behave-lsn-requirements-00 (work in progress), 2341 October 2010. 2343 [I-D.ietf-v6ops-cpe-simple-security] 2344 Woodyatt, J., "Recommended Simple Security Capabilities in 2345 Customer Premises Equipment for Providing Residential IPv6 2346 Internet Service", draft-ietf-v6ops-cpe-simple-security-16 2347 (work in progress), October 2010. 2349 [I-D.miles-behave-l2nat] 2350 Miles, D. and M. Townsley, "Layer2-Aware NAT", 2351 draft-miles-behave-l2nat-00 (work in progress), 2352 March 2009. 2354 [IGD] UPnP Gateway Committee, "WANIPConnection:1", 2355 November 2001, . 2358 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2359 RFC 793, September 1981. 2361 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2362 E. Lear, "Address Allocation for Private Internets", 2363 BCP 5, RFC 1918, February 1996. 2365 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2366 "Definition of the Differentiated Services Field (DS 2367 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2368 December 1998. 2370 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2371 Address Translator (Traditional NAT)", RFC 3022, 2372 January 2001. 2374 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2375 Self-Address Fixing (UNSAF) Across Network Address 2376 Translation", RFC 3424, November 2002. 2378 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 2379 Session Initiation Protocol (SIP) for Symmetric Response 2380 Routing", RFC 3581, August 2003. 2382 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2383 Extensions for Stateless Address Autoconfiguration in 2384 IPv6", RFC 4941, September 2007. 2386 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2387 BCP 131, RFC 4961, July 2007. 2389 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2390 February 2009. 2392 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 2393 Customer Premises Equipment (CPE) for Providing 2394 Residential IPv6 Internet Service", RFC 6092, 2395 January 2011. 2397 Appendix A. Changes 2399 A.1. Changes from draft-ietf-pcp-base-05 to -06 2401 o DS-Lite: consensus was encapsulation mode. Included a suggestion 2402 that the B4 will need to proxy PCP-to-PCP and UPnP-to-PCP. 2404 o defined THIRD_PARTY option to work with the PEER OpCode, too. 2405 This meant moving it to its own section, and having both MAP and 2406 PEER OpCodes reference that common section. 2408 o used "target" instead of "internal", in the hopes that clarifies 2409 internal address used by PCP itself (for sending its packets) 2410 versus the address for MAPpings. 2412 o Options are now required to be ordered in requests, and ordering 2413 has to be validated by the server. Intent is to ease server 2414 processing of mandatory-to-implement options. 2416 o Swapped Option values for the mandatory- and optional-to-process 2417 Options, so we can have a simple lowest..highest ordering. 2419 o added MISORDERED_OPTIONS error. 2421 o re-ordered some error messages to cause MALFORMED_REQUEST (which 2422 is PCP's most general error response) to be error 1, instead of 2423 buried in the middle of the error numbers. 2425 o clarified that, after successfully using a PCP server, that PCP 2426 server is declared to be non-responsive after 5 failed 2427 retransmissions. 2429 o tightened up text (which was inaccurate) about how long general 2430 PCP processing is to delay when receiving an error and if it 2431 should honor OpCode-specific error lifetime. Useful for MAP 2432 errors which have an error lifetime. (This all feels awkward to 2433 have only some errors with a lifetime.) 2435 o Added better discussion of multiple interfaces, including 2436 highlighting WiFi+Ethernet. Added discussion of using IPv6 2437 Privacy Addresses and RFC1918 as source addresses for PCP 2438 requests. This should finish the section on multi-interface 2439 issues. 2441 o added some text about why server might send SERVER_OVERLOADED, or 2442 might simply discard packets. 2444 o Dis-allow internal-port=0, which means we dis-allow using PCP as a 2445 DMZ-like function. Instead, ports have to be mapped individually. 2447 o Text describing server's processing of PEER is tightened up. 2449 o Server's processing of PEER now says it is implementation-specific 2450 if a PCP server continues to allow the mapping to exist after a 2451 PEER message. Client's processing of PEER says that if client 2452 wants mapping to continue to exist, client has to continue to send 2453 recurring PEER messages. 2455 A.2. Changes from draft-ietf-pcp-base-04 to -05 2457 o tweaked PCP common header packet layout. 2459 o Re-added port=0 (all ports). 2461 o minimum size is 12 octets (missed that change in -04). 2463 o removed Lifetime from PCP common header. 2465 o for MAP error responses, the lifetime indicates how long the 2466 server wants the client to avoid retrying the request. 2468 o More clearly indicated which fields are filled by the server on 2469 success responses and error responses. 2471 o Removed UPnP interworking section from this document. It will 2472 appear in [I-D.bpw-pcp-upnp-igd-interworking]. 2474 A.3. Changes from draft-ietf-pcp-base-03 to -04 2476 o "Pinhole" and "PIN" changed to "mapping" and "MAP". 2478 o Reduced from four MAP OpCodes to two. This was done by implicitly 2479 using the address family of the PCP message itself. 2481 o New option THIRD_PARTY, to more carefully split out the case where 2482 a mapping is created to a different host within the home. 2484 o Integrated a lot of editorial changes from Stuart and Francis. 2486 o Removed nested NAT text into another document, including the IANA- 2487 registered IP addresses for the PCP server. 2489 o Removed suggestion (MAY) that PCP server reserve UDP when it maps 2490 TCP. Nobody seems to need that. 2492 o Clearly added NAT and NAPT, such as in residential NATs, as within 2493 scope for PCP. 2495 o HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE 2497 o Added 'Lifetime' field to the common PCP header, which replaces 2498 the functions of the 'temporary' and 'permanent' error types of 2499 the previous version. 2501 o Allow arbitrary Options to be included in PCP response, so that 2502 PCP server can indicate un-supported PCP Options. Satisfies PCP 2503 Issue #19 2505 o Reduced scope to only deal with mapping protocols that have port 2506 numbers. 2508 o Reduced scope to not support DMZ-style forwarding. 2510 o Clarified version negotiation. 2512 A.4. Changes from draft-ietf-pcp-base-02 to -03 2514 o Adjusted abstract and introduction to make it clear PCP is 2515 intended to forward ports and intended to reduce application 2516 keepalives. 2518 o First bit in PCP common header is set. This allows DTLS and non- 2519 DTLS to be multiplexed on same port, should a future update to 2520 this specification add DTLS support. 2522 o Moved subscriber identity from common PCP section to MAP* section. 2524 o made clearer that PCP client can reduce mapping lifetime if it 2525 wishes. 2527 o Added discussion of host running a server, client, or symmetric 2528 client+server. 2530 o Introduced PEER4 and PEER6 OpCodes. 2532 o Removed REMOTE_PEER Option, as its function has been replaced by 2533 the new PEER OpCodes. 2535 o IANA assigned port 44323 to PCP. 2537 o Removed AMBIGUOUS error code, which is no longer needed. 2539 A.5. Changes from draft-ietf-pcp-base-01 to -02 2541 o more error codes 2543 o PCP client source port number should be random 2545 o PCP message minimum 8 octets, maximum 1024 octets. 2547 o tweaked a lot of text in section 7.4, "Opcode-Specific Server 2548 Operation". 2550 o opening a mapping also allows ICMP messages associated with that 2551 mapping. 2553 o PREFER_FAILURE value changed to the mandatory-to-process range. 2555 o added text recommending applications that are crashing obtain 2556 short lifetimes, to avoid consuming subscriber's port quota. 2558 A.6. Changes from draft-ietf-pcp-base-00 to -01 2560 o Significant document reorganization, primarily to split base PCP 2561 operation from OpCode operation. 2563 o packet format changed to move 'protocol' outside of PCP common 2564 header and into the MAP* opcodes 2566 o Renamed Informational Elements (IE) to Options. 2568 o Added REMOTE_PEER (for disambiguation with dynamic ports), 2569 REMOTE_PEER_FILTER (for simple packet filtering), and 2570 PREFER_FAILURE (to optimize UPnP IGD interworking) options. 2572 o Is NAT or router behind B4 in scope? 2574 o PCP option MAY be included in a request, in which case it MUST 2575 appear in a response. It MUST NOT appear in a response if it was 2576 not in the request. 2578 o Response code most significant bit now indicates permanent/ 2579 temporary error 2581 o PCP Options are split into mandatory-to-process ("P" bit), and 2582 into Specification Required and Private Use. 2584 o Epoch discussion simplified. 2586 Authors' Addresses 2588 Dan Wing (editor) 2589 Cisco Systems, Inc. 2590 170 West Tasman Drive 2591 San Jose, California 95134 2592 USA 2594 Email: dwing@cisco.com 2596 Stuart Cheshire 2597 Apple, Inc. 2598 1 Infinite Loop 2599 Cupertino, California 95014 2600 USA 2602 Phone: +1 408 974 3207 2603 Email: cheshire@apple.com 2605 Mohamed Boucadair 2606 France Telecom 2607 Rennes, 35000 2608 France 2610 Email: mohamed.boucadair@orange-ftgroup.com 2611 Reinaldo Penno 2612 Juniper Networks 2613 1194 N Mathilda Avenue 2614 Sunnyvale, California 94089 2615 USA 2617 Email: rpenno@juniper.net 2619 Francis Dupont 2620 Internet Systems Consortium 2622 Email: fdupont@isc.org