idnits 2.17.1 draft-ietf-pcp-base-26.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1421 has weird spacing: '...nternal exter...' -- The document date (June 5, 2012) is 4341 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-06) exists of draft-boucadair-pcp-failure-03 == 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-06 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 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: December 7, 2012 Apple 6 M. Boucadair 7 France Telecom 8 R. Penno 9 Cisco 10 P. Selkirk 11 ISC 12 June 5, 2012 14 Port Control Protocol (PCP) 15 draft-ietf-pcp-base-26 17 Abstract 19 The Port Control Protocol allows an IPv6 or IPv4 host to control how 20 incoming IPv6 or IPv4 packets are translated and forwarded by a 21 network address translator (NAT) or simple firewall, and also allows 22 a host to optimize its outgoing NAT keepalive messages. 24 Status of this Memo 26 This Internet-Draft is submitted 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). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 7, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 6 61 2.2. Supported Protocols . . . . . . . . . . . . . . . . . . . 6 62 2.3. Single-homed Customer Premises Network . . . . . . . . . . 6 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Relationship between PCP Server and its NAT/firewall . . . . . 10 65 5. Note on Fixed-Size Addresses . . . . . . . . . . . . . . . . . 11 66 6. Protocol Design Note . . . . . . . . . . . . . . . . . . . . . 12 67 7. Common Request and Response Header Format . . . . . . . . . . 13 68 7.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 14 69 7.2. Response Header . . . . . . . . . . . . . . . . . . . . . 15 70 7.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 7.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 19 72 8. General PCP Operation . . . . . . . . . . . . . . . . . . . . 20 73 8.1. General PCP Client: Generating a Request . . . . . . . . . 20 74 8.1.1. PCP Client Retransmission . . . . . . . . . . . . . . 21 75 8.2. General PCP Server: Processing a Request . . . . . . . . . 23 76 8.3. General PCP Client: Processing a Response . . . . . . . . 25 77 8.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . . 26 78 8.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 9. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28 80 10. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . . 29 81 10.1. For Operating a Server . . . . . . . . . . . . . . . . . . 31 82 10.2. For Operating a Symmetric Client/Server . . . . . . . . . 33 83 10.3. For Reducing NAT or Firewall Keepalive Messages . . . . . 35 84 10.4. For Restoring Lost Implicit TCP Dynamic Mapping State . . 36 85 11. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 37 86 11.1. MAP Operation Packet Formats . . . . . . . . . . . . . . . 38 87 11.2. Generating a MAP Request . . . . . . . . . . . . . . . . . 41 88 11.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . . 41 89 11.3. Processing a MAP Request . . . . . . . . . . . . . . . . . 42 90 11.4. Processing a MAP Response . . . . . . . . . . . . . . . . 44 91 11.5. Mapping Lifetime and Deletion . . . . . . . . . . . . . . 45 92 11.6. Address Change Events . . . . . . . . . . . . . . . . . . 47 93 11.7. Learning the External IP Address Alone . . . . . . . . . . 48 94 12. PEER Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 48 95 12.1. PEER Operation . . . . . . . . . . . . . . . . . . . . . . 49 96 12.2. Generating a PEER Request . . . . . . . . . . . . . . . . 53 97 12.3. Processing a PEER Request . . . . . . . . . . . . . . . . 53 98 12.4. Processing a PEER Response . . . . . . . . . . . . . . . . 55 99 13. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . . 55 100 13.1. THIRD_PARTY Option for MAP and PEER Opcodes . . . . . . . 56 101 13.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . . 58 102 13.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . . 59 103 14. Rapid Recovery . . . . . . . . . . . . . . . . . . . . . . . . 62 104 14.1. ANNOUNCE Opcode . . . . . . . . . . . . . . . . . . . . . 62 105 14.1.1. ANNOUNCE Operation . . . . . . . . . . . . . . . . . . 63 106 14.1.2. Generating and Processing a Solicited ANNOUNCE 107 Message . . . . . . . . . . . . . . . . . . . . . . . 63 108 14.1.3. Generating and Processing an Unsolicited ANNOUNCE 109 Message . . . . . . . . . . . . . . . . . . . . . . . 64 110 14.2. PCP Mapping Update . . . . . . . . . . . . . . . . . . . . 65 111 15. Implementation Considerations . . . . . . . . . . . . . . . . 67 112 15.1. Implementing MAP with EDM port-mapping NAT . . . . . . . . 67 113 15.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . . 67 114 15.3. PCP Failure Scenarios . . . . . . . . . . . . . . . . . . 68 115 15.3.1. Recreating Mappings . . . . . . . . . . . . . . . . . 68 116 15.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 69 117 15.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 69 118 15.4. Source Address Replicated in PCP Header . . . . . . . . . 70 119 15.5. State Diagram . . . . . . . . . . . . . . . . . . . . . . 70 120 16. Deployment Considerations . . . . . . . . . . . . . . . . . . 72 121 16.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 72 122 16.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 73 123 17. Security Considerations . . . . . . . . . . . . . . . . . . . 73 124 17.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 73 125 17.1.1. Attacks Considered . . . . . . . . . . . . . . . . . . 74 126 17.1.2. Deployment Examples Supporting the Simple Threat 127 Model . . . . . . . . . . . . . . . . . . . . . . . . 75 128 17.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 75 129 17.3. Residual Threats . . . . . . . . . . . . . . . . . . . . . 76 130 17.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 76 131 17.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 76 132 17.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 76 133 17.3.4. Attacks Against Server Discovery . . . . . . . . . . . 77 134 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 135 18.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 77 136 18.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 77 137 18.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 77 138 18.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 78 139 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 140 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 141 20.1. Normative References . . . . . . . . . . . . . . . . . . . 79 142 20.2. Informative References . . . . . . . . . . . . . . . . . . 79 143 Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . 82 144 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 83 145 B.1. Changes from draft-ietf-pcp-base-25 to -26 . . . . . . . . 83 146 B.2. Changes from draft-ietf-pcp-base-24 to -25 . . . . . . . . 83 147 B.3. Changes from draft-ietf-pcp-base-23 to -24 . . . . . . . . 84 148 B.4. Changes from draft-ietf-pcp-base-22 to -23 . . . . . . . . 86 149 B.5. Changes from draft-ietf-pcp-base-21 to -22 . . . . . . . . 87 150 B.6. Changes from draft-ietf-pcp-base-20 to -21 . . . . . . . . 88 151 B.7. Changes from draft-ietf-pcp-base-19 to -20 . . . . . . . . 88 152 B.8. Changes from draft-ietf-pcp-base-18 to -19 . . . . . . . . 88 153 B.9. Changes from draft-ietf-pcp-base-17 to -18 . . . . . . . . 88 154 B.10. Changes from draft-ietf-pcp-base-16 to -17 . . . . . . . . 89 155 B.11. Changes from draft-ietf-pcp-base-15 to -16 . . . . . . . . 89 156 B.12. Changes from draft-ietf-pcp-base-14 to -15 . . . . . . . . 89 157 B.13. Changes from draft-ietf-pcp-base-13 to -14 . . . . . . . . 90 158 B.14. Changes from draft-ietf-pcp-base-12 to -13 . . . . . . . . 90 159 B.15. Changes from draft-ietf-pcp-base-11 to -12 . . . . . . . . 91 160 B.16. Changes from draft-ietf-pcp-base-10 to -11 . . . . . . . . 91 161 B.17. Changes from draft-ietf-pcp-base-09 to -10 . . . . . . . . 91 162 B.18. Changes from draft-ietf-pcp-base-08 to -09 . . . . . . . . 92 163 B.19. Changes from draft-ietf-pcp-base-07 to -08 . . . . . . . . 93 164 B.20. Changes from draft-ietf-pcp-base-06 to -07 . . . . . . . . 94 165 B.21. Changes from draft-ietf-pcp-base-05 to -06 . . . . . . . . 95 166 B.22. Changes from draft-ietf-pcp-base-04 to -05 . . . . . . . . 96 167 B.23. Changes from draft-ietf-pcp-base-03 to -04 . . . . . . . . 97 168 B.24. Changes from draft-ietf-pcp-base-02 to -03 . . . . . . . . 98 169 B.25. Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . . 98 170 B.26. Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . . 99 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 173 1. Introduction 175 The Port Control Protocol (PCP) provides a mechanism to control how 176 incoming packets are forwarded by upstream devices such as Network 177 Address Translator IPv6/IPv4 (NAT64), Network Address Translator 178 IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to 179 reduce application keepalive traffic. PCP is designed to be 180 implemented in the context of Carrier-Grade NATs (CGNs), small NATs 181 (e.g., residential NATs), as well as with dual-stack and IPv6-only 182 Customer Premise Equipment (CPE) routers, and all of the currently- 183 known transition scenarios towards IPv6-only CPE routers. PCP allows 184 hosts to operate servers for a long time (e.g., a webcam) or a short 185 time (e.g., while playing a game or on a phone call) when behind a 186 NAT device, including when behind a CGN operated by their Internet 187 service provider or an IPv6 firewall integrated in their CPE router. 189 PCP allows applications to create mappings from an external IP 190 address, protocol, and port to an internal IP address, protocol, and 191 port. These mappings are required for successful inbound 192 communications destined to machines located behind a NAT or a 193 firewall. 195 After creating a mapping for incoming connections, it is necessary to 196 inform remote computers about the IP address, protocol, and port for 197 the incoming connection. This is usually done in an application- 198 specific manner. For example, a computer game might use a rendezvous 199 server specific to that game (or specific to that game developer), a 200 SIP phone would use a SIP proxy, and a client using DNS-Based Service 201 Discovery [I-D.cheshire-dnsext-dns-sd] would use DNS Update [RFC2136] 202 [RFC3007]. PCP does not provide this rendezvous function. The 203 rendezvous function may support IPv4, IPv6, or both. Depending on 204 that support and the application's support of IPv4 or IPv6, the PCP 205 client may need an IPv4 mapping, an IPv6 mapping, or both. 207 Many NAT-friendly applications send frequent application-level 208 messages to ensure their session will not be timed out by a NAT. 209 These are commonly called "NAT keepalive" messages, even though they 210 are not sent to the NAT itself (rather, they are sent 'through' the 211 NAT). These applications can reduce the frequency of such NAT 212 keepalive messages by using PCP to learn (and influence) the NAT 213 mapping lifetime. This helps reduce bandwidth on the subscriber's 214 access network, traffic to the server, and battery consumption on 215 mobile devices. 217 Many NATs and firewalls include Application Layer Gateways (ALGs) to 218 create mappings for applications that establish additional streams or 219 accept incoming connections. ALGs incorporated into NATs may also 220 modify the application payload. Industry experience has shown that 221 these ALGs are detrimental to protocol evolution. PCP allows an 222 application to create its own mappings in NATs and firewalls, 223 reducing the incentive to deploy ALGs in NATs and firewalls. 225 2. Scope 227 2.1. Deployment Scenarios 229 PCP can be used in various deployment scenarios, including: 231 o Basic NAT [RFC3022] 233 o Network Address and Port Translation [RFC3022], such as commonly 234 deployed in residential NAT devices 236 o Carrier-Grade NAT [I-D.ietf-behave-lsn-requirements] 238 o Dual-Stack Lite (DS-Lite) [RFC6333] 240 o Layer-2 Aware NAT [I-D.miles-behave-l2nat] 242 o Dual-Stack Extra Lite [I-D.arkko-dual-stack-extra-lite] 244 o NAT64, both Stateless [RFC6145] and Stateful [RFC6146] 246 o IPv4 and IPv6 simple firewall control [RFC6092] 248 o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] 250 2.2. Supported Protocols 252 The PCP Opcodes defined in this document are designed to support 253 transport-layer protocols that use a 16-bit port number (e.g., TCP, 254 UDP, SCTP [RFC4960], DCCP [RFC4340]). Protocols that do not use a 255 port number (e.g., RSVP, IPsec ESP [RFC4303], ICMP, ICMPv6) are 256 supported for IPv4 firewall, IPv6 firewall, and NPTv6 functions, but 257 are out of scope for any NAT functions. 259 2.3. Single-homed Customer Premises Network 261 PCP assumes a single-homed IP address model. That is, for a given IP 262 address of a host, only one default route exists to reach the 263 Internet from that source IP address. This is important because 264 after a PCP mapping is created and an inbound packet (e.g., TCP SYN) 265 arrives at the host, the outbound response (e.g., TCP SYNACK) has to 266 go through the same path so it is seen by the firewall or rewritten 267 by the NAT. This restriction exists because otherwise there would 268 need to be a PCP-enabled NAT for every egress (because the host could 269 not reliably determine which egress path packets would take) and the 270 client would need to be able to reliably make the same internal/ 271 external mapping in every NAT gateway, which in general is not 272 possible (because the other NATs might have the necessary port mapped 273 to another host). 275 3. Terminology 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 279 document are to be interpreted as described in "Key words for use in 280 RFCs to Indicate Requirement Levels" [RFC2119]. 282 Internal Host: 283 A host served by a NAT gateway, or protected by a firewall. This 284 is the host that will receive incoming traffic resulting from a 285 PCP mapping request, or the host that initiated an implicit 286 dynamic outbound mapping (e.g., by sending a TCP SYN) across a 287 firewall or a NAT. 289 Remote Peer Host: 290 A host with which an Internal Host is communicating. This can 291 include another Internal Host (or even the same Internal Host); if 292 a NAT is involved, the NAT would need to hairpin the traffic (see 293 Section 6 of [RFC4787] for definition of hairpin). 295 Internal Address: 296 The address of an Internal Host served by a NAT gateway or 297 protected by a firewall. 299 External Address: 300 The address of an Internal Host as seen by other Remote Peers on 301 the Internet with which the Internal Host is communicating, after 302 translation by any NAT gateways on the path. An External Address 303 is generally a public routable (i.e., non-private) address. In 304 the case of an Internal Host protected by a pure firewall, with no 305 address translation on the path, its External Address is the same 306 as its Internal Address. 308 Endpoint-Dependent Mapping (EDM): A term applied to NAT operation 309 where an implicit mapping created by outgoing traffic (e.g., TCP 310 SYN) from a single Internal Address, Protocol, and Port to 311 different Remote Peers and Ports may be assigned different 312 External Ports, and a subsequent PCP mapping request for that 313 Internal Address, Protocol, and Port may be assigned yet another 314 different External Port. This term encompasses both Address- 315 Dependent Mapping and Address and Port-Dependent Mapping 316 [RFC4787]. 318 Remote Peer Address: 319 The address of a Remote Peer, as seen by the Internal Host. A 320 Remote Address is generally a publicly routable address. In the 321 case of a Remote Peer that is itself served by a NAT gateway, the 322 Remote Address may in fact be the Remote Peer's External Address, 323 but since this remote translation is generally invisible to 324 software running on the Internal Host, the distinction can safely 325 be ignored for the purposes of this document. 327 Third Party: 328 In the common case, an Internal Host manages its own Mappings 329 using PCP requests, and the Internal Address of those Mappings is 330 the same as the source IP address of the PCP request packet. 332 In the case where one device is managing Mappings on behalf of 333 some other device that does not implement PCP, the presence of the 334 THIRD_PARTY Option in the MAP request signifies that the specified 335 address, rather than the source IP address of the PCP request 336 packet, should be used as the Internal Address for the Mapping. 338 Mapping, Port Mapping, Port Forwarding: 339 A NAT mapping creates a relationship between an internal IP 340 address, protocol, and port, and an external IP address, protocol, 341 and port. More specifically, it creates a translation rule where 342 packets destined to the external IP and port are translated to the 343 internal IP address, protocol, and port, and vice versa. In the 344 case of a pure firewall, the "Mapping" is the identity function, 345 translating an internal IP address, protocol, and port number to 346 the same external IP address, protocol, and port number. Firewall 347 filtering, applied in addition to that identity mapping function, 348 is separate from the mapping itself. 350 Mapping Types: 351 There are two dimensions to classifying mapping types: how they 352 are created (implicitly/explicitly) and their primary purpose 353 (outbound/inbound). 355 * Implicit dynamic mappings are created implicitly as a side- 356 effect of traffic such as an outgoing TCP SYN or outgoing UDP 357 packet. Such packets were not originally designed explicitly 358 for creating NAT (or firewall) state, but they can have that 359 effect when they pass through a NAT (or firewall) device. 361 * Explicit dynamic mappings are created as a result of explicit 362 PCP MAP and PEER requests. Like a DHCP address lease, explicit 363 dynamic mappings have finite lifetime, and, as with a DHCP 364 address lease, if a client wants a mapping to persist the 365 client must prove that it is still present by periodically 366 renewing the mapping to prevent it from expiring. If a PCP 367 client goes away, then any mappings it created will be 368 automatically cleaned up when they expire. 370 * Explicit static mappings are created by manual configuration 371 (e.g., via command-line interface or other user interface) and 372 persist until the user changes that manual configuration. 374 Both implicit and explicit dynamic mappings are dynamic in the 375 sense that they are created on demand, as requested (implicitly or 376 explicitly) by the Internal Host, and have a lifetime. After the 377 lifetime, the mapping is deleted unless the lifetime is extended 378 by action by the Internal Host (e.g., sending more traffic or 379 sending a new PCP request). 381 Explicit static mappings differ from explicit dynamic mappings in 382 that their lifetime is effectively infinite (they exist until 383 manually removed) but otherwise they behave exactly the same as 384 explicit MAP mappings. 386 While all mappings are by necessity bidirectional (most Internet 387 communication requires information to flow in both directions for 388 successful operation) it can be helpful when talking about 389 mappings to identify them loosely according to their 'primary' 390 purpose. 392 * Outbound mappings exist primarily to enable outbound 393 communication. For example, when a host calls connect() to 394 make an outbound connection, a NAT gateway will create an 395 implicit dynamic outbound mapping to facilitate that outbound 396 communication. 398 * Inbound mappings exist primarily to enable listening servers to 399 receive inbound connections. Generally, when a client calls 400 listen() to listen for inbound connections, a NAT gateway will 401 not implicitly create any mapping to facilitate that inbound 402 communication. A PCP MAP request can be used explicitly to 403 create a dynamic inbound mapping to enable the desired inbound 404 communication. 406 Explicit static (manual) mappings and explicit dynamic (MAP) 407 mappings both allow Internal Hosts to receive inbound traffic that 408 is not in direct response to any immediately preceding outbound 409 communication (i.e., to allow Internal Hosts to operate a "server" 410 that is accessible to other hosts on the Internet). 412 PCP Client: 413 A PCP software instance responsible for issuing PCP requests to a 414 PCP server. Unlike some other NAT and firewall control 415 applications which have to be embedded in the underlying operating 416 system or framework, several independent PCP Clients can exist on 417 the same host. Several PCP Clients can be located in the same 418 local network. A PCP Client can issue PCP requests on behalf of a 419 third party device for which it is authorized to do so. An 420 interworking function from Universal Plug and Play Internet 421 Gateway Device (UPnP IGDv1 [IGDv1]) to PCP is another example of a 422 PCP Client. A PCP server in a NAT gateway that is itself a client 423 of another NAT gateway (nested NAT) may itself act as a PCP client 424 to the upstream NAT. 426 PCP-Controlled Device: 427 A NAT or firewall that controls or rewrites packet flows between 428 internal hosts and remote peer hosts. PCP manages the Mappings on 429 this device. 431 PCP Server: 432 A PCP software instance that resides on the NAT or firewall that 433 receives PCP requests from the PCP client and creates appropriate 434 state in response to that request. 436 Subscriber: 437 The unit of billing for a commercial ISP. A subscriber may have a 438 single IP address from the commercial ISP (which can be shared 439 among multiple hosts using a NAT gateway, thereby making them 440 appear to be a single host to the ISP) or may have multiple IP 441 addresses provided by the commercial ISP. In either case, the IP 442 address or addresses provided by the ISP may themselves be further 443 translated by a large-scale NAT operated by the ISP. 445 4. Relationship between PCP Server and its NAT/firewall 447 The PCP server receives and responds to PCP requests. The PCP server 448 functionality is typically a capability of a NAT or firewall device, 449 as shown in Figure 1. It is also possible for the PCP functionality 450 to be provided by some other device, which communicates with the 451 actual NAT(s) or firewall(s) via some other proprietary mechanism, as 452 long as from the PCP client's perspective such split operation is 453 indistinguishable from the integrated case. 455 +-----------------+ 456 +------------+ | NAT or firewall | 457 | PCP client |--+ with +--- 458 +------------+ | PCP server | 459 +-----------------+ 461 Figure 1: PCP-Enabled NAT or Firewall 463 A NAT or firewall device, between the PCP client and the Internet, 464 might implement simple or advanced firewall functionality. This may 465 be a side-effect of the technology implemented by the device (e.g., a 466 network address and port translator, by virtue of its port rewriting, 467 normally requires connections to be initiated from an inside host 468 towards the Internet), or this might be an explicit firewall policy 469 to deny unsolicited traffic from the Internet. Some firewall devices 470 deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to 471 most ports) but allow certain other unsolicited traffic from the 472 Internet (e.g., UDP port 500 and IPsec ESP) [RFC6092]. Such default 473 filtering (or lack thereof) is out of scope of PCP itself. If a 474 device supports PCP and wants to receive traffic, and does not 475 possess knowledge of such filtering, it SHOULD use PCP to create the 476 necessary mappings to receive the desired traffic. 478 5. Note on Fixed-Size Addresses 480 For simplicity in building and parsing request and response packets, 481 PCP always uses fixed-size 128-bit IP address fields for both IPv6 482 addresses and IPv4 addresses. 484 When the address field holds an IPv6 address, the fixed-size 128-bit 485 IP address field holds the IPv6 address stored as-is. 487 When the address field holds an IPv4 address, IPv4-mapped IPv6 488 addresses [RFC4291] are used (::ffff:0:0/96). This has the first 80 489 bits set to zero and the next 16 set to one, while its last 32 bits 490 are filled with the IPv4 address. This is unambiguously 491 distinguishable from a native IPv6 address, because IPv4-mapped IPv6 492 address [RFC4291] would not be used for mappings. 494 When checking for an IPv4-mapped IPv6 address, all of the first 96 495 bits MUST be checked for the pattern -- it is not sufficient to check 496 for ones in bits 81-96. 498 The all-zeroes IPv6 address MUST be expressed by filling the fixed- 499 size 128-bit IP address field with all zeroes (::). 501 The all-zeroes IPv4 address MUST be expressed by 80 bits of zeros, 16 502 bits of ones, and 32 bits of zeros (::ffff:0:0). 504 6. Protocol Design Note 506 PCP can be viewed as a request/response protocol, much like many 507 other UDP-based request/response protocols, and can be implemented 508 perfectly well as such. It can also be viewed as what might be 509 called a hint/notification protocol, and this observation can help 510 simplify implementations. 512 Rather than viewing the message streams between PCP client and PCP 513 server as following a strict request/response pattern, where every 514 response is associated with exactly one request, the message flows 515 can be viewed as two somewhat independent streams carrying 516 information in opposite directions: 518 o A stream of hints flowing from PCP client to PCP server, where the 519 client indicates to the server what it would like the state of its 520 mappings to be, and 522 o A stream of notifications flowing from PCP server to PCP client, 523 where the server informs the clients what the state of its 524 mappings actually is. 526 To an extent, some of this approach is required anyway in a UDP-based 527 request/response protocol, since UDP packets can be lost, duplicated, 528 or reordered. 530 In this view of the protocol, the client transmits hints to the 531 server at various intervals signaling its desires, and the server 532 transmits notifications to the client signaling the actual state of 533 its mappings. These two message flows are loosely correlated in that 534 a client request (hint) usually elicits a server response 535 (notification), but only loosely, in that a client request may result 536 in no server response (in the case of packet loss) and a server 537 response may be generated gratuitously without an immediately 538 preceding client request (in the case where server configuration 539 change, e.g. change of external IP address on a NAT gateway, results 540 in a change of mapping state). 542 The exact times that client requests are sent are influenced by a 543 client timing state machine taking into account (i) if the client has 544 not yet received a response from the server for a prior request 545 (retransmission), and (ii) if the client has previously received a 546 response from the server saying how long the indicated mapping would 547 remain active (renewal). This design philosophy is the reason why 548 PCP's retransmissions and renewals are exactly the same packet on the 549 wire. Typically, retransmissions are sent with exponentially 550 increasing intervals as the client waits for the server to respond, 551 whereas renewals are sent with exponentially decreasing intervals as 552 the expiry time approaches, but from the server's point of view both 553 packets are identical, and both signal the client's desire that the 554 stated mapping exist or continue to exist. 556 A PCP server usually sends responses as a direct result of client 557 requests, but not always. For example, if a server is too overloaded 558 to respond, it is allowed to silently ignore a request message and 559 let the client retransmit. Also, if external factors cause a NAT 560 gateway or firewall's configuration to change, then the PCP server 561 can send unsolicited responses to clients informing them of the new 562 state of their mappings. Such reconfigurations are expected to be 563 rare, because of the disruption they can cause to clients, but should 564 they happen, PCP provides a way for servers, at their discretion, to 565 communicate the new state to clients promptly, without having to wait 566 for the next periodic renewal request. 568 This design goal helps explain why PCP request and response messages 569 have no transaction ID, because such a transaction ID is unnecessary, 570 and would unnecessarily limit the protocol and unnecessarily 571 complicate implementations. A PCP server response (i.e. 572 notification) is self-describing and complete. It communicates the 573 internal and external addresses, protocol, and ports for a mapping, 574 and its remaining lifetime. If the client does in fact currently 575 want such a mapping to exist then it can identify the mapping in 576 question from the internal address, protocol, and port, and update 577 its state to reflect the current external address and port, and 578 remaining lifetime. If a client does not currently want such a 579 mapping to exist then it can safely ignore the message. No client 580 action is required for unexpected mapping notifications. In today's 581 world a NAT gateway can have a static mapping, and the client device 582 has no explicit knowledge of this, and no way to change the fact. 583 Also, in today's world a client device can be connected directly to 584 the public Internet, with a globally-routable IP address, and in this 585 case it effectively has "mappings" for all of its listening ports. 586 Such a device has to be responsible for its own security, and cannot 587 have its security rely on assuming that some other network device 588 will be blocking all incoming packets. 590 7. Common Request and Response Header Format 592 All PCP messages are sent over UDP, with a maximum length of 1024 593 bytes. The PCP messages contain a request or response header 594 containing an Opcode, any relevant Opcode-specific information, and 595 zero or more Options. The packet layout for the common header, and 596 operation of the PCP client and PCP server, are described in the 597 following sections. The information in this section applies to all 598 Opcodes. Behavior of the Opcodes defined in this document is 599 described in Section 11 and Section 12. 601 7.1. Request Header 603 All requests have the following format: 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Version = 2 |R| Opcode | Reserved | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Requested Lifetime (32 bits) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | | 613 | PCP Client's IP Address (128 bits) | 614 | | 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 : : 618 : (optional) Opcode-specific information : 619 : : 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 : : 622 : (optional) PCP Options : 623 : : 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Figure 2: Common Request Packet Format 628 These fields are described below: 630 Version: This document specifies protocol version 2. PCP clients 631 and servers compliant with this document use the value 2. This 632 field is used for version negotiation as described in Section 9. 634 R: Indicates Request (0) or Response (1). 636 Opcode: A seven-bit value specifying the operation to be performed. 637 Opcodes are defined in Section 11 and Section 12. 639 Reserved: 16 reserved bits. MUST be 0 on transmission and MUST be 640 ignored on reception. 642 Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging 643 from 0 to 2^32-1 seconds. This is used by the MAP and PEER 644 Opcodes defined in this document for their requested lifetime. 646 PCP Client's IP Address: The source IPv4 or IPv6 address in the IP 647 header used by the PCP client when sending this PCP request. IPv4 648 is represented using an IPv4-mapped IPv6 address. This is used to 649 detect an on-path NAT, see Section 8.3. 651 Opcode-specific information: Payload data for this Opcode. The 652 length of this data is determined by the Opcode definition. 654 PCP Options: Zero, one, or more Options that are legal for both a 655 PCP request and for this Opcode. See Section 7.3. 657 7.2. Response Header 659 All responses have the following format: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Version = 2 |R| Opcode | Reserved | Result Code | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Lifetime (32 bits) | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Epoch Time (32 bits) | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | | 671 | Reserved (96 bits) | 672 | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 : : 675 : (optional) Opcode-specific response data : 676 : : 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 : (optional) Options : 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 3: Common Response Packet Format 683 These fields are described below: 685 Version: Responses from servers compliant with this specification 686 MUST use version 2. This is set by the server. 688 R: Indicates Request (0) or Response (1). All Responses MUST use 1. 689 This is set by the server. 691 Opcode: The 7-bit Opcode value. The server copies this value from 692 the request. 694 Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when 695 received. This is set by the server. 697 Result Code: The result code for this response. See Section 7.4 for 698 values. This is set by the server. 700 Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 701 2^32-1 seconds. On an error response, this indicates how long 702 clients should assume they'll get the same error response from 703 that PCP server if they repeat the same request. On a success 704 response for the PCP Opcodes that create a mapping (MAP and PEER), 705 the Lifetime field indicates the lifetime for this mapping. This 706 is set by the server. 708 Epoch Time: The server's Epoch time value. See Section 8.5 for 709 discussion. This value is set by the server, in both success and 710 error responses. 712 Reserved: 96 reserved bits. For requests that were successfully 713 parsed, this MUST be sent as 0, MUST be ignored when received. 714 This is set by the server. For requests that were not 715 successfully parsed, the server copies the last 96 bits of the PCP 716 Client's IP Address field from the request message into this 717 corresponding 96 bit field of the response. 719 Opcode-specific information: Payload data for this Opcode. The 720 length of this data is determined by the Opcode definition. 722 PCP Options: Zero, one, or more Options that are legal for both a 723 PCP response and for this Opcode. See Section 7.3. 725 7.3. Options 727 A PCP Opcode can be extended with one or more Options. Options can 728 be used in requests and responses. The design decisions in this 729 specification about whether to include a given piece of information 730 in the base Opcode format or in an Option were an engineering trade- 731 off between packet size and code complexity. For information that is 732 usually (or always) required, placing it in the fixed Opcode data 733 results in simpler code to generate and parse the packet, because the 734 information is a fixed location in the Opcode data, but wastes space 735 in the packet in the event that field is all-zeroes because the 736 information is not needed or not relevant. For information that is 737 required less often, placing it in an Option results in slightly more 738 complicated code to generate and parse packets containing that 739 Option, but saves space in the packet when that information is not 740 needed. Placing information in an Option also means that an 741 implementation that never uses that information doesn't even need to 742 implement code to generate and parse it. For example, a client that 743 never requests mappings on behalf of some other device doesn't need 744 to implement code to generate the THIRD_PARTY Option, and a PCP 745 server that doesn't implement the necessary security measures to 746 create third-party mappings safely doesn't need to implement code to 747 parse the THIRD_PARTY Option. 749 Options use the following Type-Length-Value format: 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Option Code | Reserved | Option Length | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 : (optional) data : 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Figure 4: Options Header 761 The description of the fields is as follows: 763 Option Code: 8 bits. Its most significant bit indicates if this 764 Option is mandatory (0) or optional (1) to process. 766 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 767 ignored on reception. 769 Option Length: 16 bits. Indicates the length of the enclosed data, 770 in octets. Options with length of 0 are allowed. Options that 771 are not a multiple of four octets long are followed by one, two, 772 or three zero octets to pad their effective length in the packet 773 to be a multiple of four octets. The Option Length reflects the 774 semantic length of the option, not including any padding octets. 776 data: Option data. 778 If several Options are included in a PCP request, they MAY be encoded 779 in any order by the PCP client, but MUST be processed by the PCP 780 server in the order in which they appear. It is the responsibility 781 of the PCP client to ensure the server has sufficient room to reply 782 without exceeding the 1024-byte size limit; if its reply would exceed 783 that size, the server generates an error. 785 If, while processing an Option, an error is encountered that causes a 786 PCP error response to be generated, the PCP request MUST cause no 787 state change in the PCP server or the PCP-controlled device (i.e., it 788 rolls back any changes it might have made while processing the 789 request). Such an error response MUST consist of a complete copy of 790 the request packet with the error code and other appropriate fields 791 set in the header. An Option MAY appear more than once in a request 792 or in a response, if permitted by the definition of the Option. If 793 the Option's definition allows the Option to appear only once but it 794 appears more than once in a request, and the Option is understood by 795 the PCP server, the PCP server MUST respond with the MALFORMED_OPTION 796 result code. If the PCP server encounters an invalid option (e.g., 797 PCP option length is longer than the UDP packet length) the error 798 MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST), 799 as that helps the client better understand how the packet was 800 malformed. If a PCP response would have exceeded the maximum PCP 801 message size, the PCP server SHOULD respond with MALFORMED_REQUEST. 803 If an Option cannot successfully be parsed, the PCP server MUST 804 generate an error response with code MALFORMED_OPTION. The most 805 significant bit in the Option Code indicates if its processing is 806 optional or mandatory. If the most significant bit is set, handling 807 this Option is optional, and a PCP server MAY process or ignore this 808 Option, entirely at its discretion. If the most significant bit is 809 clear, handling this Option is mandatory, and a PCP server MUST 810 return the error UNSUPP_OPTION if the Option is unrecognized, 811 unimplemented, or disabled, or if the client is not authorized to use 812 the Option. All processed options are included in successful 813 responses, but unprocessed options are not included in successful 814 responses. All options are returned in error responses. 816 PCP clients are free to ignore any or all Options included in 817 responses, although naturally if a client explicitly requests an 818 Option where correct execution of that Option requires processing the 819 Option data in the response, that client is expected to implement 820 code to do that. 822 Different options are valid for different Opcodes. For example: 824 o The THIRD_PARTY Option is valid for both MAP and PEER Opcodes. 826 o The FILTER Option is valid only for the MAP Opcode (for the PEER 827 Opcode it would have no meaning). 829 o The PREFER_FAILURE Option is valid only for the MAP Opcode (for 830 the PEER Opcode, similar semantics are automatically implied). 832 7.4. Result Codes 834 The following result codes may be returned as a result of any Opcode 835 received by the PCP server. The only success result code is 0; other 836 values indicate an error. If a PCP server encounters multiple errors 837 during processing of a request, it SHOULD use the most specific error 838 message. Each error code below is classified as either a 'long 839 lifetime' error or a 'short lifetime' error, which provides guidance 840 to PCP server developers for the value of the Lifetime field for 841 these errors. It is RECOMMENDED that short lifetime errors use a 30 842 second lifetime and long lifetime errors use a 30 minute lifetime. 844 0 SUCCESS: Success. 846 1 UNSUPP_VERSION: Unsupported protocol version. This is a long 847 lifetime error. 849 2 NOT_AUTHORIZED: The requested operation is disabled for this PCP 850 client, or the PCP client requested an operation that cannot be 851 fulfilled by the PCP server's security policy. This is a long 852 lifetime error. 854 3 MALFORMED_REQUEST: The request could not be successfully parsed. 855 This is a long lifetime error. 857 4 UNSUPP_OPCODE: Unsupported Opcode. This is a long lifetime error. 859 5 UNSUPP_OPTION: Unsupported Option. This error only occurs if the 860 Option is in the mandatory-to-process range. This is a long 861 lifetime error. 863 6 MALFORMED_OPTION: Malformed Option (e.g., appears too many times, 864 invalid length). This is a long lifetime error. 866 7 NETWORK_FAILURE: The PCP server or the device it controls are 867 experiencing a network failure of some sort (e.g., has not 868 obtained an External IP address). This is a short lifetime error. 870 8 NO_RESOURCES: Request is well-formed and valid, but the server has 871 insufficient resources to complete the requested operation at this 872 time. For example, the NAT device cannot create more mappings at 873 this time, is short of CPU cycles or memory, or due to some other 874 temporary condition. The same request may succeed in the future. 875 This is a system-wide error, different from USER_EX_QUOTA. This 876 can be used as a catch-all error, should no other error message be 877 suitable. This is a short lifetime error. 879 9 UNSUPP_PROTOCOL: Unsupported Protocol. This is a long lifetime 880 error. 882 10 USER_EX_QUOTA: This attempt to create a new mapping would exceed 883 this subscriber's port quota. This is a short lifetime error. 885 11 CANNOT_PROVIDE_EXTERNAL: the suggested external port and/or 886 external address cannot be provided. This error MUST only be 887 returned for PEER requests, for MAP requests that included the 888 PREFER_FAILURE Option (because otherwise a new external port could 889 have been assigned), or MAP requests for the SCTP protocol. See 890 Section 13.2 for processing details. The error lifetime depends 891 on the reason for the failure. 893 12 ADDRESS_MISMATCH: the source IP address of the request packet does 894 not match the contents of the PCP Client's IP Address field. This 895 is a long lifetime error. 897 13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the 898 filters in this request. This result code MUST only be returned 899 if the MAP request contained the FILTER Option. See Section 13.3 900 for processing information. This is a long lifetime error. 902 8. General PCP Operation 904 PCP messages MUST be sent over UDP [RFC0768]. Every PCP request 905 generates at least one response, so PCP does not need to run over a 906 reliable transport protocol. 908 When receiving multiple identical requests, the PCP server will 909 generate identical responses, provided the PCP server's state did not 910 change between those requests due to other activity. For example, if 911 a request is received while the PCP-controlled device has no mappings 912 available, it will generate an error response. If mappings become 913 available and then a (duplicated or re-transmitted) request is seen 914 by the server, it will generate a non-error response. A PCP client 915 will need to properly handle such updated responses for any request 916 it sends, most notably to support Mapping Update (Section 14.2). 917 Also see Section 6. 919 8.1. General PCP Client: Generating a Request 921 This section details operation specific to a PCP client, for any 922 Opcode. Procedures specific to the MAP Opcode are described in 923 Section 11, and procedures specific to the PEER Opcode are described 924 in Section 12. 926 Prior to sending its first PCP message, the PCP client determines 927 which server to use. The PCP client performs the following steps to 928 determine its PCP server: 930 1. if a PCP server is configured (e.g., in a configuration file or 931 via DHCP), that single configuration source is used as the list 932 of PCP Server(s), else; 934 2. the default router list (for IPv4 and IPv6) is used as the list 935 of PCP Server(s). Thus, if a PCP client has both an IPv4 and 936 IPv6 address, it will have an IPv4 PCP server (its IPv4 default 937 router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6 938 default router) for its IPv6 mappings. 940 For the purposes of this document, only a single PCP server address 941 is supported. Should future specifications define configuration 942 methods that provide a list of PCP server addresses, those 943 specifications will define how clients select one or more addresses 944 from that list. 946 With that PCP server address, the PCP client formulates its PCP 947 request. The PCP request contains a PCP common header, PCP Opcode 948 and payload, and (possibly) Options. As with all UDP client software 949 on any operating system, when several independent PCP clients exist 950 on the same host, each uses a distinct source port number to 951 disambiguate their requests and replies. The PCP client's source 952 port SHOULD be randomly generated [RFC6056]. 954 To assist with detecting an on-path NAT, the PCP client MUST include 955 the source IP address of the PCP message in the PCP request. This is 956 typically its own IP address; see Section 15.4 for how this can be 957 coded. 959 8.1.1. PCP Client Retransmission 961 PCP clients are responsible for reliable delivery of PCP request 962 messages. If a PCP client fails to receive an expected response from 963 a server, the client must retransmit its message. The client begins 964 the message exchange by transmitting a message to the server. The 965 message exchange terminates when either the client successfully 966 receives the appropriate response or responses from the server, or 967 when the message exchange is considered to have failed according to 968 the retransmission mechanism described below, or the PCP client is no 969 longer interested in PCP transaction (e.g., the application that 970 requested the mapping is no longer interested in the mapping). 972 The client retransmission behavior is controlled and described by the 973 following variables: 975 RT: Retransmission timeout, calculated as described below 977 IRT: Initial retransmission time, SHOULD be 3 seconds 979 MRC: Maximum retransmission count, SHOULD be 0 (0 indicates no 980 maximum) 982 MRT: Maximum retransmission time, SHOULD be 1024 seconds 984 MRD: Maximum retransmission duration, SHOULD be 0 (0 indicates no 985 maximum) 987 RAND: Randomization factor, calculated as described below 989 With each message transmission or retransmission, the client sets RT 990 according to the rules given below. If RT expires before a response 991 is received, the client recomputes RT and retransmits the request. 993 Each of the computations of a new RT include a new randomization 994 factor (RAND), which is a random number chosen with a uniform 995 distribution between -0.1 and +0.1. The randomization factor is 996 included to minimize synchronization of messages transmitted by PCP 997 clients. The algorithm for choosing a random number does not need to 998 be cryptographically sound. The algorithm SHOULD produce a different 999 sequence of random numbers from each invocation of the PCP client. 1001 The RT value is initialized based on IRT: 1003 RT = IRT + RAND*IRT 1005 RT for each subsequent message transmission is based on the previous 1006 value of RT: 1008 RT = 2*RTprev + RAND*RTprev 1010 MRT specifies an upper bound on the value of RT (disregarding the 1011 randomization added by the use of RAND). If MRT has a value of 0, 1012 there is no upper limit on the value of RT. Otherwise: 1014 if (RT > MRT) 1015 RT = MRT + RAND*MRT 1017 MRC specifies an upper bound on the number of times a client may 1018 retransmit a message. Unless MRC is zero, the message exchange fails 1019 once the client has transmitted the message MRC times. 1021 MRD specifies an upper bound on the length of time a client may 1022 retransmit a message. Unless MRD is zero, the message exchange fails 1023 once MRD seconds have elapsed since the client first transmitted the 1024 message. 1026 If both MRC and MRD are non-zero, the message exchange fails whenever 1027 either of the conditions specified in the previous two paragraphs are 1028 met. If both MRC and MRD are zero, the client continues to transmit 1029 the message until it receives a response. 1031 Once a PCP client has successfully received a response from a PCP 1032 server on that interface, it resets RT to its initial value and sends 1033 subsequent PCP requests to that same server. 1035 8.2. General PCP Server: Processing a Request 1037 This section details operation specific to a PCP server. Processing 1038 SHOULD be performed in the order of the following paragraphs. 1040 A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests 1041 from a client on the same interface it would normally receive packets 1042 from that client, and MUST silently ignore PCP requests arriving on 1043 any other interface. For example, a residential NAT gateway accepts 1044 PCP requests only when they arrive on its (LAN) interface connecting 1045 to the internal network, and silently ignores any PCP requests 1046 arriving on its external (WAN) interface. A PCP server which 1047 supports THIRD_PARTY requests MAY be configured to accept THIRD_PARTY 1048 requests on other configured interfaces (see Section 13.1). 1050 Upon receiving a request, the PCP server parses and validates it. A 1051 valid request contains a valid PCP common header, one valid PCP 1052 Opcode, and zero or more Options (which the server might or might not 1053 comprehend). If an error is encountered during processing, the 1054 server generates an error response which is sent back to the PCP 1055 client. Processing an Opcode and the Options are specific to each 1056 Opcode. 1058 Error responses have the same packet layout as success responses, 1059 with certain fields from the request copied into the response, and 1060 other fields assigned by the PCP server set as indicated in Figure 3. 1062 Copying request fields into the response is important because this is 1063 what enables a client to identify to which request a given response 1064 pertains. For Opcodes that are understood by the PCP server, it 1065 follows the requirements of that Opcode to copy the appropriate 1066 fields. For Opcodes that are not understood by the PCP server, it 1067 simply generates the UNSUPP_OPCODE response and copies fields from 1068 the PCP header and copies the rest of the PCP payload as-is (without 1069 attempting to interpret it). 1071 All responses (both error and success) contain the same Opcode as the 1072 request, but with the "R" bit set. 1074 Any error response has a nonzero Result Code, and is created by: 1075 o Copying the entire request packet, or 1024 octets, whichever is 1076 less, and zero-padding the response to a multiple of 4 octets if 1077 necessary 1078 o Setting the R bit 1079 o Setting the Result Code 1080 o Setting the Lifetime, Epoch Time and Reserved fields 1081 o Updating other fields in the response, as indicated by 'set by the 1082 server' in the PCP response field description. 1084 A success response has a zero Result Code, and is created by: 1085 o Copying the first four octets of request packet header 1086 o Setting the R bit 1087 o Setting the Result Code to zero 1088 o Setting the Lifetime, Epoch Time and Reserved fields 1089 o Possibly setting opcode-specific response data if appropriate 1090 o Adding any processed options to the response message 1092 If the received PCP request message is less than two octets long it 1093 is silently dropped. 1095 If the R bit is set the message is silently dropped. 1097 If the first octet (version) is a version that is not supported, a 1098 response is generated with the UNSUPP_VERSION result code, and the 1099 other steps detailed in Section 9 are followed. 1101 Otherwise, if the version is supported but the received message is 1102 shorter than 24 octets, the message is silently dropped. 1104 If the server is overloaded by requests (from a particular client or 1105 from all clients), it MAY simply silently discard requests, as the 1106 requests will be retried by PCP clients, or it MAY generate the 1107 NO_RESOURCES error response. 1109 If the length of the message exceeds 1024 octets, is not a multiple 1110 of 4 octets, or is too short for the opcode in question, it is 1111 invalid and a MALFORMED_REQUEST response is generated, and the 1112 response message is truncated to 1024 octets. 1114 The PCP server compares the source IP address (from the received IP 1115 header) with the field PCP Client IP Address. If they do not match, 1116 the error ADDRESS_MISMATCH MUST be returned. This is done to detect 1117 and prevent accidental use of PCP where a non-PCP-aware NAT exists 1118 between the PCP client and PCP server. If the PCP client wants such 1119 a mapping it needs to ensure the PCP field matches its apparent IP 1120 address from the perspective of the PCP server. 1122 8.3. General PCP Client: Processing a Response 1124 The PCP client receives the response and verifies that the source IP 1125 address and port belong to the PCP server of a previously-sent PCP 1126 request. If not, the response is silently dropped. 1128 If the received PCP response message is less than four octets long it 1129 is silently dropped. 1131 If the R bit is clear the message is silently dropped. 1133 If the error code is UNSUPP_VERSION processing continues as described 1134 in Section 9. 1136 The PCP client then validates that the Opcode matches a previous PCP 1137 request. Responses shorter than 24 octets, longer than 1024 octets, 1138 or not a multiple of 4 octets are invalid and ignored, likely causing 1139 the request to be re-transmitted. The response is further matched by 1140 comparing fields in the response Opcode-specific data to fields in 1141 the request Opcode-specific data, as described by the processing for 1142 that Opcode. After these matches are successful, the PCP client 1143 checks the Epoch Time field to determine if it needs to restore its 1144 state to the PCP server (see Section 8.5). A PCP client SHOULD be 1145 prepared to receive multiple responses from the PCP Server at any 1146 time after a single request is sent. This allows the PCP server to 1147 inform the client of mapping changes such as an update or deletion. 1148 For example, a PCP Server might send a SUCCESS response and, after a 1149 configuration change on the PCP Server, later send a NOT_AUTHORIZED 1150 response. A PCP client MUST be prepared to receive responses for 1151 requests it never sent (which could have been sent by a previous PCP 1152 instance on this same host, or by a previous host that used the same 1153 client IP address) by simply ignoring those unexpected messages. 1155 If the error ADDRESS_MISMATCH is received, it indicates the presence 1156 of a NAT between the PCP client and PCP server. Procedures to 1157 resolve this problem are beyond the scope of this document. 1159 For both success and error responses a Lifetime value is returned. 1160 The Lifetime indicates how long this request is considered valid by 1161 the server. The PCP client SHOULD impose an upper limit on this 1162 returned value (to protect against absurdly large values, e.g., 5 1163 years), detailed in Section 11.5. 1165 If the result code is 0 (SUCCESS), the request succeeded. 1167 If the result code is not 0, the request failed. If the result code 1168 is NO_RESOURCES, the PCP client SHOULD NOT send further requests for 1169 new mappings to that PCP server for the value of the Lifetime 1170 (limited by the sanity checking detailed in Section 11.5). If a 1171 request for renewal or deletion of an existing mapping results in 1172 NO_RESOURCES, the PCP client SHOULD NOT send further requests of any 1173 kind to that PCP server for the (limited) value of the Lifetime. For 1174 other error result codes, the PCP client SHOULD NOT resend the same 1175 request for the (limited) value of the Lifetime. 1177 If the PCP client has discovered a new PCP server (e.g., connected to 1178 a new network), the PCP client MAY immediately begin communicating 1179 with this PCP server, without regard to hold times from communicating 1180 with a previous PCP server. 1182 8.4. Multi-Interface Issues 1184 Hosts which desire a PCP mapping might be multi-interfaced (i.e., own 1185 several logical/physical interfaces). Indeed, a host can be 1186 configured with several IPv4 addresses (e.g., WiFi and Ethernet) or 1187 dual-stacked. These IP addresses may have distinct reachability 1188 scopes (e.g., if IPv6 they might have global reachability scope as 1189 for Global Unicast Address (GUA, [RFC3587]) or limited scope as for 1190 Unique Local Address (ULA) [RFC4193]). 1192 IPv6 addresses with global reachability (e.g., GUA) SHOULD be used as 1193 the source address when generating a PCP request. IPv6 addresses 1194 without global reachability (e.g., ULA [RFC4193]), SHOULD NOT be used 1195 as the source interface when generating a PCP request. If IPv6 1196 privacy addresses [RFC4941] are used for PCP mappings, a new PCP 1197 request will need to be issued whenever the IPv6 privacy address is 1198 changed. This PCP request SHOULD be sent from the IPv6 privacy 1199 address itself. It is RECOMMENDED that the client delete its 1200 mappings to the previous privacy address after it no longer needs 1201 those old mappings. 1203 Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope 1204 (e.g., private addresses [RFC1918]) MAY be used as the source 1205 interface when generating a PCP request. 1207 8.5. Epoch 1209 Every PCP response sent by the PCP server includes an Epoch time 1210 field. This time field increments by one every second. Anomalies in 1211 the received Epoch time value provide a hint to PCP clients that a 1212 PCP server state loss may have occurred. Clients respond to such 1213 state loss hints by promptly renewing their mappings, so as to 1214 quickly restore any lost state at the PCP server. 1216 If the PCP server resets or loses the state of its explicit dynamic 1217 Mappings (that is, those mappings created by PCP requests), due to 1218 reboot, power failure, or any other reason, it MUST reset its Epoch 1219 time to its initial starting value (usually zero) to provide this 1220 hint to PCP clients. After resetting its Epoch time, the PCP server 1221 resumes incrementing the Epoch time value by one every second. 1222 Similarly, if the public IP address(es) of the NAT (controlled by the 1223 PCP server) changes, the Epoch time MUST be reset. A PCP server MAY 1224 maintain one Epoch time value for all PCP clients, or MAY maintain 1225 distinct Epoch time values (per PCP client, per interface, or based 1226 on other criteria); this choice is implementation-dependent. 1228 Whenever a client receives a PCP response, the client validates the 1229 received Epoch time value according to the procedure below, using 1230 integer arithmetic: 1232 o If this is the first PCP response the client has received from 1233 this PCP server, the Epoch time value is treated as necessarily 1234 valid, otherwise 1236 * If the current PCP server Epoch time value 1237 (current_server_time) is less than the previously received PCP 1238 server Epoch time value (previous_server_time) then the client 1239 treats the Epoch time value as obviously invalid (time should 1240 not go backwards), else 1242 + The client computes the difference between its 1243 current local time value (current_client_time) and the 1244 time the previous PCP response was received from this PCP 1245 server (previous_client_time): 1246 client_delta = current_client_time - previous_client_time; 1248 + The client computes the difference between the 1249 current PCP server Epoch time value (current_server_time) 1250 and the 1251 previously received Epoch time value (previous_server_time): 1252 server_delta = current_server_time - previous_server_time; 1254 + If client_delta+2 < server_delta - server_delta/16 1255 or server_delta+2 < client_delta - client_delta/16 1256 then the client treats the Epoch time value as invalid, 1257 else the client treats the Epoch time value as valid 1259 o The client records the current time values for use in its next 1260 comparison: 1261 previous_client_time = current_client_time 1262 previous_server_time = current_server_time 1264 If the PCP client determined that the Epoch time value it received 1265 was invalid then it concludes that the PCP server may have lost 1266 state, and promptly renews all its active port mapping leases as 1267 described in Section 15.3.1. 1269 Notes: 1271 o The client clock MUST never go backwards. If current_client_time 1272 is found to be less than previous_client_time then this is a 1273 client bug, and how the client deals with this client bug is 1274 implementation specific. 1276 o The calculations above are constructed to allow client_delta and 1277 server_delta to be computed as unsigned integer values. 1279 o The "+2" in the calculations above is to accommodate quantization 1280 errors in client and server clocks (up to one second quantization 1281 error each in server and client time intervals). 1283 o The "/16" in the calculations above is to accommodate inaccurate 1284 clocks in low-cost devices. This allows for a total discrepancy 1285 of up to 1/16 (6.25%) to be considered benign, e.g., if one clock 1286 were to run too fast by 3% while the other clock ran too slow by 1287 3% then the client would not consider this difference to be 1288 anomalous or indicative of a restart having occurred. This 1289 tolerance is strict enough to be effective at detecting reboots, 1290 while not being so strict as to generate false alarms. 1292 9. Version Negotiation 1294 A PCP client sends its requests using PCP version number 2. Should 1295 later updates to this document specify different message formats with 1296 a version number greater than 2 it is expected that PCP servers will 1297 still support version 2 in addition to the newer version(s). 1298 However, in the event that a server returns a response with result 1299 code UNSUPP_VERSION, the client MAY log an error message to inform 1300 the user that it is too old to work with this server. 1302 Should later updates to this document specify different message 1303 formats with a version number greater than 2, and backwards 1304 compatibility is desired, this first octet can be used for forward 1305 and backward compatibility. 1307 If future PCP versions greater than 2 are specified, version 1308 negotiation proceeds as follows: 1310 1. The client sends its first request using the highest (i.e., 1311 presumably 'best') version number it supports. 1313 2. If the server supports that version it responds normally. 1315 3. If the server does not support that version it replies giving a 1316 result containing the result code UNSUPP_VERSION, and the closest 1317 version number it does support (if the server supports a range of 1318 versions higher than the client's requested version, the server 1319 returns the lowest of that supported range; if the server 1320 supports a range of versions lower than the client's requested 1321 version, the server returns the highest of that supported range). 1323 4. If the client receives an UNSUPP_VERSION result containing a 1324 version it does support, it records this fact and proceeds to use 1325 this message version for subsequent communication with this PCP 1326 server (until a possible future UNSUPP_VERSION response if the 1327 server is later updated, at which point the version negotiation 1328 process repeats). 1330 5. If the client receives an UNSUPP_VERSION result containing a 1331 version it does not support then the client SHOULD try the next- 1332 lower version supported by the client. The attempt to use the 1333 next-lower version repeats until the client has tried version 2. 1334 If using version 2 fails, the client MAY log an error message to 1335 inform the user that it is too old to work with this server, and 1336 the client SHOULD set a timer to retry its request in 30 minutes 1337 or the returned Lifetime value, whichever is smaller. By 1338 automatically retrying in 30 minutes, the protocol accommodates 1339 an upgrade of the PCP server. 1341 10. Introduction to MAP and PEER Opcodes 1343 There are four uses for the MAP and PEER Opcodes defined in this 1344 document: 1346 o a host operating a server and wanting an incoming connection 1347 (Section 10.1); 1349 o a host operating a client and server on the same port 1350 (Section 10.2); 1352 o a host operating a client and wanting to optimize the application 1353 keepalive traffic (Section 10.3); 1355 o and a host operating a client and wanting to restore lost state in 1356 its NAT (Section 10.4). 1358 These are discussed in the following sections, and a (non-normative) 1359 state diagram is provided in Section 15.5. 1361 When operating a server (Section 10.1 and Section 10.2) the PCP 1362 client knows if it wants an IPv4 listener, IPv6 listener, or both on 1363 the Internet. The PCP client also knows if it has an IPv4 address or 1364 IPv6 address configured on one of its interfaces. It takes the union 1365 of this knowledge to decide to which of its PCP servers to send the 1366 request (e.g., an IPv4 address or an IPv6 address), and if to send 1367 one or two MAP requests for each of its interfaces (e.g., if the PCP 1368 client has only an IPv4 address but wants both IPv6 and IPv4 1369 listeners, it sends a MAP request containing the all-zeros IPv6 1370 address in the Suggested External Address field, and sends a second 1371 MAP request containing the all-zeros IPv4 address in the Suggested 1372 External Address field. If the PCP client has both an IPv4 and IPv6 1373 address, and only wants an IPv4 listener, it sends one MAP request 1374 from its IPv4 address (if the PCP server supports NAT44 or IPv4 1375 firewall) or one MAP request from its IPv6 address (if the PCP server 1376 supports NAT64)). The PCP client can simply request the desired 1377 mapping to determine if the PCP server supports the desired mapping. 1378 Applications that embed IP addresses in payloads (e.g., FTP, SIP) 1379 will find it beneficial to avoid address family translation, if 1380 possible. 1382 The MAP and PEER requests include a Suggested External IP Address 1383 field. Some PCP-controlled devices, especially CGN but also multi- 1384 homed NPTv6 networks, have a pool of public-facing IP addresses. PCP 1385 allows the client to indicate if it wants a mapping assigned on a 1386 specific address of that pool or any address of that pool. Some 1387 applications will break if mappings are created on different IP 1388 addresses (e.g., active mode FTP), so applications should carefully 1389 consider the implications of using this capability. Static mappings 1390 for that Internal Address (e.g., those created by a command-line 1391 interface on the PCP server or PCP-controlled device) may exist to a 1392 certain External Address, and if the Suggested External IP Address is 1393 the all-zeros address, PCP SHOULD assign its mappings to the same 1394 External Address, as this can also help applications using a mix of 1395 both static mappings and PCP-created mappings. If, on the other 1396 hand, the Suggested External IP Address contains an IP address the 1397 PCP Server SHOULD create a mapping to that external address, even if 1398 there are other mappings from that same Internal Address to a 1399 different External Address. Once an Internal Address has no implicit 1400 dynamic mappings and no explicit dynamic mappings in the PCP- 1401 controlled device, a subsequent implicit or explicit mapping for that 1402 Internal Address MAY be assigned to a different External Address. 1403 Generally, this re-assignment would occur when a CGN device is load 1404 balancing newly-seen Internal Addresses to its public pool of 1405 External Addresses. 1407 The following table summarizes how various common PCP deployments use 1408 IPv6 and IPv4 addresses. The 'internal' address is implicitly the 1409 same as the source IP address of the PCP request, except when the 1410 THIRD_PARTY option is used. The 'external' address is the Suggested 1411 External Address field of the MAP or PEER request, and is address 1412 family is usually the same as the 'internal' address family, except 1413 when technologies like NAT64 are used. The 'remote peer' address is 1414 the Remote Peer IP Address of the PEER request or the FILTER option 1415 of the MAP request, and is always the same address family as the 1416 'internal' address, even when NAT64 is used. In NAT64, the IPv6 PCP 1417 client is not necessarily aware of the NAT64 or aware of the actual 1418 IPv4 address of the remote peer, so it expresses the IPv6 address 1419 from its perspective as shown in the table. 1421 internal external remote peer 1422 -------- ------- ----------- 1423 IPv4 firewall IPv4 IPv4 IPv4 1424 IPv6 firewall IPv6 IPv6 IPv6 1425 NAT44 IPv4 IPv4 IPv4 1426 NAT46 IPv4 IPv6 IPv6 1427 NAT64 IPv6 IPv4 IPv4 1428 NPTv6 IPv6 IPv6 IPv6 1430 Figure 5: Address Families with MAP and PEER 1432 10.1. For Operating a Server 1434 A host operating a server (e.g., a web server) listens for traffic on 1435 a port, but the server never initiates traffic from that port. For 1436 this to work across a NAT or a firewall, the host needs to (a) create 1437 a mapping from a public IP address, protocol, and port to itself as 1438 described in Section 11, (b) publish that public IP address, 1439 protocol, and port via some sort of rendezvous server (e.g., DNS, a 1440 SIP message, a proprietary protocol), and (c) ensure non-PCP-speaking 1441 packet filtering allow the incoming traffic (e.g., host-based 1442 firewall or network-based firewall). Publishing the public IP 1443 address and port is out of scope of this specification. To 1444 accomplish (a), the host follows the procedures described in this 1445 section. 1447 As normal, the application needs to begin listening on a port. Then, 1448 the application constructs a PCP message with the MAP Opcode, with 1449 the external address set to the appropriate all-zeroes address, 1450 depending on whether it wants a public IPv4 or IPv6 address. 1452 The following pseudo-code shows how PCP can be reliably used to 1453 operate a server: 1455 /* start listening on the local server port */ 1456 int s = socket(...); 1457 bind(s, ...); 1458 listen(s, ...); 1460 getsockname(s, &internal_sockaddr, ...); 1461 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1463 while (1) 1464 { 1465 /* Note: the "time_to_send_pcp_request()" check below includes: 1466 * 1. Sending the first request 1467 * 2. Retransmitting requests due to packet loss 1468 * 3. Resending a request due to impending lease expiration 1469 * 4. Resending a request due to server state loss 1470 * The PCP packet sent is identical in all cases, apart from the 1471 * Suggested External Address and Port which may differ between 1472 * (1), (2), and (3). 1473 */ 1474 if (time_to_send_pcp_request()) 1475 pcp_send_map_request(internal_sockaddr.sin_port, 1476 internal_sockaddr.sin_addr, 1477 &external_sockaddr, /* will be zero the first time */ 1478 requested_lifetime, &assigned_lifetime); 1480 if (pcp_response_received()) 1481 update_rendezvous_server("Client Ident", external_sockaddr); 1483 if (received_incoming_connection_or_packet()) 1484 process_it(s); 1486 if (other_work_to_do()) 1487 do_it(); 1489 /* ... */ 1491 block_until_we_need_to_do_something_else(); 1492 } 1494 Figure 6: Pseudo-code for using PCP to operate a server 1496 10.2. For Operating a Symmetric Client/Server 1498 A host operating a client and server on the same port (e.g., 1499 Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) 1500 [RFC3581]) first establishes a local listener, (usually) sends the 1501 local and public IP addresses, protocol, and ports to a rendezvous 1502 service (which is out of scope of this document), and initiates an 1503 outbound connection from that same source address and same port. To 1504 accomplish this, the application uses the procedure described in this 1505 section. 1507 An application that is using the same port for outgoing connections 1508 as well as incoming connections MUST first signal its operation of a 1509 server using the PCP MAP Opcode, as described in Section 11, and 1510 receive a positive PCP response before it sends any packets from that 1511 port. 1513 Discussion: In general, a PCP client doesn't know in advance if it 1514 is behind a NAT or firewall. On detecting the host has connected 1515 to a new network, the PCP client can attempt to request a mapping 1516 using PCP, and if that succeeds then the client knows it has 1517 successfully created a mapping. If after multiple retries it has 1518 received no PCP response, then either the client is *not* behind a 1519 NAT or firewall and has unfettered connectivity, or the client 1520 *is* behind a NAT or firewall which doesn't support PCP (and the 1521 client may still have working connectivity by virtue of static 1522 mappings previously created manually by the user). Retransmitting 1523 PCP requests multiple times before giving up and assuming 1524 unfettered connectivity adds delay in that case. Initiating 1525 outbound TCP connections immediately without waiting for PCP 1526 avoids this delay, and will work if the NAT has endpoint- 1527 independent mapping EIM behavior, but may fail if the NAT has 1528 endpoint-dependent mapping EDM behavior. Waiting enough time to 1529 allow an explicit PCP MAP Mapping to be created (if possible) 1530 first ensures that the same External Port will then be used for 1531 all subsequent implicit dynamic mappings (e.g., TCP SYNs) sent 1532 from the specified Internal Address, Protocol, and Port. PCP 1533 supports both EIM and EDM NATs, so clients need to assume they may 1534 be dealing with an EDM NAT. In this case, the client will 1535 experience more reliable connectivity if it attempts explicit PCP 1536 MAP requests first, before initiating any outbound TCP connections 1537 from that Internal Address and Port. See also Section 15.1. 1539 The following pseudo-code shows how PCP can be used to operate a 1540 symmetric client and server: 1542 /* start listening on the local server port */ 1543 int s = socket(...); 1544 bind(s, ...); 1545 listen(s, ...); 1547 getsockname(s, &internal_sockaddr, ...); 1548 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1550 while (1) 1551 { 1552 /* Note: the "time_to_send_pcp_request()" check below includes: 1553 * 1. Sending the first request 1554 * 2. Retransmitting requests due to packet loss 1555 * 3. Resending a request due to impending lease expiration 1556 * 4. Resending a request due to server state loss 1557 * The PCP packet sent is identical in all cases, apart from the 1558 * Suggested External Address and Port which may differ between 1559 * (1), (2), and (3). 1560 */ 1561 if (time_to_send_pcp_request()) 1562 pcp_send_map_request(internal_sockaddr.sin_port, 1563 internal_sockaddr.sin_addr, 1564 &external_sockaddr, /* will be zero the first time */ 1565 requested_lifetime, &assigned_lifetime); 1567 if (pcp_response_received()) 1568 update_rendezvous_server("Client Ident", external_sockaddr); 1570 if (received_incoming_connection_or_packet()) 1571 process_it(s); 1573 if (need_to_make_outgoing_connection()) 1574 make_outgoing_connection(s, ...); 1576 if (data_to_send()) 1577 send_it(s); 1579 if (other_work_to_do()) 1580 do_it(); 1582 /* ... */ 1584 block_until_we_need_to_do_something_else(); 1585 } 1587 Figure 7: Pseudo-code for using PCP to operate a symmetric client/ 1588 server 1590 10.3. For Reducing NAT or Firewall Keepalive Messages 1592 A host operating a client (e.g., XMPP client, SIP client) sends from 1593 a port, and may receive responses, but never accepts incoming 1594 connections from other Remote Peers on this port. It wants to ensure 1595 the flow to its Remote Peer is not terminated (due to inactivity) by 1596 an on-path NAT or firewall. To accomplish this, the application uses 1597 the procedure described in this section. 1599 Middleboxes such as NATs or firewalls need to see occasional traffic 1600 or will terminate their session state, causing application failures. 1601 To avoid this, many applications routinely generate keepalive traffic 1602 for the primary (or sole) purpose of maintaining state with such 1603 middleboxes. Applications can reduce such application keepalive 1604 traffic by using PCP. 1606 Note: For reasons beyond NAT, an application may find it useful to 1607 perform application-level keepalives, such as to detect a broken 1608 path between the client and server, keep state alive on the Remote 1609 Peer, or detect a powered-down client. These keepalives are not 1610 related to maintaining middlebox state, and PCP cannot do anything 1611 useful to reduce those keepalives. 1613 To use PCP for this function, the application first connects to its 1614 server, as normal. Afterwards, it issues a PCP request with the PEER 1615 Opcode as described in Section 12. 1617 The following pseudo-code shows how PCP can be reliably used with a 1618 dynamic socket, for the purposes of reducing application keepalive 1619 messages: 1621 int s = socket(...); 1622 connect(s, &remote_peer, ...); 1624 getsockname(s, &internal_sockaddr, ...); 1625 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1627 while (1) 1628 { 1629 /* Note: the "time_to_send_pcp_request()" check below includes: 1630 * 1. Sending the first request 1631 * 2. Retransmitting requests due to packet loss 1632 * 3. Resending a request due to impending lease expiration 1633 * 4. Resending a request due to server state loss 1634 * The PCP packet sent is identical in all cases, apart from the 1635 * Suggested External Address and Port which may differ between 1636 * (1), (2), and (3). 1637 */ 1638 if (time_to_send_pcp_request()) 1639 pcp_send_peer_request(internal_sockaddr.sin_port, 1640 internal_sockaddr.sin_addr, 1641 &external_sockaddr, /* will be zero the first time */ 1642 remote_peer, requested_lifetime, &assigned_lifetime); 1644 if (data_to_send()) 1645 send_it(s); 1647 if (other_work_to_do()) 1648 do_it(); 1650 /* ... */ 1652 block_until_we_need_to_do_something_else(); 1653 } 1655 Figure 8: Pseudo-code using PCP with a dynamic socket 1657 10.4. For Restoring Lost Implicit TCP Dynamic Mapping State 1659 After a NAT loses state (e.g., because of a crash or power failure), 1660 it is useful for clients to re-establish TCP mappings on the NAT. 1661 This allows servers on the Internet to see traffic from the same IP 1662 address and port, so that sessions can be resumed exactly where they 1663 were left off. This can be useful for long-lived connections (e.g., 1664 instant messaging) or for connections transferring a lot of data 1665 (e.g., FTP). This can be accomplished by first establishing a TCP 1666 connection normally and then sending a PEER request/response and 1667 remembering the External Address and External Port. Later, when the 1668 NAT has lost state, the client can send a PEER request with the 1669 Suggested External Port and Suggested External Address remembered 1670 from the previous session, which will create a mapping in the NAT 1671 that functions exactly as an implicit dynamic mapping. The client 1672 then resumes sending TCP data to the server. 1674 Note: This procedure works well for TCP, provided the NAT creates 1675 a new implicit dynamic outbound mapping only for TCP segments with 1676 the SYN bit set (i.e., the newly-booted NAT drops the re- 1677 transmitted data segments from the client because the NAT does not 1678 have an active mapping for those segments), and if the server is 1679 not sending data that elicits a RST from the NAT. This is not the 1680 case for UDP, because a new UDP mapping will be created (probably 1681 on a different port) as soon as UDP traffic is seen by the NAT. 1683 11. MAP Opcode 1685 This section defines an Opcode which controls forwarding from a NAT 1686 (or firewall) to an Internal Host. 1688 MAP: Create an explicit dynamic mapping between an Internal 1689 Address + Port and an External Address + Port. 1691 PCP Servers SHOULD provide a configuration option to allow 1692 administrators to disable MAP support if they wish. 1694 Mappings created by PCP MAP requests are, by definition, Endpoint 1695 Independent Mappings (EIM) with Endpoint Independent Filtering (EIF) 1696 (unless the FILTER Option is used), even on a NAT that usually 1697 creates Endpoint Dependent Mappings (EDM) or Endpoint Dependent 1698 Filtering (EDF) for outgoing connections, since the purpose of an 1699 (unfiltered) MAP mapping is to receive inbound traffic from any 1700 remote endpoint, not from only one specific remote endpoint. 1702 Note also that all NAT mappings (created by PCP or otherwise) are by 1703 necessity bidirectional and symmetric. For any packet going in one 1704 direction (in or out) that is translated by the NAT, a reply going in 1705 the opposite direction needs to have the corresponding opposite 1706 translation done so that the reply arrives at the right endpoint. 1707 This means that if a client creates a MAP mapping, and then later 1708 sends an outgoing packet using the mapping's internal source port, 1709 the NAT should translate that packet's Internal Address, Protocol, 1710 and Port to the mapping's External Address and Port, so that replies 1711 addressed to the External Address and Port are correctly translated 1712 to the mapping's Internal Address and Port. 1714 On Operating Systems that allow multiple listening servers to bind to 1715 the same internal protocol and port, servers MUST ensure that they 1716 have exclusive use of that internal protocol and port (e.g., by 1717 binding the port using INADDR_ANY, or using SO_EXCLUSIVEADDRUSE or 1718 similar) before sending their PCP MAP request, to ensure that no 1719 other PCP clients on the same machine are also listening on the same 1720 internal protocol and internal port. 1722 As a side-effect of creating a mapping, ICMP messages associated with 1723 the mapping MUST be forwarded (and also translated, if appropriate) 1724 for the duration of the mapping's lifetime. This is done to ensure 1725 that ICMP messages can still be used by hosts, without application 1726 programmers or PCP client implementations needing to use PCP 1727 separately to create ICMP mappings for those flows. 1729 The operation of the MAP Opcode is described in this section. 1731 11.1. MAP Operation Packet Formats 1733 The MAP Opcode has a similar packet layout for both requests and 1734 responses. If the Assigned External IP address and Assigned External 1735 Port in the PCP response always match the Internal IP Address, 1736 Protocol, and Port in the PCP request, then the functionality is 1737 purely a firewall; otherwise it pertains to a network address 1738 translator which might also perform firewall-like functions. 1740 The following diagram shows the format of the Opcode-specific 1741 information in a request for the MAP Opcode. 1743 0 1 2 3 1744 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 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | | 1747 | Mapping Nonce (96 bits) | 1748 | | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Protocol | Reserved (24 bits) | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Internal Port | Suggested External Port | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | | 1755 | Suggested External IP Address (128 bits) | 1756 | | 1757 | | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 Figure 9: MAP Opcode Request 1761 These fields are described below: 1763 Requested lifetime (in common header): Requested lifetime of this 1764 mapping, in seconds. The value 0 indicates "delete". 1766 Mapping Nonce: Random value chosen by the PCP client. 1768 Protocol: Upper-layer protocol associated with this Opcode. Values 1769 are taken from the IANA protocol registry [proto_numbers]. For 1770 example, this field contains 6 (TCP) if the Opcode is intended to 1771 create a TCP mapping. The value 0 has a special meaning for 'all 1772 protocols'. 1774 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1775 when received. 1777 Internal Port: Internal port for the mapping. The value 0 indicates 1778 "all ports", and is legal when the lifetime is zero (a delete 1779 request), if the Protocol does not use 16-bit port numbers, or the 1780 Protocol is 0 (meaning 'all protocols') 1782 Suggested External Port: Suggested external port for the mapping. 1783 This is useful for refreshing a mapping, especially after the PCP 1784 server loses state. If the PCP client does not know the external 1785 port, or does not have a preference, it MUST use 0. 1787 Suggested External IP Address: Suggested external IPv4 or IPv6 1788 address. This is useful for refreshing a mapping, especially 1789 after the PCP server loses state. If the PCP client does not know 1790 the external address, or does not have a preference, it MUST use 1791 the address-family-specific all-zeroes address (see Section 5). 1793 The internal address for the request is the source IP address of the 1794 PCP request message itself, unless the THIRD_PARTY Option is used. 1796 The following diagram shows the format of Opcode-specific information 1797 in a response packet for the MAP Opcode: 1799 0 1 2 3 1800 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 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | | 1803 | Mapping Nonce (96 bits) | 1804 | | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Protocol | Reserved (24 bits) | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Internal Port | Assigned External Port | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | | 1811 | Assigned External IP Address (128 bits) | 1812 | | 1813 | | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 Figure 10: MAP Opcode Response 1818 These fields are described below: 1820 Lifetime (in common header): On an error response, this indicates 1821 how long clients should assume they'll get the same error response 1822 from the PCP server if they repeat the same request. On a success 1823 response, this indicates the lifetime for this mapping, in 1824 seconds. 1826 Mapping Nonce: Copied from the request. 1828 Protocol: Copied from the request. 1830 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1831 when received. 1833 Internal Port: Copied from the request. 1835 Assigned External Port: On a success response, this is the assigned 1836 external port for the mapping. On an error response, the 1837 Suggested External Port is copied from the request. 1839 Assigned External IP Address: On a success response, this is the 1840 assigned external IPv4 or IPv6 address for the mapping. An IPv4 1841 address is encoded using IPv4-mapped IPv6 address. On an error 1842 response, the Suggested External IP Address is copied from the 1843 request. 1845 11.2. Generating a MAP Request 1847 This section and Section 11.5 describe the operation of a PCP client 1848 when sending requests with the MAP Opcode. 1850 The request MAY contain values in the Suggested External Port and 1851 Suggested External IP Address fields. This allows the PCP client to 1852 attempt to rebuild lost state on the PCP server, which improves the 1853 chances of existing connections surviving, and helps the PCP client 1854 avoid having to change information maintained at its rendezvous 1855 server. Of course, due to other activity on the network (e.g., by 1856 other users or network renumbering), the PCP server may not be able 1857 to grant the suggested External IP Address, Protocol, and Port, and 1858 in that case it will assign a different External IP Address and Port. 1860 If the Protocol does not use 16-bit port numbers (e.g., RSVP), the 1861 port number MUST be 0. This will cause all traffic matching that 1862 protocol to be mapped. 1864 If the client wants all protocols mapped it uses Protocol 0 (zero) 1865 and Internal Port 0 (zero). 1867 The Mapping Nonce value is randomly chosen by the PCP client, and is 1868 used as part of the validation of PCP responses (see below). 1870 11.2.1. Renewing a Mapping 1872 An existing mapping can have its lifetime extended by the PCP client. 1873 To do this, the PCP client sends a new MAP request indicating the 1874 internal port. The PCP MAP request SHOULD also include the currently 1875 assigned external IP address and port in the Suggested External IP 1876 address and Suggested External Port fields, so if the PCP server has 1877 lost state it can recreate the lost mapping with the same parameters. 1879 The PCP client SHOULD renew the mapping before its expiry time, 1880 otherwise it will be removed by the PCP server (see Section 11.5). 1881 To reduce the risk of inadvertent synchronization of renewal 1882 requests, a random jitter component should be included. It is 1883 RECOMMENDED that PCP clients send a single renewal request packet at 1884 a time chosen with uniform random distribution in the range 1/2 to 1885 5/8 of expiration time. If no SUCCESS response is received, then the 1886 next renewal request should be sent 3/4 to 3/4 + 1/16 to expiration, 1887 and then another 7/8 to 7/8 + 1/32 to expiration, and so on, subject 1888 to the constraint that renewal requests MUST NOT be sent less than 1889 four seconds apart (a PCP client MUST NOT send a flood of ever- 1890 closer-together requests in the last few seconds before a mapping 1891 expires). 1893 11.3. Processing a MAP Request 1895 This section and Section 11.5 describe the operation of a PCP server 1896 when processing a request with the MAP Opcode. Processing SHOULD be 1897 performed in the order of the following paragraphs. 1899 The Protocol, Internal Port, and Mapping Nonce fields from the MAP 1900 request are copied into the MAP response. If present and processed 1901 by the PCP server the THIRD_PARTY Option is also copied into the MAP 1902 response. 1904 If the Requested Lifetime is non-zero, it indicates a request to 1905 create a mapping or extend the lifetime of an existing mapping. If 1906 the PCP server or PCP-controlled device does not support the 1907 Protocol, it MUST generate an UNSUPP_PROTOCOL error. If the 1908 requested Lifetime is non-zero, the Internal Port is zero, and the 1909 Protocol is non-zero, it indicates a request to map all incoming 1910 traffic for that entire Protocol. If this request cannot be 1911 fulfilled in its entirety, the error UNSUPP_PROTOCOL MUST be 1912 returned. If the requested Lifetime is non-zero, the Internal Port 1913 is zero, and the Protocol is zero, it indicates a request to map all 1914 incoming traffic for all protocols. If this request cannot be 1915 fulfilled in its entirety, the error UNSUPP_PROTOCOL MUST be 1916 returned. If the Protocol is zero but the Internal Port is non-zero, 1917 the error MALFORMED_REQUEST MUST be returned. 1919 If the requested lifetime is zero, it indicates a request to delete 1920 an existing mapping or set of mappings. Processing of the lifetime 1921 is described in Section 11.5. 1923 The PCP server only needs to remember one Mapping Nonce value for 1924 each mapping (that is, the most recent Mapping Nonce value overwrites 1925 the previous Mapping Nonce value). 1927 If an Option with value less than 128 exists (i.e., mandatory to 1928 process) but that Option does not make sense (e.g., the 1929 PREFER_FAILURE Option is included in a request with lifetime=0), the 1930 request is invalid and generates a MALFORMED_OPTION error. 1932 If the PCP-controlled device is stateless (that is, it does not 1933 establish any per-flow state, and simply rewrites the address and/or 1934 port in a purely algorithmic fashion), the PCP server simply returns 1935 an answer indicating the external IP address and port yielded by this 1936 stateless algorithmic translation. This allows the PCP client to 1937 learn its external IP address and port as seen by remote peers. 1938 Examples of stateless translators include stateless NAT64, 1:1 NAT44, 1939 and NPTv6 [RFC6296], all of which modify addresses but not port 1940 numbers. 1942 It is possible that a mapping might already exist for a requested 1943 Internal Address, Protocol, and Port. If so, the PCP server takes 1944 the following actions: 1946 1. If the MAP request contains the PREFER_FAILURE Option, but the 1947 Suggested External Address and Port do not match the External 1948 Address and Port of the existing mapping, the PCP server MUST 1949 return CANNOT_PROVIDE_EXTERNAL. 1951 2. If the existing mapping is static (created outside of PCP), the 1952 PCP server MUST return the External Address and Port of the 1953 existing mapping in its response and SHOULD indicate a Lifetime 1954 of 2^32-1 seconds, regardless of the Suggested External Address 1955 and Port in the request. 1957 3. If the existing mapping is explicit dynamic inbound (created by a 1958 previous MAP request), the PCP server MUST return the existing 1959 External Address and Port in its response, regardless of the 1960 Suggested External Address and Port in the request. 1961 Additionally, the PCP server MUST update the lifetime of the 1962 existing mapping, in accordance with section 10.5. 1964 4. If the existing mapping is dynamic outbound (created by outgoing 1965 traffic or a previous PEER request), the PCP server SHOULD create 1966 a new explicit inbound mapping, replicating the ports and 1967 addresses from the outbound mapping (but the outbound mapping 1968 continues to exist, and remains in effect if the explicit inbound 1969 mapping is later deleted). 1971 The PCP server MUST NOT create mappings for the PCP ports themselves 1972 (5350 and 5351), and SHOULD have a policy control to deny mappings 1973 for other ports. In these cases, the error NOT_AUTHORIZED SHOULD be 1974 returned. 1976 If no mapping exists for the Internal Address, Protocol, and Port, 1977 and the PCP server is able to create a mapping using the Suggested 1978 External Address and Port, it SHOULD do so. This is beneficial for 1979 re-establishing state lost in the PCP server (e.g., due to a reboot). 1980 If the PCP server cannot assign the Suggested External Address and 1981 Port but can assign some other External Address and Port (and the 1982 request did not contain the PREFER_FAILURE Option) the PCP server 1983 MUST do so and return the newly assigned External Address and Port in 1984 the response. Cases where a PCP server or PCP-controlled device 1985 cannot assign the Suggested External Address and Port include: 1987 o The Suggested External Address and Port is already assigned to 1988 another existing explicit, implicit, or static mapping (i.e., is 1989 already forwarding traffic to some other internal address, 1990 protocol, and port). 1992 o The Suggested External Address and Port is already used by the NAT 1993 gateway for one of its own services (e.g., port 80 for the NAT 1994 gateway's own configuration pages). 1996 o The Suggested External Address and Port is otherwise prohibited by 1997 the PCP server's policy. 1999 o The Suggested External Address, protocol, or port is invalid 2000 (e.g., 127.0.0.1, ::1, multicast address, or the port is not valid 2001 for the indicated protocol). 2003 o The Suggested External Address does not belong to the NAT gateway. 2005 o The Suggested External Address is not configured to be used as an 2006 external address of the firewall or NAT gateway. 2008 o The PREFER_FAILURE option is included in the request and the 2009 Suggested External Address and Port are not assignable to the PCP 2010 client, which returns the CANNOT_PROVIDE_EXTERNAL error. 2012 By default, a PCP-controlled device MUST NOT create mappings for a 2013 protocol not indicated in the request. For example, if the request 2014 was for a TCP mapping, a UDP mapping MUST NOT be created. 2016 Mappings typically consume state on the PCP-controlled device, and it 2017 is RECOMMENDED that a per-host and/or per-subscriber limit be 2018 enforced by the PCP server to prevent exhausting the mapping state. 2019 If this limit is exceeded, the result code USER_EX_QUOTA is returned. 2021 If all of the preceding operations were successful (did not generate 2022 an error response), then the requested mapping is created or 2023 refreshed as described in the request and a SUCCESS response is 2024 built. 2026 11.4. Processing a MAP Response 2028 This section describes the operation of the PCP client when it 2029 receives a PCP response for the MAP Opcode. 2031 After performing common PCP response processing, the response is 2032 further matched with a previously-sent MAP request by comparing the 2033 Internal IP Address (the destination IP address of the PCP response, 2034 or other IP address specified via the THIRD_PARTY option), the 2035 Protocol, the Internal Port, and the Mapping Nonce. Other fields are 2036 not compared, because the PCP server sets those fields. Note that if 2037 the PCP server supports Mapping Update (Section 14.2) the PCP server 2038 will send additional MAP responses if the mapping changes (e.g., due 2039 to IP renumbering). 2041 On a success response, the PCP client can use the External IP Address 2042 and Port as needed. Typically the PCP client will communicate the 2043 External IP Address and Port to another host on the Internet using an 2044 application-specific rendezvous mechanism such as DNS SRV records. 2046 As long as renewal is desired, the PCP client MUST also set a timer 2047 or otherwise schedule an event to renew the mapping before its 2048 lifetime expires. Renewing a mapping is performed by sending another 2049 MAP request, exactly as described in Section 11.2, except that the 2050 Suggested External Address and Port SHOULD be set to the values 2051 received in the response. From the PCP server's point of view a MAP 2052 request to renew a mapping is identical to a MAP request to create a 2053 new mapping, and is handled identically. Indeed, in the event of PCP 2054 server state loss, a renewal request from a PCP client will appear to 2055 the server to be a request to create a new mapping, with a particular 2056 Suggested External Address and Port, which happens to be what the PCP 2057 server previously assigned. See also Section 15.3.1. 2059 On an error response, the client SHOULD NOT repeat the same request 2060 to the same PCP server within the lifetime returned in the response. 2062 11.5. Mapping Lifetime and Deletion 2064 The PCP client requests a certain lifetime, and the PCP server 2065 responds with the assigned lifetime. The PCP server MAY grant a 2066 lifetime smaller or larger than the requested lifetime. The PCP 2067 server SHOULD be configurable for permitted minimum and maximum 2068 lifetime, and the RECOMMENDED values are 120 seconds for the minimum 2069 value and 24 hours for the maximum. It is RECOMMENDED that the 2070 server be configurable to restrict lifetimes to less than 24 hours, 2071 because mappings will consume ports even if the Internal Host is no 2072 longer interested in receiving the traffic or is no longer connected 2073 to the network. These recommendations are not strict, and 2074 deployments should evaluate the trade offs to determine their own 2075 minimum and maximum lifetime values. 2077 Once a PCP server has responded positively to a MAP request for a 2078 certain lifetime, the port mapping is active for the duration of the 2079 lifetime unless the lifetime is reduced by the PCP client (to a 2080 shorter lifetime or to zero) or until the PCP server loses its state 2081 (e.g., crashes). Mappings created by PCP MAP requests are not 2082 special or different from mappings created in other ways. In 2083 particular, it is implementation-dependent if outgoing traffic 2084 extends the lifetime of such mappings beyond the PCP-assigned 2085 lifetime. PCP clients MUST NOT depend on this behavior to keep 2086 mappings active, and MUST explicitly renew their mappings as required 2087 by the Lifetime field in PCP response messages. 2089 Upon receipt of a MAP or PEER response with an absurdly long Assigned 2090 Lifetime the PCP client SHOULD behave as if it received a more sane 2091 value (e.g., 24 hours), and renew the mapping accordingly, to ensure 2092 that if the static mapping is removed the client will continue to 2093 maintain the mapping it desires. 2095 If the requested lifetime is zero then: 2097 o If both the internal port and protocol are non-zero, it indicates 2098 a request to delete the indicated mapping immediately. 2100 o If both the internal port and protocol are zero, it indicates a 2101 request to delete all mappings for this Internal Address for all 2102 transport protocols. This is useful when a host reboots or joins 2103 a new network, to clear out prior stale state from the NAT gateway 2104 before beginning to install new mappings. 2106 o If the internal port is zero and the protocol is non-zero, it 2107 indicates a request to delete a previous 'wildcard' (all-ports) 2108 mapping for that protocol. 2110 o If the internal port is non-zero and the protocol is zero, then 2111 the request is invalid and the PCP Server MUST return a 2112 MALFORMED_REQUEST error to the client. 2114 In requests where the requested Lifetime is 0, the Suggested External 2115 Address and Suggested External Port fields MUST be set to zero on 2116 transmission and MUST be ignored on reception, and these fields MUST 2117 be copied into the Assigned External IP Address and Assigned External 2118 Port of the response. 2120 PCP PEER requests cannot delete or shorten lifetimes of any mappings. 2121 If a PEER request matches an existing mapping, and the requested 2122 lifetime is less than that of the existing mapping, the PCP server 2123 returns SUCCESS with the lifetime of the existing mapping. 2125 PCP MAP requests can only delete or shorten lifetimes of MAP-created 2126 mappings. If the PCP client attempts to delete a static mapping 2127 (i.e., a mapping created outside of PCP itself), or an outbound 2128 (implicit or PEER-created) mapping, the PCP server MUST return 2129 NOT_AUTHORIZED. If the PCP client attempts to delete a mapping that 2130 does not exist, the SUCCESS result code is returned (this is 2131 necessary for PCP to return the same response for the same request). 2132 If the PCP MAP request was for port=0 (indicating 'all ports'), the 2133 PCP server deletes all of the explicit dynamic mappings it can (but 2134 not any implicit or static mappings), and returns a SUCCESS response. 2135 If the deletion request was properly formatted and successfully 2136 processed, a SUCCESS response is generated with lifetime of 0 and the 2137 server copies the protocol and internal port number from the request 2138 into the response. An inbound mapping (i.e., static mapping or MAP- 2139 created dynamic mapping) MUST NOT have its lifetime reduced by 2140 transport protocol messages (e.g., TCP RST, TCP FIN). Note the 2141 THIRD_PARTY Option, if authorized, can also delete PCP-created 2142 mappings (see Section 13.1). 2144 An application that forgets its PCP-assigned mappings (e.g., the 2145 application or OS crashes) will request new PCP mappings. This may 2146 consume port mappings, if the application binds to a different 2147 Internal Port every time it runs. The application will also likely 2148 initiate new implicit dynamic outbound mappings without using PCP, 2149 which will also consume port mappings. If there is a port mapping 2150 quota for the Internal Host, frequent restarts such as this may 2151 exhaust the quota. PCP provides some protections against such port 2152 consumption: When a PCP client first acquires a new IP address (e.g., 2153 reboots or joins a new network), it SHOULD remove mappings that may 2154 already be instantiated for that new Internal Address. To do this, 2155 the PCP client sends a MAP request with protocol, internal port, and 2156 lifetime set to 0. Some port mapping APIs (e.g., the 2157 "DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on 2158 Mac OS X, iOS, Windows, Linux [Bonjour]) automatically monitor for 2159 process exit (including application crashes) and automatically send 2160 port mapping deletion requests if the process that requested them 2161 goes away without explicitly relinquishing them. 2163 To reduce unwanted traffic and data corruption, External UDP and TCP 2164 ports SHOULD NOT be re-used for an interval (TIME_WAIT interval 2165 [RFC0793]). However, the PCP server SHOULD allow the previous user 2166 of an External Port to re-acquire the same port during that interval. 2168 11.6. Address Change Events 2170 A customer premises router might obtain a new External IP address, 2171 for a variety of reasons including a reboot, power outage, DHCP lease 2172 expiry, or other action by the ISP. If this occurs, traffic 2173 forwarded to the host's previous address might be delivered to 2174 another host which now has that address. This affects both implicit 2175 dynamic mappings and explicit dynamic mappings. However, this same 2176 problem already occurs today when a host's IP address is re-assigned, 2177 without PCP and without an ISP-operated CGN. The solution is the 2178 same as today: the problems associated with host renumbering are 2179 caused by host renumbering and are eliminated if host renumbering is 2180 avoided. PCP defined in this document does not provide machinery to 2181 reduce the host renumbering problem. 2183 When an Internal Host changes its IP address (e.g., by having a 2184 different address assigned by the DHCP server) the NAT (or firewall) 2185 will continue to send traffic to the old IP address. Typically, the 2186 Internal Host will no longer receive traffic sent to that old IP 2187 address. Assuming the Internal Host wants to continue receiving 2188 traffic, it needs to install new mappings for its new IP address. 2189 The suggested external port field will not be fulfilled by the PCP 2190 server, in all likelihood, because it is still being forwarded to the 2191 old IP address. Thus, a mapping is likely to be assigned a new 2192 external port number and/or public IP address. Note that such host 2193 renumbering is not expected to happen routinely on a regular basis 2194 for most hosts, since most hosts renew their DHCP leases before they 2195 expire (or re-request the same address after reboot) and most DHCP 2196 servers honor such requests and grant the host the same address it 2197 was previously using before the reboot. 2199 A host might gain or lose interfaces while existing mappings are 2200 active (e.g., Ethernet cable plugged in or removed, joining/leaving a 2201 WiFi network). Because of this, if the PCP client is sending a PCP 2202 request to maintain state in the PCP server, it SHOULD ensure those 2203 PCP requests continue to use the same interface (e.g., when 2204 refreshing mappings). If the PCP client is sending a PCP request to 2205 create new state in the PCP server, it MAY use a different source 2206 interface or different source address. 2208 11.7. Learning the External IP Address Alone 2210 NAT-PMP [I-D.cheshire-nat-pmp] includes a mechanism to allow clients 2211 to learn the External IP Address alone, without also requesting a 2212 port mapping. In the case of PCP, this operation no longer makes 2213 sense. PCP supports Large Scale NATs (CGN) which may have a pool of 2214 External IP Addresses, not just one. A client may not be assigned 2215 any particular External IP Address from that pool until it has at 2216 least one implicit, explicit or static port mapping, and even then 2217 only for as long as that mapping remains valid. Client software that 2218 just wishes to display the user's External IP Address for cosmetic 2219 purposes can achieve that by requesting a short-lived mapping (e.g., 2220 to the Discard service (TCP/9 or UDP/9) or some other port) and then 2221 displaying the resulting External IP Address. However, once that 2222 mapping expires a subsequent implicit or explicit dynamic mapping 2223 might be mapped to a different external IP address. 2225 12. PEER Opcode 2227 This section defines an Opcode for controlling dynamic mappings. 2229 PEER: Create a new dynamic outbound mapping to a remote peer's IP 2230 address and port, or extend the lifetime of an existing 2231 outbound mapping. 2233 The use of this Opcodes is described in this section. 2235 PCP Servers SHOULD provide a configuration option to allow 2236 administrators to disable PEER support if they wish. 2238 Because a mapping created or managed by PEER behaves almost exactly 2239 like an implicit dynamic mapping created as a side-effect of a packet 2240 (e.g., TCP SYN) sent by the host, mappings created or managed using 2241 PCP PEER requests may be Endpoint Independent Mappings (EIM) or 2242 Endpoint Dependent Mappings (EDM), with Endpoint Independent 2243 Filtering (EIF) or Endpoint Dependent Filtering (EDF), consistent 2244 with the existing behavior of the NAT gateway or firewall in question 2245 for implicit outbound mappings it creates automatically as a result 2246 of observing outgoing traffic from Internal Hosts. 2248 12.1. PEER Operation 2250 The PEER Opcode allows a PCP client to create a new explicit dynamic 2251 outbound mapping (which functions similarly to an outbound mapping 2252 created implicitly when a host sends an outbound TCP SYN) or to 2253 extend the lifetime of an existing outbound mapping. 2255 The following diagram shows the Opcode layout for the PEER Opcode. 2256 This packet format is aligned with the response packet format: 2258 0 1 2 3 2259 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 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | | 2262 | Mapping Nonce (96 bits) | 2263 | | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | Protocol | Reserved (24 bits) | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | Internal Port | Suggested External Port | 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | | 2270 | Suggested External IP Address (128 bits) | 2271 | | 2272 | | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Remote Peer Port | Reserved (16 bits) | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | | 2277 | Remote Peer IP Address (128 bits) | 2278 | | 2279 | | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 Figure 11: PEER Opcode Request 2284 These fields are described below: 2286 Requested Lifetime (in common header): Requested lifetime of this 2287 mapping, in seconds. Note that it is not possible to reduce the 2288 lifetime of a mapping (or delete it, with requested lifetime=0) 2289 using PEER. 2291 Mapping Nonce: Random value chosen by the PCP client. 2293 Protocol: Upper-layer protocol associated with this Opcode. Values 2294 are taken from the IANA protocol registry [proto_numbers]. For 2295 example, this field contains 6 (TCP) if the Opcode is describing a 2296 TCP mapping. 2298 Reserved: 24 reserved bits, MUST be set to 0 on transmission and 2299 MUST be ignored on reception. 2301 Internal Port: Internal port for the mapping. 2303 Suggested External Port: Suggested external port for the mapping. 2304 If the PCP client does not know the external port, or does not 2305 have a preference, it MUST use 0. 2307 Suggested External IP Address: Suggested External IP Address for the 2308 mapping. If the PCP client does not know the external address, or 2309 does not have a preference, it MUST use the address-family- 2310 specific all-zeroes address (see Section 5). 2312 Remote Peer Port: Remote peer's port for the mapping. 2314 Reserved: 16 reserved bits, MUST be set to 0 on transmission and 2315 MUST be ignored on reception. 2317 Remote Peer IP Address: Remote peer's IP address from the 2318 perspective of the PCP client, so that the PCP client does not 2319 need to concern itself with NAT64 or NAT46 (which both cause the 2320 client's idea of the remote peer's IP address to differ from the 2321 remote peer's actual IP address). This field allows the PCP 2322 client and PCP server to disambiguate multiple connections from 2323 the same port on the Internal Host to different servers. An IPv6 2324 address is represented directly, and an IPv4 address is 2325 represented using the IPv4-mapped address syntax (Section 5). 2327 When attempting to re-create a lost mapping, the Suggested External 2328 IP Address and Port are set to the External IP Address and Port 2329 fields received in a previous PEER response from the PCP server. On 2330 an initial PEER request, the External IP Address and Port are set to 2331 zero. 2333 Note that semantics similar to the PREFER_FAILURE option are 2334 automatically implied by PEER requests. If the Suggested External IP 2335 Address or Suggested External Port fields are non-zero, and the PCP 2336 server is unable to honor the Suggested External IP Address, 2337 Protocol, or Port, then the PCP server MUST return a 2338 CANNOT_PROVIDE_EXTERNAL error response. The PREFER_FAILURE Option is 2339 neither required nor allowed in PEER requests, and if PCP server 2340 receives a PEER request containing the PREFER_FAILURE Option it MUST 2341 return a MALFORMED_REQUEST error response. 2343 The following diagram shows the Opcode response for the PEER Opcode: 2345 0 1 2 3 2346 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 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | | 2349 | Mapping Nonce (96 bits) | 2350 | | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Protocol | Reserved (24 bits) | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | Internal Port | Assigned External Port | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | | 2357 | Assigned External IP Address (128 bits) | 2358 | | 2359 | | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | Remote Peer Port | Reserved (16 bits) | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | | 2364 | Remote Peer IP Address (128 bits) | 2365 | | 2366 | | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 Figure 12: PEER Opcode Response 2371 Lifetime (in common header): On a success response, this indicates 2372 the lifetime for this mapping, in seconds. On an error response, 2373 this indicates how long clients should assume they'll get the same 2374 error response from the PCP server if they repeat the same 2375 request. 2377 Mapping Nonce: Copied from the request. 2379 Protocol: Copied from the request. 2381 Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST 2382 be ignored on reception. 2384 Internal Port: Copied from request. 2386 Assigned External Port: On a success response, this is the assigned 2387 external port for the mapping. On an error response, the 2388 Suggested External Port is copied from the request. 2390 Assigned External IP Address: On a success response, this is the 2391 assigned external IPv4 or IPv6 address for the mapping. On an 2392 error response, the Suggested External IP Address is copied from 2393 the request. 2395 Remote Peer port: Copied from request. 2397 Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST 2398 be ignored on reception. 2400 Remote Peer IP Address: Copied from the request. 2402 12.2. Generating a PEER Request 2404 This section describes the operation of a client when generating a 2405 message with the PEER Opcode. 2407 The PEER Opcode MAY be sent before or after establishing bi- 2408 directional communication with the remote peer. 2410 If sent before, this is considered a PEER-created mapping which 2411 creates a new dynamic outbound mapping in the PCP-controlled device. 2412 This is useful for restoring a mapping after a NAT has lost its 2413 mapping state (e.g., due to a crash). 2415 If sent after, this allows the PCP client to learn the IP address, 2416 port, and lifetime of the assigned External Address and Port for the 2417 existing implicit dynamic outbound mapping, and potentially to extend 2418 this lifetime (for the purpose described in Section 10.3). 2420 The Mapping Nonce value is randomly chosen by the PCP client, and is 2421 used as part of the validation of PCP responses (see below). 2423 The PEER Opcode contains a Remote Peer Address field, which is always 2424 from the perspective of the PCP client. Note that when the PCP- 2425 controlled device is performing address family translation (NAT46 or 2426 NAT64), the remote peer address from the perspective of the PCP 2427 client is different from the remote peer address on the other side of 2428 the address family translation device. 2430 12.3. Processing a PEER Request 2432 This section describes the operation of a server when receiving a 2433 request with the PEER Opcode. Processing SHOULD be performed in the 2434 order of the following paragraphs. 2436 The following fields from a PEER request are copied into the 2437 response: Protocol, Internal Port, Remote Peer IP Address, Remote 2438 Peer Port, and Mapping Nonce. The PCP server only needs to remember 2439 one Mapping Nonce value for each mapping (that is, the most recent 2440 Mapping Nonce value overwrites the previous Mapping Nonce value). 2442 When an implicit dynamic mapping is created, some NATs and firewalls 2443 validate destination addresses and will not create an implicit 2444 dynamic mapping if the destination address is invalid (e.g., 2445 127.0.0.1). If a PCP-controlled device does such validation for 2446 implicit dynamic mappings, it SHOULD also do a similar validation of 2447 the Remote Peer IP Address, Protocol, and Port for PEER-created 2448 explicit dynamic mappings. If the validation determines the Remote 2449 Peer IP Address of a PEER request is invalid, then no mapping is 2450 created, and a MALFORMED_REQUEST error result is returned. 2452 On receiving the PEER Opcode, the PCP server examines the mapping 2453 table. If the requested mapping does not yet exist, and the 2454 Suggested External Address and Port can be honored, the mapping is 2455 created. By having PEER create such a mapping, we avoid a race 2456 condition between the PEER request or the initial outgoing packet 2457 arriving at the NAT or firewall device first, and allow PEER to be 2458 used to recreate an outbound dynamic mapping (see last paragraph of 2459 Section 15.3.1). Thereafter, this PEER-created mapping is treated as 2460 if it was an implicit dynamic outbound mapping (e.g., as if the PCP 2461 client sent a TCP SYN) and a Lifetime appropriate to such a mapping 2462 is returned (note: on many NATs and firewalls, such mapping lifetimes 2463 are very short until the bi-directional traffic is seen by the NAT or 2464 firewall). If the requested mapping does not yet exist, and 2465 Suggested External Address, Protocol, and Port cannot be honored, the 2466 error CANNOT_PROVIDE_EXTERNAL is returned. If the requested mapping 2467 already exists, it is a request to modify the lifetime of that 2468 existing mapping. 2470 The PEER Opcode can extend the lifetime of an existing dynamic 2471 outbound mapping. The PCP server may grant the client's requested 2472 lifetime, or may grant a value higher or lower, depending on local 2473 policy. The PEER Opcode MUST NOT ever reduce the lifetime of an 2474 existing outbound mapping. If the Requested Lifetime is less than 2475 the lifetime of the existing mapping, it is treated as a request for 2476 the lifetime of the mapping (this can be used to query the lifetime 2477 of an existing mapping). 2479 If all of the preceding operations were successful (did not generate 2480 an error response), then a SUCCESS response is generated, with the 2481 Lifetime field containing the lifetime of the mapping. 2483 If a PEER-created or PEER-managed mapping is not renewed using PEER, 2484 then it reverts to the NAT's usual behavior for implicit mappings, 2485 e.g., continued outbound traffic keeps the mapping alive, as per the 2486 NAT or firewall device's existing policy. A PEER-created or PEER- 2487 managed mapping may be terminated at any time by action of the TCP 2488 client or server (e.g., due to TCP FIN or TCP RST), as per the NAT or 2489 firewall device's existing policy. 2491 12.4. Processing a PEER Response 2493 This section describes the operation of a client when processing a 2494 response with the PEER Opcode. 2496 After performing common PCP response processing, the response is 2497 further matched with an outstanding PEER request by comparing the 2498 Internal IP Address (the destination IP address of the PCP response, 2499 or other IP address specified via the THIRD_PARTY option), the 2500 Protocol, the Internal Port, the Remote Peer Address, the Remote Peer 2501 Port, and the Mapping Nonce. Other fields are not compared, because 2502 the PCP server sets those fields to provide information about the 2503 mapping created by the Opcode. Note that if the PCP server supports 2504 Mapping Update (Section 14.2) the PCP server will send additional 2505 PEER responses if the mapping changes (e.g., due to IP renumbering). 2507 On a successful response, the application can use the assigned 2508 lifetime value to reduce its frequency of application keepalives for 2509 that particular NAT mapping. Of course, there may be other reasons, 2510 specific to the application, to use more frequent application 2511 keepalives. For example, the PCP assigned lifetime could be one hour 2512 but the application may want to maintain state on its server (e.g., 2513 "busy" / "away") more frequently than once an hour. If the response 2514 indicates an unexpected IP address or port (e.g., due to IP 2515 renumbering), the PCP client will want to re-establish its connection 2516 to its remote server. 2518 If the PCP client wishes to keep this mapping alive beyond the 2519 indicated lifetime, it MAY issue a new PCP request prior to the 2520 expiration, or it MAY rely on continued inside-to-outside traffic to 2521 ensure the mapping will continue to exist. See Section 11.2.1 for 2522 recommended renewal timing. 2524 Note: implementations need to expect the PEER response may contain 2525 an External IP Address with a different family than the Remote 2526 Peer IP Address, e.g., when NAT64 or NAT46 are being used. 2528 13. Options for MAP and PEER Opcodes 2530 This section describes Options for the MAP and PEER Opcodes. These 2531 Options MUST NOT appear with other Opcodes, unless permitted by those 2532 other Opcodes. 2534 13.1. THIRD_PARTY Option for MAP and PEER Opcodes 2536 This Option is used when a PCP client wants to control a mapping to 2537 an Internal Host other than itself. This is used with both MAP and 2538 PEER Opcodes. 2540 Due to security concerns with the THIRD_PARTY option, this Option 2541 MUST NOT be implemented or used unless the network on which the PCP 2542 messages are to be sent is fully trusted. For example if access 2543 control lists are installed on the PCP client, PCP server, and the 2544 network between them, so those ACLs allow only communications from a 2545 trusted PCP client to the PCP server. 2547 A management device would use this Option to control a PCP server on 2548 behalf of users. For example, a management device located in a 2549 network operations center, which presents a user interface to end 2550 users or to network operations staff, and issues PCP requests with 2551 the THIRD_PARTY option to the appropriate PCP server. 2553 The THIRD_PARTY Option is formatted as follows: 2555 0 1 2 3 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Option Code=1 | Reserved | Option Length=16 | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | | 2561 | Internal IP Address (128 bits) | 2562 | | 2563 | | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 Figure 13: THIRD_PARTY Option 2568 The fields are described below: 2570 Internal IP Address: Internal IP address for this mapping. 2572 Option Name: THIRD_PARTY 2573 Number: 1 2574 Purpose: Indicates the MAP or PEER request is for a host other 2575 than the host sending the PCP Option. 2576 Valid for Opcodes: MAP, PEER 2577 Length: 16 octets 2578 May appear in: request. May appear in response only if it 2579 appeared in the associated request. 2581 Maximum occurrences: 1 2583 A THIRD_PARTY Option MUST NOT contain the same address as the source 2584 address of the packet. A PCP server receiving a THIRD_PARTY Option 2585 specifying the same address as the source address of the packet MUST 2586 return a MALFORMED_REQUEST result code. This is because many PCP 2587 servers may not implement the THIRD_PARTY Option at all, and a client 2588 using the THIRD_PARTY Option to specify the same address as the 2589 source address of the packet will cause mapping requests to fail 2590 where they would otherwise have succeeded. 2592 A PCP server MAY be configured to permit or to prohibit the use of 2593 the THIRD_PARTY Option. If this Option is permitted, properly 2594 authorized clients may perform these operations on behalf of other 2595 hosts. If this Option is prohibited, and a PCP server receives a PCP 2596 MAP request with a THIRD_PARTY Option, it MUST generate a 2597 UNSUPP_OPTION response. 2599 It is RECOMMENDED that customer premises equipment implementing a PCP 2600 Server be configured to prohibit third party mappings by default. 2601 With this default, if a user wants to create a third party mapping, 2602 the user needs to interact out-of-band with their customer premises 2603 router (e.g., using its HTTP administrative interface). 2605 It is RECOMMENDED that service provider NAT and firewall devices 2606 implementing a PCP Server be configured to permit the THIRD_PARTY 2607 Option, when sent by a properly authorized host. If the packet 2608 arrives from an unauthorized host, the PCP server MUST generate an 2609 UNSUPP_OPTION error. 2611 Note that the THIRD_PARTY Option is not needed for today's common 2612 scenario of an ISP offering a single IP address to a customer who is 2613 using NAT to share that address locally, since in this scenario all 2614 the customer's hosts appear to be a single host from the point of 2615 view of the ISP. 2617 Where possible, it may beneficial if a client using the THIRD_PARTY 2618 Option to verify that the third party device is still present and 2619 active on the network. Otherwise the client using the THIRD_PARTY 2620 Option to maintain mappings on behalf of some other device risks 2621 maintaining those mappings forever, long after the device that 2622 required them has gone. This would defeat the purpose of PCP 2623 mappings having a finite lifetime so that they can be automatically 2624 deleted after they are no longer needed. 2626 A PCP client can delete all PCP-created explicit dynamic inbound 2627 mappings (i.e., those created by PCP MAP requests) that it is 2628 authorized to delete by sending a PCP MAP request with zero in the 2629 Internal Port field, zero in the Protocol field, and a THIRD_PARTY 2630 Option with the all-zeros address in the Internal IP Address field. 2631 Upon receipt of such a request from an authorized PCP client, the PCP 2632 server MUST delete all described mappings the PCP client is 2633 authorized to delete, and return SUCCESS. SUCCESS is returned if 2634 zero or more mappings were deleted. 2636 13.2. PREFER_FAILURE Option for MAP Opcode 2638 This Option is only used with the MAP Opcode. 2640 This Option indicates that if the PCP server is unable to map both 2641 the Suggested External Port and Suggested External Address, the PCP 2642 server should not create a mapping. This differs from the behavior 2643 without this Option, which is to create a mapping. 2645 The PREFER_FAILURE Option is formatted as follows: 2647 0 1 2 3 2648 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 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | Option Code=2 | Reserved | Option Length=0 | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 Figure 14: PREFER_FAILURE Option 2655 Option Name: PREFER_FAILURE 2656 Number: 2 2657 Purpose: indicates that the PCP server should not create an 2658 alternative mapping if the suggested external port and address 2659 cannot be mapped. 2660 Valid for Opcodes: MAP 2661 Length: 0 2662 May appear in: request. May appear in response only if it 2663 appeared in the associated request. 2664 Maximum occurrences: 1 2666 The result code CANNOT_PROVIDE_EXTERNAL is returned if the Suggested 2667 External Address, Protocol, and Port cannot be mapped. This can 2668 occur because the External Port is already mapped to another host's 2669 outbound dynamic mapping, an inbound dynamic mapping, a static 2670 mapping, or the same Internal Address, Protocol, and Port already has 2671 an outbound dynamic mapping which is mapped to a different External 2672 Port than suggested. This can also occur because the External 2673 Address is no longer available (e.g., due to renumbering). The 2674 server MAY set the Lifetime in the response to the remaining lifetime 2675 of the conflicting mapping, rounded up to the next larger integer 2676 number of seconds. 2678 PREFER_FAILURE is never necessary for a PCP client to manage mappings 2679 for itself, and its use causes additional work in the PCP client and 2680 in the PCP server. This Option exists for interworking with non-PCP 2681 mapping protocols that have different semantics than PCP (e.g., UPnP 2682 IGDv1 interworking [I-D.bpw-pcp-upnp-igd-interworking], where the 2683 semantics of UPnP IGDv1 only allow the UPnP IGDv1 client to dictate 2684 mapping a specific port), or separate port allocation systems which 2685 allocate ports to a subscriber (e.g., a subscriber-accessed web 2686 portal operated by the same ISP that operates the PCP server). A PCP 2687 server MAY support this Option, if its designers wish to support such 2688 downstream devices or separate port allocation systems. PCP servers 2689 that are not intended to interface with such systems are not required 2690 to support this Option. PCP clients other than UPnP IGDv1 2691 interworking clients or other than a separate port allocation system 2692 SHOULD NOT use this Option because it results in inefficient 2693 operation, and they cannot safely assume that all PCP servers will 2694 implement it. It is anticipated that this Option will be deprecated 2695 in the future as more clients adopt PCP natively and the need for 2696 this Option declines. 2698 If a PCP request contains the PREFER_FAILURE option and has zero in 2699 the Suggested External Port field, or has the all-zeros IPv4 or all- 2700 zeros IPv6 address in the Suggested External Address field, it is 2701 invalid. The PCP server MUST reject such a message with the 2702 MALFORMED_OPTION error code. 2704 PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE 2705 requests, to protect themselves from a rapid flurry of 65535 2706 consecutive PREFER_FAILURE requests from clients probing to discover 2707 which external ports are available. 2709 There can exist a race condition between the MAP Opcode using the 2710 PREFER_FAILURE option and Mapping Update (Section 14.2). Because of 2711 this, the PCP client MUST validate that the External IP Address, 2712 Protocol, and Port in a success response matches the associated 2713 suggested values from the request. If they don't match, it is 2714 because the Mapping Update was sent before the MAP request was 2715 processed. If the PCP client has no use for this new mapping, the 2716 PCP client SHOULD delete the mapping. 2718 13.3. FILTER Option for MAP Opcode 2720 This Option is only used with the MAP Opcode. 2722 This Option indicates that filtering incoming packets is desired. 2723 The protocol being filtered is indicated by the MAP Opcode, and the 2724 Remote Peer Port and Remote Peer IP Address of the FILTER Option 2725 indicate the permitted remote peer's source IP address, protocol, and 2726 port for packets from the Internet; other traffic from other 2727 addresses is blocked. The remote peer prefix length indicates the 2728 length of the remote peer's IP address that is significant; this 2729 allows a single Option to permit an entire subnet. After processing 2730 this MAP request containing the FILTER Option and generating a 2731 successful response, the PCP-controlled device will drop packets 2732 received on its public-facing interface that don't match the filter 2733 fields. After dropping the packet, if its security policy allows, 2734 the PCP-controlled device MAY also generate an ICMP error in response 2735 to the dropped packet. 2737 The FILTER Option is formatted as follows: 2739 0 1 2 3 2740 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 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | Option Code=3 | Reserved | Option Length=20 | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | Reserved | Prefix Length | Remote Peer Port | 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | | 2747 | Remote Peer IP address (128 bits) | 2748 | | 2749 | | 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 Figure 15: FILTER Option layout 2754 These fields are described below: 2756 Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored 2757 when received. 2759 Prefix Length: indicates how many bits of the IPv4 or IPv6 address 2760 are relevant for this filter. The value 0 indicates "no filter", 2761 and will remove all previous filters. See below for detail. 2763 Remote Peer Port: the port number of the remote peer. The value 0 2764 indicates "all ports". 2766 Remote Peer IP address: The IP address of the remote peer. 2768 Option Name: FILTER 2769 Number: 3 2770 Purpose: specifies a filter for incoming packets 2771 Valid for Opcodes: MAP 2772 Length: 20 octets 2773 May appear in: request. May appear in response only if it 2774 appeared in the associated request. 2775 Maximum occurrences: as many as fit within maximum PCP message 2776 size 2778 The Prefix Length indicates how many bits of the address are used for 2779 the filter. For IPv4 addresses (which are encoded using the IPv4- 2780 mapped address format (::FFFF:0:0/96)), this means valid prefix 2781 lengths are between 96 and 128 bits, inclusive. That is, add 96 to 2782 the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are 2783 between 0 and 128 bits, inclusive. Values outside those ranges cause 2784 the PCP server to return the MALFORMED_OPTION result code. 2786 If multiple occurrences of the FILTER Option exist in the same MAP 2787 request, they are processed in the order received (as per normal PCP 2788 Option processing) and they MAY overlap the filtering requested. If 2789 an existing mapping exists (with or without a filter) and the server 2790 receives a MAP request with FILTER, the filters indicated in the new 2791 request are added to any existing filters. If a MAP request has a 2792 lifetime of 0 and contains the FILTER Option, the error 2793 MALFORMED_OPTION is returned. 2795 If any occurrences of the FILTER Option in a request packet are not 2796 successfully processed then an error is returned (e.g., 2797 MALFORMED_OPTION if one of the Options was malformed) and as with 2798 other PCP errors, returning an error causes no state to be changed in 2799 the PCP server or in the PCP-controlled device. 2801 To remove all existing filters, the Prefix Length 0 is used. There 2802 is no mechanism to remove a specific filter. 2804 To change an existing filter, the PCP client sends a MAP request 2805 containing two FILTER Options, the first Option containing a Prefix 2806 Length of 0 (to delete all existing filters) and the second 2807 containing the new remote peer's IP address, protocol, and port. 2808 Other FILTER Options in that PCP request, if any, add more allowed 2809 Remote Peers. 2811 The PCP server or the PCP-controlled device is expected to have a 2812 limit on the number of remote peers it can support. This limit might 2813 be as small as one. If a MAP request would exceed this limit, the 2814 entire MAP request is rejected with the result code 2815 EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. 2817 All PCP servers MUST support at least one filter per MAP mapping. 2819 The use of the FILTER Option can be seen as a performance 2820 optimization. Since all software using PCP to receive incoming 2821 connections also has to deal with the case where it may be directly 2822 connected to the Internet and receive unrestricted incoming TCP 2823 connections and UDP packets, if it wishes to restrict incoming 2824 traffic to a specific source address or group of source addresses 2825 such software already needs to check the source address of incoming 2826 traffic and reject unwanted traffic. However, the FILTER Option is a 2827 particularly useful performance optimization for battery powered 2828 wireless devices, because it can enable them to conserve battery 2829 power by not having to wake up just to reject a unwanted traffic. 2831 14. Rapid Recovery 2833 PCP includes a rapid recovery feature, which allows PCP clients to 2834 repair failed mappings within seconds, rather than the minutes or 2835 hours it might take if they relied solely on waiting for the next 2836 routine renewal of the mapping. Mapping failures may occur when a 2837 NAT gateway is rebooted and loses its mapping state, or when a NAT 2838 gateway has its external IP address changed so that its current 2839 mapping state becomes invalid. 2841 The PCP rapid recovery feature enables users to, for example, connect 2842 to remote machines using ssh, and then reboot their NAT or firewall 2843 device (or even replace it with completely new hardware) without 2844 losing their established ssh connections. 2846 Use of PCP rapid recovery is a performance optimization to PCP's 2847 routine self-healing. Without rapid recovery, PCP clients will still 2848 recreate their correct state when they next renew their mappings, but 2849 this routine self-healing process may take hours rather than seconds, 2850 and will probably not happen fast enough to prevent active TCP 2851 connections from timing out. 2853 There are two mechanisms to perform rapid recovery, described below. 2854 PCP servers SHOULD implement both mechanisms. 2856 14.1. ANNOUNCE Opcode 2858 This rapid recovery mechanism uses the ANNOUNCE Opcode. When the PCP 2859 server loses its state (e.g., it lost its state when rebooted), it 2860 sends the ANNOUNCE response to the link-scoped multicast address 2861 (specific address explained below) if a multicast network exists on 2862 its local interface or, if configured with the IP address(es) and 2863 port(s) of PCP client(s), sends unicast ANNOUNCE responses to those 2864 address(es) and port(s). This means ANNOUNCE may not be available on 2865 all networks (such as networks without a multicast link between the 2866 PCP server and its PCP clients). Additionally, an ANNOUNCE request 2867 can be sent (unicast) by a PCP client which elicits a unicast 2868 ANNOUNCE response like any other Opcode. 2870 14.1.1. ANNOUNCE Operation 2872 The PCP ANNOUNCE Opcode requests and respones have no Opcode-specific 2873 payload (that is, the length of the Opcode-specific data is zero), so 2874 a packet layout is not shown. The Requested Lifetime field of 2875 requests and Lifetime field of responses are both set to 0 on 2876 transmission and ignored on reception. 2878 If a PCP server receives an ANNOUNCE request, it first parses it and 2879 generates a SUCCESS if parsing and processing of ANNOUNCE is 2880 successful (i.e., an error is generated if the request packet is mal- 2881 formed, such as non-zero Opcode length). Note that, in the future, 2882 Options MAY be sent with the PCP ANNOUNCE Opcode; PCP clients and 2883 servers need to be prepared to receive Options with the ANNOUNCE 2884 Opcode. 2886 Discussion: Client-to-server request messages are sent to 2887 listening UDP port 5351 on the server; server-to-client multicast 2888 notifications are sent to listening UDP port 5350 on the client. 2889 The reason the same UDP port is not used for both purposes is that 2890 a single device may have multiple roles. For example, a multi- 2891 function home gateway that provides NAT service (PCP server) may 2892 also provide printer sharing (which wants a PCP client), or a home 2893 computer (PCP client) may also provide "Internet Sharing" (NAT) 2894 functionality (which needs to offer PCP service). Such devices 2895 need to act as both a PCP Server and a PCP Client at the same 2896 time, and the software that implements the PCP Server on the 2897 device may not be the same software component that implements the 2898 PCP Client. The software that implements the PCP Server needs to 2899 listen for unicast client requests, whereas the software that 2900 implements the PCP Client needs to listen for multicast restart 2901 announcements. In many networking APIs it is difficult or 2902 impossible to have two independent clients listening for both 2903 unicasts and multicasts on the same port at the same time. For 2904 this reason, two ports are used. 2906 14.1.2. Generating and Processing a Solicited ANNOUNCE Message 2908 The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client. The 2909 Requested Lifetime value MUST be set to zero. 2911 When the PCP server receives the ANNOUNCE Opcode and successfully 2912 parses and processes it, it generates SUCCESS response with an 2913 Assigned Lifetime of zero. 2915 This functionality allows a PCP client to determine a server's Epoch, 2916 or to determine if a PCP server is running, without changing the 2917 server's state. 2919 14.1.3. Generating and Processing an Unsolicited ANNOUNCE Message 2921 When sending unsolicited responses, the ANNOUNCE Opcode MUST have 2922 Result Code equal to zero (SUCCESS). This message is most typically 2923 multicast, but can also be unicast. Multicast PCP restart 2924 announcements are sent to 224.0.0.1:5350 and/or [ff02::1]:5350, as 2925 described below. Sending PCP restart announcements via unicast 2926 requires that the PCP server know the IP address(es) and port(s) of 2927 its listening clients, which means that sending PCP restart 2928 announcements via unicast is only applicable to PCP servers that 2929 retain knowledge of the IP address(es) and port(s) of their clients 2930 even after they otherwise lose the rest of their state. 2932 When a PCP server device that implements this functionality reboots, 2933 restarts its NAT engine, or otherwise enters a state where it may 2934 have lost some or all of its previous mapping state (or enters a 2935 state where it doesn't even know whether it may have had prior state 2936 that it lost) it MUST inform PCP clients of this fact by unicasting 2937 or multicasting a gratuitous PCP ANNOUNCE Opcode response packet, as 2938 shown below, via paths over which it accepts PCP requests. If 2939 sending a multicast ANNOUNCE message, a PCP server device which 2940 accepts PCP requests over IPv4 sends the Restart Announcement to the 2941 IPv4 multicast address 224.0.0.1:5350 (224.0.0.1 is the All Hosts 2942 multicast group address). If sending a multicast ANNOUNCE message, a 2943 PCP server device which accepts PCP requests over IPv6 sends the 2944 Restart Announcement to the IPv6 multicast address [ff02::1]:5350 2945 (ff02::1 is for all nodes on the local segment). A PCP server device 2946 which accepts PCP requests over both IPv4 and IPv6 sends a pair of 2947 Restart Announcements, one to each multicast address. If sending a 2948 unicast ANNOUNCE messages, it sends ANNOUNCE response message to the 2949 IP address(es) and port(s) of its PCP clients. To accommodate packet 2950 loss, the PCP server device MAY transmit such packets (or packet 2951 pairs) up to ten times (with an appropriate Epoch time value in each 2952 to reflect the passage of time between transmissions) provided that 2953 the interval between the first two notifications is at least 250ms, 2954 and the interval between subsequent notification at least doubles. 2956 A PCP client that sends PCP requests to a PCP Server via a multicast- 2957 capable path, and implements the Restart Announcement feature, and 2958 wishes to receive these announcements, MUST listen to receive these 2959 PCP Restart Announcements (gratuitous PCP ANNOUNCE Opcode response 2960 packets) on the appropriate multicast-capable interfaces on which it 2961 sends PCP requests, and MAY also listen for unicast announcements 2962 from the server too, (using the UDP port it already uses to issue 2963 unicast PCP requests to, and receive unicast PCP responses from, that 2964 server). A PCP client device which sends PCP requests using IPv4 2965 listens for packets sent to the IPv4 multicast address 224.0.0.1: 2966 5350. A PCP client device which sends PCP requests using IPv6 2967 listens for packets sent to the IPv6 multicast address [ff02::1]: 2968 5350. A PCP client device which sends PCP requests using both IPv4 2969 and IPv6 listens for both types of Restart Announcement. (The 2970 SO_REUSEPORT socket option or equivalent should be used for the 2971 multicast UDP port, if required by the host OS to permit multiple 2972 independent listeners on the same multicast UDP port.) 2974 Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode 2975 response packet, a PCP client MUST (as it does with all received PCP 2976 response packets) inspect the Announcement's source IP address, and 2977 if the Epoch time value is outside the expected range for that 2978 server, it MUST wait a random amount of time between 0 and 5 seconds 2979 (to prevent synchronization of all PCP clients), then for all PCP 2980 mappings it made at that server address the client issues new PCP 2981 requests to recreate any lost mapping state. The use of the 2982 Suggested External IP Address and Suggested External Port fields in 2983 the client's renewal requests allows the client to remind the 2984 restarted PCP server device of what mappings the client had 2985 previously been given, so that in many cases the prior state can be 2986 recreated. For PCP server devices that reboot relatively quickly it 2987 is usually possible to reconstruct lost mapping state fast enough 2988 that existing TCP connections and UDP communications do not time out 2989 and continue without failure. If the Epoch time value is within the 2990 expect range for that server, the PCP client does not recreate its 2991 mappings. After receiving and validating the ANNOUNCE message, the 2992 client updates its own Epoch time for that server, as described in 2993 Section 8.5. 2995 14.2. PCP Mapping Update 2997 This rapid recovery mechanism is used when the PCP server remembers 2998 its state and determines its existing mappings are invalid (e.g., IP 2999 renumbering changes the public IP address of a PCP-controlled NAT). 3001 It is anticipated that servers which are routinely reconfigured by an 3002 administrator or have their WAN address changed frequently will 3003 implement this feature (e.g., residential CPE routers). It is 3004 anticipated that servers which are not routinely reconfigured will 3005 not implement this feature (e.g., service provider-operated CGN). 3007 If a PCP server device has not forgotten its mapping state, but for 3008 some other reason has determined that some or all of its mappings 3009 have become unusable (e.g., when a home gateway is assigned a 3010 different external IPv4 address by the upstream DHCP server) then the 3011 PCP server device automatically repairs its mappings and notifies its 3012 clients by following the procedure described below. 3014 For MAP-created and PEER-managed mappings, for each one the PCP 3015 server device should update the External IP Address and External Port 3016 to appropriate available values, and then send unicast PCP MAP or 3017 PEER responses (as appropriate for the mapping) to inform the PCP 3018 client of the new External IP Address and External Port. Such 3019 unsolicited responses are identical to the MAP or PEER responses 3020 normally returned in response to client MAP or PEER requests 3021 containing newly updated External IP Address and External Port 3022 values, and are sent to the same client IP address and port that the 3023 PCP server used to send the prior response for that mapping. If the 3024 earlier associated request contained the THIRD_PARTY Option, the 3025 THIRD_PARTY Option MUST also appear in the Mapping Update as it is 3026 necessary for the PCP client to disambiguate the response. If the 3027 earlier associated request contained the PREFER_FAILURE option, and 3028 the same external IP address, protocol, and port cannot be provided, 3029 the error CANNOT_PROVIDE_EXTERNAL SHOULD be sent. If the earlier 3030 associated request contained the FILTER option, the filters are moved 3031 to the new mapping and the FILTER Option is sent in the Mapping 3032 Update response. Non-mandatory Options SHOULD NOT be sent in the 3033 Mapping Update response. 3035 Discussion: It could have been possible to design this so that the 3036 PCP server (1) sent an ANNOUNCE Opcode to the PCP client, the PCP 3037 client reacted by (2) sending a new MAP request and (3) receiving 3038 a MAP response. Instead, that design is short-cutted by the 3039 server simply sending the message it would have sent in (3). 3041 To accommodate packet loss, the PCP server device SHOULD transmit 3042 such packets 10 times, with an appropriate Epoch time value in each 3043 to reflect the passage of time between transmissions. The interval 3044 between the first two notifications MUST be at least 250ms, and the 3045 interval between subsequent notification doubles. Once the PCP 3046 server has received a refreshed state for that mapping, the PCP 3047 server SHOULD cease those retransmissions for that mapping, as it 3048 serves no further purpose to continue sending messages regarding that 3049 mapping. 3051 Upon receipt of such an updated MAP or PEER response, a PCP client 3052 uses the information in the response to adjust rendezvous servers or 3053 re-connect to servers, respectively. For MAP, this would means 3054 updating the DNS entries or other address and port information 3055 recorded with some kind of application-specific rendezvous server. 3057 For PEER responses indicating the external port or address changed, 3058 this would typically mean re-establishing connections to servers. 3059 Any time the external address or port changes, existing TCP and UDP 3060 connections will be lost; PCP can't avoid that, but does provide 3061 immediate notification of the event to lessen the impact. 3063 15. Implementation Considerations 3065 15.1. Implementing MAP with EDM port-mapping NAT 3067 This section provides non-normative guidance that may be useful to 3068 implementers. 3070 For implicit dynamic outbound mappings, some existing NAT devices 3071 have endpoint-independent mapping (EIM) behavior while other NAT 3072 devices have endpoint-dependent mapping (EDM) behavior. NATs which 3073 have EIM behavior do not suffer from the problem described in this 3074 section. The IETF strongly encourages EIM behavior 3075 [RFC4787][RFC5382]. 3077 In such EDM NAT devices, the same external port may be used by an 3078 outbound dynamic mapping and an inbound dynamic mapping (from the 3079 same Internal Host or from a different Internal Host). This 3080 complicates the interaction with the MAP Opcode. With such NAT 3081 devices, there are two ways envisioned to implement the MAP Opcode: 3083 1. Have outbound mappings use a different set of public ports than 3084 inbound mappings (e.g., those created with MAP), thus reducing 3085 the interaction problem between them; or 3087 2. On arrival of a packet (inbound from the Internet or outbound 3088 from an Internal Host), first attempt to use a dynamic outbound 3089 mapping to process that packet. If none match, attempt to use an 3090 inbound mapping to process that packet. This effectively 3091 'prioritizes' outbound mappings above inbound mappings. 3093 15.2. Lifetime of Explicit and Implicit Dynamic Mappings 3095 This section provides non-normative guidance that may be useful to 3096 implementers. 3098 No matter if a NAT is EIM or EDM, it is possible that one (or more) 3099 outbound mappings, using the same internal port on the Internal Host, 3100 might be created before or after a MAP request. When this occurs, it 3101 is important that the NAT honor the Lifetime returned in the MAP 3102 response. Specifically, if a mapping was created with the MAP 3103 Opcode, the implementation needs to ensure that termination of an 3104 outbound mapping (e.g., via a TCP FIN handshake) does not prematurely 3105 destroy the MAP-created inbound mapping. 3107 15.3. PCP Failure Scenarios 3109 This section provides non-normative guidance that may be useful to 3110 implementers. 3112 If an event occurs that causes the PCP server to lose dynamic mapping 3113 state (such as a crash or power outage), the mappings created by PCP 3114 are lost. Occasional loss of state may be unavoidable in a 3115 residential NAT device which does not write transient information to 3116 non-volatile memory. Loss of state is expected to be rare in a 3117 service provider environment (due to redundant power, disk drives for 3118 storage, etc.). Of course, due to outright failure of service 3119 provider equipment (e.g., software malfunction), state may still be 3120 lost. 3122 The Epoch Time allows a client to deduce when a PCP server may have 3123 lost its state. When the Epoch Time value is observed to be outside 3124 the expected range, the PCP client can attempt to recreate the 3125 mappings following the procedures described in this section. 3127 Further analysis of PCP failure scenarios is in 3128 [I-D.boucadair-pcp-failure]. 3130 15.3.1. Recreating Mappings 3132 This section provides non-normative guidance that may be useful to 3133 implementers. 3135 A mapping renewal packet is formatted identically to an original 3136 mapping request; from the point of view of the client it is a renewal 3137 of an existing mapping, but from the point of view of a newly 3138 rebooted PCP server it appears as a new mapping request. In the 3139 normal process of routinely renewing its mappings before they expire, 3140 a PCP client will automatically recreate all its lost mappings. 3142 When the PCP server loses state and begins processing new PCP 3143 messages, its Epoch time is reset and begins counting again. As the 3144 result of receiving a packet where the Epoch time field is outside 3145 the expected range (Section 8.5), indicating that a reboot or similar 3146 loss of state has occurred, the client can renew its port mappings 3147 sooner, without waiting for the normal routine renewal time. 3149 15.3.2. Maintaining Mappings 3151 This section provides non-normative guidance that may be useful to 3152 implementers. 3154 A PCP client refreshes a mapping by sending a new PCP request 3155 containing information from the earlier PCP response. The PCP server 3156 will respond indicating the new lifetime. It is possible, due to 3157 reconfiguration or failure of the PCP server, that the public IP 3158 address and/or public port, or the PCP server itself, has changed 3159 (due to a new route to a different PCP server). Such events are not 3160 an error. The PCP server will simply return a new External Address 3161 and/or External Port to the client, and the client should record this 3162 new External Address and Port with its rendezvous service. To detect 3163 such events more quickly, the PCP client may find it beneficial to 3164 use shorter lifetimes (so that it communicates with the PCP server 3165 more often). 3167 If the PCP client has several mappings, the Epoch Time value only 3168 needs to be retrieved for one of them to determine whether or not it 3169 appears the PCP server may have suffered a catastrophic loss of 3170 state. If the client wishes to check the PCP server's Epoch Time, it 3171 sends a PCP request for any one of the client's mappings. This will 3172 return the current Epoch Time value. In that request the PCP client 3173 could extend the mapping lifetime (by asking for more time) or 3174 maintain the current lifetime (by asking for the same number of 3175 seconds that it knows are remaining of the lifetime). 3177 If a PCP client changes its Internal IP Address (e.g., because the 3178 Internal Host has moved to a new network), and the PCP client wishes 3179 to still receive incoming traffic, it needs create new mappings on 3180 that new network. New mappings will typically also require an update 3181 to the application-specific rendezvous server if the External Address 3182 or Port are different to the previous values (see Section 10.1 and 3183 Section 11.6). 3185 15.3.3. SCTP 3187 Although SCTP has port numbers like TCP and UDP, SCTP works 3188 differently when behind an address-sharing NAT, in that SCTP port 3189 numbers are not changed [I-D.ietf-behave-sctpnat]. Outbound dynamic 3190 SCTP mappings use the verification tag of the association instead of 3191 the local and remote peer port numbers. As with TCP, explicit 3192 outbound mappings can be made to reduce keepalive intervals, and 3193 explicit inbound mappings can be made by passive listeners expecting 3194 to receive new associations at the external port. 3196 Because an SCTP-aware NAT does not rewrite SCTP port numbers, a PCP 3197 MAP or PEER request for an SCTP mapping SHOULD provide the same 3198 Internal Port and Suggested External Port. If the PCP server 3199 supports SCTP, and the suggested external port cannot be provided in 3200 an explicit dynamic SCTP mapping, then the error 3201 CANNOT_PROVIDE_EXTERNAL is returned. This places an extra burden on 3202 the SCTP client because it then has to tear down its listening socket 3203 and try again with a different Internal Port, repeatedly until it is 3204 successful in finding a port it can use. 3206 The SCTP complications described above occur because of address 3207 sharing. The SCTP complications are avoided when address sharing is 3208 avoided (e.g., 1:1 NAT, firewall). 3210 15.4. Source Address Replicated in PCP Header 3212 All PCP requests include the PCP client's IP address replicated in 3213 the PCP header. This is used to detect address rewriting (NAT) 3214 between the PCP client and its PCP server. On operating systems that 3215 support the sockets API, the following steps are RECOMMENDED for a 3216 PCP client to insert the correct source address and port to include 3217 in the PCP header: 3219 1. Create a UDP socket. 3220 2. Call "connect" on this UDP socket using the address and port of 3221 the desired PCP server. 3222 3. Call the getsockname() function to retrieve a sockaddr containing 3223 the source address the kernel will use for UDP packets sent 3224 through this socket. 3225 4. If the IP address is an IPv4 address, encode the address into an 3226 IPv4-mapped IPv6 address. Place the native IPv6 address or IPv4- 3227 mapped IPv6 address into the PCP Client's IP Address field in the 3228 PCP header. 3229 5. Send PCP requests using this connected UDP socket. 3231 15.5. State Diagram 3233 Each mapping entry of the PCP-controlled device would go through the 3234 state machine shown below. This state diagram is non-normative. 3236 CLOSE_MSG or 3237 (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY 3238 +-------------->| |<------------+ 3239 | |NO_ENTRY | | 3240 | +-----------| |---------+ | 3241 | | +---------+ | | 3242 | | ^ | | | 3243 | | NO_TRAFFIC | | | | 3244 | | or | | | | 3245 | | CLOSE_MSGS | | | | 3246 | | | | | | 3247 | |PEER request | | MAP request| | 3248 | V | | V | 3249 +---------+ | | +---------+ 3250 +-->| "P", | | | M-R | "M", |<--+ 3251 P-R | | PEER |-----------|--|-------->| MAP | | M-R or 3252 +---| mapping| | | | mapping|---+ P-R or 3253 +---------+ | | +---------+ CLOSE_MSGS 3254 | ^ | | ^ | 3255 | |PEER request | | MAP request| | 3256 | | | | | | 3257 | | | | | | 3258 | | | | | | 3259 | | | | outbound | | 3260 | | | | TRAFFIC | | 3261 | | | V | | 3262 | | +---------+ | | 3263 | +-----------| "I", |---------+ | 3264 | | implicit| | 3265 +-------------->| mapping |<------------+ 3266 TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY 3268 Figure 16: PCP State Diagram 3270 The meanings of the states and events are: 3272 NO_ENTRY: Invalid state represents Entry does not exist. This is 3273 the only possible start state. 3275 M-R: MAP request 3277 P-R: PEER request 3279 M: Mapping entry when created by MAP request 3281 P: Mapping entry when created/managed by PEER request 3283 I: Implicit mapping created by an outgoing packet from the 3284 client (e.g., TCP SYN), and also the state when a PCP-created 3285 mapping's lifetime expires while there is still active 3286 traffic. 3288 EXPIRY: PEER or MAP lifetime expired 3290 TRAFFIC: Traffic seen by PCP-controlled device using this entry 3291 within the expiry time for that entry. This traffic may be 3292 inbound or outbound. 3294 NO_TRAFFIC: Indicates that there is no TRAFFIC. 3296 CLOSE_MSG: Protocol messages from the client or server to close 3297 the session (e.g., TCP FIN or TCP RST), as per the NAT or 3298 firewall device's handling of such protocol messages. 3300 Notes on the diagram: 3302 1. The 'and' clause indicates the events on either side of 'and' are 3303 required for the state-transition. The 'or' clause indicates 3304 either one of the events are enough for the state-transition. 3306 2. Transition from state M to state I is implementation dependent. 3308 16. Deployment Considerations 3310 16.1. Ingress Filtering 3312 As with implicit dynamic mappings created by outgoing TCP packets, 3313 explicit dynamic mappings created via PCP use the source IP address 3314 of the packet as the Internal Address for the mappings. Therefore 3315 ingress filtering [RFC2827] SHOULD be used on the path between the 3316 Internal Host and the PCP Server to prevent the injection of spoofed 3317 packets onto that path. 3319 16.2. Mapping Quota 3321 On PCP-controlled devices that create state when a mapping is created 3322 (e.g., NAT), the PCP server SHOULD maintain per-host and/or per- 3323 subscriber quotas for mappings. It is implementation-specific 3324 whether the PCP server uses a separate quotas for implicit, explicit, 3325 and static mappings, a combined quota for all of them, or some other 3326 policy. 3328 17. Security Considerations 3330 The goal of the PCP protocol is to improve the ability of end nodes 3331 to control their associated NAT state, and to improve the efficiency 3332 and error handling of NAT mappings when compared to existing implicit 3333 mapping mechanisms in NAT boxes and stateful firewalls. It is the 3334 security goal of the PCP protocol to limit any new denial of service 3335 opportunities, and to avoid introducing new attacks that can result 3336 in unauthorized changes to mapping state. One of the most serious 3337 consequences of unauthorized changes in mapping state is traffic 3338 theft. All mappings that could be created by a specific host using 3339 implicit mapping mechanisms are inherently considered to be 3340 authorized. Confidentiality of mappings is not a requirement, even 3341 in cases where the PCP messages may transit paths that would not be 3342 travelled by the mapped traffic. 3344 17.1. Simple Threat Model 3346 PCP is secure against off-path attackers who cannot spoof a packet 3347 that the PCP Server will view as a packet received from the internal 3348 network. PCP is secure against off-path attackers who can spoof the 3349 PCP server's IP address. 3351 Defending against attackers who can modify or drop packets between 3352 the internal network and the PCP server, or who can inject spoofed 3353 packets that appear to come from the internal network is out of 3354 scope. Such an attacker can re-direct traffic to a host of their 3355 choosing. 3357 A PCP Server is secure under this threat model if the PCP Server is 3358 constrained so that it does not configure any explicit mapping that 3359 it would not configure implicitly. In most cases, this means that 3360 PCP Servers running on NAT boxes or stateful firewalls that support 3361 the PEER Opcode can be secure under this threat model if all of their 3362 hosts are within a single administrative domain (or if the internal 3363 hosts can be securely partitioned into separate administrative 3364 domains, as in the DS-Lite B4 case), explicit mappings are created 3365 with the same lifetime as implicit mappings, the PCP server does not 3366 support deleting or reducing the lifetime of existing mappings, and 3367 the PCP server does not support the third party option. PCP Servers 3368 can also securely support the MAP Opcode under this threat model if 3369 the security policy on the device running the PCP Server would permit 3370 endpoint independent filtering of implicit mappings. 3372 PCP Servers that comply with the Simple Threat Model and do not 3373 implement a PCP security mechanism described in Section 17.2 MUST 3374 enforce the constraints described in the paragraph above. 3376 17.1.1. Attacks Considered 3378 o If you allow multiple administrative domains to send PCP requests 3379 to a single PCP server that does not enforce a boundary between 3380 the domains, it is possible for a node in one domain to perform a 3381 denial of service attack on other domains, or to capture traffic 3382 that is intended for a node in another domain. 3384 o If explicit mappings have longer lifetimes than implicit mappings, 3385 it makes it easier to perpetrate a denial of service attack than 3386 it would be if the PCP Server was not present. 3388 o If the PCP Server supports deleting or reducing the lifetime of 3389 existing mappings, this allows an attacking node to steal an 3390 existing mapping and receive traffic that was intended for another 3391 node. 3393 o If the THIRD_PARTY Option is supported, this also allows an 3394 attacker to open a window for an external node to attack an 3395 internal node, allows an attacker to steal traffic that was 3396 intended for another node, or may facilitate a denial of service 3397 attack. One example of how the THIRD_PARTY Option could grant an 3398 attacker more capability than a spoofed implicit mapping is that 3399 the PCP server (especially if it is running in a service 3400 provider's network) may not be aware of internal filtering that 3401 would prevent spoofing an equivalent implicit mapping, such as 3402 filtering between a guest and corporate network. 3404 o If the MAP Opcode is supported by the PCP server in cases where 3405 the security policy would not support endpoint independent 3406 filtering of implicit mappings, then the MAP Opcode changes the 3407 security properties of the device running the PCP Server by 3408 allowing explicit mappings that violate the security policy. 3410 17.1.2. Deployment Examples Supporting the Simple Threat Model 3412 This section offers two examples of how the Simple Threat Model can 3413 be supported in real-world deployment scenarios. 3415 17.1.2.1. Residential Gateway Deployment 3417 Parity with many currently-deployed residential gateways can be 3418 achieved using a PCP Server that is constrained as described in 3419 Section 17.1.1 above. 3421 17.2. Advanced Threat Model 3423 In the Advanced Threat Model the PCP protocol must be ensure that 3424 attackers (on- or off-path) cannot create unauthorized mappings or 3425 make unauthorized changes to existing mappings. The protocol must 3426 also limit the opportunity for on- or off-path attackers to 3427 perpetrate denial of service attacks. 3429 The Advanced Threat Model security model will be needed in the 3430 following cases: 3432 o Security infrastructure equipment, such as corporate firewalls, 3433 that does not create implicit mappings. 3435 o Equipment (such as CGNs or service provider firewalls) that serve 3436 multiple administrative domains and do not have a mechanism to 3437 securely partition traffic from those domains. 3439 o Any implementation that wants to be more permissive in authorizing 3440 explicit mappings than it is in authorizing implicit mappings. 3442 o Implementations that wish to support any deployment scenario that 3443 does not meet the constraints described in Section 17.1. 3445 To protect against attacks under this threat model, a PCP security 3446 mechanism that provides an authenticated, integrity protected 3447 signaling channel would need to be specified. 3449 PCP Servers that implement a PCP security mechanism MAY accept 3450 unauthenticated requests. PCP Servers implementing the PCP security 3451 mechanism MUST enforce the constraints described in Section 17.1 3452 above, in their default configuration, when processing 3453 unauthenticated requests. 3455 17.3. Residual Threats 3457 This section describes some threats that are not addressed in either 3458 of the above threat models, and recommends appropriate mitigation 3459 strategies. 3461 17.3.1. Denial of Service 3463 Because of the state created in a NAT or firewall, a per-host and/or 3464 per-subscriber quota will likely exist for both implicit dynamic 3465 mappings and explicit dynamic mappings. A host might make an 3466 excessive number of implicit or explicit dynamic mappings, consuming 3467 an inordinate number of ports, causing a denial of service to other 3468 hosts. Thus, Section 16.2 recommends that hosts be limited to a 3469 reasonable number of explicit dynamic mappings. 3471 An attacker, on the path between the PCP client and PCP server, can 3472 drop PCP requests, drop PCP responses, or spoof a PCP error, all of 3473 which will effectively deny service. Through such actions, the PCP 3474 client might not be aware the PCP server might have actually 3475 processed the PCP request. An attacker sending a NO_RESOURCES error 3476 can cause the PCP client to not send messages to that server for a 3477 while. There is no mitigation to this on-path attacker. 3479 17.3.2. Ingress Filtering 3481 It is important to prevent a host from fraudulently creating, 3482 deleting, or refreshing a mapping (or filtering) for another host, 3483 because this can expose the other host to unwanted traffic, prevent 3484 it from receiving wanted traffic, or consume the other host's mapping 3485 quota. Both implicit and explicit dynamic mappings are created based 3486 on the source IP address in the packet, and hence depend on ingress 3487 filtering to guard against spoof source IP addresses. 3489 17.3.3. Mapping Theft 3491 In the time between when a PCP server loses state and the PCP client 3492 notices the lower than expected Epoch Time value, it is possible that 3493 the PCP client's mapping will be acquired by another host (via an 3494 explicit dynamic mapping or implicit dynamic mapping). This means 3495 incoming traffic will be sent to a different host ("theft"). Rapid 3496 Recovery reduces this interval, but would not completely eliminate 3497 this threat. The PCP client can reduce this interval by using a 3498 relatively short lifetime; however, this increases the amount of PCP 3499 chatter. This threat is reduced by using persistent storage of 3500 explicit dynamic mappings in the PCP server (so it does not lose 3501 explicit dynamic mapping state), or by ensuring the previous external 3502 IP address, protocol, and port cannot be used by another host (e.g., 3503 by using a different IP address pool). 3505 17.3.4. Attacks Against Server Discovery 3507 This document does not specify server discovery, beyond contacting 3508 the default gateway. 3510 18. IANA Considerations 3512 IANA is requested to perform the following actions: 3514 18.1. Port Number 3516 PCP will use ports 5350 and 5351 (currently assigned by IANA to NAT- 3517 PMP [I-D.cheshire-nat-pmp]). We request that IANA re-assign those 3518 ports to PCP, and relinquish UDP port 44323. 3520 [Note to RFC Editor: Please remove the text about relinquishing port 3521 44323 prior to publication.] 3523 18.2. Opcodes 3525 IANA shall create a new protocol registry for PCP Opcodes, numbered 3526 0-127, initially populated with the values: 3528 value Opcode 3529 ----- ------------------------- 3530 0 ANNOUNCE 3531 1 MAP 3532 2 PEER 3533 3-31 Standards Action [RFC5226] 3534 32-63 Specification Required [RFC5226] 3535 96-126 Private Use [RFC5226] 3536 127 Reserved, Standards Action [RFC5226] 3538 The value 127 is Reserved and may be assigned via Standards Action 3539 [RFC5226]. The values in the range 3-31 can be assigned via 3540 Standards Action [RFC5226], 32-63 via Specification Required 3541 [RFC5226], and 96-126 is for Private Use [RFC5226]. 3543 18.3. Result Codes 3545 IANA shall create a new registry for PCP result codes, numbered 3546 0-255, initially populated with the result codes from Section 7.4. 3547 The value 255 is Reserved and may be assigned via Standards Action 3548 [RFC5226]. 3550 The values in the range 14-127 can be assigned via Standards Action 3551 [RFC5226], 128-191 via Specification Required [RFC5226], and 191-254 3552 is for Private Use [RFC5226]. 3554 18.4. Options 3556 IANA shall create a new registry for PCP Options, numbered 0-255 with 3557 an associated mnemonic. The values 0-127 are mandatory-to-process, 3558 and 128-255 are optional to process. The initial registry contains 3559 the Options described in Section 13. The Option values 0, 127 and 3560 255 are Reserved and may be assigned via Standards Action [RFC5226]. 3562 Additional PCP Option codes in the ranges 4-63 and 128-191 can be 3563 created via Standards Action [RFC5226], the ranges 64-95 and 192-223 3564 are for Specification Required [RFC5226] and the ranges 96-126 and 3565 224-254 are for Private Use [RFC5226]. 3567 Documents describing an Option should describe if the processing for 3568 both the PCP client and server and the information below: 3569 Option Name: 3570 Number: 3571 Purpose: 3572 Valid for Opcodes: 3573 Length: 3574 May appear in: 3575 Maximum occurrences: 3577 19. Acknowledgments 3579 Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni 3580 Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda 3581 Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani, 3582 Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete 3583 Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins, 3584 Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda 3585 Costa, Amit Jain, and Wim Henderickx for their comments and review. 3587 Thanks to Simon Perreault for highlighting the interaction of dynamic 3588 connections with PCP-created mappings. 3590 Thanks to Francis Dupont for his several thorough reviews of the 3591 specification, which improved the protocol significantly. 3593 Thanks to T. S. Ranganathan for the state diagram. 3595 Thanks to Peter Lothberg for clock skew information. 3597 Thanks to Margaret Wasserman for writing the Security Considerations 3598 section. 3600 Thanks to authors of DHCPv6 for retransmission text. 3602 20. References 3604 20.1. Normative References 3606 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3607 August 1980. 3609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3610 Requirement Levels", BCP 14, RFC 2119, March 1997. 3612 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3613 Defeating Denial of Service Attacks which employ IP Source 3614 Address Spoofing", BCP 38, RFC 2827, May 2000. 3616 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3617 Addresses", RFC 4193, October 2005. 3619 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3620 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3621 May 2008. 3623 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 3624 Protocol Port Randomization", BCP 156, RFC 6056, 3625 January 2011. 3627 [proto_numbers] 3628 IANA, "Protocol Numbers", 2011, . 3631 20.2. Informative References 3633 [Bonjour] "Bonjour", 3634 . 3636 [I-D.arkko-dual-stack-extra-lite] 3637 Arkko, J., Eggert, L., and M. Townsley, "Scalable 3638 Operation of Address Translators with Per-Interface 3639 Bindings", draft-arkko-dual-stack-extra-lite-05 (work in 3640 progress), February 2011. 3642 [I-D.boucadair-pcp-failure] 3643 Boucadair, M., Dupont, F., and R. Penno, "Port Control 3644 Protocol (PCP) Failure Scenarios", 3645 draft-boucadair-pcp-failure-03 (work in progress), 3646 May 2012. 3648 [I-D.bpw-pcp-upnp-igd-interworking] 3649 Boucadair, M., Penno, R., Wing, D., and F. Dupont, 3650 "Universal Plug and Play (UPnP) Internet Gateway Device 3651 (IGD)-Port Control Protocol (PCP) Interworking Function", 3652 draft-bpw-pcp-upnp-igd-interworking-02 (work in progress), 3653 February 2011. 3655 [I-D.cheshire-dnsext-dns-sd] 3656 Cheshire, S. and M. Krochmal, "DNS-Based Service 3657 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 3658 progress), December 2011. 3660 [I-D.cheshire-nat-pmp] 3661 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 3662 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 3664 [I-D.ietf-behave-lsn-requirements] 3665 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 3666 and H. Ashida, "Common requirements for Carrier Grade NATs 3667 (CGNs)", draft-ietf-behave-lsn-requirements-06 (work in 3668 progress), May 2012. 3670 [I-D.ietf-behave-sctpnat] 3671 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 3672 Transmission Protocol (SCTP) Network Address Translation", 3673 draft-ietf-behave-sctpnat-06 (work in progress), 3674 March 2012. 3676 [I-D.miles-behave-l2nat] 3677 Miles, D. and M. Townsley, "Layer2-Aware NAT", 3678 draft-miles-behave-l2nat-00 (work in progress), 3679 March 2009. 3681 [IGDv1] UPnP Gateway Committee, "WANIPConnection:1", 3682 November 2001, . 3685 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3686 RFC 793, September 1981. 3688 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3689 E. Lear, "Address Allocation for Private Internets", 3690 BCP 5, RFC 1918, February 1996. 3692 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 3693 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 3694 RFC 2136, April 1997. 3696 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 3697 Update", RFC 3007, November 2000. 3699 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3700 Address Translator (Traditional NAT)", RFC 3022, 3701 January 2001. 3703 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 3704 Session Initiation Protocol (SIP) for Symmetric Response 3705 Routing", RFC 3581, August 2003. 3707 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 3708 Unicast Address Format", RFC 3587, August 2003. 3710 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3711 Architecture", RFC 4291, February 2006. 3713 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3714 RFC 4303, December 2005. 3716 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3717 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 3719 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3720 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3721 RFC 4787, January 2007. 3723 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3724 Extensions for Stateless Address Autoconfiguration in 3725 IPv6", RFC 4941, September 2007. 3727 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 3728 RFC 4960, September 2007. 3730 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3731 BCP 131, RFC 4961, July 2007. 3733 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 3734 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3735 RFC 5382, October 2008. 3737 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 3738 Customer Premises Equipment (CPE) for Providing 3739 Residential IPv6 Internet Service", RFC 6092, 3740 January 2011. 3742 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 3743 Algorithm", RFC 6145, April 2011. 3745 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3746 NAT64: Network Address and Protocol Translation from IPv6 3747 Clients to IPv4 Servers", RFC 6146, April 2011. 3749 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3750 Translation", RFC 6296, June 2011. 3752 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 3753 Stack Lite Broadband Deployments Following IPv4 3754 Exhaustion", RFC 6333, August 2011. 3756 Appendix A. NAT-PMP Transition 3758 The Port Control Protocol (PCP) is a successor to the NAT Port 3759 Mapping Protocol, NAT-PMP [I-D.cheshire-nat-pmp], and shares similar 3760 semantics, concepts, and packet formats. Because of this NAT-PMP and 3761 PCP both use the same port, and use NAT-PMP and PCP's version 3762 negotiation capabilities to determine which version to use. This 3763 section describes how an orderly transition may be achieved. 3765 A client supporting both NAT-PMP and PCP SHOULD send its request 3766 using the PCP packet format. This will be received by a NAT-PMP 3767 server or a PCP server. If received by a NAT-PMP server, the 3768 response will be as indicated by the NAT-PMP specification 3769 [I-D.cheshire-nat-pmp], which will cause the client to downgrade to 3770 NAT-PMP and re-send its request in NAT-PMP format. If received by a 3771 PCP server, the response will be as described by this document and 3772 processing continues as expected. 3774 A PCP server supporting both NAT-PMP and PCP can handle requests in 3775 either format. The first octet of the packet indicates if it is NAT- 3776 PMP (first octet zero) or PCP (first octet non-zero). 3778 A PCP-only gateway receiving a NAT-PMP request (identified by the 3779 first octet being zero) will interpret the request as a version 3780 mismatch. Normal PCP processing will emit a PCP response that is 3781 compatible with NAT-PMP, without any special handling by the PCP 3782 server. 3784 Appendix B. Change History 3786 [Note to RFC Editor: Please remove this section prior to 3787 publication.] 3789 B.1. Changes from draft-ietf-pcp-base-25 to -26 3791 o Changed "internal address and port" to "internal address, 3792 protocol, and port" in several more places. 3794 o Improved wording of THIRD_PARTY restrictions. 3796 o Bump version number from 1 to 2, to accommodate pre-RFC PCP client 3797 implementations without needing a heuristic. 3799 B.2. Changes from draft-ietf-pcp-base-24 to -25 3801 o Clarified the port used by the PCP server when sending unsolicited 3802 unicast ANNOUNCE. 3804 o Removed parenthetical comment implying ANNOUNCE was not a normal 3805 Opcode; it is a normal Opcode. 3807 o Explain that non-PCP-speaking host-based and network-based 3808 firewalls need to allow incoming connections for MAP to work. 3810 o For race condition with PREFER_FAILURE, clarified that it is the 3811 PCP client's responsibility to delete the mapping if the PCP 3812 client doesn't need the mapping. 3814 o For table, the NAT64 remote peer is IPv4 (was IPv6). 3816 o Added a Mapping Nonce field to both MAP and PEER requests and 3817 responses, to protect from off-path attackers spoofing the PCP 3818 server's IP address. 3820 o Security considerations: added 'PCP is secure against off-path 3821 attackers who can spoof the PCP server's IP address', because of 3822 the addition of the Mapping Nonce. 3824 o Removed reference to DS-Lite from Security Considerations, as part 3825 of the changes to THIRD_PARTY from IESG review. 3827 o Rapid Recovery is now a SHOULD implement. 3829 o Clarify behavior of PREFER_FAILURE with zeros in Suggested 3830 External Port or Address fields. 3832 o PCP server is now more robust and insistent about informing PCP 3833 client of state changes. 3835 o When PCP server sends Mapping Update to a specific PCP client, and 3836 gets an update for a particular mapping, it doesn't need to send 3837 reminders about that mapping any more. 3839 o THIRD_PARTY is now prohibited on subscriber PCP clients. 3841 B.3. Changes from draft-ietf-pcp-base-23 to -24 3843 o Explained common questions regarding PCP's design, such as lack of 3844 transction identifiers and its request/response semantics and 3845 operation (Protocol Design Note (Section 6)). 3847 o added MUST for all-zeros IPv6 and IPv4 address formats. 3849 o included field definitions for Opcode-specific information and PCP 3850 options under both Figure 2 and Figure 3. 3852 o adopted retransmission mechanism from DHCPv6. 3854 o 1024 message size limit described in PCP message restriction. 3856 o Explained PCP server list, with example of host with IPv4 and IPv6 3857 addresses having two PCP servers (one IPv4 PCP server for IPv4 3858 mappings and one IPv6 PCP server for IPv6 mappings). 3860 o mention PCP client needs to expect unsolicited PCP responses from 3861 previous incarnations of itself (on the same host) or of this host 3862 (using same IP address as another PCP client). 3864 o eliminated overuse of 'packet format' when it was 'opcode format'. 3866 o for IANA registries, added code points assignable via Standards 3867 Action (previously was just Specification Required). 3869 o Version negotiation, added explanation that retrying after 30 3870 minutes makes the protocol self-healing if the PCP server is 3871 upgraded. 3873 o Version negotiation now accomodates non-contiguous version 3874 numbers. 3876 o Tweaked definition of VERSION field (that "1" is for this version, 3877 but other values could of course appear in the future). 3879 o when receiving unsolicited ANNOUNCE, PCP client now waits random 3880 0-5 seconds. 3882 o Removed 'interworking function' from list of terminology because 3883 we no longer use the term in this document. 3885 o tightened definitions of 'PCP client' and 'PCP server'. 3887 o For 'Requested Lifetime' definitions, removed text requiring its 3888 value be 0 for not-yet-defined opcodes. 3890 o Removed some unnecessary text suggesting logging (is an 3891 implementation detail). 3893 o Added active-mode FTP as example protocol that can break with 3894 mappings to different IP addresses. 3896 o Clarified that if PCP request contains a Suggested External 3897 Address, the PCP server should try to create a mapping to that 3898 address even if other mappings already exist to a different 3899 external address. 3901 o Changed "internal address and port" to "internal address, 3902 protocol, and port" in several places. 3904 o Clarified which 96 bits are copied into error response. Clarified 3905 that only error responses are copied verbatim from request. 3907 o a single PCP server can control multiple NATs or multiple 3908 firewalls (Section 4). 3910 o Clarified that sending unsolicited multicast ANNOUNCE is not 3911 always available on all networks. 3913 o Clarified option length error example is when option length 3914 exceeds UDP length 3916 o Explained that an on-path attacker that can spoof packets can re- 3917 direct traffic to a host of their choosing. 3919 o Instead of saying IPv4-mapped addresses won't appear on the wire, 3920 say they aren't used for mappings. 3922 o THIRD_PARTY is useful for management device (e.g., in a network 3923 operations center). 3925 o Clarified PCP responses have fields updated as indicated with 'set 3926 by the server' from field definitions. 3928 o Disallow using MAP to the PCP ports themselves and encourage 3929 implementations have policy control for other ports. 3931 o Instead of 'idempotent', now says 'identical requests generate 3932 identical response'. 3934 o Described which Options are included when sending Mapping Update 3935 (unsolicited responses), Section 14.2. 3937 o Dropped [RFC2136] and [RFC3007] to informative references. 3939 o Updated from 'should' to 'SHOULD' in Section 16.1. 3941 o Described 'hairpin' in terminology section. 3943 B.4. Changes from draft-ietf-pcp-base-22 to -23 3945 o Instead of returning error NO_RESOURCES when requesting a MAP for 3946 all protocols or for all ports, return UNSUPP_PROTOCOL. 3948 o Clarify that PEER-created mappings are treated as if it was 3949 implicit dynamic outbound mapping (Section 12.3). 3951 o Point out that PEER-created mappings may be very short until bi- 3952 directional traffic is seen by the PCP-managed device. 3954 o Clairification that an existing implicit mapping (created e.g., by 3955 TCP SYN) can become managed by a MAP request (Section 11.3. 3957 o Clarified the ANNOUNCE Opcode is being defined in Section 14.1, 3958 and that the length of requests (as well as responses) is zero. 3960 o Clarify that ANNOUNCE has Lifetime=0 for requests and responses. 3962 o Clarify ANNOUNCE can be sent unicast by the client (to solicit a 3963 response), or can be multicasted (unsolicited) by the server. 3965 o Allow ANNOUNCE to be sent unicast by the server, to accomodate 3966 case where PCP server fails but knows the IP address of a PCP 3967 client (e.g., web portal). 3969 o Clarified ports used for unicast and multicast unsolicited 3970 ANNOUNCE. 3972 o Tweaked NO_RESOURCES handling, to just disallow *new* mappings. 3974 o State diagram is now non-normative, because it overly simplifies 3975 that implicit mappings become MAP (when they actually still retain 3976 their previous behavior when the MAP expires). 3978 o In section Section 11.5, clarified that PEER cannot delete or 3979 shorten any lifetime, and that MAP can only shorten or delete 3980 lifetimes of MAP-created mappings. 3982 o Clarified handling of MAP when mapping already exists (4 steps). 3984 o 2^32-1 3986 o Randomize retry interval (1.5-2.5), and maximum retry interval is 3987 now 1024 seconds (was 15 minutes). 3989 o Remove MUST be 0 for Reserved field when sending error responses 3990 for un-parseable message. 3992 o Whenever PCP client includes Suggested IP Address (in MAP or 3993 PEER), the PCP server should try to fulfill that request, even if 3994 creating a mapping on that IP address means the internal host will 3995 have mappings on different IP addresses and ports. 3997 o For NO_RESOURCES error, the PCP client can attempt to renew and 3998 attempt to delete mappings (as they can help shed load) -- it just 3999 can't try to create new ones. 4001 o Removed the overly simplistic normative text regarding honoring 4002 Suggested External Address from Section 10 in favor of the text in 4003 Section 11.3 which has significantly more detail. 4005 B.5. Changes from draft-ietf-pcp-base-21 to -22 4007 o Removed paragraph discussing multiple addresses on the same 4008 (physical) interface; those will work with PCP. 4010 o The FILTER Option's Prefix Length field redefined to simply be a 4011 count of the relevant bits (rather than 0-32 for IPv4-mapped 4012 addresses). 4014 o Point out NO_RESOURCES attack vector in security considerations. 4016 o Tighten up recommendation for client handling long Lifetimes, and 4017 moved from the MAP-specific section to the General PCP Processing 4018 section. Client should normalize to 24 hours maximum for success 4019 and 30 minute maximum for errors. 4021 B.6. Changes from draft-ietf-pcp-base-20 to -21 4023 o To delete all mappings using THIRD_PARTY, use the all-zeros IP 4024 address (rather than previous text which used length=0). 4026 o added normative text for what PCP server does when it receives 4027 all-zeros IP address in THIRD_PARTY option. 4029 o PREFER_FAILURE allowed for use by web portal. 4031 o clarifications to mandatory option processing. 4033 o cleanup and wordsmithing of the THIRD_PARTY text. 4035 B.7. Changes from draft-ietf-pcp-base-19 to -20 4037 o clarify if Options are included in responses. 4039 o clarify when External Address can be ignored by the PCP server / 4040 PCP-controlled device 4042 o added 'Transition from state M to state I is implementation 4043 dependent' to state diagram 4045 B.8. Changes from draft-ietf-pcp-base-18 to -19 4047 o Described race condition with MAP containing PREFER_FAILURE and 4048 Mapping Update. 4050 o Added state machine (Section 15.5). 4052 o Fully integrated Rapid Recovery, with a separate Opcode having its 4053 own processing description. 4055 o Clarified that due to Mapping Update, a single MAP or PEER request 4056 can receive multiple responses, each updating the previous 4057 request, and that the PCP client needs to handle MAP updates or 4058 PEER updates accordingly. 4060 B.9. Changes from draft-ietf-pcp-base-17 to -18 4062 o Removed UNPROCESSED option. Instead, unprocessed options are 4063 simply not included in responses. 4065 o Updated terminology section for Implicit/Explicit and Outbound/ 4066 Inbound. 4068 o PEER requests cannot delete or shorten the lifetime of a mapping. 4070 o Clarified that PCP clients only retransmit mapping requests for as 4071 long as they actually want the mapping. 4073 o Revised Epoch time calculations and explanation. 4075 o Renamed the announcement opcode from No-Op to ANNOUNCE. 4077 B.10. Changes from draft-ietf-pcp-base-16 to -17 4079 o suggest acquiring a mapping to the Discard port if there is a 4080 desire to show the user their external address (Section 11.7). 4082 o Added Restart Announcement. 4084 o Tweaked terminology. 4086 o Detailed how error responses are generated. 4088 B.11. Changes from draft-ietf-pcp-base-15 to -16 4090 o fixed mistake in PCP request format (had 32 bits of extraneous 4091 fields) 4093 o Allow MAP to request all ports (port=0) for a specific protocol 4094 (protocol!=0), for the same reason we added support for all ports 4095 (port=0) and all protocols (protocol=0) in -15 4097 o corrected text on Client Processing a Response related to 4098 receiving ADDRESS_MISMATCH error. 4100 o updated Epoch text. 4102 o Added text that MALFORMED_REQUEST is generated for MAP if Protocol 4103 is zero but Internal Port is non-zero. 4105 B.12. Changes from draft-ietf-pcp-base-14 to -15 4107 o Softened and removed text that was normatively explaining how PEER 4108 is implemented within a NAT. 4110 o Allow a MAP request for protocol=0, which means "all protocols". 4111 This can work for an IPv6 or IPv4 firewall. Its use with a NAPT 4112 is undefined. 4114 o combined SERVER_OVERLOADED and NO_RESOURCES into one error code, 4115 NO_RESOURCES. 4117 o SCTP mappings have to use same internal and suggested external 4118 ports, and have implied PREFER_FAILURE semantics. 4120 o Re-instated ADDRESS_MISMATCH error, which only checks the client 4121 address (not its port). 4123 B.13. Changes from draft-ietf-pcp-base-13 to -14 4125 o Moved discussion of socket operations for PCP source address into 4126 Implementation Considerations section. 4128 o Integrated numerous WGLC comments. 4130 o NPTv6 in scope. 4132 o Re-written security considerations section. Thanks, Margaret! 4134 o Reduced PEER4 and PEER6 Opcodes to just a single Opcode, PEER. 4136 o Reduced MAP4 and MAP6 Opcodes to just a single Opcode, MAP. 4138 o Rearranged the PEER packet formats to align with MAP. 4140 o Removed discussion of the "O" bit for Options, which was 4141 confusing. Now the text just discusses the most significant bit 4142 of the Option code which indicates mandatory/optional, so it is 4143 clearer the field is 8 bits. 4145 o The THIRD_PARTY Option from an unauthorized host generates 4146 UNSUPP_OPTION, so the PCP server doesn't disclose it knows how to 4147 process THIRD_PARTY Option. 4149 o Added table to show which fields of MAP or PEER need IPv6/IPv4 4150 addresses for IPv4 firewall, DS-Lite, NAT64, NAT44, etc. 4152 o Accommodate the server's Epoch going up or down, to better detect 4153 switching to a different PCP server. 4155 o Removed ADDRESS_MISMATCH; the server always includes its idea of 4156 the Client's IP Address and Port, and it's up to the client to 4157 detect a mismatch (and rectify it). 4159 B.14. Changes from draft-ietf-pcp-base-12 to -13 4161 o All addresses are 128 bits. IPv4 addresses are represented by 4162 IPv4-mapped IPv6 addresses (::FFFF/96) 4164 o PCP request header now includes PCP client's port (in addition to 4165 the client's IP address, which was in -12). 4167 o new ADDRESS_MISMATCH error. 4169 o removed PROCESSING_ERROR error, which was too similar to 4170 MALFORMED_REQUEST. 4172 o Tweaked text describing how PCP client deals with multiple PCP 4173 server addresses (Section 8.1) 4175 o clarified that when overloaded, the server can send 4176 SERVER_OVERLOADED (and drop requests) or simply drop requests. 4178 o Clarified how PCP client chooses MAP4 or MAP6, depending on the 4179 presence of its own IPv6 or IPv4 interfaces (Section 10). 4181 o compliant PCP server MUST support MAPx and PEERx, SHOULD support 4182 ability to disable support. 4184 o clarified that MAP-created mappings have no filtering, and PEER- 4185 created mappings have whatever filtering and mapping behavior is 4186 normal for that particular NAT / firewall. 4188 o Integrated WGLC feedback (small changes to abstract, definitions, 4189 and small edits throughout the document) 4191 o allow new Options to be defined with a specification (rather than 4192 standards action) 4194 B.15. Changes from draft-ietf-pcp-base-11 to -12 4196 o added implementation note that MAP and implicit dynamic mappings 4197 have independent mapping lifetimes. 4199 B.16. Changes from draft-ietf-pcp-base-10 to -11 4201 o clarified what can cause CANNOT_PROVIDE_EXTERNAL error to be 4202 generated. 4204 B.17. Changes from draft-ietf-pcp-base-09 to -10 4206 o Added External_AF field to PEER requests. Made PEER's Suggested 4207 External IP Address and Assigned External IP Address always be 128 4208 bits long. 4210 B.18. Changes from draft-ietf-pcp-base-08 to -09 4212 o Clarified in PEER Opcode introduction (Section 12) that they can 4213 also create mappings. 4215 o More clearly explained how PEER can re-create an implicit dynamic 4216 mapping, for purposes of rebuilding state to maintain an existing 4217 session (e.g., long-lived TCP connection to a server). 4219 o Added Suggested External IP Address to the PEER Opcodes, to allow 4220 more robust rebuilding of connections. Added related text to the 4221 PEER server processing section. 4223 o Removed text encouraging PCP server to statefully remember its 4224 mappings from Section 15.3.1, as it didn't belong there. Text in 4225 Security Considerations already encourages persistent storage. 4227 o More clearly discussed how PEER is used to re-establish TCP 4228 mapping state. Moved it to a new section, as well (it is now 4229 Section 10.4). 4231 o MAP errors now copy the Suggested Address (and port) fields to 4232 Assigned IP Address (and port), to allow PCP client to distinguish 4233 among many outstanding requests when using PREFER_FAILURE. 4235 o Mapping theft can also be mitigated by ensuring hosts can't re-use 4236 same IP address or port after state loss. 4238 o the UNPROCESSED option is renumbered to 0 (zero), which ensures no 4239 other option will be given 0 and be unable to be expressed by the 4240 UNPROCESSED option (due to its 0 padding). 4242 o created new Implementation Considerations section (Section 15) 4243 which discusses non-normative things that might be useful to 4244 implementers. Some new text is in here, and the Failure Scenarios 4245 text (Section 15.3) has been moved to here. 4247 o Tweaked wording of EDM NATs in Section 15.1 to clarify the problem 4248 occurs both inside->outside and outside->inside. 4250 o removed "Interference by Other Applications on Same Host" section 4251 from security considerations. 4253 o fixed zero/non-zero text in Section 11.5. 4255 o removed duplicate text saying MAP is allowed to delete an implicit 4256 dynamic mapping. It is still allowed to do that, but it didn't 4257 need to be said twice in the same paragraph. 4259 o Renamed error from UNAUTH_TARGET_ADDRESS to 4260 UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS. 4262 o for FILTER option, removed unnecessary detail on how FILTER would 4263 be bad for PEER, as it is only allowed for MAP anyway. 4265 o In Security Considerations, explain that PEER can create a mapping 4266 which makes its security considerations the same as MAP. 4268 B.19. Changes from draft-ietf-pcp-base-07 to -08 4270 o moved all MAP4-, MAP6-, and PEER-specific options into a single 4271 section. 4273 o discussed NAT port-overloading and its impact on MAP (new section 4274 Section 15.1), which allowed removing the IMPLICIT_MAPPING_EXISTS 4275 error. 4277 o eliminated NONEXIST_PEER error (which was returned if a PEER 4278 request was received without an implicit dynamic mapping already 4279 being created), and adjusted PEER so that it creates an implicit 4280 dynamic mapping. 4282 o Removed Deployment Scenarios section (which detailed NAT64, NAT44, 4283 Dual-Stack Lite, etc.). 4285 o Added Client's IP Address to PCP common header. This allows 4286 server to refuse a PCP request if there is a mismatch with the 4287 source IP address, such as when a non-PCP-aware NAT was on the 4288 path. This should reduce failure situations where PCP is deployed 4289 in conjunction with a non-PCP-aware NAT. This addition was 4290 consensus at IETF80. 4292 o Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that 4293 MALFORMED_REQUEST is for malformed requests (and not related to 4294 failed attempts to process the request). 4296 o Removed MISORDERED_OPTIONS. Consensus of IETF80. 4298 o SERVER_OVERLOADED is now a common PCP error (instead of specific 4299 to MAP). 4301 o Tweaked PCP retransmit/retry algorithm again, to allow more 4302 aggressive PCP discovery if an implementation wants to do that. 4304 o Version negotiation text tweaked to soften NAT-PMP reference, and 4305 more clearly explain exactly what UNSUPP_VERSION should return. 4307 o PCP now uses NAT-PMP's UDP port, 5351. There are no normative 4308 changes to NAT-PMP or PCP to allow them both to use the same port 4309 number. 4311 o New Appendix A to discuss NAT-PMP / PCP interworking. 4313 o improved pseudocode to be non-blocking. 4315 o clarified that PCP cannot delete a static mapping (i.e., a mapping 4316 created by CLI or other non-PCP means). 4318 o moved theft of mapping discussion from Epoch section to Security 4319 Considerations. 4321 B.20. Changes from draft-ietf-pcp-base-06 to -07 4323 o tightened up THIRD_PARTY security discussion. Removed "highest 4324 numbered address", and left it as simply "the CPE's IP address". 4326 o removed UNABLE_TO_DELETE_ALL error. 4328 o renumbered Opcodes 4330 o renumbered some error codes 4332 o assigned value to IMPLICIT_MAPPING_EXISTS. 4334 o UNPROCESSED can include arbitrary number of option codes. 4336 o Moved lifetime fields into common request/response headers 4338 o We've noticed we're having to repeatedly explain to people that 4339 the "requested port" is merely a hint, and the NAT gateway is free 4340 to ignore it. Changed name to "suggested port" to better convey 4341 this intention. 4343 o Added NAT-PMP transition section 4345 o Separated Internal Address, External Address, Remote Peer Address 4346 definition 4348 o Unified Mapping, Port Mapping, Port Forwarding definition 4350 o adjusted so DHCP configuration is non-normative. 4352 o mentioned PCP refreshes need to be sent over the same interface. 4354 o renamed the REMOTE_PEER_FILTER option to FILTER. 4356 o Clarified FILTER option to allow sending an ICMP error if policy 4357 allows. 4359 o for MAP, clarified that if the PCP client changed its IP address 4360 and still wants to receive traffic, it needs to send a new MAP 4361 request. 4363 o clarified that PEER requests have to be sent from same interface 4364 as the connection itself. 4366 o for MAP opcode, text now requires mapping be deleted when lifetime 4367 expires (per consensus on 8-Mar interim meeting) 4369 o PEER Opcode: better description of remote peer's IP address, 4370 specifically that it does not control or establish any filtering, 4371 and explaining why it is 'from the PCP client's perspective'. 4373 o Removed latent text allowing DMZ for 'all protocols' (protocol=0). 4374 Which wouldn't have been legal, anyway, as protocol 0 is assigned 4375 by IANA to HOPOPT (thanks to James Yu for catching that one). 4377 o clarified that PCP server only listens on its internal interface. 4379 o abandoned 'target' term and reverted to simplier 'internal' term. 4381 B.21. Changes from draft-ietf-pcp-base-05 to -06 4383 o Dual-Stack Lite: consensus was encapsulation mode. Included a 4384 suggestion that the B4 will need to proxy PCP-to-PCP and UPnP-to- 4385 PCP. 4387 o defined THIRD_PARTY Option to work with the PEER Opcode, too. 4388 This meant moving it to its own section, and having both MAP and 4389 PEER Opcodes reference that common section. 4391 o used "target" instead of "internal", in the hopes that clarifies 4392 internal address used by PCP itself (for sending its packets) 4393 versus the address for MAPpings. 4395 o Options are now required to be ordered in requests, and ordering 4396 has to be validated by the server. Intent is to ease server 4397 processing of mandatory-to-implement options. 4399 o Swapped Option values for the mandatory- and optional-to-process 4400 Options, so we can have a simple lowest..highest ordering. 4402 o added MISORDERED_OPTIONS error. 4404 o re-ordered some error messages to cause MALFORMED_REQUEST (which 4405 is PCP's most general error response) to be error 1, instead of 4406 buried in the middle of the error numbers. 4408 o clarified that, after successfully using a PCP server, that PCP 4409 server is declared to be non-responsive after 5 failed 4410 retransmissions. 4412 o tightened up text (which was inaccurate) about how long general 4413 PCP processing is to delay when receiving an error and if it 4414 should honor Opcode-specific error lifetime. Useful for MAP 4415 errors which have an error lifetime. (This all feels awkward to 4416 have only some errors with a lifetime.) 4418 o Added better discussion of multiple interfaces, including 4419 highlighting WiFi+Ethernet. Added discussion of using IPv6 4420 Privacy Addresses and RFC1918 as source addresses for PCP 4421 requests. This should finish the section on multi-interface 4422 issues. 4424 o added some text about why server might send SERVER_OVERLOADED, or 4425 might simply discard packets. 4427 o Dis-allow internal-port=0, which means we dis-allow using PCP as a 4428 DMZ-like function. Instead, ports have to be mapped individually. 4430 o Text describing server's processing of PEER is tightened up. 4432 o Server's processing of PEER now says it is implementation-specific 4433 if a PCP server continues to allow the mapping to exist after a 4434 PEER message. Client's processing of PEER says that if client 4435 wants mapping to continue to exist, client has to continue to send 4436 recurring PEER messages. 4438 B.22. Changes from draft-ietf-pcp-base-04 to -05 4440 o tweaked PCP common header packet layout. 4442 o Re-added port=0 (all ports). 4444 o minimum size is 12 octets (missed that change in -04). 4446 o removed Lifetime from PCP common header. 4448 o for MAP error responses, the lifetime indicates how long the 4449 server wants the client to avoid retrying the request. 4451 o More clearly indicated which fields are filled by the server on 4452 success responses and error responses. 4454 o Removed UPnP interworking section from this document. It will 4455 appear in [I-D.bpw-pcp-upnp-igd-interworking]. 4457 B.23. Changes from draft-ietf-pcp-base-03 to -04 4459 o "Pinhole" and "PIN" changed to "mapping" and "MAP". 4461 o Reduced from four MAP Opcodes to two. This was done by implicitly 4462 using the address family of the PCP message itself. 4464 o New option THIRD_PARTY, to more carefully split out the case where 4465 a mapping is created to a different host within the home. 4467 o Integrated a lot of editorial changes from Stuart and Francis. 4469 o Removed nested NAT text into another document, including the IANA- 4470 registered IP addresses for the PCP server. 4472 o Removed suggestion (MAY) that PCP server reserve UDP when it maps 4473 TCP. Nobody seems to need that. 4475 o Clearly added NAT and NAPT, such as in residential NATs, as within 4476 scope for PCP. 4478 o HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE 4480 o Added 'Lifetime' field to the common PCP header, which replaces 4481 the functions of the 'temporary' and 'permanent' error types of 4482 the previous version. 4484 o Allow arbitrary Options to be included in PCP response, so that 4485 PCP server can indicate un-supported PCP Options. Satisfies PCP 4486 Issue #19 4488 o Reduced scope to only deal with mapping protocols that have port 4489 numbers. 4491 o Reduced scope to not support DMZ-style forwarding. 4493 o Clarified version negotiation. 4495 B.24. Changes from draft-ietf-pcp-base-02 to -03 4497 o Adjusted abstract and introduction to make it clear PCP is 4498 intended to forward ports and intended to reduce application 4499 keepalives. 4501 o First bit in PCP common header is set. This allows DTLS and non- 4502 DTLS to be multiplexed on same port, should a future update to 4503 this specification add DTLS support. 4505 o Moved subscriber identity from common PCP section to MAP* section. 4507 o made clearer that PCP client can reduce mapping lifetime if it 4508 wishes. 4510 o Added discussion of host running a server, client, or symmetric 4511 client+server. 4513 o Introduced PEER4 and PEER6 Opcodes. 4515 o Removed REMOTE_PEER Option, as its function has been replaced by 4516 the new PEER Opcodes. 4518 o IANA assigned port 44323 to PCP. 4520 o Removed AMBIGUOUS error code, which is no longer needed. 4522 B.25. Changes from draft-ietf-pcp-base-01 to -02 4524 o more error codes 4526 o PCP client source port number should be random 4528 o PCP message minimum 8 octets, maximum 1024 octets. 4530 o tweaked a lot of text in section 7.4, "Opcode-Specific Server 4531 Operation". 4533 o opening a mapping also allows ICMP messages associated with that 4534 mapping. 4536 o PREFER_FAILURE value changed to the mandatory-to-process range. 4538 o added text recommending applications that are crashing obtain 4539 short lifetimes, to avoid consuming subscriber's port quota. 4541 B.26. Changes from draft-ietf-pcp-base-00 to -01 4543 o Significant document reorganization, primarily to split base PCP 4544 operation from Opcode operation. 4546 o packet format changed to move 'protocol' outside of PCP common 4547 header and into the MAP* opcodes 4549 o Renamed Informational Elements (IE) to Options. 4551 o Added REMOTE_PEER (for disambiguation with dynamic ports), 4552 REMOTE_PEER_FILTER (for simple packet filtering), and 4553 PREFER_FAILURE (to optimize UPnP IGDv1 interworking) options. 4555 o Is NAT or router behind B4 in scope? 4557 o PCP option MAY be included in a request, in which case it MUST 4558 appear in a response. It MUST NOT appear in a response if it was 4559 not in the request. 4561 o Result code most significant bit now indicates permanent/temporary 4562 error 4564 o PCP Options are split into mandatory-to-process ("P" bit), and 4565 into Specification Required and Private Use. 4567 o Epoch discussion simplified. 4569 Authors' Addresses 4571 Dan Wing (editor) 4572 Cisco Systems, Inc. 4573 170 West Tasman Drive 4574 San Jose, California 95134 4575 USA 4577 Email: dwing@cisco.com 4578 Stuart Cheshire 4579 Apple Inc. 4580 1 Infinite Loop 4581 Cupertino, California 95014 4582 USA 4584 Phone: +1 408 974 3207 4585 Email: cheshire@apple.com 4587 Mohamed Boucadair 4588 France Telecom 4589 Rennes, 35000 4590 France 4592 Email: mohamed.boucadair@orange-ftgroup.com 4594 Reinaldo Penno 4595 Cisco Systems, Inc. 4596 170 West Tasman Drive 4597 San Jose, California 95134 4598 USA 4600 Email: repenno@cisco.com 4602 Paul Selkirk 4603 Internet Systems Consortium 4604 950 Charter Street 4605 Redwood City, California 94063 4606 USA 4608 Email: pselkirk@isc.org