idnits 2.17.1 draft-ietf-pcp-base-16.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1185 has weird spacing: '... source inter...' -- The document date (October 21, 2011) is 4571 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-02 == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-05) exists of draft-dupont-pcp-dslite-00 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-03 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-05 -- 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 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP working group D. Wing, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Cheshire 5 Expires: April 23, 2012 Apple 6 M. Boucadair 7 France Telecom 8 R. Penno 9 Juniper Networks 10 P. Selkirk 11 ISC 12 October 21, 2011 14 Port Control Protocol (PCP) 15 draft-ietf-pcp-base-16 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 April 23, 2012. 41 Copyright Notice 43 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . 10 66 6. Common Request and Response Header Format . . . . . . . . . . 11 67 6.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 12 68 6.2. Response Header . . . . . . . . . . . . . . . . . . . . . 13 69 6.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 17 71 7. General PCP Operation . . . . . . . . . . . . . . . . . . . . 18 72 7.1. General PCP Client: Generating a Request . . . . . . . . . 18 73 7.2. General PCP Server: Processing a Request . . . . . . . . . 19 74 7.3. General PCP Client: Processing a Response . . . . . . . . 21 75 7.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . . 22 76 7.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 7.6. Version Negotiation . . . . . . . . . . . . . . . . . . . 24 78 7.7. General PCP Option . . . . . . . . . . . . . . . . . . . . 25 79 7.7.1. UNPROCESSED Option . . . . . . . . . . . . . . . . . . 25 80 8. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . . 26 81 8.1. For Operating a Server . . . . . . . . . . . . . . . . . . 28 82 8.2. For Operating a Symmetric Client/Server . . . . . . . . . 29 83 8.3. For Reducing NAT Keepalive Messages . . . . . . . . . . . 32 84 8.4. For Restoring Lost Implicit TCP Dynamic Mapping State . . 33 85 9. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 34 86 9.1. MAP Operation Packet Formats . . . . . . . . . . . . . . . 35 87 9.2. Generating a MAP Request . . . . . . . . . . . . . . . . . 37 88 9.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . . 37 89 9.3. Processing a MAP Request . . . . . . . . . . . . . . . . . 38 90 9.4. Processing a MAP Response . . . . . . . . . . . . . . . . 40 91 9.5. Mapping Lifetime and Deletion . . . . . . . . . . . . . . 41 92 9.6. Address Change Events . . . . . . . . . . . . . . . . . . 43 93 9.7. Learning the External IP Address Alone . . . . . . . . . . 44 94 10. PEER Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 44 95 10.1. PEER Operation Packet Formats . . . . . . . . . . . . . . 45 96 10.2. Generating a PEER Request . . . . . . . . . . . . . . . . 48 97 10.3. Processing a PEER Request . . . . . . . . . . . . . . . . 48 98 10.4. Processing a PEER Response . . . . . . . . . . . . . . . . 50 99 11. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . . 50 100 11.1. THIRD_PARTY Option for MAP and PEER Opcodes . . . . . . . 51 101 11.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . . 53 102 11.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . . 54 103 12. Implementation Considerations . . . . . . . . . . . . . . . . 56 104 12.1. Implementing MAP with EDM port-mapping NAT . . . . . . . . 56 105 12.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . . 57 106 12.3. PCP Failure Scenarios . . . . . . . . . . . . . . . . . . 57 107 12.3.1. Recreating Mappings . . . . . . . . . . . . . . . . . 58 108 12.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 58 109 12.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 59 110 12.4. Source Address and Port in PCP Header . . . . . . . . . . 59 111 13. Deployment Considerations . . . . . . . . . . . . . . . . . . 59 112 13.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 60 113 13.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 60 114 14. Security Considerations . . . . . . . . . . . . . . . . . . . 60 115 14.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 60 116 14.1.1. Attacks Considered . . . . . . . . . . . . . . . . . . 61 117 14.1.2. Deployment Examples Supporting the Simple Threat 118 Model . . . . . . . . . . . . . . . . . . . . . . . . 62 119 14.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 62 120 14.3. Residual Threats . . . . . . . . . . . . . . . . . . . . . 63 121 14.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 63 122 14.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 64 123 14.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 64 124 14.3.4. Attacks Against Server Discovery . . . . . . . . . . . 64 125 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 126 15.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 64 127 15.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 65 128 15.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 65 129 15.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 65 130 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 131 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 132 17.1. Normative References . . . . . . . . . . . . . . . . . . . 66 133 17.2. Informative References . . . . . . . . . . . . . . . . . . 67 134 Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . 69 135 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 70 136 B.1. Changes from draft-ietf-pcp-base-15 to -16 . . . . . . . . 70 137 B.2. Changes from draft-ietf-pcp-base-14 to -15 . . . . . . . . 70 138 B.3. Changes from draft-ietf-pcp-base-13 to -14 . . . . . . . . 70 139 B.4. Changes from draft-ietf-pcp-base-12 to -13 . . . . . . . . 71 140 B.5. Changes from draft-ietf-pcp-base-11 to -12 . . . . . . . . 72 141 B.6. Changes from draft-ietf-pcp-base-10 to -11 . . . . . . . . 72 142 B.7. Changes from draft-ietf-pcp-base-09 to -10 . . . . . . . . 72 143 B.8. Changes from draft-ietf-pcp-base-08 to -09 . . . . . . . . 72 144 B.9. Changes from draft-ietf-pcp-base-07 to -08 . . . . . . . . 73 145 B.10. Changes from draft-ietf-pcp-base-06 to -07 . . . . . . . . 75 146 B.11. Changes from draft-ietf-pcp-base-05 to -06 . . . . . . . . 76 147 B.12. Changes from draft-ietf-pcp-base-04 to -05 . . . . . . . . 77 148 B.13. Changes from draft-ietf-pcp-base-03 to -04 . . . . . . . . 77 149 B.14. Changes from draft-ietf-pcp-base-02 to -03 . . . . . . . . 78 150 B.15. Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . . 79 151 B.16. Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . . 79 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 154 1. Introduction 156 The Port Control Protocol (PCP) provides a mechanism to control how 157 incoming packets are forwarded by upstream devices such as NAT64, 158 NAT44, IPv6 and IPv4 firewall devices, and a mechanism to reduce 159 application keepalive traffic. PCP is designed to be implemented in 160 the context of Carrier-Grade NATs (CGNs), small NATs (e.g., 161 residential NATs), as well as with dual-stack and IPv6-only CPE 162 routers, and all of the currently-known transition scenarios towards 163 IPv6-only CPE routers. PCP allows hosts to operate servers for a 164 long time (e.g., a webcam) or a short time (e.g., while playing a 165 game or on a phone call) when behind a NAT device, including when 166 behind a CGN operated by their Internet service provider or an IPv6 167 firewall integrated in their CPE router. 169 PCP allows applications to create mappings from an external IP 170 address and port to an internal IP address and port. These mappings 171 are required for successful inbound communications destined to 172 machines located behind a NAT or a firewall. 174 After creating a mapping for incoming connections, it is necessary to 175 inform remote computers about the IP address and port for the 176 incoming connection. This is usually done in an application-specific 177 manner. For example, a computer game might use a rendezvous server 178 specific to that game (or specific to that game developer), a SIP 179 phone would use a SIP proxy, and a client using DNS-Based Service 180 Discovery [I-D.cheshire-dnsext-dns-sd] would use DNS Update [RFC2136] 181 [RFC3007]. PCP does not provide this rendezvous function. The 182 rendezvous function may support IPv4, IPv6, or both. Depending on 183 that support and the application's support of IPv4 or IPv6, the PCP 184 client may need an IPv4 mapping, an IPv6 mapping, or both. 186 Many NAT-friendly applications send frequent application-level 187 messages to ensure their session will not be timed out by a NAT. 188 These are commonly called "NAT keepalive" messages, even though they 189 are not sent to the NAT itself (rather, they are sent 'through' the 190 NAT). These applications can reduce the frequency of such NAT 191 keepalive messages by using PCP to learn (and influence) the NAT 192 mapping lifetime. This helps reduce bandwidth on the subscriber's 193 access network, traffic to the server, and battery consumption on 194 mobile devices. 196 Many NATs and firewalls include application layer gateways (ALGs) to 197 create mappings for applications that establish additional streams or 198 accept incoming connections. ALGs incorporated into NATs may also 199 modify the application payload. Industry experience has shown that 200 these ALGs are detrimental to protocol evolution. PCP allows an 201 application to create its own mappings in NATs and firewalls, 202 reducing the incentive to deploy ALGs in NATs and firewalls. 204 2. Scope 206 2.1. Deployment Scenarios 208 PCP can be used in various deployment scenarios, including: 210 o Basic NAT [RFC3022] 212 o Network Address and Port Translation [RFC3022], such as commonly 213 deployed in residential NAT devices 215 o Carrier-Grade NAT [I-D.ietf-behave-lsn-requirements] 217 o Dual-Stack Lite (DS-Lite) [RFC6333] 219 o Layer-2 Aware NAT [I-D.miles-behave-l2nat] 221 o Dual-Stack Extra Lite [I-D.arkko-dual-stack-extra-lite] 223 o NAT64, both Stateless [RFC6145] and Stateful [RFC6146] 225 o IPv4 and IPv6 simple firewall control [RFC6092] 227 o NPTv6 [RFC6296] 229 2.2. Supported Protocols 231 The PCP Opcodes defined in this document are designed to support 232 transport-layer protocols that use a 16-bit port number (e.g., TCP, 233 UDP, SCTP, DCCP). Protocols that do not use a port number (e.g., 234 RSVP, IPsec ESP, ICMP, ICMPv6) are supported for IPv4 firewall, IPv6 235 firewall, and NPTv6 functions, but are out of scope for any NAT 236 functions. 238 2.3. Single-homed Customer Premises Network 240 PCP assumes a single-homed IP address model. That is, for a given IP 241 address of a host, only one default route exists to reach the 242 Internet. This is important because after a PCP mapping is created 243 and an inbound packet (e.g., TCP SYN) arrives at the host, the 244 outbound response (e.g., TCP SYNACK) has to go through the same path 245 so it is seen by the firewall or rewritten by the NAT. This 246 restriction exists because otherwise there would need to be a PCP- 247 enabled NAT for every egress (because the host could not reliably 248 determine which egress path packets would take) and the client would 249 need to be able to reliably make the same internal/external mapping 250 in every NAT gateway, which in general is not possible (because the 251 other NATs might have the necessary port mapped to another host). 253 3. Terminology 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in "Key words for use in 258 RFCs to Indicate Requirement Levels" [RFC2119]. 260 Internal Host: 261 A host served by a NAT gateway, or protected by a firewall. This 262 is the host that receives the incoming traffic resulting from a 263 PCP MAP request, or the host that initiated an implicit dynamic 264 mapping (e.g., by sending a TCP SYN) across a firewall or a NAT. 266 Remote Host: 267 A host with which an Internal Host is communicating. This can 268 include another Internal Host (or even the same Internal Host); if 269 a NAT is involved, the NAT would need to hairpin the traffic. 271 Internal Address: 272 The address of an Internal Host served by a NAT gateway or 273 protected by a firewall. 275 External Address: 276 The address of an Internal Host as seen by other Remote Peers on 277 the Internet with which the Internal Host is communicating, after 278 translation by any NAT gateways on the path. An External Address 279 is generally a public routable (i.e., non-private) address. In 280 the case of an Internal Host protected by a pure firewall, with no 281 address translation on the path, its External Address is the same 282 as its Internal Address. 284 Endpoint-Dependent Mapping (EDM): A term applied to NAT operation 285 where an implicit mapping created by outgoing traffic (e.g., TCP 286 SYN) from a single Internal Address and Port to different Remote 287 Peers and Ports may be assigned different External Ports, and a 288 subsequent PCP MAP request for that Internal Address and Port may 289 be assigned yet another different External Port. This term 290 encompasses both Address-Dependent Mapping and Address and Port- 291 Dependent Mapping from [RFC4787]. 293 Remote Peer Address: 294 The address of a Remote Peer, as seen by the Internal Host. A 295 Remote Address is generally a publicly routable address. In the 296 case of a Remote Peer that is itself served by a NAT gateway, the 297 Remote Address may in fact be the Remote Peer's External Address, 298 but since this remote translation is generally invisible to 299 software running on the Internal Host, the distinction can safely 300 be ignored for the purposes of this document. 302 Third Party: 303 In the common case, an Internal Host manages its own Mappings 304 using PCP requests, and the Internal Address of those Mappings is 305 the same as the source IP address of the PCP request packet. 307 In the case where one device is managing Mappings on behalf of 308 some other device that does not implement PCP, the presence of the 309 THIRD_PARTY Option in the MAP request signifies that the specified 310 address, rather than the source IP address of the PCP request 311 packet, should be used as the Internal Address for the Mapping. 313 Mapping, Port Mapping, Port Forwarding: 314 A NAT mapping creates a relationship between an internal IP 315 address, protocol, and port, and an external IP address, protocol, 316 and port. More specifically, it creates a translation rule where 317 packets destined to the external IP and port are translated to the 318 internal IP and port, and vice versa. In the case of a pure 319 firewall, the "Mapping" is the identity function, translating an 320 internal IP address and port number to the same external IP 321 address and port number. Firewall filtering, applied to that 322 identity function, is separate from the mapping itself. 324 Mapping Types: 325 There are three different ways to create mappings: implicit 326 dynamic mappings, explicit dynamic mappings, and static mappings. 327 Implicit dynamic mappings are created as a result of a TCP SYN or 328 outgoing UDP packet or a PCP PEER request, and allow Internal 329 Hosts to receive replies to their outbound packets. Explicit 330 dynamic mappings are created as a result of a PCP MAP request. 331 Static mappings are created by manual configuration (e.g., via 332 command-line interface or web page). Explicit and static mappings 333 allow Internal Hosts to receive inbound traffic that is not in 334 direct response to any immediately preceding outbound 335 communication (i.e., to allow Internal Hosts to operate a "server" 336 that is accessible to other hosts on the Internet). Both implicit 337 and explicit dynamic mappings are dynamic in the sense that they 338 are created on demand, as requested (implicitly or explicitly) by 339 the Internal Host, and have a lifetime. After the lifetime, the 340 mapping is deleted unless the lifetime is extended by action by 341 the Internal Host (e.g., sending more traffic or sending a new PCP 342 MAP request). Static mappings differ from dynamic mappings in 343 that their lifetime is effectively infinite (they exist until 344 manually removed) but otherwise they behave exactly the same as an 345 explicit dynamic mapping. 347 PCP Client: 348 A PCP software instance responsible for issuing PCP requests to a 349 PCP server. Several independent PCP Clients can exist on the same 350 host (just as several independent web browsers can exist on the 351 same host). Several PCP Clients can be located in the same local 352 network. A PCP Client can issue PCP requests on behalf of a third 353 party device for which it is authorized to do so. An interworking 354 function from Universal Plug and Play Internet Gateway Device 355 (UPnP IGD, [IGD]) to PCP is another example of a PCP Client. A 356 PCP server in a NAT gateway that is itself a client of another NAT 357 gateway (nested NAT) may itself act as a PCP client to the 358 upstream NAT. 360 PCP-Controlled Device: 361 A NAT or firewall that controls or rewrites packet flows between 362 internal hosts and remote hosts. PCP manages the Mappings on this 363 device. 365 PCP Server: 366 A PCP software instance that implements the server side of the PCP 367 protocol, via which PCP clients request and manage explicit 368 mappings. This is conceptually separate from the NAT or firewall 369 itself, but is typically implemented as a capability of the PCP- 370 controlled device. See also Section 4. 372 Interworking Function: 373 A functional element responsible for translating or proxying 374 another protocol to PCP. For example interworking between UPnP 375 IGD [IGD] with PCP. 377 Subscriber: 378 The unit of billing for a commercial ISP. A subscriber may have a 379 single IP address from the commercial ISP (which can be shared 380 among multiple hosts using a NAT gateway, thereby making them 381 appear to be a single host to the ISP) or may have multiple IP 382 addresses provided by the commercial ISP. In either case, the IP 383 address or addresses provided by the ISP may themselves be further 384 translated by a large-scale NAT operated by the ISP. 386 4. Relationship between PCP Server and its NAT/firewall 388 The PCP server receives and responds to PCP requests. The PCP server 389 functionality is typically a capability of a NAT or firewall device, 390 as shown in Figure 1. It is also possible for the PCP functionality 391 to be provided by some other device, which communicates with the 392 actual NAT or firewall via some other proprietary mechanism, as long 393 as from the PCP client's perspective such split operation is 394 indistinguishable from the integrated case. 396 +-----------------+ 397 +------------+ | NAT or firewall | 398 | PCP client |--+ with +--- 399 +------------+ | PCP server | 400 +-----------------+ 402 Figure 1: PCP-Enabled NAT or Firewall 404 A NAT or firewall device, between the PCP client and the Internet, 405 might implement simple or advanced firewall functionality. This may 406 be a side-effect of the technology implemented by the device (e.g., a 407 network address and port translator, by virtue of its port rewriting, 408 normally requires connections to be initiated from an inside host 409 towards the Internet), or this might be an explicit firewall policy 410 to deny unsolicited traffic from the Internet. Some firewall devices 411 deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to 412 most ports) but allow certain other unsolicited traffic from the 413 Internet (e.g., UDP port 500 and IPsec ESP as described in 414 [RFC6092]). Such default filtering (or lack thereof) is out of scope 415 of PCP itself. If a device supports PCP and wants to receive 416 traffic, and does not possess knowledge of such filtering, it SHOULD 417 use PCP to create the necessary mappings to receive the desired 418 traffic. 420 5. Note on Fixed-Size Addresses 422 For simplicity in building and parsing request and response packets, 423 PCP always uses fixed-size 128-bit IP address fields for both IPv6 424 addresses and IPv4 addresses. 426 When the address field holds an IPv6 address, the fixed-size 128-bit 427 IP address field holds the IPv6 address stored as-is. 429 When the address field holds an IPv4 address, IPv4-mapped IPv6 430 addresses [RFC4291] are used (::ffff:0:0/96). This has the first 80 431 bits set to zero and the next 16 set to one, while its last 32 bits 432 are filled with the IPv4 address. This is unambiguously 433 distinguishable from a legal IPv6 address, because IPv4-mapped IPv6 434 address [RFC4291] are not used as either the source or destination 435 address of actual IPv6 packets. 437 When checking for an IPv4-mapped IPv6 address, all of the first 96 438 bits MUST be checked for the pattern -- it is not sufficient to check 439 for 0xFF in bits 81-96. 441 The all-zeroes IPv6 address is expressed by filling the fixed-size 442 128-bit IP address field with all zeroes (::). 444 The all-zeroes IPv4 address is expressed as: 80 bits of zeros, 16 445 bits of ones, and 32 bits of zeros (::ffff:0:0). 447 6. Common Request and Response Header Format 449 All PCP messages contain a request (or response) header containing an 450 Opcode, any relevant Opcode-specific information, and zero or more 451 Options. The packet layout for the common header, and operation of 452 the PCP client and PCP server, are described in the following 453 sections. The information in this section applies to all Opcodes. 454 Behavior of the Opcodes defined in this document is described in 455 Section 9 and Section 10. 457 6.1. Request Header 459 All requests have the following format: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Version = 1 |R| Opcode | Reserved | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Requested Lifetime (32 bits) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 | PCP Client's IP address (128 bits) | 470 | | 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 : : 474 : (optional) Opcode-specific information : 475 : : 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 : : 478 : (optional) PCP Options : 479 : : 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 2: Common Request Packet Format 484 These fields are described below: 486 Version: This document specifies protocol version 1. This value 487 MUST be 1 when sending, and MUST be 1 when receiving. This field 488 is used for version negotiation as described in Section 7.6. 490 R: Indicates Request (0) or Response (1). All Requests MUST use 0. 492 Opcode: A seven-bit value specifying the operation to be performed. 493 Opcodes are defined in Section 9 and Section 10. 495 Reserved: 16 reserved bits. MUST be 0 on transmission and MUST be 496 ignored on reception. 498 Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging 499 from 0 to 4,294,967,295 seconds. This is used by the MAP and PEER 500 Opcodes defined in this document for their requested lifetime. 501 Future Opcodes which don't need this field MUST set the field to 502 zero on transmission and ignore it on reception. 504 PCP Client's IP Address: The source IPv4 or IPv6 address in the IP 505 header used by the PCP client when sending this PCP request. IPv4 506 is represented using an IPv4-mapped IPv6 address. 508 Reserved: 16 reserved bits, MUST be sent as 0 and MUST be ignored 509 when received. 511 6.2. Response Header 513 All responses have the following format: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Version = 1 |R| Opcode | Reserved | Result Code | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Lifetime (32 bits) | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Epoch (32 bits) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 | Reserved (96 bits) | 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 : : 529 : (optional) Opcode-specific response data : 530 : : 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 : (optional) Options : 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 3: Common Response Packet Format 537 These fields are described below: 539 Version: Responses MUST use version 1. 541 R: Indicates Request (0) or Response (1). All Responses MUST use 1. 543 Opcode: The 7-bit Opcode value, copied from the request. 545 Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when 546 received. This is set by the server. 548 Result Code: The result code for this response. See Section 6.4 for 549 values. This is set by the server. 551 Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 552 4,294,967,295 seconds. On an error response, this indicates how 553 long clients should assume they'll get the same error response 554 from that PCP server if they repeat the same request. On a 555 success response for the currently-defined PCP Opcodes -- MAP and 556 PEER -- this indicates the lifetime for this mapping. If future 557 Opcodes are defined that do not have a lifetime associated with 558 them, then in success responses for those Opcodes the Lifetime 559 MUST be set to zero on transmission and MUST be ignored on 560 reception. 562 Epoch: The server's Epoch value. See Section 7.5 for discussion. 563 This value is set by the server, in both success and error 564 responses. 566 Reserved: 96 reserved bits, MUST be sent as 0, MUST be ignored when 567 received. This is set by the server. 569 6.3. Options 571 A PCP Opcode can be extended with one or more Options. Options can 572 be used in requests and responses. The design decisions in this 573 specification about whether to include a given piece of information 574 in the base Opcode format or in an Option were an engineering trade- 575 off between packet size and code complexity. For information that is 576 usually (or always) required, placing it in the fixed Opcode data 577 results in simpler code to generate and parse the packet, because the 578 information is a fixed location in the Opcode data, but wastes space 579 in the packet in the event that field is all-zeroes because the 580 information is not needed or not relevant. For information that is 581 required less often, placing it in an Option results in slightly more 582 complicated code to generate and parse packets containing that 583 Option, but saves space in the packet when that information is not 584 needed. Placing information in an Option also means that an 585 implementation that never uses that information doesn't even need to 586 implement code to generate and parse it. For example, a client that 587 never requests mappings on behalf of some other device doesn't need 588 to implement code to generate the THIRD_PARTY Option, and a PCP 589 server that doesn't implement the necessary security measures to 590 create third-party mappings safely doesn't need to implement code to 591 parse the THIRD_PARTY Option. 593 Options use the following Type-Length-Value format: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Option Code | Reserved | Option Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 : (optional) data : 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 4: Options Header 605 The description of the fields is as follows: 607 Option Code: 8 bits. Its most significant bit and indicates if this 608 Option is mandatory (0) or optional (1) to process. 610 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 611 ignored on reception. 613 Option Length: 16 bits. Indicates the length of the enclosed data, 614 in octets. Options with length of 0 are allowed. Options that 615 are not a multiple of four octets long are followed by one, two, 616 or three octets of zeros to pad their effective length in the 617 packet to be a multiple of four octets. The Option Length 618 reflects the semantic length of the option, not including the 619 padding octets. 621 data: Option data. The Option data MUST end on a 32-bit boundary, 622 padded with 0's when necessary. 624 The handling of an Option by the PCP client and PCP server MUST be 625 specified in an appropriate document, which MUST include whether the 626 PCP Option can appear in a request and/or response, whether it can 627 appear more than once, and indicate what sort of Option data it 628 conveys. If several Options are included in a PCP request, they MAY 629 be encoded in any order by the PCP client, but MUST be processed by 630 the PCP server in the order in which they appear. It is the 631 responsibility of the PCP client to ensure the server has sufficient 632 room to reply with an error including UNPROCESSED Options; this can 633 be achieved by sending messages that don't exceed 1024- 634 4*number_of_options octets. 636 If, while processing an Option, an error is encountered that causes a 637 PCP error response to be generated, the PCP request MUST cause no 638 state change in the PCP server or the PCP-controlled device (i.e., it 639 rolls back any changes it might have made while processing the 640 request). The response MUST encode the Options in the same order as 641 received in the request. Additional Options included in the response 642 (if any) MUST be included at the end. An Option MAY appear more than 643 once in a request or in a response, if permitted by the definition of 644 the Option. If the Option's definition allows the Option to appear 645 only once but it appears more than once in a request, and the Option 646 is understood by the PCP server, the PCP server MUST respond with the 647 MALFORMED_OPTION result code; if this occurs in a response, the PCP 648 client processes the first occurrence and MAY log an error. If an 649 invalid option length is encountered (e.g., option length extends 650 beyond the length of the PCP Opcode itself), the error 651 MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST), 652 as that helps the client better understand how the packet was 653 malformed. The UNPROCESSED option MUST NOT appear in a request; if 654 it does, it causes a MALFORMED_REQUEST error. If a PCP response 655 would have exceeded the maximum PCP message size, the PCP server MAY 656 respond with MALFORMED_REQUEST. 658 The most significant bit in the Option Code indicates if its 659 processing is optional or mandatory. If the most significant bit is 660 set, handling this Option is optional, and a PCP server MAY process 661 or ignore this Option, entirely at its discretion. If the most 662 significant bit is clear, handling this Option is mandatory, and a 663 PCP server MUST process this Option or return an error code if it 664 cannot. If the PCP server does not implement this Option, or cannot 665 perform the function indicated by this Option (e.g., due to a parsing 666 error with the Option), it MUST generate an error response with code 667 UNSUPP_OPTION or MALFORMED_OPTION (as appropriate) and MUST include 668 the UNPROCESSED Option in the response (see Section 7.7.1). 670 PCP clients are free to ignore any or all Options included in 671 responses, although naturally if a client explicitly requests an 672 Option where correct handling of that Option requires processing the 673 Option data in the response, that client is expected to implement 674 code to do that. 676 Different options are valid for different Opcodes. For example, the 677 UNPROCESSED option is valid for all Opcodes, but only in response 678 messages. The THIRD_PARTY Option is valid for both MAP and PEER 679 Opcodes. The PREFER_FAILURE option is valid only for the MAP Opcode 680 (for the PEER Opcode, its semantics are implied). The FILTER option 681 is valid only for the MAP Opcode (for the PEER Opcode it would have 682 no meaning). 684 Option definitions MUST include the information below: 686 Option Name: 687 Number: 688 Purpose: 689 Valid for Opcodes: 690 Length: 691 May appear in: 692 Maximum occurrences: 694 6.4. Result Codes 696 The following result codes may be returned as a result of any Opcode 697 received by the PCP server. The only success result code is 0; other 698 values indicate an error. If a PCP server encounters multiple errors 699 during processing of a request, it SHOULD use the most specific error 700 message. Each error code below is classified as either a 'long 701 lifetime' error or a 'short lifetime' error, which provides guidance 702 to PCP server developers for the value of the Lifetime field for 703 these errors. It is RECOMMENDED that short lifetime errors use a 30 704 second lifetime and long lifetime errors use a 30 minute lifetime. 706 0 SUCCESS: Success. 708 1 UNSUPP_VERSION: Unsupported protocol version. 710 2 NOT_AUTHORIZED: The requested operation is disabled for this PCP 711 client, or the PCP client requested an operation that cannot be 712 fulfilled by the PCP server's security policy. This is a long 713 lifetime error. 715 3 MALFORMED_REQUEST: The request could not be successfully parsed. 717 4 UNSUPP_OPCODE: Unsupported Opcode. 719 5 UNSUPP_OPTION: Unsupported Option. This error only occurs if the 720 Option is in the mandatory-to-process range. 722 6 MALFORMED_OPTION: Malformed Option (e.g., appears too many times, 723 invalid length). 725 7 NETWORK_FAILURE: The PCP server or the device it controls are 726 experiencing a network failure of some sort (e.g., has not 727 obtained an External IP address). This is a short lifetime error. 729 8 NO_RESOURCES: Request is well-formed and valid, but the server has 730 insufficient resources to complete the requested operation at this 731 time. For example, the NAT device cannot create more mappings at 732 this time, is short of CPU cycles or memory, or due to some other 733 temporary condition. The same request may succeed in the future. 735 This is a system-wide error, and different from USER_EX_QUOTA. 736 This is a short lifetime error. This can be used as a catch-all 737 error, should no other error message be suitable. 739 9 UNSUPP_PROTOCOL: Unsupported Protocol. This is a long lifetime 740 error. 742 10 USER_EX_QUOTA: Mapping would exceed user's port quota. This is a 743 short lifetime error. 745 11 CANNOT_PROVIDE_EXTERNAL_PORT: the requested external port cannot 746 be provided. This error MUST only be returned for PEER requests, 747 for MAP requests that included the PREFER_FAILURE Option (because 748 otherwise a new external port could have been assigned), or MAP 749 requests for the SCTP protcool. See Section 11.2 for processing 750 details. The error lifetime depends on the reason for the 751 failure. 753 12 ADDRESS_MISMATCH: the source IP address or port of the request 754 packet does not match the contents of the PCP Client's IP Address 755 or UDP port. 757 13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the 758 filters in this request. This result code MUST only be returned 759 if the MAP request contained the FILTER Option. See Section 11.3 760 for processing information. This is a long lifetime error. 762 7. General PCP Operation 764 PCP messages MUST be sent over UDP [RFC0768]. Every PCP request 765 generates a response, so PCP does not need to run over a reliable 766 transport protocol. 768 PCP is idempotent, meaning that if the PCP client sends the same 769 request multiple times (or the PCP client sends the request once and 770 it is duplicated by the network), and the PCP server processes those 771 requests multiple times, the result is the same as if the PCP server 772 had processed only one of those duplicate requests. 774 7.1. General PCP Client: Generating a Request 776 This section details operation specific to a PCP client, for any 777 Opcode. Procedures specific to the MAP Opcode are described in 778 Section 9, and procedures specific to the PEER Opcode are described 779 in Section 10. 781 Prior to sending its first PCP message, the PCP client determines 782 which server to use. The PCP client performs the following steps to 783 determine its PCP server: 785 1. if a PCP server is configured (e.g., in a configuration file or 786 via DHCP), that single configuration source is used as the list 787 of PCP Server(s), else; 789 2. the default router list (for IPv4 and IPv6) is used as the list 790 of PCP Server(s). 792 For the purposes of this document, only a single PCP server address 793 is supported. Should future specifications define configuration 794 methods that provide a list of PCP server addresses, those 795 specifications will define how clients select one or more addresses 796 from that list. 798 With that PCP server address, the PCP client formulates its PCP 799 request. The PCP request contains a PCP common header, PCP Opcode 800 and payload, and (possibly) Options. As with all UDP or TCP client 801 software on any operating system, when several independent PCP 802 clients exist on the same host, each uses a distinct source port 803 number to disambiguate their requests and replies. The PCP client's 804 source port SHOULD be randomly generated [RFC6056]. 806 To assist with detecting an on-path NAT, the PCP client MUST include 807 the source IP address of the PCP message in the PCP request. This is 808 typically its own IP address; see Section 12.4 for how this can be 809 coded. 811 When attempting to contact a PCP server, the PCP client initializes a 812 timer to 2 seconds. The PCP client sends a PCP message to the first 813 server in its list of PCP servers. If no response is received before 814 the timer expires, the timer is doubled (to 4 seconds) and the 815 request is re-transmitted. If no response is received before the 816 timer expires, the timer is doubled again (to 8 seconds) and the 817 request is re-transmitted. 819 Once a PCP client has successfully received a response from a PCP 820 server on that interface, it sends subsequent PCP requests to that 821 same server, with a retransmission timer of 2 seconds. If, after 2 822 seconds, a response is not received from that PCP server, the same 823 back-off algorithm described above is performed. 825 7.2. General PCP Server: Processing a Request 827 This section details operation specific to a PCP server. Processing 828 SHOULD be performed in the order of the following paragraphs. 830 A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests 831 from a client on the same interface it would normally receive packets 832 from that client, and MUST silently ignore PCP requests arriving on 833 any other interface. For example, a residential NAT gateway accepts 834 PCP requests only when they arrive on its (LAN) interface connecting 835 to the internal network, and silently ignores any PCP requests 836 arriving on its external (WAN) interface. A PCP server which 837 supports THIRD_PARTY requests MAY be configured to accept THIRD_PARTY 838 requests on other interfaces from properly authorized clients. 840 Upon receiving a request, the PCP server parses and validates it. A 841 valid request contains a valid PCP common header, one valid PCP 842 Opcode, and zero or more Options (which the server might or might not 843 comprehend). If an error is encountered during processing, the 844 server generates an error response which is sent back to the PCP 845 client. Processing an Opcode and the Options are specific to each 846 Opcode. 848 If the received message is at least two octets long but the first 849 octet (version) is a version that is not supported, a response is 850 generated with the UNSUPP_VERSION result code, and the other steps 851 detailed in Section 7.6 are followed. 853 Otherwise, if the version is supported but the received message is 854 shorter than 4 octets or has the R bit set, the message is silently 855 dropped. 857 If the server is overloaded by requests (from a particular client or 858 from all clients), it MAY simply discard requests, as the requests 859 will be retried by PCP clients, or it MAY generate the NO_RESOURCES 860 error response. 862 If the length of the message exceeds 1024 octets or is not a multiple 863 of 4 octets, it is invalid. Invalid requests are handled by copying 864 up to 1024 octets of the request into the response, setting the 865 result code to MALFORMED_REQUEST, and zero-padding the response to a 866 multiple of 4 octets if necessary. 868 The PCP server compares the IP address (from the IP header) with the 869 field PCP Client IP Adddress. If they do not match, the error 870 ADDRESS_MISMATCH MUST be returned. This is done to detect and 871 prevent accidental use of PCP where a non-PCP-aware NAT exists 872 between the PCP client and PCP server. If the PCP client wants such 873 a mapping it needs to ensure the PCP field matches the IP address 874 from the perspective of the PCP server. 876 Error responses have the same packet layout as success responses, 877 with fields from the request copied into the response, and fields 878 assigned by the PCP server set as indicated in Figure 3. 880 Copying request fields are important because this is what enables a 881 client to identify to which request a given error response pertains. 882 For OpCodes that are understood by the PCP server, it follows the 883 requirements of that OpCode to copy the appropriate fields. For 884 OpCodes that are not understood by the PCP server, it simply 885 generates the UNSUPP_OPCODE response and copies fields from the PCP 886 header and copies the rest of the PCP payload as-is (without 887 attempting to interpret it). 889 7.3. General PCP Client: Processing a Response 891 The PCP client receives the response and verifies that the source IP 892 address and port belong to the PCP server of an outstanding PCP 893 request. It validates that the Opcode matches an outstanding PCP 894 request. Responses shorter than 24 octets, longer than 1024 octets, 895 or not a multiple of 4 octets are invalid and ignored, likely causing 896 the request to be re-transmitted. The response is further matched by 897 comparing fields in the response Opcode-specific data to fields in 898 the request Opcode-specific data, as described by the processing for 899 that Opcode. After these matches are successful, the PCP client 900 checks the Epoch field to determine if it needs to restore its state 901 to the PCP server (see Section 7.5). 903 If the PCP Client's IP Address and PCP Client's Port fields of the 904 PCP response header do not match the source address and port of the 905 request, it indicates the presence of a NAT between the PCP client 906 and PCP server. If they don't match, then the PCP client (or the 907 user on the client host) MUST ensure that an appropriate NAT mapping 908 is created on the intervening NAT(s) (e.g., using UPnP IGD, NAT-PMP, 909 or manual configuration), otherwise, the PCP-installed mapping will 910 be ineffective. 912 If the result code is 0 (SUCCESS), the PCP client knows the request 913 was successful. 915 If the result code is not 0, the request failed. If the result code 916 is UNSUPP_VERSION, processing continues as described in Section 7.6. 917 If the result code is NO_RESOURCES, PCP client SHOULD NOT send *any* 918 further requests to that PCP server for the indicated error lifetime. 919 For other error result codes, the PCP client SHOULD NOT resend the 920 same request for the indicated error lifetime. If the PCP server 921 indicates an error lifetime in excess of 30 minutes, the PCP client 922 MAY choose to set its retry timer to 30 minutes. 924 If the PCP client has discovered a new PCP server (e.g., connected to 925 a new network), the PCP client MAY immediately begin communicating 926 with this PCP server, without regard to hold times from communicating 927 with a previous PCP server. 929 7.4. Multi-Interface Issues 931 Hosts which desire a PCP mapping might be multi-interfaced (i.e., own 932 several logical/physical interfaces). Indeed, a host can be 933 configured with several IPv4 addresses (e.g., WiFi and Ethernet) or 934 dual-stacked. These IP addresses may have distinct reachability 935 scopes (e.g., if IPv6 they might have global reachability scope as 936 for Global Unicast Address (GUA, [RFC3587]) or limited scope as for 937 Unique Local Address (ULA) [RFC4193]). 939 IPv6 addresses with global reachability (e.g., GUA) SHOULD be used as 940 the source address when generating a PCP request. IPv6 addresses 941 without global reachability (e.g., ULA [RFC4193]), SHOULD NOT be used 942 as the source interface when generating a PCP request. If IPv6 943 privacy addresses [RFC4941] are used for PCP mappings, a new PCP 944 request will need to be issued whenever the IPv6 privacy address is 945 changed. This PCP request SHOULD be sent from the IPv6 privacy 946 address itself. It is RECOMMENDED that mappings to the previous 947 privacy address be deleted. 949 Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope 950 (e.g., private addresses [RFC1918]) MAY be used as the source 951 interface when generating a PCP request. 953 As mentioned in Section 2.3, only single-homed CP routers are in 954 scope. Therefore, there is no viable scenario where a host located 955 behind a CP router is assigned two Global Unicast Addresses belonging 956 to different global IPv6 prefixes. 958 7.5. Epoch 960 Every PCP response sent by the PCP server includes an Epoch time 961 field. This time field increments by 1 every second. Anomalies in 962 the received Epoch time value provide a hint to PCP clients that a 963 PCP server state loss may have occurred. Clients respond to such 964 state loss hints by promptly renewing their mappings, so as to 965 quickly restore any lost state at the PCP server. 967 If the PCP server resets or loses the state of its explicit dynamic 968 Mappings (that is, those mappings created by PCP requests), due to 969 reboot, power failure, or any other reason, it MUST reset its Epoch 970 time to its initial starting value (usually zero) to provide this 971 hint to PCP clients. After resetting its Epoch time, the PCP server 972 resumes incrementing the Epoch time value by one every second. 973 Similarly, if the public IP address(es) of the NAT (controlled by the 974 PCP server) changes, the Epoch time MUST be reset. A PCP server MAY 975 maintain one Epoch time value for all PCP clients, or MAY maintain 976 distinct Epoch time values (per PCP client, per interface, or based 977 on other criteria); this choice is implementation-dependent. 979 Whenever a client receives a PCP response, the client validates the 980 received Epoch time value according to the procedure below, using 981 integer arithmetic: 983 o If this is the first PCP response the client has received from 984 this PCP server, it is treated as necessarily valid, otherwise 986 * If the current PCP server Epoch time value 987 (current_server_time) is less than the previously received PCP 988 server Epoch time value (previous_server_time) then the client 989 treats the Epoch time value as obviously invalid (time should 990 not go backwards), else 992 + The client computes the difference between the 993 current PCP server Epoch time value (current_server_time) 994 and the 995 previously received Epoch time value (previous_server_time): 996 server_delta = current_server_time - previous_server_time; 998 + The client computes the difference between the 999 current local time value (current_client_time) and the 1000 time the previous PCP response was received from this PCP 1001 server (previous_client_time): 1002 client_delta = current_client_time - previous_client_time; 1004 + If client_delta+2 < server_delta - server_delta/8 1005 or server_delta+2 < client_delta - client_delta/8 1006 then the client treats the Epoch time value as invalid, 1007 else the client treats the Epoch time value as valid 1009 o The client records the current time values for use in its next 1010 comparison: 1011 previous_server_time = current_server_time 1012 previous_client_time = current_client_time 1014 If the PCP client determined that the Epoch time value it received 1015 was invalid then it concludes that the PCP server may have lost 1016 state, and promptly renews all its active port mapping leases as 1017 described in Section 12.3.1. 1019 Note: The "+2" in the calculations above is to accomodate 1020 quantization errors in client and server clocks (up to one second 1021 quantization error each in server and client time intervals). 1023 Note: The "/8" in the calculations above is to accomodate inaccurate 1024 clocks in low-cost devices. This value allows for a difference of up 1025 to 12.5% in clock rate between PCP client and server to be treated as 1026 benign by the client. This value has not been discussed by the PCP 1027 working group. If we were to require more accurate clocks in low- 1028 cost devices then more restrictive error tolerances could be imposed, 1029 such as "/64" or "/256". 1031 7.6. Version Negotiation 1033 A PCP client sends its requests using PCP version number 1. Should 1034 later updates to this document specify different message formats with 1035 a version number greater than 1 it is expected that PCP servers will 1036 still support version 1 in addition to the newer version(s). 1037 However, in the event that a server returns a response with result 1038 code UNSUPP_VERSION, the client MAY log an error message to inform 1039 the user that it is too old to work with this server. 1041 Should later updates to this document specify different message 1042 formats with a version number greater than 1, and backwards 1043 compatibility is desired, these first two octets can be used for 1044 forward and backward compatibility. 1046 If future PCP versions greater than 1 are specified, version 1047 negotiation proceeds as follows: 1049 1. If a client or server supports more than one version it SHOULD 1050 support a contiguous range of versions -- i.e., a lowest version 1051 and a highest version and all versions in between. 1053 2. The client sends first request using highest (i.e., presumably 1054 'best') version number it supports. 1056 3. If the server supports that version it responds normally. 1058 4. If the server does not support that version it replies giving a 1059 result containing the result code UNSUPP_VERSION, and the closest 1060 version number it does support (if the server supports a range of 1061 versions higher than the client's requested version, the server 1062 returns the lowest of that supported range; if the server 1063 supports a range of versions lower than the client's requested 1064 version, the server returns the highest of that supported range). 1066 5. If the client receives an UNSUPP_VERSION result containing a 1067 version it does support, it records this fact and proceeds to use 1068 this message version for subsequent communication with this PCP 1069 server (until a possible future UNSUPP_VERSION response if the 1070 server is later updated, at which point the version negotiation 1071 process repeats). 1073 6. If the client receives an UNSUPP_VERSION result containing a 1074 version it does not support then the client MAY log an error 1075 message to inform the user that it is too old to work with this 1076 server, and the client SHOULD set a timer to retry its request in 1077 30 minutes or the returned Lifetime value, whichever is smaller. 1079 7.7. General PCP Option 1081 The following Option can appear in certain PCP responses, without 1082 regard to the Opcode. 1084 7.7.1. UNPROCESSED Option 1086 If the PCP server cannot process a mandatory-to-process Option, for 1087 whatever reason, it includes the UNPROCESSED Option in the response, 1088 shown in Figure 5. This helps with debugging interactions between 1089 the PCP client and PCP server. This Option MUST NOT appear more than 1090 once in a PCP response. The unprocessed Options are listed once, and 1091 the Option data is zero-filled to the necessary 32 bit boundary. If 1092 a certain Option appeared more than once in the PCP request, that 1093 Option value MAY appear once or as many times as it occurred in the 1094 request. The order of the Options in the PCP request has no 1095 relationship with the order of the Option values in this UNPROCESSED 1096 Option. This Option MUST NOT appear in a response unless the 1097 associated request contained at least one mandatory-to-process 1098 Option. 1100 The UNPROCESSED Option is formatted as follows: 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Option Code=0 | Reserved | Option Length=variable | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Option-code-1 | ... additional option-codes as necessary | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Figure 5: UNPROCESSED option 1112 Option Name: UNPROCESSED 1113 Number: 0 1114 Purpose: indicates which PCP Options in the request were not 1115 processed by the PCP server 1116 Valid for Opcodes: all 1117 Length: 1 octet or more 1118 May appear in: responses, and only if the result code is non-zero. 1119 Maximum occurrences: 1 1121 8. Introduction to MAP and PEER Opcodes 1123 There are four uses for the MAP and PEER Opcodes defined in this 1124 document: 1126 o a host operating a server and wanting an incoming connection 1127 (Section 8.1); 1129 o a host operating a client and server on the same port 1130 (Section 8.2); 1132 o a host operating a client and wanting to optimize the application 1133 keepalive traffic (Section 8.3); 1135 o and a host operating a client and wanting to restore lost state in 1136 its NAT (Section 8.4). 1138 These are discussed in the following sections. 1140 When operating a server (Section 8.1 and Section 8.2) the PCP client 1141 knows if it wants an IPv4 listener, IPv6 listener, or both on the 1142 Internet. The PCP client also knows if it has an IPv4 address or 1143 IPv6 address configured on one of its interfaces. It takes the union 1144 of this knowledge to decide to which of its PCP servers to send the 1145 request (e.g., a PCP server on its IPv4 interface or its IPv6 1146 interface), and if to send one or two MAP requests for each of its 1147 interfaces (e.g., if the PCP client has only an IPv4 address but 1148 wants both IPv6 and IPv4 listeners, it sends a MAP request containing 1149 the all-zeros IPv6 address in the Requested External Address field, 1150 and sends a second MAP request containing the all-zeros IPv4 address 1151 in the Requested External Address field. If the PCP client has both 1152 an IPv4 and IPv6 address, and only wants an IPv4 listener, it sends 1153 one MAP request from its IPv4 interface (if the PCP server supports 1154 NAT44 or IPv4 firewall) or one MAP request from its IPv6 interface 1155 (if the PCP server supports NAT64)). The PCP client can simply 1156 request the desired mapping to determine if the PCP server supports 1157 the desired mapping. Applications that embed IP addresses in 1158 payloads (e.g., FTP, SIP) will find it beneficial to avoid address 1159 family translation, if possible. 1161 It is REQUIRED that the PCP-controlled device assign the same 1162 external IP address to PCP-created explicit dynamic mappings and to 1163 implicit dynamic mappings for a given Internal Host. In the absence 1164 of a PCP option indicating otherwise, it is REQUIRED that PCP-created 1165 explicit dynamic mappings be assigned the same external IP address. 1166 It is RECOMMENDED that static mappings for that Internal Host (e.g., 1167 those created by a command-line interface on the PCP server or PCP- 1168 controlled device) also be assigned to the same IP address. Once all 1169 internal addresses assigned to a given Internal Host have no implicit 1170 dynamic mappings and have no explicit dynamic mappings in the PCP- 1171 controlled device, a subsequent PCP request for that Internal Address 1172 MAY be assigned to a different External Address. Generally, this re- 1173 assignment would occur when a CGN device is load balancing newly-seen 1174 hosts to its public IPv4 address pool. 1176 The following table summarizes how various common PCP deployments use 1177 IPv6 and IPv4 addresses. The 'source' is the source address of the 1178 PCP packet itself, 'internal' is the Internal IP Address field of the 1179 THIRD_PARTY Option (if present) or the same as the source address of 1180 the PCP packet iself (if the THIRD_PARTY Option is not present), 1181 'external' is the Requested External Address field of the MAP or PEER 1182 request, the 'remote peer' is the Remote Peer IP Address of the PEER 1183 request or the FILTER option of the MAP request. 1185 source internal external remote peer 1186 ------ -------- ------- ----------- 1187 IPv4 firewall IPv4 IPv4 IPv4 IPv4 1188 IPv6 firewall IPv6 IPv6 IPv6 IPv6 1189 NAT44 IPv4 IPv4 IPv4 IPv4 1190 DS-Lite plain mode (1) IPv6 IPv4 IPv4 IPv4 1191 DS-Lite encap. (2) IPv4 IPv4 IPv4 IPv4 1192 NAT64 (3) IPv6 IPv6 IPv4 IPv6 1193 NPTv6 IPv6 IPv6 IPv6 IPv6 1195 Figure 6: Address Families with MAP and PEER 1197 In (1) and (2), 'source' refers to the PCP messaging between the 1198 Dual-Stack Lite B4 element and the AFTR element, with (1) showing 1199 Dual-Stack Lite plain mode and (2) showing Dual-Stack Lite 1200 encapsulation mode [I-D.dupont-pcp-dslite]. In a Dual-Stack Lite 1201 environment within the subscriber's network from a host to the B4 1202 element, the PCP messaging is IPv4 firewall, IPv6 firewall, or NAT44. 1203 In (3), the IPv6 PCP client is not necessarily aware of the NAT64 or 1204 aware of the actual IPv4 address of the remote peer, so it expresses 1205 the IPv6 address from its perspective as shown in the table. 1207 Note that PCP requests containing the MAP or PEER Opcodes cannot 1208 delete or shorten the lifetime of an existing implicit mapping for 1209 the indicated internal address and port. Conceptually implicit and 1210 explicit mappings are different "layers" in the NAT forwarding state 1211 database. 1213 8.1. For Operating a Server 1215 A host operating a server (e.g., a web server) listens for traffic on 1216 a port, but the server never initiates traffic from that port. For 1217 this to work across a NAT or a firewall, the host needs to (a) create 1218 a mapping from a public IP address and port to itself as described in 1219 Section 9 and (b) publish that public IP address and port via some 1220 sort of rendezvous server (e.g., DNS, a SIP message, a proprietary 1221 protocol). Publishing the public IP address and port is out of scope 1222 of this specification. To accomplish (a), the host follows the 1223 procedures described in this section. 1225 As normal, the application needs to begin listening on a port. Then, 1226 the application constructs a PCP message with the MAP Opcode, with 1227 the external address set to the appropriate all-zeroes address, 1228 depending on whether it wants a public IPv4 or IPv6 address. 1230 The following pseudo-code shows how PCP can be reliably used to 1231 operate a server: 1233 /* start listening on the local server port */ 1234 int s = socket(...); 1235 bind(s, ...); 1236 listen(s, ...); 1238 getsockname(s, &internal_sockaddr, ...); 1239 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1241 while (1) 1242 { 1243 /* Note: the "time_to_send_pcp_request()" check below includes: 1244 * 1. Sending the first request 1245 * 2. Retransmitting requests due to packet loss 1246 * 3. Resending a request due to impending lease expiration 1247 * The PCP packet sent is identical in all cases, apart from the 1248 * Suggested External Address and Port which may differ between 1249 * (1), (2), and (3). 1250 */ 1251 if (time_to_send_pcp_request()) 1252 pcp_send_map_request(internal_sockaddr.sin_port, 1253 internal_sockaddr.sin_addr, 1254 &external_sockaddr, /* will be zero the first time */ 1255 requested_lifetime, &assigned_lifetime); 1257 if (pcp_response_received()) 1258 update_rendezvous_server("Client Ident", external_sockaddr); 1260 if (received_incoming_connection_or_packet()) 1261 process_it(s); 1263 if (other_work_to_do()) 1264 do_it(); 1266 /* ... */ 1268 block_until_we_need_to_do_something_else(); 1269 } 1271 Figure 7: Pseudo-code for using PCP to operate a server 1273 8.2. For Operating a Symmetric Client/Server 1275 A host operating a client and server on the same port (e.g., 1276 Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) 1277 [RFC3581]) first establishes a local listener, (usually) sends the 1278 local and public IP addresses and ports to a rendezvous service 1279 (which is out of scope of this document), and initiates an outbound 1280 connection from that same source address and same port. To 1281 accomplish this, the application uses the procedure described in this 1282 section. 1284 An application that is using the same port for outgoing connections 1285 as well as incoming connections MUST first signal its operation of a 1286 server using the PCP MAP Opcode, as described in Section 9, and 1287 receive a positive PCP response before it sends any packets from that 1288 port. 1290 Discussion: In general, a PCP client doesn't know in advance if it 1291 is behind a NAT or firewall. On detecting the host has connected 1292 to a new network, the PCP client can attempt to request a mapping 1293 using PCP, and if that succeeds then the client knows it has 1294 successfully created a mapping. If after multiple retries it has 1295 received no PCP response, then either the client is *not* behind a 1296 NAT or firewall and has unfettered connectivity, or the client 1297 *is* behind a NAT or firewall which doesn't support PCP (and the 1298 client may still have working connectivity by virtue of static 1299 mappings previously created manually by the user). Retransmitting 1300 PCP requests multiple times before giving up and assuming 1301 unfettered connectivity adds delay in that case. Initiating 1302 outbound TCP connections immediately without waiting for PCP 1303 avoids this delay, and will work if the NAT has endpoint- 1304 independent mapping (EIM) behavior, but may fail if the NAT has 1305 endpoint-dependent mapping (EDM) behavior. Waiting enough time to 1306 allow an explicit PCP MAP Mapping to be created (if possible) 1307 first ensures that the same External Port will then be used for 1308 all subsequent TCP SYNs sent from the specified Internal Address 1309 and Port. PCP supports both EIM and EDM NATs, so clients need to 1310 assume they may be dealing with an EDM NAT. In this case, the 1311 client will experience more reliable connectivity if it attempts 1312 explicit PCP MAP requests first, before initiating any outbound 1313 TCP connections from that Internal Address and Port. See also 1314 Section 12.1. 1316 The following pseudo-code shows how PCP can be used to operate a 1317 symmetric client and server: 1319 /* start listening on the local server port */ 1320 int s = socket(...); 1321 bind(s, ...); 1322 listen(s, ...); 1324 getsockname(s, &internal_sockaddr, ...); 1325 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1327 while (1) 1328 { 1329 /* Note: the "time_to_send_pcp_request()" check below includes: 1330 * 1. Sending the first request 1331 * 2. Retransmitting requests due to packet loss 1332 * 3. Resending a request due to impending lease expiration 1333 * The PCP packet sent is identical in all cases, apart from the 1334 * Suggested External Address and Port which may differ between 1335 * (1), (2), and (3). 1336 */ 1337 if (time_to_send_pcp_request()) 1338 pcp_send_map_request(internal_sockaddr.sin_port, 1339 internal_sockaddr.sin_addr, 1340 &external_sockaddr, /* will be zero the first time */ 1341 requested_lifetime, &assigned_lifetime); 1343 if (pcp_response_received()) 1344 update_rendezvous_server("Client Ident", external_sockaddr); 1346 if (received_incoming_connection_or_packet()) 1347 process_it(s); 1349 if (need_to_make_outgoing_connection()) 1350 make_outgoing_connection(s, ...); 1352 if (data_to_send()) 1353 send_it(s); 1355 if (other_work_to_do()) 1356 do_it(); 1358 /* ... */ 1360 block_until_we_need_to_do_something_else(); 1361 } 1363 Figure 8: Pseudo-code for using PCP to operate a symmetric client/ 1364 server 1366 8.3. For Reducing NAT Keepalive Messages 1368 A host operating a client (e.g., XMPP client, SIP client) sends from 1369 a port, and may receive responses, but never accepts incoming 1370 connections from other Remote Peers on this port. It wants to ensure 1371 the flow to its Remote Peer is not terminated (due to inactivity) by 1372 an on-path NAT or firewall. To accomplish this, the application uses 1373 the procedure described in this section. 1375 Middleboxes such as NATs or firewalls need to see occasional traffic 1376 or will terminate their session state, causing application failures. 1377 To avoid this, many applications routinely generate keepalive traffic 1378 for the primary (or sole) purpose of maintaining state with such 1379 middleboxes. Applications can reduce such application keepalive 1380 traffic by using PCP. 1382 Note: For reasons beyond NAT, an application may find it useful to 1383 perform application-level keepalives, such as to detect a broken 1384 path between the client and server, keep state alive on the Remote 1385 Peer, or detect a powered-down client. These keepalives are not 1386 related to maintaining middlebox state, and PCP cannot do anything 1387 useful to reduce those keepalives. 1389 To use PCP for this function, the application first connects to its 1390 server, as normal. Afterwards, it issues a PCP request with the PEER 1391 Opcode as described in Section 10. 1393 The following pseudo-code shows how PCP can be reliably used with a 1394 dynamic socket, for the purposes of reducing application keepalive 1395 messages: 1397 int s = socket(...); 1398 connect(s, &remote_peer, ...); 1400 getsockname(s, &internal_sockaddr, ...); 1401 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1403 while (1) 1404 { 1405 /* Note: the "time_to_send_pcp_request()" check below includes: 1406 * 1. Sending the first request 1407 * 2. Retransmitting requests due to packet loss 1408 * 3. Resending a request due to impending lease expiration 1409 * The PCP packet sent is identical in all cases, apart from the 1410 * Suggested External Address and Port which may differ between 1411 * (1), (2), and (3). 1412 */ 1413 if (time_to_send_pcp_request()) 1414 pcp_send_peer_request(internal_sockaddr.sin_port, 1415 internal_sockaddr.sin_addr, 1416 &external_sockaddr, /* will be zero the first time */ 1417 remote_peer, requested_lifetime, &assigned_lifetime); 1419 if (data_to_send()) 1420 send_it(s); 1422 if (other_work_to_do()) 1423 do_it(); 1425 /* ... */ 1427 block_until_we_need_to_do_something_else(); 1428 } 1430 Figure 9: Pseudo-code using PCP with a dynamic socket 1432 8.4. For Restoring Lost Implicit TCP Dynamic Mapping State 1434 After a NAT loses state (e.g., because of a crash or power failure), 1435 it is useful for clients to re-establish TCP mappings on the NAT. 1436 This allows servers on the Internet to see traffic from the same IP 1437 address and port, so that sessions can be resumed exactly where they 1438 were left off. This can be useful for long-lived connections (e.g., 1439 instant messaging) or for connections transferring a lot of data 1440 (e.g., FTP). This can be accomplished by first establishing a TCP 1441 connection normally and then sending a PEER request/response and 1442 remembering the External Address and External Port. Later, when the 1443 NAT has lost state, the client can send a PEER request with the 1444 Suggested External Port and Suggested External Address remembered 1445 from the previous session, which will create a mapping in the NAT 1446 that functions exactly as an implicit dynamic mapping. The client 1447 then resumes sending TCP data to the server. 1449 Note: This procedure works well for TCP, provided the NAT only 1450 creates a new implicit dynamic mapping for TCP segments with the 1451 SYN bit set (i.e., the newly-booted NAT drops the re-transmitted 1452 data segments from the client because the NAT does not have an 1453 active mapping for those segments), and if the server is not 1454 sending data that elicits a RST from the NAT. This is not the 1455 case for UDP, because a new UDP mapping will be created (probably 1456 on a different port) as soon as UDP traffic is seen by the NAT. 1458 9. MAP Opcode 1460 This section defines an Opcode which controls forwarding from a NAT 1461 (or firewall) to an Internal Host. 1463 MAP: Create an explicit dynamic mapping between an Internal 1464 Address and an External IP address. 1466 PCP Servers SHOULD provide a configuration option to allow 1467 administrators to disable MAP support if they wish. 1469 Mappings created by PCP MAP requests are, by definition, Endpoint 1470 Independent Mappings (EIM) with Endpoint Independent Filtering (EIF) 1471 (unless the FILTER Option is used), even on a NAT that usually 1472 creates Endpoint Dependent Mappings (EDM) or Endpoint Dependent 1473 Filtering (EDF) for outgoing connections, since the purpose of an 1474 (unfiltered) MAP mapping is to receive inbound traffic from any 1475 remote endpoint, not from only one specific remote endpoint. 1477 Note also that all NAT mappings (created by PCP or otherwise) are by 1478 necessity bidirectional and symmetric. For any packet going in one 1479 direction (in or out) that is translated by the NAT, a reply going in 1480 the opposite direction needs to have the corresponding opposite 1481 translation done so that the reply arrives at the right endpoint. 1482 This means that if a client creates a MAP mapping, and then later 1483 sends an outgoing packet using the mapping's internal source port, 1484 the NAT should translate that packet's Internal Address and Port to 1485 the mapping's External Address and Port, so that replies addressed to 1486 the External Address and Port are correctly translated to the 1487 mapping's Internal Address and Port. 1489 On Operating Systems that allow multiple listening clients to bind to 1490 the same Internal Port, clients MUST ensure that they have exclusive 1491 use of that Internal Port (e.g., by binding the port using 1492 INADDR_ANY, or using SO_EXCLUSIVEADDRUSE or similar) before sending 1493 their MAP request, to ensure that no other clients on the same 1494 machine are also listening on the same Internal Port. 1496 The operation of the MAP Opcode is described in this section. 1498 9.1. MAP Operation Packet Formats 1500 The MAP Opcode has a similar packet layout for both requests and 1501 responses. If the Assigned External IP address and Assigned External 1502 Port in the PCP response always match the Internal IP Address and 1503 Port in the PCP request, then the functionality is purely a firewall; 1504 otherwise it pertains to a network address translator which might 1505 also perform firewall-like functions. 1507 The following diagram shows the format of the Opcode-specific 1508 information in a request for the MAP Opcode. 1510 0 1 2 3 1511 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 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Protocol | Reserved (24 bits) | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Internal Port | Suggested External Port | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | | 1518 | Suggested External IP Address (128 bits) | 1519 | | 1520 | | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Figure 10: MAP Opcode Request Packet Format 1525 These fields are described below: 1527 Requested lifetime (in common header): Requested lifetime of this 1528 mapping, in seconds. The value 0 indicates "delete". 1530 Protocol: Upper-layer protocol associated with this Opcode. Values 1531 are taken from the IANA protocol registry [proto_numbers]. For 1532 example, this field contains 6 (TCP) if the Opcode is intended to 1533 create a TCP mapping. The value 0 has a special meaning for 'all 1534 protocols'. 1536 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1537 when received. 1539 Internal Port: Internal port for the mapping. The value 0 indicates 1540 "all ports", and is legal when the lifetime is zero (a delete 1541 request), if the Protocol does not use 16-bit port numbers, or the 1542 Protocol is 0 (meaning 'all protocols') 1544 Suggested External Port: Suggested external port for the mapping. 1545 This is useful for refreshing a mapping, especially after the PCP 1546 server loses state. If the PCP client does not know the external 1547 port, or does not have a preference, it MUST use 0. 1549 Suggested External IP Address: Suggested external IPv4 or IPv6 1550 address. This is useful for refreshing a mapping, especially 1551 after the PCP server loses state. If the PCP client does not know 1552 the external address, or does not have a preference, it MUST use 1553 the address-family-specific all-zeroes address (see Section 5). 1555 The internal address for the request is the source IP address of the 1556 PCP request message itself, unless the THIRD_PARTY Option is used. 1558 The following diagram shows the format of Opcode-specific information 1559 in a response packet for the MAP Opcode: 1561 0 1 2 3 1562 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 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Protocol | Reserved (24 bits) | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Internal Port | Assigned External Port | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | | 1569 | Assigned External IP Address (128 bits) | 1570 | | 1571 | | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 Figure 11: MAP Opcode Response Packet Format 1576 These fields are described below: 1578 Lifetime (in common header): On a success response, this indicates 1579 the lifetime for this mapping, in seconds. On an error response, 1580 this indicates how long clients should assume they'll get the same 1581 error response from the PCP server if they repeat the same 1582 request. 1584 Protocol: Copied from the request. 1586 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1587 when received. 1589 Internal Port: Copied from the request. 1591 Assigned External Port: On a success response, this is the assigned 1592 external port for the mapping. On an error response, the 1593 Suggested External Port is copied from the request. 1595 Assigned External IP Address: On a success response, this is the 1596 assigned external IPv4 or IPv6 address for the mapping. An IPv4 1597 address is encoded using IPv4-mapped IPv6 address. On an error 1598 response, the Suggested External IP Address is copied from the 1599 request. 1601 9.2. Generating a MAP Request 1603 This section and Section 9.5 describe the operation of a PCP client 1604 when sending requests with the MAP Opcode. 1606 The request MAY contain values in the Suggested External Port and 1607 Suggested External IP Address fields. This allows the PCP client to 1608 attempt to rebuild lost state on the PCP server, which improves the 1609 chances of existing connections surviving, and helps the PCP client 1610 avoid having to change information maintained at its rendezvous 1611 server. Of course, due to other activity on the network (e.g., by 1612 other users or network renumbering), the PCP server may not be able 1613 grant the suggested External IP Address and Port, and in that case it 1614 will assign a different External IP Address and Port. 1616 If the Protocol does not use 16-bit port numbers (e.g., RSVP), the 1617 port number MUST be 0. This will cause all traffic matching that 1618 protocol to be mapped. 1620 If the client wants all protocols mapped it uses Protocol 0 (zero) 1621 and Internal Port 0 (zero). 1623 9.2.1. Renewing a Mapping 1625 An existing mapping can have its lifetime extended by the PCP client. 1626 To do this, the PCP client sends a new MAP request indicating the 1627 internal port. The PCP MAP request SHOULD also include the currently 1628 assigned external IP address and port as the suggested external IP 1629 address and port, so that if the NAT gateway has lost state it can 1630 recreate the lost mapping with the same parameters. 1632 The PCP client SHOULD renew the mapping before its expiry time, 1633 otherwise it will be removed by the PCP server (see Section 9.5). To 1634 reduce the risk of inadvertent synchronization of renewal requests, a 1635 random jitter component should be included. It is RECOMMENDED that 1636 PCP clients send a single renewal request packet at a time chosen 1637 with uniform random distribution in the range 1/2 to 5/8 of 1638 expiration time. If no SUCCESS response is received, then the next 1639 renewal request should be sent 3/4 to 3/4 + 1/16 to expiration, and 1640 then another 7/8 to 7/8 + 1/32 to expiration, and so on, subject to 1641 the constraint that renewal requests MUST NOT be sent less than four 1642 seconds apart (a PCP client MUST NOT send a flood of ever-closer- 1643 together requests in the last few seconds before a mapping expires). 1645 The PCP client SHOULD impose an upper limit on this returned Assigned 1646 Lifetime value, and 24 hours is RECOMMENDED. This means if the PCP 1647 server returns an absurdly long Assigned Lifetime (e.g., 5 years), 1648 the PCP client will behave as if it received a more sane value (e.g., 1649 24 hours). 1651 9.3. Processing a MAP Request 1653 This section and Section 9.5 describe the operation of a PCP server 1654 when processing a request with the MAP Opcode. Processing SHOULD be 1655 performed in the order of the following paragraphs. 1657 The following fields from the MAP request are copied into the MAP 1658 response: Protocol, Internal Port, Requested External Address, and 1659 (if present and processed by the PCP server) the THIRD_PARTY Option. 1661 If the Requested Lifetime is non-zero, it indicates a request to 1662 create a mapping or extend the lifetime of an existing mapping. If 1663 the PCP server or PCP-controlled device does not support the Protocol 1664 or cannot create a mapping for the Protocol (e.g., because the 1665 request is for a NAT mapping instead of a firewall mapping and the 1666 PCP-controlled device is not a NAT or does not support NATting that 1667 specific Protocol), it MUST generate an UNSUPP_PROTOCOL error. If 1668 the requested Lifetime is non-zero, the Internal Port is zero, and 1669 the Protocol is non-zero, it indicates a request to map all incoming 1670 traffic for that entire Protocol. If this request cannot be 1671 fulfilled in its entirety, the error UNSUPP_PROTOCOL MUST be 1672 returned. If the requested Lifetime is non-zero, the Internal Port 1673 is zero, and the Protocol is zero, it indicates a request to map all 1674 incoming traffic for all protocols. If this request cannot be 1675 fulfilled in its entirety, the error UNSUPP_PROTOCOL MUST be 1676 returned. If the Protocol is 0 but the Internal Port is non-zero, 1677 the error MALFORMED_REQUEST MUST be returned. 1679 If the requested lifetime is zero, it indicates a request to delete 1680 an existing mapping or set of mappings. Processing of the lifetime 1681 is described in Section 9.5. 1683 If the PCP-controlled device is stateless (that is, it does not 1684 establish any per-flow state, and simply rewrites the address and/or 1685 port in a purely algorithmic fashion), the PCP server simply returns 1686 an answer indicating the external IP address and port yielded by this 1687 stateless algorithmic translation. This allows the PCP client to 1688 learn its external IP address and port as seen by remote peers. 1689 Examples of stateless translators include stateless NAT64, 1:1 NAT44, 1690 and NPTv6 [RFC6296], all of which modify addresses but not port 1691 numbers. 1693 If an Option with value less than 128 exists (i.e., mandatory to 1694 process) but that Option does not make sense (e.g., the 1695 PREFER_FAILURE Option is included in a request with lifetime=0), the 1696 request is invalid and generates a MALFORMED_OPTION error. 1698 If a mapping already exists for the requested Internal Address and 1699 Port and the PREFER_FAILURE Option is not present, the PCP server 1700 MUST refresh the lifetime of that already-existing mapping, and 1701 return the already-existing External Address and Port in its 1702 response, regardless of the Suggested External Address and Port in 1703 the request. If a mapping already exists for the requested Internal 1704 Address and Port the request contains the PREFER_FAILURE Option, but 1705 the Suggested External Address and Port do not match the actual 1706 External Address and Port of the already existing mapping, the error 1707 CANNOT_PROVIDE_EXTERNAL_PORT is returned. If an implicit mapping 1708 already exists for the requested Internal Address and Port, the 1709 mapping SHOULD be upgraded to an explicit mapping. 1711 If no mapping exists for the Internal Address and Port, and the PCP 1712 server is able to create a mapping using the Suggested External 1713 Address and Port, it SHOULD do so. This is beneficial for re- 1714 establishing state lost in the PCP server (e.g., due to a reboot). 1715 If the PCP server cannot assign the Suggested External Address and 1716 Port but can assign some other External Address and Port (and the 1717 request did not contain the PREFER_FAILURE Option) the PCP server 1718 MUST do so and return the newly assigned External Address and Port in 1719 the response. Cases where a NAT gateway cannot assign the Suggested 1720 External Address and Port include: 1722 o The Suggested External Address and Port is already assigned to 1723 another existing explicit, implicit, or static mapping (i.e., is 1724 already forwarding traffic to some other internal address and 1725 port). 1727 o The Suggested External Address and Port is already used by the NAT 1728 gateway for one of its own services (e.g., port 80 for the NAT 1729 gateway's own configuration pages). 1731 o The Suggested External Address and Port is otherwise prohibited by 1732 the PCP server's policy. 1734 o The Suggested External Address or port is invalid (e.g., 1735 127.0.0.1, ::1, multicast address, or the port 0 is not valid for 1736 the indicated protocol). 1738 o The Suggested External Address does not belong to the NAT gateway. 1740 o The Suggested External Address is not configured to be used as an 1741 external address of the firewall or NAT gateway. 1743 o The PREFER_FAILURE option is included in the request and the 1744 Suggested External Address and Port are not assignable to the PCP 1745 client, which returns the CANNOT_PROVIDE_EXTERNAL_PORT error. 1747 By default, a PCP-controlled device MUST NOT create mappings for a 1748 protocol not indicated in the request. For example, if the request 1749 was for a TCP mapping, a UDP mapping MUST NOT be created. 1751 Mappings typically consume state on the PCP-controlled device, and it 1752 is RECOMMENDED that a per-host and/or per-subscriber limit be 1753 enforced by the PCP server to prevent exhausting the mapping state. 1754 If this limit is exceeded, the result code USER_EX_QUOTA is returned. 1756 If all of the preceding operations were successful (did not generate 1757 an error response), then the requested mapping is created or 1758 refreshed as described in the request and a SUCCESS response is 1759 built. This SUCCESS response contains the same Opcode as the 1760 request, but with the "R" bit set. 1762 9.4. Processing a MAP Response 1764 This section describes the operation of the PCP client when it 1765 receives a PCP response for the MAP Opcode. 1767 After performing common PCP response processing, the response is 1768 further matched with an outstanding request by comparing the 1769 protocol, internal IP address, and internal port. Other fields are 1770 not compared, because the PCP server sets those fields. 1772 On a success response, the PCP client can use the External IP Address 1773 and Port as desired. Typically the PCP client will communicate the 1774 External IP Address and Port to another host on the Internet using an 1775 application-specific rendezvous mechanism such as DNS SRV records. 1777 The PCP client MUST also set a timer or otherwise schedule an event 1778 to renew the mapping before its lifetime expires. Renewing a mapping 1779 is performed by sending another MAP request, exactly as described in 1780 Section 9.2, except that the Suggested External Address and Port 1781 SHOULD be set to the values received in the response. From the PCP 1782 server's point of view a MAP request to renew a mapping is identical 1783 to a MAP request to request a new mapping, and is handled 1784 identically. Indeed, in the event of PCP server state loss, a 1785 renewal request from a PCP client will appear to the server to be a 1786 request for a new mapping, with a particular Suggested External 1787 Address and Port, which happens to be what the PCP server previously 1788 assigned. See also Section 12.3.2. 1790 On an error response, the client SHOULD NOT repeat the same request 1791 to the same PCP server within the lifetime returned in the response. 1793 9.5. Mapping Lifetime and Deletion 1795 The PCP client requests a certain lifetime, and the PCP server 1796 responds with the assigned lifetime. The PCP server MAY grant a 1797 lifetime smaller or larger than the requested lifetime. The PCP 1798 server SHOULD be configurable for permitted minimum and maximum 1799 lifetime, and the RECOMMENDED values are 120 seconds for the minimum 1800 value and 24 hours for the maximum. It is RECOMMENDED that the 1801 server be configurable to restrict lifetimes to less than 24 hours, 1802 because mappings will consume ports even if the Internal Host is no 1803 longer interested in receiving the traffic or is no longer connected 1804 to the network. These recommendations are not strict, and 1805 deployments should evaluate the trade offs to determine their own 1806 minimum and maximum lifetime values. 1808 Once a PCP server has responded positively to a mapping request for a 1809 certain lifetime, the port mapping is active for the duration of the 1810 lifetime unless the lifetime is reduced by the PCP client (to a 1811 shorter lifetime or to zero) or until the PCP server loses its state 1812 (e.g., crashes). Mappings created by PCP MAP requests are not 1813 special or different from mappings created in other ways. In 1814 particular, it is implementation-dependent if outgoing traffic 1815 extends the lifetime of such mappings beyond the PCP-assigned 1816 lifetime. PCP clients MUST NOT depend on this behavior to keep 1817 mappings active, and MUST explicitly renew their mappings as required 1818 by the Lifetime field in PCP response messages. 1820 If a PCP client sends a PCP MAP request to create a mapping that 1821 already exists as a static mapping, the PCP server will return a 1822 successful result, confirming that the requested mapping exists. The 1823 lifetime the PCP server returns for such a static mapping SHOULD be 1824 4294967295 (0xFFFFFFFF). There is no need for a PCP client to renew 1825 a static mapping. 1827 If the requested lifetime is zero then: 1829 o If both the internal port and protocol are non-zero, it indicates 1830 a request to delete the indicated mapping immediately. 1832 o If both the internal port and protocol are zero, it indicates a 1833 request to delete all mappings for this Internal Address for all 1834 transport protocols. This is useful when a host reboots or joins 1835 a new network, to clear out prior stale state from the NAT gateway 1836 before beginning to install new mappings. 1838 o If the internal port is zero and the protocol is non-zero, or the 1839 internal port is non-zero and the protocol is zero, then the 1840 request is invalid and the PCP Server MUST return a 1841 MALFORMED_REQUEST error to the client. 1843 In requests where the requested Lifetime is 0, the Suggested External 1844 Address and Suggested External Port fields MUST be set to zero on 1845 transmission and MUST be ignored on reception, and these fields MUST 1846 be copied into the Assigned External IP Address and Assigned External 1847 Port of the response. 1849 If the PCP client attempts to delete a single static mapping (i.e., a 1850 mapping created outside of PCP itself), the error NOT_AUTHORIZED is 1851 returned. If the PCP client attempts to delete a mapping that does 1852 not exist, the SUCCESS result code is returned (this is necessary for 1853 PCP to be idempotent). If the PCP MAP request was for port=0 1854 (indicating 'all ports'), the PCP server deletes all of the explicit 1855 dynamic mappings it can (but not any implicit or static mappings), 1856 and returns a SUCCESS response. If the deletion request was properly 1857 formatted and successfully processed, a SUCCESS response is generated 1858 with lifetime of 0 and the server copies the protocol and internal 1859 port number from the request into the response. An explicit dynamic 1860 mapping MUST NOT have its lifetime reduced by transport protocol 1861 messages (e.g., TCP RST, TCP FIN). 1863 An application that forgets its PCP-assigned mappings (e.g., the 1864 application or OS crashes) will request new PCP mappings. This may 1865 consume port mappings, if the application binds to a different 1866 Internal Port every time it runs. The application will also likely 1867 initiate new implicit dynamic mappings without using PCP, which will 1868 also consume port mappings. If there is a port mapping quota for the 1869 Internal Host, frequent restarts such as this may exhaust the quota. 1870 PCP provides some protections against such port consumption: When a 1871 PCP client first acquires a new IP address (e.g., reboots or joins a 1872 new network), it SHOULD remove mappings that may already be 1873 instantiated for that new Internal Address. To do this, the PCP 1874 client sends a MAP request with protocol, internal port, and lifetime 1875 set to 0. Some port mapping APIs (e.g., the 1876 "DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on 1877 Mac OS X, iOS, Windows, Linux [Bonjour]) automatically monitor for 1878 process exit (including application crashes) and automatically send 1879 port mapping deletion requests if the process that requested them 1880 goes away without explicitly relinquishing them. 1882 To reduce unwanted traffic and data corruption, External UDP and TCP 1883 ports SHOULD NOT be re-used for an interval (TIME_WAIT interval 1884 [RFC0793]). However, the PCP server SHOULD allow the previous user 1885 of an External Port to re-acquire the same port during that interval. 1887 As a side-effect of creating a mapping, ICMP messages associated with 1888 the mapping MUST be forwarded (and also translated, if appropriate) 1889 for the duration of the mapping's lifetime. This is done to ensure 1890 that ICMP messages can still be used by hosts, without application 1891 programmers or PCP client implementations needing to signal PCP 1892 separately to create ICMP mappings for those flows. 1894 9.6. Address Change Events 1896 A customer premises router might obtain a new IP address, for a 1897 variety of reasons including a reboot, power outage, DHCP lease 1898 expiry, or other action by the ISP. If this occurs, traffic 1899 forwarded to the host's previous address might be delivered to 1900 another host which now has that address. This affects both implicit 1901 dynamic mappings and explicit dynamic mappings. However, this same 1902 problem already occurs today when a host's IP address is re-assigned, 1903 without PCP and without an ISP-operated CGN. The solution is the 1904 same as today: the problems associated with host renumbering are 1905 caused by host renumbering and are eliminated if host renumbering is 1906 avoided. PCP defined in this document does not provide machinery to 1907 reduce the host renumbering problem. 1909 When an Internal Host changes its IP address (e.g., by having a 1910 different address assigned by the DHCP server) the NAT (or firewall) 1911 will continue to send traffic to the old IP address. Typically, the 1912 Internal Host will no longer receive traffic sent to that old IP 1913 address. Assuming the Internal Host wants to continue receiving 1914 traffic, it needs to install new mappings for its new IP address. 1915 The suggested external port field will not be fulfilled by the PCP 1916 server, in all likelihood, because it is still being forwarded to the 1917 old IP address. Thus, a mapping is likely to be assigned a new 1918 external port number and/or public IP address. Note that such host 1919 renumbering is not expected to happen routinely on a regular basis 1920 for most hosts, since most hosts renew their DHCP leases before they 1921 expire (or re-request the same address after reboot) and most DHCP 1922 servers honor such requests and grant the host the same address it 1923 was previously using before the reboot. 1925 A host might gain or lose interfaces while existing mappings are 1926 active (e.g., Ethernet cable plugged in or removed, joining/leaving a 1927 WiFi network). Because of this, if the PCP client is sending a PCP 1928 request to maintain state in the PCP server, it SHOULD ensure those 1929 PCP requests continue to use the same interface (e.g., when 1930 refreshing mappings). If the PCP client is sending a PCP request to 1931 create new state in the PCP server, it MAY use a different source 1932 interface or different source address. 1934 9.7. Learning the External IP Address Alone 1936 NAT-PMP [I-D.cheshire-nat-pmp] includes a mechanism to allow clients 1937 to learn the External IP Address alone, without also requesting a 1938 port mapping. In the case of PCP, this operation no longer makes 1939 sense. PCP supports Large Scale NATs (CGN) which may have a pool of 1940 External IP Addresses, not just one. A client may not be assigned 1941 any particular External IP Address from that pool until it has made 1942 at least one implicit or explicit port mapping, and even then only 1943 for as long as that implicit or explicit port mapping remains valid. 1944 Client software that just wishes to display the user's External IP 1945 Address for cosmetic purposes can achieve that by requesting a short- 1946 lived mapping and then displaying the resulting External IP Address. 1947 However, once that mapping expires a subsequent implicit or explicit 1948 dynamic mapping might be mapped to a different external IP address. 1950 10. PEER Opcode 1952 This section defines an Opcode for controlling dynamic mappings. 1954 PEER: Create an implicit dynamic mapping, or set or query an 1955 existing implicit dynamic mapping to a remote peer's IPv4 1956 address and port. 1958 The use of these Opcodes is described in this section. 1960 PCP Servers SHOULD provide a configuration option to allow 1961 administrators to disable PEER support if they wish. 1963 Because a mapping created or managed by PEER behaves almost exactly 1964 as if an implicit dynamic mapping were created by a packet sent by 1965 the host (e.g., TCP SYN sent by the host), mappings created or 1966 managed using PCP PEER requests may be Endpoint Independent Mappings 1967 (EIM) or Endpoint Dependent Mappings (EDM), with Endpoint Independent 1968 Filtering (EIF) or Endpoint Dependent Filtering (EDF), consistent 1969 with the existing behavior of the NAT gateway or firewall in question 1970 for implicit mappings it creates automatically as a result of 1971 observing outgoing traffic from Internal Hosts. 1973 10.1. PEER Operation Packet Formats 1975 The PEER Opcode allows the PCP client to create an implicit dynamic 1976 mapping (which functions similar to the host sending a TCP SYN), and 1977 allows the PCP client to manage an implicit dynamic mapping by 1978 extending its lifetime. 1980 The following diagram shows the request packet format for the PEER 1981 Opcode. This packet format is aligned with the response packet 1982 format: 1984 0 1 2 3 1985 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 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Protocol | Reserved (24 bits) | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Internal Port | Suggested External Port | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | | 1992 | Suggested External IP Address (128 bits) | 1993 | | 1994 | | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 | Remote Peer Port | Reserved (16 bits) | 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | | 1999 | Remote Peer IP Address (128 bits) | 2000 | | 2001 | | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 Figure 12: PEER Opcode Request Packet Format 2006 These fields are described below: 2008 Requested Lifetime (in common header): Requested lifetime of this 2009 mapping, in seconds. Note that, depending on the implementation 2010 of the PCP-controlled device, it may not be possible to reduce the 2011 lifetime of a mapping (or delete it, with requested lifetime=0) 2012 using PEER. 2014 Protocol: Upper-layer protocol associated with this Opcode. Values 2015 are taken from the IANA protocol registry [proto_numbers]. For 2016 example, this field contains 6 (TCP) if the Opcode is describing a 2017 TCP mapping. 2019 Reserved: 24 reserved bits, MUST be set to 0 on transmission and 2020 MUST be ignored on reception. 2022 Internal Port: Internal port for the mapping. 2024 Suggested External Port: Suggested external port for the mapping. 2025 If the PCP client does not know the external port, or does not 2026 have a preference, it MUST use 0. 2028 Suggested External IP Address: Suggested External IP Address for the 2029 mapping. If the PCP client does not know the external address, or 2030 does not have a preference, it MUST use the address-family- 2031 specific all-zeroes address (see Section 5). 2033 Remote Peer Port: Remote peer's port for the mapping. 2035 Reserved: 16 reserved bits, MUST be set to 0 on transmission and 2036 MUST be ignored on reception. 2038 Remote Peer IP Address: Remote peer's IP address from the 2039 perspective of the PCP client, so that the PCP client does not 2040 need to concern itself with NAT64 or NAT46 (which both cause the 2041 client's idea of the remote peer's IP address to differ from the 2042 remote peer's actual IP address). This field allows the PCP 2043 client and PCP server to disambiguate multiple connections from 2044 the same port on the Internal Host to different servers, and does 2045 not create or adjust the filtering associated with the mapping 2046 (for that, the FILTER option is used, Section 11.3). An IPv6 2047 address is represented directly, and an IPv4 address is 2048 represented using the IPv4-mapped address syntax (80 bits of 2049 zeros, 16 bits of ones, and 32 bits of the IPv4 address). 2051 When attempting to re-create a lost mapping, the Suggested External 2052 IP Address and Port are set to the External IP Address and Port 2053 fields received in a previous PEER response from the PCP server. On 2054 an initial PEER request, the External IP Address and Port are set to 2055 zero. 2057 Note that the PREFER_FAILURE semantics are automatically implied by 2058 PEER requests. If the Suggested External IP Address or Suggested 2059 External Port fields are non-zero, and the PCP server is unable to 2060 honor the Suggested External IP Address or Port, then the PCP server 2061 MUST return a CANNOT_PROVIDE_EXTERNAL_PORT error response. The 2062 PREFER_FAILURE Option is neither required nor allowed in PEER 2063 requests, and if PCP server receives a PEER request containing the 2064 PREFER_FAILURE Option it MUST return a MALFORMED_REQUEST error 2065 response. 2067 The following diagram shows the response packet format for the PEER 2068 Opcode: 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Protocol | Reserved (24 bits) | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Internal Port | Assigned External Port | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | | 2078 | Assigned External IP Address (128 bits) | 2079 | | 2080 | | 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Remote Peer Port | Reserved (16 bits) | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | | 2085 | Remote Peer IP Address (128 bits) | 2086 | | 2087 | | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 Figure 13: PEER Opcode Response Packet Format 2092 Lifetime (in common header): On a success response, this indicates 2093 the lifetime for this mapping, in seconds. On an error response, 2094 this indicates how long clients should assume they'll get the same 2095 error response from the PCP server if they repeat the same 2096 request. 2098 Protocol: Copied from the request. 2100 Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST 2101 be ignored on reception. 2103 Internal Port: Copied from request. 2105 Assigned External Port: On a success response, this is the assigned 2106 external port for the mapping. On an error response, the 2107 Suggested External Port is copied from the request. 2109 Assigned External IP Address: On a success response, this is the 2110 assigned external IPv4 or IPv6 address for the mapping; IPv4 or 2111 IPv6 address is indicated by the Opcode. On an error response, 2112 the Suggested External IP Address is copied from the request. 2114 Remote Peer port: Copied from request. 2116 Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST 2117 be ignored on reception. 2119 Remote Peer IP Address: Copied from the request. 2121 10.2. Generating a PEER Request 2123 This section describes the operation of a client when generating a 2124 message with the PEER Opcode. 2126 The PEER Opcode MAY be sent before or after establishing bi- 2127 directional communication with the remote peer. 2129 If sent before, this is considered a PEER-created mapping which 2130 creates a new dynamic mapping in the PCP-controlled device, which 2131 will be used for translating traffic to and from the remote peer; 2132 this mapping functions the same as if an implicit dynamic mapping 2133 were created (e.g., because of a TCP SYN from the client). This 2134 is useful for restoring a mapping after a NAT has lost its 2135 implicit mapping state (e.g., due to a crash). Note that some PCP 2136 servers and some PCP-controlled devices are expected to not 2137 support this functionality and will respond with a PCP error. 2139 If sent after, this is considered an "implicit dynamic mapping". 2140 This allows the client to learn the IP address, port, and lifetime 2141 of the assigned External Address and Port for the implicit 2142 mapping, and to extend this lifetime (for the purpose described in 2143 Section 8.3). 2145 The PEER Opcode contains a Remote Peer Address field, which is always 2146 from the perspective of the PCP client. Note that when the PCP- 2147 controlled device is performing address family translation (NAT46 or 2148 NAT64), the remote peer address from the perspective of the PCP 2149 client is different from the remote peer address on the other side of 2150 the address family translation device. 2152 10.3. Processing a PEER Request 2154 This section describes the operation of a server when receiving a 2155 request with the PEER Opcode. Processing SHOULD be performed in the 2156 order of the following paragraphs. 2158 The following fields from a PEER request are copied into the 2159 response: Protocol, Internal Port, Remote Peer IP Address, and Remote 2160 Peer Port. 2162 When an implicit dynamic mapping is created, some NATs and firewalls 2163 validate destination addresses and will not create an implicit 2164 dynamic mapping if the destination address is invalid (e.g., 2165 127.0.0.1). If a PCP-controlled device does such validation for 2166 implicit dynamic mappings, it SHOULD also do a similar validation of 2167 the Remote Peer IP Address and Port for PEER-created implicit dynamic 2168 mappings. If the validation determines the Remote Peer IP Address of 2169 a PEER request is invalid, then no mapping is created, and a 2170 MALFORMED_REQUEST error result is returned. 2172 On receiving the PEER Opcode, the PCP server examines the mapping 2173 table. If the requested mapping does not yet exist, and the 2174 Suggested External Address and Port can be honored, the mapping is 2175 created. By having PEER create such a mapping, we avoid a race 2176 condition between the PEER request or the initial outgoing packet 2177 arriving at the NAT gateway first, and allow PEER to be used to 2178 recreate an implicit dynamic mapping (see last paragraph of 2179 Section 12.3.1). If the requested mapping does not yet exist, but 2180 Suggested External Address and Port cannot be honored, the error 2181 CANNOT_PROVIDE_EXTERNAL_PORT is returned. If the requested mapping 2182 already exists, it is a request to modify that existing mapping. 2184 The PEER Opcode MAY reduce the lifetime of an existing implicit 2185 dynamic mapping created by PEER; this is implementation-dependent. 2187 If the PCP-controlled device can extend the lifetime of a mapping, 2188 the PCP server uses the smaller of its configured maximum lifetime 2189 value and the requested lifetime from the PEER request, and sets the 2190 lifetime to that value. 2192 If all of the preceding operations were successful (did not generate 2193 an error response), then a SUCCESS response is generated, with the 2194 Lifetime field containing the lifetime of the mapping. 2196 After a successful PEER response is sent, it is implementation- 2197 specific if the PCP-controlled device destroys the mapping when the 2198 lifetime expires, or if the PCP-controlled device's implementation 2199 allows traffic to keep the mapping alive. Thus, if the PCP client 2200 wants the mapping to persist beyond the lifetime reported in the 2201 response, it MUST refresh the mapping (by sending another PEER 2202 message) prior to the expiration of the lifetime. If the mapping is 2203 terminated by the TCP client or server (e.g., TCP FIN or TCP RST), 2204 the mapping will be destroyed normally; the mapping will not persist 2205 for the time indicated by Lifetime. This means the Lifetime in a 2206 PEER response indicates how long the mapping will persist in the 2207 absence of a transport termination message (e.g., TCP RST). 2209 Some transport protocols signal the end of a connection (e.g., TCP 2210 FIN, TCP RST, SCTP SHUTDOWN). After a successful PEER response is 2211 sent, the receipt of such a transport-specific message MUST NOT cause 2212 the mapping to be destroyed. Rather, the mapping is maintained until 2213 the PEER-signaled lifetime expires. If the PCP client wishes to 2214 terminate the mapping prior to this, it will send a PEER request with 2215 Lifetime set to 0, which MAY be honored by the PCP server; as stated 2216 earlier, that is implementation-dependent. 2218 10.4. Processing a PEER Response 2220 This section describes the operation of a client when processing a 2221 response with the PEER Opcode. 2223 After performing common PCP response processing, the response is 2224 further matched with a request by comparing the protocol, internal IP 2225 address, internal port, remote peer address and remote peer port. 2226 Other fields are not compared, because the PCP server changes those 2227 fields to provide information about the mapping created by the 2228 Opcode. 2230 On a successful response, the application can use the assigned 2231 lifetime value to reduce its frequency of application keepalives for 2232 that particular NAT mapping. Of course, there may be other reasons, 2233 specific to the application, to use more frequent application 2234 keepalives. For example, the PCP assigned lifetime could be one hour 2235 but the application may want to maintain state on its server (e.g., 2236 "busy" / "away") more frequently than once an hour. 2238 If the PCP client wishes to keep this mapping alive beyond the 2239 indicated lifetime, it SHOULD issue a new PCP request prior to the 2240 expiration. That is, inside->outside traffic is not sufficient to 2241 ensure the mapping will continue to exist. See Section 9.2.1 for 2242 recommended renewal timing. 2244 Note: implementations need to expect the PEER response may contain 2245 an External IP Address with a different family than the Remote 2246 Peer IP Address, e.g., when NAT64 or NAT46 are being used. 2248 11. Options for MAP and PEER Opcodes 2250 This section describes Options for the MAP and PEER Opcodes. These 2251 Options MUST NOT appear with other Opcodes, unless permitted by those 2252 other Opcodes. 2254 11.1. THIRD_PARTY Option for MAP and PEER Opcodes 2256 This Option is used when a PCP client wants to control a mapping to 2257 an Internal Host other than itself. This is used with both MAP and 2258 PEER Opcodes. 2260 The THIRD_PARTY Option is formatted as follows: 2262 0 1 2 3 2263 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 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | Option Code=1 | Reserved | Option Length=16 or 0 | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | | 2268 | Internal IP Address (128 bits) | 2269 | | 2270 | | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 Figure 14: THIRD_PARTY Option packet format 2275 The fields are described below: 2277 Internal IP Address: Internal IP address for this mapping. If the 2278 Option Length is zero, there is no Internal IP address for this 2279 mapping and this indicates "all Internal IPv4 and IPv6 Addresses 2280 for which this client is authorized" which is used to delete all 2281 pre-existing mappings with the MAP Opcode. 2283 Option Name: THIRD_PARTY 2284 Number: 1 2285 Purpose: Indicates the MAP or PEER request is for a host other 2286 than the host sending the PCP Option. 2287 Valid for Opcodes: MAP, PEER 2288 Length: 0 or 16 octets 2289 May appear in: request. May appear in response only if it 2290 appeared in the associated request. 2291 Maximum occurrences: 1 2293 A THIRD_PARTY Option MUST NOT contain the same address as the source 2294 address of the packet. A PCP server receiving a THIRD_PARTY Option 2295 specifying the same address as the source address of the packet MUST 2296 return a MALFORMED_REQUEST result code. This is because many PCP 2297 servers may not implement the THIRD_PARTY Option at all, and a client 2298 using the THIRD_PARTY Option to specify the same address as the 2299 source address of the packet will cause mapping requests to fail 2300 where they would otherwise have succeeded. 2302 A PCP server MAY be configured to permit or to prohibit the use of 2303 the THIRD_PARTY Option. If this Option is permitted, properly 2304 authorized clients may perform these operations on behalf of other 2305 hosts. If this Option is prohibited, and a PCP server receives a PCP 2306 MAP request with a THIRD_PARTY Option, it MUST generate a 2307 UNSUPP_OPTION response. 2309 It is RECOMMENDED that customer premises equipment implementing a PCP 2310 Server be configured to prohibit third party mappings by default. 2311 With this default, if a user wants to create a third party mapping, 2312 the user needs to interact out-of-band with their customer premises 2313 router (e.g., using its HTTP administrative interface). 2315 It is RECOMMENDED that service provider NAT and firewall devices 2316 implementing a PCP Server be configured to permit the THIRD_PARTY 2317 Option, when sent by a properly authorized host. If the packet 2318 arrives from an unauthorized host, the PCP server MUST generate an 2319 UNSUPP_OPTION error. 2321 Determining which PCP clients are authorized to use the THIRD_PARTY 2322 Option for which other hosts is deployment-dependent. For example, 2323 an ISP using Dual-Stack Lite could choose to allow a client 2324 connecting over a given IPv6 tunnel to manage mappings for any other 2325 host connecting over the same IPv6 tunnel, or the ISP could choose to 2326 allow only the DS-Lite B4 element to manage mappings for other hosts 2327 connecting over the same IPv6 tunnel. A cryptographic authentication 2328 and authorization model is outside the scope of this specification. 2329 Note that the THIRD_PARTY Option is not needed for today's common 2330 scenario of an ISP offering a single IP address to a customer who is 2331 using NAT to share that address locally, since in this scenario all 2332 the customer's hosts appear to be a single host from the point of 2333 view of the ISP. 2335 Where possible, it may beneficial if a client using the THIRD_PARTY 2336 Option to create and maintain mappings on behalf of some other device 2337 can take steps to verify that the other device is still present and 2338 active on the network. Otherwise the client using the THIRD_PARTY 2339 Option to maintain mappings on behalf of some other device risks 2340 maintaining those mappings forever, long after the device that 2341 required them has gone. This would defeat the purpose of PCP 2342 mappings having a finite lifetime so that they can be automatically 2343 deleted after they are no longer needed. 2345 A PCP client can delete all PCP-created explicit dynamic mappings 2346 (i.e., those created by PCP MAP requests) that it is authorized to 2347 delete by sending a PCP MAP request including a zero-length 2348 THIRD_PARTY Option. 2350 11.2. PREFER_FAILURE Option for MAP Opcode 2352 This Option is only used with the MAP Opcode. 2354 This Option indicates that if the PCP server is unable to map the 2355 Suggested External Port, the PCP server should not map an external 2356 port. This differs from the behavior without this Option, which is 2357 to map a different external port. 2359 The PREFER_FAILURE Option is formatted as follows: 2361 0 1 2 3 2362 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 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | Option Code=2 | Reserved | Option Length=0 | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 Figure 15: PREFER_FAILURE Option packet format 2369 Option Name: PREFER_FAILURE 2370 Number: 2 2371 Purpose: indicates that the PCP server should not create an 2372 alternative mapping if the suggested external port and address are 2373 not available. 2374 Valid for Opcodes: MAP 2375 Length: 0 2376 May appear in: requests 2377 Maximum occurrences: 1 2379 The result code CANNOT_PROVIDE_EXTERNAL_PORT is returned if the 2380 Suggested External Port cannot be mapped. This can occur because the 2381 External Port is already mapped to another host's implicit dynamic 2382 mapping, an explicit dynamic mapping, a static mapping, or the same 2383 Internal Address and Port has an implicit dynamic mapping which is 2384 mapped to a different External Port than requested. The server MAY 2385 set the Lifetime in the response to the remaining lifetime of the 2386 conflicting mapping, rounded up to the next larger integer number of 2387 seconds. 2389 This Option exists solely for use by UPnP IGD interworking 2390 [I-D.bpw-pcp-upnp-igd-interworking], where the semantics of UPnP IGD 2391 version 1 only allow the UPnP IGD client to dictate mapping a 2392 specific port. A PCP server MAY support this Option, if its 2393 designers wish to support downstream devices that perform UPnP IGD 2394 interworking. PCP servers MAY choose to rate-limit their handling of 2395 PREFER_FAILURE requests, to protect themselves from a rapid flurry of 2396 65535 consecutive PREFER_FAILURE requests from clients probing to 2397 discover which external ports are available. PCP servers that are 2398 not intended to support downstream devices that perform UPnP IGD 2399 interworking are not required to support this Option. PCP clients 2400 other than UPnP IGD interworking clients SHOULD NOT use this Option 2401 because it results in inefficient operation, and they cannot safely 2402 assume that all PCP servers will implement it. It is anticipated 2403 that this Option will be deprecated in the future as more clients 2404 adopt PCP natively and the need for UPnP IGD interworking declines. 2406 11.3. FILTER Option for MAP Opcode 2408 This Option is only used with the MAP Opcode. 2410 This Option indicates that filtering incoming packets is desired. 2411 The Remote Peer Port and Remote Peer IP Address indicate the 2412 permitted remote peer's source IP address and port for packets from 2413 the Internet. The remote peer prefix length indicates the length of 2414 the remote peer's IP address that is significant; this allows a 2415 single Option to permit an entire subnet. After processing this MAP 2416 request containing the FILTER Option and generating a successful 2417 response, the PCP-controlled device will drop packets received on its 2418 public-facing interface that don't match the filter fields. After 2419 dropping the packet, if its security policy allows, the PCP- 2420 controlled device MAY also generate an ICMP error in response to the 2421 dropped packet. 2423 The FILTER Option is formatted as follows: 2425 0 1 2 3 2426 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 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | Option Code=3 | Reserved | Option Length=20 | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Reserved | Prefix Length | Remote Peer Port | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | | 2433 | Remote Peer IP address (128 bits) | 2434 | | 2435 | | 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 Figure 16: FILTER Option layout 2440 These fields are described below: 2442 Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored 2443 when received. 2445 Prefix Length: indicates how many bits of the IPv4 or IPv6 address 2446 are relevant for this filter. The value 0 indicates "no filter", 2447 and will remove all previous filters. See below for detail. 2449 Remote Peer Port: the port number of the remote peer. The value 0 2450 indicates "all ports". 2452 Remote Peer IP address: The IP address of the remote peer. 2454 Option Name: FILTER 2455 Number: 3 2456 Purpose: specifies a filter for incoming packets 2457 Valid for Opcodes: MAP 2458 Length: 20 octets 2459 May appear in: requests, and MUST appear in successfully-processed 2460 responses 2461 Maximum occurrences: as many as fit within maximum PCP message 2462 size 2464 The Prefix Length indicates how many bits of the IPv6 address or IPv4 2465 address are used for the filter. For IPv4 addresses, which are 2466 represented using the IPv4-mapped address format (::FFFF:0:0/96), the 2467 value of the Prefix Length pertains only to to the IPv4 portion of 2468 the address. Thus, a Prefix Length of 32 with an IPv4-mapped address 2469 indicates "only this address". With IPv4-mapped addresses, the 2470 minimum Prefix length value is 0 and the maximum is 32; for IPv6 2471 addresses the minimum value is 0 and the maximum is 128. Values 2472 outside those range cause the PCP server to return the 2473 MALFORMED_OPTION result code. 2475 If multiple occurrences of the FILTER Option exist in the same MAP 2476 request, they are processed in the same order received (as per normal 2477 PCP Option processing) and they MAY overlap the filtering requested. 2478 If an existing mapping exists (with or without a filter) and the 2479 server receives a MAP request with FILTER, the filters indicated in 2480 the new request are added to any existing filters. If a MAP request 2481 has a lifetime of 0 and contains the FILTER Option, the error 2482 MALFORMED_OPTION is returned. 2484 If any of occurrences of the FILTER Option in a request packet are 2485 not successfully processed then an error is returned (e.g., 2486 MALFORMED_OPTION if one of the Options was malformed) and as with 2487 other PCP errors, returning an error causes no state to be changed in 2488 the PCP server or in the PCP-controlled device. 2490 To remove all existing filters, the Prefix Length 0 is used. There 2491 is no mechanism to remove a specific filter. 2493 To change an existing filter, the PCP client sends a MAP request 2494 containing two FILTER Options, the first Option containing a Prefix 2495 Length of 0 (to delete all existing filters) and the second 2496 containing the new remote peer's IP address and port. Other FILTER 2497 Options in that PCP request, if any, add more allowed Remote Peers. 2499 The PCP server or the PCP-controlled device is expected to have a 2500 limit on the number of remote peers it can support. This limit might 2501 be as small as one. If a MAP request would exceed this limit, the 2502 entire MAP request is rejected with the result code 2503 EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. 2505 All PCP servers MUST support at least one filter per MAP mapping. 2507 The use of the FILTER Option can be seen as a performance 2508 optimization. Since all software using PCP to receive incoming 2509 connections also has to deal with the case where may be directly 2510 connected to the Internet and receive unrestricted incoming TCP 2511 connections and UDP packets, if it wishes to restrict incoming 2512 traffic to a specific source address or group of source addresses 2513 such software already needs to check the source address of incoming 2514 traffic and reject unwanted traffic. However, the FILTER Option is a 2515 particularly useful performance optimization for battery powered 2516 wireless devices, because it can enable them to conserve battery 2517 power by not having to wake up just to reject a unwanted traffic. 2519 12. Implementation Considerations 2521 12.1. Implementing MAP with EDM port-mapping NAT 2523 This section provides non-normative guidance that may be useful to 2524 implementors. 2526 For implicit dynamic mappings, some existing NAT devices have 2527 endpoint-independent mapping (EIM) behavior while other NAT devices 2528 have endpoint-dependent mapping (EDM) behavior. NATs which have EIM 2529 behavior do not suffer from the problem described in this section. 2530 The IETF strongly encourages EIM behavior [RFC4787][RFC5382]. 2532 In such EDM NAT devices, the same external port may be used by an 2533 implicit dynamic mapping (from the same Internal Host or from a 2534 different Internal Host) and an explicit dynamic mapping. This 2535 complicates the interaction with the MAP Opcode. With such NAT 2536 devices, there are two ways envisioned to implement the MAP Opcode: 2538 1. Have implicit dynamic mappings use a different set of public 2539 ports than explicit dynamic mappings (e.g., those created with 2540 MAP), thus reducing the interaction problem between them; or 2542 2. On arrival of a packet (inbound from the Internet or outbound 2543 from an Internal Host), first attempt to use an implicit dynamic 2544 mapping to process that packet. If none match, then the incoming 2545 packet should use the explicit dynamic mapping to process that 2546 packet. This effectively 'prioritizes' implicit dynamic mappings 2547 above explicit dynamic mappings. 2549 12.2. Lifetime of Explicit and Implicit Dynamic Mappings 2551 This section provides non-normative guidance that may be useful to 2552 implementors. 2554 No matter if a NAT is EIM or EDM, it is possible that one (or more) 2555 implicit dynamic mappings, using the same internal port on the 2556 Internal Host, might be created before or after a MAP request. When 2557 this occurs, it is important that the NAT honor the Lifetime returned 2558 in the MAP response. Specifically, if a mapping was created with the 2559 MAP Opcode, the implementation needs to ensure that termination of an 2560 implicit dynamic mapping (e.g., via a TCP FIN handshake) does not 2561 prematurely destroy the MAP-created mapping. On a NAT that 2562 implements endpoint-independent mapping with endpoint-independent 2563 filtering, this could be implemented by extending the lifetime of the 2564 implicit dynamic mapping to the lifetime of the explicit dynamic 2565 mapping. 2567 12.3. PCP Failure Scenarios 2569 This section provides non-normative guidance that may be useful to 2570 implementors. 2572 If an event occurs that causes the PCP server to lose explicit 2573 dynamic mapping state (such as a crash or power outage), the mappings 2574 created by PCP are lost. Such loss of state is expected to be rare 2575 in a service provider environment (due to redundant power, disk 2576 drives for storage, etc.), but more common in a residential NAT 2577 device which does not write this information to non-volatile memory. 2578 Of course, due to outright failure of service provider equipment 2579 (e.g., software malfunction), state may still be lost. 2581 The Epoch allows a client to deduce when a PCP server may have lost 2582 its state. When the Epoch value is observed to be outside the 2583 expected range, the PCP client can attempt to recreate the mappings 2584 following the procedures described in this section. 2586 Further analysis of PCP failure scenarios is in 2587 [I-D.boucadair-pcp-failure]. 2589 12.3.1. Recreating Mappings 2591 This section provides non-normative guidance that may be useful to 2592 implementors. 2594 A mapping renewal packet is formatted identically to an original 2595 mapping request; from the point of view of the client it is a renewal 2596 of an existing mapping, but from the point of view of a newly 2597 rebooted PCP server it appears as a new mapping request. In the 2598 normal process of routinely renewing its mappings before they expire, 2599 a PCP client will automatically recreate all its lost mappings. 2601 When the PCP server loses state and begins processing new PCP 2602 messages, its Epoch is reset and begins counting again from zero (per 2603 the procedure of Section 7.5). As the result of receiving a packet 2604 where the Epoch field is outside the expected range, indicating that 2605 a reboot or similar loss of state has occurred, the client can renew 2606 its port mappings sooner, without waiting for the normal routine 2607 renewal time. 2609 12.3.2. Maintaining Mappings 2611 This section provides non-normative guidance that may be useful to 2612 implementors. 2614 A PCP client refreshes a mapping by sending a new PCP request 2615 containing information from the earlier PCP response. The PCP server 2616 will respond indicating the new lifetime. It is possible, due to 2617 reconfiguration or failure of the PCP server, that the public IP 2618 address and/or public port, or the PCP server itself, has changed 2619 (due to a new route to a different PCP server). To detect such 2620 events more quickly, the PCP client may find it beneficial to use 2621 shorter lifetimes (so that it communicates with the PCP server more 2622 often). If the PCP client has several mappings, the Epoch value only 2623 needs to be retrieved for one of them to determine whether or not it 2624 appears the PCP server may have suffered a catastrophic loss of 2625 state. 2627 If the client wishes to check the PCP server's Epoch, it sends a PCP 2628 request for any one of the client's mappings. This will return the 2629 current Epoch value. In that request the PCP client could extend the 2630 mapping lifetime (by asking for more time) or maintain the current 2631 lifetime (by asking for the same number of seconds that it knows are 2632 remaining of the lifetime). 2634 If a PCP client changes its Internal IP Address (e.g., because the 2635 Internal Host has moved to a new network), and the PCP client wishes 2636 to still receive incoming traffic, it needs create new mappings on 2637 that new network. New mappings will typically also require an update 2638 to the application-specific rendezvous server if the External Address 2639 or Port are different to the previous values (see Section 8.1 and 2640 Section 9.6). 2642 12.3.3. SCTP 2644 Although SCTP has port numbers like TCP and UDP, SCTP works 2645 differently when behind an address-sharing NAT, in that SCTP port 2646 numbers are not changed [I-D.ietf-behave-sctpnat]. Because implicit 2647 dynamic SCTP mappings use the verification tag of the association 2648 instead of the local and remote peer port numbers, explicit dynamic 2649 SCTP mappings need only be established by passive listeners expecting 2650 to receive new associations at the external port. 2652 Because an SCTP-aware NAT does not rewrite SCTP port numbers (and 2653 firewalls never do), a PCP MAP or PEER request for an SCTP mapping 2654 SHOULD provide the same Internal Port and Requested External Port. 2655 If the PCP server supports SCTP, and the requested external port 2656 cannot be provided in an explicit dynamic SCTP mapping, then the 2657 error CANNOT_PROVIDE_EXTERNAL_PORT is returned. 2659 12.4. Source Address and Port in PCP Header 2661 All PCP requests include the PCP client's IP address in the PCP 2662 header. This is used to detect address rewriting (NAT) between the 2663 PCP client and its PCP server. On operating systems that support the 2664 sockets API, the following steps are RECOMMENDED for a PCP client to 2665 insert the correct source address and port to include in the PCP 2666 header: 2668 1. Create a UDP socket. 2669 2. Bind the UDP socket. 2670 3. Call the getsockname() function to retrieve a sockaddr containing 2671 the source address and port the kernel will use for UDP packets 2672 sent through this socket. 2673 4. If the IP address is an IPv4 address, encode the address into an 2674 IPv4-mapped IPv6 address. Place the IPv6 address (or IPv4-mapped 2675 IPv6 address) into the PCP Client's IP Address field in the PCP 2676 header. 2677 5. Send PCP requests using this bound UDP socket. 2679 13. Deployment Considerations 2680 13.1. Ingress Filtering 2682 As with implicit dynamic mappings created by outgoing TCP packets, 2683 explicit dynamic mappings created via PCP use the source IP address 2684 of the packet as the Internal Address for the mappings. Therefore 2685 ingress filtering [RFC2827] should be used on the path between the 2686 Internal Host and the PCP Server to prevent the injection of spoofed 2687 packets onto that path. 2689 13.2. Mapping Quota 2691 On PCP-controlled devices that create state when a mapping is created 2692 (e.g., NAT), the PCP server SHOULD maintain per-host and/or per- 2693 subscriber quotas for mappings. It is implementation-specific 2694 whether the PCP server uses a separate quotas for implicit, explicit, 2695 and static mappings, a combined quota for all of them, or some other 2696 policy. 2698 14. Security Considerations 2700 The goal of the PCP protocol is to improve the ability of end nodes 2701 to control their associated NAT state, and to improve the efficiency 2702 and error handling of NAT mappings when compared to existing implicit 2703 mapping mechanisms in NAT boxes and stateful firewalls. It is the 2704 security goal of the PCP protocol to limit any new denial of service 2705 opportunities, and to avoid introducing new attacks that can result 2706 in unauthorized changes to mapping state. One of the most serious 2707 consequences of unauthorized changes in mapping state is traffic 2708 theft. All mappings that could be created by a specific host using 2709 implicit mapping mechanisms are inherently considered to be 2710 authorized. Confidentiality of mappings is not a requirement, even 2711 in cases where the PCP messages may transit paths that would not be 2712 travelled by the mapped traffic. 2714 14.1. Simple Threat Model 2716 PCP is secure against off-path attackers who cannot spoof a packet 2717 that the PCP Server will view as a packet received from the internal 2718 network. 2720 Defending against attackers who can modify or drop packets between 2721 the internal network and the PCP server, or who can inject spoofed 2722 packets that appear to come from the internal network is out-of- 2723 scope. 2725 A PCP Server is secure under this threat model if the PCP Server is 2726 constrained so that it does not configure any explicit mapping that 2727 it would not configure implicitly. In most cases, this means that 2728 PCP Servers running on NAT boxes or stateful firewalls that support 2729 the PEER Opcode can be secure under this threat model if all of their 2730 hosts are within a single administrative domain (or if the internal 2731 hosts can be securely partitioned into separate administrative 2732 domains, as in the DS-Lite B4 case), explicit mappings are created 2733 with the same lifetime as implicit mappings, the PCP server does not 2734 support deleting or reducing the lifetime of existing mappings, and 2735 the PCP server does not support the third party option. PCP Servers 2736 can also securely support the MAP Opcode under this threat model if 2737 the security policy on the device running the PCP Server would permit 2738 endpoint independent filtering of implicit mappings. 2740 PCP Servers that comply with the Simple Threat Model and do not 2741 implement a PCP security mechanism described in Section 14.2 MUST 2742 enforce the constraints described in the paragraph above. 2744 14.1.1. Attacks Considered 2746 o If you allow multiple administrative domains to send PCP requests 2747 to a single PCP server that does not enforce a boundary between 2748 the domains, it is possible for a node in one domain to perform a 2749 denial of service attack on other domains, or to capture traffic 2750 that is intended for a node in another domain. 2752 o If explicit mappings have longer lifetimes than implicit mappings, 2753 it makes it easier to perpetrate a denial of service attack than 2754 it would be if the PCP Server was not present. 2756 o If the PCP Server supports deleting or reducing the lifetime of 2757 existing mappings, this allows an attacking node to steal an 2758 existing mapping and receive traffic that was intended for another 2759 node. 2761 o If the THIRD_PARTY Option is supported, this also allows an 2762 attacker to open a window for an external node to attack an 2763 internal node, allows an attacker to steal traffic that was 2764 intended for another node, or may facilitate a denial of service 2765 attack. One example of how the THIRD_PARTY Option could grant an 2766 attacker more capability than a spoofed implicit mapping is that 2767 the PCP server (especially if it is running in a service 2768 provider's network) may not be aware of internal filtering that 2769 would prevent spoofing an equivalent implicit mapping, such as 2770 filtering between a guest and corporate network. 2772 o If the MAP Opcode is supported by the PCP server in cases where 2773 the security policy would not support endpoint independent 2774 filtering of implicit mappings, then the MAP Opcode changes the 2775 security properties of the device running the PCP Server by 2776 allowing explicit mappings that violate the security policy. 2778 14.1.2. Deployment Examples Supporting the Simple Threat Model 2780 This section offers two examples of how the Simple Threat Model can 2781 be supported in real-world deployment scenarios. 2783 14.1.2.1. Residential Gateway Deployment 2785 Parity with many currently-deployed residential gateways can be 2786 achieved using a PCP Server that is constrained as described in 2787 Section 14.1.1 above. 2789 14.1.2.2. DS-Lite Deployment 2791 A DS-Lite deployment could be secure under the Simple Threat Model, 2792 even if the B4 device makes PCP mapping requests on behalf of 2793 internal clients using the THIRD_PARTY option. In this case the DS- 2794 Lite PCP server MUST be configured to only allow the B4 device to 2795 make THIRD_PARTY requests, and only on behalf of other Internal Hosts 2796 sharing the same DS-Lite IPv6 tunnel. The B4 device MUST guard 2797 against spoofed packets being injected into the IPv6 tunnel using the 2798 B4 device's IPv4 source address, so the DS-Lite PCP Server can trust 2799 that packets received over the DS-Lite IPv6 tunnel with the B4 2800 device's source IPv4 address do in fact originate from the B4 device. 2801 The B4 device is in a position to enforce this requirement, because 2802 it is the DS-Lite IPv6 tunnel endpoint. 2804 Allowing the B4 device to use the THIRD_PARTY Option to create 2805 mappings for hosts reached via the IPv6 tunnel terminated by the B4 2806 device is acceptable, because the B4 device is capable of creating 2807 these mappings implicitly and can prevent others from spoofing these 2808 mappings. 2810 DS-Lite's security policies may also permit use of the MAP Opcode. 2812 14.2. Advanced Threat Model 2814 In the Advanced Threat Model the PCP protocol must be ensure that 2815 attackers (on- or off-path) cannot create unauthorized mappings or 2816 make unauthorized changes to existing mappings. The protocol must 2817 also limit the opportunity for on- or off-path attackers to 2818 perpetrate denial of service attacks. 2820 The Advanced Threat Model security model will be needed in the 2821 following cases: 2823 o Security infrastructure equipment, such as corporate firewalls, 2824 that does not create implicit mappings. 2826 o Equipment (such as CGNs or service provider firewalls) that serve 2827 multiple administrative domains and do not have a mechanism to 2828 securely partition traffic from those domains. 2830 o Any implementation that wants to be more permissive in authorizing 2831 explicit mappings than it is in authorizing implicit mappings. 2833 o Implementations that support the THIRD_PARTY Option (unless they 2834 can meet the constraints outlined in Section 14.1.2.2). 2836 o Implementations that wish to support any deployment scenario that 2837 does not meet the constraints described in Section 14.1. 2839 To protect against attacks under this threat model, a PCP security 2840 mechanism which provides an authenticated, integrity protected 2841 signaling channel would need to be specified. 2843 PCP Servers that implement a PCP security mechanism MAY accept 2844 unauthenticated requests. PCP Servers implementing the PCP security 2845 mechanism MUST enforce the constraints described in Section 14.1 2846 above, in their default configuration, when processing 2847 unauthenticated requests. 2849 14.3. Residual Threats 2851 This section describes some threats that are not addressed in either 2852 of the above threat models, and recommends appropriate mitigation 2853 strategies. 2855 14.3.1. Denial of Service 2857 Because of the state created in a NAT or firewall, a per-host and/or 2858 per-subscriber quota will likely exist for both implicit dynamic 2859 mappings and explicit dynamic mappings. A host might make an 2860 excessive number of implicit or explicit dynamic mappings, consuming 2861 an inordinate number of ports, causing a denial of service to other 2862 hosts. Thus, Section 13.2 recommends that hosts be limited to a 2863 reasonable number of explicit dynamic mappings. 2865 An attacker, on the path between the PCP client and PCP server, can 2866 drop PCP requests, drop PCP responses, or spoof a PCP error, all of 2867 which will effective deny service. Through such actions, the PCP 2868 client would not be aware the PCP server might have actually 2869 processed the PCP request. 2871 14.3.2. Ingress Filtering 2873 It is important to prevent a host from fraudulently creating, 2874 deleting, or refreshing a mapping (or filtering) for another host, 2875 because this can expose the other host to unwanted traffic, prevent 2876 it from receiving wanted traffic, or consume the other host's mapping 2877 quota. Both implicit and explicit dynamic mappings are created based 2878 on the source IP address in the packet, and hence depend on ingress 2879 filtering to guard against spoof source IP addresses. 2881 14.3.3. Mapping Theft 2883 In the time between when a PCP server loses state and the PCP client 2884 notices the lower than expected Epoch value, it is possible that the 2885 PCP client's mapping will be acquired by another host (via an 2886 explicit dynamic mapping or implicit dynamic mapping). This means 2887 incoming traffic will be sent to a different host ("theft"). A rapid 2888 recovery mechanism to immediately inform the PCP client of state loss 2889 would reduce this interval, but would not completely eliminate this 2890 threat. The PCP client can reduce this interval by using a 2891 relatively short lifetime; however, this increases the amount of PCP 2892 chatter. This threat is reduced by using persistent storage of 2893 explicit dynamic mappings in the PCP server (so it does not lose 2894 explicit dynamic mapping state), or by ensuring the previous external 2895 IP address and port cannot be used by another host (e.g., by using a 2896 different IP address pool). 2898 14.3.4. Attacks Against Server Discovery 2900 This document does not specify server discovery, beyond contacting 2901 the default gateway. 2903 15. IANA Considerations 2905 IANA is requested to perform the following actions: 2907 15.1. Port Number 2909 PCP will use port 5351 (currently assigned by IANA to NAT-PMP 2910 [I-D.cheshire-nat-pmp]). We request that IANA re-assign that same 2911 port number to PCP, and relinquish UDP port 44323. 2913 [Note to RFC Editor: Please remove the text about relinquishing port 2914 44323 prior to publication.] 2916 15.2. Opcodes 2918 IANA shall create a new protocol registry for PCP Opcodes, numbered 2919 0-127, initially populated with the values: 2921 value Opcode 2922 ----- ------------------------- 2923 0 Reserved for "no-op" operation code 2924 1 MAP 2925 2 PEER 2926 3-95 (specification required) 2927 96-126 (private use) 2928 127 Reserved 2930 The values 0 and 127 are Reserved and may be assigned via Standards 2931 Action [RFC5226]. The values in the range 3-95 can be assigned via 2932 Specification Required [RFC5226], and the range 96-126 is for Private 2933 Use [RFC5226]. 2935 15.3. Result Codes 2937 IANA shall create a new registry for PCP result codes, numbered 2938 0-255, initially populated with the result codes from Section 6.4. 2939 The value 255 is Reserved and may be assigned via Standards Action 2940 [RFC5226]. 2942 Result Codes in the range 13-191 can be assigned via Specification 2943 Required [RFC5226], and the range 192-254 is for Private Use 2944 [RFC5226]. 2946 15.4. Options 2948 IANA shall create a new registry for PCP Options, numbered 0-255 with 2949 an associated mnemonic. The values 0-127 are mandatory-to-process, 2950 and 128-255 are optional to process. The initial registry contains 2951 the Options described in Section 7.7.1 and Section 11. The Option 2952 values 127 and 255 are Reserved and may be assigned via Standards 2953 Action [RFC5226]. 2955 Additional PCP Option codes in the ranges 4-63 and 128-191 can be 2956 created via Specification Required [RFC5226], and the ranges 64-126 2957 and 192-254 are for Private Use [RFC5226]. 2959 16. Acknowledgments 2961 Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni 2962 Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda 2963 Costa, and James Woodyatt for their comments and review. Thanks to 2964 Simon Perreault for highlighting the interaction of dynamic 2965 connections with PCP-created mappings. 2967 Thanks to Francis Dupont for his several thorough reviews of the 2968 specification, which improved the protocol significantly. 2970 Thanks to Margaret Wasserman for writing the Security Considerations 2971 section. 2973 17. References 2975 17.1. Normative References 2977 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2978 August 1980. 2980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2981 Requirement Levels", BCP 14, RFC 2119, March 1997. 2983 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 2984 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 2985 RFC 2136, April 1997. 2987 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2988 Defeating Denial of Service Attacks which employ IP Source 2989 Address Spoofing", BCP 38, RFC 2827, May 2000. 2991 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 2992 Update", RFC 3007, November 2000. 2994 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2995 Addresses", RFC 4193, October 2005. 2997 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2998 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2999 May 2008. 3001 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 3002 Protocol Port Randomization", BCP 156, RFC 6056, 3003 January 2011. 3005 [proto_numbers] 3006 IANA, "Protocol Numbers", 2011, . 3009 17.2. Informative References 3011 [Bonjour] "Bonjour", 3012 . 3014 [I-D.arkko-dual-stack-extra-lite] 3015 Arkko, J., Eggert, L., and M. Townsley, "Scalable 3016 Operation of Address Translators with Per-Interface 3017 Bindings", draft-arkko-dual-stack-extra-lite-05 (work in 3018 progress), February 2011. 3020 [I-D.boucadair-pcp-failure] 3021 Boucadair, M., Dupont, F., and R. Penno, "Port Control 3022 Protocol (PCP) Failure Scenarios", 3023 draft-boucadair-pcp-failure-02 (work in progress), 3024 September 2011. 3026 [I-D.bpw-pcp-upnp-igd-interworking] 3027 Boucadair, M., Penno, R., Wing, D., and F. Dupont, 3028 "Universal Plug and Play (UPnP) Internet Gateway Device 3029 (IGD)-Port Control Protocol (PCP) Interworking Function", 3030 draft-bpw-pcp-upnp-igd-interworking-02 (work in progress), 3031 February 2011. 3033 [I-D.cheshire-dnsext-dns-sd] 3034 Cheshire, S. and M. Krochmal, "DNS-Based Service 3035 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 3036 progress), February 2011. 3038 [I-D.cheshire-nat-pmp] 3039 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 3040 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 3042 [I-D.dupont-pcp-dslite] 3043 Dupont, F., Tsou, T., and J. Qin, "The Port Control 3044 Protocol in Dual-Stack Lite environments", 3045 draft-dupont-pcp-dslite-00 (work in progress), 3046 August 2011. 3048 [I-D.ietf-behave-lsn-requirements] 3049 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 3050 and H. Ashida, "Common requirements for Carrier Grade NAT 3051 (CGN)", draft-ietf-behave-lsn-requirements-03 (work in 3052 progress), August 2011. 3054 [I-D.ietf-behave-sctpnat] 3055 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 3056 Transmission Protocol (SCTP) Network Address Translation", 3057 draft-ietf-behave-sctpnat-05 (work in progress), 3058 June 2011. 3060 [I-D.miles-behave-l2nat] 3061 Miles, D. and M. Townsley, "Layer2-Aware NAT", 3062 draft-miles-behave-l2nat-00 (work in progress), 3063 March 2009. 3065 [IGD] UPnP Gateway Committee, "WANIPConnection:1", 3066 November 2001, . 3069 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3070 RFC 793, September 1981. 3072 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3073 E. Lear, "Address Allocation for Private Internets", 3074 BCP 5, RFC 1918, February 1996. 3076 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3077 Address Translator (Traditional NAT)", RFC 3022, 3078 January 2001. 3080 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 3081 Session Initiation Protocol (SIP) for Symmetric Response 3082 Routing", RFC 3581, August 2003. 3084 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 3085 Unicast Address Format", RFC 3587, August 2003. 3087 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3088 Architecture", RFC 4291, February 2006. 3090 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3091 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3092 RFC 4787, January 2007. 3094 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3095 Extensions for Stateless Address Autoconfiguration in 3096 IPv6", RFC 4941, September 2007. 3098 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3099 BCP 131, RFC 4961, July 2007. 3101 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 3102 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3103 RFC 5382, October 2008. 3105 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 3106 Customer Premises Equipment (CPE) for Providing 3107 Residential IPv6 Internet Service", RFC 6092, 3108 January 2011. 3110 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 3111 Algorithm", RFC 6145, April 2011. 3113 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3114 NAT64: Network Address and Protocol Translation from IPv6 3115 Clients to IPv4 Servers", RFC 6146, April 2011. 3117 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3118 Translation", RFC 6296, June 2011. 3120 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 3121 Stack Lite Broadband Deployments Following IPv4 3122 Exhaustion", RFC 6333, August 2011. 3124 Appendix A. NAT-PMP Transition 3126 The Port Control Protocol (PCP) is a successor to the NAT Port 3127 Mapping Protocol, NAT-PMP [I-D.cheshire-nat-pmp], and shares similar 3128 semantics, concepts, and packet formats. Because of this NAT-PMP and 3129 PCP both use the same port, and use NAT-PMP and PCP's version 3130 negotiation capabilities to determine which version to use. This 3131 section describes how an orderly transition may be achieved. 3133 A client supporting both NAT-PMP and PCP SHOULD send its request 3134 using the PCP packet format. This will be received by a NAT-PMP 3135 server or a PCP server. If received by a NAT-PMP server, the 3136 response will be as indicated by the NAT-PMP specification 3137 [I-D.cheshire-nat-pmp], which will cause the client to downgrade to 3138 NAT-PMP and re-send its request in NAT-PMP format. If received by a 3139 PCP server, the response will be as described by this document and 3140 processing continues as expected. 3142 A PCP server supporting both NAT-PMP and PCP can handle requests in 3143 either format. The first octet of the packet indicates if it is NAT- 3144 PMP (first octet zero) or PCP (first octet non-zero). 3146 A PCP-only gateway receiving a NAT-PMP request (identified by the 3147 first octet being zero) will interpret the request as a version 3148 mismatch. Normal PCP processing will emit a PCP response that is 3149 compatible with NAT-PMP, without any special handling by the PCP 3150 server. 3152 Appendix B. Change History 3154 [Note to RFC Editor: Please remove this section prior to 3155 publication.] 3157 B.1. Changes from draft-ietf-pcp-base-15 to -16 3159 o fixed mistake in PCP request format (had 32 bits of extraneous 3160 fields) 3162 o Allow MAP to request all ports (port=0) for a specific protocol 3163 (protocol!=0), for the same reason we added support for all ports 3164 (port=0) and all protocols (protocol=0) in -15 3166 o corrected text on Client Processing a Response related to 3167 receiving ADDRESS_MISMATCH error. 3169 o updated Epoch text. 3171 o Added text that MALFORMED_REQUEST is generated for MAP if Protocol 3172 is zero but Internal Port is non-zero. 3174 B.2. Changes from draft-ietf-pcp-base-14 to -15 3176 o Softened and removed text that was normatively explaining how PEER 3177 is implemented within a NAT. 3179 o Allow a MAP request for protocol=0, which means "all protocols". 3180 This can work for an IPv6 or IPv4 firewall. Its use with a NAPT 3181 is undefined. 3183 o combined SERVER_OVERLOADED and NO_RESOURCES into one error code, 3184 NO_RESOURCES. 3186 o SCTP mappings have to use same internal and requested external 3187 ports, and have implied PREFER_FAILURE semantics. 3189 o Re-instated ADDRESS_MISMATCH error, which only checks the client 3190 address (not its port). 3192 B.3. Changes from draft-ietf-pcp-base-13 to -14 3194 o Moved discussion of socket operations for PCP source address into 3195 Implementation Considerations section. 3197 o Integrated numerous WGLC comments. 3199 o NPTv6 in scope. 3201 o Re-written security considerations section. Thanks, Margaret! 3203 o Reduced PEER4 and PEER6 Opcodes to just a single Opcode, PEER. 3205 o Reduced MAP4 and MAP6 Opcodes to just a single Opcode, MAP. 3207 o Rearranged the PEER packet formats to align with MAP. 3209 o Removed discussion of the "O" bit for Options, which was 3210 confusing. Now the text just discusses the most significant bit 3211 of the Option code which indicates mandatory/optional, so it is 3212 clearer the field is 8 bits. 3214 o The THIRD_PARTY Option from an unauthorized host generates 3215 UNSUPP_OPTION, so the PCP server doesn't disclose it knows how to 3216 process THIRD_PARTY Option. 3218 o Added table to show which fields of MAP or PEER need IPv6/IPv4 3219 addresses for IPv4 firewall, DS-Lite, NAT64, NAT44, etc. 3221 o Accommodate the server's Epoch going up or down, to better detect 3222 switching to a different PCP server. 3224 o Removed ADDRESS_MISMATCH; the server always includes its idea of 3225 the Client's IP Address and Port, and it's up to the client to 3226 detect a mismatch (and rectify it). 3228 B.4. Changes from draft-ietf-pcp-base-12 to -13 3230 o All addresses are 128 bits. IPv4 addresses are represented by 3231 IPv4-mapped IPv6 addresses (::FFFF/96) 3233 o PCP request header now includes PCP client's port (in addition to 3234 the client's IP address, which was in -12). 3236 o new ADDRESS_MISMATCH error. 3238 o removed PROCESSING_ERROR error, which was too similar to 3239 MALFORMED_REQUEST. 3241 o Tweaked text describing how PCP client deals with multiple PCP 3242 server addresses (Section 7.1) 3244 o clarified that when overloaded, the server can send 3245 SERVER_OVERLOADED (and drop requests) or simply drop requests. 3247 o Clarified how PCP client chooses MAP4 or MAP6, depending on the 3248 presence of its own IPv6 or IPv4 interfaces (Section 8). 3250 o compliant PCP server MUST support MAPx and PEERx, SHOULD support 3251 ability to disable support. 3253 o clarified that MAP-created mappings have no filtering, and PEER- 3254 created mappings have whatever filtering and mapping behavior is 3255 normal for that particular NAT / firewall. 3257 o Integrated WGLC feedback (small changes to abstract, definitions, 3258 and small edits throughout the document) 3260 o allow new Options to be defined with a specification (rather than 3261 standards action) 3263 B.5. Changes from draft-ietf-pcp-base-11 to -12 3265 o added implementation note that MAP and implicit dynamic mappings 3266 have independent mapping lifetimes. 3268 B.6. Changes from draft-ietf-pcp-base-10 to -11 3270 o clarified what can cause CANNOT_PROVIDE_EXTERNAL_PORT error to be 3271 generated. 3273 B.7. Changes from draft-ietf-pcp-base-09 to -10 3275 o Added External_AF field to PEER requests. Made PEER's Suggested 3276 External IP Address and Assigned External IP Address always be 128 3277 bits long. 3279 B.8. Changes from draft-ietf-pcp-base-08 to -09 3281 o Clarified in PEER Opcode introduction (Section 10) that they can 3282 also create mappings. 3284 o More clearly explained how PEER can re-create an implicit dynamic 3285 mapping, for purposes of rebuilding state to maintain an existing 3286 session (e.g., long-lived TCP connection to a server). 3288 o Added Suggested External IP Address to the PEER Opcodes, to allow 3289 more robust rebuilding of connections. Added related text to the 3290 PEER server processing section. 3292 o Removed text encouraging PCP server to statefully remember its 3293 mappings from Section 12.3.1, as it didn't belong there. Text in 3294 Security Considerations already encourages persistent storage. 3296 o More clearly discussed how PEER is used to re-establish TCP 3297 mapping state. Moved it to a new section, as well (it is now 3298 Section 8.4). 3300 o MAP errors now copy the Requested IP Address (and port) fields to 3301 Assigned IP Address (and port), to allow PCP client to distinguish 3302 among many outstanding requests when using PREFER_FAILURE. 3304 o Mapping theft can also be mitigated by ensuring hosts can't re-use 3305 same IP address or port after state loss. 3307 o the UNPROCESSED option is renumbered to 0 (zero), which ensures no 3308 other option will be given 0 and be unable to be expressed by the 3309 UNPROCESSED option (due to its 0 padding). 3311 o created new Implementation Considerations section (Section 12) 3312 which discusses non-normative things that might be useful to 3313 implementors. Some new text is in here, and the Failure Scenarios 3314 text (Section 12.3) has been moved to here. 3316 o Tweaked wording of EDM NATs in Section 12.1 to clarify the problem 3317 occurs both inside->outside and outside->inside. 3319 o removed "Interference by Other Applications on Same Host" section 3320 from security considerations. 3322 o fixed zero/non-zero text in Section 9.5. 3324 o removed duplicate text saying MAP is allowed to delete an implicit 3325 dynamic mapping. It is still allowed to do that, but it didn't 3326 need to be said twice in the same paragraph. 3328 o Renamed error from UNAUTH_TARGET_ADDRESS to 3329 UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS. 3331 o for FILTER option, removed unnecessary detail on how FILTER would 3332 be bad for PEER, as it is only allowed for MAP anyway. 3334 o In Security Considerations, explain that PEER can create a mapping 3335 which makes its security considerations the same as MAP. 3337 B.9. Changes from draft-ietf-pcp-base-07 to -08 3339 o moved all MAP4-, MAP6-, and PEER-specific options into a single 3340 section. 3342 o discussed NAT port-overloading and its impact on MAP (new section 3343 Section 12.1), which allowed removing the IMPLICIT_MAPPING_EXISTS 3344 error. 3346 o eliminated NONEXIST_PEER error (which was returned if a PEER 3347 request was received without an implicit dynamic mapping already 3348 being created), and adjusted PEER so that it creates an implicit 3349 dynamic mapping. 3351 o Removed Deployment Scenarios section (which detailed NAT64, NAT44, 3352 Dual-Stack Lite, etc.). 3354 o Added Client's IP Address to PCP common header. This allows 3355 server to refuse a PCP request if there is a mismatch with the 3356 source IP address, such as when a non-PCP-aware NAT was on the 3357 path. This should reduce failure situations where PCP is deployed 3358 in conjunction with a non-PCP-aware NAT. This addition was 3359 consensus at IETF80. 3361 o Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that 3362 MALFORMED_REQUEST is for malformed requests (and not related to 3363 failed attempts to process the request). 3365 o Removed MISORDERED_OPTIONS. Consensus of IETF80. 3367 o SERVER_OVERLOADED is now a common PCP error (instead of specific 3368 to MAP). 3370 o Tweaked PCP retransmit/retry algorithm again, to allow more 3371 aggressive PCP discovery if an implementation wants to do that. 3373 o Version negotiation text tweaked to soften NAT-PMP reference, and 3374 more clearly explain exactly what UNSUPP_VERSION should return. 3376 o PCP now uses NAT-PMP's UDP port, 5351. There are no normative 3377 changes to NAT-PMP or PCP to allow them both to use the same port 3378 number. 3380 o New Appendix A to discuss NAT-PMP / PCP interworking. 3382 o improved pseudocode to be non-blocking. 3384 o clarified that PCP cannot delete a static mapping (i.e., a mapping 3385 created by CLI or other non-PCP means). 3387 o moved theft of mapping discussion from Epoch section to Security 3388 Considerations. 3390 B.10. Changes from draft-ietf-pcp-base-06 to -07 3392 o tightened up THIRD_PARTY security discussion. Removed "highest 3393 numbered address", and left it as simply "the CPE's IP address". 3395 o removed UNABLE_TO_DELETE_ALL error. 3397 o renumbered Opcodes 3399 o renumbered some error codes 3401 o assigned value to IMPLICIT_MAPPING_EXISTS. 3403 o UNPROCESSED can include arbitrary number of option codes. 3405 o Moved lifetime fields into common request/response headers 3407 o We've noticed we're having to repeatedly explain to people that 3408 the "requested port" is merely a hint, and the NAT gateway is free 3409 to ignore it. Changed name to "suggested port" to better convey 3410 this intention. 3412 o Added NAT-PMP transition section 3414 o Separated Internal Address, External Address, Remote Peer Address 3415 definition 3417 o Unified Mapping, Port Mapping, Port Forwarding definition 3419 o adjusted so DHCP configuration is non-normative. 3421 o mentioned PCP refreshes need to be sent over the same interface. 3423 o renamed the REMOTE_PEER_FILTER option to FILTER. 3425 o Clarified FILTER option to allow sending an ICMP error if policy 3426 allows. 3428 o for MAP, clarified that if the PCP client changed its IP address 3429 and still wants to receive traffic, it needs to send a new MAP 3430 request. 3432 o clarified that PEER requests have to be sent from same interface 3433 as the connection itself. 3435 o for MAP opcode, text now requires mapping be deleted when lifetime 3436 expires (per consensus on 8-Mar interim meeting) 3438 o PEER Opcode: better description of remote peer's IP address, 3439 specifically that it does not control or establish any filtering, 3440 and explaining why it is 'from the PCP client's perspective'. 3442 o Removed latent text allowing DMZ for 'all protocols' (protocol=0). 3443 Which wouldn't have been legal, anyway, as protocol 0 is assigned 3444 by IANA to HOPOPT (thanks to James Yu for catching that one). 3446 o clarified that PCP server only listens on its internal interface. 3448 o abandoned 'target' term and reverted to simplier 'internal' term. 3450 B.11. Changes from draft-ietf-pcp-base-05 to -06 3452 o Dual-Stack Lite: consensus was encapsulation mode. Included a 3453 suggestion that the B4 will need to proxy PCP-to-PCP and UPnP-to- 3454 PCP. 3456 o defined THIRD_PARTY Option to work with the PEER Opcode, too. 3457 This meant moving it to its own section, and having both MAP and 3458 PEER Opcodes reference that common section. 3460 o used "target" instead of "internal", in the hopes that clarifies 3461 internal address used by PCP itself (for sending its packets) 3462 versus the address for MAPpings. 3464 o Options are now required to be ordered in requests, and ordering 3465 has to be validated by the server. Intent is to ease server 3466 processing of mandatory-to-implement options. 3468 o Swapped Option values for the mandatory- and optional-to-process 3469 Options, so we can have a simple lowest..highest ordering. 3471 o added MISORDERED_OPTIONS error. 3473 o re-ordered some error messages to cause MALFORMED_REQUEST (which 3474 is PCP's most general error response) to be error 1, instead of 3475 buried in the middle of the error numbers. 3477 o clarified that, after successfully using a PCP server, that PCP 3478 server is declared to be non-responsive after 5 failed 3479 retransmissions. 3481 o tightened up text (which was inaccurate) about how long general 3482 PCP processing is to delay when receiving an error and if it 3483 should honor Opcode-specific error lifetime. Useful for MAP 3484 errors which have an error lifetime. (This all feels awkward to 3485 have only some errors with a lifetime.) 3487 o Added better discussion of multiple interfaces, including 3488 highlighting WiFi+Ethernet. Added discussion of using IPv6 3489 Privacy Addresses and RFC1918 as source addresses for PCP 3490 requests. This should finish the section on multi-interface 3491 issues. 3493 o added some text about why server might send SERVER_OVERLOADED, or 3494 might simply discard packets. 3496 o Dis-allow internal-port=0, which means we dis-allow using PCP as a 3497 DMZ-like function. Instead, ports have to be mapped individually. 3499 o Text describing server's processing of PEER is tightened up. 3501 o Server's processing of PEER now says it is implementation-specific 3502 if a PCP server continues to allow the mapping to exist after a 3503 PEER message. Client's processing of PEER says that if client 3504 wants mapping to continue to exist, client has to continue to send 3505 recurring PEER messages. 3507 B.12. Changes from draft-ietf-pcp-base-04 to -05 3509 o tweaked PCP common header packet layout. 3511 o Re-added port=0 (all ports). 3513 o minimum size is 12 octets (missed that change in -04). 3515 o removed Lifetime from PCP common header. 3517 o for MAP error responses, the lifetime indicates how long the 3518 server wants the client to avoid retrying the request. 3520 o More clearly indicated which fields are filled by the server on 3521 success responses and error responses. 3523 o Removed UPnP interworking section from this document. It will 3524 appear in [I-D.bpw-pcp-upnp-igd-interworking]. 3526 B.13. Changes from draft-ietf-pcp-base-03 to -04 3528 o "Pinhole" and "PIN" changed to "mapping" and "MAP". 3530 o Reduced from four MAP Opcodes to two. This was done by implicitly 3531 using the address family of the PCP message itself. 3533 o New option THIRD_PARTY, to more carefully split out the case where 3534 a mapping is created to a different host within the home. 3536 o Integrated a lot of editorial changes from Stuart and Francis. 3538 o Removed nested NAT text into another document, including the IANA- 3539 registered IP addresses for the PCP server. 3541 o Removed suggestion (MAY) that PCP server reserve UDP when it maps 3542 TCP. Nobody seems to need that. 3544 o Clearly added NAT and NAPT, such as in residential NATs, as within 3545 scope for PCP. 3547 o HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE 3549 o Added 'Lifetime' field to the common PCP header, which replaces 3550 the functions of the 'temporary' and 'permanent' error types of 3551 the previous version. 3553 o Allow arbitrary Options to be included in PCP response, so that 3554 PCP server can indicate un-supported PCP Options. Satisfies PCP 3555 Issue #19 3557 o Reduced scope to only deal with mapping protocols that have port 3558 numbers. 3560 o Reduced scope to not support DMZ-style forwarding. 3562 o Clarified version negotiation. 3564 B.14. Changes from draft-ietf-pcp-base-02 to -03 3566 o Adjusted abstract and introduction to make it clear PCP is 3567 intended to forward ports and intended to reduce application 3568 keepalives. 3570 o First bit in PCP common header is set. This allows DTLS and non- 3571 DTLS to be multiplexed on same port, should a future update to 3572 this specification add DTLS support. 3574 o Moved subscriber identity from common PCP section to MAP* section. 3576 o made clearer that PCP client can reduce mapping lifetime if it 3577 wishes. 3579 o Added discussion of host running a server, client, or symmetric 3580 client+server. 3582 o Introduced PEER4 and PEER6 Opcodes. 3584 o Removed REMOTE_PEER Option, as its function has been replaced by 3585 the new PEER Opcodes. 3587 o IANA assigned port 44323 to PCP. 3589 o Removed AMBIGUOUS error code, which is no longer needed. 3591 B.15. Changes from draft-ietf-pcp-base-01 to -02 3593 o more error codes 3595 o PCP client source port number should be random 3597 o PCP message minimum 8 octets, maximum 1024 octets. 3599 o tweaked a lot of text in section 7.4, "Opcode-Specific Server 3600 Operation". 3602 o opening a mapping also allows ICMP messages associated with that 3603 mapping. 3605 o PREFER_FAILURE value changed to the mandatory-to-process range. 3607 o added text recommending applications that are crashing obtain 3608 short lifetimes, to avoid consuming subscriber's port quota. 3610 B.16. Changes from draft-ietf-pcp-base-00 to -01 3612 o Significant document reorganization, primarily to split base PCP 3613 operation from Opcode operation. 3615 o packet format changed to move 'protocol' outside of PCP common 3616 header and into the MAP* opcodes 3618 o Renamed Informational Elements (IE) to Options. 3620 o Added REMOTE_PEER (for disambiguation with dynamic ports), 3621 REMOTE_PEER_FILTER (for simple packet filtering), and 3622 PREFER_FAILURE (to optimize UPnP IGD interworking) options. 3624 o Is NAT or router behind B4 in scope? 3626 o PCP option MAY be included in a request, in which case it MUST 3627 appear in a response. It MUST NOT appear in a response if it was 3628 not in the request. 3630 o Result code most significant bit now indicates permanent/temporary 3631 error 3633 o PCP Options are split into mandatory-to-process ("P" bit), and 3634 into Specification Required and Private Use. 3636 o Epoch discussion simplified. 3638 Authors' Addresses 3640 Dan Wing (editor) 3641 Cisco Systems, Inc. 3642 170 West Tasman Drive 3643 San Jose, California 95134 3644 USA 3646 Email: dwing@cisco.com 3648 Stuart Cheshire 3649 Apple Inc. 3650 1 Infinite Loop 3651 Cupertino, California 95014 3652 USA 3654 Phone: +1 408 974 3207 3655 Email: cheshire@apple.com 3657 Mohamed Boucadair 3658 France Telecom 3659 Rennes, 35000 3660 France 3662 Email: mohamed.boucadair@orange-ftgroup.com 3664 Reinaldo Penno 3665 Juniper Networks 3666 1194 N Mathilda Avenue 3667 Sunnyvale, California 94089 3668 USA 3670 Email: rpenno@juniper.net 3671 Paul Selkirk 3672 Internet Systems Consortium 3673 950 Charter Street 3674 Redwood City, California 94063 3675 USA 3677 Email: pselkirk@isc.org