idnits 2.17.1 draft-ietf-pcp-base-29.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 1493 has weird spacing: '...nternal exter...' -- The document date (November 7, 2012) is 4150 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-07 == 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: May 11, 2013 Apple 6 M. Boucadair 7 France Telecom 8 R. Penno 9 Cisco 10 P. Selkirk 11 ISC 12 November 7, 2012 14 Port Control Protocol (PCP) 15 draft-ietf-pcp-base-29 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 May 11, 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 . . . . . . . . . . . . . . . . . . 77 122 17.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 77 123 17.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 78 124 18. Security Considerations . . . . . . . . . . . . . . . . . . . 78 125 18.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 78 126 18.1.1. Attacks Considered . . . . . . . . . . . . . . . . . 79 127 18.1.2. Deployment Examples Supporting the Simple Threat 128 Model . . . . . . . . . . . . . . . . . . . . . . . . 80 129 18.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 80 130 18.3. Residual Threats . . . . . . . . . . . . . . . . . . . . 81 131 18.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 81 132 18.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 81 133 18.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 81 134 18.3.4. Attacks Against Server Discovery . . . . . . . . . . 82 135 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 136 19.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 82 137 19.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 82 138 19.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . 82 139 19.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 83 140 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 141 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 142 21.1. Normative References . . . . . . . . . . . . . . . . . . 84 143 21.2. Informative References . . . . . . . . . . . . . . . . . 84 145 Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . 87 146 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 87 147 B.1. Changes from draft-ietf-pcp-base-28 to -29 . . . . . . . 88 148 B.2. Changes from draft-ietf-pcp-base-27 to -28 . . . . . . . 88 149 B.3. Changes from draft-ietf-pcp-base-26 to -27 . . . . . . . 88 150 B.4. Changes from draft-ietf-pcp-base-25 to -26 . . . . . . . 90 151 B.5. Changes from draft-ietf-pcp-base-24 to -25 . . . . . . . 90 152 B.6. Changes from draft-ietf-pcp-base-23 to -24 . . . . . . . 91 153 B.7. Changes from draft-ietf-pcp-base-22 to -23 . . . . . . . 93 154 B.8. Changes from draft-ietf-pcp-base-21 to -22 . . . . . . . 95 155 B.9. Changes from draft-ietf-pcp-base-20 to -21 . . . . . . . 95 156 B.10. Changes from draft-ietf-pcp-base-19 to -20 . . . . . . . 95 157 B.11. Changes from draft-ietf-pcp-base-18 to -19 . . . . . . . 95 158 B.12. Changes from draft-ietf-pcp-base-17 to -18 . . . . . . . 96 159 B.13. Changes from draft-ietf-pcp-base-16 to -17 . . . . . . . 96 160 B.14. Changes from draft-ietf-pcp-base-15 to -16 . . . . . . . 96 161 B.15. Changes from draft-ietf-pcp-base-14 to -15 . . . . . . . 97 162 B.16. Changes from draft-ietf-pcp-base-13 to -14 . . . . . . . 97 163 B.17. Changes from draft-ietf-pcp-base-12 to -13 . . . . . . . 98 164 B.18. Changes from draft-ietf-pcp-base-11 to -12 . . . . . . . 99 165 B.19. Changes from draft-ietf-pcp-base-10 to -11 . . . . . . . 99 166 B.20. Changes from draft-ietf-pcp-base-09 to -10 . . . . . . . 99 167 B.21. Changes from draft-ietf-pcp-base-08 to -09 . . . . . . . 99 168 B.22. Changes from draft-ietf-pcp-base-07 to -08 . . . . . . . 100 169 B.23. Changes from draft-ietf-pcp-base-06 to -07 . . . . . . . 101 170 B.24. Changes from draft-ietf-pcp-base-05 to -06 . . . . . . . 102 171 B.25. Changes from draft-ietf-pcp-base-04 to -05 . . . . . . . 104 172 B.26. Changes from draft-ietf-pcp-base-03 to -04 . . . . . . . 104 173 B.27. Changes from draft-ietf-pcp-base-02 to -03 . . . . . . . 105 174 B.28. Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . 105 175 B.29. Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . 106 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 178 1. Introduction 180 The Port Control Protocol (PCP) provides a mechanism to control how 181 incoming packets are forwarded by upstream devices such as Network 182 Address Translator IPv6/IPv4 (NAT64), Network Address Translator 183 IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to 184 reduce application keepalive traffic. PCP is designed to be 185 implemented in the context of Carrier-Grade NATs (CGNs), small NATs 186 (e.g., residential NATs), as well as with dual-stack and IPv6-only 187 Customer Premises Equipment (CPE) routers, and all of the currently- 188 known transition scenarios towards IPv6-only CPE routers. PCP allows 189 hosts to operate servers for a long time (e.g., a network-attached 190 home security camera) or a short time (e.g., while playing a game or 191 on a phone call) when behind a NAT device, including when behind a 192 CGN operated by their Internet service provider or an IPv6 firewall 193 integrated in their CPE router. 195 PCP allows applications to create mappings from an external IP 196 address, protocol, and port to an internal IP address, protocol, and 197 port. These mappings are required for successful inbound 198 communications destined to machines located behind a NAT or a 199 firewall. 201 After creating a mapping for incoming connections, it is necessary to 202 inform remote computers about the IP address, protocol, and port for 203 the incoming connection. This is usually done in an application- 204 specific manner. For example, a computer game might use a rendezvous 205 server specific to that game (or specific to that game developer), a 206 SIP phone would use a SIP proxy, and a client using DNS-Based Service 207 Discovery [I-D.cheshire-dnsext-dns-sd] would use DNS Update [RFC2136] 208 [RFC3007]. PCP does not provide this rendezvous function. The 209 rendezvous function may support IPv4, IPv6, or both. Depending on 210 that support and the application's support of IPv4 or IPv6, the PCP 211 client may need an IPv4 mapping, an IPv6 mapping, or both. 213 Many NAT-friendly applications send frequent application-level 214 messages to ensure their session will not be timed out by a NAT. 215 These are commonly called "NAT keepalive" messages, even though they 216 are not sent to the NAT itself (rather, they are sent 'through' the 217 NAT). These applications can reduce the frequency of such NAT 218 keepalive messages by using PCP to learn (and influence) the NAT 219 mapping lifetime. This helps reduce bandwidth on the subscriber's 220 access network, traffic to the server, and battery consumption on 221 mobile devices. 223 Many NATs and firewalls include Application Layer Gateways (ALGs) to 224 create mappings for applications that establish additional streams or 225 accept incoming connections. ALGs incorporated into NATs may also 226 modify the application payload. Industry experience has shown that 227 these ALGs are detrimental to protocol evolution. PCP allows an 228 application to create its own mappings in NATs and firewalls, 229 reducing the incentive to deploy ALGs in NATs and firewalls. 231 2. Scope 233 2.1. Deployment Scenarios 235 PCP can be used in various deployment scenarios, including: 237 o Basic NAT [RFC3022] 239 o Network Address and Port Translation [RFC3022], such as commonly 240 deployed in residential NAT devices 242 o Carrier-Grade NAT [I-D.ietf-behave-lsn-requirements] 244 o Dual-Stack Lite (DS-Lite) [RFC6333] 246 o Layer-2 Aware NAT [I-D.miles-behave-l2nat] 248 o Dual-Stack Extra Lite [RFC6619] 250 o NAT64, both Stateless [RFC6145] and Stateful [RFC6146] 252 o IPv4 and IPv6 simple firewall control [RFC6092] 254 o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] 256 2.2. Supported Protocols 258 The PCP Opcodes defined in this document are designed to support 259 transport-layer protocols that use a 16-bit port number (e.g., TCP, 260 UDP, SCTP [RFC4960], DCCP [RFC4340]). Protocols that do not use a 261 port number (e.g., RSVP, IPsec ESP [RFC4303], ICMP, ICMPv6) are 262 supported for IPv4 firewall, IPv6 firewall, and NPTv6 functions, but 263 are out of scope for any NAT functions. 265 2.3. Single-homed Customer Premises Network 267 PCP assumes a single-homed IP address model. That is, for a given IP 268 address of a host, only one default route exists to reach other hosts 269 on the Internet from that source IP address. This is important 270 because after a PCP mapping is created and an inbound packet (e.g., 271 TCP SYN) is rewritten and delivered to a host, the outbound response 272 (e.g., TCP SYNACK) has to go through the same (reverse) path so it 273 passes through the same NAT to have the necessary inverse rewrite 274 performed. This restriction exists because otherwise there would 275 need to be a PCP-enabled NAT for every egress (because the host could 276 not reliably determine which egress path packets would take) and the 277 client would need to be able to reliably make the same internal/ 278 external mapping in every NAT gateway, which in general is not 279 possible (because the other NATs might already have the necessary 280 External Port mapped to another host). 282 3. Terminology 284 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 285 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 286 document are to be interpreted as described in "Key words for use in 287 RFCs to Indicate Requirement Levels" [RFC2119]. 289 Internal Host: 290 A host served by a NAT gateway, or protected by a firewall. This 291 is the host that will receive incoming traffic resulting from a 292 PCP mapping request, or the host that initiated an implicit 293 dynamic outbound mapping (e.g., by sending a TCP SYN) across a 294 firewall or a NAT. 296 Remote Peer Host: 297 A host with which an Internal Host is communicating. This can 298 include another Internal Host (or even the same Internal Host); if 299 a NAT is involved, the NAT would need to hairpin the traffic 300 [RFC4787]. 302 Internal Address: 303 The address of an Internal Host served by a NAT gateway or 304 protected by a firewall. 306 External Address: 307 The address of an Internal Host as seen by other Remote Peers on 308 the Internet with which the Internal Host is communicating, after 309 translation by any NAT gateways on the path. An External Address 310 is generally a public routable (i.e., non-private) address. In 311 the case of an Internal Host protected by a pure firewall, with no 312 address translation on the path, its External Address is the same 313 as its Internal Address. 315 Endpoint-Dependent Mapping (EDM): A term applied to NAT operation 316 where an implicit mapping created by outgoing traffic (e.g., TCP 317 SYN) from a single Internal Address, Protocol, and Port to 318 different Remote Peers and Ports may be assigned different 319 External Ports, and a subsequent PCP mapping request for that 320 Internal Address, Protocol, and Port may be assigned yet another 321 different External Port. This term encompasses both Address- 322 Dependent Mapping and Address and Port-Dependent Mapping 323 [RFC4787]. 325 Endpoint-Independent Mapping (EIM): A term applied to NAT operation 326 where all mappings from a single Internal Address, Protocol, and 327 Port to different Remote Peers and Ports are all assigned the same 328 External Address and Port. 330 Remote Peer Address: 331 The address of a Remote Peer, as seen by the Internal Host. A 332 Remote Address is generally a publicly routable address. In the 333 case of a Remote Peer that is itself served by a NAT gateway, the 334 Remote Address may in fact be the Remote Peer's External Address, 335 but since this remote translation is generally invisible to 336 software running on the Internal Host, the distinction can safely 337 be ignored for the purposes of this document. 339 Third Party: 340 In the common case, an Internal Host manages its own Mappings 341 using PCP requests, and the Internal Address of those Mappings is 342 the same as the source IP address of the PCP request packet. 344 In the case where one device is managing Mappings on behalf of 345 some other device that does not implement PCP, the presence of the 346 THIRD_PARTY Option in the MAP request signifies that the specified 347 address, rather than the source IP address of the PCP request 348 packet, should be used as the Internal Address for the Mapping. 350 Mapping, Port Mapping, Port Forwarding: 351 A NAT mapping creates a relationship between an internal IP 352 address, protocol, and port, and an external IP address, protocol, 353 and port. More specifically, it creates a translation rule where 354 packets destined to the external IP and port are translated to the 355 internal IP address, protocol, and port, and vice versa. In the 356 case of a pure firewall, the "Mapping" is the identity function, 357 translating an internal IP address, protocol, and port number to 358 the same external IP address, protocol, and port number. Firewall 359 filtering, applied in addition to that identity mapping function, 360 is separate from the mapping itself. 362 Mapping Types: 363 There are three dimensions to classifying mapping types: how they 364 are created (implicitly/explicitly), their primary purpose 365 (outbound/inbound), and how they are deleted (dynamic/static). 366 Implicit mappings are created as a side-effect of some other 367 operation; explicit mappings are created by a mechanism explicitly 368 dealing with mappings. Outbound mappings exist primarily to 369 facilitate outbound communication; inbound mappings exist 370 primarily to facilitate inbound communication. Dynamic mappings 371 are deleted when their lifetime expires, or though other protocol 372 action; static mappings are permanent until the user chooses to 373 delete them. 375 * Implicit dynamic mappings are created implicitly as a side- 376 effect of traffic such as an outgoing TCP SYN or outgoing UDP 377 packet. Such packets were not originally designed explicitly 378 for creating NAT (or firewall) state, but they can have that 379 effect when they pass through a NAT (or firewall) device. 380 Implicit dynamic mappings usually have a finite lifetime, 381 though this lifetime is generally not known to the client using 382 them. 384 * Explicit dynamic mappings are created as a result of explicit 385 PCP MAP and PEER requests. Like a DHCP address lease, explicit 386 dynamic mappings have finite lifetime, and this lifetime is 387 communicated to the client. As with a DHCP address lease, if 388 the client wants a mapping to persist the client must prove 389 that it is still present by periodically renewing the mapping 390 to prevent it from expiring. If a PCP client goes away, then 391 any mappings it created will be automatically cleaned up when 392 they expire. 394 * Explicit static mappings are created by manual configuration 395 (e.g., via command-line interface or other user interface) and 396 persist until the user changes that manual configuration. 398 Both implicit and explicit dynamic mappings are dynamic in the 399 sense that they are created on demand, as requested (implicitly or 400 explicitly) by the Internal Host, and have a lifetime. After the 401 lifetime, the mapping is deleted unless the lifetime is extended 402 by action by the Internal Host (e.g., sending more traffic or 403 sending another PCP request). 405 Static mappings are by their nature always explicit. Static 406 mappings differ from explicit dynamic mappings in that their 407 lifetime is effectively infinite (they exist until manually 408 removed) but otherwise they behave exactly the same as explicit 409 MAP mappings. 411 While all mappings are by necessity bidirectional (most Internet 412 communication requires information to flow in both directions for 413 successful operation) when talking about mappings it can be 414 helpful to identify them loosely according to their 'primary' 415 purpose. 417 * Outbound mappings exist primarily to enable outbound 418 communication. For example, when a host calls connect() to 419 make an outbound connection, a NAT gateway will create an 420 implicit dynamic outbound mapping to facilitate that outbound 421 communication. 423 * Inbound mappings exist primarily to enable listening servers to 424 receive inbound connections. Generally, when a client calls 425 listen() to listen for inbound connections, a NAT gateway will 426 not implicitly create any mapping to facilitate that inbound 427 communication. A PCP MAP request can be used explicitly to 428 create a dynamic inbound mapping to enable the desired inbound 429 communication. 431 Explicit static (manual) mappings and explicit dynamic (MAP) 432 mappings both allow Internal Hosts to receive inbound traffic that 433 is not in direct response to any immediately preceding outbound 434 communication (i.e., to allow Internal Hosts to operate a "server" 435 that is accessible to other hosts on the Internet). 437 PCP Client: 438 A PCP software instance responsible for issuing PCP requests to a 439 PCP server. Several independent PCP Clients can exist on the same 440 host. Several PCP Clients can be located in the same local 441 network. A PCP Client can issue PCP requests on behalf of a third 442 party device for which it is authorized to do so. An interworking 443 function from Universal Plug and Play Internet Gateway Device 444 (UPnP IGDv1 [IGDv1]) to PCP is another example of a PCP Client. A 445 PCP server in a NAT gateway that is itself a client of another NAT 446 gateway (nested NAT) may itself act as a PCP client to the 447 upstream NAT. 449 PCP-Controlled Device: 450 A NAT or firewall that controls or rewrites packet flows between 451 internal hosts and remote peer hosts. PCP manages the Mappings on 452 this device. 454 PCP Server: 455 A PCP software instance that resides on the NAT or firewall that 456 receives PCP requests from the PCP client and creates appropriate 457 state in response to that request. 459 Subscriber: 460 The unit of billing for a commercial ISP. A subscriber may have a 461 single IP address from the commercial ISP (which can be shared 462 among multiple hosts using a NAT gateway, thereby making them 463 appear to be a single host to the ISP) or may have multiple IP 464 addresses provided by the commercial ISP. In either case, the IP 465 address or addresses provided by the ISP may themselves be further 466 translated by a Carrier-Grade NAT (CGN) operated by the ISP. 468 4. Relationship between PCP Server and its NAT/firewall 470 The PCP server receives and responds to PCP requests. The PCP server 471 functionality is typically a capability of a NAT or firewall device, 472 as shown in Figure 1. It is also possible for the PCP functionality 473 to be provided by some other device, which communicates with the 474 actual NAT(s) or firewall(s) via some other proprietary mechanism, as 475 long as from the PCP client's perspective such split operation is 476 indistinguishable from the integrated case. 478 +-----------------+ 479 +------------+ | NAT or firewall | 480 | PCP client |--+ with +--- 481 +------------+ | PCP server | 482 +-----------------+ 484 Figure 1: PCP-Enabled NAT or Firewall 486 A NAT or firewall device, between the PCP client and the Internet, 487 might implement simple or advanced firewall functionality. This may 488 be a side-effect of the technology implemented by the device (e.g., a 489 network address and port translator, by virtue of its port rewriting, 490 normally requires connections to be initiated from an inside host 491 towards the Internet), or this might be an explicit firewall policy 492 to deny unsolicited traffic from the Internet. Some firewall devices 493 deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to 494 most ports) but allow certain other unsolicited traffic from the 495 Internet (e.g., UDP port 500 and IPsec ESP) [RFC6092]. Such default 496 filtering (or lack thereof) is out of scope of PCP itself. If a 497 client device wants to receive traffic and supports PCP, and does not 498 possess prior knowledge of such default filtering policy, it SHOULD 499 use PCP to request the necessary mappings to receive the desired 500 traffic. 502 5. Note on Fixed-Size Addresses 504 For simplicity in building and parsing request and response packets, 505 PCP always uses fixed-size 128-bit IP address fields for both IPv6 506 addresses and IPv4 addresses. 508 When the address field holds an IPv6 address, the fixed-size 128-bit 509 IP address field holds the IPv6 address stored as-is. 511 When the address field holds an IPv4 address, IPv4-mapped IPv6 512 addresses [RFC4291] are used (::ffff:0:0/96). This has the first 80 513 bits set to zero and the next 16 set to one, while its last 32 bits 514 are filled with the IPv4 address. This is unambiguously 515 distinguishable from a native IPv6 address, because an IPv4-mapped 516 IPv6 address [RFC4291] would not be valid for a mapping. 518 When checking for an IPv4-mapped IPv6 address, all of the first 96 519 bits MUST be checked for the pattern -- it is not sufficient to check 520 for ones in bits 81-96. 522 The all-zeroes IPv6 address MUST be expressed by filling the fixed- 523 size 128-bit IP address field with all zeroes (::). 525 The all-zeroes IPv4 address MUST be expressed by 80 bits of zeros, 16 526 bits of ones, and 32 bits of zeros (::ffff:0:0). 528 6. Protocol Design Note 530 PCP can be viewed as a request/response protocol, much like many 531 other UDP-based request/response protocols, and can be implemented 532 perfectly well as such. It can also be viewed as what might be 533 called a hint/notification protocol, and this observation can help 534 simplify implementations. 536 Rather than viewing the message streams between PCP client and PCP 537 server as following a strict request/response pattern, where every 538 response is associated with exactly one request, the message flows 539 can be viewed as two somewhat independent streams carrying 540 information in opposite directions: 542 o A stream of hints flowing from PCP client to PCP server, where the 543 client indicates to the server what it would like the state of its 544 mappings to be, and 546 o A stream of notifications flowing from PCP server to PCP client, 547 where the server informs the clients what the state of its 548 mappings actually is. 550 To an extent, some of this approach is required anyway in a UDP-based 551 request/response protocol, since UDP packets can be lost, duplicated, 552 or reordered. 554 In this view of the protocol, the client transmits hints to the 555 server at various intervals signaling its desires, and the server 556 transmits notifications to the client signaling the actual state of 557 its mappings. These two message flows are loosely correlated in that 558 a client request (hint) usually elicits a server response 559 (notification), but only loosely, in that a client request may result 560 in no server response (in the case of packet loss) and a server 561 response may be generated gratuitously without an immediately 562 preceding client request (in the case where server configuration 563 change, e.g. change of external IP address on a NAT gateway, results 564 in a change of mapping state). 566 The exact times that client requests are sent are influenced by a 567 client timing state machine taking into account whether (i) the 568 client has not yet received a response from the server for a prior 569 request (retransmission), or (ii) the client has previously received 570 a response from the server saying how long the indicated mapping 571 would remain active (renewal). This design philosophy is the reason 572 why PCP's retransmissions and renewals are exactly the same packet on 573 the wire. Typically, retransmissions are sent with exponentially 574 increasing intervals as the client waits for the server to respond, 575 whereas renewals are sent with exponentially decreasing intervals as 576 the expiry time approaches, but from the server's point of view both 577 packets are identical, and both signal the client's desire that the 578 stated mapping exist or continue to exist. 580 A PCP server usually sends responses as a direct result of client 581 requests, but not always. For example, if a server is too overloaded 582 to respond, it is allowed to silently ignore a request message and 583 let the client retransmit. Also, if external factors cause a NAT 584 gateway or firewall's configuration to change, then the PCP server 585 can send unsolicited responses to clients informing them of the new 586 state of their mappings. Such reconfigurations are expected to be 587 rare, because of the disruption they can cause to clients, but should 588 they happen, PCP provides a way for servers to communicate the new 589 state to clients promptly, without having to wait for the next 590 periodic renewal request. 592 This design goal helps explain why PCP request and response messages 593 have no transaction ID, because such a transaction ID is unnecessary, 594 and would unnecessarily limit the protocol and unnecessarily 595 complicate implementations. A PCP server response (i.e. 596 notification) is self-describing and complete. It communicates the 597 internal and external addresses, protocol, and ports for a mapping, 598 and its remaining lifetime. If the client does in fact currently 599 want such a mapping to exist then it can identify the mapping in 600 question from the internal address, protocol, and port, and update 601 its state to reflect the current external address and port, and 602 remaining lifetime. If a client does not currently want such a 603 mapping to exist then it can safely ignore the message. No client 604 action is required for unexpected mapping notifications. In today's 605 world a NAT gateway can have a static mapping, and the client device 606 has no explicit knowledge of this, and no way to change the fact. 607 Also, in today's world a client device can be connected directly to 608 the public Internet, with a globally-routable IP address, and in this 609 case it effectively has "mappings" for all of its listening ports. 610 Such a device has to be responsible for its own security, and cannot 611 rely on assuming that some other network device will be blocking all 612 incoming packets. 614 7. Common Request and Response Header Format 616 All PCP messages are sent over UDP, with a maximum UDP payload length 617 of 1100 octets. The PCP messages contain a request or response 618 header containing an Opcode, any relevant Opcode-specific 619 information, and zero or more Options. All numeric quantities larger 620 than a single octet (e.g. Result codes, Lifetimes, Epoch times, 621 etc.) are represented in conventional IETF network order, i.e. most 622 significant octet first. Non-numeric quantities are represented 623 as-is on all platforms, with no byte swapping (e.g. IP addresses and 624 ports are placed in PCP messages using the same representation as 625 when placed in IP or TCP headers). 627 The packet layout for the common header, and operation of the PCP 628 client and PCP server, are described in the following sections. The 629 information in this section applies to all Opcodes. Behavior of the 630 Opcodes defined in this document is described in Section 11 and 631 Section 12. 633 7.1. Request Header 635 All requests have the following format: 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Version = 2 |R| Opcode | Reserved | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Requested Lifetime (32 bits) | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 | PCP Client's IP Address (128 bits) | 646 | | 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 : : 650 : (optional) Opcode-specific information : 651 : : 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 : : 654 : (optional) PCP Options : 655 : : 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 2: Common Request Packet Format 660 These fields are described below: 662 Version: This document specifies protocol version 2. PCP clients 663 and servers compliant with this document use the value 2. This 664 field is used for version negotiation as described in Section 9. 666 R: Indicates Request (0) or Response (1). 668 Opcode: A seven-bit value specifying the operation to be performed. 669 Opcodes are defined in Section 11 and Section 12. 671 Reserved: 16 reserved bits. MUST be zero on transmission and MUST 672 be ignored on reception. 674 Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging 675 from 0 to 2^32-1 seconds. This is used by the MAP and PEER 676 Opcodes defined in this document for their requested lifetime. 678 PCP Client's IP Address: The source IPv4 or IPv6 address in the IP 679 header used by the PCP client when sending this PCP request. IPv4 680 is represented using an IPv4-mapped IPv6 address. This is used to 681 detect an unexpected NAT on the path between the PCP client and 682 the PCP-controlled NAT or firewall device. See Section 8.1 684 Opcode-specific information: Payload data for this Opcode. The 685 length of this data is determined by the Opcode definition. 687 PCP Options: Zero, one, or more Options that are legal for both a 688 PCP request and for this Opcode. See Section 7.3. 690 7.2. Response Header 692 All responses have the following format: 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Version = 2 |R| Opcode | Reserved | Result Code | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Lifetime (32 bits) | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Epoch Time (32 bits) | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | | 704 | Reserved (96 bits) | 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 : : 708 : (optional) Opcode-specific response data : 709 : : 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 : (optional) Options : 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 3: Common Response Packet Format 716 These fields are described below: 718 Version: Responses from servers compliant with this specification 719 MUST use version 2. This is set by the server. 721 R: Indicates Request (0) or Response (1). All Responses MUST use 1. 722 This is set by the server. 724 Opcode: The 7-bit Opcode value. The server copies this value from 725 the request. 727 Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when 728 received. This is set by the server. 730 Result Code: The result code for this response. See Section 7.4 for 731 values. This is set by the server. 733 Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 734 2^32-1 seconds. On an error response, this indicates how long 735 clients should assume they'll get the same error response from 736 that PCP server if they repeat the same request. On a success 737 response for the PCP Opcodes that create a mapping (MAP and PEER), 738 the Lifetime field indicates the lifetime for this mapping. This 739 is set by the server. 741 Epoch Time: The server's Epoch time value. See Section 8.5 for 742 discussion. This value is set by the server, in both success and 743 error responses. 745 Reserved: 96 reserved bits. For requests that were successfully 746 parsed, this MUST be sent as 0, MUST be ignored when received. 747 This is set by the server. For requests that were not 748 successfully parsed, the server copies the last 96 bits of the PCP 749 Client's IP Address field from the request message into this 750 corresponding 96 bit field of the response. 752 Opcode-specific information: Payload data for this Opcode. The 753 length of this data is determined by the Opcode definition. 755 PCP Options: Zero, one, or more Options that are legal for both a 756 PCP response and for this Opcode. See Section 7.3. 758 7.3. Options 760 A PCP Opcode can be extended with one or more Options. Options can 761 be used in requests and responses. The design decisions in this 762 specification about whether to include a given piece of information 763 in the base Opcode format or in an Option were an engineering trade- 764 off between packet size and code complexity. For information that is 765 usually (or always) required, placing it in the fixed Opcode data 766 results in simpler code to generate and parse the packet, because the 767 information is a fixed location in the Opcode data, but wastes space 768 in the packet in the event that field is all-zeroes because the 769 information is not needed or not relevant. For information that is 770 required less often, placing it in an Option results in slightly more 771 complicated code to generate and parse packets containing that 772 Option, but saves space in the packet when that information is not 773 needed. Placing information in an Option also means that an 774 implementation that never uses that information doesn't even need to 775 implement code to generate and parse it. For example, a client that 776 never requests mappings on behalf of some other device doesn't need 777 to implement code to generate the THIRD_PARTY Option, and a PCP 778 server that doesn't implement the necessary security measures to 779 create third-party mappings safely doesn't need to implement code to 780 parse the THIRD_PARTY Option. 782 Options use the following Type-Length-Value format: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Option Code | Reserved | Option Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 : (optional) data : 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 4: Options Header 794 The description of the fields is as follows: 796 Option Code: 8 bits. Its most significant bit indicates if this 797 Option is mandatory (0) or optional (1) to process. 799 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 800 ignored on reception. 802 Option Length: 16 bits. Indicates the length of the enclosed data, 803 in octets. Options with length of 0 are allowed. Options that 804 are not a multiple of four octets long are followed by one, two, 805 or three zero octets to pad their effective length in the packet 806 to be a multiple of four octets. The Option Length reflects the 807 semantic length of the option, not including any padding octets. 809 data: Option data. 811 If several Options are included in a PCP request, they MAY be encoded 812 in any order by the PCP client, but MUST be processed by the PCP 813 server in the order in which they appear. It is the responsibility 814 of the PCP client to ensure the server has sufficient room to reply 815 without exceeding the 1100 octet size limit; if its reply would 816 exceed that size, the server generates an error. 818 If, while processing a PCP request, including its options, an error 819 is encountered that causes a PCP error response to be generated, the 820 PCP request MUST cause no state change in the PCP server or the PCP- 821 controlled device (i.e., it rolls back any changes it might have made 822 while processing the request). Such an error response MUST consist 823 of a complete copy of the request packet with the error code and 824 other appropriate fields set in the header. 826 An Option MAY appear more than once in a request or in a response, if 827 permitted by the definition of the Option. If the Option's 828 definition allows the Option to appear only once but it appears more 829 than once in a request, and the Option is understood by the PCP 830 server, the PCP server MUST respond with the MALFORMED_OPTION result 831 code. If the PCP server encounters an invalid option (e.g., PCP 832 option length is longer than the UDP packet length) the error 833 MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST), 834 as that helps the client better understand how the packet was 835 malformed. If a PCP response would have exceeded the maximum PCP 836 message size, the PCP server SHOULD respond with MALFORMED_REQUEST. 838 If the overall Option structure of a request cannot successfully be 839 parsed (e.g. a nonsensical option length) the PCP server MUST 840 generate an error response with code MALFORMED_OPTION. 842 If the overall Option structure of a request is valid then how each 843 individual Option is handled is determined by the most significant 844 bit in the Option Code. If the most significant bit is set, handling 845 this Option is optional, and a PCP server MAY process or ignore this 846 Option, entirely at its discretion. If the most significant bit is 847 clear, handling this Option is mandatory, and a PCP server MUST 848 return the error MALFORMED_OPTION if the option contents are 849 malformed, or UNSUPP_OPTION if the Option is unrecognized, 850 unimplemented, or disabled, or if the client is not authorized to use 851 the Option. In error responses all options are returned. In success 852 responses all processed options are included and unprocessed options 853 are not included. 855 PCP clients are free to ignore any or all Options included in 856 responses, although naturally if a client explicitly requests an 857 Option where correct execution of that Option requires processing the 858 Option data in the response, that client is expected to implement 859 code to do that. 861 Different options are valid for different Opcodes. For example: 863 o The THIRD_PARTY Option is valid for both MAP and PEER Opcodes. 865 o The FILTER Option is valid only for the MAP Opcode (for the PEER 866 Opcode it would have no meaning). 868 o The PREFER_FAILURE Option is valid only for the MAP Opcode (for 869 the PEER Opcode, similar semantics are automatically implied). 871 7.4. Result Codes 873 The following result codes may be returned as a result of any Opcode 874 received by the PCP server. The only success result code is 0; other 875 values indicate an error. If a PCP server encounters multiple errors 876 during processing of a request, it SHOULD use the most specific error 877 message. Each error code below is classified as either a 'long 878 lifetime' error or a 'short lifetime' error, which provides guidance 879 to PCP server developers for the value of the Lifetime field for 880 these errors. It is RECOMMENDED that short lifetime errors use a 30 881 second lifetime and long lifetime errors use a 30 minute lifetime. 883 0 SUCCESS: Success. 885 1 UNSUPP_VERSION: The version number at the start of the PCP Request 886 header is not recognized by this PCP server. This is a long 887 lifetime error. This document describes PCP version 2. 889 2 NOT_AUTHORIZED: The requested operation is disabled for this PCP 890 client, or the PCP client requested an operation that cannot be 891 fulfilled by the PCP server's security policy. This is a long 892 lifetime error. 894 3 MALFORMED_REQUEST: The request could not be successfully parsed. 895 This is a long lifetime error. 897 4 UNSUPP_OPCODE: Unsupported Opcode. This is a long lifetime error. 899 5 UNSUPP_OPTION: Unsupported Option. This error only occurs if the 900 Option is in the mandatory-to-process range. This is a long 901 lifetime error. 903 6 MALFORMED_OPTION: Malformed Option (e.g., appears too many times, 904 invalid length). This is a long lifetime error. 906 7 NETWORK_FAILURE: The PCP server or the device it controls are 907 experiencing a network failure of some sort (e.g., has not 908 obtained an External IP address). This is a short lifetime error. 910 8 NO_RESOURCES: Request is well-formed and valid, but the server has 911 insufficient resources to complete the requested operation at this 912 time. For example, the NAT device cannot create more mappings at 913 this time, is short of CPU cycles or memory, or is unable to 914 handle the request due to some other temporary condition. The 915 same request may succeed in the future. This is a system-wide 916 error, different from USER_EX_QUOTA. This can be used as a catch- 917 all error, should no other error message be suitable. This is a 918 short lifetime error. 920 9 UNSUPP_PROTOCOL: Unsupported transport protocol, e.g. SCTP in a 921 NAT that handles only UDP and TCP. This is a long lifetime error. 923 10 USER_EX_QUOTA: This attempt to create a new mapping would exceed 924 this subscriber's port quota. This is a short lifetime error. 926 11 CANNOT_PROVIDE_EXTERNAL: The suggested external port and/or 927 external address cannot be provided. This error MUST only be 928 returned for: 929 * MAP requests that included the PREFER_FAILURE Option 930 (normal MAP requests will return an available external port) 931 * MAP requests for the SCTP protocol (PREFER_FAILURE is implied) 932 * PEER requests 934 See Section 13.2 for processing details. The error lifetime 935 depends on the reason for the failure. 937 12 ADDRESS_MISMATCH: The source IP address of the request packet does 938 not match the contents of the PCP Client's IP Address field, due 939 to an unexpected NAT on the path between the PCP client and the 940 PCP-controlled NAT or firewall. This is a long lifetime error. 942 13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the 943 filters in this request. This result code MUST only be returned 944 if the MAP request contained the FILTER Option. See Section 13.3 945 for processing information. This is a long lifetime error. 947 8. General PCP Operation 949 PCP messages MUST be sent over UDP [RFC0768]. Every PCP request 950 generates at least one response, so PCP does not need to run over a 951 reliable transport protocol. 953 When receiving multiple identical requests, the PCP server will 954 generate identical responses, provided the PCP server's state did not 955 change between those requests due to other activity. For example, if 956 a request is received while the PCP-controlled device has no mappings 957 available, it will generate an error response. If mappings become 958 available and then a (duplicated or re-transmitted) request is seen 959 by the server, it will generate a non-error response. A PCP client 960 MUST handle such updated responses for any request it sends, most 961 notably to support Rapid Recovery (Section 14). Also see the 962 Protocol Design Note (Section 6). 964 8.1. General PCP Client: Generating a Request 966 This section details operation specific to a PCP client, for any 967 Opcode. Procedures specific to the MAP Opcode are described in 968 Section 11, and procedures specific to the PEER Opcode are described 969 in Section 12. 971 Prior to sending its first PCP message, the PCP client determines 972 which server to use. The PCP client performs the following steps to 973 determine its PCP server: 975 1. if a PCP server is configured (e.g., in a configuration file or 976 via DHCP), that single configuration source is used as the list 977 of PCP Server(s), else; 979 2. the default router list (for IPv4 and IPv6) is used as the list 980 of PCP Server(s). Thus, if a PCP client has both an IPv4 and 981 IPv6 address, it will have an IPv4 PCP server (its IPv4 default 982 router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6 983 default router) for its IPv6 mappings. 985 For the purposes of this document, only a single PCP server address 986 is supported. Should future specifications define configuration 987 methods that provide a longer list of PCP server addresses, those 988 specifications will define how clients select one or more addresses 989 from that list. 991 With that PCP server address, the PCP client formulates its PCP 992 request. The PCP request contains a PCP common header, PCP Opcode 993 and payload, and (possibly) Options. As with all UDP client software 994 on any operating system, when several independent PCP clients exist 995 on the same host, each uses a distinct source port number to 996 disambiguate their requests and replies. The PCP client's source 997 port SHOULD be randomly generated [RFC6056]. 999 The PCP client MUST include the source IP address of the PCP message 1000 in the PCP request. This is typically its own IP address; see 1001 Section 16.4 for how this can be coded. This is used to detect an 1002 unexpected NAT on the path between the PCP client and the PCP- 1003 controlled NAT or firewall device, to avoid wasting state on the PCP- 1004 controlled NAT creating pointless non-functional mappings. When such 1005 an intervening non-PCP-aware inner NAT is detected, mappings must 1006 first be created by some other means in the inner NAT, before 1007 mappings can be usefully created in the outer PCP-controlled NAT. 1008 Having created mappings in the inner NAT by some other means, the PCP 1009 client should then use the inner NAT's External Address as the Client 1010 IP Address, to signal to the outer PCP-controlled NAT that the client 1011 is aware of the inner NAT, and has taken steps to create mappings in 1012 it by some other means, so that mappings created in the outer NAT 1013 will not be a pointless waste of state. 1015 8.1.1. PCP Client Retransmission 1017 PCP clients are responsible for reliable delivery of PCP request 1018 messages. If a PCP client fails to receive an expected response from 1019 a server, the client must retransmit its message. The 1020 retransmissions MUST use the same Mapping Nonce value (see 1021 Section 11.1 and Section 12.1). The client begins the message 1022 exchange by transmitting a message to the server. The message 1023 exchange continues for as long as the client wishes to maintain the 1024 mapping, and terminates when the PCP client is no longer interested 1025 in the PCP transaction (e.g., the application that requested the 1026 mapping is no longer interested in the mapping) or (optionally) when 1027 the message exchange is considered to have failed according to the 1028 retransmission mechanism described below. 1030 The client retransmission behavior is controlled and described by the 1031 following variables: 1033 RT: Retransmission timeout, calculated as described below 1035 IRT: Initial retransmission time, SHOULD be 3 seconds 1037 MRC: Maximum retransmission count, SHOULD be 0 (0 indicates no 1038 maximum) 1040 MRT: Maximum retransmission time, SHOULD be 1024 seconds 1042 MRD: Maximum retransmission duration, SHOULD be 0 (0 indicates no 1043 maximum) 1045 RAND: Randomization factor, calculated as described below 1047 With each message transmission or retransmission, the client sets RT 1048 according to the rules given below. If RT expires before a response 1049 is received, the client recomputes RT and retransmits the request. 1051 Each of the computations of a new RT include a new randomization 1052 factor (RAND), which is a random number chosen with a uniform 1053 distribution between -0.1 and +0.1. The randomization factor is 1054 included to minimize synchronization of messages transmitted by PCP 1055 clients. The algorithm for choosing a random number does not need to 1056 be cryptographically sound. The algorithm SHOULD produce a different 1057 sequence of random numbers from each invocation of the PCP client. 1059 The RT value is initialized based on IRT: 1061 RT = (1 + RAND) * IRT 1063 RT for each subsequent message transmission is based on the previous 1064 value of RT, subject to the upper bound on the value of RT specified 1065 by MRT. If MRT has a value of 0, there is no upper limit on the 1066 value of RT, and MRT is treated as "infinity": 1068 RT = (1 + RAND) * MIN (2 * RTprev, MRT) 1070 MRC specifies an upper bound on the number of times a client may 1071 retransmit a message. Unless MRC is zero, the message exchange fails 1072 once the client has transmitted the message MRC times. 1074 MRD specifies an upper bound on the length of time a client may 1075 retransmit a message. Unless MRD is zero, the message exchange fails 1076 once MRD seconds have elapsed since the client first transmitted the 1077 message. 1079 If both MRC and MRD are non-zero, the message exchange fails whenever 1080 either of the conditions specified in the previous two paragraphs are 1081 met. If both MRC and MRD are zero, the client continues to transmit 1082 the message until it receives a response, or the client no longer 1083 wants a mapping. 1085 Once a PCP client has successfully received a response from a PCP 1086 server on that interface, it resets RT to a value randomly selected 1087 in the range 1/2 to 5/8 of the mapping lifetime, as described in 1088 Section 11.2.1, and sends subsequent PCP requests for that mapping to 1089 that same server. 1091 Note: If the server's state changes between retranmissions and the 1092 server's response is delayed or lost, the state in the PCP client 1093 and server may not be synchronized. This is not unique to PCP, 1094 but also occurs with other network protocols (e.g., TCP). In the 1095 unlikely event that such de-synchronization occurs, PCP heals 1096 itself after Lifetime seconds. 1098 8.2. General PCP Server: Processing a Request 1100 This section details operation specific to a PCP server. Processing 1101 SHOULD be performed in the order of the following paragraphs. 1103 A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests 1104 from a client on the same interface it would normally receive packets 1105 from that client, and MUST silently ignore PCP requests arriving on 1106 any other interface. For example, a residential NAT gateway accepts 1107 PCP requests only when they arrive on its (LAN) interface connecting 1108 to the internal network, and silently ignores any PCP requests 1109 arriving on its external (WAN) interface. A PCP server which 1110 supports THIRD_PARTY requests MAY be configured to accept THIRD_PARTY 1111 requests on other configured interfaces (see Section 13.1). 1113 Upon receiving a request, the PCP server parses and validates it. A 1114 valid request contains a valid PCP common header, one valid PCP 1115 Opcode, and zero or more Options (which the server might or might not 1116 comprehend). If an error is encountered during processing, the 1117 server generates an error response which is sent back to the PCP 1118 client. Processing an Opcode and the Options are specific to each 1119 Opcode. 1121 Error responses have the same packet layout as success responses, 1122 with certain fields from the request copied into the response, and 1123 other fields assigned by the PCP server set as indicated in Figure 3. 1125 Copying request fields into the response is important because this is 1126 what enables a client to identify to which request a given response 1127 pertains. For Opcodes that are understood by the PCP server, it 1128 follows the requirements of that Opcode to copy the appropriate 1129 fields. For Opcodes that are not understood by the PCP server, it 1130 simply generates the UNSUPP_OPCODE response and copies fields from 1131 the PCP header and copies the rest of the PCP payload as-is (without 1132 attempting to interpret it). 1134 All responses (both error and success) contain the same Opcode as the 1135 request, but with the "R" bit set. 1137 Any error response has a nonzero Result Code, and is created by: 1138 o Copying the entire UDP payload, or 1100 octets, whichever is less, 1139 and zero-padding the response to a multiple of 4 octets if 1140 necessary 1141 o Setting the R bit 1142 o Setting the Result Code 1143 o Setting the Lifetime, Epoch Time and Reserved fields 1144 o Updating other fields in the response, as indicated by 'set by the 1145 server' in the PCP response field description. 1147 A success response has a zero Result Code, and is created by: 1148 o Copying the first four octets of request packet header 1149 o Setting the R bit 1150 o Setting the Result Code to zero 1151 o Setting the Lifetime, Epoch Time and Reserved fields 1152 o Possibly setting opcode-specific response data if appropriate 1153 o Adding any processed options to the response message 1155 If the received PCP request message is less than two octets long it 1156 is silently dropped. 1158 If the R bit is set the message is silently dropped. 1160 If the first octet (version) is a version that is not supported, a 1161 response is generated with the UNSUPP_VERSION result code, and the 1162 other steps detailed in Section 9 are followed. 1164 Otherwise, if the version is supported but the received message is 1165 shorter than 24 octets, the message is silently dropped. 1167 If the server is overloaded by requests (from a particular client or 1168 from all clients), it MAY simply silently discard requests, as the 1169 requests will be retried by PCP clients, or it MAY generate the 1170 NO_RESOURCES error response. 1172 If the length of the message exceeds 1100 octets, is not a multiple 1173 of 4 octets, or is too short for the opcode in question, it is 1174 invalid and a MALFORMED_REQUEST response is generated, and the 1175 response message is truncated to 1100 octets. 1177 The PCP server compares the source IP address (from the received IP 1178 header) with the field PCP Client IP Address. If they do not match, 1179 the error ADDRESS_MISMATCH MUST be returned. This is done to detect 1180 and prevent accidental use of PCP where a non-PCP-aware NAT exists 1181 between the PCP client and PCP server. If the PCP client wants such 1182 a mapping it needs to ensure the PCP field matches its apparent IP 1183 address from the perspective of the PCP server. 1185 8.3. General PCP Client: Processing a Response 1187 The PCP client receives the response and verifies that the source IP 1188 address and port belong to the PCP server of a previously-sent PCP 1189 request. If not, the response is silently dropped. 1191 If the received PCP response message is less than four octets long it 1192 is silently dropped. 1194 If the R bit is clear the message is silently dropped. 1196 If the error code is UNSUPP_VERSION processing continues as described 1197 in Section 9. 1199 The PCP client then validates that the Opcode matches a previous PCP 1200 request. Responses shorter than 24 octets, longer than 1100 octets, 1201 or not a multiple of 4 octets are invalid and ignored, likely causing 1202 the request to be re-transmitted. The response is further matched by 1203 comparing fields in the response Opcode-specific data to fields in 1204 the request Opcode-specific data, as described by the processing for 1205 that Opcode. 1207 After these matches are successful, the PCP client checks the Epoch 1208 Time field to determine if it needs to restore its state to the PCP 1209 server (see Section 8.5). A PCP client SHOULD be prepared to receive 1210 multiple responses from the PCP Server at any time after a single 1211 request is sent. This allows the PCP server to inform the client of 1212 mapping changes such as an update or deletion. For example, a PCP 1213 Server might send a SUCCESS response and, after a configuration 1214 change on the PCP Server, later send a NOT_AUTHORIZED response. A 1215 PCP client MUST be prepared to receive responses for requests it 1216 never sent (which could have been sent by a previous PCP instance on 1217 this same host, or by a previous host that used the same client IP 1218 address, or by a malicious attacker) by simply ignoring those 1219 unexpected messages. 1221 If the error ADDRESS_MISMATCH is received, it indicates the presence 1222 of a NAT between the PCP client and PCP server. Procedures to 1223 resolve this problem are beyond the scope of this document. 1225 For both success and error responses a Lifetime value is returned. 1226 The Lifetime indicates how long this request is considered valid by 1227 the server. The PCP client SHOULD impose an upper limit on this 1228 returned value (to protect against absurdly large values, e.g., 5 1229 years), detailed in Section 15. 1231 If the result code is 0 (SUCCESS), the request succeeded. 1233 If the result code is not 0, the request failed, and the PCP client 1234 SHOULD NOT resend the same request for the indicated Lifetime of the 1235 error (as limited by the sanity checking detailed in Section 15). 1237 If the PCP client has discovered a new PCP server (e.g., connected to 1238 a new network), the PCP client MAY immediately begin communicating 1239 with this PCP server, without regard to hold times from communicating 1240 with a previous PCP server. 1242 8.4. Multi-Interface Issues 1244 Hosts that desire a PCP mapping might be multi-interfaced (i.e., own 1245 several logical/physical interfaces). Indeed, a host can be 1246 configured with several IPv4 addresses (e.g., Wi-Fi and Ethernet) or 1247 dual-stacked. These IP addresses may have distinct reachability 1248 scopes (e.g., if IPv6 they might have global reachability scope as 1249 for Global Unicast Address (GUA, [RFC3587]) or limited scope as for 1250 Unique Local Address (ULA) [RFC4193]). 1252 IPv6 addresses with global reachability (e.g., GUA) SHOULD be used as 1253 the source address when generating a PCP request. IPv6 addresses 1254 without global reachability (e.g., ULA [RFC4193]), SHOULD NOT be used 1255 as the source interface when generating a PCP request. If IPv6 1256 privacy addresses [RFC4941] are used for PCP mappings, a new PCP 1257 request will need to be issued whenever the IPv6 privacy address is 1258 changed. This PCP request SHOULD be sent from the IPv6 privacy 1259 address itself. It is RECOMMENDED that the client delete its 1260 mappings to the previous privacy address after it no longer needs 1261 those old mappings. 1263 Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope 1264 (e.g., private addresses [RFC1918]) MAY be used as the source 1265 interface when generating a PCP request. 1267 8.5. Epoch 1269 Every PCP response sent by the PCP server includes an Epoch time 1270 field. This time field increments by one every second. Anomalies in 1271 the received Epoch time value provide a hint to PCP clients that a 1272 PCP server state loss may have occurred. Clients respond to such 1273 state loss hints by promptly renewing their mappings, so as to 1274 quickly restore any lost state at the PCP server. 1276 If the PCP server resets or loses the state of its explicit dynamic 1277 Mappings (that is, those mappings created by PCP requests), due to 1278 reboot, power failure, or any other reason, it MUST reset its Epoch 1279 time to its initial starting value (usually zero) to provide this 1280 hint to PCP clients. After resetting its Epoch time, the PCP server 1281 resumes incrementing the Epoch time value by one every second. 1282 Similarly, if the External IP Address(es) of the NAT (controlled by 1283 the PCP server) changes, the Epoch time MUST be reset. A PCP server 1284 MAY maintain one Epoch time value for all PCP clients, or MAY 1285 maintain distinct Epoch time values (per PCP client, per interface, 1286 or based on other criteria); this choice is implementation-dependent. 1288 Whenever a client receives a PCP response, the client validates the 1289 received Epoch time value according to the procedure below, using 1290 integer arithmetic: 1292 o If this is the first PCP response the client has received from 1293 this PCP server, the Epoch time value is treated as necessarily 1294 valid, otherwise 1296 * If the current PCP server Epoch time (curr_server_time) is less 1297 than the previously received PCP server Epoch time 1298 (prev_server_time) by more than one second, then the client 1299 treats the Epoch time as obviously invalid (time should not go 1300 backwards). The server Epoch time apparently going backwards 1301 by *up to* one second is not deemed invalid, so that minor 1302 packet re-ordering on the path from PCP Server to PCP Client 1303 does not trigger a cascade of unnecessary mapping renewals. If 1304 the server Epoch time passes this check, then further 1305 validation checks are performed: 1307 + The client computes the difference between its 1308 current local time (curr_client_time) and the 1309 time the previous PCP response was received from this PCP 1310 server (prev_client_time): 1311 client_delta = curr_client_time - prev_client_time; 1313 + The client computes the difference between the 1314 current PCP server Epoch time (curr_server_time) and the 1315 previously received Epoch time (prev_server_time): 1316 server_delta = curr_server_time - prev_server_time; 1318 + If client_delta+2 < server_delta - server_delta/16 1319 or server_delta+2 < client_delta - client_delta/16 1320 then the client treats the Epoch time value as invalid, 1321 else the client treats the Epoch time value as valid 1323 o The client records the current time values for use in its next 1324 comparison: 1325 prev_client_time = curr_client_time 1326 prev_server_time = curr_server_time 1328 If the PCP client determined that the Epoch time value it received 1329 was invalid then it concludes that the PCP server may have lost 1330 state, and promptly renews all its active port mapping leases as 1331 described in Section 16.3.1. 1333 Notes: 1335 o The client clock MUST never go backwards. If curr_client_time is 1336 found to be less than prev_client_time then this is a client bug, 1337 and how the client deals with this client bug is implementation 1338 specific. 1340 o The calculations above are constructed to allow client_delta and 1341 server_delta to be computed as unsigned integer values. 1343 o The "+2" in the calculations above is to accommodate quantization 1344 errors in client and server clocks (up to one second quantization 1345 error each in server and client time intervals). 1347 o The "/16" in the calculations above is to accommodate inaccurate 1348 clocks in low-cost devices. This allows for a total discrepancy 1349 of up to 1/16 (6.25%) to be considered benign, e.g., if one clock 1350 were to run too fast by 3% while the other clock ran too slow by 1351 3% then the client would not consider this difference to be 1352 anomalous or indicative of a restart having occurred. This 1353 tolerance is strict enough to be effective at detecting reboots, 1354 while not being so strict as to generate false alarms. 1356 9. Version Negotiation 1358 A PCP client sends its requests using PCP version number 2. Should 1359 later updates to this document specify different message formats with 1360 a version number greater than 2 it is expected that PCP servers will 1361 still support version 2 in addition to the newer version(s). 1362 However, in the event that a server returns a response with result 1363 code UNSUPP_VERSION, the client MAY log an error message to inform 1364 the user that it is too old to work with this server. 1366 Should later updates to this document specify different message 1367 formats with a version number greater than 2, and backwards 1368 compatibility is desired, this first octet can be used for forward 1369 and backward compatibility. 1371 If future PCP versions greater than 2 are specified, version 1372 negotiation proceeds as follows: 1374 1. The client sends its first request using the highest (i.e., 1375 presumably 'best') version number it supports. 1377 2. If the server supports that version it responds normally. 1379 3. If the server does not support that version it replies giving a 1380 result containing the result code UNSUPP_VERSION, and the closest 1381 version number it does support (if the server supports a range of 1382 versions higher than the client's requested version, the server 1383 returns the lowest of that supported range; if the server 1384 supports a range of versions lower than the client's requested 1385 version, the server returns the highest of that supported range). 1387 4. If the client receives an UNSUPP_VERSION result containing a 1388 version it does support, it records this fact and proceeds to use 1389 this message version for subsequent communication with this PCP 1390 server (until a possible future UNSUPP_VERSION response if the 1391 server is later updated, at which point the version negotiation 1392 process repeats). 1394 5. If the client receives an UNSUPP_VERSION result containing a 1395 version it does not support then the client SHOULD try the next- 1396 lower version supported by the client. The attempt to use the 1397 next-lower version repeats until the client has tried version 2. 1398 If using version 2 fails, the client MAY log an error message to 1399 inform the user that it is too old to work with this server, and 1400 the client SHOULD set a timer to retry its request in 30 minutes 1401 or the returned Lifetime value, whichever is smaller. By 1402 automatically retrying in 30 minutes, the protocol accommodates 1403 an upgrade of the PCP server. 1405 10. Introduction to MAP and PEER Opcodes 1407 There are four uses for the MAP and PEER Opcodes defined in this 1408 document: 1410 o a host operating a server and wanting an incoming connection 1411 (Section 10.1); 1413 o a host operating a client and server on the same port 1414 (Section 10.2); 1416 o a host operating a client and wanting to optimize the application 1417 keepalive traffic (Section 10.3); 1419 o and a host operating a client and wanting to restore lost state in 1420 its NAT (Section 10.4). 1422 These are discussed in the following sections, and a (non-normative) 1423 state diagram is provided in Section 16.5. 1425 When operating a server (Section 10.1 and Section 10.2) the PCP 1426 client knows if it wants an IPv4 listener, IPv6 listener, or both on 1427 the Internet. The PCP client also knows if it has an IPv4 address or 1428 IPv6 address configured on one of its interfaces. It takes the union 1429 of this knowledge to decide to which of its PCP servers to send the 1430 request (e.g., an IPv4 address or an IPv6 address), and if to send 1431 one or two MAP requests for each of its interfaces (e.g., if the PCP 1432 client has only an IPv4 address but wants both IPv6 and IPv4 1433 listeners, it sends a MAP request containing the all-zeros IPv6 1434 address in the Suggested External Address field, and sends a second 1435 MAP request containing the all-zeros IPv4 address in the Suggested 1436 External Address field. If the PCP client has both an IPv4 and IPv6 1437 address, and only wants an IPv4 listener, it sends one MAP request 1438 from its IPv4 address (if the PCP server supports NAT44 or IPv4 1439 firewall) or one MAP request from its IPv6 address (if the PCP server 1440 supports NAT64). The PCP client can simply request the desired 1441 mapping to determine if the PCP server supports the desired mapping. 1442 Applications that embed IP addresses in payloads (e.g., FTP, SIP) 1443 will find it beneficial to avoid address family translation, if 1444 possible. 1446 The MAP and PEER requests include a Suggested External IP Address 1447 field. Some PCP-controlled devices, especially CGN but also multi- 1448 homed NPTv6 networks, have a pool of public-facing IP addresses. PCP 1449 allows the client to indicate if it wants a mapping assigned on a 1450 specific address of that pool or any address of that pool. Some 1451 applications will break if mappings are created on different IP 1452 addresses (e.g., active mode FTP), so applications should carefully 1453 consider the implications of using this capability. Static mappings 1454 for that Internal Address (e.g., those created by a command-line 1455 interface on the PCP server or PCP-controlled device) may exist to a 1456 certain External Address, and if the Suggested External IP Address is 1457 the all-zeros address, PCP SHOULD assign its mappings to the same 1458 External Address, as this can also help applications using a mix of 1459 both static mappings and PCP-created mappings. If, on the other 1460 hand, the Suggested External IP Address contains a non-zero IP 1461 address the PCP Server SHOULD create a mapping to that external 1462 address, even if there are other mappings from that same Internal 1463 Address to a different External Address. Once an Internal Address 1464 has no implicit dynamic mappings and no explicit dynamic mappings in 1465 the PCP-controlled device, a subsequent implicit or explicit mapping 1466 for that Internal Address MAY be assigned to a different External 1467 Address. Generally, this re-assignment would occur when a CGN device 1468 is load balancing newly-seen Internal Addresses to its public pool of 1469 External Addresses. 1471 The following table summarizes how various common PCP deployments use 1472 IPv6 and IPv4 addresses. 1474 The 'internal' address is implicitly the same as the source IP 1475 address of the PCP request, except when the THIRD_PARTY option is 1476 used. 1478 The 'external' address is the Suggested External Address field of the 1479 MAP or PEER request, and is address family is usually the same as the 1480 'internal' address family, except when technologies like NAT64 are 1481 used. 1483 The 'remote peer' address is the Remote Peer IP Address of the PEER 1484 request or the FILTER option of the MAP request, and is always the 1485 same address family as the 'internal' address, even when NAT64 is 1486 used. 1488 In NAT64, the IPv6 PCP client is not necessarily aware of the NAT64 1489 or aware of the actual IPv4 address of the remote peer, so it 1490 expresses the IPv6 address from its perspective, as shown in the 1491 table. 1493 internal external PCP remote peer actual remote peer 1494 -------- ------- --------------- ------------------ 1495 IPv4 firewall IPv4 IPv4 IPv4 IPv4 1496 IPv6 firewall IPv6 IPv6 IPv6 IPv6 1497 NAT44 IPv4 IPv4 IPv4 IPv4 1498 NAT46 IPv4 IPv6 IPv4 IPv6 1499 NAT64 IPv6 IPv4 IPv6 IPv4 1500 NPTv6 IPv6 IPv6 IPv6 IPv6 1502 Figure 5: Address Families with MAP and PEER 1504 10.1. For Operating a Server 1506 A host operating a server (e.g., a web server) listens for traffic on 1507 a port, but the server never initiates traffic from that port. For 1508 this to work across a NAT or a firewall, the host needs to (a) create 1509 a mapping from a public IP address, protocol, and port to itself as 1510 described in Section 11, (b) publish that public IP address, 1511 protocol, and port via some sort of rendezvous server (e.g., DNS, a 1512 SIP message, a proprietary protocol), and (c) ensure that any other 1513 non-PCP-speaking packet filtering middleboxes on the path (e.g., 1514 host-based firewall, network-based firewall, or other NATs) will also 1515 allow the incoming traffic. Publishing the public IP address and 1516 port is out of scope of this specification. To accomplish (a), the 1517 host follows the procedures described in this section. 1519 As normal, the application needs to begin listening on a port. Then, 1520 the application constructs a PCP message with the MAP Opcode, with 1521 the external address set to the appropriate all-zeroes address, 1522 depending on whether it wants a public IPv4 or IPv6 address. 1524 The following pseudo-code shows how PCP can be reliably used to 1525 operate a server: 1527 /* start listening on the local server port */ 1528 int s = socket(...); 1529 bind(s, ...); 1530 listen(s, ...); 1532 getsockname(s, &internal_sockaddr, ...); 1533 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1535 while (1) 1536 { 1537 /* Note: The "time_to_send_pcp_request()" check below includes: 1538 * 1. Sending the first request 1539 * 2. Retransmitting requests due to packet loss 1540 * 3. Resending a request due to impending lease expiration 1541 * 4. Resending a request due to server state loss 1542 * The PCP packet sent is identical in all four cases; from 1543 * the PCP server's point of view they are the same operation. 1544 * The Suggested External Address and Port may be updated 1545 * repeatedly during the lifetime of the mapping. 1546 * Other fields in the packet generally remain unchanged. 1547 */ 1548 if (time_to_send_pcp_request()) 1549 pcp_send_map_request(internal_sockaddr.sin_port, 1550 internal_sockaddr.sin_addr, 1551 &external_sockaddr, /* will be zero the first time */ 1552 requested_lifetime, &assigned_lifetime); 1554 if (pcp_response_received()) 1555 update_rendezvous_server("Client Ident", external_sockaddr); 1557 if (received_incoming_connection_or_packet()) 1558 process_it(s); 1560 if (other_work_to_do()) 1561 do_it(); 1563 /* ... */ 1565 block_until_we_need_to_do_something_else(); 1566 } 1568 Figure 6: Pseudo-code for using PCP to operate a server 1570 10.2. For Operating a Symmetric Client/Server 1572 A host operating a client and server on the same port (e.g., 1573 Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) 1574 [RFC3581]) first establishes a local listener, (usually) sends the 1575 local and public IP addresses, protocol, and ports to a rendezvous 1576 service (which is out of scope of this document), and initiates an 1577 outbound connection from that same source address and same port. To 1578 accomplish this, the application uses the procedure described in this 1579 section. 1581 An application that is using the same port for outgoing connections 1582 as well as incoming connections MUST first signal its operation of a 1583 server using the PCP MAP Opcode, as described in Section 11, and 1584 receive a positive PCP response before it sends any packets from that 1585 port. 1587 Discussion: In general, a PCP client doesn't know in advance if it 1588 is behind a NAT or firewall. On detecting the host has connected 1589 to a new network, the PCP client can attempt to request a mapping 1590 using PCP, and if that succeeds then the client knows it has 1591 successfully created a mapping. If after multiple retries it has 1592 received no PCP response, then either the client is *not* behind a 1593 NAT or firewall and has unfettered connectivity, or the client 1594 *is* behind a NAT or firewall which doesn't support PCP (and the 1595 client may still have working connectivity by virtue of static 1596 mappings previously created manually by the user). Retransmitting 1597 PCP requests multiple times before giving up and assuming 1598 unfettered connectivity adds delay in that case. Initiating 1599 outbound TCP connections immediately without waiting for PCP 1600 avoids this delay, and will work if the NAT has endpoint- 1601 independent mapping EIM behavior, but may fail if the NAT has 1602 endpoint-dependent mapping EDM behavior. Waiting enough time to 1603 allow an explicit PCP MAP Mapping to be created (if possible) 1604 first ensures that the same External Port will then be used for 1605 all subsequent implicit dynamic mappings (e.g., TCP SYNs) sent 1606 from the specified Internal Address, Protocol, and Port. PCP 1607 supports both EIM and EDM NATs, so clients need to assume they may 1608 be dealing with an EDM NAT. In this case, the client will 1609 experience more reliable connectivity if it attempts explicit PCP 1610 MAP requests first, before initiating any outbound TCP connections 1611 from that Internal Address and Port. See also Section 16.1. 1613 The following pseudo-code shows how PCP can be used to operate a 1614 symmetric client and server: 1616 /* start listening on the local server port */ 1617 int s = socket(...); 1618 bind(s, ...); 1619 listen(s, ...); 1621 getsockname(s, &internal_sockaddr, ...); 1622 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1624 while (1) 1625 { 1626 /* Note: The "time_to_send_pcp_request()" check below includes: 1627 * 1. Sending the first request 1628 * 2. Retransmitting requests due to packet loss 1629 * 3. Resending a request due to impending lease expiration 1630 * 4. Resending a request due to server state loss 1631 */ 1632 if (time_to_send_pcp_request()) 1633 pcp_send_map_request(internal_sockaddr.sin_port, 1634 internal_sockaddr.sin_addr, 1635 &external_sockaddr, /* will be zero the first time */ 1636 requested_lifetime, &assigned_lifetime); 1638 if (pcp_response_received()) 1639 update_rendezvous_server("Client Ident", external_sockaddr); 1641 if (received_incoming_connection_or_packet()) 1642 process_it(s); 1644 if (need_to_make_outgoing_connection()) 1645 make_outgoing_connection(s, ...); 1647 if (data_to_send()) 1648 send_it(s); 1650 if (other_work_to_do()) 1651 do_it(); 1653 /* ... */ 1655 block_until_we_need_to_do_something_else(); 1656 } 1658 Figure 7: Pseudo-code for using PCP to operate a symmetric client/ 1659 server 1661 10.3. For Reducing NAT or Firewall Keepalive Messages 1663 A host operating a client (e.g., XMPP client, SIP client) sends from 1664 a port, and may receive responses, but never accepts incoming 1665 connections from other Remote Peers on this port. It wants to ensure 1666 the flow to its Remote Peer is not terminated (due to inactivity) by 1667 an on-path NAT or firewall. To accomplish this, the application uses 1668 the procedure described in this section. 1670 Middleboxes such as NATs or firewalls need to see occasional traffic 1671 or will terminate their session state, causing application failures. 1672 To avoid this, many applications routinely generate keepalive traffic 1673 for the primary (or sole) purpose of maintaining state with such 1674 middleboxes. Applications can reduce such application keepalive 1675 traffic by using PCP. 1677 Note: For reasons beyond NAT, an application may find it useful to 1678 perform application-level keepalives, such as to detect a broken 1679 path between the client and server, keep state alive on the Remote 1680 Peer, or detect a powered-down client. These keepalives are not 1681 related to maintaining middlebox state, and PCP cannot do anything 1682 useful to reduce those keepalives. 1684 To use PCP for this function, the application first connects to its 1685 server, as normal. Afterwards, it issues a PCP request with the PEER 1686 Opcode as described in Section 12. 1688 The following pseudo-code shows how PCP can be reliably used with a 1689 dynamic socket, for the purposes of reducing application keepalive 1690 messages: 1692 int s = socket(...); 1693 connect(s, &remote_peer, ...); 1695 getsockname(s, &internal_sockaddr, ...); 1696 bzero(&external_sockaddr, sizeof(external_sockaddr)); 1698 while (1) 1699 { 1700 /* Note: The "time_to_send_pcp_request()" check below includes: 1701 * 1. Sending the first request 1702 * 2. Retransmitting requests due to packet loss 1703 * 3. Resending a request due to impending lease expiration 1704 * 4. Resending a request due to server state loss 1705 */ 1706 if (time_to_send_pcp_request()) 1707 pcp_send_peer_request(internal_sockaddr.sin_port, 1708 internal_sockaddr.sin_addr, 1709 &external_sockaddr, /* will be zero the first time */ 1710 remote_peer, requested_lifetime, &assigned_lifetime); 1712 if (data_to_send()) 1713 send_it(s); 1715 if (other_work_to_do()) 1716 do_it(); 1718 /* ... */ 1720 block_until_we_need_to_do_something_else(); 1721 } 1723 Figure 8: Pseudo-code using PCP with a dynamic socket 1725 10.4. For Restoring Lost Implicit TCP Dynamic Mapping State 1727 After a NAT loses state (e.g., because of a crash or power failure), 1728 it is useful for clients to re-establish TCP mappings on the NAT. 1729 This allows servers on the Internet to see traffic from the same IP 1730 address and port, so that sessions can be resumed exactly where they 1731 were left off. This can be useful for long-lived connections (e.g., 1732 instant messaging) or for connections transferring a lot of data 1733 (e.g., FTP). This can be accomplished by first establishing a TCP 1734 connection normally and then sending a PEER request/response and 1735 remembering the External Address and External Port. Later, when the 1736 NAT has lost state, the client can send a PEER request with the 1737 Suggested External Port and Suggested External Address remembered 1738 from the previous session, which will create a mapping in the NAT 1739 that functions exactly as an implicit dynamic mapping. The client 1740 then resumes sending TCP data to the server. 1742 Note: This procedure works well for TCP, provided the NAT creates 1743 a new implicit dynamic outbound mapping only for TCP segments with 1744 the SYN bit set (i.e., the newly-booted NAT drops the re- 1745 transmitted data segments from the client because the NAT does not 1746 have an active mapping for those segments), and if the server is 1747 not sending data that elicits a RST from the NAT. This is not the 1748 case for UDP, because a new UDP mapping will be created (probably 1749 on a different port) as soon as UDP traffic is seen by the NAT. 1751 11. MAP Opcode 1753 This section defines an Opcode which controls forwarding from a NAT 1754 (or firewall) to an Internal Host. 1756 MAP: Create an explicit dynamic mapping between an Internal 1757 Address + Port and an External Address + Port. 1759 PCP Servers SHOULD provide a configuration option to allow 1760 administrators to disable MAP support if they wish. 1762 Mappings created by PCP MAP requests are, by definition, Endpoint 1763 Independent Mappings (EIM) with Endpoint Independent Filtering (EIF) 1764 (unless the FILTER Option is used), even on a NAT that usually 1765 creates Endpoint Dependent Mappings (EDM) or Endpoint Dependent 1766 Filtering (EDF) for outgoing connections, since the purpose of an 1767 (unfiltered) MAP mapping is to receive inbound traffic from any 1768 remote endpoint, not from only one specific remote endpoint. 1770 Note also that all NAT mappings (created by PCP or otherwise) are by 1771 necessity bidirectional and symmetric. For any packet going in one 1772 direction (in or out) that is translated by the NAT, a reply going in 1773 the opposite direction needs to have the corresponding opposite 1774 translation done so that the reply arrives at the right endpoint. 1775 This means that if a client creates a MAP mapping, and then later 1776 sends an outgoing packet using the mapping's Internal Address, 1777 Protocol and Port, the NAT should translate that packet's Internal 1778 Address and Port to the mapping's External Address and Port, so that 1779 replies addressed to the External Address and Port are correctly 1780 translated back to the mapping's Internal Address and Port. 1782 On Operating Systems that allow multiple listening servers to bind to 1783 the same internal address, protocol and port, servers MUST ensure 1784 that they have exclusive use of that internal address, protocol and 1785 port (e.g., by binding the port using INADDR_ANY, or using 1786 SO_EXCLUSIVEADDRUSE or similar) before sending their PCP MAP request, 1787 to ensure that no other PCP clients on the same machine are also 1788 listening on the same internal protocol and internal port. 1790 As a side-effect of creating a mapping, ICMP messages associated with 1791 the mapping MUST be forwarded (and also translated, if appropriate) 1792 for the duration of the mapping's lifetime. This is done to ensure 1793 that ICMP messages can still be used by hosts, without application 1794 programmers or PCP client implementations needing to use PCP 1795 separately to create ICMP mappings for those flows. 1797 The operation of the MAP Opcode is described in this section. 1799 11.1. MAP Operation Packet Formats 1801 The MAP Opcode has a similar packet layout for both requests and 1802 responses. If the Assigned External IP address and Port in the PCP 1803 response always match the Internal IP Address and Port from the PCP 1804 request, then the functionality is purely a firewall; otherwise it 1805 pertains to a network address translator which might also perform 1806 firewall-like functions. 1808 The following diagram shows the format of the Opcode-specific 1809 information in a request for the MAP Opcode. 1811 0 1 2 3 1812 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 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | | 1815 | Mapping Nonce (96 bits) | 1816 | | 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 | Protocol | Reserved (24 bits) | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | Internal Port | Suggested External Port | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | | 1823 | Suggested External IP Address (128 bits) | 1824 | | 1825 | | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 Figure 9: MAP Opcode Request 1830 These fields are described below: 1832 Requested lifetime (in common header): Requested lifetime of this 1833 mapping, in seconds. The value 0 indicates "delete". 1835 Mapping Nonce: Random value chosen by the PCP client. See 1836 Section 11.2. Zero is a legal value (but unlikely, occurring in 1837 roughly one in 2^96 requests). 1839 Protocol: Upper-layer protocol associated with this Opcode. Values 1840 are taken from the IANA protocol registry [proto_numbers]. For 1841 example, this field contains 6 (TCP) if the Opcode is intended to 1842 create a TCP mapping. The value 0 has a special meaning for 'all 1843 protocols'. 1845 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1846 when received. 1848 Internal Port: Internal port for the mapping. The value 0 indicates 1849 'all ports', and is legal when the lifetime is zero (a delete 1850 request), if the Protocol does not use 16-bit port numbers, or the 1851 client is requesting 'all ports'. If Protocol is zero (meaning 1852 'all protocols'), then Internal Port MUST be zero on transmission 1853 and MUST be ignored on reception. 1855 Suggested External Port: Suggested external port for the mapping. 1856 This is useful for refreshing a mapping, especially after the PCP 1857 server loses state. If the PCP client does not know the external 1858 port, or does not have a preference, it MUST use 0. 1860 Suggested External IP Address: Suggested external IPv4 or IPv6 1861 address. This is useful for refreshing a mapping, especially 1862 after the PCP server loses state. If the PCP client does not know 1863 the external address, or does not have a preference, it MUST use 1864 the address-family-specific all-zeroes address (see Section 5). 1866 The internal address for the request is the source IP address of the 1867 PCP request message itself, unless the THIRD_PARTY Option is used. 1869 The following diagram shows the format of Opcode-specific information 1870 in a response packet for the MAP Opcode: 1872 0 1 2 3 1873 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 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | | 1876 | Mapping Nonce (96 bits) | 1877 | | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Protocol | Reserved (24 bits) | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Internal Port | Assigned External Port | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | | 1884 | Assigned External IP Address (128 bits) | 1885 | | 1886 | | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 Figure 10: MAP Opcode Response 1891 These fields are described below: 1893 Lifetime (in common header): On an error response, this indicates 1894 how long clients should assume they'll get the same error response 1895 from the PCP server if they repeat the same request. On a success 1896 response, this indicates the lifetime for this mapping, in 1897 seconds. 1899 Mapping Nonce: Copied from the request. 1901 Protocol: Copied from the request. 1903 Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored 1904 when received. 1906 Internal Port: Copied from the request. 1908 Assigned External Port: On a success response, this is the assigned 1909 external port for the mapping. On an error response, the 1910 Suggested External Port is copied from the request. 1912 Assigned External IP Address: On a success response, this is the 1913 assigned external IPv4 or IPv6 address for the mapping. An IPv4 1914 address is encoded using IPv4-mapped IPv6 address. On an error 1915 response, the Suggested External IP Address is copied from the 1916 request. 1918 11.2. Generating a MAP Request 1920 This section describes the operation of a PCP client when sending 1921 requests with the MAP Opcode. 1923 The request MAY contain values in the Suggested External Port and 1924 Suggested External IP Address fields. This allows the PCP client to 1925 attempt to rebuild lost state on the PCP server, which improves the 1926 chances of existing connections surviving, and helps the PCP client 1927 avoid having to change information maintained at its rendezvous 1928 server. Of course, due to other activity on the network (e.g., by 1929 other users or network renumbering), the PCP server may not be able 1930 to grant the suggested External IP Address, Protocol, and Port, and 1931 in that case it will assign a different External IP Address and Port. 1933 A PCP client MUST be written assuming that it may *never* be assigned 1934 the external port it suggests. In the case of recreating state after 1935 a NAT gateway crash, the Suggested External Port, being one that was 1936 previously allocated to this client, is likely to be available for 1937 this client to continue using. In all other cases, the client MUST 1938 assume that it is unlikely that its Suggested External Port will be 1939 granted. For example, when many subscribers are sharing a Carrier- 1940 Grade NAT, popular ports such as 80, 443 and 8080 are likely to be in 1941 high demand. At most one client can have each of those popular ports 1942 for each External IP Address, and all the other clients will be 1943 assigned other, dynamically allocated, External Ports. Indeed, some 1944 ISPs may, by policy, choose not to grant those External Ports to 1945 *anyone*, so that none of their clients are *ever* assigned External 1946 Ports 80, 443 or 8080. 1948 If the Protocol does not use 16-bit port numbers (e.g., RSVP, IP 1949 protocol number 46), the port number MUST be zero. This will cause 1950 all traffic matching that protocol to be mapped. 1952 If the client wants all protocols mapped it uses Protocol 0 (zero) 1953 and Internal Port 0 (zero). 1955 The Mapping Nonce value is randomly chosen by the PCP client, 1956 following accepted practices for generating unguessable random 1957 numbers [RFC4086], and is used as part of the validation of PCP 1958 responses (see below) by the PCP client, and validation for mapping 1959 refreshes by the PCP server. The client MUST use a different Mapping 1960 Nonce for each PCP server it communicates with, and it is RECOMMENDED 1961 to choose a new random Mapping Nonce whenever the PCP client is 1962 initialized. The client MAY use a different Mapping Nonce for every 1963 mapping. 1965 11.2.1. Renewing a Mapping 1967 An existing mapping can have its lifetime extended by the PCP client. 1968 To do this, the PCP client sends a new MAP request indicating the 1969 internal port. The PCP MAP request SHOULD also include the currently 1970 assigned external IP address and port in the Suggested External IP 1971 address and Suggested External Port fields, so if the PCP server has 1972 lost state it can recreate the lost mapping with the same parameters. 1974 The PCP client SHOULD renew the mapping before its expiry time, 1975 otherwise it will be removed by the PCP server (see Section 15). To 1976 reduce the risk of inadvertent synchronization of renewal requests, a 1977 random jitter component should be included. It is RECOMMENDED that 1978 PCP clients send a single renewal request packet at a time chosen 1979 with uniform random distribution in the range 1/2 to 5/8 of 1980 expiration time. If no SUCCESS response is received, then the next 1981 renewal request should be sent 3/4 to 3/4 + 1/16 to expiration, and 1982 then another 7/8 to 7/8 + 1/32 to expiration, and so on, subject to 1983 the constraint that renewal requests MUST NOT be sent less than four 1984 seconds apart (a PCP client MUST NOT send a flood of ever-closer- 1985 together requests in the last few seconds before a mapping expires). 1987 11.3. Processing a MAP Request 1989 This section describes the operation of a PCP server when processing 1990 a request with the MAP Opcode. Processing SHOULD be performed in the 1991 order of the following paragraphs. 1993 The Protocol, Internal Port, and Mapping Nonce fields from the MAP 1994 request are copied into the MAP response. If present and processed 1995 by the PCP server the THIRD_PARTY Option is also copied into the MAP 1996 response. 1998 If the Requested Lifetime is non-zero then: 2000 o If both the protocol and internal port are non-zero, it indicates 2001 a request to create a mapping or extend the lifetime of an 2002 existing mapping. If the PCP server or PCP-controlled device does 2003 not support the Protocol, the UNSUPP_PROTOCOL error MUST be 2004 returned. 2006 o If the protocol is non-zero and the internal port is zero, it 2007 indicates a request to create or extend a mapping for all incoming 2008 traffic for that entire Protocol. If this request cannot be 2009 fulfilled in its entirety, the UNSUPP_PROTOCOL error MUST be 2010 returned. 2012 o If both the protocol and internal port are zero, it indicates a 2013 request to create or extend a mapping for all incoming traffic for 2014 all protocols (commonly called a "DMZ host"). If this request 2015 cannot be fulfilled in its entirety, the UNSUPP_PROTOCOL error 2016 MUST be returned. 2018 o If the protocol is zero and the internal port is non-zero, then 2019 the request is invalid and the PCP Server MUST return a 2020 MALFORMED_REQUEST error to the client. 2022 If the requested lifetime is zero, it indicates a request to delete 2023 an existing mapping. 2025 Further processing of the lifetime is described in Section 15. 2027 If operating in the Simple Threat Model (Section 18.1), and the 2028 Internal port, Protocol, and Internal Address match an existing 2029 explicit dynamic mapping, but the Mapping Nonce does not match, the 2030 request MUST be rejected with a NOT_AUTHORIZED error with the 2031 Lifetime of the error indicating duration of that existing mapping. 2032 The PCP server only needs to remember one Mapping Nonce value for 2033 each explicit dynamic mapping. 2035 If the Internal port, Protocol, and Internal Address match an 2036 existing static mapping (which will have no nonce) then a PCP reply 2037 is sent giving the External Address and Port of that static mapping, 2038 using the nonce from the PCP request. The server does not record the 2039 nonce. 2041 If an Option with value less than 128 exists (i.e., mandatory to 2042 process) but that Option does not make sense (e.g., the 2043 PREFER_FAILURE Option is included in a request with lifetime=0), the 2044 request is invalid and generates a MALFORMED_OPTION error. 2046 If the PCP-controlled device is stateless (that is, it does not 2047 establish any per-flow state, and simply rewrites the address and/or 2048 port in a purely algorithmic fashion), the PCP server simply returns 2049 an answer indicating the external IP address and port yielded by this 2050 stateless algorithmic translation. This allows the PCP client to 2051 learn its external IP address and port as seen by remote peers. 2052 Examples of stateless translators include stateless NAT64, 1:1 NAT44, 2053 and NPTv6 [RFC6296], all of which modify addresses but not port 2054 numbers. 2056 It is possible that a mapping might already exist for a requested 2057 Internal Address, Protocol, and Port. If so, the PCP server takes 2058 the following actions: 2060 1. If the MAP request contains the PREFER_FAILURE Option, but the 2061 Suggested External Address and Port do not match the External 2062 Address and Port of the existing mapping, the PCP server MUST 2063 return CANNOT_PROVIDE_EXTERNAL. 2065 2. If the existing mapping is static (created outside of PCP), the 2066 PCP server MUST return the External Address and Port of the 2067 existing mapping in its response and SHOULD indicate a Lifetime 2068 of 2^32-1 seconds, regardless of the Suggested External Address 2069 and Port in the request. 2071 3. If the existing mapping is explicit dynamic inbound (created by a 2072 previous MAP request), the PCP server MUST return the existing 2073 External Address and Port in its response, regardless of the 2074 Suggested External Address and Port in the request. 2075 Additionally, the PCP server MUST update the lifetime of the 2076 existing mapping, in accordance with section 10.5. 2078 4. If the existing mapping is dynamic outbound (created by outgoing 2079 traffic or a previous PEER request), the PCP server SHOULD create 2080 a new explicit inbound mapping, replicating the ports and 2081 addresses from the outbound mapping (but the outbound mapping 2082 continues to exist, and remains in effect if the explicit inbound 2083 mapping is later deleted). 2085 If no mapping exists for the Internal Address, Protocol, and Port, 2086 and the PCP server is able to create a mapping using the Suggested 2087 External Address and Port, it SHOULD do so. This is beneficial for 2088 re-establishing state lost in the PCP server (e.g., due to a reboot). 2089 There are, however, cases where the PCP server is not able to create 2090 a new mapping using the Suggested External Address and Port: 2092 o The Suggested External Address, Protocol, and Port is already 2093 assigned to another existing explicit or implicit mapping (i.e., 2094 is already forwarding traffic to some other internal address and 2095 port). 2097 o The Suggested External Address, Protocol, and Port is already used 2098 by the NAT gateway for one of its own services. For example, TCP 2099 port 80 for the NAT gateway's own configuration web pages, or UDP 2100 ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT 2101 create client mappings for External UDP ports 5350 or 5351. 2103 o The Suggested External Address, Protocol, and Port is otherwise 2104 prohibited by the PCP server's policy. 2106 o The Suggested External IP Address, Protocol, or Suggested Port are 2107 invalid or invalid combinations (e.g., External Address 127.0.0.1, 2108 ::1, a multicast address, or the Suggested Port is not valid for 2109 the Protocol). 2111 o The Suggested External Address does not belong to the NAT gateway. 2113 o The Suggested External Address is not configured to be used as an 2114 external address of the firewall or NAT gateway. 2116 If the PCP server cannot assign the Suggested External Address, 2117 Protocol, and Port, then: 2119 o If the request contained the PREFER_FAILURE Option, then the PCP 2120 server MUST return CANNOT_PROVIDE_EXTERNAL. 2122 o If the request did not contain the PREFER_FAILURE Option, and the 2123 PCP server can assign some other External Address and Port for 2124 that protocol, then the PCP server MUST do so and return the newly 2125 assigned External Address and Port in the response. In no case is 2126 the client penalized for a 'poor' choice of Suggested External 2127 Address and Port. The Suggested External Address and Port may be 2128 used by the server to guide its choice of what External Address 2129 and Port to assign, but in no case do they cause the server to 2130 fail to allocate an External Address and Port where otherwise it 2131 would have succeeded. The presence of a non-zero Suggested 2132 External Address or Port is merely a hint; it never does any harm. 2134 By default, a PCP-controlled device MUST NOT create mappings for a 2135 protocol not indicated in the request. For example, if the request 2136 was for a TCP mapping, a UDP mapping MUST NOT be created. 2138 Mappings typically consume state on the PCP-controlled device, and it 2139 is RECOMMENDED that a per-host and/or per-subscriber limit be 2140 enforced by the PCP server to prevent exhausting the mapping state. 2141 If this limit is exceeded, the result code USER_EX_QUOTA is returned. 2143 If all of the preceding operations were successful (did not generate 2144 an error response), then the requested mapping is created or 2145 refreshed as described in the request and a SUCCESS response is 2146 built. 2148 11.4. Processing a MAP Response 2150 This section describes the operation of the PCP client when it 2151 receives a PCP response for the MAP Opcode. 2153 After performing common PCP response processing, the response is 2154 further matched with a previously-sent MAP request by comparing the 2155 Internal IP Address (the destination IP address of the PCP response, 2156 or other IP address specified via the THIRD_PARTY option), the 2157 Protocol, the Internal Port, and the Mapping Nonce. Other fields are 2158 not compared, because the PCP server sets those fields. The PCP 2159 server will send a Mapping Update (Section 14.2) if the mapping 2160 changes (e.g., due to IP renumbering). 2162 If the result code is NO_RESOURCES and the request was for the 2163 creation or renewal of a mapping, then the PCP client SHOULD NOT send 2164 further requests for any new mappings to that PCP server for the 2165 (limited) value of the Lifetime. If the result code is NO_RESOURCES 2166 and the request was for the deletion of a mapping, then the PCP 2167 client SHOULD NOT send further requests of *any kind* to that PCP 2168 server for the (limited) value of the Lifetime. 2170 On a success response, the PCP client can use the External IP Address 2171 and Port as needed. Typically the PCP client will communicate the 2172 External IP Address and Port to another host on the Internet using an 2173 application-specific rendezvous mechanism such as DNS SRV records. 2175 As long as renewal is desired, the PCP client MUST also set a timer 2176 or otherwise schedule an event to renew the mapping before its 2177 lifetime expires. Renewing a mapping is performed by sending another 2178 MAP request, exactly as described in Section 11.2, except that the 2179 Suggested External Address and Port SHOULD be set to the values 2180 received in the response. From the PCP server's point of view a MAP 2181 request to renew a mapping is identical to a MAP request to create a 2182 new mapping, and is handled identically. Indeed, in the event of PCP 2183 server state loss, a renewal request from a PCP client will appear to 2184 the server to be a request to create a new mapping, with a particular 2185 Suggested External Address and Port, which happens to be what the PCP 2186 server previously assigned. See also Section 16.3.1. 2188 On an error response, the client SHOULD NOT repeat the same request 2189 to the same PCP server within the lifetime returned in the response. 2191 11.5. Address Change Events 2193 A customer premises router might obtain a new External IP address, 2194 for a variety of reasons including a reboot, power outage, DHCP lease 2195 expiry, or other action by the ISP. If this occurs, traffic 2196 forwarded to the host's previous address might be delivered to 2197 another host which now has that address. This affects all mapping 2198 types, whether implicit or explicit. This same problem already 2199 occurs today when a host's IP address is re-assigned, without PCP and 2200 without an ISP-operated CGN. The solution is the same as today: the 2201 problems associated with host renumbering are caused by host 2202 renumbering, and are eliminated if host renumbering is avoided. PCP 2203 defined in this document does not provide machinery to reduce the 2204 host renumbering problem. 2206 When an Internal Host changes its Internal IP address (e.g., by 2207 having a different address assigned by the DHCP server) the NAT (or 2208 firewall) will continue to send traffic to the old IP address. 2209 Typically, the Internal Host will no longer receive traffic sent to 2210 that old IP address. Assuming the Internal Host wants to continue 2211 receiving traffic, it needs to install new mappings for its new IP 2212 address. The suggested external port field will not be fulfilled by 2213 the PCP server, in all likelihood, because it is still being 2214 forwarded to the old IP address. Thus, a mapping is likely to be 2215 assigned a new External Port number and/or External IP Address. Note 2216 that such host renumbering is not expected to happen routinely on a 2217 regular basis for most hosts, since most hosts renew their DHCP 2218 leases before they expire (or re-request the same address after 2219 reboot) and most DHCP servers honor such requests and grant the host 2220 the same address it was previously using before the reboot. 2222 A host might gain or lose interfaces while existing mappings are 2223 active (e.g., Ethernet cable plugged in or removed, joining/leaving a 2224 Wi-Fi network). Because of this, if the PCP client is sending a PCP 2225 request to maintain state in the PCP server, it SHOULD ensure those 2226 PCP requests continue to use the same interface (e.g., when 2227 refreshing mappings). If the PCP client is sending a PCP request to 2228 create new state in the PCP server, it MAY use a different source 2229 interface or different source address. 2231 11.6. Learning the External IP Address Alone 2233 NAT-PMP [I-D.cheshire-nat-pmp] includes a mechanism to allow clients 2234 to learn the External IP Address alone, without also requesting a 2235 port mapping. NAT-PMP was designed for residential NAT gateways, 2236 where such an operation makes sense because the residential NAT 2237 gateway has only one External IP Address. PCP has broader scope, and 2238 also supports Carrier-Grade NATs (CGN) which may have a pool of 2239 External IP Addresses, not just one. A client may not be assigned 2240 any particular External IP Address from that pool until it has at 2241 least one implicit, explicit or static port mapping, and even then 2242 only for as long as that mapping remains valid. Client software that 2243 just wishes to display the user's External IP Address for cosmetic 2244 purposes can achieve that by requesting a short-lived mapping (e.g., 2245 to the Discard service (TCP/9 or UDP/9) or some other port) and then 2246 displaying the resulting External IP Address. However, once that 2247 mapping expires a subsequent implicit or explicit dynamic mapping 2248 might be mapped to a different external IP address. 2250 12. PEER Opcode 2252 This section defines an Opcode for controlling dynamic mappings. 2254 PEER: Create a new dynamic outbound mapping to a remote peer's IP 2255 address and port, or extend the lifetime of an existing 2256 outbound mapping. 2258 The use of this Opcodes is described in this section. 2260 PCP Servers SHOULD provide a configuration option to allow 2261 administrators to disable PEER support if they wish. 2263 Because a mapping created or managed by PEER behaves almost exactly 2264 like an implicit dynamic mapping created as a side-effect of a packet 2265 (e.g., TCP SYN) sent by the host, mappings created or managed using 2266 PCP PEER requests may be Endpoint Independent Mappings (EIM) or 2267 Endpoint Dependent Mappings (EDM), with Endpoint Independent 2268 Filtering (EIF) or Endpoint Dependent Filtering (EDF), consistent 2269 with the existing behavior of the NAT gateway or firewall in question 2270 for implicit outbound mappings it creates automatically as a result 2271 of observing outgoing traffic from Internal Hosts. 2273 12.1. PEER Operation Packet Formats 2275 The PEER Opcode allows a PCP client to create a new explicit dynamic 2276 outbound mapping (which functions similarly to an outbound mapping 2277 created implicitly when a host sends an outbound TCP SYN) or to 2278 extend the lifetime of an existing outbound mapping. 2280 The following diagram shows the Opcode layout for the PEER Opcode. 2281 This packet format is aligned with the response packet format: 2283 0 1 2 3 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | | 2287 | Mapping Nonce (96 bits) | 2288 | | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Protocol | Reserved (24 bits) | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | Internal Port | Suggested External Port | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | | 2295 | Suggested External IP Address (128 bits) | 2296 | | 2297 | | 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | Remote Peer Port | Reserved (16 bits) | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | | 2302 | Remote Peer IP Address (128 bits) | 2303 | | 2304 | | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 Figure 11: PEER Opcode Request 2309 These fields are described below: 2311 Requested Lifetime (in common header): Requested lifetime of this 2312 mapping, in seconds. Note that it is not possible to reduce the 2313 lifetime of a mapping (or delete it, with requested lifetime=0) 2314 using PEER. 2316 Mapping Nonce: Random value chosen by the PCP client. See 2317 Section 12.2. Zero is a legal value (but unlikely, occurring in 2318 roughly one in 2^96 requests). 2320 Protocol: Upper-layer protocol associated with this Opcode. Values 2321 are taken from the IANA protocol registry [proto_numbers]. For 2322 example, this field contains 6 (TCP) if the Opcode is describing a 2323 TCP mapping. Protocol MUST NOT be zero. 2325 Reserved: 24 reserved bits, MUST be set to 0 on transmission and 2326 MUST be ignored on reception. 2328 Internal Port: Internal port for the mapping. Internal Port MUST 2329 NOT be zero. 2331 Suggested External Port: Suggested external port for the mapping. 2332 If the PCP client does not know the external port, or does not 2333 have a preference, it MUST use 0. 2335 Suggested External IP Address: Suggested External IP Address for the 2336 mapping. If the PCP client does not know the external address, or 2337 does not have a preference, it MUST use the address-family- 2338 specific all-zeroes address (see Section 5). 2340 Remote Peer Port: Remote peer's port for the mapping. Remote Peer 2341 Port MUST NOT be zero. 2343 Reserved: 16 reserved bits, MUST be set to 0 on transmission and 2344 MUST be ignored on reception. 2346 Remote Peer IP Address: Remote peer's IP address. This is from the 2347 perspective of the PCP client, so that the PCP client does not 2348 need to concern itself with NAT64 or NAT46 (which both cause the 2349 client's idea of the remote peer's IP address to differ from the 2350 remote peer's actual IP address). This field allows the PCP 2351 client and PCP server to disambiguate multiple connections from 2352 the same port on the Internal Host to different servers. An IPv6 2353 address is represented directly, and an IPv4 address is 2354 represented using the IPv4-mapped address syntax (Section 5). 2356 When attempting to re-create a lost mapping, the Suggested External 2357 IP Address and Port are set to the External IP Address and Port 2358 fields received in a previous PEER response from the PCP server. On 2359 an initial PEER request, the External IP Address and Port are set to 2360 zero. 2362 Note that semantics similar to the PREFER_FAILURE option are 2363 automatically implied by PEER requests. If the Suggested External IP 2364 Address or Suggested External Port fields are non-zero, and the PCP 2365 server is unable to honor the Suggested External IP Address, 2366 Protocol, or Port, then the PCP server MUST return a 2367 CANNOT_PROVIDE_EXTERNAL error response. The PREFER_FAILURE Option is 2368 neither required nor allowed in PEER requests, and if PCP server 2369 receives a PEER request containing the PREFER_FAILURE Option it MUST 2370 return a MALFORMED_REQUEST error response. 2372 The following diagram shows the Opcode response for the PEER Opcode: 2374 0 1 2 3 2375 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 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | | 2378 | Mapping Nonce (96 bits) | 2379 | | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | Protocol | Reserved (24 bits) | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | Internal Port | Assigned External Port | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | | 2386 | Assigned External IP Address (128 bits) | 2387 | | 2388 | | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Remote Peer Port | Reserved (16 bits) | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | | 2393 | Remote Peer IP Address (128 bits) | 2394 | | 2395 | | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 Figure 12: PEER Opcode Response 2400 Lifetime (in common header): On a success response, this indicates 2401 the lifetime for this mapping, in seconds. On an error response, 2402 this indicates how long clients should assume they'll get the same 2403 error response from the PCP server if they repeat the same 2404 request. 2406 Mapping Nonce: Copied from the request. 2408 Protocol: Copied from the request. 2410 Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST 2411 be ignored on reception. 2413 Internal Port: Copied from request. 2415 Assigned External Port: On a success response, this is the assigned 2416 external port for the mapping. On an error response, the 2417 Suggested External Port is copied from the request. 2419 Assigned External IP Address: On a success response, this is the 2420 assigned external IPv4 or IPv6 address for the mapping. On an 2421 error response, the Suggested External IP Address is copied from 2422 the request. 2424 Remote Peer port: Copied from request. 2426 Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST 2427 be ignored on reception. 2429 Remote Peer IP Address: Copied from the request. 2431 12.2. Generating a PEER Request 2433 This section describes the operation of a client when generating a 2434 message with the PEER Opcode. 2436 The PEER Opcode MAY be sent before or after establishing bi- 2437 directional communication with the remote peer. 2439 If sent before, this is considered a PEER-created mapping which 2440 creates a new dynamic outbound mapping in the PCP-controlled device. 2441 This is useful for restoring a mapping after a NAT has lost its 2442 mapping state (e.g., due to a crash). 2444 If sent after, this allows the PCP client to learn the IP address, 2445 port, and lifetime of the assigned External Address and Port for the 2446 existing implicit dynamic outbound mapping, and potentially to extend 2447 this lifetime (for the purpose described in Section 10.3). 2449 The Mapping Nonce value is randomly chosen by the PCP client, 2450 following accepted practices for generating unguessable random 2451 numbers [RFC4086], and is used as part of the validation of PCP 2452 responses (see below) by the PCP client, and validation for mapping 2453 refreshes by the PCP server. The client MUST use a different Mapping 2454 Nonce for each PCP server it communicates with, and it is RECOMMENDED 2455 to choose a new random Mapping Nonce whenever the PCP client is 2456 initialized. The client MAY use a different Mapping Nonce for every 2457 mapping. 2459 The PEER Opcode contains a Remote Peer Address field, which is always 2460 from the perspective of the PCP client. Note that when the PCP- 2461 controlled device is performing address family translation (NAT46 or 2462 NAT64), the remote peer address from the perspective of the PCP 2463 client is different from the remote peer address on the other side of 2464 the address family translation device. 2466 12.3. Processing a PEER Request 2468 This section describes the operation of a server when receiving a 2469 request with the PEER Opcode. Processing SHOULD be performed in the 2470 order of the following paragraphs. 2472 The following fields from a PEER request are copied into the 2473 response: Protocol, Internal Port, Remote Peer IP Address, Remote 2474 Peer Port, and Mapping Nonce. 2476 When an implicit dynamic mapping is created, some NATs and firewalls 2477 validate destination addresses and will not create an implicit 2478 dynamic mapping if the destination address is invalid (e.g., 2479 127.0.0.1). If a PCP-controlled device does such validation for 2480 implicit dynamic mappings, it SHOULD also do a similar validation of 2481 the Remote Peer IP Address, Protocol, and Port for PEER-created 2482 explicit dynamic mappings. If the validation determines the Remote 2483 Peer IP Address of a PEER request is invalid, then no mapping is 2484 created, and a MALFORMED_REQUEST error result is returned. 2486 On receiving the PEER Opcode, the PCP server examines the mapping 2487 table for a matching five-tuple { Protocol, Internal Address, 2488 Internal Port, Remote Peer Address, Remote Peer Port }. 2490 If no matching mapping is found, and the Suggested External Address 2491 and Port are either zero or can be honored for the specified 2492 Protocol, a new mapping is created. By having PEER create such a 2493 mapping, we avoid a race condition between the PEER request or the 2494 initial outgoing packet arriving at the NAT or firewall device first, 2495 and allow PEER to be used to recreate an outbound dynamic mapping 2496 (see last paragraph of Section 16.3.1). Thereafter, this PEER- 2497 created mapping is treated as if it was an implicit dynamic outbound 2498 mapping (e.g., as if the PCP client sent a TCP SYN) and a Lifetime 2499 appropriate to such a mapping is returned (note: on many NATs and 2500 firewalls, such mapping lifetimes are very short until the bi- 2501 directional traffic is seen by the NAT or firewall). 2503 If no matching mapping is found, and the Suggested External Address 2504 and Port cannot be honored, then no new state is created, and the 2505 error CANNOT_PROVIDE_EXTERNAL is returned. 2507 If a matching mapping is found, but no pervious PEER Opcode was 2508 successfully processed for this mapping, then the Suggested External 2509 Address and Port values in the request are ignored, Lifetime of that 2510 mapping is adjusted as described below, and information about the 2511 existing mapping is returned. This allows a client to explicitly 2512 extend the lifetime of an existing mapping and/or to learn an 2513 existing mapping's External Address, Port and lifetime. The Mapping 2514 Nonce is remembered for this mapping. 2516 If operating in the Simple Threat Model (Section 18.1), and the 2517 Internal port, Protocol, and Internal Address match a mapping that 2518 already exists, but the Mapping Nonce does not match (that is, a 2519 previous PEER request was processed), the request MUST be rejected 2520 with a NOT_AUTHORIZED error with the Lifetime of the error indicating 2521 duration of that existing mapping. The PCP server only needs to 2522 remember one Mapping Nonce value for each mapping. 2524 Processing the lifetime value of the PEER Opcode is described in 2525 Section 15. Sending a PEER request with a very short Requested 2526 Lifetime can be used to query the lifetime of an existing mapping. 2528 If all of the preceding operations were successful (did not generate 2529 an error response), then a SUCCESS response is generated, with the 2530 Lifetime field containing the lifetime of the mapping. 2532 If a PEER-created or PEER-managed mapping is not renewed using PEER, 2533 then it reverts to the NAT's usual behavior for implicit mappings, 2534 e.g., continued outbound traffic keeps the mapping alive, as per the 2535 NAT or firewall device's existing policy. A PEER-created or PEER- 2536 managed mapping may be terminated at any time by action of the TCP 2537 client or server (e.g., due to TCP FIN or TCP RST), as per the NAT or 2538 firewall device's existing policy. 2540 12.4. Processing a PEER Response 2542 This section describes the operation of a client when processing a 2543 response with the PEER Opcode. 2545 After performing common PCP response processing, the response is 2546 further matched with an outstanding PEER request by comparing the 2547 Internal IP Address (the destination IP address of the PCP response, 2548 or other IP address specified via the THIRD_PARTY option), the 2549 Protocol, the Internal Port, the Remote Peer Address, the Remote Peer 2550 Port, and the Mapping Nonce. Other fields are not compared, because 2551 the PCP server sets those fields to provide information about the 2552 mapping created by the Opcode. The PCP server will send a Mapping 2553 Update (Section 14.2) if the mapping changes (e.g., due to IP 2554 renumbering). 2556 If the result code is NO_RESOURCES and the request was for the 2557 creation or renewal of a mapping, then the PCP client SHOULD NOT send 2558 further requests for any new mappings to that PCP server for the 2559 (limited) value of the Lifetime. 2561 On a successful response, the application can use the assigned 2562 lifetime value to reduce its frequency of application keepalives for 2563 that particular NAT mapping. Of course, there may be other reasons, 2564 specific to the application, to use more frequent application 2565 keepalives. For example, the PCP assigned lifetime could be one hour 2566 but the application may want to maintain state on its server (e.g., 2567 "busy" / "away") more frequently than once an hour. If the response 2568 indicates an unexpected IP address or port (e.g., due to IP 2569 renumbering), the PCP client will want to re-establish its connection 2570 to its remote server. 2572 If the PCP client wishes to keep this mapping alive beyond the 2573 indicated lifetime, it MAY rely on continued inside-to-outside 2574 traffic to ensure the mapping will continue to exist, or it MAY issue 2575 a new PCP request prior to the expiration. The recommended timings 2576 for renewing PEER mappings are the same as for MAP mappings, as 2577 described in Section 11.2.1. 2579 Note: Implementations need to expect the PEER response may contain 2580 an External IP Address with a different family than the Remote 2581 Peer IP Address, e.g., when NAT64 or NAT46 are being used. 2583 13. Options for MAP and PEER Opcodes 2585 This section describes Options for the MAP and PEER Opcodes. These 2586 Options MUST NOT appear with other Opcodes, unless permitted by those 2587 other Opcodes. 2589 13.1. THIRD_PARTY Option for MAP and PEER Opcodes 2591 This Option is used when a PCP client wants to control a mapping to 2592 an Internal Host other than itself. This is used with both MAP and 2593 PEER Opcodes. 2595 Due to security concerns with the THIRD_PARTY option, this Option 2596 MUST NOT be implemented or used unless the network on which the PCP 2597 messages are to be sent is fully trusted. For example if access 2598 control lists are installed on the PCP client, PCP server, and the 2599 network between them, so those ACLs allow only communications from a 2600 trusted PCP client to the PCP server. 2602 A management device would use this Option to control a PCP server on 2603 behalf of users. For example, a management device located in a 2604 network operations center, which presents a user interface to end 2605 users or to network operations staff, and issues PCP requests with 2606 the THIRD_PARTY option to the appropriate PCP server. 2608 The THIRD_PARTY Option is formatted as follows: 2610 0 1 2 3 2611 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 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | Option Code=1 | Reserved | Option Length=16 | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | | 2616 | Internal IP Address (128 bits) | 2617 | | 2618 | | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 Figure 13: THIRD_PARTY Option 2623 The fields are described below: 2625 Internal IP Address: Internal IP address for this mapping. 2627 Option Name: THIRD_PARTY 2628 Number: 1 2629 Purpose: Indicates the MAP or PEER request is for a host other 2630 than the host sending the PCP Option. 2631 Valid for Opcodes: MAP, PEER 2632 Length: 16 octets 2633 May appear in: request. May appear in response only if it 2634 appeared in the associated request. 2635 Maximum occurrences: 1 2637 A THIRD_PARTY Option MUST NOT contain the same address as the source 2638 address of the packet. This is because many PCP servers may not 2639 implement the THIRD_PARTY Option at all, and with those servers a 2640 client redundantly using the THIRD_PARTY Option to specify its own IP 2641 address would cause such mapping requests to fail where they would 2642 otherwise have succeeded. A PCP server receiving a THIRD_PARTY 2643 Option specifying the same address as the source address of the 2644 packet MUST return a MALFORMED_REQUEST result code. 2646 A PCP server MAY be configured to permit or to prohibit the use of 2647 the THIRD_PARTY Option. If this Option is permitted, properly 2648 authorized clients may perform these operations on behalf of other 2649 hosts. If this Option is prohibited, and a PCP server receives a PCP 2650 MAP request with a THIRD_PARTY Option, it MUST generate a 2651 UNSUPP_OPTION response. 2653 It is RECOMMENDED that customer premises equipment implementing a PCP 2654 Server be configured to prohibit third party mappings by default. 2655 With this default, if a user wants to create a third party mapping, 2656 the user needs to interact out-of-band with their customer premises 2657 router (e.g., using its HTTP administrative interface). 2659 It is RECOMMENDED that service provider NAT and firewall devices 2660 implementing a PCP Server be configured to permit the THIRD_PARTY 2661 Option, when sent by a properly authorized host. If the packet 2662 arrives from an unauthorized host, the PCP server MUST generate an 2663 UNSUPP_OPTION error. 2665 Note that the THIRD_PARTY Option is not needed for today's common 2666 scenario of an ISP offering a single IP address to a customer who is 2667 using NAT to share that address locally, since in this scenario all 2668 the customer's hosts appear, from the point of view of the ISP, to be 2669 a single host. 2671 When a PCP client is using the THIRD_PARTY Option to make and 2672 maintain mappings on behalf of some other device, it may be 2673 beneficial if, where possible, the PCP client verifies that the other 2674 device is actually present and active on the network. Otherwise the 2675 PCP client risks maintaining those mappings forever, long after the 2676 device that required them has gone. This would defeat the purpose of 2677 PCP mappings having a finite lifetime so that they can be 2678 automatically deleted after they are no longer needed. 2680 13.2. PREFER_FAILURE Option for MAP Opcode 2682 This Option is only used with the MAP Opcode. 2684 This Option indicates that if the PCP server is unable to map both 2685 the Suggested External Port and Suggested External Address, the PCP 2686 server should not create a mapping. This differs from the behavior 2687 without this Option, which is to create a mapping. 2689 The PREFER_FAILURE Option is formatted as follows: 2691 0 1 2 3 2692 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 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | Option Code=2 | Reserved | Option Length=0 | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 Figure 14: PREFER_FAILURE Option 2699 Option Name: PREFER_FAILURE 2700 Number: 2 2701 Purpose: indicates that the PCP server should not create an 2702 alternative mapping if the suggested external port and address 2703 cannot be mapped. 2704 Valid for Opcodes: MAP 2705 Length: 0 2706 May appear in: request. May appear in response only if it 2707 appeared in the associated request. 2708 Maximum occurrences: 1 2710 The result code CANNOT_PROVIDE_EXTERNAL is returned if the Suggested 2711 External Address, Protocol, and Port cannot be mapped. This can 2712 occur because the External Port is already mapped to another host's 2713 outbound dynamic mapping, an inbound dynamic mapping, a static 2714 mapping, or the same Internal Address, Protocol, and Port already has 2715 an outbound dynamic mapping which is mapped to a different External 2716 Port than suggested. This can also occur because the External 2717 Address is no longer available (e.g., due to renumbering). The 2718 server MAY set the Lifetime in the response to the remaining lifetime 2719 of the conflicting mapping + TIME_WAIT [RFC0793], rounded up to the 2720 next larger integer number of seconds. 2722 PREFER_FAILURE is never necessary for a PCP client to manage mappings 2723 for itself, and its use causes additional work in the PCP client and 2724 in the PCP server. This Option exists for interworking with non-PCP 2725 mapping protocols that have different semantics than PCP (e.g., UPnP 2726 IGDv1 interworking [I-D.ietf-pcp-upnp-igd-interworking], where the 2727 semantics of UPnP IGDv1 only allow the UPnP IGDv1 client to dictate 2728 mapping a specific port), or separate port allocation systems which 2729 allocate ports to a subscriber (e.g., a subscriber-accessed web 2730 portal operated by the same ISP that operates the PCP server). A PCP 2731 server MAY support this Option, if its designers wish to support such 2732 downstream devices or separate port allocation systems. PCP servers 2733 that are not intended to interface with such systems are not required 2734 to support this Option. PCP clients other than UPnP IGDv1 2735 interworking clients or other than a separate port allocation system 2736 SHOULD NOT use this Option because it results in inefficient 2737 operation, and they cannot safely assume that all PCP servers will 2738 implement it. It is anticipated that this Option will be deprecated 2739 in the future as more clients adopt PCP natively and the need for 2740 this Option declines. 2742 If a PCP request contains the PREFER_FAILURE option and has zero in 2743 the Suggested External Port field, or has the all-zeros IPv4 or all- 2744 zeros IPv6 address in the Suggested External Address field, it is 2745 invalid. The PCP server MUST reject such a message with the 2746 MALFORMED_OPTION error code. 2748 PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE 2749 requests, to protect themselves from a rapid flurry of 65535 2750 consecutive PREFER_FAILURE requests from clients probing to discover 2751 which external ports are available. 2753 There can exist a race condition between the MAP Opcode using the 2754 PREFER_FAILURE option and Mapping Update (Section 14.2). For 2755 example, a previous host on the local network could have previously 2756 had the same Internal Address, with a mapping for the same Internal 2757 Port. At about the same moment that the current host sends a MAP 2758 Request using the PREFER_FAILURE option, the PCP server could send a 2759 spontaneous mapping update for the old mapping due to an external 2760 configuration change, which could appear to be a reply to the new 2761 mapping request. Because of this, the PCP client MUST validate that 2762 the External IP Address, Protocol, Port and Nonce in a success 2763 response matches the associated suggested values from the request. 2764 If they don't match, it is because the Mapping Update was sent before 2765 the MAP request was processed. 2767 13.3. FILTER Option for MAP Opcode 2769 This Option is only used with the MAP Opcode. 2771 This Option indicates that filtering incoming packets is desired. 2772 The protocol being filtered is indicated by the Protocol field in the 2773 MAP Request, and the Remote Peer IP Address and Remote Peer Port of 2774 the FILTER Option indicate the permitted remote peer's source IP 2775 address and source port for packets from the Internet; other traffic 2776 from other addresses is blocked. The remote peer prefix length 2777 indicates the length of the remote peer's IP address that is 2778 significant; this allows a single Option to permit an entire subnet. 2779 After processing this MAP request containing the FILTER Option and 2780 generating a successful response, the PCP-controlled device will drop 2781 packets received on its public-facing interface that don't match the 2782 filter fields. After dropping the packet, if its security policy 2783 allows, the PCP-controlled device MAY also generate an ICMP error in 2784 response to the dropped packet. 2786 The use of the FILTER Option can be seen as a performance 2787 optimization. Since all software using PCP to receive incoming 2788 connections also has to deal with the case where it may be directly 2789 connected to the Internet and receive unrestricted incoming TCP 2790 connections and UDP packets, if it wishes to restrict incoming 2791 traffic to a specific source address or group of source addresses 2792 such software already needs to check the source address of incoming 2793 traffic and reject unwanted traffic. However, the FILTER Option is a 2794 particularly useful performance optimization for battery powered 2795 wireless devices, because it can enable them to conserve battery 2796 power by not having to wake up just to reject unwanted traffic. 2798 The FILTER Option is formatted as follows: 2800 0 1 2 3 2801 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 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 | Option Code=3 | Reserved | Option Length=20 | 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 | Reserved | Prefix Length | Remote Peer Port | 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 | | 2808 | Remote Peer IP address (128 bits) | 2809 | | 2810 | | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 Figure 15: FILTER Option layout 2815 These fields are described below: 2817 Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored 2818 when received. 2820 Prefix Length: indicates how many bits of the IPv4 or IPv6 address 2821 are relevant for this filter. The value 0 indicates "no filter", 2822 and will remove all previous filters. See below for detail. 2824 Remote Peer Port: the port number of the remote peer. The value 0 2825 indicates "all ports". 2827 Remote Peer IP address: The IP address of the remote peer. 2829 Option Name: FILTER 2830 Number: 3 2831 Purpose: specifies a filter for incoming packets 2832 Valid for Opcodes: MAP 2833 Length: 20 octets 2834 May appear in: request. May appear in response only if it 2835 appeared in the associated request. 2836 Maximum occurrences: as many as fit within maximum PCP message 2837 size 2839 The Prefix Length indicates how many bits of the address are used for 2840 the filter. For IPv4 addresses (which are encoded using the IPv4- 2841 mapped address format (::FFFF:0:0/96)), this means valid prefix 2842 lengths are between 96 and 128 bits, inclusive. That is, add 96 to 2843 the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are 2844 between 0 and 128 bits, inclusive. Values outside those ranges cause 2845 the PCP server to return the MALFORMED_OPTION result code. 2847 If multiple occurrences of the FILTER Option exist in the same MAP 2848 request, they are processed in the order received (as per normal PCP 2849 Option processing) and they MAY overlap the filtering requested. If 2850 an existing mapping exists (with or without a filter) and the server 2851 receives a MAP request with FILTER, the filters indicated in the new 2852 request are added to any existing filters. If a MAP request has a 2853 lifetime of 0 and contains the FILTER Option, the error 2854 MALFORMED_OPTION is returned. 2856 If any occurrences of the FILTER Option in a request packet are not 2857 successfully processed then an error is returned (e.g., 2858 MALFORMED_OPTION if one of the Options was malformed) and as with 2859 other PCP errors, returning an error causes no state to be changed in 2860 the PCP server or in the PCP-controlled device. 2862 To remove all existing filters, the Prefix Length 0 is used. There 2863 is no mechanism to remove a specific filter. 2865 To change an existing filter, the PCP client sends a MAP request 2866 containing two FILTER Options, the first Option containing a Prefix 2867 Length of 0 (to delete all existing filters) and the second 2868 containing the new remote peer's IP address, protocol, and port. 2869 Other FILTER Options in that PCP request, if any, add more allowed 2870 Remote Peers. 2872 The PCP server or the PCP-controlled device is expected to have a 2873 limit on the number of remote peers it can support. This limit might 2874 be as small as one. If a MAP request would exceed this limit, the 2875 entire MAP request is rejected with the result code 2876 EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. 2878 All PCP servers MUST support at least one filter per MAP mapping. 2880 14. Rapid Recovery 2882 PCP includes a rapid recovery feature, which allows PCP clients to 2883 repair failed mappings within seconds, rather than the minutes or 2884 hours it might take if they relied solely on waiting for the next 2885 routine renewal of the mapping. Mapping failures may occur when a 2886 NAT gateway is rebooted and loses its mapping state, or when a NAT 2887 gateway has its external IP address changed so that its current 2888 mapping state becomes invalid. 2890 The PCP rapid recovery feature enables users to, for example, connect 2891 to remote machines using ssh, and then reboot their NAT or firewall 2892 device (or even replace it with completely new hardware) without 2893 losing their established ssh connections. 2895 Use of PCP rapid recovery is a performance optimization to PCP's 2896 routine self-healing. Without rapid recovery, PCP clients will still 2897 recreate their correct state when they next renew their mappings, but 2898 this routine self-healing process may take hours rather than seconds, 2899 and will probably not happen fast enough to prevent active TCP 2900 connections from timing out. 2902 There are two mechanisms to perform rapid recovery, described below. 2903 A PCP server that can lose state (e.g., due to reboot) or might have 2904 a mapping change (e.g., due to IP renumbering) MUST implement either 2905 the Announce Opcode or the Mapping Update mechanism and SHOULD 2906 implement both mechanisms. Failing to implement and deploy a rapid 2907 recovery mechanism will encourage application developers to feel the 2908 need to refresh their PCP state more frequently than necessary, 2909 causing more network traffic. 2911 14.1. ANNOUNCE Opcode 2913 This rapid recovery mechanism uses the ANNOUNCE Opcode. When the PCP 2914 server loses its state (e.g., it lost its state when rebooted), it 2915 sends the ANNOUNCE response to the link-scoped multicast address 2916 (specific address explained below) if a multicast network exists on 2917 its local interface or, if configured with the IP address(es) and 2918 port(s) of PCP client(s), sends unicast ANNOUNCE responses to those 2919 address(es) and port(s). This means ANNOUNCE may not be available on 2920 all networks (such as networks without a multicast link between the 2921 PCP server and its PCP clients). Additionally, an ANNOUNCE request 2922 can be sent (unicast) by a PCP client which elicits a unicast 2923 ANNOUNCE response like any other Opcode. 2925 14.1.1. ANNOUNCE Operation 2927 The PCP ANNOUNCE Opcode requests and respones have no Opcode-specific 2928 payload (that is, the length of the Opcode-specific data is zero). 2929 The Requested Lifetime field of requests and Lifetime field of 2930 responses are both set to 0 on transmission and ignored on reception. 2932 If a PCP server receives an ANNOUNCE request, it first parses it and 2933 generates a SUCCESS if parsing and processing of ANNOUNCE is 2934 successful. An error is generated if the Client's IP Address field 2935 does not match the packet source address, or the request packet is 2936 otherwise malformed, such as packet length less than 24 octets. Note 2937 that, in the future, Options MAY be sent with the PCP ANNOUNCE 2938 Opcode; PCP clients and servers need to be prepared to receive 2939 Options with the ANNOUNCE Opcode. 2941 Discussion: Client-to-server request messages are sent to 2942 listening UDP port 5351 on the server; server-to-client multicast 2943 notifications are sent to listening UDP port 5350 on the client. 2944 The reason the same UDP port is not used for both purposes is that 2945 a single device may have multiple roles. For example, a multi- 2946 function home gateway that provides NAT service (PCP server) may 2947 also provide printer sharing (which wants a PCP client), or a home 2948 computer (PCP client) may also provide "Internet Sharing" (NAT) 2949 functionality (which needs to offer PCP service). Such devices 2950 need to act as both a PCP Server and a PCP Client at the same 2951 time, and the software that implements the PCP Server on the 2952 device may not be the same software component that implements the 2953 PCP Client. The software that implements the PCP Server needs to 2954 listen for unicast client requests, whereas the software that 2955 implements the PCP Client needs to listen for multicast restart 2956 announcements. In many networking APIs it is difficult or 2957 impossible to have two independent clients listening for both 2958 unicasts and multicasts on the same port at the same time. For 2959 this reason, two ports are used. 2961 14.1.2. Generating and Processing a Solicited ANNOUNCE Message 2963 The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client. The 2964 Requested Lifetime value MUST be set to zero. 2966 When the PCP server receives the ANNOUNCE Opcode and successfully 2967 parses and processes it, it generates SUCCESS response with an 2968 Assigned Lifetime of zero. 2970 This functionality allows a PCP client to determine a server's Epoch, 2971 or to determine if a PCP server is running, without changing the 2972 server's state. 2974 14.1.3. Generating and Processing an Unsolicited ANNOUNCE Message 2976 When sending unsolicited responses, the ANNOUNCE Opcode MUST have 2977 Result Code equal to zero (SUCCESS), and the packet MUST be sent from 2978 the unicast IP address and UDP port number on which PCP requests are 2979 received (so PCP response processing accepts the message, see 2980 Section 8.3). This message is most typically multicast, but can also 2981 be unicast. Multicast PCP restart announcements are sent to 2982 224.0.0.1:5350 and/or [ff02::1]:5350, as described below. Sending 2983 PCP restart announcements via unicast requires that the PCP server 2984 know the IP address(es) and port(s) of its listening clients, which 2985 means that sending PCP restart announcements via unicast is only 2986 applicable to PCP servers that retain knowledge of the IP address(es) 2987 and port(s) of their clients even after they otherwise lose the rest 2988 of their state. 2990 When a PCP server device that implements this functionality reboots, 2991 restarts its NAT engine, or otherwise enters a state where it may 2992 have lost some or all of its previous mapping state (or enters a 2993 state where it doesn't even know whether it may have had prior state 2994 that it lost) it MUST inform PCP clients of this fact by unicasting 2995 or multicasting a gratuitous PCP ANNOUNCE Opcode response packet, as 2996 shown below, via paths over which it accepts PCP requests. If 2997 sending a multicast ANNOUNCE message, a PCP server device which 2998 accepts PCP requests over IPv4 sends the Restart Announcement to the 2999 IPv4 multicast address 224.0.0.1:5350 (224.0.0.1 is the All Hosts 3000 multicast group address), and a PCP server device which accepts PCP 3001 requests over IPv6 sends the Restart Announcement to the IPv6 3002 multicast address [ff02::1]:5350 (ff02::1 is for all nodes on the 3003 local segment). A PCP server device which accepts PCP requests over 3004 both IPv4 and IPv6 sends a pair of Restart Announcements, one to each 3005 multicast address. If sending a unicast ANNOUNCE messages, it sends 3006 ANNOUNCE response message to the IP address(es) and port(s) of its 3007 PCP clients. To accommodate packet loss, the PCP server device MAY 3008 transmit such packets (or packet pairs) up to ten times (with an 3009 appropriate Epoch time value in each to reflect the passage of time 3010 between transmissions) provided that the interval between the first 3011 two notifications is at least 250ms, and the interval between 3012 subsequent notification at least doubles. 3014 A PCP client that sends PCP requests to a PCP Server via a multicast- 3015 capable path, and implements the Restart Announcement feature, and 3016 wishes to receive these announcements, MUST listen to receive these 3017 PCP Restart Announcements (gratuitous PCP ANNOUNCE Opcode response 3018 packets) on the appropriate multicast-capable interfaces on which it 3019 sends PCP requests, and MAY also listen for unicast announcements 3020 from the server too, (using the UDP port it already uses to issue 3021 unicast PCP requests to, and receive unicast PCP responses from, that 3022 server). A PCP client device which sends PCP requests using IPv4 3023 listens for packets sent to the IPv4 multicast address 224.0.0.1: 3024 5350. A PCP client device which sends PCP requests using IPv6 3025 listens for packets sent to the IPv6 multicast address [ff02::1]: 3026 5350. A PCP client device which sends PCP requests using both IPv4 3027 and IPv6 listens for both types of Restart Announcement. The 3028 SO_REUSEPORT socket option or equivalent should be used for the 3029 multicast UDP port, if required by the host OS to permit multiple 3030 independent listeners on the same multicast UDP port. 3032 Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode 3033 response packet, a PCP client MUST (as it does with all received PCP 3034 response packets) inspect the Announcement's source IP address, and 3035 if the Epoch time value is outside the expected range for that 3036 server, it MUST wait a random amount of time between 0 and 5 seconds 3037 (to prevent synchronization of all PCP clients), then for all PCP 3038 mappings it made at that server address the client issues new PCP 3039 requests to recreate any lost mapping state. The use of the 3040 Suggested External IP Address and Suggested External Port fields in 3041 the client's renewal requests allows the client to remind the 3042 restarted PCP server device of what mappings the client had 3043 previously been given, so that in many cases the prior state can be 3044 recreated. For PCP server devices that reboot relatively quickly it 3045 is usually possible to reconstruct lost mapping state fast enough 3046 that existing TCP connections and UDP communications do not time out, 3047 and continue without failure. As for all PCP response messages, if 3048 the Epoch time value is within the expected range for that server, 3049 the PCP client does not recreate its mappings. As for all PCP 3050 response messages, after receiving and validating the ANNOUNCE 3051 message, the client updates its own Epoch time for that server, as 3052 described in Section 8.5. 3054 14.2. PCP Mapping Update 3056 This rapid recovery mechanism is used when the PCP server remembers 3057 its state and determines its existing mappings are invalid (e.g., IP 3058 renumbering changes the External IP Address of a PCP-controlled NAT). 3060 It is anticipated that servers which are routinely reconfigured by an 3061 administrator or have their WAN address changed frequently will 3062 implement this feature (e.g., residential CPE routers). It is 3063 anticipated that servers which are not routinely reconfigured will 3064 not implement this feature (e.g., service provider-operated CGN). 3066 If a PCP server device has not forgotten its mapping state, but for 3067 some other reason has determined that some or all of its mappings 3068 have become unusable (e.g., when a home gateway is assigned a 3069 different external IPv4 address by the upstream DHCP server) then the 3070 PCP server device automatically repairs its mappings and notifies its 3071 clients by following the procedure described below. 3073 For PCP-managed mappings, for each one the PCP server device should 3074 update the External IP Address and External Port to appropriate 3075 available values, and then send unicast PCP MAP or PEER responses (as 3076 appropriate for the mapping) to inform the PCP client of the new 3077 External IP Address and External Port. Such unsolicited responses 3078 are identical to the MAP or PEER responses normally returned in 3079 response to client MAP or PEER requests, containing newly updated 3080 External IP Address and External Port values, and are sent to the 3081 same client IP address and port that the PCP server used to send the 3082 prior response for that mapping. If the earlier associated request 3083 contained the THIRD_PARTY Option, the THIRD_PARTY Option MUST also 3084 appear in the Mapping Update as it is necessary for the PCP client to 3085 disambiguate the response. If the earlier associated request 3086 contained the PREFER_FAILURE option, and the same external IP 3087 address, protocol, and port cannot be provided, the error 3088 CANNOT_PROVIDE_EXTERNAL SHOULD be sent. If the earlier associated 3089 request contained the FILTER option, the filters are moved to the new 3090 mapping and the FILTER Option is sent in the Mapping Update response. 3091 Non-mandatory Options SHOULD NOT be sent in the Mapping Update 3092 response. 3094 Discussion: It could have been possible to design this so that the 3095 PCP server (1) sent an ANNOUNCE Opcode to the PCP client, the PCP 3096 client reacted by (2) sending a new MAP request and (3) receiving 3097 a MAP response. Instead, that design is short-cutted by the 3098 server simply sending the message it would have sent in (3). 3100 To accommodate packet loss, the PCP server device SHOULD transmit 3101 such packets 3 times, with an appropriate Epoch time value in each to 3102 reflect the passage of time between transmissions. The interval 3103 between the first two notifications MUST be at least 250ms, and the 3104 third packet after a 500ms interval. Once the PCP server has 3105 received a refreshed state for that mapping, the PCP server SHOULD 3106 cease those retransmissions for that mapping, as it serves no further 3107 purpose to continue sending messages regarding that mapping. 3109 Upon receipt of such an updated MAP or PEER response, a PCP client 3110 uses the information in the response to adjust rendezvous servers or 3111 re-connect to servers, respectively. For MAP, this would means 3112 updating the DNS entries or other address and port information 3113 recorded with some kind of application-specific rendezvous server. 3114 For PEER responses giving a CANNOT_PROVIDE_EXTERNAL error, this would 3115 typically mean establishing new connections to servers. Any time the 3116 external address or port changes, existing TCP and UDP connections 3117 will be lost; PCP can't avoid that, but does provide immediate 3118 notification of the event to lessen the impact. 3120 15. Mapping Lifetime and Deletion 3122 The PCP client requests a certain lifetime, and the PCP server 3123 responds with the assigned lifetime. The PCP server MAY grant a 3124 lifetime smaller or larger than the requested lifetime. The PCP 3125 server SHOULD be configurable for permitted minimum and maximum 3126 lifetime, and the minimum value SHOULD be 120 seconds. The maximum 3127 value SHOULD be the remaining lifetime of the IP address assigned to 3128 the PCP client if that information is available (e.g., from the DHCP 3129 server), or half the lifetime of IP address assignments on that 3130 network if the remaining lifetime is not available, or 24 hours. 3131 Excessively long lifetimes can cause consumption of ports even if the 3132 Internal Host is no longer interested in receiving the traffic or is 3133 no longer connected to the network. These recommendations are not 3134 strict, and deployments should evaluate the trade offs to determine 3135 their own minimum and maximum lifetime values. 3137 Once a PCP server has responded positively to a MAP request for a 3138 certain lifetime, the port mapping is active for the duration of the 3139 lifetime unless the lifetime is reduced by the PCP client (to a 3140 shorter lifetime or to zero) or until the PCP server loses its state 3141 (e.g., crashes). Mappings created by PCP MAP requests are not 3142 special or different from mappings created in other ways. In 3143 particular, it is implementation-dependent if outgoing traffic 3144 extends the lifetime of such mappings beyond the PCP-assigned 3145 lifetime. PCP clients MUST NOT depend on this behavior to keep 3146 mappings active, and MUST explicitly renew their mappings as required 3147 by the Lifetime field in PCP response messages. 3149 Upon receipt of a PCP response with an absurdly long Assigned 3150 Lifetime the PCP client SHOULD behave as if it received a more sane 3151 value (e.g., 24 hours), and renew the mapping accordingly, to ensure 3152 that if the static mapping is removed the client will continue to 3153 maintain the mapping it desires. 3155 An application that forgets its PCP-assigned mappings (e.g., the 3156 application or OS crashes) will request new PCP mappings. This may 3157 consume port mappings, if the application binds to a different 3158 Internal Port every time it runs. The application will also likely 3159 initiate new implicit dynamic outbound mappings without using PCP, 3160 which will also consume port mappings. If there is a port mapping 3161 quota for the Internal Host, frequent restarts such as this may 3162 exhaust the quota and using the same Mapping Nonce can help alleviate 3163 such exhaustion. 3165 To help clean PCP state, it is RECOMMENDED that devices which combine 3166 IP address assignment (e.g., DHCP server) with the PCP server 3167 function (e.g., such as a residential CPE) flush PCP state when an IP 3168 address is allocated to a new host, because the new host will be 3169 unable perform the functions described in the previous paragaph 3170 because the new host does not know the previous host's Mapping Nonce 3171 value. It is good hygiene to also flush TCP and UDP flow state of 3172 NAT or fireall functions, although out of scope of this document. 3174 To reduce unwanted traffic and data corruption for both TCP and UDP, 3175 the Assigned External Port created by the MAP Opcode or PEER Opcode 3176 SHOULD NOT be re-used for the same interval enforced by NAT for 3177 implicitly creating mappings, which is typically the maximum segment 3178 lifetime interval of 120 seconds [RFC0793]. To reduce port stealing 3179 attacks, the Assigned External Port SHOULD NOT be re-used by the same 3180 Client IP Address (or Internal IP Address if using the THIRD_PARTY 3181 Option) for the duration the PCP-controlled device keeps a mapping 3182 for active bi-directional traffic (e.g., 2 minutes for UDP [RFC4787], 3183 2 hours 4 minutes for TCP [RFC5382]). However, within the above 3184 times, the PCP server SHOULD allow a request using the same Client IP 3185 Address (and same Internal IP Address if using the THIRD_PARTY 3186 Option), Internal Port, and Mapping Nonce to re-acquire the same 3187 External Port. 3189 The assigned lifetime is calculated by subtracting (a) zero or the 3190 number of seconds since the internal host sent a packet for this 3191 mapping from (b) the lifetime the PCP-controlled device uses for 3192 transitory connection idle-timeout (e.g., a NAT device might use 2 3193 minutes for UDP [RFC4787] or 4 minutes for TCP [RFC5382]). If the 3194 result is a negative number, the assigned lifetime is 0. 3196 15.1. Lifetime Processing for the MAP Opcode 3198 If the the requested lifetime is zero then: 3200 o If both the protocol and internal port are non-zero, it indicates 3201 a request to delete the indicated mapping immediately. 3203 o If the protocol is non-zero and the internal port is zero, it 3204 indicates a request to delete a previous 'wildcard' (all-ports) 3205 mapping for that protocol. 3207 o If both the protocol and internal port are zero, it indicates a 3208 request to delete all mappings for this Internal Address for all 3209 transport protocols. Such a request is rejected with a 3210 NOT_AUTHORIZED error. To delete all mappings the client has to 3211 send separate MAP requests with appropriate Mapping Nonce values. 3213 o If the protocol is zero and the internal port is non-zero, then 3214 the request is invalid and the PCP Server MUST return a 3215 MALFORMED_REQUEST error to the client. 3217 In requests where the requested Lifetime is 0, the Suggested External 3218 Address and Suggested External Port fields MUST be set to zero on 3219 transmission and MUST be ignored on reception, and these fields MUST 3220 be copied into the Assigned External IP Address and Assigned External 3221 Port of the response. 3223 PCP MAP requests can only delete or shorten lifetimes of MAP-created 3224 mappings. If the PCP client attempts to delete a static mapping 3225 (i.e., a mapping created outside of PCP itself), or an outbound 3226 (implicit or PEER-created) mapping, the PCP server MUST return 3227 NOT_AUTHORIZED. If the PCP client attempts to delete a mapping that 3228 does not exist, the SUCCESS result code is returned (this is 3229 necessary for PCP to return the same response for the same request). 3230 If the deletion request was properly formatted and successfully 3231 processed, a SUCCESS response is generated with the assigned lifetime 3232 of the mapping and the server copies the protocol and internal port 3233 number from the request into the response. An inbound mapping (i.e., 3234 static mapping or MAP- created dynamic mapping) MUST NOT have its 3235 lifetime reduced by transport protocol messages (e.g., TCP RST, TCP 3236 FIN). Note the THIRD_PARTY Option, if authorized, can also delete 3237 PCP-created mappings (see Section 13.1). 3239 16. Implementation Considerations 3241 Section 16 provides non-normative guidance that may be useful to 3242 implementers. 3244 16.1. Implementing MAP with EDM port-mapping NAT 3246 For implicit dynamic outbound mappings, some existing NAT devices 3247 have endpoint-independent mapping (EIM) behavior while other NAT 3248 devices have endpoint-dependent mapping (EDM) behavior. NATs which 3249 have EIM behavior do not suffer from the problem described in this 3250 section. The IETF strongly encourages EIM behavior 3251 [RFC4787][RFC5382]. 3253 In EDM NAT devices, the same external port may be used by an outbound 3254 dynamic mapping and an inbound dynamic mapping (from the same 3255 Internal Host or from a different Internal Host). This complicates 3256 the interaction with the MAP Opcode. With such NAT devices, there 3257 are two ways envisioned to implement the MAP Opcode: 3259 1. Have outbound mappings use a different set of External ports than 3260 inbound mappings (e.g., those created with MAP), thus reducing 3261 the interaction problem between them; or 3263 2. On arrival of a packet (inbound from the Internet or outbound 3264 from an Internal Host), first attempt to use a dynamic outbound 3265 mapping to process that packet. If none match, attempt to use an 3266 inbound mapping to process that packet. This effectively 3267 'prioritizes' outbound mappings above inbound mappings. 3269 16.2. Lifetime of Explicit and Implicit Dynamic Mappings 3271 No matter if a NAT is EIM or EDM, it is possible that one (or more) 3272 outbound mappings, using the same internal port on the Internal Host, 3273 might be created before or after a MAP request. When this occurs, it 3274 is important that the NAT honor the Lifetime returned in the MAP 3275 response. Specifically, if a mapping was created with the MAP 3276 Opcode, the implementation needs to ensure that termination of an 3277 outbound mapping (e.g., via a TCP FIN handshake) does not prematurely 3278 destroy the MAP-created inbound mapping. 3280 16.3. PCP Failure Recovery 3282 If an event occurs that causes the PCP server to lose dynamic mapping 3283 state (such as a crash or power outage), the mappings created by PCP 3284 are lost. Occasional loss of state may be unavoidable in a 3285 residential NAT device which does not write transient information to 3286 non-volatile memory. Loss of state is expected to be rare in a 3287 service provider environment (due to redundant power, disk drives for 3288 storage, etc.). Of course, due to outright failure of service 3289 provider equipment (e.g., software malfunction), state may still be 3290 lost. 3292 The Epoch Time allows a client to deduce when a PCP server may have 3293 lost its state. When the Epoch Time value is observed to be outside 3294 the expected range, the PCP client can attempt to recreate the 3295 mappings following the procedures described in this section. 3297 Further analysis of PCP failure scenarios is in 3298 [I-D.boucadair-pcp-failure]. 3300 16.3.1. Recreating Mappings 3302 A mapping renewal packet is formatted identically to an original 3303 mapping request; from the point of view of the client it is a renewal 3304 of an existing mapping, but from the point of view of a newly 3305 rebooted PCP server it appears as a new mapping request. In the 3306 normal process of routinely renewing its mappings before they expire, 3307 a PCP client will automatically recreate all its lost mappings. 3309 When the PCP server loses state and begins processing new PCP 3310 messages, its Epoch time is reset and begins counting again. As the 3311 result of receiving a packet where the Epoch time field is outside 3312 the expected range (Section 8.5), indicating that a reboot or similar 3313 loss of state has occurred, the client can renew its port mappings 3314 sooner, without waiting for the normal routine renewal time. 3316 16.3.2. Maintaining Mappings 3318 A PCP client refreshes a mapping by sending a new PCP request 3319 containing information from the earlier PCP response. The PCP server 3320 will respond indicating the new lifetime. It is possible, due to 3321 reconfiguration or failure of the PCP server, that the External IP 3322 Address and/or External Port, or the PCP server itself, has changed 3323 (due to a new route to a different PCP server). Such events are 3324 rare, but not an error. The PCP server will simply return a new 3325 External Address and/or External Port to the client, and the client 3326 should record this new External Address and Port with its rendezvous 3327 service. To detect such events more quickly, a server that requires 3328 extremely high availability may find it beneficial to use shorter 3329 lifetimes in its PCP mappings requests, so that it communicates with 3330 the PCP server more often. This is an engineering trade-off based on 3331 (i) the acceptable downtime for the service in question, (ii) the 3332 expected likelihood of NAT or firewall state loss, and (iii) the 3333 amount of PCP maintenance traffic that is acceptable. 3335 If the PCP client has several mappings, the Epoch Time value only 3336 needs to be retrieved for one of them to determine whether or not it 3337 appears the PCP server may have suffered a catastrophic loss of 3338 state. If the client wishes to check the PCP server's Epoch Time, it 3339 sends a PCP request for any one of the client's mappings. This will 3340 return the current Epoch Time value. In that request the PCP client 3341 could extend the mapping lifetime (by asking for more time) or 3342 maintain the current lifetime (by asking for the same number of 3343 seconds that it knows are remaining of the lifetime). 3345 If a PCP client changes its Internal IP Address (e.g., because the 3346 Internal Host has moved to a new network), and the PCP client wishes 3347 to still receive incoming traffic, it needs create new mappings on 3348 that new network. New mappings will typically also require an update 3349 to the application-specific rendezvous server if the External Address 3350 or Port are different from the previous values (see Section 10.1 and 3351 Section 11.5). 3353 16.3.3. SCTP 3355 Although SCTP has port numbers like TCP and UDP, SCTP works 3356 differently when behind an address-sharing NAT, in that SCTP port 3357 numbers are not changed [I-D.ietf-behave-sctpnat]. Outbound dynamic 3358 SCTP mappings use the verification tag of the association instead of 3359 the local and remote peer port numbers. As with TCP, explicit 3360 outbound mappings can be made to reduce keepalive intervals, and 3361 explicit inbound mappings can be made by passive listeners expecting 3362 to receive new associations at the external port. 3364 Because an SCTP-aware NAT does not (currently) rewrite SCTP port 3365 numbers, it will not be able to assign an External Port that is 3366 different from the client's Internal Port. A PCP client making a MAP 3367 request for SCTP should be aware of this restriction. The PCP client 3368 SHOULD make its SCTP MAP request just as it would for a TCP MAP 3369 request: in its initial PCP MAP request it SHOULD specify zero for 3370 the External Address and Port, and then in subsequent renewals it 3371 SHOULD echo the assigned External Address and Port. However, since a 3372 current SCTP-aware NAT can only assign an External Port that is the 3373 same as the Internal Port, it may not be able to do that if the 3374 External Port is already assigned to a different PCP client. This is 3375 likely if there is more than one instance of a given SCTP service on 3376 the local network, since both instances are likely to listen on the 3377 same well-known SCTP port for that service on their respective hosts, 3378 but they can't both have the same External Port on the NAT gateway's 3379 External Address. A particular External Port may not be assignable 3380 for other reasons, such as when it is already in use by the NAT 3381 device itself, or otherwise prohibited by policy, as described in 3382 Section 11.3. In the event that the External Port matching the 3383 Internal Port cannot be assigned (and the SCTP-aware NAT does not 3384 perform SCTP port rewriting) then the SCTP-aware NAT MUST return a 3385 CANNOT_PROVIDE_EXTERNAL error to the requesting PCP client. Note 3386 that this restriction places extra burden on the SCTP server whose 3387 MAP request failed, because it then has to tear down its exiting 3388 listening socket and try again with a different Internal Port, 3389 repeatedly until it is successful in finding an External Port it can 3390 use. 3392 The SCTP complications described above occur because of address 3393 sharing. The SCTP complications are avoided when address sharing is 3394 avoided (e.g., 1:1 NAT, firewall). 3396 16.4. Source Address Replicated in PCP Header 3398 All PCP requests include the PCP client's IP address replicated in 3399 the PCP header. This is used to detect address rewriting (NAT) 3400 between the PCP client and its PCP server. On operating systems that 3401 support the sockets API, the following steps are RECOMMENDED for a 3402 PCP client to insert the correct source address and port in the PCP 3403 header: 3405 1. Create a UDP socket. 3406 2. Call "connect" on this UDP socket using the address and port of 3407 the desired PCP server. 3408 3. Call the getsockname() function to retrieve a sockaddr containing 3409 the source address the kernel will use for UDP packets sent 3410 through this socket. 3412 4. If the IP address is an IPv4 address, encode the address into an 3413 IPv4-mapped IPv6 address. Place the native IPv6 address or IPv4- 3414 mapped IPv6 address into the PCP Client's IP Address field in the 3415 PCP header. 3416 5. Send PCP requests using this connected UDP socket. 3418 16.5. State Diagram 3420 Each mapping entry of the PCP-controlled device would go through the 3421 state machine shown below. This state diagram is non-normative. 3423 CLOSE_MSG or 3424 (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY 3425 +-------------->| |<------------+ 3426 | |NO_ENTRY | | 3427 | +-----------| |---------+ | 3428 | | +---------+ | | 3429 | | ^ | | | 3430 | | NO_TRAFFIC | | | | 3431 | | or | | | | 3432 | | CLOSE_MSGS | | | | 3433 | | | | | | 3434 | |PEER request | | MAP request| | 3435 | V | | V | 3436 +---------+ | | +---------+ 3437 +-->| "P", | | | M-R | "M", |<--+ 3438 P-R | | PEER |-----------|--|-------->| MAP | | M-R or 3439 +---| mapping| | | | mapping|---+ P-R or 3440 +---------+ | | +---------+ CLOSE_MSGS 3441 | ^ | | ^ | 3442 | |PEER request | | MAP request| | 3443 | | | | | | 3444 | | | | | | 3445 | | | | | | 3446 | | | | outbound | | 3447 | | | | TRAFFIC | | 3448 | | | V | | 3449 | | +---------+ | | 3450 | +-----------| "I", |---------+ | 3451 | | implicit| | 3452 +-------------->| mapping |<------------+ 3453 TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY 3455 Figure 16: PCP State Diagram 3457 The meanings of the states and events are: 3459 NO_ENTRY: Invalid state represents Entry does not exist. This is 3460 the only possible start state. 3462 M-R: MAP request 3464 P-R: PEER request 3466 M: Mapping entry when created by MAP request 3468 P: Mapping entry when created/managed by PEER request 3470 I: Implicit mapping created by an outgoing packet from the 3471 client (e.g., TCP SYN), and also the state when a PCP-created 3472 mapping's lifetime expires while there is still active 3473 traffic. 3475 EXPIRY: PEER or MAP lifetime expired 3477 TRAFFIC: Traffic seen by PCP-controlled device using this entry 3478 within the expiry time for that entry. This traffic may be 3479 inbound or outbound. 3481 NO_TRAFFIC: Indicates that there is no TRAFFIC. 3483 CLOSE_MSG: Protocol messages from the client or server to close 3484 the session (e.g., TCP FIN or TCP RST), as per the NAT or 3485 firewall device's handling of such protocol messages. 3487 Notes on the diagram: 3489 1. The 'and' clause indicates the events on either side of 'and' are 3490 required for the state-transition. The 'or' clause indicates 3491 either one of the events are enough for the state-transition. 3493 2. Transition from state M to state I is implementation dependent. 3495 17. Deployment Considerations 3497 17.1. Ingress Filtering 3499 As with implicit dynamic mappings created by outgoing TCP SYN 3500 packets, explicit dynamic mappings created via PCP use the source IP 3501 address of the packet as the Internal Address for the mappings. 3502 Therefore ingress filtering [RFC2827] SHOULD be used on the path 3503 between the Internal Host and the PCP Server to prevent the injection 3504 of spoofed packets onto that path. 3506 17.2. Mapping Quota 3508 On PCP-controlled devices that create state when a mapping is created 3509 (e.g., NAT), the PCP server SHOULD maintain per-host and/or per- 3510 subscriber quotas for mappings. It is implementation-specific 3511 whether the PCP server uses a separate quotas for implicit, explicit, 3512 and static mappings, a combined quota for all of them, or some other 3513 policy. 3515 18. Security Considerations 3517 The goal of the PCP protocol is to improve the ability of end nodes 3518 to control their associated NAT state, and to improve the efficiency 3519 and error handling of NAT mappings when compared to existing implicit 3520 mapping mechanisms in NAT boxes and stateful firewalls. It is the 3521 security goal of the PCP protocol to limit any new denial of service 3522 opportunities, and to avoid introducing new attacks that can result 3523 in unauthorized changes to mapping state. One of the most serious 3524 consequences of unauthorized changes in mapping state is traffic 3525 theft. All mappings that could be created by a specific host using 3526 implicit mapping mechanisms are inherently considered to be 3527 authorized. Confidentiality of mappings is not a requirement, even 3528 in cases where the PCP messages may transit paths that would not be 3529 travelled by the mapped traffic. 3531 18.1. Simple Threat Model 3533 PCP is secure against off-path attackers who cannot spoof a packet 3534 that the PCP Server will view as a packet received from the internal 3535 network. PCP is secure against off-path attackers who can spoof the 3536 PCP server's IP address. 3538 Defending against attackers who can modify or drop packets between 3539 the internal network and the PCP server, or who can inject spoofed 3540 packets that appear to come from the internal network is out of 3541 scope. Such an attacker can re-direct traffic to a host of their 3542 choosing. 3544 A PCP Server is secure under this threat model if the PCP Server is 3545 constrained so that it does not configure any explicit mapping that 3546 it would not configure implicitly. In most cases, this means that 3547 PCP Servers running on NAT boxes or stateful firewalls that support 3548 the PEER and MAP Opcodes can be secure under this threat model if (1) 3549 all of their hosts are within a single administrative domain (or if 3550 the internal hosts can be securely partitioned into separate 3551 administrative domains, as in the DS-Lite B4 case), (2) explicit 3552 mappings are created with the same lifetime as implicit mappings, and 3553 (3) the THIRD_PARTY option is not supported. PCP Servers can also 3554 securely support the MAP Opcode under this threat model if the 3555 security policy on the device running the PCP Server would permit 3556 endpoint independent filtering of implicit mappings. 3558 PCP Servers that comply with the Simple Threat Model and do not 3559 implement a PCP security mechanism described in Section 18.2 MUST 3560 enforce the constraints described in the paragraph above. 3562 18.1.1. Attacks Considered 3564 o If you allow multiple administrative domains to send PCP requests 3565 to a single PCP server that does not enforce a boundary between 3566 the domains, it is possible for a node in one domain to perform a 3567 denial of service attack on other domains, or to capture traffic 3568 that is intended for a node in another domain. 3570 o If explicit mappings have longer lifetimes than implicit mappings, 3571 it makes it easier to perpetrate a denial of service attack than 3572 it would be if the PCP Server was not present. 3574 o If the PCP Server supports deleting or reducing the lifetime of 3575 existing mappings, this allows an attacking node to steal an 3576 existing mapping and receive traffic that was intended for another 3577 node. 3579 o If the THIRD_PARTY Option is supported, this also allows an 3580 attacker to open a window for an external node to attack an 3581 internal node, allows an attacker to steal traffic that was 3582 intended for another node, or may facilitate a denial of service 3583 attack. One example of how the THIRD_PARTY Option could grant an 3584 attacker more capability than a spoofed implicit mapping is that 3585 the PCP server (especially if it is running in a service 3586 provider's network) may not be aware of internal filtering that 3587 would prevent spoofing an equivalent implicit mapping, such as 3588 filtering between a guest and corporate network. 3590 o If the MAP Opcode is supported by the PCP server in cases where 3591 the security policy would not support endpoint independent 3592 filtering of implicit mappings, then the MAP Opcode changes the 3593 security properties of the device running the PCP Server by 3594 allowing explicit mappings that violate the security policy. 3596 18.1.2. Deployment Examples Supporting the Simple Threat Model 3598 This section offers two examples of how the Simple Threat Model can 3599 be supported in real-world deployment scenarios. 3601 18.1.2.1. Residential Gateway Deployment 3603 Parity with many currently-deployed residential gateways can be 3604 achieved using a PCP Server that is constrained as described in 3605 Section 18.1 above. 3607 18.2. Advanced Threat Model 3609 In the Advanced Threat Model the PCP protocol ensures that attackers 3610 (on- or off-path) cannot create unauthorized mappings or make 3611 unauthorized changes to existing mappings. The protocol must also 3612 limit the opportunity for on- or off-path attackers to perpetrate 3613 denial of service attacks. 3615 The Advanced Threat Model security model will be needed in the 3616 following cases: 3618 o Security infrastructure equipment, such as corporate firewalls, 3619 that does not create implicit mappings. 3621 o Equipment (such as CGNs or service provider firewalls) that serve 3622 multiple administrative domains and do not have a mechanism to 3623 securely partition traffic from those domains. 3625 o Any implementation that wants to be more permissive in authorizing 3626 explicit mappings than it is in authorizing implicit mappings. 3628 o Implementations that wish to support any deployment scenario that 3629 does not meet the constraints described in Section 18.1. 3631 To protect against attacks under this threat model, a PCP security 3632 mechanism that provides an authenticated, integrity-protected 3633 signaling channel would need to be specified. 3635 PCP Servers that implement a PCP security mechanism MAY accept 3636 unauthenticated requests. PCP Servers implementing the PCP security 3637 mechanism MUST enforce the constraints described in Section 18.1 3638 above, in their default configuration, when processing 3639 unauthenticated requests. 3641 18.3. Residual Threats 3643 This section describes some threats that are not addressed in either 3644 of the above threat models, and recommends appropriate mitigation 3645 strategies. 3647 18.3.1. Denial of Service 3649 Because of the state created in a NAT or firewall, a per-host and/or 3650 per-subscriber quota will likely exist for both implicit dynamic 3651 mappings and explicit dynamic mappings. A host might make an 3652 excessive number of implicit or explicit dynamic mappings, consuming 3653 an inordinate number of ports, causing a denial of service to other 3654 hosts. Thus, Section 17.2 recommends that hosts be limited to a 3655 reasonable number of explicit dynamic mappings. 3657 An attacker, on the path between the PCP client and PCP server, can 3658 drop PCP requests, drop PCP responses, or spoof a PCP error, all of 3659 which will effectively deny service. Through such actions, the PCP 3660 client might not be aware the PCP server might have actually 3661 processed the PCP request. An attacker sending a NO_RESOURCES error 3662 can cause the PCP client to not send messages to that server for a 3663 while. There is no mitigation to this on-path attacker. 3665 18.3.2. Ingress Filtering 3667 It is important to prevent a host from fraudulently creating, 3668 deleting, or refreshing a mapping (or filtering) for another host, 3669 because this can expose the other host to unwanted traffic, prevent 3670 it from receiving wanted traffic, or consume the other host's mapping 3671 quota. Both implicit and explicit dynamic mappings are created based 3672 on the source IP address in the packet, and hence depend on ingress 3673 filtering to guard against spoof source IP addresses. 3675 18.3.3. Mapping Theft 3677 In the time between when a PCP server loses state and the PCP client 3678 notices the lower-than-expected Epoch Time value, it is possible that 3679 the PCP client's mapping will be acquired by another host (via an 3680 explicit dynamic mapping or implicit dynamic mapping). This means 3681 incoming traffic will be sent to a different host ("theft"). Rapid 3682 Recovery reduces this interval, but would not completely eliminate 3683 this threat. The PCP client can reduce this interval by using a 3684 relatively short lifetime; however, this increases the amount of PCP 3685 chatter. This threat is reduced by using persistent storage of 3686 explicit dynamic mappings in the PCP server (so it does not lose 3687 explicit dynamic mapping state), or by ensuring the previous external 3688 IP address, protocol, and port cannot be used by another host (e.g., 3689 by using a different IP address pool). 3691 18.3.4. Attacks Against Server Discovery 3693 This document does not specify server discovery, beyond contacting 3694 the default gateway. 3696 19. IANA Considerations 3698 IANA is requested to perform the following actions: 3700 19.1. Port Number 3702 PCP will use ports 5350 and 5351 (currently assigned by IANA to NAT- 3703 PMP [I-D.cheshire-nat-pmp]). We request that IANA re-assign those 3704 ports to PCP, and relinquish UDP port 44323. 3706 [Note to RFC Editor: Please remove the text about relinquishing port 3707 44323 prior to publication.] 3709 19.2. Opcodes 3711 IANA shall create a new protocol registry for PCP Opcodes, numbered 3712 0-127, initially populated with the values: 3714 value Opcode 3715 ----- ------------------------- 3716 0 ANNOUNCE 3717 1 MAP 3718 2 PEER 3719 3-31 Standards Action [RFC5226] 3720 32-63 Specification Required [RFC5226] 3721 96-126 Private Use [RFC5226] 3722 127 Reserved, Standards Action [RFC5226] 3724 The value 127 is Reserved and may be assigned via Standards Action 3725 [RFC5226]. The values in the range 3-31 can be assigned via 3726 Standards Action [RFC5226], 32-63 via Specification Required 3727 [RFC5226], and 96-126 is for Private Use [RFC5226]. 3729 19.3. Result Codes 3731 IANA shall create a new registry for PCP result codes, numbered 3732 0-255, initially populated with the result codes from Section 7.4. 3733 The value 255 is Reserved and may be assigned via Standards Action 3734 [RFC5226]. 3736 The values in the range 14-127 can be assigned via Standards Action 3737 [RFC5226], 128-191 via Specification Required [RFC5226], and 191-254 3738 is for Private Use [RFC5226]. 3740 19.4. Options 3742 IANA shall create a new registry for PCP Options, numbered 0-255, 3743 each with an associated mnemonic. The values 0-127 are mandatory-to- 3744 process, and 128-255 are optional to process. The initial registry 3745 contains the Options described in Section 13. The Option values 0, 3746 127 and 255 are Reserved and may be assigned via Standards Action 3747 [RFC5226]. 3749 Additional PCP Option codes in the ranges 4-63 and 128-191 can be 3750 created via Standards Action [RFC5226], the ranges 64-95 and 192-223 3751 are for Specification Required [RFC5226] and the ranges 96-126 and 3752 224-254 are for Private Use [RFC5226]. 3754 Documents describing an Option should describe if the processing for 3755 both the PCP client and server and the information below: 3756 Option Name: 3757 Number: 3758 Purpose: 3759 Valid for Opcodes: 3760 Length: 3761 May appear in: 3762 Maximum occurrences: 3764 20. Acknowledgments 3766 Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni 3767 Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda 3768 Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani, 3769 Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete 3770 Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins, 3771 Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda 3772 Costa, Amit Jain, and Wim Henderickx for their comments and review. 3774 Thanks to Simon Perreault for highlighting the interaction of dynamic 3775 connections with PCP-created mappings. 3777 Thanks to Francis Dupont for his several thorough reviews of the 3778 specification, which improved the protocol significantly. 3780 Thanks to T. S. Ranganathan for the state diagram. 3782 Thanks to Peter Lothberg for clock skew information. 3784 Thanks to Margaret Wasserman and Sam Hartman for writing the Security 3785 Considerations section. 3787 Thanks to authors of DHCPv6 for retransmission text. 3789 21. References 3791 21.1. Normative References 3793 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3794 August 1980. 3796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3797 Requirement Levels", BCP 14, RFC 2119, March 1997. 3799 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3800 Defeating Denial of Service Attacks which employ IP Source 3801 Address Spoofing", BCP 38, RFC 2827, May 2000. 3803 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3804 Requirements for Security", BCP 106, RFC 4086, June 2005. 3806 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3807 Addresses", RFC 4193, October 2005. 3809 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3810 Architecture", RFC 4291, February 2006. 3812 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3813 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3814 May 2008. 3816 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 3817 Protocol Port Randomization", BCP 156, RFC 6056, 3818 January 2011. 3820 [proto_numbers] 3821 IANA, "Protocol Numbers", 2011, . 3824 21.2. Informative References 3826 [I-D.boucadair-pcp-failure] 3827 Boucadair, M., Dupont, F., and R. Penno, "Port Control 3828 Protocol (PCP) Failure Scenarios", 3829 draft-boucadair-pcp-failure-04 (work in progress), 3830 August 2012. 3832 [I-D.cheshire-dnsext-dns-sd] 3833 Cheshire, S. and M. Krochmal, "DNS-Based Service 3834 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 3835 progress), December 2011. 3837 [I-D.cheshire-nat-pmp] 3838 Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 3839 (NAT-PMP)", draft-cheshire-nat-pmp-05 (work in progress), 3840 September 2012. 3842 [I-D.ietf-behave-lsn-requirements] 3843 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 3844 and H. Ashida, "Common requirements for Carrier Grade NATs 3845 (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in 3846 progress), August 2012. 3848 [I-D.ietf-behave-sctpnat] 3849 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 3850 Transmission Protocol (SCTP) Network Address Translation", 3851 draft-ietf-behave-sctpnat-07 (work in progress), 3852 October 2012. 3854 [I-D.ietf-pcp-upnp-igd-interworking] 3855 Boucadair, M., Dupont, F., Penno, R., and D. Wing, 3856 "Universal Plug and Play (UPnP) Internet Gateway Device 3857 (IGD)-Port Control Protocol (PCP) Interworking Function", 3858 draft-ietf-pcp-upnp-igd-interworking-04 (work in 3859 progress), September 2012. 3861 [I-D.miles-behave-l2nat] 3862 Miles, D. and M. Townsley, "Layer2-Aware NAT", 3863 draft-miles-behave-l2nat-00 (work in progress), 3864 March 2009. 3866 [IGDv1] UPnP Gateway Committee, "WANIPConnection:1", 3867 November 2001, . 3870 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3871 RFC 793, September 1981. 3873 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3874 E. Lear, "Address Allocation for Private Internets", 3875 BCP 5, RFC 1918, February 1996. 3877 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 3878 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 3879 RFC 2136, April 1997. 3881 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 3882 Update", RFC 3007, November 2000. 3884 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3885 Address Translator (Traditional NAT)", RFC 3022, 3886 January 2001. 3888 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 3889 Session Initiation Protocol (SIP) for Symmetric Response 3890 Routing", RFC 3581, August 2003. 3892 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 3893 Unicast Address Format", RFC 3587, August 2003. 3895 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3896 RFC 4303, December 2005. 3898 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 3899 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 3901 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3902 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3903 RFC 4787, January 2007. 3905 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3906 Extensions for Stateless Address Autoconfiguration in 3907 IPv6", RFC 4941, September 2007. 3909 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 3910 RFC 4960, September 2007. 3912 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3913 BCP 131, RFC 4961, July 2007. 3915 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 3916 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3917 RFC 5382, October 2008. 3919 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 3920 Customer Premises Equipment (CPE) for Providing 3921 Residential IPv6 Internet Service", RFC 6092, 3922 January 2011. 3924 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 3925 Algorithm", RFC 6145, April 2011. 3927 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3928 NAT64: Network Address and Protocol Translation from IPv6 3929 Clients to IPv4 Servers", RFC 6146, April 2011. 3931 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3932 Translation", RFC 6296, June 2011. 3934 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 3935 Stack Lite Broadband Deployments Following IPv4 3936 Exhaustion", RFC 6333, August 2011. 3938 [RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable 3939 Operation of Address Translators with Per-Interface 3940 Bindings", RFC 6619, June 2012. 3942 Appendix A. NAT-PMP Transition 3944 The Port Control Protocol (PCP) is a successor to the NAT Port 3945 Mapping Protocol, NAT-PMP [I-D.cheshire-nat-pmp], and shares similar 3946 semantics, concepts, and packet formats. Because of this NAT-PMP and 3947 PCP both use the same port, and use NAT-PMP and PCP's version 3948 negotiation capabilities to determine which version to use. This 3949 section describes how an orderly transition may be achieved. 3951 A client supporting both NAT-PMP and PCP SHOULD send its request 3952 using the PCP packet format. This will be received by a NAT-PMP 3953 server or a PCP server. If received by a NAT-PMP server, the 3954 response will be as indicated by the NAT-PMP specification 3955 [I-D.cheshire-nat-pmp], which will cause the client to downgrade to 3956 NAT-PMP and re-send its request in NAT-PMP format. If received by a 3957 PCP server, the response will be as described by this document and 3958 processing continues as expected. 3960 A PCP server supporting both NAT-PMP and PCP can handle requests in 3961 either format. The first octet of the packet indicates if it is NAT- 3962 PMP (first octet zero) or PCP (first octet non-zero). 3964 A PCP-only gateway receiving a NAT-PMP request (identified by the 3965 first octet being zero) will interpret the request as a version 3966 mismatch. Normal PCP processing will emit a PCP response that is 3967 compatible with NAT-PMP, without any special handling by the PCP 3968 server. 3970 Appendix B. Change History 3972 [Note to RFC Editor: Please remove this section prior to 3973 publication.] 3975 B.1. Changes from draft-ietf-pcp-base-28 to -29 3977 o Removed text suggesting PCP client can remove old mappings when it 3978 acquires a new IP address. 3980 B.2. Changes from draft-ietf-pcp-base-27 to -28 3982 o When processing MAP request or processing PEER request, Mapping 3983 Nonce validation only applies to Basic Threat Model, and not to 3984 THIRD_PARTY. 3986 o A maximum payload size of 1100 keeps PCP packets below IPv6's 1280 3987 MTU limit while still allowing some room for encapsulation. This 3988 accomodates EAP over PANA over PCP (EAP needs 1020 octets, per 3989 RFC3748), should PCP authentication decide to use EAP over PANA 3990 over PCP. 3992 o Both MAP and PEER-created mappings cannot have their lifetimes 3993 reduced beyond normal UDP/TCP timesouts. 3995 o Disallow re-assigning External Port to same internal host. 3997 B.3. Changes from draft-ietf-pcp-base-26 to -27 3999 o For table, reverted the NAT64 remote peer to IPv6 -- because from 4000 the IPv6 PCP client's perspective, the remote peer really is IPv6. 4002 o "list of PCP server addresses" changed to "longer list of PCP 4003 server addresses" 4005 o Clarify that unsolicited ANNOUNCE messages are sent from the PCP 4006 server IP address and PCP port. 4008 o "1024 bytes" changed to "1024 octets". 4010 o Clarify that re-transmitted requests must use same Mapping Nonce 4011 value (beginning of Section 8.1.1). 4013 o Describe that de-synchronization that can occur (end of 4014 Section 8.1.1). 4016 o For devices that lose state or expect IP renumbering, Rapid 4017 Recovery is now a MUST, with SHOULD for implementing both 4018 multicast Announce mechanism and unicast mechanisms. 4020 o For refreshing MAP or PEER, Mapping Nonce has to match the 4021 previous MAP or PEER. This protects from off-path attackers 4022 stealing MAP or shortening PEER mappings. 4024 o With the Mapping Nonce change, we now allow PEER to reduce mapping 4025 lifetime to same lifetime as implicit mapping lifetime (but not 4026 shorter). Changes for this are in both PEER section and Security 4027 Considerations. 4029 o With Mapping Nonce change, can no longer delete a 'set of 4030 mappings' (because we cannot send multiple Mapping Nonce values), 4031 so removed text that allowed that. 4033 o Send Mapping Update only 3 times (used to be 10 times). 4035 o General PCP processing now requires validating Mapping Nonce, if 4036 the opcode uses a Mapping Nonce Section 8.3. 4038 o Moved text describing NO_RESOURCES handling from General 4039 Processing section to MAP and PEER processing sections, as it 4040 NO_RESOURCES processing should be done after validating Mapping 4041 Nonce. 4043 o Clarified SCTP NAT behavior (port numbers stay the same, causing 4044 grief). 4046 o added EIM definition. 4048 o Clarified Mapping Type definitions. 4050 o PCP Client definition simplified to no longer obliquely and 4051 erroneously reference UPnP IGD. 4053 o Clarified using network-byte order. 4055 o Epoch time comparison now allows slight packet re-ordering. 4057 o Encourage that when new address is assigned (e.g., DHCP) that PCP 4058 as well as non-PCP mappings be cleaned up. 4060 o Simplified formatting of retransmission, but no normative change. 4062 o Clarified how server chooses ports and how Suggested External Port 4063 can gently influence that decision. 4065 o Described how PCP client can use PCP Client Address with a non- 4066 PCP-aware inner NAT (Section 8.1.) 4068 o Clarified 1024 octet length applies to UDP payload itself, and 4069 that error responses copy 1024 of UDP payload. 4071 o Lifetime for both MAP and PEER should not exceed the remaining IP 4072 address lifetime of the PCP client (if known) or half the typical 4073 IP address lifetime (if the remaining lifetime is unknown). 4075 o Lifetime section was (mistakenly) a subsection of the MAP section, 4076 but referenced by both MAP and PEER. It is now a top-level 4077 section. 4079 o Clarified that PEER cannot reduce lifetime beyond normal implicit 4080 mapping lifetime, no matter what. This restriction prevents 4081 malicious or accidental deletion of a quiescent connection that 4082 was not using PCP. 4084 o Clarified port re-use of PCP-created mappings should follow same 4085 port re-use algorithm used by the NAT for implicitly-created 4086 mappings (likely maximum segment lifetime). 4088 o Other minor text changes; consult diffs. 4090 B.4. Changes from draft-ietf-pcp-base-25 to -26 4092 o Changed "internal address and port" to "internal address, 4093 protocol, and port" in several more places. 4095 o Improved wording of THIRD_PARTY restrictions. 4097 o Bump version number from 1 to 2, to accommodate pre-RFC PCP client 4098 implementations without needing a heuristic. 4100 B.5. Changes from draft-ietf-pcp-base-24 to -25 4102 o Clarified the port used by the PCP server when sending unsolicited 4103 unicast ANNOUNCE. 4105 o Removed parenthetical comment implying ANNOUNCE was not a normal 4106 Opcode; it is a normal Opcode. 4108 o Explain that non-PCP-speaking host-based and network-based 4109 firewalls need to allow incoming connections for MAP to work. 4111 o For race condition with PREFER_FAILURE, clarified that it is the 4112 PCP client's responsibility to delete the mapping if the PCP 4113 client doesn't need the mapping. 4115 o For table, the NAT64 remote peer is IPv4 (was IPv6). 4117 o Added a Mapping Nonce field to both MAP and PEER requests and 4118 responses, to protect from off-path attackers spoofing the PCP 4119 server's IP address. 4121 o Security considerations: added 'PCP is secure against off-path 4122 attackers who can spoof the PCP server's IP address', because of 4123 the addition of the Mapping Nonce. 4125 o Removed reference to DS-Lite from Security Considerations, as part 4126 of the changes to THIRD_PARTY from IESG review. 4128 o Rapid Recovery is now a SHOULD implement. 4130 o Clarify behavior of PREFER_FAILURE with zeros in Suggested 4131 External Port or Address fields. 4133 o PCP server is now more robust and insistent about informing PCP 4134 client of state changes. 4136 o When PCP server sends Mapping Update to a specific PCP client, and 4137 gets an update for a particular mapping, it doesn't need to send 4138 reminders about that mapping any more. 4140 o THIRD_PARTY is now prohibited on subscriber PCP clients. 4142 B.6. Changes from draft-ietf-pcp-base-23 to -24 4144 o Explained common questions regarding PCP's design, such as lack of 4145 transction identifiers and its request/response semantics and 4146 operation (Protocol Design Note (Section 6)). 4148 o added MUST for all-zeros IPv6 and IPv4 address formats. 4150 o included field definitions for Opcode-specific information and PCP 4151 options under both Figure 2 and Figure 3. 4153 o adopted retransmission mechanism from DHCPv6. 4155 o 1024 message size limit described in PCP message restriction. 4157 o Explained PCP server list, with example of host with IPv4 and IPv6 4158 addresses having two PCP servers (one IPv4 PCP server for IPv4 4159 mappings and one IPv6 PCP server for IPv6 mappings). 4161 o mention PCP client needs to expect unsolicited PCP responses from 4162 previous incarnations of itself (on the same host) or of this host 4163 (using same IP address as another PCP client). 4165 o eliminated overuse of 'packet format' when it was 'opcode format'. 4167 o for IANA registries, added code points assignable via Standards 4168 Action (previously was just Specification Required). 4170 o Version negotiation, added explanation that retrying after 30 4171 minutes makes the protocol self-healing if the PCP server is 4172 upgraded. 4174 o Version negotiation now accomodates non-contiguous version 4175 numbers. 4177 o Tweaked definition of VERSION field (that "1" is for this version, 4178 but other values could of course appear in the future). 4180 o when receiving unsolicited ANNOUNCE, PCP client now waits random 4181 0-5 seconds. 4183 o Removed 'interworking function' from list of terminology because 4184 we no longer use the term in this document. 4186 o tightened definitions of 'PCP client' and 'PCP server'. 4188 o For 'Requested Lifetime' definitions, removed text requiring its 4189 value be 0 for not-yet-defined opcodes. 4191 o Removed some unnecessary text suggesting logging (is an 4192 implementation detail). 4194 o Added active-mode FTP as example protocol that can break with 4195 mappings to different IP addresses. 4197 o Clarified that if PCP request contains a Suggested External 4198 Address, the PCP server should try to create a mapping to that 4199 address even if other mappings already exist to a different 4200 external address. 4202 o Changed "internal address and port" to "internal address, 4203 protocol, and port" in several places. 4205 o Clarified which 96 bits are copied into error response. Clarified 4206 that only error responses are copied verbatim from request. 4208 o a single PCP server can control multiple NATs or multiple 4209 firewalls (Section 4). 4211 o Clarified that sending unsolicited multicast ANNOUNCE is not 4212 always available on all networks. 4214 o Clarified option length error example is when option length 4215 exceeds UDP length 4217 o Explained that an on-path attacker that can spoof packets can re- 4218 direct traffic to a host of their choosing. 4220 o Instead of saying IPv4-mapped addresses won't appear on the wire, 4221 say they aren't used for mappings. 4223 o THIRD_PARTY is useful for management device (e.g., in a network 4224 operations center). 4226 o Clarified PCP responses have fields updated as indicated with 'set 4227 by the server' from field definitions. 4229 o Disallow using MAP to the PCP ports themselves and encourage 4230 implementations have policy control for other ports. 4232 o Instead of 'idempotent', now says 'identical requests generate 4233 identical response'. 4235 o Described which Options are included when sending Mapping Update 4236 (unsolicited responses), Section 14.2. 4238 o Dropped [RFC2136] and [RFC3007] to informative references. 4240 o Updated from 'should' to 'SHOULD' in Section 17.1. 4242 o Described 'hairpin' in terminology section. 4244 B.7. Changes from draft-ietf-pcp-base-22 to -23 4246 o Instead of returning error NO_RESOURCES when requesting a MAP for 4247 all protocols or for all ports, return UNSUPP_PROTOCOL. 4249 o Clarify that PEER-created mappings are treated as if it was 4250 implicit dynamic outbound mapping (Section 12.3). 4252 o Point out that PEER-created mappings may be very short until bi- 4253 directional traffic is seen by the PCP-managed device. 4255 o Clairification that an existing implicit mapping (created e.g., by 4256 TCP SYN) can become managed by a MAP request (Section 11.3. 4258 o Clarified the ANNOUNCE Opcode is being defined in Section 14.1, 4259 and that the length of requests (as well as responses) is zero. 4261 o Clarify that ANNOUNCE has Lifetime=0 for requests and responses. 4263 o Clarify ANNOUNCE can be sent unicast by the client (to solicit a 4264 response), or can be multicasted (unsolicited) by the server. 4266 o Allow ANNOUNCE to be sent unicast by the server, to accomodate 4267 case where PCP server fails but knows the IP address of a PCP 4268 client (e.g., web portal). 4270 o Clarified ports used for unicast and multicast unsolicited 4271 ANNOUNCE. 4273 o Tweaked NO_RESOURCES handling, to just disallow *new* mappings. 4275 o State diagram is now non-normative, because it overly simplifies 4276 that implicit mappings become MAP (when they actually still retain 4277 their previous behavior when the MAP expires). 4279 o In section Section 15, clarified that PEER cannot delete or 4280 shorten any lifetime, and that MAP can only shorten or delete 4281 lifetimes of MAP-created mappings. 4283 o Clarified handling of MAP when mapping already exists (4 steps). 4285 o 2^32-1 4287 o Randomize retry interval (1.5-2.5), and maximum retry interval is 4288 now 1024 seconds (was 15 minutes). 4290 o Remove MUST be 0 for Reserved field when sending error responses 4291 for un-parseable message. 4293 o Whenever PCP client includes Suggested IP Address (in MAP or 4294 PEER), the PCP server should try to fulfill that request, even if 4295 creating a mapping on that IP address means the internal host will 4296 have mappings on different IP addresses and ports. 4298 o For NO_RESOURCES error, the PCP client can attempt to renew and 4299 attempt to delete mappings (as they can help shed load) -- it just 4300 can't try to create new ones. 4302 o Removed the overly simplistic normative text regarding honoring 4303 Suggested External Address from Section 10 in favor of the text in 4304 Section 11.3 which has significantly more detail. 4306 B.8. Changes from draft-ietf-pcp-base-21 to -22 4308 o Removed paragraph discussing multiple addresses on the same 4309 (physical) interface; those will work with PCP. 4311 o The FILTER Option's Prefix Length field redefined to simply be a 4312 count of the relevant bits (rather than 0-32 for IPv4-mapped 4313 addresses). 4315 o Point out NO_RESOURCES attack vector in security considerations. 4317 o Tighten up recommendation for client handling long Lifetimes, and 4318 moved from the MAP-specific section to the General PCP Processing 4319 section. Client should normalize to 24 hours maximum for success 4320 and 30 minute maximum for errors. 4322 B.9. Changes from draft-ietf-pcp-base-20 to -21 4324 o To delete all mappings using THIRD_PARTY, use the all-zeros IP 4325 address (rather than previous text which used length=0). 4327 o added normative text for what PCP server does when it receives 4328 all-zeros IP address in THIRD_PARTY option. 4330 o PREFER_FAILURE allowed for use by web portal. 4332 o clarifications to mandatory option processing. 4334 o cleanup and wordsmithing of the THIRD_PARTY text. 4336 B.10. Changes from draft-ietf-pcp-base-19 to -20 4338 o clarify if Options are included in responses. 4340 o clarify when External Address can be ignored by the PCP server / 4341 PCP-controlled device 4343 o added 'Transition from state M to state I is implementation 4344 dependent' to state diagram 4346 B.11. Changes from draft-ietf-pcp-base-18 to -19 4348 o Described race condition with MAP containing PREFER_FAILURE and 4349 Mapping Update. 4351 o Added state machine (Section 16.5). 4353 o Fully integrated Rapid Recovery, with a separate Opcode having its 4354 own processing description. 4356 o Clarified that due to Mapping Update, a single MAP or PEER request 4357 can receive multiple responses, each updating the previous 4358 request, and that the PCP client needs to handle MAP updates or 4359 PEER updates accordingly. 4361 B.12. Changes from draft-ietf-pcp-base-17 to -18 4363 o Removed UNPROCESSED option. Instead, unprocessed options are 4364 simply not included in responses. 4366 o Updated terminology section for Implicit/Explicit and Outbound/ 4367 Inbound. 4369 o PEER requests cannot delete or shorten the lifetime of a mapping. 4371 o Clarified that PCP clients only retransmit mapping requests for as 4372 long as they actually want the mapping. 4374 o Revised Epoch time calculations and explanation. 4376 o Renamed the announcement opcode from No-Op to ANNOUNCE. 4378 B.13. Changes from draft-ietf-pcp-base-16 to -17 4380 o suggest acquiring a mapping to the Discard port if there is a 4381 desire to show the user their external address (Section 11.6). 4383 o Added Restart Announcement. 4385 o Tweaked terminology. 4387 o Detailed how error responses are generated. 4389 B.14. Changes from draft-ietf-pcp-base-15 to -16 4391 o fixed mistake in PCP request format (had 32 bits of extraneous 4392 fields) 4394 o Allow MAP to request all ports (port=0) for a specific protocol 4395 (protocol!=0), for the same reason we added support for all ports 4396 (port=0) and all protocols (protocol=0) in -15 4398 o corrected text on Client Processing a Response related to 4399 receiving ADDRESS_MISMATCH error. 4401 o updated Epoch text. 4403 o Added text that MALFORMED_REQUEST is generated for MAP if Protocol 4404 is zero but Internal Port is non-zero. 4406 B.15. Changes from draft-ietf-pcp-base-14 to -15 4408 o Softened and removed text that was normatively explaining how PEER 4409 is implemented within a NAT. 4411 o Allow a MAP request for protocol=0, which means "all protocols". 4412 This can work for an IPv6 or IPv4 firewall. Its use with a NAPT 4413 is undefined. 4415 o combined SERVER_OVERLOADED and NO_RESOURCES into one error code, 4416 NO_RESOURCES. 4418 o SCTP mappings have to use same internal and suggested external 4419 ports, and have implied PREFER_FAILURE semantics. 4421 o Re-instated ADDRESS_MISMATCH error, which only checks the client 4422 address (not its port). 4424 B.16. Changes from draft-ietf-pcp-base-13 to -14 4426 o Moved discussion of socket operations for PCP source address into 4427 Implementation Considerations section. 4429 o Integrated numerous WGLC comments. 4431 o NPTv6 in scope. 4433 o Re-written security considerations section. Thanks, Margaret! 4435 o Reduced PEER4 and PEER6 Opcodes to just a single Opcode, PEER. 4437 o Reduced MAP4 and MAP6 Opcodes to just a single Opcode, MAP. 4439 o Rearranged the PEER packet formats to align with MAP. 4441 o Removed discussion of the "O" bit for Options, which was 4442 confusing. Now the text just discusses the most significant bit 4443 of the Option code which indicates mandatory/optional, so it is 4444 clearer the field is 8 bits. 4446 o The THIRD_PARTY Option from an unauthorized host generates 4447 UNSUPP_OPTION, so the PCP server doesn't disclose it knows how to 4448 process THIRD_PARTY Option. 4450 o Added table to show which fields of MAP or PEER need IPv6/IPv4 4451 addresses for IPv4 firewall, DS-Lite, NAT64, NAT44, etc. 4453 o Accommodate the server's Epoch going up or down, to better detect 4454 switching to a different PCP server. 4456 o Removed ADDRESS_MISMATCH; the server always includes its idea of 4457 the Client's IP Address and Port, and it's up to the client to 4458 detect a mismatch (and rectify it). 4460 B.17. Changes from draft-ietf-pcp-base-12 to -13 4462 o All addresses are 128 bits. IPv4 addresses are represented by 4463 IPv4-mapped IPv6 addresses (::FFFF/96) 4465 o PCP request header now includes PCP client's port (in addition to 4466 the client's IP address, which was in -12). 4468 o new ADDRESS_MISMATCH error. 4470 o removed PROCESSING_ERROR error, which was too similar to 4471 MALFORMED_REQUEST. 4473 o Tweaked text describing how PCP client deals with multiple PCP 4474 server addresses (Section 8.1) 4476 o clarified that when overloaded, the server can send 4477 SERVER_OVERLOADED (and drop requests) or simply drop requests. 4479 o Clarified how PCP client chooses MAP4 or MAP6, depending on the 4480 presence of its own IPv6 or IPv4 interfaces (Section 10). 4482 o compliant PCP server MUST support MAPx and PEERx, SHOULD support 4483 ability to disable support. 4485 o clarified that MAP-created mappings have no filtering, and PEER- 4486 created mappings have whatever filtering and mapping behavior is 4487 normal for that particular NAT / firewall. 4489 o Integrated WGLC feedback (small changes to abstract, definitions, 4490 and small edits throughout the document) 4492 o allow new Options to be defined with a specification (rather than 4493 standards action) 4495 B.18. Changes from draft-ietf-pcp-base-11 to -12 4497 o added implementation note that MAP and implicit dynamic mappings 4498 have independent mapping lifetimes. 4500 B.19. Changes from draft-ietf-pcp-base-10 to -11 4502 o clarified what can cause CANNOT_PROVIDE_EXTERNAL error to be 4503 generated. 4505 B.20. Changes from draft-ietf-pcp-base-09 to -10 4507 o Added External_AF field to PEER requests. Made PEER's Suggested 4508 External IP Address and Assigned External IP Address always be 128 4509 bits long. 4511 B.21. Changes from draft-ietf-pcp-base-08 to -09 4513 o Clarified in PEER Opcode introduction (Section 12) that they can 4514 also create mappings. 4516 o More clearly explained how PEER can re-create an implicit dynamic 4517 mapping, for purposes of rebuilding state to maintain an existing 4518 session (e.g., long-lived TCP connection to a server). 4520 o Added Suggested External IP Address to the PEER Opcodes, to allow 4521 more robust rebuilding of connections. Added related text to the 4522 PEER server processing section. 4524 o Removed text encouraging PCP server to statefully remember its 4525 mappings from Section 16.3.1, as it didn't belong there. Text in 4526 Security Considerations already encourages persistent storage. 4528 o More clearly discussed how PEER is used to re-establish TCP 4529 mapping state. Moved it to a new section, as well (it is now 4530 Section 10.4). 4532 o MAP errors now copy the Suggested Address (and port) fields to 4533 Assigned IP Address (and port), to allow PCP client to distinguish 4534 among many outstanding requests when using PREFER_FAILURE. 4536 o Mapping theft can also be mitigated by ensuring hosts can't re-use 4537 same IP address or port after state loss. 4539 o the UNPROCESSED option is renumbered to 0 (zero), which ensures no 4540 other option will be given 0 and be unable to be expressed by the 4541 UNPROCESSED option (due to its 0 padding). 4543 o created new Implementation Considerations section (Section 16) 4544 which discusses non-normative things that might be useful to 4545 implementers. Some new text is in here, and the Failure Scenarios 4546 text (Section 16.3) has been moved to here. 4548 o Tweaked wording of EDM NATs in Section 16.1 to clarify the problem 4549 occurs both inside->outside and outside->inside. 4551 o removed "Interference by Other Applications on Same Host" section 4552 from security considerations. 4554 o fixed zero/non-zero text in Section 15. 4556 o removed duplicate text saying MAP is allowed to delete an implicit 4557 dynamic mapping. It is still allowed to do that, but it didn't 4558 need to be said twice in the same paragraph. 4560 o Renamed error from UNAUTH_TARGET_ADDRESS to 4561 UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS. 4563 o for FILTER option, removed unnecessary detail on how FILTER would 4564 be bad for PEER, as it is only allowed for MAP anyway. 4566 o In Security Considerations, explain that PEER can create a mapping 4567 which makes its security considerations the same as MAP. 4569 B.22. Changes from draft-ietf-pcp-base-07 to -08 4571 o moved all MAP4-, MAP6-, and PEER-specific options into a single 4572 section. 4574 o discussed NAT port-overloading and its impact on MAP (new section 4575 Section 16.1), which allowed removing the IMPLICIT_MAPPING_EXISTS 4576 error. 4578 o eliminated NONEXIST_PEER error (which was returned if a PEER 4579 request was received without an implicit dynamic mapping already 4580 being created), and adjusted PEER so that it creates an implicit 4581 dynamic mapping. 4583 o Removed Deployment Scenarios section (which detailed NAT64, NAT44, 4584 Dual-Stack Lite, etc.). 4586 o Added Client's IP Address to PCP common header. This allows 4587 server to refuse a PCP request if there is a mismatch with the 4588 source IP address, such as when a non-PCP-aware NAT was on the 4589 path. This should reduce failure situations where PCP is deployed 4590 in conjunction with a non-PCP-aware NAT. This addition was 4591 consensus at IETF80. 4593 o Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that 4594 MALFORMED_REQUEST is for malformed requests (and not related to 4595 failed attempts to process the request). 4597 o Removed MISORDERED_OPTIONS. Consensus of IETF80. 4599 o SERVER_OVERLOADED is now a common PCP error (instead of specific 4600 to MAP). 4602 o Tweaked PCP retransmit/retry algorithm again, to allow more 4603 aggressive PCP discovery if an implementation wants to do that. 4605 o Version negotiation text tweaked to soften NAT-PMP reference, and 4606 more clearly explain exactly what UNSUPP_VERSION should return. 4608 o PCP now uses NAT-PMP's UDP port, 5351. There are no normative 4609 changes to NAT-PMP or PCP to allow them both to use the same port 4610 number. 4612 o New Appendix A to discuss NAT-PMP / PCP interworking. 4614 o improved pseudocode to be non-blocking. 4616 o clarified that PCP cannot delete a static mapping (i.e., a mapping 4617 created by CLI or other non-PCP means). 4619 o moved theft of mapping discussion from Epoch section to Security 4620 Considerations. 4622 B.23. Changes from draft-ietf-pcp-base-06 to -07 4624 o tightened up THIRD_PARTY security discussion. Removed "highest 4625 numbered address", and left it as simply "the CPE's IP address". 4627 o removed UNABLE_TO_DELETE_ALL error. 4629 o renumbered Opcodes 4631 o renumbered some error codes 4633 o assigned value to IMPLICIT_MAPPING_EXISTS. 4635 o UNPROCESSED can include arbitrary number of option codes. 4637 o Moved lifetime fields into common request/response headers 4638 o We've noticed we're having to repeatedly explain to people that 4639 the "requested port" is merely a hint, and the NAT gateway is free 4640 to ignore it. Changed name to "suggested port" to better convey 4641 this intention. 4643 o Added NAT-PMP transition section 4645 o Separated Internal Address, External Address, Remote Peer Address 4646 definition 4648 o Unified Mapping, Port Mapping, Port Forwarding definition 4650 o adjusted so DHCP configuration is non-normative. 4652 o mentioned PCP refreshes need to be sent over the same interface. 4654 o renamed the REMOTE_PEER_FILTER option to FILTER. 4656 o Clarified FILTER option to allow sending an ICMP error if policy 4657 allows. 4659 o for MAP, clarified that if the PCP client changed its IP address 4660 and still wants to receive traffic, it needs to send a new MAP 4661 request. 4663 o clarified that PEER requests have to be sent from same interface 4664 as the connection itself. 4666 o for MAP opcode, text now requires mapping be deleted when lifetime 4667 expires (per consensus on 8-Mar interim meeting) 4669 o PEER Opcode: better description of remote peer's IP address, 4670 specifically that it does not control or establish any filtering, 4671 and explaining why it is 'from the PCP client's perspective'. 4673 o Removed latent text allowing DMZ for 'all protocols' (protocol=0). 4674 Which wouldn't have been legal, anyway, as protocol 0 is assigned 4675 by IANA to HOPOPT (thanks to James Yu for catching that one). 4677 o clarified that PCP server only listens on its internal interface. 4679 o abandoned 'target' term and reverted to simplier 'internal' term. 4681 B.24. Changes from draft-ietf-pcp-base-05 to -06 4683 o Dual-Stack Lite: consensus was encapsulation mode. Included a 4684 suggestion that the B4 will need to proxy PCP-to-PCP and UPnP-to- 4685 PCP. 4687 o defined THIRD_PARTY Option to work with the PEER Opcode, too. 4688 This meant moving it to its own section, and having both MAP and 4689 PEER Opcodes reference that common section. 4691 o used "target" instead of "internal", in the hopes that clarifies 4692 internal address used by PCP itself (for sending its packets) 4693 versus the address for MAPpings. 4695 o Options are now required to be ordered in requests, and ordering 4696 has to be validated by the server. Intent is to ease server 4697 processing of mandatory-to-implement options. 4699 o Swapped Option values for the mandatory- and optional-to-process 4700 Options, so we can have a simple lowest..highest ordering. 4702 o added MISORDERED_OPTIONS error. 4704 o re-ordered some error messages to cause MALFORMED_REQUEST (which 4705 is PCP's most general error response) to be error 1, instead of 4706 buried in the middle of the error numbers. 4708 o clarified that, after successfully using a PCP server, that PCP 4709 server is declared to be non-responsive after 5 failed 4710 retransmissions. 4712 o tightened up text (which was inaccurate) about how long general 4713 PCP processing is to delay when receiving an error and if it 4714 should honor Opcode-specific error lifetime. Useful for MAP 4715 errors which have an error lifetime. (This all feels awkward to 4716 have only some errors with a lifetime.) 4718 o Added better discussion of multiple interfaces, including 4719 highlighting Wi-Fi+Ethernet. Added discussion of using IPv6 4720 Privacy Addresses and RFC1918 as source addresses for PCP 4721 requests. This should finish the section on multi-interface 4722 issues. 4724 o added some text about why server might send SERVER_OVERLOADED, or 4725 might simply discard packets. 4727 o Dis-allow internal-port=0, which means we dis-allow using PCP as a 4728 DMZ-like function. Instead, ports have to be mapped individually. 4730 o Text describing server's processing of PEER is tightened up. 4732 o Server's processing of PEER now says it is implementation-specific 4733 if a PCP server continues to allow the mapping to exist after a 4734 PEER message. Client's processing of PEER says that if client 4735 wants mapping to continue to exist, client has to continue to send 4736 recurring PEER messages. 4738 B.25. Changes from draft-ietf-pcp-base-04 to -05 4740 o tweaked PCP common header packet layout. 4742 o Re-added port=0 (all ports). 4744 o minimum size is 12 octets (missed that change in -04). 4746 o removed Lifetime from PCP common header. 4748 o for MAP error responses, the lifetime indicates how long the 4749 server wants the client to avoid retrying the request. 4751 o More clearly indicated which fields are filled by the server on 4752 success responses and error responses. 4754 o Removed UPnP interworking section from this document. It will 4755 appear in [I-D.ietf-pcp-upnp-igd-interworking]. 4757 B.26. Changes from draft-ietf-pcp-base-03 to -04 4759 o "Pinhole" and "PIN" changed to "mapping" and "MAP". 4761 o Reduced from four MAP Opcodes to two. This was done by implicitly 4762 using the address family of the PCP message itself. 4764 o New option THIRD_PARTY, to more carefully split out the case where 4765 a mapping is created to a different host within the home. 4767 o Integrated a lot of editorial changes from Stuart and Francis. 4769 o Removed nested NAT text into another document, including the IANA- 4770 registered IP addresses for the PCP server. 4772 o Removed suggestion (MAY) that PCP server reserve UDP when it maps 4773 TCP. Nobody seems to need that. 4775 o Clearly added NAT and NAPT, such as in residential NATs, as within 4776 scope for PCP. 4778 o HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE 4780 o Added 'Lifetime' field to the common PCP header, which replaces 4781 the functions of the 'temporary' and 'permanent' error types of 4782 the previous version. 4784 o Allow arbitrary Options to be included in PCP response, so that 4785 PCP server can indicate un-supported PCP Options. Satisfies PCP 4786 Issue #19 4788 o Reduced scope to only deal with mapping protocols that have port 4789 numbers. 4791 o Reduced scope to not support DMZ-style forwarding. 4793 o Clarified version negotiation. 4795 B.27. Changes from draft-ietf-pcp-base-02 to -03 4797 o Adjusted abstract and introduction to make it clear PCP is 4798 intended to forward ports and intended to reduce application 4799 keepalives. 4801 o First bit in PCP common header is set. This allows DTLS and non- 4802 DTLS to be multiplexed on same port, should a future update to 4803 this specification add DTLS support. 4805 o Moved subscriber identity from common PCP section to MAP* section. 4807 o made clearer that PCP client can reduce mapping lifetime if it 4808 wishes. 4810 o Added discussion of host running a server, client, or symmetric 4811 client+server. 4813 o Introduced PEER4 and PEER6 Opcodes. 4815 o Removed REMOTE_PEER Option, as its function has been replaced by 4816 the new PEER Opcodes. 4818 o IANA assigned port 44323 to PCP. 4820 o Removed AMBIGUOUS error code, which is no longer needed. 4822 B.28. Changes from draft-ietf-pcp-base-01 to -02 4824 o more error codes 4826 o PCP client source port number should be random 4828 o PCP message minimum 8 octets, maximum 1024 octets. 4830 o tweaked a lot of text in section 7.4, "Opcode-Specific Server 4831 Operation". 4833 o opening a mapping also allows ICMP messages associated with that 4834 mapping. 4836 o PREFER_FAILURE value changed to the mandatory-to-process range. 4838 o added text recommending applications that are crashing obtain 4839 short lifetimes, to avoid consuming subscriber's port quota. 4841 B.29. Changes from draft-ietf-pcp-base-00 to -01 4843 o Significant document reorganization, primarily to split base PCP 4844 operation from Opcode operation. 4846 o packet format changed to move 'protocol' outside of PCP common 4847 header and into the MAP* opcodes 4849 o Renamed Informational Elements (IE) to Options. 4851 o Added REMOTE_PEER (for disambiguation with dynamic ports), 4852 REMOTE_PEER_FILTER (for simple packet filtering), and 4853 PREFER_FAILURE (to optimize UPnP IGDv1 interworking) options. 4855 o Is NAT or router behind B4 in scope? 4857 o PCP option MAY be included in a request, in which case it MUST 4858 appear in a response. It MUST NOT appear in a response if it was 4859 not in the request. 4861 o Result code most significant bit now indicates permanent/temporary 4862 error 4864 o PCP Options are split into mandatory-to-process ("P" bit), and 4865 into Specification Required and Private Use. 4867 o Epoch discussion simplified. 4869 Authors' Addresses 4871 Dan Wing (editor) 4872 Cisco Systems, Inc. 4873 170 West Tasman Drive 4874 San Jose, California 95134 4875 USA 4877 Email: dwing@cisco.com 4878 Stuart Cheshire 4879 Apple Inc. 4880 1 Infinite Loop 4881 Cupertino, California 95014 4882 USA 4884 Phone: +1 408 974 3207 4885 Email: cheshire@apple.com 4887 Mohamed Boucadair 4888 France Telecom 4889 Rennes, 35000 4890 France 4892 Email: mohamed.boucadair@orange.com 4894 Reinaldo Penno 4895 Cisco Systems, Inc. 4896 170 West Tasman Drive 4897 San Jose, California 95134 4898 USA 4900 Email: repenno@cisco.com 4902 Paul Selkirk 4903 Internet Systems Consortium 4904 950 Charter Street 4905 Redwood City, California 94063 4906 USA 4908 Email: pselkirk@isc.org