idnits 2.17.1 draft-ietf-pcp-base-28.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1492 has weird spacing: '...nternal exter...' -- The document date (October 2, 2012) is 4223 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-04 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-05 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-09 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-06 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-upnp-igd-interworking-04 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP working group D. Wing, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Cheshire 5 Expires: April 5, 2013 Apple 6 M. Boucadair 7 France Telecom 8 R. Penno 9 Cisco 10 P. Selkirk 11 ISC 12 October 2, 2012 14 Port Control Protocol (PCP) 15 draft-ietf-pcp-base-28 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 5, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 6 61 2.2. Supported Protocols . . . . . . . . . . . . . . . . . . . 6 62 2.3. Single-homed Customer Premises Network . . . . . . . . . 6 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Relationship between PCP Server and its NAT/firewall . . . . 11 65 5. Note on Fixed-Size Addresses . . . . . . . . . . . . . . . . 11 66 6. Protocol Design Note . . . . . . . . . . . . . . . . . . . . 12 67 7. Common Request and Response Header Format . . . . . . . . . . 14 68 7.1. Request Header . . . . . . . . . . . . . . . . . . . . . 15 69 7.2. Response Header . . . . . . . . . . . . . . . . . . . . . 16 70 7.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 7.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . 20 72 8. General PCP Operation . . . . . . . . . . . . . . . . . . . . 21 73 8.1. General PCP Client: Generating a Request . . . . . . . . 22 74 8.1.1. PCP Client Retransmission . . . . . . . . . . . . . . 23 75 8.2. General PCP Server: Processing a Request . . . . . . . . 25 76 8.3. General PCP Client: Processing a Response . . . . . . . . 27 77 8.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . 28 78 8.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 9. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 30 80 10. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . 31 81 10.1. For Operating a Server . . . . . . . . . . . . . . . . . 33 82 10.2. For Operating a Symmetric Client/Server . . . . . . . . . 36 83 10.3. For Reducing NAT or Firewall Keepalive Messages . . . . . 38 84 10.4. For Restoring Lost Implicit TCP Dynamic Mapping State . . 39 85 11. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 40 86 11.1. MAP Operation Packet Formats . . . . . . . . . . . . . . 41 87 11.2. Generating a MAP Request . . . . . . . . . . . . . . . . 44 88 11.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . 45 89 11.3. Processing a MAP Request . . . . . . . . . . . . . . . . 45 90 11.4. Processing a MAP Response . . . . . . . . . . . . . . . . 48 91 11.5. Address Change Events . . . . . . . . . . . . . . . . . . 49 92 11.6. Learning the External IP Address Alone . . . . . . . . . 50 93 12. PEER Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 51 94 12.1. PEER Operation Packet Formats . . . . . . . . . . . . . . 51 95 12.2. Generating a PEER Request . . . . . . . . . . . . . . . . 55 96 12.3. Processing a PEER Request . . . . . . . . . . . . . . . . 56 97 12.4. Processing a PEER Response . . . . . . . . . . . . . . . 57 98 13. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . 58 99 13.1. THIRD_PARTY Option for MAP and PEER Opcodes . . . . . . . 58 100 13.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . 60 101 13.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . 62 102 14. Rapid Recovery . . . . . . . . . . . . . . . . . . . . . . . 64 103 14.1. ANNOUNCE Opcode . . . . . . . . . . . . . . . . . . . . . 65 104 14.1.1. ANNOUNCE Operation . . . . . . . . . . . . . . . . . 65 105 14.1.2. Generating and Processing a Solicited ANNOUNCE 106 Message . . . . . . . . . . . . . . . . . . . . . . . 66 107 14.1.3. Generating and Processing an Unsolicited ANNOUNCE 108 Message . . . . . . . . . . . . . . . . . . . . . . . 66 109 14.2. PCP Mapping Update . . . . . . . . . . . . . . . . . . . 68 110 15. Mapping Lifetime and Deletion . . . . . . . . . . . . . . . . 69 111 15.1. Lifetime Processing for the MAP Opcode . . . . . . . . . 71 112 16. Implementation Considerations . . . . . . . . . . . . . . . . 72 113 16.1. Implementing MAP with EDM port-mapping NAT . . . . . . . 72 114 16.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . 73 115 16.3. PCP Failure Recovery . . . . . . . . . . . . . . . . . . 73 116 16.3.1. Recreating Mappings . . . . . . . . . . . . . . . . . 73 117 16.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . 74 118 16.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 74 119 16.4. Source Address Replicated in PCP Header . . . . . . . . . 75 120 16.5. State Diagram . . . . . . . . . . . . . . . . . . . . . . 76 121 17. Deployment Considerations . . . . . . . . . . . . . . . . . . 78 122 17.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 78 123 17.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 79 124 18. Security Considerations . . . . . . . . . . . . . . . . . . . 79 125 18.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 79 126 18.1.1. Attacks Considered . . . . . . . . . . . . . . . . . 80 127 18.1.2. Deployment Examples Supporting the Simple Threat 128 Model . . . . . . . . . . . . . . . . . . . . . . . . 81 129 18.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 81 130 18.3. Residual Threats . . . . . . . . . . . . . . . . . . . . 82 131 18.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 82 132 18.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 82 133 18.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 82 134 18.3.4. Attacks Against Server Discovery . . . . . . . . . . 83 135 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 136 19.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 83 137 19.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 83 138 19.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . 83 139 19.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 84 140 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 141 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 142 21.1. Normative References . . . . . . . . . . . . . . . . . . 85 143 21.2. Informative References . . . . . . . . . . . . . . . . . 85 145 Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . 88 146 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 89 147 B.1. Changes from draft-ietf-pcp-base-27 to -28 . . . . . . . 89 148 B.2. Changes from draft-ietf-pcp-base-26 to -27 . . . . . . . 89 149 B.3. Changes from draft-ietf-pcp-base-25 to -26 . . . . . . . 91 150 B.4. Changes from draft-ietf-pcp-base-24 to -25 . . . . . . . 91 151 B.5. Changes from draft-ietf-pcp-base-23 to -24 . . . . . . . 92 152 B.6. Changes from draft-ietf-pcp-base-22 to -23 . . . . . . . 94 153 B.7. Changes from draft-ietf-pcp-base-21 to -22 . . . . . . . 96 154 B.8. Changes from draft-ietf-pcp-base-20 to -21 . . . . . . . 96 155 B.9. Changes from draft-ietf-pcp-base-19 to -20 . . . . . . . 96 156 B.10. Changes from draft-ietf-pcp-base-18 to -19 . . . . . . . 96 157 B.11. Changes from draft-ietf-pcp-base-17 to -18 . . . . . . . 97 158 B.12. Changes from draft-ietf-pcp-base-16 to -17 . . . . . . . 97 159 B.13. Changes from draft-ietf-pcp-base-15 to -16 . . . . . . . 97 160 B.14. Changes from draft-ietf-pcp-base-14 to -15 . . . . . . . 98 161 B.15. Changes from draft-ietf-pcp-base-13 to -14 . . . . . . . 98 162 B.16. Changes from draft-ietf-pcp-base-12 to -13 . . . . . . . 99 163 B.17. Changes from draft-ietf-pcp-base-11 to -12 . . . . . . . 100 164 B.18. Changes from draft-ietf-pcp-base-10 to -11 . . . . . . . 100 165 B.19. Changes from draft-ietf-pcp-base-09 to -10 . . . . . . . 100 166 B.20. Changes from draft-ietf-pcp-base-08 to -09 . . . . . . . 100 167 B.21. Changes from draft-ietf-pcp-base-07 to -08 . . . . . . . 101 168 B.22. Changes from draft-ietf-pcp-base-06 to -07 . . . . . . . 102 169 B.23. Changes from draft-ietf-pcp-base-05 to -06 . . . . . . . 103 170 B.24. Changes from draft-ietf-pcp-base-04 to -05 . . . . . . . 105 171 B.25. Changes from draft-ietf-pcp-base-03 to -04 . . . . . . . 105 172 B.26. Changes from draft-ietf-pcp-base-02 to -03 . . . . . . . 106 173 B.27. Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . 106 174 B.28. Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . 107 175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107 177 1. Introduction 179 The Port Control Protocol (PCP) provides a mechanism to control how 180 incoming packets are forwarded by upstream devices such as Network 181 Address Translator IPv6/IPv4 (NAT64), Network Address Translator 182 IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to 183 reduce application keepalive traffic. PCP is designed to be 184 implemented in the context of Carrier-Grade NATs (CGNs), small NATs 185 (e.g., residential NATs), as well as with dual-stack and IPv6-only 186 Customer Premises Equipment (CPE) routers, and all of the currently- 187 known transition scenarios towards IPv6-only CPE routers. PCP allows 188 hosts to operate servers for a long time (e.g., a network-attached 189 home security camera) or a short time (e.g., while playing a game or 190 on a phone call) when behind a NAT device, including when behind a 191 CGN operated by their Internet service provider or an IPv6 firewall 192 integrated in their CPE router. 194 PCP allows applications to create mappings from an external IP 195 address, protocol, and port to an internal IP address, protocol, and 196 port. These mappings are required for successful inbound 197 communications destined to machines located behind a NAT or a 198 firewall. 200 After creating a mapping for incoming connections, it is necessary to 201 inform remote computers about the IP address, protocol, and port for 202 the incoming connection. This is usually done in an application- 203 specific manner. For example, a computer game might use a rendezvous 204 server specific to that game (or specific to that game developer), a 205 SIP phone would use a SIP proxy, and a client using DNS-Based Service 206 Discovery [I-D.cheshire-dnsext-dns-sd] would use DNS Update [RFC2136] 207 [RFC3007]. PCP does not provide this rendezvous function. The 208 rendezvous function may support IPv4, IPv6, or both. Depending on 209 that support and the application's support of IPv4 or IPv6, the PCP 210 client may need an IPv4 mapping, an IPv6 mapping, or both. 212 Many NAT-friendly applications send frequent application-level 213 messages to ensure their session will not be timed out by a NAT. 214 These are commonly called "NAT keepalive" messages, even though they 215 are not sent to the NAT itself (rather, they are sent 'through' the 216 NAT). These applications can reduce the frequency of such NAT 217 keepalive messages by using PCP to learn (and influence) the NAT 218 mapping lifetime. This helps reduce bandwidth on the subscriber's 219 access network, traffic to the server, and battery consumption on 220 mobile devices. 222 Many NATs and firewalls include Application Layer Gateways (ALGs) to 223 create mappings for applications that establish additional streams or 224 accept incoming connections. ALGs incorporated into NATs may also 225 modify the application payload. Industry experience has shown that 226 these ALGs are detrimental to protocol evolution. PCP allows an 227 application to create its own mappings in NATs and firewalls, 228 reducing the incentive to deploy ALGs in NATs and firewalls. 230 2. Scope 232 2.1. Deployment Scenarios 234 PCP can be used in various deployment scenarios, including: 236 o Basic NAT [RFC3022] 238 o Network Address and Port Translation [RFC3022], such as commonly 239 deployed in residential NAT devices 241 o Carrier-Grade NAT [I-D.ietf-behave-lsn-requirements] 243 o Dual-Stack Lite (DS-Lite) [RFC6333] 245 o Layer-2 Aware NAT [I-D.miles-behave-l2nat] 247 o Dual-Stack Extra Lite [RFC6619] 249 o NAT64, both Stateless [RFC6145] and Stateful [RFC6146] 251 o IPv4 and IPv6 simple firewall control [RFC6092] 253 o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] 255 2.2. Supported Protocols 257 The PCP Opcodes defined in this document are designed to support 258 transport-layer protocols that use a 16-bit port number (e.g., TCP, 259 UDP, SCTP [RFC4960], DCCP [RFC4340]). Protocols that do not use a 260 port number (e.g., RSVP, IPsec ESP [RFC4303], ICMP, ICMPv6) are 261 supported for IPv4 firewall, IPv6 firewall, and NPTv6 functions, but 262 are out of scope for any NAT functions. 264 2.3. Single-homed Customer Premises Network 266 PCP assumes a single-homed IP address model. That is, for a given IP 267 address of a host, only one default route exists to reach other hosts 268 on the Internet from that source IP address. This is important 269 because after a PCP mapping is created and an inbound packet (e.g., 270 TCP SYN) is rewritten and delivered to a host, the outbound response 271 (e.g., TCP SYNACK) has to go through the same (reverse) path so it 272 passes through the same NAT to have the necessary inverse rewrite 273 performed. This restriction exists because otherwise there would 274 need to be a PCP-enabled NAT for every egress (because the host could 275 not reliably determine which egress path packets would take) and the 276 client would need to be able to reliably make the same internal/ 277 external mapping in every NAT gateway, which in general is not 278 possible (because the other NATs might already have the necessary 279 External Port mapped to another host). 281 3. Terminology 283 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 284 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 285 document are to be interpreted as described in "Key words for use in 286 RFCs to Indicate Requirement Levels" [RFC2119]. 288 Internal Host: 289 A host served by a NAT gateway, or protected by a firewall. This 290 is the host that will receive incoming traffic resulting from a 291 PCP mapping request, or the host that initiated an implicit 292 dynamic outbound mapping (e.g., by sending a TCP SYN) across a 293 firewall or a NAT. 295 Remote Peer Host: 296 A host with which an Internal Host is communicating. This can 297 include another Internal Host (or even the same Internal Host); if 298 a NAT is involved, the NAT would need to hairpin the traffic 299 [RFC4787]. 301 Internal Address: 302 The address of an Internal Host served by a NAT gateway or 303 protected by a firewall. 305 External Address: 306 The address of an Internal Host as seen by other Remote Peers on 307 the Internet with which the Internal Host is communicating, after 308 translation by any NAT gateways on the path. An External Address 309 is generally a public routable (i.e., non-private) address. In 310 the case of an Internal Host protected by a pure firewall, with no 311 address translation on the path, its External Address is the same 312 as its Internal Address. 314 Endpoint-Dependent Mapping (EDM): A term applied to NAT operation 315 where an implicit mapping created by outgoing traffic (e.g., TCP 316 SYN) from a single Internal Address, Protocol, and Port to 317 different Remote Peers and Ports may be assigned different 318 External Ports, and a subsequent PCP mapping request for that 319 Internal Address, Protocol, and Port may be assigned yet another 320 different External Port. This term encompasses both Address- 321 Dependent Mapping and Address and Port-Dependent Mapping 322 [RFC4787]. 324 Endpoint-Independent Mapping (EIM): A term applied to NAT operation 325 where all mappings from a single Internal Address, Protocol, and 326 Port to different Remote Peers and Ports are all assigned the same 327 External Address and Port. 329 Remote Peer Address: 330 The address of a Remote Peer, as seen by the Internal Host. A 331 Remote Address is generally a publicly routable address. In the 332 case of a Remote Peer that is itself served by a NAT gateway, the 333 Remote Address may in fact be the Remote Peer's External Address, 334 but since this remote translation is generally invisible to 335 software running on the Internal Host, the distinction can safely 336 be ignored for the purposes of this document. 338 Third Party: 339 In the common case, an Internal Host manages its own Mappings 340 using PCP requests, and the Internal Address of those Mappings is 341 the same as the source IP address of the PCP request packet. 343 In the case where one device is managing Mappings on behalf of 344 some other device that does not implement PCP, the presence of the 345 THIRD_PARTY Option in the MAP request signifies that the specified 346 address, rather than the source IP address of the PCP request 347 packet, should be used as the Internal Address for the Mapping. 349 Mapping, Port Mapping, Port Forwarding: 350 A NAT mapping creates a relationship between an internal IP 351 address, protocol, and port, and an external IP address, protocol, 352 and port. More specifically, it creates a translation rule where 353 packets destined to the external IP and port are translated to the 354 internal IP address, protocol, and port, and vice versa. In the 355 case of a pure firewall, the "Mapping" is the identity function, 356 translating an internal IP address, protocol, and port number to 357 the same external IP address, protocol, and port number. Firewall 358 filtering, applied in addition to that identity mapping function, 359 is separate from the mapping itself. 361 Mapping Types: 362 There are three dimensions to classifying mapping types: how they 363 are created (implicitly/explicitly), their primary purpose 364 (outbound/inbound), and how they are deleted (dynamic/static). 365 Implicit mappings are created as a side-effect of some other 366 operation; explicit mappings are created by a mechanism explicitly 367 dealing with mappings. Outbound mappings exist primarily to 368 facilitate outbound communication; inbound mappings exist 369 primarily to facilitate inbound communication. Dynamic mappings 370 are deleted when their lifetime expires, or though other protocol 371 action; static mappings are permanent until the user chooses to 372 delete them. 374 * Implicit dynamic mappings are created implicitly as a side- 375 effect of traffic such as an outgoing TCP SYN or outgoing UDP 376 packet. Such packets were not originally designed explicitly 377 for creating NAT (or firewall) state, but they can have that 378 effect when they pass through a NAT (or firewall) device. 379 Implicit dynamic mappings usually have a finite lifetime, 380 though this lifetime is generally not known to the client using 381 them. 383 * Explicit dynamic mappings are created as a result of explicit 384 PCP MAP and PEER requests. Like a DHCP address lease, explicit 385 dynamic mappings have finite lifetime, and this lifetime is 386 communicated to the client. As with a DHCP address lease, if 387 the client wants a mapping to persist the client must prove 388 that it is still present by periodically renewing the mapping 389 to prevent it from expiring. If a PCP client goes away, then 390 any mappings it created will be automatically cleaned up when 391 they expire. 393 * Explicit static mappings are created by manual configuration 394 (e.g., via command-line interface or other user interface) and 395 persist until the user changes that manual configuration. 397 Both implicit and explicit dynamic mappings are dynamic in the 398 sense that they are created on demand, as requested (implicitly or 399 explicitly) by the Internal Host, and have a lifetime. After the 400 lifetime, the mapping is deleted unless the lifetime is extended 401 by action by the Internal Host (e.g., sending more traffic or 402 sending another PCP request). 404 Static mappings are by their nature always explicit. Static 405 mappings differ from explicit dynamic mappings in that their 406 lifetime is effectively infinite (they exist until manually 407 removed) but otherwise they behave exactly the same as explicit 408 MAP mappings. 410 While all mappings are by necessity bidirectional (most Internet 411 communication requires information to flow in both directions for 412 successful operation) when talking about mappings it can be 413 helpful to identify them loosely according to their 'primary' 414 purpose. 416 * Outbound mappings exist primarily to enable outbound 417 communication. For example, when a host calls connect() to 418 make an outbound connection, a NAT gateway will create an 419 implicit dynamic outbound mapping to facilitate that outbound 420 communication. 422 * Inbound mappings exist primarily to enable listening servers to 423 receive inbound connections. Generally, when a client calls 424 listen() to listen for inbound connections, a NAT gateway will 425 not implicitly create any mapping to facilitate that inbound 426 communication. A PCP MAP request can be used explicitly to 427 create a dynamic inbound mapping to enable the desired inbound 428 communication. 430 Explicit static (manual) mappings and explicit dynamic (MAP) 431 mappings both allow Internal Hosts to receive inbound traffic that 432 is not in direct response to any immediately preceding outbound 433 communication (i.e., to allow Internal Hosts to operate a "server" 434 that is accessible to other hosts on the Internet). 436 PCP Client: 437 A PCP software instance responsible for issuing PCP requests to a 438 PCP server. Several independent PCP Clients can exist on the same 439 host. Several PCP Clients can be located in the same local 440 network. A PCP Client can issue PCP requests on behalf of a third 441 party device for which it is authorized to do so. An interworking 442 function from Universal Plug and Play Internet Gateway Device 443 (UPnP IGDv1 [IGDv1]) to PCP is another example of a PCP Client. A 444 PCP server in a NAT gateway that is itself a client of another NAT 445 gateway (nested NAT) may itself act as a PCP client to the 446 upstream NAT. 448 PCP-Controlled Device: 449 A NAT or firewall that controls or rewrites packet flows between 450 internal hosts and remote peer hosts. PCP manages the Mappings on 451 this device. 453 PCP Server: 454 A PCP software instance that resides on the NAT or firewall that 455 receives PCP requests from the PCP client and creates appropriate 456 state in response to that request. 458 Subscriber: 459 The unit of billing for a commercial ISP. A subscriber may have a 460 single IP address from the commercial ISP (which can be shared 461 among multiple hosts using a NAT gateway, thereby making them 462 appear to be a single host to the ISP) or may have multiple IP 463 addresses provided by the commercial ISP. In either case, the IP 464 address or addresses provided by the ISP may themselves be further 465 translated by a Carrier-Grade NAT (CGN) operated by the ISP. 467 4. Relationship between PCP Server and its NAT/firewall 469 The PCP server receives and responds to PCP requests. The PCP server 470 functionality is typically a capability of a NAT or firewall device, 471 as shown in Figure 1. It is also possible for the PCP functionality 472 to be provided by some other device, which communicates with the 473 actual NAT(s) or firewall(s) via some other proprietary mechanism, as 474 long as from the PCP client's perspective such split operation is 475 indistinguishable from the integrated case. 477 +-----------------+ 478 +------------+ | NAT or firewall | 479 | PCP client |--+ with +--- 480 +------------+ | PCP server | 481 +-----------------+ 483 Figure 1: PCP-Enabled NAT or Firewall 485 A NAT or firewall device, between the PCP client and the Internet, 486 might implement simple or advanced firewall functionality. This may 487 be a side-effect of the technology implemented by the device (e.g., a 488 network address and port translator, by virtue of its port rewriting, 489 normally requires connections to be initiated from an inside host 490 towards the Internet), or this might be an explicit firewall policy 491 to deny unsolicited traffic from the Internet. Some firewall devices 492 deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to 493 most ports) but allow certain other unsolicited traffic from the 494 Internet (e.g., UDP port 500 and IPsec ESP) [RFC6092]. Such default 495 filtering (or lack thereof) is out of scope of PCP itself. If a 496 client device wants to receive traffic and supports PCP, and does not 497 possess prior knowledge of such default filtering policy, it SHOULD 498 use PCP to request the necessary mappings to receive the desired 499 traffic. 501 5. Note on Fixed-Size Addresses 503 For simplicity in building and parsing request and response packets, 504 PCP always uses fixed-size 128-bit IP address fields for both IPv6 505 addresses and IPv4 addresses. 507 When the address field holds an IPv6 address, the fixed-size 128-bit 508 IP address field holds the IPv6 address stored as-is. 510 When the address field holds an IPv4 address, IPv4-mapped IPv6 511 addresses [RFC4291] are used (::ffff:0:0/96). This has the first 80 512 bits set to zero and the next 16 set to one, while its last 32 bits 513 are filled with the IPv4 address. This is unambiguously 514 distinguishable from a native IPv6 address, because an IPv4-mapped 515 IPv6 address [RFC4291] would not be valid for a mapping. 517 When checking for an IPv4-mapped IPv6 address, all of the first 96 518 bits MUST be checked for the pattern -- it is not sufficient to check 519 for ones in bits 81-96. 521 The all-zeroes IPv6 address MUST be expressed by filling the fixed- 522 size 128-bit IP address field with all zeroes (::). 524 The all-zeroes IPv4 address MUST be expressed by 80 bits of zeros, 16 525 bits of ones, and 32 bits of zeros (::ffff:0:0). 527 6. Protocol Design Note 529 PCP can be viewed as a request/response protocol, much like many 530 other UDP-based request/response protocols, and can be implemented 531 perfectly well as such. It can also be viewed as what might be 532 called a hint/notification protocol, and this observation can help 533 simplify implementations. 535 Rather than viewing the message streams between PCP client and PCP 536 server as following a strict request/response pattern, where every 537 response is associated with exactly one request, the message flows 538 can be viewed as two somewhat independent streams carrying 539 information in opposite directions: 541 o A stream of hints flowing from PCP client to PCP server, where the 542 client indicates to the server what it would like the state of its 543 mappings to be, and 545 o A stream of notifications flowing from PCP server to PCP client, 546 where the server informs the clients what the state of its 547 mappings actually is. 549 To an extent, some of this approach is required anyway in a UDP-based 550 request/response protocol, since UDP packets can be lost, duplicated, 551 or reordered. 553 In this view of the protocol, the client transmits hints to the 554 server at various intervals signaling its desires, and the server 555 transmits notifications to the client signaling the actual state of 556 its mappings. These two message flows are loosely correlated in that 557 a client request (hint) usually elicits a server response 558 (notification), but only loosely, in that a client request may result 559 in no server response (in the case of packet loss) and a server 560 response may be generated gratuitously without an immediately 561 preceding client request (in the case where server configuration 562 change, e.g. change of external IP address on a NAT gateway, results 563 in a change of mapping state). 565 The exact times that client requests are sent are influenced by a 566 client timing state machine taking into account whether (i) the 567 client has not yet received a response from the server for a prior 568 request (retransmission), or (ii) the client has previously received 569 a response from the server saying how long the indicated mapping 570 would remain active (renewal). This design philosophy is the reason 571 why PCP's retransmissions and renewals are exactly the same packet on 572 the wire. Typically, retransmissions are sent with exponentially 573 increasing intervals as the client waits for the server to respond, 574 whereas renewals are sent with exponentially decreasing intervals as 575 the expiry time approaches, but from the server's point of view both 576 packets are identical, and both signal the client's desire that the 577 stated mapping exist or continue to exist. 579 A PCP server usually sends responses as a direct result of client 580 requests, but not always. For example, if a server is too overloaded 581 to respond, it is allowed to silently ignore a request message and 582 let the client retransmit. Also, if external factors cause a NAT 583 gateway or firewall's configuration to change, then the PCP server 584 can send unsolicited responses to clients informing them of the new 585 state of their mappings. Such reconfigurations are expected to be 586 rare, because of the disruption they can cause to clients, but should 587 they happen, PCP provides a way for servers to communicate the new 588 state to clients promptly, without having to wait for the next 589 periodic renewal request. 591 This design goal helps explain why PCP request and response messages 592 have no transaction ID, because such a transaction ID is unnecessary, 593 and would unnecessarily limit the protocol and unnecessarily 594 complicate implementations. A PCP server response (i.e. 595 notification) is self-describing and complete. It communicates the 596 internal and external addresses, protocol, and ports for a mapping, 597 and its remaining lifetime. If the client does in fact currently 598 want such a mapping to exist then it can identify the mapping in 599 question from the internal address, protocol, and port, and update 600 its state to reflect the current external address and port, and 601 remaining lifetime. If a client does not currently want such a 602 mapping to exist then it can safely ignore the message. No client 603 action is required for unexpected mapping notifications. In today's 604 world a NAT gateway can have a static mapping, and the client device 605 has no explicit knowledge of this, and no way to change the fact. 606 Also, in today's world a client device can be connected directly to 607 the public Internet, with a globally-routable IP address, and in this 608 case it effectively has "mappings" for all of its listening ports. 609 Such a device has to be responsible for its own security, and cannot 610 rely on assuming that some other network device will be blocking all 611 incoming packets. 613 7. Common Request and Response Header Format 615 All PCP messages are sent over UDP, with a maximum UDP payload length 616 of 1100 octets. The PCP messages contain a request or response 617 header containing an Opcode, any relevant Opcode-specific 618 information, and zero or more Options. All numeric quantities larger 619 than a single octet (e.g. Result codes, Lifetimes, Epoch times, 620 etc.) are represented in conventional IETF network order, i.e. most 621 significant octet first. Non-numeric quantities are represented 622 as-is on all platforms, with no byte swapping (e.g. IP addresses and 623 ports are placed in PCP messages using the same representation as 624 when placed in IP or TCP headers). 626 The packet layout for the common header, and operation of the PCP 627 client and PCP server, are described in the following sections. The 628 information in this section applies to all Opcodes. Behavior of the 629 Opcodes defined in this document is described in Section 11 and 630 Section 12. 632 7.1. Request Header 634 All requests have the following format: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Version = 2 |R| Opcode | Reserved | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Requested Lifetime (32 bits) | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 | PCP Client's IP Address (128 bits) | 645 | | 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 : : 649 : (optional) Opcode-specific information : 650 : : 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 : : 653 : (optional) PCP Options : 654 : : 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 2: Common Request Packet Format 659 These fields are described below: 661 Version: This document specifies protocol version 2. PCP clients 662 and servers compliant with this document use the value 2. This 663 field is used for version negotiation as described in Section 9. 665 R: Indicates Request (0) or Response (1). 667 Opcode: A seven-bit value specifying the operation to be performed. 668 Opcodes are defined in Section 11 and Section 12. 670 Reserved: 16 reserved bits. MUST be zero on transmission and MUST 671 be ignored on reception. 673 Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging 674 from 0 to 2^32-1 seconds. This is used by the MAP and PEER 675 Opcodes defined in this document for their requested lifetime. 677 PCP Client's IP Address: The source IPv4 or IPv6 address in the IP 678 header used by the PCP client when sending this PCP request. IPv4 679 is represented using an IPv4-mapped IPv6 address. This is used to 680 detect an unexpected NAT on the path between the PCP client and 681 the PCP-controlled NAT or firewall device. See Section 8.1 683 Opcode-specific information: Payload data for this Opcode. The 684 length of this data is determined by the Opcode definition. 686 PCP Options: Zero, one, or more Options that are legal for both a 687 PCP request and for this Opcode. See Section 7.3. 689 7.2. Response Header 691 All responses have the following format: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Version = 2 |R| Opcode | Reserved | Result Code | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Lifetime (32 bits) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Epoch Time (32 bits) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | | 703 | Reserved (96 bits) | 704 | | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 : : 707 : (optional) Opcode-specific response data : 708 : : 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 : (optional) Options : 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 3: Common Response Packet Format 715 These fields are described below: 717 Version: Responses from servers compliant with this specification 718 MUST use version 2. This is set by the server. 720 R: Indicates Request (0) or Response (1). All Responses MUST use 1. 721 This is set by the server. 723 Opcode: The 7-bit Opcode value. The server copies this value from 724 the request. 726 Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when 727 received. This is set by the server. 729 Result Code: The result code for this response. See Section 7.4 for 730 values. This is set by the server. 732 Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 733 2^32-1 seconds. On an error response, this indicates how long 734 clients should assume they'll get the same error response from 735 that PCP server if they repeat the same request. On a success 736 response for the PCP Opcodes that create a mapping (MAP and PEER), 737 the Lifetime field indicates the lifetime for this mapping. This 738 is set by the server. 740 Epoch Time: The server's Epoch time value. See Section 8.5 for 741 discussion. This value is set by the server, in both success and 742 error responses. 744 Reserved: 96 reserved bits. For requests that were successfully 745 parsed, this MUST be sent as 0, MUST be ignored when received. 746 This is set by the server. For requests that were not 747 successfully parsed, the server copies the last 96 bits of the PCP 748 Client's IP Address field from the request message into this 749 corresponding 96 bit field of the response. 751 Opcode-specific information: Payload data for this Opcode. The 752 length of this data is determined by the Opcode definition. 754 PCP Options: Zero, one, or more Options that are legal for both a 755 PCP response and for this Opcode. See Section 7.3. 757 7.3. Options 759 A PCP Opcode can be extended with one or more Options. Options can 760 be used in requests and responses. The design decisions in this 761 specification about whether to include a given piece of information 762 in the base Opcode format or in an Option were an engineering trade- 763 off between packet size and code complexity. For information that is 764 usually (or always) required, placing it in the fixed Opcode data 765 results in simpler code to generate and parse the packet, because the 766 information is a fixed location in the Opcode data, but wastes space 767 in the packet in the event that field is all-zeroes because the 768 information is not needed or not relevant. For information that is 769 required less often, placing it in an Option results in slightly more 770 complicated code to generate and parse packets containing that 771 Option, but saves space in the packet when that information is not 772 needed. Placing information in an Option also means that an 773 implementation that never uses that information doesn't even need to 774 implement code to generate and parse it. For example, a client that 775 never requests mappings on behalf of some other device doesn't need 776 to implement code to generate the THIRD_PARTY Option, and a PCP 777 server that doesn't implement the necessary security measures to 778 create third-party mappings safely doesn't need to implement code to 779 parse the THIRD_PARTY Option. 781 Options use the following Type-Length-Value format: 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Option Code | Reserved | Option Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 : (optional) data : 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 4: Options Header 793 The description of the fields is as follows: 795 Option Code: 8 bits. Its most significant bit indicates if this 796 Option is mandatory (0) or optional (1) to process. 798 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 799 ignored on reception. 801 Option Length: 16 bits. Indicates the length of the enclosed data, 802 in octets. Options with length of 0 are allowed. Options that 803 are not a multiple of four octets long are followed by one, two, 804 or three zero octets to pad their effective length in the packet 805 to be a multiple of four octets. The Option Length reflects the 806 semantic length of the option, not including any padding octets. 808 data: Option data. 810 If several Options are included in a PCP request, they MAY be encoded 811 in any order by the PCP client, but MUST be processed by the PCP 812 server in the order in which they appear. It is the responsibility 813 of the PCP client to ensure the server has sufficient room to reply 814 without exceeding the 1100 octet size limit; if its reply would 815 exceed that size, the server generates an error. 817 If, while processing a PCP request, including its options, an error 818 is encountered that causes a PCP error response to be generated, the 819 PCP request MUST cause no state change in the PCP server or the PCP- 820 controlled device (i.e., it rolls back any changes it might have made 821 while processing the request). Such an error response MUST consist 822 of a complete copy of the request packet with the error code and 823 other appropriate fields set in the header. 825 An Option MAY appear more than once in a request or in a response, if 826 permitted by the definition of the Option. If the Option's 827 definition allows the Option to appear only once but it appears more 828 than once in a request, and the Option is understood by the PCP 829 server, the PCP server MUST respond with the MALFORMED_OPTION result 830 code. If the PCP server encounters an invalid option (e.g., PCP 831 option length is longer than the UDP packet length) the error 832 MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST), 833 as that helps the client better understand how the packet was 834 malformed. If a PCP response would have exceeded the maximum PCP 835 message size, the PCP server SHOULD respond with MALFORMED_REQUEST. 837 If the overall Option structure of a request cannot successfully be 838 parsed (e.g. a nonsensical option length) the PCP server MUST 839 generate an error response with code MALFORMED_OPTION. 841 If the overall Option structure of a request is valid then how each 842 individual Option is handled is determined by the most significant 843 bit in the Option Code. If the most significant bit is set, handling 844 this Option is optional, and a PCP server MAY process or ignore this 845 Option, entirely at its discretion. If the most significant bit is 846 clear, handling this Option is mandatory, and a PCP server MUST 847 return the error MALFORMED_OPTION if the option contents are 848 malformed, or UNSUPP_OPTION if the Option is unrecognized, 849 unimplemented, or disabled, or if the client is not authorized to use 850 the Option. In error responses all options are returned. In success 851 responses all processed options are included and unprocessed options 852 are not included. 854 PCP clients are free to ignore any or all Options included in 855 responses, although naturally if a client explicitly requests an 856 Option where correct execution of that Option requires processing the 857 Option data in the response, that client is expected to implement 858 code to do that. 860 Different options are valid for different Opcodes. For example: 862 o The THIRD_PARTY Option is valid for both MAP and PEER Opcodes. 864 o The FILTER Option is valid only for the MAP Opcode (for the PEER 865 Opcode it would have no meaning). 867 o The PREFER_FAILURE Option is valid only for the MAP Opcode (for 868 the PEER Opcode, similar semantics are automatically implied). 870 7.4. Result Codes 872 The following result codes may be returned as a result of any Opcode 873 received by the PCP server. The only success result code is 0; other 874 values indicate an error. If a PCP server encounters multiple errors 875 during processing of a request, it SHOULD use the most specific error 876 message. Each error code below is classified as either a 'long 877 lifetime' error or a 'short lifetime' error, which provides guidance 878 to PCP server developers for the value of the Lifetime field for 879 these errors. It is RECOMMENDED that short lifetime errors use a 30 880 second lifetime and long lifetime errors use a 30 minute lifetime. 882 0 SUCCESS: Success. 884 1 UNSUPP_VERSION: The version number at the start of the PCP Request 885 header is not recognized by this PCP server. This is a long 886 lifetime error. This document describes PCP version 2. 888 2 NOT_AUTHORIZED: The requested operation is disabled for this PCP 889 client, or the PCP client requested an operation that cannot be 890 fulfilled by the PCP server's security policy. This is a long 891 lifetime error. 893 3 MALFORMED_REQUEST: The request could not be successfully parsed. 894 This is a long lifetime error. 896 4 UNSUPP_OPCODE: Unsupported Opcode. This is a long lifetime error. 898 5 UNSUPP_OPTION: Unsupported Option. This error only occurs if the 899 Option is in the mandatory-to-process range. This is a long 900 lifetime error. 902 6 MALFORMED_OPTION: Malformed Option (e.g., appears too many times, 903 invalid length). This is a long lifetime error. 905 7 NETWORK_FAILURE: The PCP server or the device it controls are 906 experiencing a network failure of some sort (e.g., has not 907 obtained an External IP address). This is a short lifetime error. 909 8 NO_RESOURCES: Request is well-formed and valid, but the server has 910 insufficient resources to complete the requested operation at this 911 time. For example, the NAT device cannot create more mappings at 912 this time, is short of CPU cycles or memory, or is unable to 913 handle the request due to some other temporary condition. The 914 same request may succeed in the future. This is a system-wide 915 error, different from USER_EX_QUOTA. This can be used as a catch- 916 all error, should no other error message be suitable. This is a 917 short lifetime error. 919 9 UNSUPP_PROTOCOL: Unsupported transport protocol, e.g. SCTP in a 920 NAT that handles only UDP and TCP. This is a long lifetime error. 922 10 USER_EX_QUOTA: This attempt to create a new mapping would exceed 923 this subscriber's port quota. This is a short lifetime error. 925 11 CANNOT_PROVIDE_EXTERNAL: The suggested external port and/or 926 external address cannot be provided. This error MUST only be 927 returned for: 928 * MAP requests that included the PREFER_FAILURE Option 929 (normal MAP requests will return an available external port) 930 * MAP requests for the SCTP protocol (PREFER_FAILURE is implied) 931 * PEER requests 933 See Section 13.2 for processing details. The error lifetime 934 depends on the reason for the failure. 936 12 ADDRESS_MISMATCH: The source IP address of the request packet does 937 not match the contents of the PCP Client's IP Address field, due 938 to an unexpected NAT on the path between the PCP client and the 939 PCP-controlled NAT or firewall. This is a long lifetime error. 941 13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the 942 filters in this request. This result code MUST only be returned 943 if the MAP request contained the FILTER Option. See Section 13.3 944 for processing information. This is a long lifetime error. 946 8. General PCP Operation 948 PCP messages MUST be sent over UDP [RFC0768]. Every PCP request 949 generates at least one response, so PCP does not need to run over a 950 reliable transport protocol. 952 When receiving multiple identical requests, the PCP server will 953 generate identical responses, provided the PCP server's state did not 954 change between those requests due to other activity. For example, if 955 a request is received while the PCP-controlled device has no mappings 956 available, it will generate an error response. If mappings become 957 available and then a (duplicated or re-transmitted) request is seen 958 by the server, it will generate a non-error response. A PCP client 959 MUST handle such updated responses for any request it sends, most 960 notably to support Rapid Recovery (Section 14). Also see the 961 Protocol Design Note (Section 6). 963 8.1. General PCP Client: Generating a Request 965 This section details operation specific to a PCP client, for any 966 Opcode. Procedures specific to the MAP Opcode are described in 967 Section 11, and procedures specific to the PEER Opcode are described 968 in Section 12. 970 Prior to sending its first PCP message, the PCP client determines 971 which server to use. The PCP client performs the following steps to 972 determine its PCP server: 974 1. if a PCP server is configured (e.g., in a configuration file or 975 via DHCP), that single configuration source is used as the list 976 of PCP Server(s), else; 978 2. the default router list (for IPv4 and IPv6) is used as the list 979 of PCP Server(s). Thus, if a PCP client has both an IPv4 and 980 IPv6 address, it will have an IPv4 PCP server (its IPv4 default 981 router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6 982 default router) for its IPv6 mappings. 984 For the purposes of this document, only a single PCP server address 985 is supported. Should future specifications define configuration 986 methods that provide a longer list of PCP server addresses, those 987 specifications will define how clients select one or more addresses 988 from that list. 990 With that PCP server address, the PCP client formulates its PCP 991 request. The PCP request contains a PCP common header, PCP Opcode 992 and payload, and (possibly) Options. As with all UDP client software 993 on any operating system, when several independent PCP clients exist 994 on the same host, each uses a distinct source port number to 995 disambiguate their requests and replies. The PCP client's source 996 port SHOULD be randomly generated [RFC6056]. 998 The PCP client MUST include the source IP address of the PCP message 999 in the PCP request. This is typically its own IP address; see 1000 Section 16.4 for how this can be coded. This is used to detect an 1001 unexpected NAT on the path between the PCP client and the PCP- 1002 controlled NAT or firewall device, to avoid wasting state on the PCP- 1003 controlled NAT creating pointless non-functional mappings. When such 1004 an intervening non-PCP-aware inner NAT is detected, mappings must 1005 first be created by some other means in the inner NAT, before 1006 mappings can be usefully created in the outer PCP-controlled NAT. 1007 Having created mappings in the inner NAT by some other means, the PCP 1008 client should then use the inner NAT's External Address as the Client 1009 IP Address, to signal to the outer PCP-controlled NAT that the client 1010 is aware of the inner NAT, and has taken steps to create mappings in 1011 it by some other means, so that mappings created in the outer NAT 1012 will not be a pointless waste of state. 1014 8.1.1. PCP Client Retransmission 1016 PCP clients are responsible for reliable delivery of PCP request 1017 messages. If a PCP client fails to receive an expected response from 1018 a server, the client must retransmit its message. The 1019 retransmissions MUST use the same Mapping Nonce value (see 1020 Section 11.1 and Section 12.1). The client begins the message 1021 exchange by transmitting a message to the server. The message 1022 exchange continues for as long as the client wishes to maintain the 1023 mapping, and terminates when the PCP client is no longer interested 1024 in the PCP transaction (e.g., the application that requested the 1025 mapping is no longer interested in the mapping) or (optionally) when 1026 the message exchange is considered to have failed according to the 1027 retransmission mechanism described below. 1029 The client retransmission behavior is controlled and described by the 1030 following variables: 1032 RT: Retransmission timeout, calculated as described below 1034 IRT: Initial retransmission time, SHOULD be 3 seconds 1036 MRC: Maximum retransmission count, SHOULD be 0 (0 indicates no 1037 maximum) 1039 MRT: Maximum retransmission time, SHOULD be 1024 seconds 1041 MRD: Maximum retransmission duration, SHOULD be 0 (0 indicates no 1042 maximum) 1044 RAND: Randomization factor, calculated as described below 1046 With each message transmission or retransmission, the client sets RT 1047 according to the rules given below. If RT expires before a response 1048 is received, the client recomputes RT and retransmits the request. 1050 Each of the computations of a new RT include a new randomization 1051 factor (RAND), which is a random number chosen with a uniform 1052 distribution between -0.1 and +0.1. The randomization factor is 1053 included to minimize synchronization of messages transmitted by PCP 1054 clients. The algorithm for choosing a random number does not need to 1055 be cryptographically sound. The algorithm SHOULD produce a different 1056 sequence of random numbers from each invocation of the PCP client. 1058 The RT value is initialized based on IRT: 1060 RT = (1 + RAND) * IRT 1062 RT for each subsequent message transmission is based on the previous 1063 value of RT, subject to the upper bound on the value of RT specified 1064 by MRT. If MRT has a value of 0, there is no upper limit on the 1065 value of RT, and MRT is treated as "infinity": 1067 RT = (1 + RAND) * MIN (2 * RTprev, MRT) 1069 MRC specifies an upper bound on the number of times a client may 1070 retransmit a message. Unless MRC is zero, the message exchange fails 1071 once the client has transmitted the message MRC times. 1073 MRD specifies an upper bound on the length of time a client may 1074 retransmit a message. Unless MRD is zero, the message exchange fails 1075 once MRD seconds have elapsed since the client first transmitted the 1076 message. 1078 If both MRC and MRD are non-zero, the message exchange fails whenever 1079 either of the conditions specified in the previous two paragraphs are 1080 met. If both MRC and MRD are zero, the client continues to transmit 1081 the message until it receives a response, or the client no longer 1082 wants a mapping. 1084 Once a PCP client has successfully received a response from a PCP 1085 server on that interface, it resets RT to a value randomly selected 1086 in the range 1/2 to 5/8 of the mapping lifetime, as described in 1087 Section 11.2.1, and sends subsequent PCP requests for that mapping to 1088 that same server. 1090 Note: If the server's state changes between retranmissions and the 1091 server's response is delayed or lost, the state in the PCP client 1092 and server may not be synchronized. This is not unique to PCP, 1093 but also occurs with other network protocols (e.g., TCP). In the 1094 unlikely event that such de-synchronization occurs, PCP heals 1095 itself after Lifetime seconds. 1097 8.2. General PCP Server: Processing a Request 1099 This section details operation specific to a PCP server. Processing 1100 SHOULD be performed in the order of the following paragraphs. 1102 A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests 1103 from a client on the same interface it would normally receive packets 1104 from that client, and MUST silently ignore PCP requests arriving on 1105 any other interface. For example, a residential NAT gateway accepts 1106 PCP requests only when they arrive on its (LAN) interface connecting 1107 to the internal network, and silently ignores any PCP requests 1108 arriving on its external (WAN) interface. A PCP server which 1109 supports THIRD_PARTY requests MAY be configured to accept THIRD_PARTY 1110 requests on other configured interfaces (see Section 13.1). 1112 Upon receiving a request, the PCP server parses and validates it. A 1113 valid request contains a valid PCP common header, one valid PCP 1114 Opcode, and zero or more Options (which the server might or might not 1115 comprehend). If an error is encountered during processing, the 1116 server generates an error response which is sent back to the PCP 1117 client. Processing an Opcode and the Options are specific to each 1118 Opcode. 1120 Error responses have the same packet layout as success responses, 1121 with certain fields from the request copied into the response, and 1122 other fields assigned by the PCP server set as indicated in Figure 3. 1124 Copying request fields into the response is important because this is 1125 what enables a client to identify to which request a given response 1126 pertains. For Opcodes that are understood by the PCP server, it 1127 follows the requirements of that Opcode to copy the appropriate 1128 fields. For Opcodes that are not understood by the PCP server, it 1129 simply generates the UNSUPP_OPCODE response and copies fields from 1130 the PCP header and copies the rest of the PCP payload as-is (without 1131 attempting to interpret it). 1133 All responses (both error and success) contain the same Opcode as the 1134 request, but with the "R" bit set. 1136 Any error response has a nonzero Result Code, and is created by: 1137 o Copying the entire UDP payload, or 1100 octets, whichever is less, 1138 and zero-padding the response to a multiple of 4 octets if 1139 necessary 1140 o Setting the R bit 1141 o Setting the Result Code 1142 o Setting the Lifetime, Epoch Time and Reserved fields 1143 o Updating other fields in the response, as indicated by 'set by the 1144 server' in the PCP response field description. 1146 A success response has a zero Result Code, and is created by: 1147 o Copying the first four octets of request packet header 1148 o Setting the R bit 1149 o Setting the Result Code to zero 1150 o Setting the Lifetime, Epoch Time and Reserved fields 1151 o Possibly setting opcode-specific response data if appropriate 1152 o Adding any processed options to the response message 1154 If the received PCP request message is less than two octets long it 1155 is silently dropped. 1157 If the R bit is set the message is silently dropped. 1159 If the first octet (version) is a version that is not supported, a 1160 response is generated with the UNSUPP_VERSION result code, and the 1161 other steps detailed in Section 9 are followed. 1163 Otherwise, if the version is supported but the received message is 1164 shorter than 24 octets, the message is silently dropped. 1166 If the server is overloaded by requests (from a particular client or 1167 from all clients), it MAY simply silently discard requests, as the 1168 requests will be retried by PCP clients, or it MAY generate the 1169 NO_RESOURCES error response. 1171 If the length of the message exceeds 1100 octets, is not a multiple 1172 of 4 octets, or is too short for the opcode in question, it is 1173 invalid and a MALFORMED_REQUEST response is generated, and the 1174 response message is truncated to 1100 octets. 1176 The PCP server compares the source IP address (from the received IP 1177 header) with the field PCP Client IP Address. If they do not match, 1178 the error ADDRESS_MISMATCH MUST be returned. This is done to detect 1179 and prevent accidental use of PCP where a non-PCP-aware NAT exists 1180 between the PCP client and PCP server. If the PCP client wants such 1181 a mapping it needs to ensure the PCP field matches its apparent IP 1182 address from the perspective of the PCP server. 1184 8.3. General PCP Client: Processing a Response 1186 The PCP client receives the response and verifies that the source IP 1187 address and port belong to the PCP server of a previously-sent PCP 1188 request. If not, the response is silently dropped. 1190 If the received PCP response message is less than four octets long it 1191 is silently dropped. 1193 If the R bit is clear the message is silently dropped. 1195 If the error code is UNSUPP_VERSION processing continues as described 1196 in Section 9. 1198 The PCP client then validates that the Opcode matches a previous PCP 1199 request. Responses shorter than 24 octets, longer than 1100 octets, 1200 or not a multiple of 4 octets are invalid and ignored, likely causing 1201 the request to be re-transmitted. The response is further matched by 1202 comparing fields in the response Opcode-specific data to fields in 1203 the request Opcode-specific data, as described by the processing for 1204 that Opcode. 1206 After these matches are successful, the PCP client checks the Epoch 1207 Time field to determine if it needs to restore its state to the PCP 1208 server (see Section 8.5). A PCP client SHOULD be prepared to receive 1209 multiple responses from the PCP Server at any time after a single 1210 request is sent. This allows the PCP server to inform the client of 1211 mapping changes such as an update or deletion. For example, a PCP 1212 Server might send a SUCCESS response and, after a configuration 1213 change on the PCP Server, later send a NOT_AUTHORIZED response. A 1214 PCP client MUST be prepared to receive responses for requests it 1215 never sent (which could have been sent by a previous PCP instance on 1216 this same host, or by a previous host that used the same client IP 1217 address, or by a malicious attacker) by simply ignoring those 1218 unexpected messages. 1220 If the error ADDRESS_MISMATCH is received, it indicates the presence 1221 of a NAT between the PCP client and PCP server. Procedures to 1222 resolve this problem are beyond the scope of this document. 1224 For both success and error responses a Lifetime value is returned. 1225 The Lifetime indicates how long this request is considered valid by 1226 the server. The PCP client SHOULD impose an upper limit on this 1227 returned value (to protect against absurdly large values, e.g., 5 1228 years), detailed in Section 15. 1230 If the result code is 0 (SUCCESS), the request succeeded. 1232 If the result code is not 0, the request failed, and the PCP client 1233 SHOULD NOT resend the same request for the indicated Lifetime of the 1234 error (as limited by the sanity checking detailed in Section 15). 1236 If the PCP client has discovered a new PCP server (e.g., connected to 1237 a new network), the PCP client MAY immediately begin communicating 1238 with this PCP server, without regard to hold times from communicating 1239 with a previous PCP server. 1241 8.4. Multi-Interface Issues 1243 Hosts that desire a PCP mapping might be multi-interfaced (i.e., own 1244 several logical/physical interfaces). Indeed, a host can be 1245 configured with several IPv4 addresses (e.g., Wi-Fi and Ethernet) or 1246 dual-stacked. These IP addresses may have distinct reachability 1247 scopes (e.g., if IPv6 they might have global reachability scope as 1248 for Global Unicast Address (GUA, [RFC3587]) or limited scope as for 1249 Unique Local Address (ULA) [RFC4193]). 1251 IPv6 addresses with global reachability (e.g., GUA) SHOULD be used as 1252 the source address when generating a PCP request. IPv6 addresses 1253 without global reachability (e.g., ULA [RFC4193]), SHOULD NOT be used 1254 as the source interface when generating a PCP request. If IPv6 1255 privacy addresses [RFC4941] are used for PCP mappings, a new PCP 1256 request will need to be issued whenever the IPv6 privacy address is 1257 changed. This PCP request SHOULD be sent from the IPv6 privacy 1258 address itself. It is RECOMMENDED that the client delete its 1259 mappings to the previous privacy address after it no longer needs 1260 those old mappings. 1262 Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope 1263 (e.g., private addresses [RFC1918]) MAY be used as the source 1264 interface when generating a PCP request. 1266 8.5. Epoch 1268 Every PCP response sent by the PCP server includes an Epoch time 1269 field. This time field increments by one every second. Anomalies in 1270 the received Epoch time value provide a hint to PCP clients that a 1271 PCP server state loss may have occurred. Clients respond to such 1272 state loss hints by promptly renewing their mappings, so as to 1273 quickly restore any lost state at the PCP server. 1275 If the PCP server resets or loses the state of its explicit dynamic 1276 Mappings (that is, those mappings created by PCP requests), due to 1277 reboot, power failure, or any other reason, it MUST reset its Epoch 1278 time to its initial starting value (usually zero) to provide this 1279 hint to PCP clients. After resetting its Epoch time, the PCP server 1280 resumes incrementing the Epoch time value by one every second. 1281 Similarly, if the External IP Address(es) of the NAT (controlled by 1282 the PCP server) changes, the Epoch time MUST be reset. A PCP server 1283 MAY maintain one Epoch time value for all PCP clients, or MAY 1284 maintain distinct Epoch time values (per PCP client, per interface, 1285 or based on other criteria); this choice is implementation-dependent. 1287 Whenever a client receives a PCP response, the client validates the 1288 received Epoch time value according to the procedure below, using 1289 integer arithmetic: 1291 o If this is the first PCP response the client has received from 1292 this PCP server, the Epoch time value is treated as necessarily 1293 valid, otherwise 1295 * If the current PCP server Epoch time (curr_server_time) is less 1296 than the previously received PCP server Epoch time 1297 (prev_server_time) by more than one second, then the client 1298 treats the Epoch time as obviously invalid (time should not go 1299 backwards). The server Epoch time apparently going backwards 1300 by *up to* one second is not deemed invalid, so that minor 1301 packet re-ordering on the path from PCP Server to PCP Client 1302 does not trigger a cascade of unnecessary mapping renewals. If 1303 the server Epoch time passes this check, then further 1304 validation checks are performed: 1306 + The client computes the difference between its 1307 current local time (curr_client_time) and the 1308 time the previous PCP response was received from this PCP 1309 server (prev_client_time): 1310 client_delta = curr_client_time - prev_client_time; 1312 + The client computes the difference between the 1313 current PCP server Epoch time (curr_server_time) and the 1314 previously received Epoch time (prev_server_time): 1315 server_delta = curr_server_time - prev_server_time; 1317 + If client_delta+2 < server_delta - server_delta/16 1318 or server_delta+2 < client_delta - client_delta/16 1319 then the client treats the Epoch time value as invalid, 1320 else the client treats the Epoch time value as valid 1322 o The client records the current time values for use in its next 1323 comparison: 1324 prev_client_time = curr_client_time 1325 prev_server_time = curr_server_time 1327 If the PCP client determined that the Epoch time value it received 1328 was invalid then it concludes that the PCP server may have lost 1329 state, and promptly renews all its active port mapping leases as 1330 described in Section 16.3.1. 1332 Notes: 1334 o The client clock MUST never go backwards. If curr_client_time is 1335 found to be less than prev_client_time then this is a client bug, 1336 and how the client deals with this client bug is implementation 1337 specific. 1339 o The calculations above are constructed to allow client_delta and 1340 server_delta to be computed as unsigned integer values. 1342 o The "+2" in the calculations above is to accommodate quantization 1343 errors in client and server clocks (up to one second quantization 1344 error each in server and client time intervals). 1346 o The "/16" in the calculations above is to accommodate inaccurate 1347 clocks in low-cost devices. This allows for a total discrepancy 1348 of up to 1/16 (6.25%) to be considered benign, e.g., if one clock 1349 were to run too fast by 3% while the other clock ran too slow by 1350 3% then the client would not consider this difference to be 1351 anomalous or indicative of a restart having occurred. This 1352 tolerance is strict enough to be effective at detecting reboots, 1353 while not being so strict as to generate false alarms. 1355 9. Version Negotiation 1357 A PCP client sends its requests using PCP version number 2. Should 1358 later updates to this document specify different message formats with 1359 a version number greater than 2 it is expected that PCP servers will 1360 still support version 2 in addition to the newer version(s). 1361 However, in the event that a server returns a response with result 1362 code UNSUPP_VERSION, the client MAY log an error message to inform 1363 the user that it is too old to work with this server. 1365 Should later updates to this document specify different message 1366 formats with a version number greater than 2, and backwards 1367 compatibility is desired, this first octet can be used for forward 1368 and backward compatibility. 1370 If future PCP versions greater than 2 are specified, version 1371 negotiation proceeds as follows: 1373 1. The client sends its first request using the highest (i.e., 1374 presumably 'best') version number it supports. 1376 2. If the server supports that version it responds normally. 1378 3. If the server does not support that version it replies giving a 1379 result containing the result code UNSUPP_VERSION, and the closest 1380 version number it does support (if the server supports a range of 1381 versions higher than the client's requested version, the server 1382 returns the lowest of that supported range; if the server 1383 supports a range of versions lower than the client's requested 1384 version, the server returns the highest of that supported range). 1386 4. If the client receives an UNSUPP_VERSION result containing a 1387 version it does support, it records this fact and proceeds to use 1388 this message version for subsequent communication with this PCP 1389 server (until a possible future UNSUPP_VERSION response if the 1390 server is later updated, at which point the version negotiation 1391 process repeats). 1393 5. If the client receives an UNSUPP_VERSION result containing a 1394 version it does not support then the client SHOULD try the next- 1395 lower version supported by the client. The attempt to use the 1396 next-lower version repeats until the client has tried version 2. 1397 If using version 2 fails, the client MAY log an error message to 1398 inform the user that it is too old to work with this server, and 1399 the client SHOULD set a timer to retry its request in 30 minutes 1400 or the returned Lifetime value, whichever is smaller. By 1401 automatically retrying in 30 minutes, the protocol accommodates 1402 an upgrade of the PCP server. 1404 10. Introduction to MAP and PEER Opcodes 1406 There are four uses for the MAP and PEER Opcodes defined in this 1407 document: 1409 o a host operating a server and wanting an incoming connection 1410 (Section 10.1); 1412 o a host operating a client and server on the same port 1413 (Section 10.2); 1415 o a host operating a client and wanting to optimize the application 1416 keepalive traffic (Section 10.3); 1418 o and a host operating a client and wanting to restore lost state in 1419 its NAT (Section 10.4). 1421 These are discussed in the following sections, and a (non-normative) 1422 state diagram is provided in Section 16.5. 1424 When operating a server (Section 10.1 and Section 10.2) the PCP 1425 client knows if it wants an IPv4 listener, IPv6 listener, or both on 1426 the Internet. The PCP client also knows if it has an IPv4 address or 1427 IPv6 address configured on one of its interfaces. It takes the union 1428 of this knowledge to decide to which of its PCP servers to send the 1429 request (e.g., an IPv4 address or an IPv6 address), and if to send 1430 one or two MAP requests for each of its interfaces (e.g., if the PCP 1431 client has only an IPv4 address but wants both IPv6 and IPv4 1432 listeners, it sends a MAP request containing the all-zeros IPv6 1433 address in the Suggested External Address field, and sends a second 1434 MAP request containing the all-zeros IPv4 address in the Suggested 1435 External Address field. If the PCP client has both an IPv4 and IPv6 1436 address, and only wants an IPv4 listener, it sends one MAP request 1437 from its IPv4 address (if the PCP server supports NAT44 or IPv4 1438 firewall) or one MAP request from its IPv6 address (if the PCP server 1439 supports NAT64). The PCP client can simply request the desired 1440 mapping to determine if the PCP server supports the desired mapping. 1441 Applications that embed IP addresses in payloads (e.g., FTP, SIP) 1442 will find it beneficial to avoid address family translation, if 1443 possible. 1445 The MAP and PEER requests include a Suggested External IP Address 1446 field. Some PCP-controlled devices, especially CGN but also multi- 1447 homed NPTv6 networks, have a pool of public-facing IP addresses. PCP 1448 allows the client to indicate if it wants a mapping assigned on a 1449 specific address of that pool or any address of that pool. Some 1450 applications will break if mappings are created on different IP 1451 addresses (e.g., active mode FTP), so applications should carefully 1452 consider the implications of using this capability. Static mappings 1453 for that Internal Address (e.g., those created by a command-line 1454 interface on the PCP server or PCP-controlled device) may exist to a 1455 certain External Address, and if the Suggested External IP Address is 1456 the all-zeros address, PCP SHOULD assign its mappings to the same 1457 External Address, as this can also help applications using a mix of 1458 both static mappings and PCP-created mappings. If, on the other 1459 hand, the Suggested External IP Address contains a non-zero IP 1460 address the PCP Server SHOULD create a mapping to that external 1461 address, even if there are other mappings from that same Internal 1462 Address to a different External Address. Once an Internal Address 1463 has no implicit dynamic mappings and no explicit dynamic mappings in 1464 the PCP-controlled device, a subsequent implicit or explicit mapping 1465 for that Internal Address MAY be assigned to a different External 1466 Address. Generally, this re-assignment would occur when a CGN device 1467 is load balancing newly-seen Internal Addresses to its public pool of 1468 External Addresses. 1470 The following table summarizes how various common PCP deployments use 1471 IPv6 and IPv4 addresses. 1473 The 'internal' address is implicitly the same as the source IP 1474 address of the PCP request, except when the THIRD_PARTY option is 1475 used. 1477 The 'external' address is the Suggested External Address field of the 1478 MAP or PEER request, and is address family is usually the same as the 1479 'internal' address family, except when technologies like NAT64 are 1480 used. 1482 The 'remote peer' address is the Remote Peer IP Address of the PEER 1483 request or the FILTER option of the MAP request, and is always the 1484 same address family as the 'internal' address, even when NAT64 is 1485 used. 1487 In NAT64, the IPv6 PCP client is not necessarily aware of the NAT64 1488 or aware of the actual IPv4 address of the remote peer, so it 1489 expresses the IPv6 address from its perspective, as shown in the 1490 table. 1492 internal external PCP remote peer actual remote peer 1493 -------- ------- --------------- ------------------ 1494 IPv4 firewall IPv4 IPv4 IPv4 IPv4 1495 IPv6 firewall IPv6 IPv6 IPv6 IPv6 1496 NAT44 IPv4 IPv4 IPv4 IPv4 1497 NAT46 IPv4 IPv6 IPv4 IPv6 1498 NAT64 IPv6 IPv4 IPv6 IPv4 1499 NPTv6 IPv6 IPv6 IPv6 IPv6 1501 Figure 5: Address Families with MAP and PEER 1503 10.1. For Operating a Server 1505 A host operating a server (e.g., a web server) listens for traffic on 1506 a port, but the server never initiates traffic from that port. For 1507 this to work across a NAT or a firewall, the host needs to (a) create 1508 a mapping from a public IP address, protocol, and port to itself as 1509 described in Section 11, (b) publish that public IP address, 1510 protocol, and port via some sort of rendezvous server (e.g., DNS, a 1511 SIP message, a proprietary protocol), and (c) ensure that any other 1512 non-PCP-speaking packet filtering middleboxes on the path (e.g., 1513 host-based firewall, network-based firewall, or other NATs) will also 1514 allow the incoming traffic. Publishing the public IP address and 1515 port is out of scope of this specification. To accomplish (a), the 1516 host follows the procedures described in this section. 1518 As normal, the application needs to begin listening on a port. Then, 1519 the application constructs a PCP message with the MAP Opcode, with 1520 the external address set to the appropriate all-zeroes address, 1521 depending on whether it wants a public IPv4 or IPv6 address. 1523 The following pseudo-code shows how PCP can be reliably used to 1524 operate a server: 1526 /* start listening on the local server port */ 1527 int s = socket(...); 1528 bind(s, ...); 1529 listen(s, ...); 1531 getsockname(s, &internal_sockaddr, ...); 1532 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1534 while (1) 1535 { 1536 /* Note: The "time_to_send_pcp_request()" check below includes: 1537 * 1. Sending the first request 1538 * 2. Retransmitting requests due to packet loss 1539 * 3. Resending a request due to impending lease expiration 1540 * 4. Resending a request due to server state loss 1541 * The PCP packet sent is identical in all four cases; from 1542 * the PCP server's point of view they are the same operation. 1543 * The Suggested External Address and Port may be updated 1544 * repeatedly during the lifetime of the mapping. 1545 * Other fields in the packet generally remain unchanged. 1546 */ 1547 if (time_to_send_pcp_request()) 1548 pcp_send_map_request(internal_sockaddr.sin_port, 1549 internal_sockaddr.sin_addr, 1550 &external_sockaddr, /* will be zero the first time */ 1551 requested_lifetime, &assigned_lifetime); 1553 if (pcp_response_received()) 1554 update_rendezvous_server("Client Ident", external_sockaddr); 1556 if (received_incoming_connection_or_packet()) 1557 process_it(s); 1559 if (other_work_to_do()) 1560 do_it(); 1562 /* ... */ 1564 block_until_we_need_to_do_something_else(); 1565 } 1567 Figure 6: Pseudo-code for using PCP to operate a server 1569 10.2. For Operating a Symmetric Client/Server 1571 A host operating a client and server on the same port (e.g., 1572 Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) 1573 [RFC3581]) first establishes a local listener, (usually) sends the 1574 local and public IP addresses, protocol, and ports to a rendezvous 1575 service (which is out of scope of this document), and initiates an 1576 outbound connection from that same source address and same port. To 1577 accomplish this, the application uses the procedure described in this 1578 section. 1580 An application that is using the same port for outgoing connections 1581 as well as incoming connections MUST first signal its operation of a 1582 server using the PCP MAP Opcode, as described in Section 11, and 1583 receive a positive PCP response before it sends any packets from that 1584 port. 1586 Discussion: In general, a PCP client doesn't know in advance if it 1587 is behind a NAT or firewall. On detecting the host has connected 1588 to a new network, the PCP client can attempt to request a mapping 1589 using PCP, and if that succeeds then the client knows it has 1590 successfully created a mapping. If after multiple retries it has 1591 received no PCP response, then either the client is *not* behind a 1592 NAT or firewall and has unfettered connectivity, or the client 1593 *is* behind a NAT or firewall which doesn't support PCP (and the 1594 client may still have working connectivity by virtue of static 1595 mappings previously created manually by the user). Retransmitting 1596 PCP requests multiple times before giving up and assuming 1597 unfettered connectivity adds delay in that case. Initiating 1598 outbound TCP connections immediately without waiting for PCP 1599 avoids this delay, and will work if the NAT has endpoint- 1600 independent mapping EIM behavior, but may fail if the NAT has 1601 endpoint-dependent mapping EDM behavior. Waiting enough time to 1602 allow an explicit PCP MAP Mapping to be created (if possible) 1603 first ensures that the same External Port will then be used for 1604 all subsequent implicit dynamic mappings (e.g., TCP SYNs) sent 1605 from the specified Internal Address, Protocol, and Port. PCP 1606 supports both EIM and EDM NATs, so clients need to assume they may 1607 be dealing with an EDM NAT. In this case, the client will 1608 experience more reliable connectivity if it attempts explicit PCP 1609 MAP requests first, before initiating any outbound TCP connections 1610 from that Internal Address and Port. See also Section 16.1. 1612 The following pseudo-code shows how PCP can be used to operate a 1613 symmetric client and server: 1615 /* start listening on the local server port */ 1616 int s = socket(...); 1617 bind(s, ...); 1618 listen(s, ...); 1620 getsockname(s, &internal_sockaddr, ...); 1621 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1623 while (1) 1624 { 1625 /* Note: The "time_to_send_pcp_request()" check below includes: 1626 * 1. Sending the first request 1627 * 2. Retransmitting requests due to packet loss 1628 * 3. Resending a request due to impending lease expiration 1629 * 4. Resending a request due to server state loss 1630 */ 1631 if (time_to_send_pcp_request()) 1632 pcp_send_map_request(internal_sockaddr.sin_port, 1633 internal_sockaddr.sin_addr, 1634 &external_sockaddr, /* will be zero the first time */ 1635 requested_lifetime, &assigned_lifetime); 1637 if (pcp_response_received()) 1638 update_rendezvous_server("Client Ident", external_sockaddr); 1640 if (received_incoming_connection_or_packet()) 1641 process_it(s); 1643 if (need_to_make_outgoing_connection()) 1644 make_outgoing_connection(s, ...); 1646 if (data_to_send()) 1647 send_it(s); 1649 if (other_work_to_do()) 1650 do_it(); 1652 /* ... */ 1654 block_until_we_need_to_do_something_else(); 1655 } 1657 Figure 7: Pseudo-code for using PCP to operate a symmetric client/ 1658 server 1660 10.3. For Reducing NAT or Firewall Keepalive Messages 1662 A host operating a client (e.g., XMPP client, SIP client) sends from 1663 a port, and may receive responses, but never accepts incoming 1664 connections from other Remote Peers on this port. It wants to ensure 1665 the flow to its Remote Peer is not terminated (due to inactivity) by 1666 an on-path NAT or firewall. To accomplish this, the application uses 1667 the procedure described in this section. 1669 Middleboxes such as NATs or firewalls need to see occasional traffic 1670 or will terminate their session state, causing application failures. 1671 To avoid this, many applications routinely generate keepalive traffic 1672 for the primary (or sole) purpose of maintaining state with such 1673 middleboxes. Applications can reduce such application keepalive 1674 traffic by using PCP. 1676 Note: For reasons beyond NAT, an application may find it useful to 1677 perform application-level keepalives, such as to detect a broken 1678 path between the client and server, keep state alive on the Remote 1679 Peer, or detect a powered-down client. These keepalives are not 1680 related to maintaining middlebox state, and PCP cannot do anything 1681 useful to reduce those keepalives. 1683 To use PCP for this function, the application first connects to its 1684 server, as normal. Afterwards, it issues a PCP request with the PEER 1685 Opcode as described in Section 12. 1687 The following pseudo-code shows how PCP can be reliably used with a 1688 dynamic socket, for the purposes of reducing application keepalive 1689 messages: 1691 int s = socket(...); 1692 connect(s, &remote_peer, ...); 1694 getsockname(s, &internal_sockaddr, ...); 1695 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1697 while (1) 1698 { 1699 /* Note: The "time_to_send_pcp_request()" check below includes: 1700 * 1. Sending the first request 1701 * 2. Retransmitting requests due to packet loss 1702 * 3. Resending a request due to impending lease expiration 1703 * 4. Resending a request due to server state loss 1704 */ 1705 if (time_to_send_pcp_request()) 1706 pcp_send_peer_request(internal_sockaddr.sin_port, 1707 internal_sockaddr.sin_addr, 1708 &external_sockaddr, /* will be zero the first time */ 1709 remote_peer, requested_lifetime, &assigned_lifetime); 1711 if (data_to_send()) 1712 send_it(s); 1714 if (other_work_to_do()) 1715 do_it(); 1717 /* ... */ 1719 block_until_we_need_to_do_something_else(); 1720 } 1722 Figure 8: Pseudo-code using PCP with a dynamic socket 1724 10.4. For Restoring Lost Implicit TCP Dynamic Mapping State 1726 After a NAT loses state (e.g., because of a crash or power failure), 1727 it is useful for clients to re-establish TCP mappings on the NAT. 1728 This allows servers on the Internet to see traffic from the same IP 1729 address and port, so that sessions can be resumed exactly where they 1730 were left off. This can be useful for long-lived connections (e.g., 1731 instant messaging) or for connections transferring a lot of data 1732 (e.g., FTP). This can be accomplished by first establishing a TCP 1733 connection normally and then sending a PEER request/response and 1734 remembering the External Address and External Port. Later, when the 1735 NAT has lost state, the client can send a PEER request with the 1736 Suggested External Port and Suggested External Address remembered 1737 from the previous session, which will create a mapping in the NAT 1738 that functions exactly as an implicit dynamic mapping. The client 1739 then resumes sending TCP data to the server. 1741 Note: This procedure works well for TCP, provided the NAT creates 1742 a new implicit dynamic outbound mapping only for TCP segments with 1743 the SYN bit set (i.e., the newly-booted NAT drops the re- 1744 transmitted data segments from the client because the NAT does not 1745 have an active mapping for those segments), and if the server is 1746 not sending data that elicits a RST from the NAT. This is not the 1747 case for UDP, because a new UDP mapping will be created (probably 1748 on a different port) as soon as UDP traffic is seen by the NAT. 1750 11. MAP Opcode 1752 This section defines an Opcode which controls forwarding from a NAT 1753 (or firewall) to an Internal Host. 1755 MAP: Create an explicit dynamic mapping between an Internal 1756 Address + Port and an External Address + Port. 1758 PCP Servers SHOULD provide a configuration option to allow 1759 administrators to disable MAP support if they wish. 1761 Mappings created by PCP MAP requests are, by definition, Endpoint 1762 Independent Mappings (EIM) with Endpoint Independent Filtering (EIF) 1763 (unless the FILTER Option is used), even on a NAT that usually 1764 creates Endpoint Dependent Mappings (EDM) or Endpoint Dependent 1765 Filtering (EDF) for outgoing connections, since the purpose of an 1766 (unfiltered) MAP mapping is to receive inbound traffic from any 1767 remote endpoint, not from only one specific remote endpoint. 1769 Note also that all NAT mappings (created by PCP or otherwise) are by 1770 necessity bidirectional and symmetric. For any packet going in one 1771 direction (in or out) that is translated by the NAT, a reply going in 1772 the opposite direction needs to have the corresponding opposite 1773 translation done so that the reply arrives at the right endpoint. 1774 This means that if a client creates a MAP mapping, and then later 1775 sends an outgoing packet using the mapping's Internal Address, 1776 Protocol and Port, the NAT should translate that packet's Internal 1777 Address and Port to the mapping's External Address and Port, so that 1778 replies addressed to the External Address and Port are correctly 1779 translated back to the mapping's Internal Address and Port. 1781 On Operating Systems that allow multiple listening servers to bind to 1782 the same internal address, protocol and port, servers MUST ensure 1783 that they have exclusive use of that internal address, protocol and 1784 port (e.g., by binding the port using INADDR_ANY, or using 1785 SO_EXCLUSIVEADDRUSE or similar) before sending their PCP MAP request, 1786 to ensure that no other PCP clients on the same machine are also 1787 listening on the same internal protocol and internal port. 1789 As a side-effect of creating a mapping, ICMP messages associated with 1790 the mapping MUST be forwarded (and also translated, if appropriate) 1791 for the duration of the mapping's lifetime. This is done to ensure 1792 that ICMP messages can still be used by hosts, without application 1793 programmers or PCP client implementations needing to use PCP 1794 separately to create ICMP mappings for those flows. 1796 The operation of the MAP Opcode is described in this section. 1798 11.1. MAP Operation Packet Formats 1800 The MAP Opcode has a similar packet layout for both requests and 1801 responses. If the Assigned External IP address and Port in the PCP 1802 response always match the Internal IP Address and Port from the PCP 1803 request, then the functionality is purely a firewall; otherwise it 1804 pertains to a network address translator which might also perform 1805 firewall-like functions. 1807 The following diagram shows the format of the Opcode-specific 1808 information in a request for the MAP Opcode. 1810 0 1 2 3 1811 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 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | | 1814 | Mapping Nonce (96 bits) | 1815 | | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Protocol | Reserved (24 bits) | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Internal Port | Suggested External Port | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | | 1822 | Suggested External IP Address (128 bits) | 1823 | | 1824 | | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 Figure 9: MAP Opcode Request 1829 These fields are described below: 1831 Requested lifetime (in common header): Requested lifetime of this 1832 mapping, in seconds. The value 0 indicates "delete". 1834 Mapping Nonce: Random value chosen by the PCP client. See 1835 Section 11.2. Zero is a legal value (but unlikely, occurring in 1836 roughly one in 2^96 requests). 1838 Protocol: Upper-layer protocol associated with this Opcode. Values 1839 are taken from the IANA protocol registry [proto_numbers]. For 1840 example, this field contains 6 (TCP) if the Opcode is intended to 1841 create a TCP mapping. The value 0 has a special meaning for 'all 1842 protocols'. 1844 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1845 when received. 1847 Internal Port: Internal port for the mapping. The value 0 indicates 1848 'all ports', and is legal when the lifetime is zero (a delete 1849 request), if the Protocol does not use 16-bit port numbers, or the 1850 client is requesting 'all ports'. If Protocol is zero (meaning 1851 'all protocols'), then Internal Port MUST be zero on transmission 1852 and MUST be ignored on reception. 1854 Suggested External Port: Suggested external port for the mapping. 1855 This is useful for refreshing a mapping, especially after the PCP 1856 server loses state. If the PCP client does not know the external 1857 port, or does not have a preference, it MUST use 0. 1859 Suggested External IP Address: Suggested external IPv4 or IPv6 1860 address. This is useful for refreshing a mapping, especially 1861 after the PCP server loses state. If the PCP client does not know 1862 the external address, or does not have a preference, it MUST use 1863 the address-family-specific all-zeroes address (see Section 5). 1865 The internal address for the request is the source IP address of the 1866 PCP request message itself, unless the THIRD_PARTY Option is used. 1868 The following diagram shows the format of Opcode-specific information 1869 in a response packet for the MAP Opcode: 1871 0 1 2 3 1872 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 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | | 1875 | Mapping Nonce (96 bits) | 1876 | | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Protocol | Reserved (24 bits) | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Internal Port | Assigned External Port | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | | 1883 | Assigned External IP Address (128 bits) | 1884 | | 1885 | | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 Figure 10: MAP Opcode Response 1890 These fields are described below: 1892 Lifetime (in common header): On an error response, this indicates 1893 how long clients should assume they'll get the same error response 1894 from the PCP server if they repeat the same request. On a success 1895 response, this indicates the lifetime for this mapping, in 1896 seconds. 1898 Mapping Nonce: Copied from the request. 1900 Protocol: Copied from the request. 1902 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1903 when received. 1905 Internal Port: Copied from the request. 1907 Assigned External Port: On a success response, this is the assigned 1908 external port for the mapping. On an error response, the 1909 Suggested External Port is copied from the request. 1911 Assigned External IP Address: On a success response, this is the 1912 assigned external IPv4 or IPv6 address for the mapping. An IPv4 1913 address is encoded using IPv4-mapped IPv6 address. On an error 1914 response, the Suggested External IP Address is copied from the 1915 request. 1917 11.2. Generating a MAP Request 1919 This section describes the operation of a PCP client when sending 1920 requests with the MAP Opcode. 1922 The request MAY contain values in the Suggested External Port and 1923 Suggested External IP Address fields. This allows the PCP client to 1924 attempt to rebuild lost state on the PCP server, which improves the 1925 chances of existing connections surviving, and helps the PCP client 1926 avoid having to change information maintained at its rendezvous 1927 server. Of course, due to other activity on the network (e.g., by 1928 other users or network renumbering), the PCP server may not be able 1929 to grant the suggested External IP Address, Protocol, and Port, and 1930 in that case it will assign a different External IP Address and Port. 1932 A PCP client MUST be written assuming that it may *never* be assigned 1933 the external port it suggests. In the case of recreating state after 1934 a NAT gateway crash, the Suggested External Port, being one that was 1935 previously allocated to this client, is likely to be available for 1936 this client to continue using. In all other cases, the client MUST 1937 assume that it is unlikely that its Suggested External Port will be 1938 granted. For example, when many subscribers are sharing a Carrier- 1939 Grade NAT, popular ports such as 80, 443 and 8080 are likely to be in 1940 high demand. At most one client can have each of those popular ports 1941 for each External IP Address, and all the other clients will be 1942 assigned other, dynamically allocated, External Ports. Indeed, some 1943 ISPs may, by policy, choose not to grant those External Ports to 1944 *anyone*, so that none of their clients are *ever* assigned External 1945 Ports 80, 443 or 8080. 1947 If the Protocol does not use 16-bit port numbers (e.g., RSVP, IP 1948 protocol number 46), the port number MUST be zero. This will cause 1949 all traffic matching that protocol to be mapped. 1951 If the client wants all protocols mapped it uses Protocol 0 (zero) 1952 and Internal Port 0 (zero). 1954 The Mapping Nonce value is randomly chosen by the PCP client, 1955 following accepted practices for generating unguessable random 1956 numbers [RFC4086], and is used as part of the validation of PCP 1957 responses (see below) by the PCP client, and validation for mapping 1958 refreshes by the PCP server. The client MUST use a different Mapping 1959 Nonce for each PCP server it communicates with, and it is RECOMMENDED 1960 to choose a new random Mapping Nonce whenever the PCP client is 1961 initialized. The client MAY use a different Mapping Nonce for every 1962 mapping. 1964 11.2.1. Renewing a Mapping 1966 An existing mapping can have its lifetime extended by the PCP client. 1967 To do this, the PCP client sends a new MAP request indicating the 1968 internal port. The PCP MAP request SHOULD also include the currently 1969 assigned external IP address and port in the Suggested External IP 1970 address and Suggested External Port fields, so if the PCP server has 1971 lost state it can recreate the lost mapping with the same parameters. 1973 The PCP client SHOULD renew the mapping before its expiry time, 1974 otherwise it will be removed by the PCP server (see Section 15). To 1975 reduce the risk of inadvertent synchronization of renewal requests, a 1976 random jitter component should be included. It is RECOMMENDED that 1977 PCP clients send a single renewal request packet at a time chosen 1978 with uniform random distribution in the range 1/2 to 5/8 of 1979 expiration time. If no SUCCESS response is received, then the next 1980 renewal request should be sent 3/4 to 3/4 + 1/16 to expiration, and 1981 then another 7/8 to 7/8 + 1/32 to expiration, and so on, subject to 1982 the constraint that renewal requests MUST NOT be sent less than four 1983 seconds apart (a PCP client MUST NOT send a flood of ever-closer- 1984 together requests in the last few seconds before a mapping expires). 1986 11.3. Processing a MAP Request 1988 This section describes the operation of a PCP server when processing 1989 a request with the MAP Opcode. Processing SHOULD be performed in the 1990 order of the following paragraphs. 1992 The Protocol, Internal Port, and Mapping Nonce fields from the MAP 1993 request are copied into the MAP response. If present and processed 1994 by the PCP server the THIRD_PARTY Option is also copied into the MAP 1995 response. 1997 If the Requested Lifetime is non-zero then: 1999 o If both the protocol and internal port are non-zero, it indicates 2000 a request to create a mapping or extend the lifetime of an 2001 existing mapping. If the PCP server or PCP-controlled device does 2002 not support the Protocol, the UNSUPP_PROTOCOL error MUST be 2003 returned. 2005 o If the protocol is non-zero and the internal port is zero, it 2006 indicates a request to create or extend a mapping for all incoming 2007 traffic for that entire Protocol. If this request cannot be 2008 fulfilled in its entirety, the UNSUPP_PROTOCOL error MUST be 2009 returned. 2011 o If both the protocol and internal port are zero, it indicates a 2012 request to create or extend a mapping for all incoming traffic for 2013 all protocols (commonly called a "DMZ host"). If this request 2014 cannot be fulfilled in its entirety, the UNSUPP_PROTOCOL error 2015 MUST be returned. 2017 o If the protocol is zero and the internal port is non-zero, then 2018 the request is invalid and the PCP Server MUST return a 2019 MALFORMED_REQUEST error to the client. 2021 If the requested lifetime is zero, it indicates a request to delete 2022 an existing mapping. 2024 Further processing of the lifetime is described in Section 15. 2026 If operating in the Simple Threat Model (Section 18.1), and the 2027 Internal port, Protocol, and Internal Address match an existing 2028 explicit dynamic mapping, but the Mapping Nonce does not match, the 2029 request MUST be rejected with a NOT_AUTHORIZED error with the 2030 Lifetime of the error indicating duration of that existing mapping. 2031 The PCP server only needs to remember one Mapping Nonce value for 2032 each explicit dynamic mapping. 2034 If the Internal port, Protocol, and Internal Address match an 2035 existing static mapping (which will have no nonce) then a PCP reply 2036 is sent giving the External Address and Port of that static mapping, 2037 using the nonce from the PCP request. The server does not record the 2038 nonce. 2040 If an Option with value less than 128 exists (i.e., mandatory to 2041 process) but that Option does not make sense (e.g., the 2042 PREFER_FAILURE Option is included in a request with lifetime=0), the 2043 request is invalid and generates a MALFORMED_OPTION error. 2045 If the PCP-controlled device is stateless (that is, it does not 2046 establish any per-flow state, and simply rewrites the address and/or 2047 port in a purely algorithmic fashion), the PCP server simply returns 2048 an answer indicating the external IP address and port yielded by this 2049 stateless algorithmic translation. This allows the PCP client to 2050 learn its external IP address and port as seen by remote peers. 2051 Examples of stateless translators include stateless NAT64, 1:1 NAT44, 2052 and NPTv6 [RFC6296], all of which modify addresses but not port 2053 numbers. 2055 It is possible that a mapping might already exist for a requested 2056 Internal Address, Protocol, and Port. If so, the PCP server takes 2057 the following actions: 2059 1. If the MAP request contains the PREFER_FAILURE Option, but the 2060 Suggested External Address and Port do not match the External 2061 Address and Port of the existing mapping, the PCP server MUST 2062 return CANNOT_PROVIDE_EXTERNAL. 2064 2. If the existing mapping is static (created outside of PCP), the 2065 PCP server MUST return the External Address and Port of the 2066 existing mapping in its response and SHOULD indicate a Lifetime 2067 of 2^32-1 seconds, regardless of the Suggested External Address 2068 and Port in the request. 2070 3. If the existing mapping is explicit dynamic inbound (created by a 2071 previous MAP request), the PCP server MUST return the existing 2072 External Address and Port in its response, regardless of the 2073 Suggested External Address and Port in the request. 2074 Additionally, the PCP server MUST update the lifetime of the 2075 existing mapping, in accordance with section 10.5. 2077 4. If the existing mapping is dynamic outbound (created by outgoing 2078 traffic or a previous PEER request), the PCP server SHOULD create 2079 a new explicit inbound mapping, replicating the ports and 2080 addresses from the outbound mapping (but the outbound mapping 2081 continues to exist, and remains in effect if the explicit inbound 2082 mapping is later deleted). 2084 If no mapping exists for the Internal Address, Protocol, and Port, 2085 and the PCP server is able to create a mapping using the Suggested 2086 External Address and Port, it SHOULD do so. This is beneficial for 2087 re-establishing state lost in the PCP server (e.g., due to a reboot). 2088 There are, however, cases where the PCP server is not able to create 2089 a new mapping using the Suggested External Address and Port: 2091 o The Suggested External Address, Protocol, and Port is already 2092 assigned to another existing explicit or implicit mapping (i.e., 2093 is already forwarding traffic to some other internal address and 2094 port). 2096 o The Suggested External Address, Protocol, and Port is already used 2097 by the NAT gateway for one of its own services. For example, TCP 2098 port 80 for the NAT gateway's own configuration web pages, or UDP 2099 ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT 2100 create client mappings for External UDP ports 5350 or 5351. 2102 o The Suggested External Address, Protocol, and Port is otherwise 2103 prohibited by the PCP server's policy. 2105 o The Suggested External IP Address, Protocol, or Suggested Port are 2106 invalid or invalid combinations (e.g., External Address 127.0.0.1, 2107 ::1, a multicast address, or the Suggested Port is not valid for 2108 the Protocol). 2110 o The Suggested External Address does not belong to the NAT gateway. 2112 o The Suggested External Address is not configured to be used as an 2113 external address of the firewall or NAT gateway. 2115 If the PCP server cannot assign the Suggested External Address, 2116 Protocol, and Port, then: 2118 o If the request contained the PREFER_FAILURE Option, then the PCP 2119 server MUST return CANNOT_PROVIDE_EXTERNAL. 2121 o If the request did not contain the PREFER_FAILURE Option, and the 2122 PCP server can assign some other External Address and Port for 2123 that protocol, then the PCP server MUST do so and return the newly 2124 assigned External Address and Port in the response. In no case is 2125 the client penalized for a 'poor' choice of Suggested External 2126 Address and Port. The Suggested External Address and Port may be 2127 used by the server to guide its choice of what External Address 2128 and Port to assign, but in no case do they cause the server to 2129 fail to allocate an External Address and Port where otherwise it 2130 would have succeeded. The presence of a non-zero Suggested 2131 External Address or Port is merely a hint; it never does any harm. 2133 By default, a PCP-controlled device MUST NOT create mappings for a 2134 protocol not indicated in the request. For example, if the request 2135 was for a TCP mapping, a UDP mapping MUST NOT be created. 2137 Mappings typically consume state on the PCP-controlled device, and it 2138 is RECOMMENDED that a per-host and/or per-subscriber limit be 2139 enforced by the PCP server to prevent exhausting the mapping state. 2140 If this limit is exceeded, the result code USER_EX_QUOTA is returned. 2142 If all of the preceding operations were successful (did not generate 2143 an error response), then the requested mapping is created or 2144 refreshed as described in the request and a SUCCESS response is 2145 built. 2147 11.4. Processing a MAP Response 2149 This section describes the operation of the PCP client when it 2150 receives a PCP response for the MAP Opcode. 2152 After performing common PCP response processing, the response is 2153 further matched with a previously-sent MAP request by comparing the 2154 Internal IP Address (the destination IP address of the PCP response, 2155 or other IP address specified via the THIRD_PARTY option), the 2156 Protocol, the Internal Port, and the Mapping Nonce. Other fields are 2157 not compared, because the PCP server sets those fields. The PCP 2158 server will send a Mapping Update (Section 14.2) if the mapping 2159 changes (e.g., due to IP renumbering). 2161 If the result code is NO_RESOURCES and the request was for the 2162 creation or renewal of a mapping, then the PCP client SHOULD NOT send 2163 further requests for any new mappings to that PCP server for the 2164 (limited) value of the Lifetime. If the result code is NO_RESOURCES 2165 and the request was for the deletion of a mapping, then the PCP 2166 client SHOULD NOT send further requests of *any kind* to that PCP 2167 server for the (limited) value of the Lifetime. 2169 On a success response, the PCP client can use the External IP Address 2170 and Port as needed. Typically the PCP client will communicate the 2171 External IP Address and Port to another host on the Internet using an 2172 application-specific rendezvous mechanism such as DNS SRV records. 2174 As long as renewal is desired, the PCP client MUST also set a timer 2175 or otherwise schedule an event to renew the mapping before its 2176 lifetime expires. Renewing a mapping is performed by sending another 2177 MAP request, exactly as described in Section 11.2, except that the 2178 Suggested External Address and Port SHOULD be set to the values 2179 received in the response. From the PCP server's point of view a MAP 2180 request to renew a mapping is identical to a MAP request to create a 2181 new mapping, and is handled identically. Indeed, in the event of PCP 2182 server state loss, a renewal request from a PCP client will appear to 2183 the server to be a request to create a new mapping, with a particular 2184 Suggested External Address and Port, which happens to be what the PCP 2185 server previously assigned. See also Section 16.3.1. 2187 On an error response, the client SHOULD NOT repeat the same request 2188 to the same PCP server within the lifetime returned in the response. 2190 11.5. Address Change Events 2192 A customer premises router might obtain a new External IP address, 2193 for a variety of reasons including a reboot, power outage, DHCP lease 2194 expiry, or other action by the ISP. If this occurs, traffic 2195 forwarded to the host's previous address might be delivered to 2196 another host which now has that address. This affects all mapping 2197 types, whether implicit or explicit. This same problem already 2198 occurs today when a host's IP address is re-assigned, without PCP and 2199 without an ISP-operated CGN. The solution is the same as today: the 2200 problems associated with host renumbering are caused by host 2201 renumbering, and are eliminated if host renumbering is avoided. PCP 2202 defined in this document does not provide machinery to reduce the 2203 host renumbering problem. 2205 When an Internal Host changes its Internal IP address (e.g., by 2206 having a different address assigned by the DHCP server) the NAT (or 2207 firewall) will continue to send traffic to the old IP address. 2208 Typically, the Internal Host will no longer receive traffic sent to 2209 that old IP address. Assuming the Internal Host wants to continue 2210 receiving traffic, it needs to install new mappings for its new IP 2211 address. The suggested external port field will not be fulfilled by 2212 the PCP server, in all likelihood, because it is still being 2213 forwarded to the old IP address. Thus, a mapping is likely to be 2214 assigned a new External Port number and/or External IP Address. Note 2215 that such host renumbering is not expected to happen routinely on a 2216 regular basis for most hosts, since most hosts renew their DHCP 2217 leases before they expire (or re-request the same address after 2218 reboot) and most DHCP servers honor such requests and grant the host 2219 the same address it was previously using before the reboot. 2221 A host might gain or lose interfaces while existing mappings are 2222 active (e.g., Ethernet cable plugged in or removed, joining/leaving a 2223 Wi-Fi network). Because of this, if the PCP client is sending a PCP 2224 request to maintain state in the PCP server, it SHOULD ensure those 2225 PCP requests continue to use the same interface (e.g., when 2226 refreshing mappings). If the PCP client is sending a PCP request to 2227 create new state in the PCP server, it MAY use a different source 2228 interface or different source address. 2230 11.6. Learning the External IP Address Alone 2232 NAT-PMP [I-D.cheshire-nat-pmp] includes a mechanism to allow clients 2233 to learn the External IP Address alone, without also requesting a 2234 port mapping. NAT-PMP was designed for residential NAT gateways, 2235 where such an operation makes sense because the residential NAT 2236 gateway has only one External IP Address. PCP has broader scope, and 2237 also supports Carrier-Grade NATs (CGN) which may have a pool of 2238 External IP Addresses, not just one. A client may not be assigned 2239 any particular External IP Address from that pool until it has at 2240 least one implicit, explicit or static port mapping, and even then 2241 only for as long as that mapping remains valid. Client software that 2242 just wishes to display the user's External IP Address for cosmetic 2243 purposes can achieve that by requesting a short-lived mapping (e.g., 2244 to the Discard service (TCP/9 or UDP/9) or some other port) and then 2245 displaying the resulting External IP Address. However, once that 2246 mapping expires a subsequent implicit or explicit dynamic mapping 2247 might be mapped to a different external IP address. 2249 12. PEER Opcode 2251 This section defines an Opcode for controlling dynamic mappings. 2253 PEER: Create a new dynamic outbound mapping to a remote peer's IP 2254 address and port, or extend the lifetime of an existing 2255 outbound mapping. 2257 The use of this Opcodes is described in this section. 2259 PCP Servers SHOULD provide a configuration option to allow 2260 administrators to disable PEER support if they wish. 2262 Because a mapping created or managed by PEER behaves almost exactly 2263 like an implicit dynamic mapping created as a side-effect of a packet 2264 (e.g., TCP SYN) sent by the host, mappings created or managed using 2265 PCP PEER requests may be Endpoint Independent Mappings (EIM) or 2266 Endpoint Dependent Mappings (EDM), with Endpoint Independent 2267 Filtering (EIF) or Endpoint Dependent Filtering (EDF), consistent 2268 with the existing behavior of the NAT gateway or firewall in question 2269 for implicit outbound mappings it creates automatically as a result 2270 of observing outgoing traffic from Internal Hosts. 2272 12.1. PEER Operation Packet Formats 2274 The PEER Opcode allows a PCP client to create a new explicit dynamic 2275 outbound mapping (which functions similarly to an outbound mapping 2276 created implicitly when a host sends an outbound TCP SYN) or to 2277 extend the lifetime of an existing outbound mapping. 2279 The following diagram shows the Opcode layout for the PEER Opcode. 2280 This packet format is aligned with the response packet format: 2282 0 1 2 3 2283 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 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | | 2286 | Mapping Nonce (96 bits) | 2287 | | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | Protocol | Reserved (24 bits) | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | Internal Port | Suggested External Port | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | | 2294 | Suggested External IP Address (128 bits) | 2295 | | 2296 | | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | Remote Peer Port | Reserved (16 bits) | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | | 2301 | Remote Peer IP Address (128 bits) | 2302 | | 2303 | | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 Figure 11: PEER Opcode Request 2308 These fields are described below: 2310 Requested Lifetime (in common header): Requested lifetime of this 2311 mapping, in seconds. Note that it is not possible to reduce the 2312 lifetime of a mapping (or delete it, with requested lifetime=0) 2313 using PEER. 2315 Mapping Nonce: Random value chosen by the PCP client. See 2316 Section 12.2. Zero is a legal value (but unlikely, occurring in 2317 roughly one in 2^96 requests). 2319 Protocol: Upper-layer protocol associated with this Opcode. Values 2320 are taken from the IANA protocol registry [proto_numbers]. For 2321 example, this field contains 6 (TCP) if the Opcode is describing a 2322 TCP mapping. Protocol MUST NOT be zero. 2324 Reserved: 24 reserved bits, MUST be set to 0 on transmission and 2325 MUST be ignored on reception. 2327 Internal Port: Internal port for the mapping. Internal Port MUST 2328 NOT be zero. 2330 Suggested External Port: Suggested external port for the mapping. 2331 If the PCP client does not know the external port, or does not 2332 have a preference, it MUST use 0. 2334 Suggested External IP Address: Suggested External IP Address for the 2335 mapping. If the PCP client does not know the external address, or 2336 does not have a preference, it MUST use the address-family- 2337 specific all-zeroes address (see Section 5). 2339 Remote Peer Port: Remote peer's port for the mapping. Remote Peer 2340 Port MUST NOT be zero. 2342 Reserved: 16 reserved bits, MUST be set to 0 on transmission and 2343 MUST be ignored on reception. 2345 Remote Peer IP Address: Remote peer's IP address. This is from the 2346 perspective of the PCP client, so that the PCP client does not 2347 need to concern itself with NAT64 or NAT46 (which both cause the 2348 client's idea of the remote peer's IP address to differ from the 2349 remote peer's actual IP address). This field allows the PCP 2350 client and PCP server to disambiguate multiple connections from 2351 the same port on the Internal Host to different servers. An IPv6 2352 address is represented directly, and an IPv4 address is 2353 represented using the IPv4-mapped address syntax (Section 5). 2355 When attempting to re-create a lost mapping, the Suggested External 2356 IP Address and Port are set to the External IP Address and Port 2357 fields received in a previous PEER response from the PCP server. On 2358 an initial PEER request, the External IP Address and Port are set to 2359 zero. 2361 Note that semantics similar to the PREFER_FAILURE option are 2362 automatically implied by PEER requests. If the Suggested External IP 2363 Address or Suggested External Port fields are non-zero, and the PCP 2364 server is unable to honor the Suggested External IP Address, 2365 Protocol, or Port, then the PCP server MUST return a 2366 CANNOT_PROVIDE_EXTERNAL error response. The PREFER_FAILURE Option is 2367 neither required nor allowed in PEER requests, and if PCP server 2368 receives a PEER request containing the PREFER_FAILURE Option it MUST 2369 return a MALFORMED_REQUEST error response. 2371 The following diagram shows the Opcode response for the PEER Opcode: 2373 0 1 2 3 2374 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 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 | | 2377 | Mapping Nonce (96 bits) | 2378 | | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | Protocol | Reserved (24 bits) | 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | Internal Port | Assigned External Port | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | | 2385 | Assigned External IP Address (128 bits) | 2386 | | 2387 | | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Remote Peer Port | Reserved (16 bits) | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | | 2392 | Remote Peer IP Address (128 bits) | 2393 | | 2394 | | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 Figure 12: PEER Opcode Response 2399 Lifetime (in common header): On a success response, this indicates 2400 the lifetime for this mapping, in seconds. On an error response, 2401 this indicates how long clients should assume they'll get the same 2402 error response from the PCP server if they repeat the same 2403 request. 2405 Mapping Nonce: Copied from the request. 2407 Protocol: Copied from the request. 2409 Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST 2410 be ignored on reception. 2412 Internal Port: Copied from request. 2414 Assigned External Port: On a success response, this is the assigned 2415 external port for the mapping. On an error response, the 2416 Suggested External Port is copied from the request. 2418 Assigned External IP Address: On a success response, this is the 2419 assigned external IPv4 or IPv6 address for the mapping. On an 2420 error response, the Suggested External IP Address is copied from 2421 the request. 2423 Remote Peer port: Copied from request. 2425 Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST 2426 be ignored on reception. 2428 Remote Peer IP Address: Copied from the request. 2430 12.2. Generating a PEER Request 2432 This section describes the operation of a client when generating a 2433 message with the PEER Opcode. 2435 The PEER Opcode MAY be sent before or after establishing bi- 2436 directional communication with the remote peer. 2438 If sent before, this is considered a PEER-created mapping which 2439 creates a new dynamic outbound mapping in the PCP-controlled device. 2440 This is useful for restoring a mapping after a NAT has lost its 2441 mapping state (e.g., due to a crash). 2443 If sent after, this allows the PCP client to learn the IP address, 2444 port, and lifetime of the assigned External Address and Port for the 2445 existing implicit dynamic outbound mapping, and potentially to extend 2446 this lifetime (for the purpose described in Section 10.3). 2448 The Mapping Nonce value is randomly chosen by the PCP client, 2449 following accepted practices for generating unguessable random 2450 numbers [RFC4086], and is used as part of the validation of PCP 2451 responses (see below) by the PCP client, and validation for mapping 2452 refreshes by the PCP server. The client MUST use a different Mapping 2453 Nonce for each PCP server it communicates with, and it is RECOMMENDED 2454 to choose a new random Mapping Nonce whenever the PCP client is 2455 initialized. The client MAY use a different Mapping Nonce for every 2456 mapping. 2458 The PEER Opcode contains a Remote Peer Address field, which is always 2459 from the perspective of the PCP client. Note that when the PCP- 2460 controlled device is performing address family translation (NAT46 or 2461 NAT64), the remote peer address from the perspective of the PCP 2462 client is different from the remote peer address on the other side of 2463 the address family translation device. 2465 12.3. Processing a PEER Request 2467 This section describes the operation of a server when receiving a 2468 request with the PEER Opcode. Processing SHOULD be performed in the 2469 order of the following paragraphs. 2471 The following fields from a PEER request are copied into the 2472 response: Protocol, Internal Port, Remote Peer IP Address, Remote 2473 Peer Port, and Mapping Nonce. 2475 When an implicit dynamic mapping is created, some NATs and firewalls 2476 validate destination addresses and will not create an implicit 2477 dynamic mapping if the destination address is invalid (e.g., 2478 127.0.0.1). If a PCP-controlled device does such validation for 2479 implicit dynamic mappings, it SHOULD also do a similar validation of 2480 the Remote Peer IP Address, Protocol, and Port for PEER-created 2481 explicit dynamic mappings. If the validation determines the Remote 2482 Peer IP Address of a PEER request is invalid, then no mapping is 2483 created, and a MALFORMED_REQUEST error result is returned. 2485 On receiving the PEER Opcode, the PCP server examines the mapping 2486 table for a matching five-tuple { Protocol, Internal Address, 2487 Internal Port, Remote Peer Address, Remote Peer Port }. 2489 If no matching mapping is found, and the Suggested External Address 2490 and Port are either zero or can be honored for the specified 2491 Protocol, a new mapping is created. By having PEER create such a 2492 mapping, we avoid a race condition between the PEER request or the 2493 initial outgoing packet arriving at the NAT or firewall device first, 2494 and allow PEER to be used to recreate an outbound dynamic mapping 2495 (see last paragraph of Section 16.3.1). Thereafter, this PEER- 2496 created mapping is treated as if it was an implicit dynamic outbound 2497 mapping (e.g., as if the PCP client sent a TCP SYN) and a Lifetime 2498 appropriate to such a mapping is returned (note: on many NATs and 2499 firewalls, such mapping lifetimes are very short until the bi- 2500 directional traffic is seen by the NAT or firewall). 2502 If no matching mapping is found, and the Suggested External Address 2503 and Port cannot be honored, then no new state is created, and the 2504 error CANNOT_PROVIDE_EXTERNAL is returned. 2506 If a matching mapping is found, but no pervious PEER Opcode was 2507 successfully processed for this mapping, then the Suggested External 2508 Address and Port values in the request are ignored, Lifetime of that 2509 mapping is adjusted as described below, and information about the 2510 existing mapping is returned. This allows a client to explicitly 2511 extend the lifetime of an existing mapping and/or to learn an 2512 existing mapping's External Address, Port and lifetime. The Mapping 2513 Nonce is remembered for this mapping. 2515 If operating in the Simple Threat Model (Section 18.1), and the 2516 Internal port, Protocol, and Internal Address match a mapping that 2517 already exists, but the Mapping Nonce does not match (that is, a 2518 previous PEER request was processed), the request MUST be rejected 2519 with a NOT_AUTHORIZED error with the Lifetime of the error indicating 2520 duration of that existing mapping. The PCP server only needs to 2521 remember one Mapping Nonce value for each mapping. 2523 Processing the lifetime value of the PEER Opcode is described in 2524 Section 15. Sending a PEER request with a very short Requested 2525 Lifetime can be used to query the lifetime of an existing mapping. 2527 If all of the preceding operations were successful (did not generate 2528 an error response), then a SUCCESS response is generated, with the 2529 Lifetime field containing the lifetime of the mapping. 2531 If a PEER-created or PEER-managed mapping is not renewed using PEER, 2532 then it reverts to the NAT's usual behavior for implicit mappings, 2533 e.g., continued outbound traffic keeps the mapping alive, as per the 2534 NAT or firewall device's existing policy. A PEER-created or PEER- 2535 managed mapping may be terminated at any time by action of the TCP 2536 client or server (e.g., due to TCP FIN or TCP RST), as per the NAT or 2537 firewall device's existing policy. 2539 12.4. Processing a PEER Response 2541 This section describes the operation of a client when processing a 2542 response with the PEER Opcode. 2544 After performing common PCP response processing, the response is 2545 further matched with an outstanding PEER request by comparing the 2546 Internal IP Address (the destination IP address of the PCP response, 2547 or other IP address specified via the THIRD_PARTY option), the 2548 Protocol, the Internal Port, the Remote Peer Address, the Remote Peer 2549 Port, and the Mapping Nonce. Other fields are not compared, because 2550 the PCP server sets those fields to provide information about the 2551 mapping created by the Opcode. The PCP server will send a Mapping 2552 Update (Section 14.2) if the mapping changes (e.g., due to IP 2553 renumbering). 2555 If the result code is NO_RESOURCES and the request was for the 2556 creation or renewal of a mapping, then the PCP client SHOULD NOT send 2557 further requests for any new mappings to that PCP server for the 2558 (limited) value of the Lifetime. 2560 On a successful response, the application can use the assigned 2561 lifetime value to reduce its frequency of application keepalives for 2562 that particular NAT mapping. Of course, there may be other reasons, 2563 specific to the application, to use more frequent application 2564 keepalives. For example, the PCP assigned lifetime could be one hour 2565 but the application may want to maintain state on its server (e.g., 2566 "busy" / "away") more frequently than once an hour. If the response 2567 indicates an unexpected IP address or port (e.g., due to IP 2568 renumbering), the PCP client will want to re-establish its connection 2569 to its remote server. 2571 If the PCP client wishes to keep this mapping alive beyond the 2572 indicated lifetime, it MAY rely on continued inside-to-outside 2573 traffic to ensure the mapping will continue to exist, or it MAY issue 2574 a new PCP request prior to the expiration. The recommended timings 2575 for renewing PEER mappings are the same as for MAP mappings, as 2576 described in Section 11.2.1. 2578 Note: Implementations need to expect the PEER response may contain 2579 an External IP Address with a different family than the Remote 2580 Peer IP Address, e.g., when NAT64 or NAT46 are being used. 2582 13. Options for MAP and PEER Opcodes 2584 This section describes Options for the MAP and PEER Opcodes. These 2585 Options MUST NOT appear with other Opcodes, unless permitted by those 2586 other Opcodes. 2588 13.1. THIRD_PARTY Option for MAP and PEER Opcodes 2590 This Option is used when a PCP client wants to control a mapping to 2591 an Internal Host other than itself. This is used with both MAP and 2592 PEER Opcodes. 2594 Due to security concerns with the THIRD_PARTY option, this Option 2595 MUST NOT be implemented or used unless the network on which the PCP 2596 messages are to be sent is fully trusted. For example if access 2597 control lists are installed on the PCP client, PCP server, and the 2598 network between them, so those ACLs allow only communications from a 2599 trusted PCP client to the PCP server. 2601 A management device would use this Option to control a PCP server on 2602 behalf of users. For example, a management device located in a 2603 network operations center, which presents a user interface to end 2604 users or to network operations staff, and issues PCP requests with 2605 the THIRD_PARTY option to the appropriate PCP server. 2607 The THIRD_PARTY Option is formatted as follows: 2609 0 1 2 3 2610 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 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | Option Code=1 | Reserved | Option Length=16 | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | | 2615 | Internal IP Address (128 bits) | 2616 | | 2617 | | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 Figure 13: THIRD_PARTY Option 2622 The fields are described below: 2624 Internal IP Address: Internal IP address for this mapping. 2626 Option Name: THIRD_PARTY 2627 Number: 1 2628 Purpose: Indicates the MAP or PEER request is for a host other 2629 than the host sending the PCP Option. 2630 Valid for Opcodes: MAP, PEER 2631 Length: 16 octets 2632 May appear in: request. May appear in response only if it 2633 appeared in the associated request. 2634 Maximum occurrences: 1 2636 A THIRD_PARTY Option MUST NOT contain the same address as the source 2637 address of the packet. This is because many PCP servers may not 2638 implement the THIRD_PARTY Option at all, and with those servers a 2639 client redundantly using the THIRD_PARTY Option to specify its own IP 2640 address would cause such mapping requests to fail where they would 2641 otherwise have succeeded. A PCP server receiving a THIRD_PARTY 2642 Option specifying the same address as the source address of the 2643 packet MUST return a MALFORMED_REQUEST result code. 2645 A PCP server MAY be configured to permit or to prohibit the use of 2646 the THIRD_PARTY Option. If this Option is permitted, properly 2647 authorized clients may perform these operations on behalf of other 2648 hosts. If this Option is prohibited, and a PCP server receives a PCP 2649 MAP request with a THIRD_PARTY Option, it MUST generate a 2650 UNSUPP_OPTION response. 2652 It is RECOMMENDED that customer premises equipment implementing a PCP 2653 Server be configured to prohibit third party mappings by default. 2654 With this default, if a user wants to create a third party mapping, 2655 the user needs to interact out-of-band with their customer premises 2656 router (e.g., using its HTTP administrative interface). 2658 It is RECOMMENDED that service provider NAT and firewall devices 2659 implementing a PCP Server be configured to permit the THIRD_PARTY 2660 Option, when sent by a properly authorized host. If the packet 2661 arrives from an unauthorized host, the PCP server MUST generate an 2662 UNSUPP_OPTION error. 2664 Note that the THIRD_PARTY Option is not needed for today's common 2665 scenario of an ISP offering a single IP address to a customer who is 2666 using NAT to share that address locally, since in this scenario all 2667 the customer's hosts appear, from the point of view of the ISP, to be 2668 a single host. 2670 When a PCP client is using the THIRD_PARTY Option to make and 2671 maintain mappings on behalf of some other device, it may be 2672 beneficial if, where possible, the PCP client verifies that the other 2673 device is actually present and active on the network. Otherwise the 2674 PCP client risks maintaining those mappings forever, long after the 2675 device that required them has gone. This would defeat the purpose of 2676 PCP mappings having a finite lifetime so that they can be 2677 automatically deleted after they are no longer needed. 2679 13.2. PREFER_FAILURE Option for MAP Opcode 2681 This Option is only used with the MAP Opcode. 2683 This Option indicates that if the PCP server is unable to map both 2684 the Suggested External Port and Suggested External Address, the PCP 2685 server should not create a mapping. This differs from the behavior 2686 without this Option, which is to create a mapping. 2688 The PREFER_FAILURE Option is formatted as follows: 2690 0 1 2 3 2691 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 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Option Code=2 | Reserved | Option Length=0 | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 Figure 14: PREFER_FAILURE Option 2698 Option Name: PREFER_FAILURE 2699 Number: 2 2700 Purpose: indicates that the PCP server should not create an 2701 alternative mapping if the suggested external port and address 2702 cannot be mapped. 2703 Valid for Opcodes: MAP 2704 Length: 0 2705 May appear in: request. May appear in response only if it 2706 appeared in the associated request. 2707 Maximum occurrences: 1 2709 The result code CANNOT_PROVIDE_EXTERNAL is returned if the Suggested 2710 External Address, Protocol, and Port cannot be mapped. This can 2711 occur because the External Port is already mapped to another host's 2712 outbound dynamic mapping, an inbound dynamic mapping, a static 2713 mapping, or the same Internal Address, Protocol, and Port already has 2714 an outbound dynamic mapping which is mapped to a different External 2715 Port than suggested. This can also occur because the External 2716 Address is no longer available (e.g., due to renumbering). The 2717 server MAY set the Lifetime in the response to the remaining lifetime 2718 of the conflicting mapping + TIME_WAIT [RFC0793], rounded up to the 2719 next larger integer number of seconds. 2721 PREFER_FAILURE is never necessary for a PCP client to manage mappings 2722 for itself, and its use causes additional work in the PCP client and 2723 in the PCP server. This Option exists for interworking with non-PCP 2724 mapping protocols that have different semantics than PCP (e.g., UPnP 2725 IGDv1 interworking [I-D.ietf-pcp-upnp-igd-interworking], where the 2726 semantics of UPnP IGDv1 only allow the UPnP IGDv1 client to dictate 2727 mapping a specific port), or separate port allocation systems which 2728 allocate ports to a subscriber (e.g., a subscriber-accessed web 2729 portal operated by the same ISP that operates the PCP server). A PCP 2730 server MAY support this Option, if its designers wish to support such 2731 downstream devices or separate port allocation systems. PCP servers 2732 that are not intended to interface with such systems are not required 2733 to support this Option. PCP clients other than UPnP IGDv1 2734 interworking clients or other than a separate port allocation system 2735 SHOULD NOT use this Option because it results in inefficient 2736 operation, and they cannot safely assume that all PCP servers will 2737 implement it. It is anticipated that this Option will be deprecated 2738 in the future as more clients adopt PCP natively and the need for 2739 this Option declines. 2741 If a PCP request contains the PREFER_FAILURE option and has zero in 2742 the Suggested External Port field, or has the all-zeros IPv4 or all- 2743 zeros IPv6 address in the Suggested External Address field, it is 2744 invalid. The PCP server MUST reject such a message with the 2745 MALFORMED_OPTION error code. 2747 PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE 2748 requests, to protect themselves from a rapid flurry of 65535 2749 consecutive PREFER_FAILURE requests from clients probing to discover 2750 which external ports are available. 2752 There can exist a race condition between the MAP Opcode using the 2753 PREFER_FAILURE option and Mapping Update (Section 14.2). For 2754 example, a previous host on the local network could have previously 2755 had the same Internal Address, with a mapping for the same Internal 2756 Port. At about the same moment that the current host sends a MAP 2757 Request using the PREFER_FAILURE option, the PCP server could send a 2758 spontaneous mapping update for the old mapping due to an external 2759 configuration change, which could appear to be a reply to the new 2760 mapping request. Because of this, the PCP client MUST validate that 2761 the External IP Address, Protocol, Port and Nonce in a success 2762 response matches the associated suggested values from the request. 2763 If they don't match, it is because the Mapping Update was sent before 2764 the MAP request was processed. 2766 13.3. FILTER Option for MAP Opcode 2768 This Option is only used with the MAP Opcode. 2770 This Option indicates that filtering incoming packets is desired. 2771 The protocol being filtered is indicated by the Protocol field in the 2772 MAP Request, and the Remote Peer IP Address and Remote Peer Port of 2773 the FILTER Option indicate the permitted remote peer's source IP 2774 address and source port for packets from the Internet; other traffic 2775 from other addresses is blocked. The remote peer prefix length 2776 indicates the length of the remote peer's IP address that is 2777 significant; this allows a single Option to permit an entire subnet. 2778 After processing this MAP request containing the FILTER Option and 2779 generating a successful response, the PCP-controlled device will drop 2780 packets received on its public-facing interface that don't match the 2781 filter fields. After dropping the packet, if its security policy 2782 allows, the PCP-controlled device MAY also generate an ICMP error in 2783 response to the dropped packet. 2785 The use of the FILTER Option can be seen as a performance 2786 optimization. Since all software using PCP to receive incoming 2787 connections also has to deal with the case where it may be directly 2788 connected to the Internet and receive unrestricted incoming TCP 2789 connections and UDP packets, if it wishes to restrict incoming 2790 traffic to a specific source address or group of source addresses 2791 such software already needs to check the source address of incoming 2792 traffic and reject unwanted traffic. However, the FILTER Option is a 2793 particularly useful performance optimization for battery powered 2794 wireless devices, because it can enable them to conserve battery 2795 power by not having to wake up just to reject unwanted traffic. 2797 The FILTER Option is formatted as follows: 2799 0 1 2 3 2800 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 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 | Option Code=3 | Reserved | Option Length=20 | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | Reserved | Prefix Length | Remote Peer Port | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | | 2807 | Remote Peer IP address (128 bits) | 2808 | | 2809 | | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 Figure 15: FILTER Option layout 2814 These fields are described below: 2816 Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored 2817 when received. 2819 Prefix Length: indicates how many bits of the IPv4 or IPv6 address 2820 are relevant for this filter. The value 0 indicates "no filter", 2821 and will remove all previous filters. See below for detail. 2823 Remote Peer Port: the port number of the remote peer. The value 0 2824 indicates "all ports". 2826 Remote Peer IP address: The IP address of the remote peer. 2828 Option Name: FILTER 2829 Number: 3 2830 Purpose: specifies a filter for incoming packets 2831 Valid for Opcodes: MAP 2832 Length: 20 octets 2833 May appear in: request. May appear in response only if it 2834 appeared in the associated request. 2835 Maximum occurrences: as many as fit within maximum PCP message 2836 size 2838 The Prefix Length indicates how many bits of the address are used for 2839 the filter. For IPv4 addresses (which are encoded using the IPv4- 2840 mapped address format (::FFFF:0:0/96)), this means valid prefix 2841 lengths are between 96 and 128 bits, inclusive. That is, add 96 to 2842 the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are 2843 between 0 and 128 bits, inclusive. Values outside those ranges cause 2844 the PCP server to return the MALFORMED_OPTION result code. 2846 If multiple occurrences of the FILTER Option exist in the same MAP 2847 request, they are processed in the order received (as per normal PCP 2848 Option processing) and they MAY overlap the filtering requested. If 2849 an existing mapping exists (with or without a filter) and the server 2850 receives a MAP request with FILTER, the filters indicated in the new 2851 request are added to any existing filters. If a MAP request has a 2852 lifetime of 0 and contains the FILTER Option, the error 2853 MALFORMED_OPTION is returned. 2855 If any occurrences of the FILTER Option in a request packet are not 2856 successfully processed then an error is returned (e.g., 2857 MALFORMED_OPTION if one of the Options was malformed) and as with 2858 other PCP errors, returning an error causes no state to be changed in 2859 the PCP server or in the PCP-controlled device. 2861 To remove all existing filters, the Prefix Length 0 is used. There 2862 is no mechanism to remove a specific filter. 2864 To change an existing filter, the PCP client sends a MAP request 2865 containing two FILTER Options, the first Option containing a Prefix 2866 Length of 0 (to delete all existing filters) and the second 2867 containing the new remote peer's IP address, protocol, and port. 2868 Other FILTER Options in that PCP request, if any, add more allowed 2869 Remote Peers. 2871 The PCP server or the PCP-controlled device is expected to have a 2872 limit on the number of remote peers it can support. This limit might 2873 be as small as one. If a MAP request would exceed this limit, the 2874 entire MAP request is rejected with the result code 2875 EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. 2877 All PCP servers MUST support at least one filter per MAP mapping. 2879 14. Rapid Recovery 2881 PCP includes a rapid recovery feature, which allows PCP clients to 2882 repair failed mappings within seconds, rather than the minutes or 2883 hours it might take if they relied solely on waiting for the next 2884 routine renewal of the mapping. Mapping failures may occur when a 2885 NAT gateway is rebooted and loses its mapping state, or when a NAT 2886 gateway has its external IP address changed so that its current 2887 mapping state becomes invalid. 2889 The PCP rapid recovery feature enables users to, for example, connect 2890 to remote machines using ssh, and then reboot their NAT or firewall 2891 device (or even replace it with completely new hardware) without 2892 losing their established ssh connections. 2894 Use of PCP rapid recovery is a performance optimization to PCP's 2895 routine self-healing. Without rapid recovery, PCP clients will still 2896 recreate their correct state when they next renew their mappings, but 2897 this routine self-healing process may take hours rather than seconds, 2898 and will probably not happen fast enough to prevent active TCP 2899 connections from timing out. 2901 There are two mechanisms to perform rapid recovery, described below. 2902 A PCP server that can lose state (e.g., due to reboot) or might have 2903 a mapping change (e.g., due to IP renumbering) MUST implement either 2904 the Announce Opcode or the Mapping Update mechanism and SHOULD 2905 implement both mechanisms. Failing to implement and deploy a rapid 2906 recovery mechanism will encourage application developers to feel the 2907 need to refresh their PCP state more frequently than necessary, 2908 causing more network traffic. 2910 14.1. ANNOUNCE Opcode 2912 This rapid recovery mechanism uses the ANNOUNCE Opcode. When the PCP 2913 server loses its state (e.g., it lost its state when rebooted), it 2914 sends the ANNOUNCE response to the link-scoped multicast address 2915 (specific address explained below) if a multicast network exists on 2916 its local interface or, if configured with the IP address(es) and 2917 port(s) of PCP client(s), sends unicast ANNOUNCE responses to those 2918 address(es) and port(s). This means ANNOUNCE may not be available on 2919 all networks (such as networks without a multicast link between the 2920 PCP server and its PCP clients). Additionally, an ANNOUNCE request 2921 can be sent (unicast) by a PCP client which elicits a unicast 2922 ANNOUNCE response like any other Opcode. 2924 14.1.1. ANNOUNCE Operation 2926 The PCP ANNOUNCE Opcode requests and respones have no Opcode-specific 2927 payload (that is, the length of the Opcode-specific data is zero). 2928 The Requested Lifetime field of requests and Lifetime field of 2929 responses are both set to 0 on transmission and ignored on reception. 2931 If a PCP server receives an ANNOUNCE request, it first parses it and 2932 generates a SUCCESS if parsing and processing of ANNOUNCE is 2933 successful. An error is generated if the Client's IP Address field 2934 does not match the packet source address, or the request packet is 2935 otherwise malformed, such as packet length less than 24 octets. Note 2936 that, in the future, Options MAY be sent with the PCP ANNOUNCE 2937 Opcode; PCP clients and servers need to be prepared to receive 2938 Options with the ANNOUNCE Opcode. 2940 Discussion: Client-to-server request messages are sent to 2941 listening UDP port 5351 on the server; server-to-client multicast 2942 notifications are sent to listening UDP port 5350 on the client. 2943 The reason the same UDP port is not used for both purposes is that 2944 a single device may have multiple roles. For example, a multi- 2945 function home gateway that provides NAT service (PCP server) may 2946 also provide printer sharing (which wants a PCP client), or a home 2947 computer (PCP client) may also provide "Internet Sharing" (NAT) 2948 functionality (which needs to offer PCP service). Such devices 2949 need to act as both a PCP Server and a PCP Client at the same 2950 time, and the software that implements the PCP Server on the 2951 device may not be the same software component that implements the 2952 PCP Client. The software that implements the PCP Server needs to 2953 listen for unicast client requests, whereas the software that 2954 implements the PCP Client needs to listen for multicast restart 2955 announcements. In many networking APIs it is difficult or 2956 impossible to have two independent clients listening for both 2957 unicasts and multicasts on the same port at the same time. For 2958 this reason, two ports are used. 2960 14.1.2. Generating and Processing a Solicited ANNOUNCE Message 2962 The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client. The 2963 Requested Lifetime value MUST be set to zero. 2965 When the PCP server receives the ANNOUNCE Opcode and successfully 2966 parses and processes it, it generates SUCCESS response with an 2967 Assigned Lifetime of zero. 2969 This functionality allows a PCP client to determine a server's Epoch, 2970 or to determine if a PCP server is running, without changing the 2971 server's state. 2973 14.1.3. Generating and Processing an Unsolicited ANNOUNCE Message 2975 When sending unsolicited responses, the ANNOUNCE Opcode MUST have 2976 Result Code equal to zero (SUCCESS), and the packet MUST be sent from 2977 the unicast IP address and UDP port number on which PCP requests are 2978 received (so PCP response processing accepts the message, see 2979 Section 8.3). This message is most typically multicast, but can also 2980 be unicast. Multicast PCP restart announcements are sent to 2981 224.0.0.1:5350 and/or [ff02::1]:5350, as described below. Sending 2982 PCP restart announcements via unicast requires that the PCP server 2983 know the IP address(es) and port(s) of its listening clients, which 2984 means that sending PCP restart announcements via unicast is only 2985 applicable to PCP servers that retain knowledge of the IP address(es) 2986 and port(s) of their clients even after they otherwise lose the rest 2987 of their state. 2989 When a PCP server device that implements this functionality reboots, 2990 restarts its NAT engine, or otherwise enters a state where it may 2991 have lost some or all of its previous mapping state (or enters a 2992 state where it doesn't even know whether it may have had prior state 2993 that it lost) it MUST inform PCP clients of this fact by unicasting 2994 or multicasting a gratuitous PCP ANNOUNCE Opcode response packet, as 2995 shown below, via paths over which it accepts PCP requests. If 2996 sending a multicast ANNOUNCE message, a PCP server device which 2997 accepts PCP requests over IPv4 sends the Restart Announcement to the 2998 IPv4 multicast address 224.0.0.1:5350 (224.0.0.1 is the All Hosts 2999 multicast group address), and a PCP server device which accepts PCP 3000 requests over IPv6 sends the Restart Announcement to the IPv6 3001 multicast address [ff02::1]:5350 (ff02::1 is for all nodes on the 3002 local segment). A PCP server device which accepts PCP requests over 3003 both IPv4 and IPv6 sends a pair of Restart Announcements, one to each 3004 multicast address. If sending a unicast ANNOUNCE messages, it sends 3005 ANNOUNCE response message to the IP address(es) and port(s) of its 3006 PCP clients. To accommodate packet loss, the PCP server device MAY 3007 transmit such packets (or packet pairs) up to ten times (with an 3008 appropriate Epoch time value in each to reflect the passage of time 3009 between transmissions) provided that the interval between the first 3010 two notifications is at least 250ms, and the interval between 3011 subsequent notification at least doubles. 3013 A PCP client that sends PCP requests to a PCP Server via a multicast- 3014 capable path, and implements the Restart Announcement feature, and 3015 wishes to receive these announcements, MUST listen to receive these 3016 PCP Restart Announcements (gratuitous PCP ANNOUNCE Opcode response 3017 packets) on the appropriate multicast-capable interfaces on which it 3018 sends PCP requests, and MAY also listen for unicast announcements 3019 from the server too, (using the UDP port it already uses to issue 3020 unicast PCP requests to, and receive unicast PCP responses from, that 3021 server). A PCP client device which sends PCP requests using IPv4 3022 listens for packets sent to the IPv4 multicast address 224.0.0.1: 3023 5350. A PCP client device which sends PCP requests using IPv6 3024 listens for packets sent to the IPv6 multicast address [ff02::1]: 3025 5350. A PCP client device which sends PCP requests using both IPv4 3026 and IPv6 listens for both types of Restart Announcement. The 3027 SO_REUSEPORT socket option or equivalent should be used for the 3028 multicast UDP port, if required by the host OS to permit multiple 3029 independent listeners on the same multicast UDP port. 3031 Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode 3032 response packet, a PCP client MUST (as it does with all received PCP 3033 response packets) inspect the Announcement's source IP address, and 3034 if the Epoch time value is outside the expected range for that 3035 server, it MUST wait a random amount of time between 0 and 5 seconds 3036 (to prevent synchronization of all PCP clients), then for all PCP 3037 mappings it made at that server address the client issues new PCP 3038 requests to recreate any lost mapping state. The use of the 3039 Suggested External IP Address and Suggested External Port fields in 3040 the client's renewal requests allows the client to remind the 3041 restarted PCP server device of what mappings the client had 3042 previously been given, so that in many cases the prior state can be 3043 recreated. For PCP server devices that reboot relatively quickly it 3044 is usually possible to reconstruct lost mapping state fast enough 3045 that existing TCP connections and UDP communications do not time out, 3046 and continue without failure. As for all PCP response messages, if 3047 the Epoch time value is within the expected range for that server, 3048 the PCP client does not recreate its mappings. As for all PCP 3049 response messages, after receiving and validating the ANNOUNCE 3050 message, the client updates its own Epoch time for that server, as 3051 described in Section 8.5. 3053 14.2. PCP Mapping Update 3055 This rapid recovery mechanism is used when the PCP server remembers 3056 its state and determines its existing mappings are invalid (e.g., IP 3057 renumbering changes the External IP Address of a PCP-controlled NAT). 3059 It is anticipated that servers which are routinely reconfigured by an 3060 administrator or have their WAN address changed frequently will 3061 implement this feature (e.g., residential CPE routers). It is 3062 anticipated that servers which are not routinely reconfigured will 3063 not implement this feature (e.g., service provider-operated CGN). 3065 If a PCP server device has not forgotten its mapping state, but for 3066 some other reason has determined that some or all of its mappings 3067 have become unusable (e.g., when a home gateway is assigned a 3068 different external IPv4 address by the upstream DHCP server) then the 3069 PCP server device automatically repairs its mappings and notifies its 3070 clients by following the procedure described below. 3072 For PCP-managed mappings, for each one the PCP server device should 3073 update the External IP Address and External Port to appropriate 3074 available values, and then send unicast PCP MAP or PEER responses (as 3075 appropriate for the mapping) to inform the PCP client of the new 3076 External IP Address and External Port. Such unsolicited responses 3077 are identical to the MAP or PEER responses normally returned in 3078 response to client MAP or PEER requests, containing newly updated 3079 External IP Address and External Port values, and are sent to the 3080 same client IP address and port that the PCP server used to send the 3081 prior response for that mapping. If the earlier associated request 3082 contained the THIRD_PARTY Option, the THIRD_PARTY Option MUST also 3083 appear in the Mapping Update as it is necessary for the PCP client to 3084 disambiguate the response. If the earlier associated request 3085 contained the PREFER_FAILURE option, and the same external IP 3086 address, protocol, and port cannot be provided, the error 3087 CANNOT_PROVIDE_EXTERNAL SHOULD be sent. If the earlier associated 3088 request contained the FILTER option, the filters are moved to the new 3089 mapping and the FILTER Option is sent in the Mapping Update response. 3090 Non-mandatory Options SHOULD NOT be sent in the Mapping Update 3091 response. 3093 Discussion: It could have been possible to design this so that the 3094 PCP server (1) sent an ANNOUNCE Opcode to the PCP client, the PCP 3095 client reacted by (2) sending a new MAP request and (3) receiving 3096 a MAP response. Instead, that design is short-cutted by the 3097 server simply sending the message it would have sent in (3). 3099 To accommodate packet loss, the PCP server device SHOULD transmit 3100 such packets 3 times, with an appropriate Epoch time value in each to 3101 reflect the passage of time between transmissions. The interval 3102 between the first two notifications MUST be at least 250ms, and the 3103 third packet after a 500ms interval. Once the PCP server has 3104 received a refreshed state for that mapping, the PCP server SHOULD 3105 cease those retransmissions for that mapping, as it serves no further 3106 purpose to continue sending messages regarding that mapping. 3108 Upon receipt of such an updated MAP or PEER response, a PCP client 3109 uses the information in the response to adjust rendezvous servers or 3110 re-connect to servers, respectively. For MAP, this would means 3111 updating the DNS entries or other address and port information 3112 recorded with some kind of application-specific rendezvous server. 3113 For PEER responses giving a CANNOT_PROVIDE_EXTERNAL error, this would 3114 typically mean establishing new connections to servers. Any time the 3115 external address or port changes, existing TCP and UDP connections 3116 will be lost; PCP can't avoid that, but does provide immediate 3117 notification of the event to lessen the impact. 3119 15. Mapping Lifetime and Deletion 3121 The PCP client requests a certain lifetime, and the PCP server 3122 responds with the assigned lifetime. The PCP server MAY grant a 3123 lifetime smaller or larger than the requested lifetime. The PCP 3124 server SHOULD be configurable for permitted minimum and maximum 3125 lifetime, and the minimum value SHOULD be 120 seconds. The maximum 3126 value SHOULD be the remaining lifetime of the IP address assigned to 3127 the PCP client if that information is available (e.g., from the DHCP 3128 server), or half the lifetime of IP address assignments on that 3129 network if the remaining lifetime is not available, or 24 hours. 3130 Excessively long lifetimes can cause consumption of ports even if the 3131 Internal Host is no longer interested in receiving the traffic or is 3132 no longer connected to the network. These recommendations are not 3133 strict, and deployments should evaluate the trade offs to determine 3134 their own minimum and maximum lifetime values. 3136 Once a PCP server has responded positively to a MAP request for a 3137 certain lifetime, the port mapping is active for the duration of the 3138 lifetime unless the lifetime is reduced by the PCP client (to a 3139 shorter lifetime or to zero) or until the PCP server loses its state 3140 (e.g., crashes). Mappings created by PCP MAP requests are not 3141 special or different from mappings created in other ways. In 3142 particular, it is implementation-dependent if outgoing traffic 3143 extends the lifetime of such mappings beyond the PCP-assigned 3144 lifetime. PCP clients MUST NOT depend on this behavior to keep 3145 mappings active, and MUST explicitly renew their mappings as required 3146 by the Lifetime field in PCP response messages. 3148 Upon receipt of a PCP response with an absurdly long Assigned 3149 Lifetime the PCP client SHOULD behave as if it received a more sane 3150 value (e.g., 24 hours), and renew the mapping accordingly, to ensure 3151 that if the static mapping is removed the client will continue to 3152 maintain the mapping it desires. 3154 An application that forgets its PCP-assigned mappings (e.g., the 3155 application or OS crashes) will request new PCP mappings. This may 3156 consume port mappings, if the application binds to a different 3157 Internal Port every time it runs. The application will also likely 3158 initiate new implicit dynamic outbound mappings without using PCP, 3159 which will also consume port mappings. If there is a port mapping 3160 quota for the Internal Host, frequent restarts such as this may 3161 exhaust the quota. PCP provides some protections against such port 3162 consumption: When a PCP client first acquires a new IP address (e.g., 3163 reboots or joins a new network), it SHOULD remove mappings that may 3164 already be instantiated for that new Internal Address. To do this, 3165 the PCP client sends a MAP request with protocol, internal port, and 3166 lifetime set to 0. Some port mapping APIs (e.g., the 3167 "DNSServiceNATPortMappingCreate" API provided by Apple's Bonjour on 3168 Mac OS X, iOS, Windows, Linux [Bonjour]) automatically monitor for 3169 process exit (including application crashes) and automatically send 3170 port mapping deletion requests if the process that requested them 3171 goes away without explicitly relinquishing them. 3173 To help clean PCP state, it is RECOMMENDED that devices which combine 3174 IP address assignment (e.g., DHCP server) with the PCP server 3175 function (e.g., such as a residential CPE) flush PCP state when an IP 3176 address is allocated to a new host, because the new host will be 3177 unable perform the functions described in the previous paragaph 3178 because the new host does not know the previous host's Mapping Nonce 3179 value. It is good hygiene to also flush TCP and UDP flow state of 3180 NAT or fireall functions, although out of scope of this document. 3182 To reduce unwanted traffic and data corruption for both TCP and UDP, 3183 the Assigned External Port created by the MAP Opcode or PEER Opcode 3184 SHOULD NOT be re-used for the same interval enforced by NAT for 3185 implicitly creating mappings, which is typically the maximum segment 3186 lifetime interval of 120 seconds [RFC0793]. To reduce port stealing 3187 attacks, the Assigned External Port SHOULD NOT be re-used by the same 3188 Client IP Address (or Internal IP Address if using the THIRD_PARTY 3189 Option) for the duration the PCP-controlled device keeps a mapping 3190 for active bi-directional traffic (e.g., 2 minutes for UDP [RFC4787], 3191 2 hours 4 minutes for TCP [RFC5382]). However, within the above 3192 times, the PCP server SHOULD allow a request using the same Client IP 3193 Address (and same Internal IP Address if using the THIRD_PARTY 3194 Option), Internal Port, and Mapping Nonce to re-acquire the same 3195 External Port. 3197 The assigned lifetime is calculated by subtracting (a) zero or the 3198 number of seconds since the internal host sent a packet for this 3199 mapping from (b) the lifetime the PCP-controlled device uses for 3200 transitory connection idle-timeout (e.g., a NAT device might use 2 3201 minutes for UDP [RFC4787] or 4 minutes for TCP [RFC5382]). If the 3202 result is a negative number, the assigned lifetime is 0. 3204 15.1. Lifetime Processing for the MAP Opcode 3206 If the the requested lifetime is zero then: 3208 o If both the protocol and internal port are non-zero, it indicates 3209 a request to delete the indicated mapping immediately. 3211 o If the protocol is non-zero and the internal port is zero, it 3212 indicates a request to delete a previous 'wildcard' (all-ports) 3213 mapping for that protocol. 3215 o If both the protocol and internal port are zero, it indicates a 3216 request to delete all mappings for this Internal Address for all 3217 transport protocols. Such a request is rejected with a 3218 NOT_AUTHORIZED error. To delete all mappings the client has to 3219 send separate MAP requests with appropriate Mapping Nonce values. 3221 o If the protocol is zero and the internal port is non-zero, then 3222 the request is invalid and the PCP Server MUST return a 3223 MALFORMED_REQUEST error to the client. 3225 In requests where the requested Lifetime is 0, the Suggested External 3226 Address and Suggested External Port fields MUST be set to zero on 3227 transmission and MUST be ignored on reception, and these fields MUST 3228 be copied into the Assigned External IP Address and Assigned External 3229 Port of the response. 3231 PCP MAP requests can only delete or shorten lifetimes of MAP-created 3232 mappings. If the PCP client attempts to delete a static mapping 3233 (i.e., a mapping created outside of PCP itself), or an outbound 3234 (implicit or PEER-created) mapping, the PCP server MUST return 3235 NOT_AUTHORIZED. If the PCP client attempts to delete a mapping that 3236 does not exist, the SUCCESS result code is returned (this is 3237 necessary for PCP to return the same response for the same request). 3238 If the deletion request was properly formatted and successfully 3239 processed, a SUCCESS response is generated with the assigned lifetime 3240 of the mapping and the server copies the protocol and internal port 3241 number from the request into the response. An inbound mapping (i.e., 3242 static mapping or MAP- created dynamic mapping) MUST NOT have its 3243 lifetime reduced by transport protocol messages (e.g., TCP RST, TCP 3244 FIN). Note the THIRD_PARTY Option, if authorized, can also delete 3245 PCP-created mappings (see Section 13.1). 3247 16. Implementation Considerations 3249 Section 16 provides non-normative guidance that may be useful to 3250 implementers. 3252 16.1. Implementing MAP with EDM port-mapping NAT 3254 For implicit dynamic outbound mappings, some existing NAT devices 3255 have endpoint-independent mapping (EIM) behavior while other NAT 3256 devices have endpoint-dependent mapping (EDM) behavior. NATs which 3257 have EIM behavior do not suffer from the problem described in this 3258 section. The IETF strongly encourages EIM behavior 3259 [RFC4787][RFC5382]. 3261 In EDM NAT devices, the same external port may be used by an outbound 3262 dynamic mapping and an inbound dynamic mapping (from the same 3263 Internal Host or from a different Internal Host). This complicates 3264 the interaction with the MAP Opcode. With such NAT devices, there 3265 are two ways envisioned to implement the MAP Opcode: 3267 1. Have outbound mappings use a different set of External ports than 3268 inbound mappings (e.g., those created with MAP), thus reducing 3269 the interaction problem between them; or 3271 2. On arrival of a packet (inbound from the Internet or outbound 3272 from an Internal Host), first attempt to use a dynamic outbound 3273 mapping to process that packet. If none match, attempt to use an 3274 inbound mapping to process that packet. This effectively 3275 'prioritizes' outbound mappings above inbound mappings. 3277 16.2. Lifetime of Explicit and Implicit Dynamic Mappings 3279 No matter if a NAT is EIM or EDM, it is possible that one (or more) 3280 outbound mappings, using the same internal port on the Internal Host, 3281 might be created before or after a MAP request. When this occurs, it 3282 is important that the NAT honor the Lifetime returned in the MAP 3283 response. Specifically, if a mapping was created with the MAP 3284 Opcode, the implementation needs to ensure that termination of an 3285 outbound mapping (e.g., via a TCP FIN handshake) does not prematurely 3286 destroy the MAP-created inbound mapping. 3288 16.3. PCP Failure Recovery 3290 If an event occurs that causes the PCP server to lose dynamic mapping 3291 state (such as a crash or power outage), the mappings created by PCP 3292 are lost. Occasional loss of state may be unavoidable in a 3293 residential NAT device which does not write transient information to 3294 non-volatile memory. Loss of state is expected to be rare in a 3295 service provider environment (due to redundant power, disk drives for 3296 storage, etc.). Of course, due to outright failure of service 3297 provider equipment (e.g., software malfunction), state may still be 3298 lost. 3300 The Epoch Time allows a client to deduce when a PCP server may have 3301 lost its state. When the Epoch Time value is observed to be outside 3302 the expected range, the PCP client can attempt to recreate the 3303 mappings following the procedures described in this section. 3305 Further analysis of PCP failure scenarios is in 3306 [I-D.boucadair-pcp-failure]. 3308 16.3.1. Recreating Mappings 3310 A mapping renewal packet is formatted identically to an original 3311 mapping request; from the point of view of the client it is a renewal 3312 of an existing mapping, but from the point of view of a newly 3313 rebooted PCP server it appears as a new mapping request. In the 3314 normal process of routinely renewing its mappings before they expire, 3315 a PCP client will automatically recreate all its lost mappings. 3317 When the PCP server loses state and begins processing new PCP 3318 messages, its Epoch time is reset and begins counting again. As the 3319 result of receiving a packet where the Epoch time field is outside 3320 the expected range (Section 8.5), indicating that a reboot or similar 3321 loss of state has occurred, the client can renew its port mappings 3322 sooner, without waiting for the normal routine renewal time. 3324 16.3.2. Maintaining Mappings 3326 A PCP client refreshes a mapping by sending a new PCP request 3327 containing information from the earlier PCP response. The PCP server 3328 will respond indicating the new lifetime. It is possible, due to 3329 reconfiguration or failure of the PCP server, that the External IP 3330 Address and/or External Port, or the PCP server itself, has changed 3331 (due to a new route to a different PCP server). Such events are 3332 rare, but not an error. The PCP server will simply return a new 3333 External Address and/or External Port to the client, and the client 3334 should record this new External Address and Port with its rendezvous 3335 service. To detect such events more quickly, a server that requires 3336 extremely high availability may find it beneficial to use shorter 3337 lifetimes in its PCP mappings requests, so that it communicates with 3338 the PCP server more often. This is an engineering trade-off based on 3339 (i) the acceptable downtime for the service in question, (ii) the 3340 expected likelihood of NAT or firewall state loss, and (iii) the 3341 amount of PCP maintenance traffic that is acceptable. 3343 If the PCP client has several mappings, the Epoch Time value only 3344 needs to be retrieved for one of them to determine whether or not it 3345 appears the PCP server may have suffered a catastrophic loss of 3346 state. If the client wishes to check the PCP server's Epoch Time, it 3347 sends a PCP request for any one of the client's mappings. This will 3348 return the current Epoch Time value. In that request the PCP client 3349 could extend the mapping lifetime (by asking for more time) or 3350 maintain the current lifetime (by asking for the same number of 3351 seconds that it knows are remaining of the lifetime). 3353 If a PCP client changes its Internal IP Address (e.g., because the 3354 Internal Host has moved to a new network), and the PCP client wishes 3355 to still receive incoming traffic, it needs create new mappings on 3356 that new network. New mappings will typically also require an update 3357 to the application-specific rendezvous server if the External Address 3358 or Port are different from the previous values (see Section 10.1 and 3359 Section 11.5). 3361 16.3.3. SCTP 3363 Although SCTP has port numbers like TCP and UDP, SCTP works 3364 differently when behind an address-sharing NAT, in that SCTP port 3365 numbers are not changed [I-D.ietf-behave-sctpnat]. Outbound dynamic 3366 SCTP mappings use the verification tag of the association instead of 3367 the local and remote peer port numbers. As with TCP, explicit 3368 outbound mappings can be made to reduce keepalive intervals, and 3369 explicit inbound mappings can be made by passive listeners expecting 3370 to receive new associations at the external port. 3372 Because an SCTP-aware NAT does not (currently) rewrite SCTP port 3373 numbers, it will not be able to assign an External Port that is 3374 different from the client's Internal Port. A PCP client making a MAP 3375 request for SCTP should be aware of this restriction. The PCP client 3376 SHOULD make its SCTP MAP request just as it would for a TCP MAP 3377 request: in its initial PCP MAP request it SHOULD specify zero for 3378 the External Address and Port, and then in subsequent renewals it 3379 SHOULD echo the assigned External Address and Port. However, since a 3380 current SCTP-aware NAT can only assign an External Port that is the 3381 same as the Internal Port, it may not be able to do that if the 3382 External Port is already assigned to a different PCP client. This is 3383 likely if there is more than one instance of a given SCTP service on 3384 the local network, since both instances are likely to listen on the 3385 same well-known SCTP port for that service on their respective hosts, 3386 but they can't both have the same External Port on the NAT gateway's 3387 External Address. A particular External Port may not be assignable 3388 for other reasons, such as when it is already in use by the NAT 3389 device itself, or otherwise prohibited by policy, as described in 3390 Section 11.3. In the event that the External Port matching the 3391 Internal Port cannot be assigned (and the SCTP-aware NAT does not 3392 perform SCTP port rewriting) then the SCTP-aware NAT MUST return a 3393 CANNOT_PROVIDE_EXTERNAL error to the requesting PCP client. Note 3394 that this restriction places extra burden on the SCTP server whose 3395 MAP request failed, because it then has to tear down its exiting 3396 listening socket and try again with a different Internal Port, 3397 repeatedly until it is successful in finding an External Port it can 3398 use. 3400 The SCTP complications described above occur because of address 3401 sharing. The SCTP complications are avoided when address sharing is 3402 avoided (e.g., 1:1 NAT, firewall). 3404 16.4. Source Address Replicated in PCP Header 3406 All PCP requests include the PCP client's IP address replicated in 3407 the PCP header. This is used to detect address rewriting (NAT) 3408 between the PCP client and its PCP server. On operating systems that 3409 support the sockets API, the following steps are RECOMMENDED for a 3410 PCP client to insert the correct source address and port in the PCP 3411 header: 3413 1. Create a UDP socket. 3414 2. Call "connect" on this UDP socket using the address and port of 3415 the desired PCP server. 3416 3. Call the getsockname() function to retrieve a sockaddr containing 3417 the source address the kernel will use for UDP packets sent 3418 through this socket. 3419 4. If the IP address is an IPv4 address, encode the address into an 3420 IPv4-mapped IPv6 address. Place the native IPv6 address or IPv4- 3421 mapped IPv6 address into the PCP Client's IP Address field in the 3422 PCP header. 3423 5. Send PCP requests using this connected UDP socket. 3425 16.5. State Diagram 3427 Each mapping entry of the PCP-controlled device would go through the 3428 state machine shown below. This state diagram is non-normative. 3430 CLOSE_MSG or 3431 (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY 3432 +-------------->| |<------------+ 3433 | |NO_ENTRY | | 3434 | +-----------| |---------+ | 3435 | | +---------+ | | 3436 | | ^ | | | 3437 | | NO_TRAFFIC | | | | 3438 | | or | | | | 3439 | | CLOSE_MSGS | | | | 3440 | | | | | | 3441 | |PEER request | | MAP request| | 3442 | V | | V | 3443 +---------+ | | +---------+ 3444 +-->| "P", | | | M-R | "M", |<--+ 3445 P-R | | PEER |-----------|--|-------->| MAP | | M-R or 3446 +---| mapping| | | | mapping|---+ P-R or 3447 +---------+ | | +---------+ CLOSE_MSGS 3448 | ^ | | ^ | 3449 | |PEER request | | MAP request| | 3450 | | | | | | 3451 | | | | | | 3452 | | | | | | 3453 | | | | outbound | | 3454 | | | | TRAFFIC | | 3455 | | | V | | 3456 | | +---------+ | | 3457 | +-----------| "I", |---------+ | 3458 | | implicit| | 3459 +-------------->| mapping |<------------+ 3460 TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY 3462 Figure 16: PCP State Diagram 3464 The meanings of the states and events are: 3466 NO_ENTRY: Invalid state represents Entry does not exist. This is 3467 the only possible start state. 3469 M-R: MAP request 3471 P-R: PEER request 3473 M: Mapping entry when created by MAP request 3475 P: Mapping entry when created/managed by PEER request 3477 I: Implicit mapping created by an outgoing packet from the 3478 client (e.g., TCP SYN), and also the state when a PCP-created 3479 mapping's lifetime expires while there is still active 3480 traffic. 3482 EXPIRY: PEER or MAP lifetime expired 3484 TRAFFIC: Traffic seen by PCP-controlled device using this entry 3485 within the expiry time for that entry. This traffic may be 3486 inbound or outbound. 3488 NO_TRAFFIC: Indicates that there is no TRAFFIC. 3490 CLOSE_MSG: Protocol messages from the client or server to close 3491 the session (e.g., TCP FIN or TCP RST), as per the NAT or 3492 firewall device's handling of such protocol messages. 3494 Notes on the diagram: 3496 1. The 'and' clause indicates the events on either side of 'and' are 3497 required for the state-transition. The 'or' clause indicates 3498 either one of the events are enough for the state-transition. 3500 2. Transition from state M to state I is implementation dependent. 3502 17. Deployment Considerations 3504 17.1. Ingress Filtering 3506 As with implicit dynamic mappings created by outgoing TCP SYN 3507 packets, explicit dynamic mappings created via PCP use the source IP 3508 address of the packet as the Internal Address for the mappings. 3509 Therefore ingress filtering [RFC2827] SHOULD be used on the path 3510 between the Internal Host and the PCP Server to prevent the injection 3511 of spoofed packets onto that path. 3513 17.2. Mapping Quota 3515 On PCP-controlled devices that create state when a mapping is created 3516 (e.g., NAT), the PCP server SHOULD maintain per-host and/or per- 3517 subscriber quotas for mappings. It is implementation-specific 3518 whether the PCP server uses a separate quotas for implicit, explicit, 3519 and static mappings, a combined quota for all of them, or some other 3520 policy. 3522 18. Security Considerations 3524 The goal of the PCP protocol is to improve the ability of end nodes 3525 to control their associated NAT state, and to improve the efficiency 3526 and error handling of NAT mappings when compared to existing implicit 3527 mapping mechanisms in NAT boxes and stateful firewalls. It is the 3528 security goal of the PCP protocol to limit any new denial of service 3529 opportunities, and to avoid introducing new attacks that can result 3530 in unauthorized changes to mapping state. One of the most serious 3531 consequences of unauthorized changes in mapping state is traffic 3532 theft. All mappings that could be created by a specific host using 3533 implicit mapping mechanisms are inherently considered to be 3534 authorized. Confidentiality of mappings is not a requirement, even 3535 in cases where the PCP messages may transit paths that would not be 3536 travelled by the mapped traffic. 3538 18.1. Simple Threat Model 3540 PCP is secure against off-path attackers who cannot spoof a packet 3541 that the PCP Server will view as a packet received from the internal 3542 network. PCP is secure against off-path attackers who can spoof the 3543 PCP server's IP address. 3545 Defending against attackers who can modify or drop packets between 3546 the internal network and the PCP server, or who can inject spoofed 3547 packets that appear to come from the internal network is out of 3548 scope. Such an attacker can re-direct traffic to a host of their 3549 choosing. 3551 A PCP Server is secure under this threat model if the PCP Server is 3552 constrained so that it does not configure any explicit mapping that 3553 it would not configure implicitly. In most cases, this means that 3554 PCP Servers running on NAT boxes or stateful firewalls that support 3555 the PEER and MAP Opcodes can be secure under this threat model if (1) 3556 all of their hosts are within a single administrative domain (or if 3557 the internal hosts can be securely partitioned into separate 3558 administrative domains, as in the DS-Lite B4 case), (2) explicit 3559 mappings are created with the same lifetime as implicit mappings, and 3560 (3) the THIRD_PARTY option is not supported. PCP Servers can also 3561 securely support the MAP Opcode under this threat model if the 3562 security policy on the device running the PCP Server would permit 3563 endpoint independent filtering of implicit mappings. 3565 PCP Servers that comply with the Simple Threat Model and do not 3566 implement a PCP security mechanism described in Section 18.2 MUST 3567 enforce the constraints described in the paragraph above. 3569 18.1.1. Attacks Considered 3571 o If you allow multiple administrative domains to send PCP requests 3572 to a single PCP server that does not enforce a boundary between 3573 the domains, it is possible for a node in one domain to perform a 3574 denial of service attack on other domains, or to capture traffic 3575 that is intended for a node in another domain. 3577 o If explicit mappings have longer lifetimes than implicit mappings, 3578 it makes it easier to perpetrate a denial of service attack than 3579 it would be if the PCP Server was not present. 3581 o If the PCP Server supports deleting or reducing the lifetime of 3582 existing mappings, this allows an attacking node to steal an 3583 existing mapping and receive traffic that was intended for another 3584 node. 3586 o If the THIRD_PARTY Option is supported, this also allows an 3587 attacker to open a window for an external node to attack an 3588 internal node, allows an attacker to steal traffic that was 3589 intended for another node, or may facilitate a denial of service 3590 attack. One example of how the THIRD_PARTY Option could grant an 3591 attacker more capability than a spoofed implicit mapping is that 3592 the PCP server (especially if it is running in a service 3593 provider's network) may not be aware of internal filtering that 3594 would prevent spoofing an equivalent implicit mapping, such as 3595 filtering between a guest and corporate network. 3597 o If the MAP Opcode is supported by the PCP server in cases where 3598 the security policy would not support endpoint independent 3599 filtering of implicit mappings, then the MAP Opcode changes the 3600 security properties of the device running the PCP Server by 3601 allowing explicit mappings that violate the security policy. 3603 18.1.2. Deployment Examples Supporting the Simple Threat Model 3605 This section offers two examples of how the Simple Threat Model can 3606 be supported in real-world deployment scenarios. 3608 18.1.2.1. Residential Gateway Deployment 3610 Parity with many currently-deployed residential gateways can be 3611 achieved using a PCP Server that is constrained as described in 3612 Section 18.1 above. 3614 18.2. Advanced Threat Model 3616 In the Advanced Threat Model the PCP protocol ensures that attackers 3617 (on- or off-path) cannot create unauthorized mappings or make 3618 unauthorized changes to existing mappings. The protocol must also 3619 limit the opportunity for on- or off-path attackers to perpetrate 3620 denial of service attacks. 3622 The Advanced Threat Model security model will be needed in the 3623 following cases: 3625 o Security infrastructure equipment, such as corporate firewalls, 3626 that does not create implicit mappings. 3628 o Equipment (such as CGNs or service provider firewalls) that serve 3629 multiple administrative domains and do not have a mechanism to 3630 securely partition traffic from those domains. 3632 o Any implementation that wants to be more permissive in authorizing 3633 explicit mappings than it is in authorizing implicit mappings. 3635 o Implementations that wish to support any deployment scenario that 3636 does not meet the constraints described in Section 18.1. 3638 To protect against attacks under this threat model, a PCP security 3639 mechanism that provides an authenticated, integrity-protected 3640 signaling channel would need to be specified. 3642 PCP Servers that implement a PCP security mechanism MAY accept 3643 unauthenticated requests. PCP Servers implementing the PCP security 3644 mechanism MUST enforce the constraints described in Section 18.1 3645 above, in their default configuration, when processing 3646 unauthenticated requests. 3648 18.3. Residual Threats 3650 This section describes some threats that are not addressed in either 3651 of the above threat models, and recommends appropriate mitigation 3652 strategies. 3654 18.3.1. Denial of Service 3656 Because of the state created in a NAT or firewall, a per-host and/or 3657 per-subscriber quota will likely exist for both implicit dynamic 3658 mappings and explicit dynamic mappings. A host might make an 3659 excessive number of implicit or explicit dynamic mappings, consuming 3660 an inordinate number of ports, causing a denial of service to other 3661 hosts. Thus, Section 17.2 recommends that hosts be limited to a 3662 reasonable number of explicit dynamic mappings. 3664 An attacker, on the path between the PCP client and PCP server, can 3665 drop PCP requests, drop PCP responses, or spoof a PCP error, all of 3666 which will effectively deny service. Through such actions, the PCP 3667 client might not be aware the PCP server might have actually 3668 processed the PCP request. An attacker sending a NO_RESOURCES error 3669 can cause the PCP client to not send messages to that server for a 3670 while. There is no mitigation to this on-path attacker. 3672 18.3.2. Ingress Filtering 3674 It is important to prevent a host from fraudulently creating, 3675 deleting, or refreshing a mapping (or filtering) for another host, 3676 because this can expose the other host to unwanted traffic, prevent 3677 it from receiving wanted traffic, or consume the other host's mapping 3678 quota. Both implicit and explicit dynamic mappings are created based 3679 on the source IP address in the packet, and hence depend on ingress 3680 filtering to guard against spoof source IP addresses. 3682 18.3.3. Mapping Theft 3684 In the time between when a PCP server loses state and the PCP client 3685 notices the lower-than-expected Epoch Time value, it is possible that 3686 the PCP client's mapping will be acquired by another host (via an 3687 explicit dynamic mapping or implicit dynamic mapping). This means 3688 incoming traffic will be sent to a different host ("theft"). Rapid 3689 Recovery reduces this interval, but would not completely eliminate 3690 this threat. The PCP client can reduce this interval by using a 3691 relatively short lifetime; however, this increases the amount of PCP 3692 chatter. This threat is reduced by using persistent storage of 3693 explicit dynamic mappings in the PCP server (so it does not lose 3694 explicit dynamic mapping state), or by ensuring the previous external 3695 IP address, protocol, and port cannot be used by another host (e.g., 3696 by using a different IP address pool). 3698 18.3.4. Attacks Against Server Discovery 3700 This document does not specify server discovery, beyond contacting 3701 the default gateway. 3703 19. IANA Considerations 3705 IANA is requested to perform the following actions: 3707 19.1. Port Number 3709 PCP will use ports 5350 and 5351 (currently assigned by IANA to NAT- 3710 PMP [I-D.cheshire-nat-pmp]). We request that IANA re-assign those 3711 ports to PCP, and relinquish UDP port 44323. 3713 [Note to RFC Editor: Please remove the text about relinquishing port 3714 44323 prior to publication.] 3716 19.2. Opcodes 3718 IANA shall create a new protocol registry for PCP Opcodes, numbered 3719 0-127, initially populated with the values: 3721 value Opcode 3722 ----- ------------------------- 3723 0 ANNOUNCE 3724 1 MAP 3725 2 PEER 3726 3-31 Standards Action [RFC5226] 3727 32-63 Specification Required [RFC5226] 3728 96-126 Private Use [RFC5226] 3729 127 Reserved, Standards Action [RFC5226] 3731 The value 127 is Reserved and may be assigned via Standards Action 3732 [RFC5226]. The values in the range 3-31 can be assigned via 3733 Standards Action [RFC5226], 32-63 via Specification Required 3734 [RFC5226], and 96-126 is for Private Use [RFC5226]. 3736 19.3. Result Codes 3738 IANA shall create a new registry for PCP result codes, numbered 3739 0-255, initially populated with the result codes from Section 7.4. 3740 The value 255 is Reserved and may be assigned via Standards Action 3741 [RFC5226]. 3743 The values in the range 14-127 can be assigned via Standards Action 3744 [RFC5226], 128-191 via Specification Required [RFC5226], and 191-254 3745 is for Private Use [RFC5226]. 3747 19.4. Options 3749 IANA shall create a new registry for PCP Options, numbered 0-255, 3750 each with an associated mnemonic. The values 0-127 are mandatory-to- 3751 process, and 128-255 are optional to process. The initial registry 3752 contains the Options described in Section 13. The Option values 0, 3753 127 and 255 are Reserved and may be assigned via Standards Action 3754 [RFC5226]. 3756 Additional PCP Option codes in the ranges 4-63 and 128-191 can be 3757 created via Standards Action [RFC5226], the ranges 64-95 and 192-223 3758 are for Specification Required [RFC5226] and the ranges 96-126 and 3759 224-254 are for Private Use [RFC5226]. 3761 Documents describing an Option should describe if the processing for 3762 both the PCP client and server and the information below: 3763 Option Name: 3764 Number: 3765 Purpose: 3766 Valid for Opcodes: 3767 Length: 3768 May appear in: 3769 Maximum occurrences: 3771 20. Acknowledgments 3773 Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni 3774 Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda 3775 Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani, 3776 Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete 3777 Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins, 3778 Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda 3779 Costa, Amit Jain, and Wim Henderickx for their comments and review. 3781 Thanks to Simon Perreault for highlighting the interaction of dynamic 3782 connections with PCP-created mappings. 3784 Thanks to Francis Dupont for his several thorough reviews of the 3785 specification, which improved the protocol significantly. 3787 Thanks to T. S. Ranganathan for the state diagram. 3789 Thanks to Peter Lothberg for clock skew information. 3791 Thanks to Margaret Wasserman and Sam Hartman for writing the Security 3792 Considerations section. 3794 Thanks to authors of DHCPv6 for retransmission text. 3796 21. References 3798 21.1. Normative References 3800 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3801 August 1980. 3803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3804 Requirement Levels", BCP 14, RFC 2119, March 1997. 3806 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3807 Defeating Denial of Service Attacks which employ IP Source 3808 Address Spoofing", BCP 38, RFC 2827, May 2000. 3810 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3811 Requirements for Security", BCP 106, RFC 4086, June 2005. 3813 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3814 Addresses", RFC 4193, October 2005. 3816 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3817 Architecture", RFC 4291, February 2006. 3819 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3820 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3821 May 2008. 3823 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 3824 Protocol Port Randomization", BCP 156, RFC 6056, 3825 January 2011. 3827 [proto_numbers] 3828 IANA, "Protocol Numbers", 2011, . 3831 21.2. Informative References 3833 [Bonjour] "Bonjour", 3834 . 3836 [I-D.boucadair-pcp-failure] 3837 Boucadair, M., Dupont, F., and R. Penno, "Port Control 3838 Protocol (PCP) Failure Scenarios", 3839 draft-boucadair-pcp-failure-04 (work in progress), 3840 August 2012. 3842 [I-D.cheshire-dnsext-dns-sd] 3843 Cheshire, S. and M. Krochmal, "DNS-Based Service 3844 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 3845 progress), December 2011. 3847 [I-D.cheshire-nat-pmp] 3848 Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 3849 (NAT-PMP)", draft-cheshire-nat-pmp-05 (work in progress), 3850 September 2012. 3852 [I-D.ietf-behave-lsn-requirements] 3853 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 3854 and H. Ashida, "Common requirements for Carrier Grade NATs 3855 (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in 3856 progress), August 2012. 3858 [I-D.ietf-behave-sctpnat] 3859 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 3860 Transmission Protocol (SCTP) Network Address Translation", 3861 draft-ietf-behave-sctpnat-06 (work in progress), 3862 March 2012. 3864 [I-D.ietf-pcp-upnp-igd-interworking] 3865 Boucadair, M., Dupont, F., Penno, R., and D. Wing, 3866 "Universal Plug and Play (UPnP) Internet Gateway Device 3867 (IGD)-Port Control Protocol (PCP) Interworking Function", 3868 draft-ietf-pcp-upnp-igd-interworking-04 (work in 3869 progress), September 2012. 3871 [I-D.miles-behave-l2nat] 3872 Miles, D. and M. Townsley, "Layer2-Aware NAT", 3873 draft-miles-behave-l2nat-00 (work in progress), 3874 March 2009. 3876 [IGDv1] UPnP Gateway Committee, "WANIPConnection:1", 3877 November 2001, . 3880 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3881 RFC 793, September 1981. 3883 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3884 E. Lear, "Address Allocation for Private Internets", 3885 BCP 5, RFC 1918, February 1996. 3887 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 3888 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 3889 RFC 2136, April 1997. 3891 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 3892 Update", RFC 3007, November 2000. 3894 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3895 Address Translator (Traditional NAT)", RFC 3022, 3896 January 2001. 3898 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 3899 Session Initiation Protocol (SIP) for Symmetric Response 3900 Routing", RFC 3581, August 2003. 3902 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 3903 Unicast Address Format", RFC 3587, August 2003. 3905 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3906 RFC 4303, December 2005. 3908 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3909 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 3911 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3912 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3913 RFC 4787, January 2007. 3915 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3916 Extensions for Stateless Address Autoconfiguration in 3917 IPv6", RFC 4941, September 2007. 3919 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 3920 RFC 4960, September 2007. 3922 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3923 BCP 131, RFC 4961, July 2007. 3925 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 3926 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3927 RFC 5382, October 2008. 3929 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 3930 Customer Premises Equipment (CPE) for Providing 3931 Residential IPv6 Internet Service", RFC 6092, 3932 January 2011. 3934 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 3935 Algorithm", RFC 6145, April 2011. 3937 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3938 NAT64: Network Address and Protocol Translation from IPv6 3939 Clients to IPv4 Servers", RFC 6146, April 2011. 3941 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3942 Translation", RFC 6296, June 2011. 3944 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 3945 Stack Lite Broadband Deployments Following IPv4 3946 Exhaustion", RFC 6333, August 2011. 3948 [RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable 3949 Operation of Address Translators with Per-Interface 3950 Bindings", RFC 6619, June 2012. 3952 Appendix A. NAT-PMP Transition 3954 The Port Control Protocol (PCP) is a successor to the NAT Port 3955 Mapping Protocol, NAT-PMP [I-D.cheshire-nat-pmp], and shares similar 3956 semantics, concepts, and packet formats. Because of this NAT-PMP and 3957 PCP both use the same port, and use NAT-PMP and PCP's version 3958 negotiation capabilities to determine which version to use. This 3959 section describes how an orderly transition may be achieved. 3961 A client supporting both NAT-PMP and PCP SHOULD send its request 3962 using the PCP packet format. This will be received by a NAT-PMP 3963 server or a PCP server. If received by a NAT-PMP server, the 3964 response will be as indicated by the NAT-PMP specification 3965 [I-D.cheshire-nat-pmp], which will cause the client to downgrade to 3966 NAT-PMP and re-send its request in NAT-PMP format. If received by a 3967 PCP server, the response will be as described by this document and 3968 processing continues as expected. 3970 A PCP server supporting both NAT-PMP and PCP can handle requests in 3971 either format. The first octet of the packet indicates if it is NAT- 3972 PMP (first octet zero) or PCP (first octet non-zero). 3974 A PCP-only gateway receiving a NAT-PMP request (identified by the 3975 first octet being zero) will interpret the request as a version 3976 mismatch. Normal PCP processing will emit a PCP response that is 3977 compatible with NAT-PMP, without any special handling by the PCP 3978 server. 3980 Appendix B. Change History 3982 [Note to RFC Editor: Please remove this section prior to 3983 publication.] 3985 B.1. Changes from draft-ietf-pcp-base-27 to -28 3987 o When processing MAP request or processing PEER request, Mapping 3988 Nonce validation only applies to Basic Threat Model, and not to 3989 THIRD_PARTY. 3991 o A maximum payload size of 1100 keeps PCP packets below IPv6's 1280 3992 MTU limit while still allowing some room for encapsulation. This 3993 accomodates EAP over PANA over PCP (EAP needs 1020 octets, per 3994 RFC3748), should PCP authentication decide to use EAP over PANA 3995 over PCP. 3997 o Both MAP and PEER-created mappings cannot have their lifetimes 3998 reduced beyond normal UDP/TCP timesouts. 4000 o Disallow re-assigning External Port to same internal host. 4002 B.2. Changes from draft-ietf-pcp-base-26 to -27 4004 o For table, reverted the NAT64 remote peer to IPv6 -- because from 4005 the IPv6 PCP client's perspective, the remote peer really is IPv6. 4007 o "list of PCP server addresses" changed to "longer list of PCP 4008 server addresses" 4010 o Clarify that unsolicited ANNOUNCE messages are sent from the PCP 4011 server IP address and PCP port. 4013 o "1024 bytes" changed to "1024 octets". 4015 o Clarify that re-transmitted requests must use same Mapping Nonce 4016 value (beginning of Section 8.1.1). 4018 o Describe that de-synchronization that can occur (end of 4019 Section 8.1.1). 4021 o For devices that lose state or expect IP renumbering, Rapid 4022 Recovery is now a MUST, with SHOULD for implementing both 4023 multicast Announce mechanism and unicast mechanisms. 4025 o For refreshing MAP or PEER, Mapping Nonce has to match the 4026 previous MAP or PEER. This protects from off-path attackers 4027 stealing MAP or shortening PEER mappings. 4029 o With the Mapping Nonce change, we now allow PEER to reduce mapping 4030 lifetime to same lifetime as implicit mapping lifetime (but not 4031 shorter). Changes for this are in both PEER section and Security 4032 Considerations. 4034 o With Mapping Nonce change, can no longer delete a 'set of 4035 mappings' (because we cannot send multiple Mapping Nonce values), 4036 so removed text that allowed that. 4038 o Send Mapping Update only 3 times (used to be 10 times). 4040 o General PCP processing now requires validating Mapping Nonce, if 4041 the opcode uses a Mapping Nonce Section 8.3. 4043 o Moved text describing NO_RESOURCES handling from General 4044 Processing section to MAP and PEER processing sections, as it 4045 NO_RESOURCES processing should be done after validating Mapping 4046 Nonce. 4048 o Clarified SCTP NAT behavior (port numbers stay the same, causing 4049 grief). 4051 o added EIM definition. 4053 o Clarified Mapping Type definitions. 4055 o PCP Client definition simplified to no longer obliquely and 4056 erroneously reference UPnP IGD. 4058 o Clarified using network-byte order. 4060 o Epoch time comparison now allows slight packet re-ordering. 4062 o Encourage that when new address is assigned (e.g., DHCP) that PCP 4063 as well as non-PCP mappings be cleaned up. 4065 o Simplified formatting of retransmission, but no normative change. 4067 o Clarified how server chooses ports and how Suggested External Port 4068 can gently influence that decision. 4070 o Described how PCP client can use PCP Client Address with a non- 4071 PCP-aware inner NAT (Section 8.1.) 4073 o Clarified 1024 octet length applies to UDP payload itself, and 4074 that error responses copy 1024 of UDP payload. 4076 o Lifetime for both MAP and PEER should not exceed the remaining IP 4077 address lifetime of the PCP client (if known) or half the typical 4078 IP address lifetime (if the remaining lifetime is unknown). 4080 o Lifetime section was (mistakenly) a subsection of the MAP section, 4081 but referenced by both MAP and PEER. It is now a top-level 4082 section. 4084 o Clarified that PEER cannot reduce lifetime beyond normal implicit 4085 mapping lifetime, no matter what. This restriction prevents 4086 malicious or accidental deletion of a quiescent connection that 4087 was not using PCP. 4089 o Clarified port re-use of PCP-created mappings should follow same 4090 port re-use algorithm used by the NAT for implicitly-created 4091 mappings (likely maximum segment lifetime). 4093 o Other minor text changes; consult diffs. 4095 B.3. Changes from draft-ietf-pcp-base-25 to -26 4097 o Changed "internal address and port" to "internal address, 4098 protocol, and port" in several more places. 4100 o Improved wording of THIRD_PARTY restrictions. 4102 o Bump version number from 1 to 2, to accommodate pre-RFC PCP client 4103 implementations without needing a heuristic. 4105 B.4. Changes from draft-ietf-pcp-base-24 to -25 4107 o Clarified the port used by the PCP server when sending unsolicited 4108 unicast ANNOUNCE. 4110 o Removed parenthetical comment implying ANNOUNCE was not a normal 4111 Opcode; it is a normal Opcode. 4113 o Explain that non-PCP-speaking host-based and network-based 4114 firewalls need to allow incoming connections for MAP to work. 4116 o For race condition with PREFER_FAILURE, clarified that it is the 4117 PCP client's responsibility to delete the mapping if the PCP 4118 client doesn't need the mapping. 4120 o For table, the NAT64 remote peer is IPv4 (was IPv6). 4122 o Added a Mapping Nonce field to both MAP and PEER requests and 4123 responses, to protect from off-path attackers spoofing the PCP 4124 server's IP address. 4126 o Security considerations: added 'PCP is secure against off-path 4127 attackers who can spoof the PCP server's IP address', because of 4128 the addition of the Mapping Nonce. 4130 o Removed reference to DS-Lite from Security Considerations, as part 4131 of the changes to THIRD_PARTY from IESG review. 4133 o Rapid Recovery is now a SHOULD implement. 4135 o Clarify behavior of PREFER_FAILURE with zeros in Suggested 4136 External Port or Address fields. 4138 o PCP server is now more robust and insistent about informing PCP 4139 client of state changes. 4141 o When PCP server sends Mapping Update to a specific PCP client, and 4142 gets an update for a particular mapping, it doesn't need to send 4143 reminders about that mapping any more. 4145 o THIRD_PARTY is now prohibited on subscriber PCP clients. 4147 B.5. Changes from draft-ietf-pcp-base-23 to -24 4149 o Explained common questions regarding PCP's design, such as lack of 4150 transction identifiers and its request/response semantics and 4151 operation (Protocol Design Note (Section 6)). 4153 o added MUST for all-zeros IPv6 and IPv4 address formats. 4155 o included field definitions for Opcode-specific information and PCP 4156 options under both Figure 2 and Figure 3. 4158 o adopted retransmission mechanism from DHCPv6. 4160 o 1024 message size limit described in PCP message restriction. 4162 o Explained PCP server list, with example of host with IPv4 and IPv6 4163 addresses having two PCP servers (one IPv4 PCP server for IPv4 4164 mappings and one IPv6 PCP server for IPv6 mappings). 4166 o mention PCP client needs to expect unsolicited PCP responses from 4167 previous incarnations of itself (on the same host) or of this host 4168 (using same IP address as another PCP client). 4170 o eliminated overuse of 'packet format' when it was 'opcode format'. 4172 o for IANA registries, added code points assignable via Standards 4173 Action (previously was just Specification Required). 4175 o Version negotiation, added explanation that retrying after 30 4176 minutes makes the protocol self-healing if the PCP server is 4177 upgraded. 4179 o Version negotiation now accomodates non-contiguous version 4180 numbers. 4182 o Tweaked definition of VERSION field (that "1" is for this version, 4183 but other values could of course appear in the future). 4185 o when receiving unsolicited ANNOUNCE, PCP client now waits random 4186 0-5 seconds. 4188 o Removed 'interworking function' from list of terminology because 4189 we no longer use the term in this document. 4191 o tightened definitions of 'PCP client' and 'PCP server'. 4193 o For 'Requested Lifetime' definitions, removed text requiring its 4194 value be 0 for not-yet-defined opcodes. 4196 o Removed some unnecessary text suggesting logging (is an 4197 implementation detail). 4199 o Added active-mode FTP as example protocol that can break with 4200 mappings to different IP addresses. 4202 o Clarified that if PCP request contains a Suggested External 4203 Address, the PCP server should try to create a mapping to that 4204 address even if other mappings already exist to a different 4205 external address. 4207 o Changed "internal address and port" to "internal address, 4208 protocol, and port" in several places. 4210 o Clarified which 96 bits are copied into error response. Clarified 4211 that only error responses are copied verbatim from request. 4213 o a single PCP server can control multiple NATs or multiple 4214 firewalls (Section 4). 4216 o Clarified that sending unsolicited multicast ANNOUNCE is not 4217 always available on all networks. 4219 o Clarified option length error example is when option length 4220 exceeds UDP length 4222 o Explained that an on-path attacker that can spoof packets can re- 4223 direct traffic to a host of their choosing. 4225 o Instead of saying IPv4-mapped addresses won't appear on the wire, 4226 say they aren't used for mappings. 4228 o THIRD_PARTY is useful for management device (e.g., in a network 4229 operations center). 4231 o Clarified PCP responses have fields updated as indicated with 'set 4232 by the server' from field definitions. 4234 o Disallow using MAP to the PCP ports themselves and encourage 4235 implementations have policy control for other ports. 4237 o Instead of 'idempotent', now says 'identical requests generate 4238 identical response'. 4240 o Described which Options are included when sending Mapping Update 4241 (unsolicited responses), Section 14.2. 4243 o Dropped [RFC2136] and [RFC3007] to informative references. 4245 o Updated from 'should' to 'SHOULD' in Section 17.1. 4247 o Described 'hairpin' in terminology section. 4249 B.6. Changes from draft-ietf-pcp-base-22 to -23 4251 o Instead of returning error NO_RESOURCES when requesting a MAP for 4252 all protocols or for all ports, return UNSUPP_PROTOCOL. 4254 o Clarify that PEER-created mappings are treated as if it was 4255 implicit dynamic outbound mapping (Section 12.3). 4257 o Point out that PEER-created mappings may be very short until bi- 4258 directional traffic is seen by the PCP-managed device. 4260 o Clairification that an existing implicit mapping (created e.g., by 4261 TCP SYN) can become managed by a MAP request (Section 11.3. 4263 o Clarified the ANNOUNCE Opcode is being defined in Section 14.1, 4264 and that the length of requests (as well as responses) is zero. 4266 o Clarify that ANNOUNCE has Lifetime=0 for requests and responses. 4268 o Clarify ANNOUNCE can be sent unicast by the client (to solicit a 4269 response), or can be multicasted (unsolicited) by the server. 4271 o Allow ANNOUNCE to be sent unicast by the server, to accomodate 4272 case where PCP server fails but knows the IP address of a PCP 4273 client (e.g., web portal). 4275 o Clarified ports used for unicast and multicast unsolicited 4276 ANNOUNCE. 4278 o Tweaked NO_RESOURCES handling, to just disallow *new* mappings. 4280 o State diagram is now non-normative, because it overly simplifies 4281 that implicit mappings become MAP (when they actually still retain 4282 their previous behavior when the MAP expires). 4284 o In section Section 15, clarified that PEER cannot delete or 4285 shorten any lifetime, and that MAP can only shorten or delete 4286 lifetimes of MAP-created mappings. 4288 o Clarified handling of MAP when mapping already exists (4 steps). 4290 o 2^32-1 4292 o Randomize retry interval (1.5-2.5), and maximum retry interval is 4293 now 1024 seconds (was 15 minutes). 4295 o Remove MUST be 0 for Reserved field when sending error responses 4296 for un-parseable message. 4298 o Whenever PCP client includes Suggested IP Address (in MAP or 4299 PEER), the PCP server should try to fulfill that request, even if 4300 creating a mapping on that IP address means the internal host will 4301 have mappings on different IP addresses and ports. 4303 o For NO_RESOURCES error, the PCP client can attempt to renew and 4304 attempt to delete mappings (as they can help shed load) -- it just 4305 can't try to create new ones. 4307 o Removed the overly simplistic normative text regarding honoring 4308 Suggested External Address from Section 10 in favor of the text in 4309 Section 11.3 which has significantly more detail. 4311 B.7. Changes from draft-ietf-pcp-base-21 to -22 4313 o Removed paragraph discussing multiple addresses on the same 4314 (physical) interface; those will work with PCP. 4316 o The FILTER Option's Prefix Length field redefined to simply be a 4317 count of the relevant bits (rather than 0-32 for IPv4-mapped 4318 addresses). 4320 o Point out NO_RESOURCES attack vector in security considerations. 4322 o Tighten up recommendation for client handling long Lifetimes, and 4323 moved from the MAP-specific section to the General PCP Processing 4324 section. Client should normalize to 24 hours maximum for success 4325 and 30 minute maximum for errors. 4327 B.8. Changes from draft-ietf-pcp-base-20 to -21 4329 o To delete all mappings using THIRD_PARTY, use the all-zeros IP 4330 address (rather than previous text which used length=0). 4332 o added normative text for what PCP server does when it receives 4333 all-zeros IP address in THIRD_PARTY option. 4335 o PREFER_FAILURE allowed for use by web portal. 4337 o clarifications to mandatory option processing. 4339 o cleanup and wordsmithing of the THIRD_PARTY text. 4341 B.9. Changes from draft-ietf-pcp-base-19 to -20 4343 o clarify if Options are included in responses. 4345 o clarify when External Address can be ignored by the PCP server / 4346 PCP-controlled device 4348 o added 'Transition from state M to state I is implementation 4349 dependent' to state diagram 4351 B.10. Changes from draft-ietf-pcp-base-18 to -19 4353 o Described race condition with MAP containing PREFER_FAILURE and 4354 Mapping Update. 4356 o Added state machine (Section 16.5). 4358 o Fully integrated Rapid Recovery, with a separate Opcode having its 4359 own processing description. 4361 o Clarified that due to Mapping Update, a single MAP or PEER request 4362 can receive multiple responses, each updating the previous 4363 request, and that the PCP client needs to handle MAP updates or 4364 PEER updates accordingly. 4366 B.11. Changes from draft-ietf-pcp-base-17 to -18 4368 o Removed UNPROCESSED option. Instead, unprocessed options are 4369 simply not included in responses. 4371 o Updated terminology section for Implicit/Explicit and Outbound/ 4372 Inbound. 4374 o PEER requests cannot delete or shorten the lifetime of a mapping. 4376 o Clarified that PCP clients only retransmit mapping requests for as 4377 long as they actually want the mapping. 4379 o Revised Epoch time calculations and explanation. 4381 o Renamed the announcement opcode from No-Op to ANNOUNCE. 4383 B.12. Changes from draft-ietf-pcp-base-16 to -17 4385 o suggest acquiring a mapping to the Discard port if there is a 4386 desire to show the user their external address (Section 11.6). 4388 o Added Restart Announcement. 4390 o Tweaked terminology. 4392 o Detailed how error responses are generated. 4394 B.13. Changes from draft-ietf-pcp-base-15 to -16 4396 o fixed mistake in PCP request format (had 32 bits of extraneous 4397 fields) 4399 o Allow MAP to request all ports (port=0) for a specific protocol 4400 (protocol!=0), for the same reason we added support for all ports 4401 (port=0) and all protocols (protocol=0) in -15 4403 o corrected text on Client Processing a Response related to 4404 receiving ADDRESS_MISMATCH error. 4406 o updated Epoch text. 4408 o Added text that MALFORMED_REQUEST is generated for MAP if Protocol 4409 is zero but Internal Port is non-zero. 4411 B.14. Changes from draft-ietf-pcp-base-14 to -15 4413 o Softened and removed text that was normatively explaining how PEER 4414 is implemented within a NAT. 4416 o Allow a MAP request for protocol=0, which means "all protocols". 4417 This can work for an IPv6 or IPv4 firewall. Its use with a NAPT 4418 is undefined. 4420 o combined SERVER_OVERLOADED and NO_RESOURCES into one error code, 4421 NO_RESOURCES. 4423 o SCTP mappings have to use same internal and suggested external 4424 ports, and have implied PREFER_FAILURE semantics. 4426 o Re-instated ADDRESS_MISMATCH error, which only checks the client 4427 address (not its port). 4429 B.15. Changes from draft-ietf-pcp-base-13 to -14 4431 o Moved discussion of socket operations for PCP source address into 4432 Implementation Considerations section. 4434 o Integrated numerous WGLC comments. 4436 o NPTv6 in scope. 4438 o Re-written security considerations section. Thanks, Margaret! 4440 o Reduced PEER4 and PEER6 Opcodes to just a single Opcode, PEER. 4442 o Reduced MAP4 and MAP6 Opcodes to just a single Opcode, MAP. 4444 o Rearranged the PEER packet formats to align with MAP. 4446 o Removed discussion of the "O" bit for Options, which was 4447 confusing. Now the text just discusses the most significant bit 4448 of the Option code which indicates mandatory/optional, so it is 4449 clearer the field is 8 bits. 4451 o The THIRD_PARTY Option from an unauthorized host generates 4452 UNSUPP_OPTION, so the PCP server doesn't disclose it knows how to 4453 process THIRD_PARTY Option. 4455 o Added table to show which fields of MAP or PEER need IPv6/IPv4 4456 addresses for IPv4 firewall, DS-Lite, NAT64, NAT44, etc. 4458 o Accommodate the server's Epoch going up or down, to better detect 4459 switching to a different PCP server. 4461 o Removed ADDRESS_MISMATCH; the server always includes its idea of 4462 the Client's IP Address and Port, and it's up to the client to 4463 detect a mismatch (and rectify it). 4465 B.16. Changes from draft-ietf-pcp-base-12 to -13 4467 o All addresses are 128 bits. IPv4 addresses are represented by 4468 IPv4-mapped IPv6 addresses (::FFFF/96) 4470 o PCP request header now includes PCP client's port (in addition to 4471 the client's IP address, which was in -12). 4473 o new ADDRESS_MISMATCH error. 4475 o removed PROCESSING_ERROR error, which was too similar to 4476 MALFORMED_REQUEST. 4478 o Tweaked text describing how PCP client deals with multiple PCP 4479 server addresses (Section 8.1) 4481 o clarified that when overloaded, the server can send 4482 SERVER_OVERLOADED (and drop requests) or simply drop requests. 4484 o Clarified how PCP client chooses MAP4 or MAP6, depending on the 4485 presence of its own IPv6 or IPv4 interfaces (Section 10). 4487 o compliant PCP server MUST support MAPx and PEERx, SHOULD support 4488 ability to disable support. 4490 o clarified that MAP-created mappings have no filtering, and PEER- 4491 created mappings have whatever filtering and mapping behavior is 4492 normal for that particular NAT / firewall. 4494 o Integrated WGLC feedback (small changes to abstract, definitions, 4495 and small edits throughout the document) 4497 o allow new Options to be defined with a specification (rather than 4498 standards action) 4500 B.17. Changes from draft-ietf-pcp-base-11 to -12 4502 o added implementation note that MAP and implicit dynamic mappings 4503 have independent mapping lifetimes. 4505 B.18. Changes from draft-ietf-pcp-base-10 to -11 4507 o clarified what can cause CANNOT_PROVIDE_EXTERNAL error to be 4508 generated. 4510 B.19. Changes from draft-ietf-pcp-base-09 to -10 4512 o Added External_AF field to PEER requests. Made PEER's Suggested 4513 External IP Address and Assigned External IP Address always be 128 4514 bits long. 4516 B.20. Changes from draft-ietf-pcp-base-08 to -09 4518 o Clarified in PEER Opcode introduction (Section 12) that they can 4519 also create mappings. 4521 o More clearly explained how PEER can re-create an implicit dynamic 4522 mapping, for purposes of rebuilding state to maintain an existing 4523 session (e.g., long-lived TCP connection to a server). 4525 o Added Suggested External IP Address to the PEER Opcodes, to allow 4526 more robust rebuilding of connections. Added related text to the 4527 PEER server processing section. 4529 o Removed text encouraging PCP server to statefully remember its 4530 mappings from Section 16.3.1, as it didn't belong there. Text in 4531 Security Considerations already encourages persistent storage. 4533 o More clearly discussed how PEER is used to re-establish TCP 4534 mapping state. Moved it to a new section, as well (it is now 4535 Section 10.4). 4537 o MAP errors now copy the Suggested Address (and port) fields to 4538 Assigned IP Address (and port), to allow PCP client to distinguish 4539 among many outstanding requests when using PREFER_FAILURE. 4541 o Mapping theft can also be mitigated by ensuring hosts can't re-use 4542 same IP address or port after state loss. 4544 o the UNPROCESSED option is renumbered to 0 (zero), which ensures no 4545 other option will be given 0 and be unable to be expressed by the 4546 UNPROCESSED option (due to its 0 padding). 4548 o created new Implementation Considerations section (Section 16) 4549 which discusses non-normative things that might be useful to 4550 implementers. Some new text is in here, and the Failure Scenarios 4551 text (Section 16.3) has been moved to here. 4553 o Tweaked wording of EDM NATs in Section 16.1 to clarify the problem 4554 occurs both inside->outside and outside->inside. 4556 o removed "Interference by Other Applications on Same Host" section 4557 from security considerations. 4559 o fixed zero/non-zero text in Section 15. 4561 o removed duplicate text saying MAP is allowed to delete an implicit 4562 dynamic mapping. It is still allowed to do that, but it didn't 4563 need to be said twice in the same paragraph. 4565 o Renamed error from UNAUTH_TARGET_ADDRESS to 4566 UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS. 4568 o for FILTER option, removed unnecessary detail on how FILTER would 4569 be bad for PEER, as it is only allowed for MAP anyway. 4571 o In Security Considerations, explain that PEER can create a mapping 4572 which makes its security considerations the same as MAP. 4574 B.21. Changes from draft-ietf-pcp-base-07 to -08 4576 o moved all MAP4-, MAP6-, and PEER-specific options into a single 4577 section. 4579 o discussed NAT port-overloading and its impact on MAP (new section 4580 Section 16.1), which allowed removing the IMPLICIT_MAPPING_EXISTS 4581 error. 4583 o eliminated NONEXIST_PEER error (which was returned if a PEER 4584 request was received without an implicit dynamic mapping already 4585 being created), and adjusted PEER so that it creates an implicit 4586 dynamic mapping. 4588 o Removed Deployment Scenarios section (which detailed NAT64, NAT44, 4589 Dual-Stack Lite, etc.). 4591 o Added Client's IP Address to PCP common header. This allows 4592 server to refuse a PCP request if there is a mismatch with the 4593 source IP address, such as when a non-PCP-aware NAT was on the 4594 path. This should reduce failure situations where PCP is deployed 4595 in conjunction with a non-PCP-aware NAT. This addition was 4596 consensus at IETF80. 4598 o Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that 4599 MALFORMED_REQUEST is for malformed requests (and not related to 4600 failed attempts to process the request). 4602 o Removed MISORDERED_OPTIONS. Consensus of IETF80. 4604 o SERVER_OVERLOADED is now a common PCP error (instead of specific 4605 to MAP). 4607 o Tweaked PCP retransmit/retry algorithm again, to allow more 4608 aggressive PCP discovery if an implementation wants to do that. 4610 o Version negotiation text tweaked to soften NAT-PMP reference, and 4611 more clearly explain exactly what UNSUPP_VERSION should return. 4613 o PCP now uses NAT-PMP's UDP port, 5351. There are no normative 4614 changes to NAT-PMP or PCP to allow them both to use the same port 4615 number. 4617 o New Appendix A to discuss NAT-PMP / PCP interworking. 4619 o improved pseudocode to be non-blocking. 4621 o clarified that PCP cannot delete a static mapping (i.e., a mapping 4622 created by CLI or other non-PCP means). 4624 o moved theft of mapping discussion from Epoch section to Security 4625 Considerations. 4627 B.22. Changes from draft-ietf-pcp-base-06 to -07 4629 o tightened up THIRD_PARTY security discussion. Removed "highest 4630 numbered address", and left it as simply "the CPE's IP address". 4632 o removed UNABLE_TO_DELETE_ALL error. 4634 o renumbered Opcodes 4636 o renumbered some error codes 4638 o assigned value to IMPLICIT_MAPPING_EXISTS. 4640 o UNPROCESSED can include arbitrary number of option codes. 4642 o Moved lifetime fields into common request/response headers 4643 o We've noticed we're having to repeatedly explain to people that 4644 the "requested port" is merely a hint, and the NAT gateway is free 4645 to ignore it. Changed name to "suggested port" to better convey 4646 this intention. 4648 o Added NAT-PMP transition section 4650 o Separated Internal Address, External Address, Remote Peer Address 4651 definition 4653 o Unified Mapping, Port Mapping, Port Forwarding definition 4655 o adjusted so DHCP configuration is non-normative. 4657 o mentioned PCP refreshes need to be sent over the same interface. 4659 o renamed the REMOTE_PEER_FILTER option to FILTER. 4661 o Clarified FILTER option to allow sending an ICMP error if policy 4662 allows. 4664 o for MAP, clarified that if the PCP client changed its IP address 4665 and still wants to receive traffic, it needs to send a new MAP 4666 request. 4668 o clarified that PEER requests have to be sent from same interface 4669 as the connection itself. 4671 o for MAP opcode, text now requires mapping be deleted when lifetime 4672 expires (per consensus on 8-Mar interim meeting) 4674 o PEER Opcode: better description of remote peer's IP address, 4675 specifically that it does not control or establish any filtering, 4676 and explaining why it is 'from the PCP client's perspective'. 4678 o Removed latent text allowing DMZ for 'all protocols' (protocol=0). 4679 Which wouldn't have been legal, anyway, as protocol 0 is assigned 4680 by IANA to HOPOPT (thanks to James Yu for catching that one). 4682 o clarified that PCP server only listens on its internal interface. 4684 o abandoned 'target' term and reverted to simplier 'internal' term. 4686 B.23. Changes from draft-ietf-pcp-base-05 to -06 4688 o Dual-Stack Lite: consensus was encapsulation mode. Included a 4689 suggestion that the B4 will need to proxy PCP-to-PCP and UPnP-to- 4690 PCP. 4692 o defined THIRD_PARTY Option to work with the PEER Opcode, too. 4693 This meant moving it to its own section, and having both MAP and 4694 PEER Opcodes reference that common section. 4696 o used "target" instead of "internal", in the hopes that clarifies 4697 internal address used by PCP itself (for sending its packets) 4698 versus the address for MAPpings. 4700 o Options are now required to be ordered in requests, and ordering 4701 has to be validated by the server. Intent is to ease server 4702 processing of mandatory-to-implement options. 4704 o Swapped Option values for the mandatory- and optional-to-process 4705 Options, so we can have a simple lowest..highest ordering. 4707 o added MISORDERED_OPTIONS error. 4709 o re-ordered some error messages to cause MALFORMED_REQUEST (which 4710 is PCP's most general error response) to be error 1, instead of 4711 buried in the middle of the error numbers. 4713 o clarified that, after successfully using a PCP server, that PCP 4714 server is declared to be non-responsive after 5 failed 4715 retransmissions. 4717 o tightened up text (which was inaccurate) about how long general 4718 PCP processing is to delay when receiving an error and if it 4719 should honor Opcode-specific error lifetime. Useful for MAP 4720 errors which have an error lifetime. (This all feels awkward to 4721 have only some errors with a lifetime.) 4723 o Added better discussion of multiple interfaces, including 4724 highlighting Wi-Fi+Ethernet. Added discussion of using IPv6 4725 Privacy Addresses and RFC1918 as source addresses for PCP 4726 requests. This should finish the section on multi-interface 4727 issues. 4729 o added some text about why server might send SERVER_OVERLOADED, or 4730 might simply discard packets. 4732 o Dis-allow internal-port=0, which means we dis-allow using PCP as a 4733 DMZ-like function. Instead, ports have to be mapped individually. 4735 o Text describing server's processing of PEER is tightened up. 4737 o Server's processing of PEER now says it is implementation-specific 4738 if a PCP server continues to allow the mapping to exist after a 4739 PEER message. Client's processing of PEER says that if client 4740 wants mapping to continue to exist, client has to continue to send 4741 recurring PEER messages. 4743 B.24. Changes from draft-ietf-pcp-base-04 to -05 4745 o tweaked PCP common header packet layout. 4747 o Re-added port=0 (all ports). 4749 o minimum size is 12 octets (missed that change in -04). 4751 o removed Lifetime from PCP common header. 4753 o for MAP error responses, the lifetime indicates how long the 4754 server wants the client to avoid retrying the request. 4756 o More clearly indicated which fields are filled by the server on 4757 success responses and error responses. 4759 o Removed UPnP interworking section from this document. It will 4760 appear in [I-D.ietf-pcp-upnp-igd-interworking]. 4762 B.25. Changes from draft-ietf-pcp-base-03 to -04 4764 o "Pinhole" and "PIN" changed to "mapping" and "MAP". 4766 o Reduced from four MAP Opcodes to two. This was done by implicitly 4767 using the address family of the PCP message itself. 4769 o New option THIRD_PARTY, to more carefully split out the case where 4770 a mapping is created to a different host within the home. 4772 o Integrated a lot of editorial changes from Stuart and Francis. 4774 o Removed nested NAT text into another document, including the IANA- 4775 registered IP addresses for the PCP server. 4777 o Removed suggestion (MAY) that PCP server reserve UDP when it maps 4778 TCP. Nobody seems to need that. 4780 o Clearly added NAT and NAPT, such as in residential NATs, as within 4781 scope for PCP. 4783 o HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE 4785 o Added 'Lifetime' field to the common PCP header, which replaces 4786 the functions of the 'temporary' and 'permanent' error types of 4787 the previous version. 4789 o Allow arbitrary Options to be included in PCP response, so that 4790 PCP server can indicate un-supported PCP Options. Satisfies PCP 4791 Issue #19 4793 o Reduced scope to only deal with mapping protocols that have port 4794 numbers. 4796 o Reduced scope to not support DMZ-style forwarding. 4798 o Clarified version negotiation. 4800 B.26. Changes from draft-ietf-pcp-base-02 to -03 4802 o Adjusted abstract and introduction to make it clear PCP is 4803 intended to forward ports and intended to reduce application 4804 keepalives. 4806 o First bit in PCP common header is set. This allows DTLS and non- 4807 DTLS to be multiplexed on same port, should a future update to 4808 this specification add DTLS support. 4810 o Moved subscriber identity from common PCP section to MAP* section. 4812 o made clearer that PCP client can reduce mapping lifetime if it 4813 wishes. 4815 o Added discussion of host running a server, client, or symmetric 4816 client+server. 4818 o Introduced PEER4 and PEER6 Opcodes. 4820 o Removed REMOTE_PEER Option, as its function has been replaced by 4821 the new PEER Opcodes. 4823 o IANA assigned port 44323 to PCP. 4825 o Removed AMBIGUOUS error code, which is no longer needed. 4827 B.27. Changes from draft-ietf-pcp-base-01 to -02 4829 o more error codes 4831 o PCP client source port number should be random 4833 o PCP message minimum 8 octets, maximum 1024 octets. 4835 o tweaked a lot of text in section 7.4, "Opcode-Specific Server 4836 Operation". 4838 o opening a mapping also allows ICMP messages associated with that 4839 mapping. 4841 o PREFER_FAILURE value changed to the mandatory-to-process range. 4843 o added text recommending applications that are crashing obtain 4844 short lifetimes, to avoid consuming subscriber's port quota. 4846 B.28. Changes from draft-ietf-pcp-base-00 to -01 4848 o Significant document reorganization, primarily to split base PCP 4849 operation from Opcode operation. 4851 o packet format changed to move 'protocol' outside of PCP common 4852 header and into the MAP* opcodes 4854 o Renamed Informational Elements (IE) to Options. 4856 o Added REMOTE_PEER (for disambiguation with dynamic ports), 4857 REMOTE_PEER_FILTER (for simple packet filtering), and 4858 PREFER_FAILURE (to optimize UPnP IGDv1 interworking) options. 4860 o Is NAT or router behind B4 in scope? 4862 o PCP option MAY be included in a request, in which case it MUST 4863 appear in a response. It MUST NOT appear in a response if it was 4864 not in the request. 4866 o Result code most significant bit now indicates permanent/temporary 4867 error 4869 o PCP Options are split into mandatory-to-process ("P" bit), and 4870 into Specification Required and Private Use. 4872 o Epoch discussion simplified. 4874 Authors' Addresses 4876 Dan Wing (editor) 4877 Cisco Systems, Inc. 4878 170 West Tasman Drive 4879 San Jose, California 95134 4880 USA 4882 Email: dwing@cisco.com 4883 Stuart Cheshire 4884 Apple Inc. 4885 1 Infinite Loop 4886 Cupertino, California 95014 4887 USA 4889 Phone: +1 408 974 3207 4890 Email: cheshire@apple.com 4892 Mohamed Boucadair 4893 France Telecom 4894 Rennes, 35000 4895 France 4897 Email: mohamed.boucadair@orange.com 4899 Reinaldo Penno 4900 Cisco Systems, Inc. 4901 170 West Tasman Drive 4902 San Jose, California 95134 4903 USA 4905 Email: repenno@cisco.com 4907 Paul Selkirk 4908 Internet Systems Consortium 4909 950 Charter Street 4910 Redwood City, California 94063 4911 USA 4913 Email: pselkirk@isc.org