idnits 2.17.1 draft-wing-pcp-base-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 581 has weird spacing: '...al port reque...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 25, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Saltzer84' is defined on line 1486, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-05) exists of draft-arkko-dual-stack-extra-lite-03 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP working group D. Wing 3 Internet-Draft Cisco 4 Intended status: Standards Track October 25, 2010 5 Expires: April 28, 2011 7 Pinhole Control Protocol (PCP) 8 draft-wing-pcp-base-01 10 Abstract 12 Pinhole Control Protocol is an address-family independent mechanism 13 to control how incoming packets are forwarded by upstream devices 14 such as IPv4 NAT devices, NAT64 devices, and IPv6 firewalls. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 4 59 2.2. Supported Transport Protocols . . . . . . . . . . . . . . 5 60 2.3. Single-homed Customer Premise Network . . . . . . . . . . 5 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. PCP Server Discovery . . . . . . . . . . . . . . . . . . . . . 6 63 5. Common Request and Response Header Format . . . . . . . . . . 7 64 5.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Response Header . . . . . . . . . . . . . . . . . . . . . 8 66 5.3. Information Elements . . . . . . . . . . . . . . . . . . . 9 67 5.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. PIN OpCodes . . . . . . . . . . . . . . . . . . . . . . . 11 70 7. PCP Mapping State Maintenance . . . . . . . . . . . . . . . . 14 71 7.1. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.2. Recreating Pinholes . . . . . . . . . . . . . . . . . . . 15 73 7.3. Maintaining Pinholes . . . . . . . . . . . . . . . . . . . 17 74 7.4. Nested NATs . . . . . . . . . . . . . . . . . . . . . . . 17 75 8. Processing Pinhole Requests and Responses . . . . . . . . . . 18 76 8.1. Generating and Sending a Request . . . . . . . . . . . . . 18 77 8.2. Processing a Request and Generating the Response . . . . . 18 78 8.3. Processing a Response . . . . . . . . . . . . . . . . . . 20 79 9. PCP Client Operation . . . . . . . . . . . . . . . . . . . . . 20 80 9.1. Pinhole Lifetime Extension . . . . . . . . . . . . . . . . 20 81 9.2. Pinhole Deletion . . . . . . . . . . . . . . . . . . . . . 20 82 9.3. Multi-interface Issues . . . . . . . . . . . . . . . . . . 21 83 9.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 21 84 10. PCP Server Operation . . . . . . . . . . . . . . . . . . . . . 21 85 10.1. Relationship of PCP Server and its NAT . . . . . . . . . . 21 86 10.2. Pinhole Lifetime . . . . . . . . . . . . . . . . . . . . . 22 87 10.3. Pinhole deletion . . . . . . . . . . . . . . . . . . . . . 22 88 10.4. Subscriber Identification . . . . . . . . . . . . . . . . 23 89 10.5. External IP Address . . . . . . . . . . . . . . . . . . . 24 90 11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24 91 11.1. Dual Stack-Lite . . . . . . . . . . . . . . . . . . . . . 24 92 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 24 93 11.1.2. Encapsulation Mode . . . . . . . . . . . . . . . . . 25 94 11.1.3. Plain IPv6 Mode . . . . . . . . . . . . . . . . . . . 25 95 11.2. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 11.3. NAT44 and NAT444 . . . . . . . . . . . . . . . . . . . . . 26 97 11.4. IPv6 Firewall . . . . . . . . . . . . . . . . . . . . . . 26 98 12. Adjacent Port Procedure . . . . . . . . . . . . . . . . . . . 26 99 13. Interworking with UPnP IGD . . . . . . . . . . . . . . . . . . 27 100 13.1. UPnP IGD 1.0 with AddPortMapping Action . . . . . . . . . 27 101 13.2. UPnP IGD 2.0 with AddAnyPortMapping Action . . . . . . . . 29 102 13.3. Lifetime Maintenance . . . . . . . . . . . . . . . . . . . 30 103 14. NAT-PMP Backwards Compatibility . . . . . . . . . . . . . . . 30 104 15. Security Considerations . . . . . . . . . . . . . . . . . . . 31 105 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 106 16.1. PCP Server IP address . . . . . . . . . . . . . . . . . . 31 107 16.2. Port Number . . . . . . . . . . . . . . . . . . . . . . . 31 108 16.3. OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 16.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 31 110 16.5. Information Elements . . . . . . . . . . . . . . . . . . . 31 111 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 112 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 18.1. Normative References . . . . . . . . . . . . . . . . . . . 32 114 18.2. Informative References . . . . . . . . . . . . . . . . . . 33 115 Appendix A. Analysis of Techniques to Discover PCP Server . . . . 34 116 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 118 1. Introduction 120 Pinhole Control Protocol (PCP) provides a mechanism to control how 121 incoming packets are forwarded by upstream devices such as NATs and 122 firewalls. PCP is primarily designed to be implemented in the 123 context of both large scale NAT and low-scale NAT (e.g., residential 124 NATs). PCP allows hosts to operate servers permanently (e.g., a 125 webcam) or temporarily (e.g., while playing a game) when behind one 126 or more NAT devices, including when behind a large-scale NAT operated 127 by their Internet service provider. 129 PCP allows applications to create pinholes from an external IP 130 address to an internal IP address and port. If the PCP-controlled 131 device is a NAT, a mapping is created; if the PCP-controlled device 132 is a firewall, a pinhole is created in the firewall. These pinholes 133 are required for successful inbound communications destined to 134 machines located behind a NAT. 136 After creating a pinhole for incoming connections, it is necessary to 137 inform remote computers about the IP address and port for the 138 incoming connection. This is usually done in an application-specific 139 manner. For example, a computer game would use a rendzevous server 140 specific to that game (or specific to that game developer), and a SIP 141 phone would use a SIP proxy. PCP does not provide this rendezvous 142 function. 144 2. Scope 146 2.1. Deployment Scenarios 148 PCP can be used in various deployment scenarios, including: 150 o DS-Lite [I-D.ietf-softwire-dual-stack-lite], and; 152 o NAT64, both Stateful [I-D.ietf-behave-v6v4-xlate-stateful] and 153 Stateless [I-D.ietf-behave-v6v4-xlate], and; 155 o Large-Scale NAT44 [I-D.ietf-behave-lsn-requirements], including 156 nested NATs ("NAT444"), and; 158 o Layer-2 aware NAT [I-D.miles-behave-l2nat] and Dual-Stack Extra 159 Lite [I-D.arkko-dual-stack-extra-lite], and; 161 o IPv6 firewall control [I-D.ietf-v6ops-cpe-simple-security]. 163 2.2. Supported Transport Protocols 165 The PCP OpCodes defined in this document are designed to support 166 transport protocols that uses a port number (e.g., TCP, UDP, SCTP, 167 DCCP). Transport protocols that do not use a port number (e.g., 168 IPsec ESP) can be wildcarded (allowing any traffic with that protocol 169 to pass), provided of course the upstream device being controlled by 170 PCP supports that functionality, or new PCP OpCodes can be defined to 171 support those protocols. 173 In this document, only TCP and UDP are defined. 175 2.3. Single-homed Customer Premise Network 177 The PCP machinery assumes a single-homed subscriber model. That is, 178 for a given IP version, only one default route exists to reach the 179 Internet, much as there is only one default route for a dynamic 180 connection (e.g., TCP SYN) towards the Internet. This restriction 181 exists because otherwise there would need to be one PCP server for 182 each egress, because the host could not reliably determine which 183 egress path packets would take. 185 3. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC2119]. 191 Port Forwarding: 193 Port forwarding allows a host to receive traffic sent to a 194 specific IP address and port. 196 In the context of a NAT with internal and external IP 197 addresses, if an internal host is listening to connections on a 198 specific port (that is, operating as a server), the external IP 199 address and port number need to be port forwarded (also called 200 "mapped") to the internal IP address and port number. The 201 internal and external IP addresses are different, and a key 202 point is that the internal and external transport destination 203 port numbers could be different. For example, a webcam might 204 be listening on port 80 on its internal address 192.168.1.1, 205 while its publicly-accessible external address is 192.0.2.1 and 206 port is 12345. The NAT does 'port forwarding' of one to the 207 other. 209 In the context of a firewall, the internal and external IP 210 addresses (and ports) are not changed. 212 PCP Client: 214 The network element that sends PCP requests to the PCP Server. 215 This network element could be an application running on a host, 216 embedded in the host's OS or libraries, or running on a network 217 device (such as a customer premise router). 219 PCP Server: 221 A network element which receives and processes PCP requests 222 from a PCP Client. See also Section 10.1. 224 Mapping: 226 In the context of Network Address Translation a mapping creates 227 a relationship between an internal IP transport address and an 228 external IP transport address. More specifically, it creates a 229 translation rule where packets destined to the external IP and 230 port are translated to the internal IP and port. 232 Mapping Types: 234 There are three different ways to create mappings: dynamic 235 (e.g., outgoing TCP SYN), PCP, and static configured (e.g., CLI 236 or web page) . These mappings are one and the same but their 237 attributes such as lifetime or filtering might be different. 239 Interworking Function: A PCP Interworking Function denotes a 240 functional element which is responsible for another protocol with 241 PCP, for example interworking with UPnP IGD [IGD] described in 242 Section 13. 244 4. PCP Server Discovery 246 There are several possible methods to discover a PCP Service: 248 o sending the PCP message to the default router. This requires the 249 default router to support PCP. 251 o a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA. 252 This follows the same routing path as other Internet-bound 253 traffic. 255 [Ed. Note: For an IPv4 address, would the AFTR element's IPv4 256 address, 192.0.0.1, be suitable as this address for DS-Lite 257 deployments? Would that same address be suitable for all PCP 258 deployment scenarios?] 260 o New DHCP option. This requires the local network's DHCP server 261 support the new option. 263 [Ed. Note: more discussion around these methods is necessary to 264 reach consensus on the best approach(es)s for PCP.] 266 5. Common Request and Response Header Format 268 PCP is intended to be backwards compatible with NAT-PMP so that a 269 NAT-PMP client (or server) will receive an error message when sending 270 a request to a PCP server (or client). 272 All PCP messages contain a request (or response) header, opcode- 273 specific information, and (optional) informational elements. These 274 are described in the following sections. 276 5.1. Request Header 278 All requests have the following format: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Ver=1 |reserve| OpCode | Protocol | Reserved | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Reserved (32 bits) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 : : 288 : (optional) opcode-specific information : 289 : : 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 : (optional) Informational Elements : 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 1: Common Request Packet Format 296 These fields are described below: 298 Ver: Version is 1 299 reserve: 4 reserved bits, MUST be sent as 0, MUST be ignored when 300 received. 302 OpCode: defined in Figure 5. 304 Protocol: indicates protocol associated with this opcode. For 305 example, this field contains 6 (TCP) if the opcode is intended to 306 create a TCP mapping. Values are taken from the IANA protocol 307 registry [proto_numbers]. If a particular OpCode does not need 308 the field, it MUST sent as 0 and MUST be ignored when received. 310 Reserved: The reserved fields MUST be sent as 0 and MUST be ignored 311 when received. 313 5.2. Response Header 315 All responses have the following format: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Ver=1 |reserve| Opcode+128 | Protocol | Result Code | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Epoch | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 : : 325 : (optional) OpCode-specific response data : 326 : : 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 : (optional) Informational Elements : 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: Common Response Packet Format 333 These fields are described below: 335 Ver: Version is 1 337 reserve: 4 reserved bits, MUST be sent as 0, MUST be ignored when 338 received. 340 OpCode+128: The OpCode value from the request plus 128. 342 Protocol: Protocol field, echoed exactly from the request 343 Result Code: The result code for this response. See Section 5.4 for 344 values. 346 Epoch: The server's Epoch value. The same value is used for all PCP 347 clients. See Section 7.1 for discussion. 349 5.3. Information Elements 351 The Informational Elements (IE) allow extending PCP, without defining 352 a new PCP version and without consuming additional opcodes. IEs can 353 be used in requests and responses. It is anticipated that IEs will 354 include information which are associated with the normal function of 355 an OpCode, such as one of the PIN OpCodes defined in this document. 356 For example, an IE could indicate DSCP markings to apply to incoming 357 or outgoing traffic associated with a PCP pinhole, or an IE could 358 include descriptive text (e.g., "for my webcam"). 360 IEs use the following Type-Length-Value format: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | IE Code | Reserved | IE-Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 : data : 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 3: Informational Element header 371 The description of the fields is as follows: 373 IE Code: IE codes MUST be registered with IANA following the 374 procedure described in Section 16.5. 376 Reserved: MUST be set to 0 on transmission and MUST be ignored on 377 reception. 379 IE-Length: Indicates in units of 4 octets the length of the enclosed 380 data. IEs MUST be padded when necessary to 32 bits boundaries. 381 IEs with length of 0 are allowed. 383 A given IE MAY be included in the request and/or the response. The 384 handling of an IE at the PCP Client and the PCP Server sides MUST be 385 specified in dedicated document(s). 387 [Ed. Note: Do we want to allow an unsolicited IE to appear in a 388 response?] 390 If several IEs are to be included in a PCP request or response, IEs 391 MAY be encoded in any order by the PCP Client or the PCP Server. 393 [Ed. Note: There are two proposals to handle unsupported IEs on 394 the server: (1) return a notification in the response with the 395 Code(s) of unsupported IEs, (2) every IE that appears in a request 396 will cause an IE to appear in the response if the server 397 understood the request' IE(s). Consensus is needed.] 399 [Ed. Note: There is a proposal to define a Mandatory bit, so that 400 the PCP server will not process a PCP request at all if it 401 encounters an unsupported IE with the Mandatory bit set. This 402 diverges from IE being "informational", but may have some value. 403 Consensus is needed.] 405 New IEs are defined in companion documents and MUST follow the format 406 shown in Figure 1. To avoid errors and increased complexity, it is 407 RECOMMENDED to define one single IE which carry all the required 408 information for a given usage instead of defining several IEs to be 409 included simultaneously in the same PCP message. Interdependence 410 between IEs SHOULD be avoided at maximum. 412 5.4. Result Codes 414 The following response codes are defined: 416 0 - Success 417 1 - Unsupported Version 418 2 - Not Authorized/Refused 419 (e.g., PCP server supports mapping, but feature is disabled) 420 3 - Network Failure 421 (e.g., NAT device has not obtained a DHCP lease) 422 4 - Out of resources 423 (e.g., NAT device cannot create more mappings at this time) 424 5 - Unsupported opcode 426 Figure 4: PCP Result Codes 428 Additional result codes are defined following the procedure in 429 Section 16.4. 431 6. OpCodes 433 This document defines four OpCodes which share a similar packet 434 layout for requests and responses. For these OpCodes, the request 435 and response packet formats take the same space and layout. New 436 OpCodes MAY choose to follow the same format. The OpCodes defined in 437 this document are: 439 PIN44 = 0 = IPv4 address to IPv4 address (NAT44 or IPv4 firewall) 440 PIN46 = 1 = IPv4 address to IPv6 address (NAT46) 441 PIN64 = 2 = IPv6 address to IPv4 address (NAT64) 442 PIN66 = 3 = IPv6 address to IPv6 address (NAT66 or IPv6 firewall) 444 Figure 5: OpCodes 446 6.1. PIN OpCodes 448 The four PIN OpCodes (PIN44, PIN46, PIN64, PIN66) share a similar 449 packet layout for both requests and responses. Because of this 450 similarity, they are shown together. For all of the PIN OpCodes, if 451 the internal-ip-address and internal-port matches (requested) 452 external-ip-address and (requested) external-port, the (request or) 453 response pertains to a firewall; otherwise it pertains to a NAT. 455 The following diagram shows the request packet format for PIN44, 456 PIN46, PIN64, and PIN66: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 | | 463 | Reserved (always 160 bits) | 464 | | 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 : : 468 : Pinhole Internal IP address (32 or 128, depending on OpCode) : 469 : : 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 : : 472 : Requested external IP address (32 or 128, depending on OpCode): 473 : : 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Requested lifetime | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | internal port | requested external port | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 6: PIN OpCode Request Packet Format 482 These fields are described below: 484 Reserved: MUST be 0 on transmission and MUST be ignored on 485 reception. 487 Pinhole Internal IP Address: Internal IP address of the pinhole. 488 This can be IPv4 or IPv6, depending on the OpCode. 490 Requested External IP Address: Requested external IP address. This 491 is useful for refreshing a mapping, especially after the PCP 492 server loses state. If the PCP server can fulfill the request, it 493 will do so. If the PCP client doesn't know the external address, 494 or doesn't have a preference, it MAY place any value into this 495 field including 0. If the Pinhole Internal IP Address equals the 496 Requested External IP Address, it indicates the PCP client wants 497 firewall (versus NAT) behavior. 499 Requested lifetime: Requested lifetime of this pinhole, in seconds. 501 internal port: Internal port for the pinhole. 503 requested external port: requested external port. 505 internal port: Internal port for the pinhole, copied from request. 507 Assigned external port: requested external port for the mapping. 508 This is useful for refreshing a mapping, especially after the PCP 509 server loses state. If the PCP server can fulfill the request, it 510 will do so. If the PCP client doesn't know the external port, or 511 doesn't have a preference, it SHOULD use 0. 513 [Ed. Note: for firewall, we need to add fields indicating the 514 remote peer address (address family will match the address family 515 of the requsted IP address). Addition permission for multiple 516 remote peers is possible (by sending multiple PCP requests, one 517 for each remote peer's IP address). Deleting a single permission 518 would require a new OpCode. Should perhaps firewall use different 519 OpCodes than NAT??] 521 The following diagram shows the response packet format for PIN44, 522 PIN46, PIN64, and PIN66: 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | PCP Request Address Family | PCP Request Port | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 | PCP Request IP Address (always 128 bits) | 531 | (first 32 bits are XOR'd) | 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 : : 535 : Pinhole Internal IP address (32 or 128, depending on OpCode) : 536 : : 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 : : 539 : Assigned external IP address (32 or 128, depending on OpCode) : 540 : : 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Assigned lifetime | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | internal port | assigned external port | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 7: PIN OpCode Response Packet Format 549 These fields are described below: 551 PCP Request Address Family: The IP address family of the PCP 552 request, as received in the IP header by the PCP server. Will 553 usually be 1 (IPv4) or 2 (IPv6). This is used by the PCP client 554 to determine if there is a NAT between the PCP client and PCP 555 server (see Section 7.4). 557 PCP Request Port: The port of the PCP request, as received in the 558 UDP header by the PCP server. This is used by the PCP client to 559 determine if there is a NAT between the PCP client and PCP server 560 (see Section 7.4). 562 PCP Request IP Address: The IPv4 or IPv6 address of the PCP request, 563 as received in the IP header by the PCP server. This is used by 564 the PCP client to determine if there is a NAT between the PCP 565 client and PCP server (see Section 7.4). As some NATs rewrite 566 IPv4 packets containing the NAT's public IPv4 address in the UDP 567 payload, the first 32 bits of the address are XOR'd with 568 0xFFFFFFFF if it contains an IPv4 address; IPv6 addresses are not 569 XOR'd. 571 Pinhole Internal IP address Copied from request. IPv4 or IPv6 572 address is indicated by the OpCode. 574 Assigned external IP address Assigned external IPv4 or IPv6 address 575 for the pinhole. IPv4 or IPv6 address is indicated by the OpCode 577 Assigned Lifetime Lifetime for this mapping, in seconds 579 internal port Internal port for the pinhole, copied from request. 581 Assigned external port requested external port for the mapping. 582 IPv4 or IPv6 address is indicated by the OpCode 584 7. PCP Mapping State Maintenance 586 If an event occurs that causes the PCP server and NAT to lose state 587 (such as a crash or power outage), the pinholes created by PCP are 588 lost. Such loss of state is rare in a service provider environment 589 (due to redundant power, disk drives for storage, etc.). But such 590 loss of state is more common in a residential NAT device which does 591 not write information to its non-volatile memory. 593 The Epoch indicates if the PCP server has lost its state. If this 594 occurs, the PCP client can attempt to recreate the pinholes following 595 the procedures described in this section. 597 7.1. Epoch 599 Every packet sent by the PCP Server includes a "Seconds since start 600 of epoch" field (SSSOE). The PCP Server MUST set its Epoch time to 601 zero when it is ready to accept new connections. If the PCP Server 602 resets or loses the state of its port mapping table, due to reboot, 603 power failure, or any other reason, it MUST reset its epoch time and 604 begin counting SSSOE from 0 again. Whenever a client receives any 605 packet from the PCP Server, either gratuitously or in response to a 606 client request, the client computes its own conservative estimate of 607 the expected SSSOE value by taking the SSSOE value in the last packet 608 it received from the gateway and adding 7/8 (87.5%) of the time 609 elapsed since that packet was received. If the SSSOE in the newly 610 received packet is less than the client's conservative estimate by 611 more than one second, then the client concludes that the NAT gateway 612 has undergone a reboot or other loss of port mapping state, and the 613 client MUST immediately renew all its active port mapping leases as 614 described in Section 7.2. 616 7.2. Recreating Pinholes 618 The NAT gateway MAY store mappings in persistent storage so when it 619 is powered off or rebooted, it remembers the port mapping state of 620 the network. 622 However, maintaining this state is not essential for correct 623 operation. When the NAT gateway powers on or clears its port mapping 624 state as the result of a configuration change, it MUST reset the 625 epoch time. 627 A mapping renewal packet is formatted identically to an original 628 mapping request; from the point of view of the client it is a renewal 629 of an existing mapping, but from the point of view of the freshly- 630 rebooted NAT gateway it appears as a new mapping request. 632 This self-healing property of the protocol is very important. 634 The remarkable reliability of the Internet as a whole derives in 635 large part from the fact that important state is held in the 636 endpoints, not in the network itself [Saltzer84]]. Power-cycling an 637 Ethernet switch results only in a brief interruption in the flow of 638 packets; established TCP connections through that switch are not 639 broken, merely delayed for a few seconds. Indeed, an old Ethernet 640 switch can even be replaced with a new one, and as long as the cables 641 are transferred over reasonably quickly, after the upgrade all the 642 TCP connections that were previously going though the old switch will 643 be unbroken and now going through the new one. The same is true of 644 IP routers, wireless base stations, etc. The one exception is NAT 645 gateways. Because the port mapping state is required for the NAT 646 gateway to know where to forward inbound packets, loss of that state 647 breaks connectivity through the NAT gateway. By allowing clients to 648 detect when this loss of NAT gateway state has occurred, and recreate 649 it on demand, we turn hard state in the network into soft state, and 650 allow it to be recovered automatically when needed. 652 Without this automatic recreation of soft state in the NAT gateway, 653 reliable long-term networking would not be achieved. As mentioned 654 above, the reliability of the Internet does not come from trying to 655 build a perfect network in which errors never happen, but from 656 accepting that in any sufficiently large system there will always be 657 some component somewhere that's failing, and designing mechanisms 658 that can handle those failures and recover. To illustrate this point 659 with an example, consider the following scenario: Imagine a network 660 security camera that has a web interface and accepts incoming 661 connections from web browser clients. Imagine this network security 662 camera uses NAT-PMP or a similar protocol to set up an inbound port 663 mapping in the NAT gateway so that it can receive incoming 664 connections from clients the other side of the NAT gateway. Now, 665 this camera may well operate for weeks, months, or even years. 666 During that time it's possible that the NAT gateway could experience 667 a power failure or be rebooted. The user could upgrade the NAT 668 gateway's firmware, or even replace the entire NAT gateway device 669 with a newer model. The general point is that if the camera operates 670 for a long enough period of time, some kind of disruption to the NAT 671 gateway becomes inevitable. The question is not whether the NAT 672 gateway will lose its port mappings, but when, and how often. If the 673 network camera and devices like it on the network can detect when the 674 NAT gateway has lost its port mappings, and recreate them 675 automatically, then these disruptions are self-correcting and largely 676 invisible to the end user. If, on the other hand, the disruptions 677 are not self-correcting, and after a NAT gateway reboot the user has 678 to manually reset or reboot all the other devices on the network too, 679 then these disruptions are *very* visible to the end user. This 680 aspect of the design is what makes the difference between a protocol 681 that keeps on working indefinitely over a time scale of months or 682 years, and a protocol that works in brief testing, but in the real 683 world is continually failing and requiring manual intervention to get 684 it going again. 686 When a client renews its port mappings as the result of receiving a 687 packet where the "Seconds since start of epoch" field (SSSoE) 688 indicates that a reboot or similar loss of state has occurred, the 689 client MUST first delay by a random amount of time selected with 690 uniform random distribution in the range 0 to 5 seconds, and then 691 send its first port mapping request. After that request is 692 acknowledged by the gateway, the client may then send its second 693 request, and so on, as rapidly as the gateway allows. The requests 694 SHOULD be issued serially, one at a time; the client SHOULD NOT issue 695 multiple requests simultaneously in parallel. 697 [Ed. Note: the paragraph above is copied from NAT-PMP, and seems 698 to be advice specific to receiving asynchronous notification that 699 the Epoch was reset. Asynchronous notification needs the delay 700 described (in fact, it probably needs greater delay than 0-5 701 seconds if on a larger network) and also needs to discourage 702 sending multiple PCP requests serially. However, PCP does not 703 have asynchronous notification (yet), and has different needs/ 704 requirements for pacing. In short: the above paragraph needs some 705 discussion.] 707 The discussion in this section focusses on recreating inbound port 708 mappings after loss of NAT gateway state, because that is the more 709 serious problem. Losing port mappings for outgoing connections 710 destroys those currently active connections, but does not prevent 711 clients from establishing new outgoing connections. In contrast, 712 losing inbound port mappings not only destroys all existing inbound 713 connections, but also prevents the reception of any new inbound 714 connections until the port mapping is recreated. Accordingly, we 715 consider recovery of inbound port mappings the more important 716 priority. However, clients that want outgoing connections to survive 717 a NAT gateway reboot can also achieve that using NAT-PMP. After 718 initiating an outbound TCP connection (which will cause the NAT 719 gateway to establish an implicit port mapping) the client should send 720 the NAT gateway a port mapping request for the source port of its TCP 721 connection, which will cause the NAT gateway to send a response 722 giving the external port it allocated for that mapping. The client 723 can then store this information, and use later to recreate the 724 mapping if it determines that the NAT gateway has lost its mapping 725 state. 727 7.3. Maintaining Pinholes 729 A PCP client can refresh a pinhole by sending a new PCP request 730 containing information from the earlier PCP response. The PCP server 731 will respond indicating the new lifetime. It is possible, due to 732 failure of the PCP server, that the public IP address and/or public 733 port, or the PCP server itself, has changed (due to a new route to a 734 different PCP server). To detect such events more quickly, the PCP 735 client may find it beneficial to use shorter lifetimes (so that it 736 communicates with the PCP server more often). If the PCP client has 737 several pinholes, the Epoch value only needs to be retrieved for one 738 of them to verify the PCP server has not lost port forwarding state. 740 7.4. Nested NATs 742 A PCP Client can detect the presence of a NAT on the path between the 743 PCP client and PCP server by sending a PCP request to the PCP server 744 and comparing fields in the PCP response. If the request's IP 745 address family, IP address, and source port match the information in 746 the PCP response's payload (PCP Request Address Family, PCP Request 747 Port, and PCP Request XOR'd IP Address), there is no NAT on the path. 748 If they differ, there is a NAT on the path. 750 Note: this provides a function similar to STUN [RFC5389]. Being 751 integrated within PCP itself provides the advantage of checking 752 the path to the PCP server, which may be a different path than to 753 the STUN server. 755 After determining a NAT is on the path, the PCP application can take 756 appropriate action based on this information. This action would 757 require using another mechanism to open pinholes in the intervening 758 NATs (e.g., UPnP IGD, NAT-PMP) or returning an error to the user. 760 8. Processing Pinhole Requests and Responses 762 PCP messages MUST be sent over UDP, and the PCP Server MUST listen 763 for PCP requests on the PCP port number (Section 16.2). Every PCP 764 request generates a response, so PCP does not need to run over a 765 reliable transport protocol. 767 8.1. Generating and Sending a Request 769 To create a pinhole, the PCP client generates a PCP request for the 770 appropriate address family of the internal host and the desired 771 public mapping. The PCP request contains a PCP common header, PCP 772 OpCode and payload, and optional Information Elements. 774 The PCP client determines its PCP server using the procedure 775 described in Section 4. It initializes its retransmission timer, 776 RETRY_TIMER, to the round trip time between the PCP client and PCP 777 server. If this value is unknown, 250ms is RECOMMENDED. The PCP 778 Client sends its PCP message to the PCP server and waits RETRY_TIMER 779 for a response. If no response is received, it doubles the value of 780 RETRY_TIMER, sends another (identical) PCP message and waits 781 RETRY_TIMER*2. This procedure is repeated three times, doubling the 782 value of RETRY_TIMER each time. If no response is received after 4 783 attempts, the PCP client tries with the next IP address in its list 784 of PCP servers. If it has exhausted its list, it SHOULD abort the 785 procedure. If, when sending PCP requests the PCP Client receives an 786 ICMP error (e.g., port unreachable, network unreachable) it SHOULD 787 immediately abort the procedure. Once a PCP client has successfully 788 communicated with a PCP server, it continues communicating with that 789 PCP server until that PCP server becomes non-responsive, which causes 790 the PCP client to attempt to re-iterate the procedure starting with 791 the first PCP server on its list. 793 8.2. Processing a Request and Generating the Response 795 Upon receiving a PCP request message, the PCP Server parses and 796 validates it. A valid request contains a valid PCP common header, 797 one valid PCP Opcode, and optional Informational Elements (which the 798 server might or might not comprehend). If an error is encountered 799 during processing, an error response is generated and sent back to 800 the PCP client. 802 After successful parsing of the message, the PCP server validates 803 that the internal IP address in the PCP request belongs to that 804 subscriber. This validation depends on the deployment scenario; see 805 Section 10.4. If the internal IP address in the PCP request does not 806 belong to the subscriber, an error response MUST be generated with 807 error-code=2. 809 If the requested lifetime is 0, it indicates a Delete request. This 810 means the pinhole described by the internal IP address should be 811 deleted, and requested external port field is ignored by the server 812 (that is, it isn't validated). If the deletion request was 813 successful, apositive response generated containing external port of 814 0 and lifetime of 0. If the deletion request was unsusccessful a 815 non-zero result code is returned and the lifetime is undefined. If 816 the client attempts to delete a port mapping which was manually 817 assigned by some kind of configuration tool, the PCP server MUST 818 respond with a 'Not Authorized' error (result code 2). 820 [Ed. Note: Should we similarly return an error if attempting to 821 delete mappings that were created dynamically (e.g., TCP SYN)?] 823 When a mapping is destroyed as a result of its lifetime expiring or 824 for any other reason, if the NAT gateway's internal state indicates 825 that there are still active TCP connections traversing that now- 826 defunct mapping, then the NAT gateway SHOULD send appropriately- 827 constructed TCP RST (reset) packets both to the local client and to 828 the remote peer on the Internet to terminate that TCP connection. 830 A client can request the explicit deletion of all its UDP or TCP 831 mappings by sending the same deletion request to the NAT gateway with 832 external port, internal port, and lifetime set to 0. A client MAY 833 choose to do this when it first acquires a new IP address in order to 834 protect itself from port mappings that were performed by a previous 835 owner of the IP address. After receiving such a deletion request, 836 the PCP server and NAT MUST delete all the port mappings. The PCP 837 server responds to such a deletion request with a response as 838 described above, with the internal port set to zero. If the PCP 839 server is unable to delete a port mapping, for example, because the 840 mapping was manually configured by a configuration tooll, the gateway 841 MUST still delete as many port mappings as possible, but respond with 842 a non-zero result code. The exact result code to return depends on 843 the cause of the failure. If the gateway is able to successfully 844 delete all port mappings as requested, it MUST respond with a result 845 code of 0. 847 The PCP-controlled device MAY reduce the lifetime that was requested 848 by the PCP Client. The PCP-controlled device SHOULD NOT offer a 849 lease lifetime greater than that requested by the PCP Client. The 850 RECOMMENDED lifetime assigned by the server is 7200 seconds (i.e., 851 two hours). 853 By default, a PCP-controlled device MUST NOT create mappings for a 854 protocol not indicated in the request. For example, if the request 855 was for a TCP mapping, a UDP mapping MUST NOT be created. 856 Nevertheless, a configurable feature MAY be supported by the PCP- 857 controlled device, which MAY reserve (but not forward) the companion 858 port so the same PCP Client can request it in the future. 860 If all of the proceeding operations were successful (did not generate 861 an error response), then the requested pinholes are created as 862 described in the request and a positive response is built. This 863 positive response contains the same OpCode as the request plus 128. 865 8.3. Processing a Response 867 The PCP client receives the response and checks that the response 868 matches one of its outstanding requests. If it is an error response, 869 the PCP client knows that none of the requested pinholes were 870 created, and can attempt to resolve the problem based on the error 871 code and error subcode. 873 If it is an positive response, the PCP client knows the request was 874 entirely successful and can use the external IP address and port(s) 875 as desired. Typically the PCP client will communicate the external 876 IP address and port(s) to another host on the Internet using an 877 application-specific mechanism. 879 9. PCP Client Operation 881 This section details operation specific to a PCP client. 883 9.1. Pinhole Lifetime Extension 885 An existing mapping can have its lifetime extended by the PCP client. 886 To do this, the PCP client sends a new PCP map request to the server 887 indicating the internal IP address and port(s). 889 The PCP Client SHOULD renew the mapping before its expiry time, 890 otherwise it will be removed by the PCP Server (see Section 10.3). 891 In order to prevent excessive PCP chatter, it is RECOMMENDED to renew 892 only 60 seconds before expiration time (to account for 893 retransmissions that might be necessary due to packet loss, clock 894 synchronization between PCP client and PCP server, and so on). 896 9.2. Pinhole Deletion 898 A PCP Client MAY delete a pinhole prior to its natural expiration by 899 sending a PCP Map Request with a lifetime of 0. The PCP server 900 responds by returning a PCP Map Response with a lifetime of 0. 902 To delete all pinholes for all ports, the "W" (wildcard) bit is set, 903 and no internal port/external port is included in the PCP request. 905 To delete all pinholes for all hosts associated with this subscriber, 906 an all-zero internal IP address is used. 908 9.3. Multi-interface Issues 910 Hosts which desire a PCP mapping might be multi-interfaced (i.e., own 911 several logical/physical interfaces). Indeed, a host can be dual- 912 stack or be configured with several IP addresses. These IP addresses 913 may have distinct reachability scopes (e.g., if IPv6 they might have 914 global reachability scope as for GUA (Global Unicast Address) or 915 limited scope such as ULA (Unique Local Address, [RFC4193])). 917 IPv6 addresses with global reachability scope SHOULD be used as 918 internal IP address when instructing a PCP mapping in a PCP- 919 controlled device. IPv6 addresses with limited scope (e.g., ULA), 920 SHOULD NOT be indicated as internal IP address in a PCP message. 922 As mentioned in Section 2.3, only mono-homed CP routers are in scope. 923 Therefore, there is no viable scenario where a host located behind a 924 CP router is assigned with two GUA addresses belonging to the same 925 global IPv6 prefix. 927 9.4. Renumbering 929 The customer premise router might obtain a new IPv6 prefix, either 930 due to a reboot, power outage, DHCPv6 lease expiry, or other action. 931 If this occurs, the ports reserved using PCP might be delivered to 932 another customer who now has that (old) address. This same problem 933 can occur if an IP address is re-assigned today, without PCP. The 934 solution is the same as today: ISPs should not re-assign IP 935 addresses. 937 10. PCP Server Operation 939 This section details operation specific to a PCP server. 941 10.1. Relationship of PCP Server and its NAT 943 The PCP server receives PCP requests. The PCP server might be 944 integrated within the NAT device (as shown in Figure 8) which is 945 expected to be a common deployment. 947 +-----------------+ 948 +------------+ | NAT or firewall | 949 | PCP Client |--+ +--- 950 +------------+ | with embedded | 951 | PCP server | 952 +-----------------+ 954 Figure 8: device with Embedded PCP Server 956 However, it is useful to also model a separation of the PCP server 957 from the NAT, as shown below (Figure 9). The PCP server would 958 communicate with the NAT using a protocol beyond the scope of this 959 document, such as a proprietary protocol or any suitable standard 960 protocol for NAT control). 961 +-----------------+ 962 +--+ NAT or firewall +--- 963 / +-----------------+ 964 +------------+ / ^ 965 | PCP Client +- | suitable NAT control protocol 966 +------------+ \ v 967 \ +------------+ 968 +--+ PCP Server | 969 +------------+ 971 Figure 9: NAT with Separate PCP Server 973 10.2. Pinhole Lifetime 975 Once a PCP server has responded positively to a pinhole request for a 976 certain lifetime, the port forwarding is active for the duration of 977 the lifetime unless deleted by the PCP client. Also see XXX. 979 It is NOT RECOMMENDED that the server allow long lifetimes (exceeding 980 24 hours), because they will consume ports even if the internal host 981 is no longer interested in receiving the traffic or no longer 982 connected to the network. 984 The PCP server SHOULD be configurable for permitted minimum and 985 maximum lifetime, and the RECOMMENDED values are 120 seconds for the 986 minimum value and 24 hours for the maximum. 988 10.3. Pinhole deletion 990 A pinhole MUST be deleted by the PCP Server upon the expiry of its 991 lifetime, or upon request from the PCP client. 993 In order to prevent another subscriber from receiving unwanted 994 traffic, the PCP server SHOULD NOT assign that same external port to 995 another host for 120 seconds (MSL, [RFC0793]). 997 [Ed. Note: it should (MUST?) allow the same host to re-acquire 998 the same port, though.] 1000 10.4. Subscriber Identification 1002 Subscribers identification is required for several reasons such as 1003 the following: 1005 o Allow access to the network resources; 1007 o Configure service profiles such as a bandwidth and/or port usage 1008 quotas for fairness service usage among all subscribers; 1010 o Blacklist a subscriber because of abuse or non-payment of service 1011 fee, etc. 1013 o Legal requirements such as legal intercept or legal storage. 1015 A PCP Client can create mappings in a PCP-controlled device on behalf 1016 of a third party device (e.g., a computer can create PCP mappings on 1017 behalf of a webcam). However, it is not desirable for a PCP client 1018 to open pinholes for a different subscriber. The mechanism to 1019 identify "same subscriber" depends on the sort of NAT on this 1020 network: 1022 o If the PCP-controlled device is a NAT64: the internal IP address 1023 indicated in the PCP message and the source IPv6 address of 1024 received PCP request MUST belong to the same IPv6 prefix. The 1025 length of the IPv6 prefix is the same as the length assigned to 1026 each subscriber on that particular network. 1028 o If the PCP-controlled device is a DS-Lite AFTR: DS-Lite (Section 1029 11 of [I-D.ietf-softwire-dual-stack-lite]) already requires the 1030 tunnel transport source address be validated, and that same 1031 address is used by PCP to assign the tunnel-ID to the requested 1032 mapping (see Section 11.1.2 and Section 11.1.3). Thus, PCP 1033 acquires the same security properties as DS-Lite. If address 1034 validation is implemented correctly, the PCP Client can not 1035 instruct mappings on behalf of devices of another subscriber. 1037 o If CGN with a routed network, each subscriber has one IPv4 address 1038 and all PCP requests MUST be sent from only that IP address and 1039 MUST only open pinholes towards its own IP address. 1041 PCP-controlled devices can be a DS-Lite AFTR or an IPv4-IPv6 1042 interconnection node such as NAT46 or NAT64. These nodes are 1043 deployed by Service Providers to deliver global connectivity service 1044 to their customers. Appropriate functions to restrict the use of 1045 these resources (e.g., LSN facility) to only subscribed users should 1046 be supported by these devices. Access control can be implicit or 1047 explicit: 1049 o It is said to be explicit if an authorisation procedure is 1050 required for a user to be granted access to such resources. For 1051 such variant of PCP-controlled device, a subscriber can be 1052 identified by an IPv6 address, an IPv4 address, a MAC address, or 1053 any other information. 1055 o For other scenarios, such as plain IPv4-in-IPv6 encapsulation for 1056 a DS-Lite architecture, the access to the service is based on the 1057 source IPv6 prefix. No per-user polices is pre-configured in the 1058 PCP-controlled device. 1060 10.5. External IP Address 1062 If there are active mappings for a particular PCP Client -- created 1063 via dynamic assignment or created by PCP -- subsequent mapping 1064 requests from that same PCP Client MUST use the same external IP 1065 address. This is necessary because some protocols require using the 1066 same IP address for several ports, and follows REQ-1 of 1067 [I-D.ietf-behave-lsn-requirements]. Additionally, all PCP-mapped 1068 requests MUST also use the same external IP address. Once a client 1069 has no active dynamic mappings and no PCP pinholes, a subsequent 1070 dynamic mapping or PCP request MAY be assigned to a different 1071 external IP address. 1073 11. Deployment Scenarios 1075 11.1. Dual Stack-Lite 1077 The interesting components in a Dual-Stack Lite deployment are the B4 1078 element (which is the customer premise router) and the AFTR element 1079 (which is the device that both terminates the IPv6-over-IPv4 tunnel 1080 and also implements the large-scale NAT44 function). The B4 element 1081 does not need to perform a NAT function (and usually does not perform 1082 a NAT function), but it does operate its own DHCP server. 1084 11.1.1. Overview 1086 Various PCP deployment scenarios can be considered to control the PCP 1087 server embedded in the AFTR element: 1089 1. UPnP IGD and NAT-PMP are used in the LAN: an interworking 1090 function is required to be embedded in the B4 element to ensure 1091 interworking between the protocol used in the LAN and PCP. UPnP 1092 IGD-PCP Interworking Function is described in Section 13. 1094 2. Hosts behind the B4 element include a PCP Client, and communicate 1095 directly with the PCP server. No interworking function is 1096 required to be embedded in the B4 element. 1098 3. The B4 element include a PCP Client which is invoked by an HTTP- 1099 based configuration (as is common today). The internal-IP- 1100 address in the PCP payload would be the internal host used in the 1101 port forwarding configuration. 1103 Two modes are identified to forward PCP packets to a PCP Server 1104 controlling the provisioned AFTR as described in the following sub- 1105 sections. 1107 [Ed. Note: We need to decide on Encapsulation Mode or Plain IPv6 1108 Mode.] 1110 11.1.2. Encapsulation Mode 1112 In this mode, B4 element does no processing at all of the PCP 1113 messages, and forwards them as any other UDP traffic. With DS-Lite, 1114 this means that IPv4 PCP messages issued by internal PCP Clients are 1115 encapsulated into the IPv6 tunnel sent to the AFTR as for any other 1116 IPv4 packets. The AFTR decapsulates the IPv4 packets and processes 1117 the PCP requests (because the destination IPv4 address points to the 1118 PCP Server embedded in the AFTR). 1120 11.1.3. Plain IPv6 Mode 1122 Another alternative for deployment of PCP in a DS-Lite context is to 1123 rely on a PCP Proxy in the B4 element. Protocol exchanges between 1124 the PCP Proxy and the PCP Server are conveyed using plain IPv6 (no 1125 tunnelling is used). Nevertheless, the IPv6 address used as source 1126 address by the PCP Proxy MUST be the same as the one used by the B4 1127 element. 1129 11.2. NAT64 1131 Hosts behind a NAT64 device can make use of PCP in order to perform 1132 port reservation (to get a publicly routable IPv4 port). 1134 If the IANA-assigned IP address is used for the discovery of the PCP 1135 Server, that IPv4 address can be placed into the IPv6 destination 1136 address following that particular network's well-known prefix or 1137 network-specific prefix, per [I-D.ietf-behave-address-format]. 1139 11.3. NAT44 and NAT444 1141 Subscribers are given only one IPv4 address. To accomodate multiple 1142 hosts within the home, subscribers operate a NAPT device. When this 1143 occurs in conjunction with an upstream NAT44, this is nicknamed 1144 "NAT444". 1146 In either environment (with or without a NAPT in the home), the 1147 service provider and PCP server see only one IPv4 address from each 1148 subscriber. 1150 PCP includes a function to detect a NAT between the PCP client and 1151 PCP server, described in Section 7.4. 1153 11.4. IPv6 Firewall 1155 [Ed. Note: PCP packet format needs changes to support IPv6 firewall, 1156 or we need additional OpCodes for IPv6 firewall.] 1158 12. Adjacent Port Procedure 1160 RTP and RTCP have historically run on adjacent ports, and some 1161 existing equipment still expects them to be on adjacent ports. To 1162 accomodate that, a procedure can be used rather than adding 1163 complexity to the protocol or to the server implementation. 1165 [Ed. Note: Are there any other referencable protocols that need 1166 adjacent ports?] 1168 The procedure is for the PCP client to bind to two ports on its local 1169 interface. It then sends a PCP request for external port 0 1170 (indicating it will accept any port from the server) for one of those 1171 internal ports. This request can have a short lifetime (e.g., 5 1172 seconds) to avoid the need to delete the pinhole. It receives the 1173 PCP response indicating it now has external port N. The PCP client 1174 then attempts to obtain a port on either side of this external port. 1175 It sends two PCP requests, using the same internal port number in 1176 both requests, for external port N-1 and for external port N+1. The 1177 adjacent external ports N-1 and N+1 are either (a) not available, (b) 1178 only one is available, or (c) both are available. If (a), an 1179 unrelated port will be assigned and the procedure can be repeated. 1180 If (b) the procedure was successful. Case (c) is also successful, 1181 because the PCP client cannot distinguish it from case (b), because 1182 the PCP server maps an specific internal IP address and internal port 1183 to a single external IP address and port. 1185 [Ed. Note: Add message flow diagram showing adjacent port 1186 procedure] 1188 13. Interworking with UPnP IGD 1190 The following diagram shows how UPnP IGD can be interworked with PCP, 1191 using an interworking function (IWF). 1193 +-------------+ 1194 | IGD Control | 1195 | Point |-----+ 1196 +-------------+ | +---------+ +--------+ 1197 +---| IGD-PCP | | PCP | 1198 | IWF +-------+ Server |-- 1199 +---| | | | 1200 +-------------+ | +---------+ +--------+ 1201 | Local Host |-----+ 1202 +-------------+ | | 1203 | | 1204 LAN Side | WAN side | 1205 <======UPnP IGD=============>|<========PCP=====>| 1207 Figure 10: Network Diagram, Interworking UPnP IGD and PCP 1209 13.1. UPnP IGD 1.0 with AddPortMapping Action 1211 In UPnP IGD 1.0 [IGD] it is only possible to request a specific port 1212 using the AddPortMapping action. Requesting a specific port is 1213 incompatible with both (1) a large-scale NAT and with (2) successful 1214 applications. Regarding (1), other subscribers are likely to also be 1215 running the same application, all demanding (or desiring) the same 1216 port number. Regarding (2), a popular application will exist on 1217 multiple devices within the home. Thus, PCP is not designed to 1218 optimize for this behavior of requesting a particular port as it 1219 cannot work well in address sharing environments; but PCP will work 1220 with this behavior using the suggested procedure below. 1222 Due to this incompatibility with large-scale address sharing and 1223 popular applications, future hosts and applications will either 1224 support UPnP IGD 2.0 (which has improved behavior, see Section 13.2) 1225 or will support PCP. 1227 To interwork from UPnP IGD to PCP, our recommendation is that every 1228 UPnP request be forwarded to the PCP server -- this works no matter 1229 if the UPnP IGD control point is randomizing or incrementing each 1230 port number when its requests fail. When a requested port assignment 1231 fails, most UPnP IGD control points will retry the port assignment 1232 requesting the next higher port or requesting a random port. In 1233 either case, the described procedure will work. The UPnP IGD/PCP 1234 interworking function would request very short leases (e.g., 5 1235 seconds) in order to avoid the chatter of a Delete message 1236 (lifetime=0). Once a port can be allocated, its lifetime is 1237 extended. When interworking with UPnP IGD, the in-home CPE limits 1238 itself to sending one PCP message a second, which ensures there are 1239 only 5 outstanding PCP reservations at a time; this avoids consuming 1240 all of that subscriber's NAT mappings while trying to find an 1241 available port via the UPnP IGD->PCP interworking function). 1243 Note: for this to work successfully, the PCP server (large NAT) 1244 needs to honor the requested-external-port field in the PCP 1245 request. Which is the purpose of that field, of course. 1247 Message flow would be similar to this: 1249 UPnP CP in-home CPE PCP server 1250 | | | 1251 |-UPnP:give me port 80--->| | 1252 | |-PCP:request port 80------>| 1253 | | with lifetime=5 seconds | 1254 | |<-PCP:here is port 51389---| 1255 |<-UPnP: unavailable------| | 1256 | | | 1257 | (allow port 51389 to naturally expire, | 1258 | or actively Delete it) | 1259 | | | 1260 |-UPnP:give me port 3213->| | 1261 | |-PCP:request port 3213---->| 1262 | | with lifetime=5 seconds | 1263 | |<-PCP:here is port 23831---| 1264 |<-UPnP: unavailable------| | 1265 | | | 1266 | (allow port 23831 to naturally expire, | 1267 | or actively Delete it) | 1268 | | | 1269 ... ... ... ... 1270 | | | 1271 |-UPnP:give me port 8921->| | 1272 | |-PCP:request port 8921---->| 1273 | | with lifetime=5 seconds | 1274 | |<-PCP:here is port 8921----| 1275 | | | 1276 | |-PCP:life=1 hour,port=8921>| 1277 | |<-PCP:ok-------------------| 1278 | | | 1279 |<-UPnP: ok, port 8921----| | 1280 | | | 1282 Figure 11: Message Flow: Interworking from UPnP IGD 1.0 1283 AddPortMapping action to PCP 1285 13.2. UPnP IGD 2.0 with AddAnyPortMapping Action 1287 If the UPnP IGD control point and the UPnP IGD interworking function 1288 both implement UPnP IGD 2.0 [IGD-2] and the UPnP IGD control point 1289 uses the IGD 2's new AddAnyPortMapping message, only one round-trip 1290 is necessary. This is because AddAnyPortMapping has semantics 1291 similar to PCP's semantics, allowing the PCP server to assign any 1292 port. 1294 13.3. Lifetime Maintenance 1296 UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP 1297 interworking function is responsible for extending the lifetime of 1298 mappings that are still interesting to the UPnP IGD device. 1300 Note: It can be an implementation advantage, where possible, for 1301 the UPnP IGD/PCP interworking function to request a port mapping 1302 lifetime only while that client is active and connected. For 1303 example, creating a PCP mapping that is equal to the client's 1304 remaining DHCP lifetime is one useful approach. The UPnP IGD/PCP 1305 interworking function is responsible for renewing the PCP lifetime 1306 as necessary. As long as client renews its DHCP lease, the PCP 1307 lifetime should also be extended. For clients not using DHCP, 1308 other mechanisms to check on the client host's liveliness can also 1309 be useful (e.g., ping, ARP, or WiFi association) can be used to 1310 discern liveliness of the UPnP IGD control point. However, it is 1311 NOT RECOMMENDED to attempt to connect to the TCP or UDP port 1312 opened on the control point to determine if the host still wants 1313 to receive packets; the server could be temporarily down when 1314 tested, causing a false negative. 1316 14. NAT-PMP Backwards Compatibility 1318 Because NAT-PMP and PCP share the same port, it is important that a 1319 NAT-PMP client receive a NAT-PMP error message. This is done by 1320 examining the version number of the incoming PCP message; if it is 1321 zero, the message is from a NAT-PMP client. A valid NAT-PMP response 1322 (rather than a PCP response) is necessary, shown below. 1324 A server which supports both NAT-PMP and PCP would be able to process 1325 both NAT-PMP and PCP requests normally, and (if necessary) proxy 1326 between the protocols. 1328 0 1 2 3 1329 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 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | 0 | OP = 128 + x | Response Code=1 (unsupp. ver.)| 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | | 1334 | 0 (96 bits) | 1335 | | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 Figure 12: NAT-PMP response 1340 [Ed. Note: More analysis is necessary on NAT-PMP backward 1341 compatibility, including checking if NAT-PMP clients are compliant 1342 with [I-D.cheshire-nat-pmp]] regarding error handling. 1344 15. Security Considerations 1346 [Ed. Note: to be completed.] 1348 16. IANA Considerations 1350 IANA is requested to perform the following actions: 1352 16.1. PCP Server IP address 1354 IANA shall assign an IPv4 and an IPv6 address for PCP discovery. 1356 [Ed. Note: perhaps we can use the AFTR element's IPv4 address? But 1357 still need an IPv6 address assigned for PIN64 and PIN66.] 1359 16.2. Port Number 1361 Re-use NAT-PMP port number, UDP/5351. 1363 16.3. OpCodes 1365 IANA shall create a new protocol registry for PCP OpCodes, initially 1366 populared with the values in Figure 5. 1368 New OpCodes can be created via Standards Action [RFC2434]. 1370 16.4. Result Codes 1372 IANA shall create a new registry for PCP result codes, numbered 1373 0-255, initially populated with the error codes from Figure 4. 1375 New Result Codes can be created via Specification Required [RFC2434]. 1377 16.5. Information Elements 1379 IANA shall create a new registry for PCP Information Elements, 1380 numbered 0-255 with associated mnemonic. 1382 New information elements in the range 0-127 can be created via 1383 Standards Action [RFC2434], new information elements in the range 1384 128-192 can be created with Expert Review [RFC2434], and the range 1385 193-255 is for Private Use [RFC2434]. 1387 17. Acknowledgments 1389 Thanks to Alain Durand and Christian Jacquenet for their comments and 1390 review. 1392 Thanks to Mohamed Boucadair, Francis Dupont, and Reinaldo Penno for 1393 significant contributions. Thanks to Stuart Cheshire for writing 1394 NAT-PMP [I-D.cheshire-nat-pmp] and for his contributions to this 1395 document. 1397 18. References 1399 18.1. Normative References 1401 [I-D.ietf-behave-v6v4-xlate] 1402 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1403 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 1404 progress), September 2010. 1406 [I-D.ietf-behave-v6v4-xlate-stateful] 1407 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1408 NAT64: Network Address and Protocol Translation from IPv6 1409 Clients to IPv4 Servers", 1410 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1411 progress), July 2010. 1413 [I-D.ietf-softwire-dual-stack-lite] 1414 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1415 Stack Lite Broadband Deployments Following IPv4 1416 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 1417 in progress), August 2010. 1419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1420 Requirement Levels", BCP 14, RFC 2119, March 1997. 1422 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1423 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1424 October 1998. 1426 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1427 Addresses", RFC 4193, October 2005. 1429 [proto_numbers] 1430 IANA, "Protocol Numbers", 2010, . 1433 18.2. Informative References 1435 [I-D.arkko-dual-stack-extra-lite] 1436 Arkko, J. and L. Eggert, "Scalable Operation of Address 1437 Translators with Per-Interface Bindings", 1438 draft-arkko-dual-stack-extra-lite-03 (work in progress), 1439 October 2010. 1441 [I-D.cheshire-nat-pmp] 1442 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1443 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1445 [I-D.ietf-behave-address-format] 1446 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1447 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1448 draft-ietf-behave-address-format-10 (work in progress), 1449 August 2010. 1451 [I-D.ietf-behave-lsn-requirements] 1452 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 1453 "Common requirements for IP address sharing schemes", 1454 draft-ietf-behave-lsn-requirements-00 (work in progress), 1455 October 2010. 1457 [I-D.ietf-v6ops-cpe-simple-security] 1458 Woodyatt, J., "Recommended Simple Security Capabilities in 1459 Customer Premises Equipment for Providing Residential IPv6 1460 Internet Service", draft-ietf-v6ops-cpe-simple-security-16 1461 (work in progress), October 2010. 1463 [I-D.miles-behave-l2nat] 1464 Miles, D. and M. Townsley, "Layer2-Aware NAT", 1465 draft-miles-behave-l2nat-00 (work in progress), 1466 March 2009. 1468 [IGD] UPnP Gateway Committee, "WANIPConnection:1", 1469 November 2001, . 1472 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V 1473 2.0", September 2010, . 1475 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1476 RFC 793, September 1981. 1478 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1479 "Service Location Protocol, Version 2", RFC 2608, 1480 June 1999. 1482 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1483 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1484 October 2008. 1486 [Saltzer84] 1487 Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments 1488 in system design", 1984, . 1491 Appendix A. Analysis of Techniques to Discover PCP Server 1493 [[Ed. Note: This Appendix will be removed in a later version of 1494 this document. It is included here for reference and discussion 1495 purposes.]] 1497 Several mechanisms for discovering the PCP Server can be envisaged as 1498 listed below: 1500 1. A special-purpose IPv4 or IPv6 address, assigned by IANA, which 1501 is routed normally until it hits a PCP Server, which responds. 1503 Analysis: This solution can be deployed in the context of DS- 1504 Lite architecture. Concretely, a well-known IPv4 address can 1505 be used to reach a PCP Server embedded in the device that 1506 embeds the AFTR capabilities. Since all IPv4 messages issued 1507 by a DS-Lite CP router will be encapsulated in IPv6, no state 1508 synchronisation issues will be experienced because PCP 1509 messages will be handled by the appropriate PCP Server. 1511 In some deployment scenarios (e.g., deployment of several 1512 stateful NAT64/NAT46 in the same domain), the use of this 1513 address is not recommended since PCP messages, issued by a 1514 given host, may be handled by a PCP Server embedded in a NAT 1515 node which is not involved to handle IP packets issued from 1516 that host. The use of this special-purpose IP address may 1517 induce session failures and therefore the customer may 1518 experience troubles when accessing its services. 1520 Consequently, the use of a special-purpose IPv4 address is 1521 suitable for DS-Lite NAT44. As for NAT46/NAT64, this is left 1522 to the Service Providers according to their deployment 1523 configuration. 1525 The special-use address MUST NOT be advertised in the global 1526 routing table. Packets with that destination address SHOULD 1527 be filtered so they are not transmitted on the Internet. 1529 2. Assume the default router is a PCP Server, and send PCP packets 1530 to the IP address of the default router. 1532 Analysis: This solution is not suitable for DS-Lite NAT44 nor 1533 for all variants of NAT64/NAT46. 1535 In the context of DS-Lite: There is no default IPv4 router 1536 configured in the CP router. All outgoing IPv4 traffic is 1537 encapsulated in IPv6 and then forwarded to a pre-configured 1538 DS-Lite AFTR device. Furthermore, if IPv6 is used to reach 1539 the PCP Server, the first router may not be the one which 1540 embeds the AFTR. 1542 For NAT64/NAT46 scenarios: The NAT function is not embedded 1543 in the first router, therefore this solution candidate does 1544 not allow to discover a valid PCP Server. 1546 Therefore, this alternative is not recommended. 1548 3. Service Location Protocol (SLP [RFC2608]). 1550 Analysis: This solution is not suitable in scenarios where 1551 multicast is not enabled. SLP is a chatty protocol. This 1552 alternative is not recommended. 1554 4. NAPTR. The host would issue a DNS query for a NAPTR record, 1555 formed from some bits of the host's IPv4 or IPv6 address. For 1556 example, a host with the IPv6 address 2001:db8:1:2:3:4:567:89ab 1557 would first send an NAPTR query for 1558 3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements, 1559 representing a /64 network prefix), which returns the PCP 1560 Server's IPv6 address. A similar scheme can be used with IPv4 1561 using, for example, the first 24 bits of the IPv4 address. 1563 Analysis: This solution candidate requires more configuration 1564 effort by the Service Provider so as to redirect a given 1565 client to the appropriate PCP Server. Any change of the 1566 engineering policies (e.g., introduce new LSN device, load- 1567 based dimensioning, load-balancing, etc.) would require to 1568 update the zone configuration. This would be a hurdle for the 1569 flexibility of the operational networks. Adherence to DNS is 1570 not encouraged and means which allows for more flexibility are 1571 to be promoted. 1573 Therefore, this mechanism is not recommended. 1575 5. New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a 1576 PCP Server. 1578 Analysis: Since DS-Lite and NAT64/NAT46 are likely to be 1579 deployed in provider-provisioned environments, DHCP (both 1580 DHCPv6 and IPv4 DHCP) is convenient to provision the address/ 1581 FQDN of the PCP Server. 1583 Author's Address 1585 Dan Wing 1586 Cisco Systems, Inc. 1587 170 West Tasman Drive 1588 San Jose, California 95134 1589 USA 1591 Email: dwing@cisco.com