idnits 2.17.1 draft-ietf-pcp-port-set-13.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2015) is 3109 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Sun 3 Internet-Draft China Telecom 4 Intended status: Standards Track M. Boucadair 5 Expires: April 24, 2016 France Telecom 6 S. Sivakumar 7 Cisco Systems 8 C. Zhou 9 Huawei Technologies 10 T. Tsou 11 Huawei Technologies (USA) 12 S. Perreault 13 Jive Communications 14 October 22, 2015 16 Port Control Protocol (PCP) Extension for Port Set Allocation 17 draft-ietf-pcp-port-set-13 19 Abstract 21 In some use cases, e.g., Lightweight 4over6, the client may require 22 not just one port, but a port set. This document defines an 23 extension to the Port Control Protocol (PCP) allowing clients to 24 manipulate sets of ports as a whole. This is accomplished by a new 25 MAP option: PORT_SET. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 24, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Applications Using Port Sets . . . . . . . . . . . . . . 3 63 1.2. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 3 64 1.3. Firewall Control . . . . . . . . . . . . . . . . . . . . 3 65 1.4. Discovering Stateless Port Set Mappings . . . . . . . . . 4 66 2. The need for PORT_SET . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. The PORT_SET Option . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 7 70 4.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Absence of Capability Discovery . . . . . . . . . . . . . 8 72 4.4. Port Set Renewal and Deletion . . . . . . . . . . . . . . 9 73 4.4.1. Overlap Conditions . . . . . . . . . . . . . . . . . 9 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Simple Request on NAT44 . . . . . . . . . . . . . . . . . 9 76 5.2. Stateless Mapping Discovery . . . . . . . . . . . . . . . 10 77 5.3. Resolving Overlap . . . . . . . . . . . . . . . . . . . . 11 78 6. Operational Considerations . . . . . . . . . . . . . . . . . 12 79 6.1. Limits and Quotas . . . . . . . . . . . . . . . . . . . . 12 80 6.2. High Availability . . . . . . . . . . . . . . . . . . . . 12 81 6.3. Idempotence . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.4. What Should a PCP Client Do When It Receives Fewer Ports 83 than Requested? . . . . . . . . . . . . . . . . . . . . . 13 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 11.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 This document extends Port Control Protocol (PCP) [RFC6887] with the 96 ability to retrieve a set of ports using a single request. It does 97 so by defining a new PORT_SET option. 99 This section describes a few (and non-exhaustive) envisioned use 100 cases. Note that the PCP extension defined in this document is 101 generic and is expected to be applicable to other use cases. 103 1.1. Applications Using Port Sets 105 Some applications require not just one port, but a port set. One 106 example is a Session Initiation Protocol (SIP) User Agent Server 107 (UAS) [RFC3261] expecting to handle multiple concurrent calls, 108 including media termination. When it receives a call, it needs to 109 signal media port numbers to its peer. Generating individual PCP MAP 110 requests for each of the media ports during call setup would 111 introduce unwanted latency and increased signaling load. Instead, 112 the server can pre-allocate a set of ports such that no PCP exchange 113 is needed during call setup. 115 1.2. Lightweight 4over6 117 In the Lightweight 4over6 (lw4o6) [RFC7596] architecture, shared 118 global addresses can be allocated to customers. It allows moving the 119 Network Address Translation (NAT) function, otherwise accomplished by 120 a Carrier-Grade NAT (CGN) [RFC6888], to the Customer-Premises 121 Equipment (CPE). This provides more control over the NAT function to 122 the user, and more scalability to the Internet Service Provider 123 (ISP). 125 In the lw4o6 architecture, the PCP-controlled device corresponds to 126 the Lightweight AFTR (lwAFTR), and the PCP client corresponds to the 127 Lightweight B4 (lwB4). The PCP client sends a PCP MAP request 128 containing a PORT_SET option to trigger shared address allocation on 129 the Lightweight AFTR (lwAFTR). The PCP response contains the shared 130 address information, including the port set allocated to the 131 Lightweight B4 (lwB4). 133 1.3. Firewall Control 135 Port sets are often used in firewall rules. For example, defining a 136 range for Real-time Transport Protocol (RTP) [RFC3550] traffic is 137 common practice. The PCP MAP request can already be used for 138 firewall control. The PORT_SET option brings the additional ability 139 to manipulate firewall rules operating on port sets instead of single 140 ports. 142 1.4. Discovering Stateless Port Set Mappings 144 A PCP MAP request can be used to retrieve a mapping from a stateless 145 device (i.e., one that does not establish any per-flow state, and 146 simply rewrites the address and/or port in a purely algorithmic 147 fashion, including no rewriting). Similarly, a PCP MAP request with 148 a PORT_SET request can be used to discover a port set mapping from a 149 stateless device. See Section 5.2 for an example. 151 2. The need for PORT_SET 153 Multiple PCP MAP requests can be used to manipulate a set of ports, 154 having roughly the same effect as a single use of a PCP MAP request 155 with a PORT_SET option. However, use of the PORT_SET option is more 156 efficient when considering the following aspects: 158 Network Traffic: A single request uses less network resources than 159 multiple requests. 161 Latency: Even though PCP MAP requests can be sent in parallel, we 162 can expect the total processing time to be longer for multiple 163 requests than a single one. 165 Server-side efficiency: Some PCP-controlled devices can allocate 166 port sets in a manner such that data passing through the device is 167 processed much more efficiently than the equivalent using 168 individual port allocations. For example, a CGN having a "bulk" 169 port allocation scheme (see [RFC6888], Section 5) often has this 170 property. 172 Server-side scalability: The number of state table entries in PCP- 173 controlled devices is often a limiting factor. Allocating port 174 sets in a single request can result in a single mapping entry 175 being used, therefore allowing greater scalability. 177 Therefore, while it is functionally possible to obtain the same 178 results using plain MAP, the extension proposed in this document 179 allows greater efficiency, scalability, and simplicity, while 180 lowering latency and necessary network traffic. 182 In addition, PORT_SET supports parity preservation. Some protocols 183 (e.g., RTP [RFC3550]) assign meaning to a port number's parity. When 184 mapping sets of ports for the purpose of using such kind of protocol, 185 preserving parity can be necessary. 187 3. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 4. The PORT_SET Option 195 Option Name: PORT_SET 197 Number: TBD (see Section 8) 199 Purpose: To map sets of ports. 201 Valid for Opcodes: MAP 203 Length: 5 bytes 205 May appear in: Both requests and responses 207 Maximum occurrences: 1 209 The PORT_SET option indicates that the PCP client wishes to reserve a 210 set of ports. The requested number of ports in that set is indicated 211 in the option. 213 The maximum occurrences of the PORT_SET option MUST be limited to 1. 214 The reason is that the suggested external port set depends on the 215 data contained in the MAP Opcode header. Having two PORT_SET options 216 with a single MAP Opcode header would imply having two overlapping 217 suggested external port sets. 219 Note that the option number is in the "optional to process" range 220 (128-191), meaning that a PCP MAP request with a PORT_SET option will 221 be interpreted by a PCP server that does not support PORT_SET as a 222 single-port PCP MAP request, as if the PORT_SET option was absent. 224 The PORT_SET Option is formatted as shown in Figure 1. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |Option Code=TBD| Reserved | Option Length=5 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Port Set Size | First Internal Port | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Reserved |P| 234 +-+-+-+-+-+-+-+-+ 236 Figure 1: PORT_SET Option 238 The fields are as follows: 240 Port Set Size: A 16-bit unsigned integer. Number of ports 241 requested. MUST NOT be zero. 243 First Internal Port: In a request, this field MUST be set equal to 244 the Internal Port field in the MAP opcode by the PCP client. In a 245 response, this field indicates the first internal port of the port 246 set mapped by the PCP server, which may differ from the value sent 247 in the request. That is to be contrasted to the Internal Port 248 field, which by necessity is always identical in matched requests 249 and responses. 251 Reserved: MUST be set to zero when sending, MUST be ignored when 252 receiving. 254 P: 1 if parity preservation is requested, 0 otherwise. See 255 [RFC4787], Section 4.2.2. 257 The Internal Port Set is defined as being the range of Port Set Size 258 ports starting from the First Internal Port. The Suggested External 259 Port Set is defined as being the range of Port Set Size ports 260 starting from the Suggested External Port. Similarly, the Assigned 261 External Port Set is defined as being the range of Port Set Size 262 ports starting from the Assigned External Port. The Internal Port 263 Set returned in a response and the Assigned External Port Set have 264 the same size. 266 The Suggested External Port corresponds to the first port in the 267 suggested External Port Set. Its purpose is for clients to be able to 268 regenerate previous mappings after state loss. When such an event 269 happens, clients may attempt to regenerate identical mappings by 270 suggesting the same External Port Set as before the state loss. Note 271 that there is no guarantee that the allocated External Port Set will 272 be the one suggested by the client. 274 4.1. Client Behavior 276 To retrieve a set of ports, the PCP client adds a PORT_SET option to 277 its PCP MAP request. If parity preservation is required (i.e., an 278 even port to be mapped to an even port, and an odd port to be mapped 279 to an odd port), the PCP client MUST set the parity bit (to 1) to ask 280 the PCP server to preserve the port parity. 282 The PCP client MUST NOT include more than one PORT_SET option in a 283 PCP MAP request. If several port sets are needed, the PCP client 284 MUST issue separate PCP MAP requests, each potentially including a 285 PORT_SET option. These individual PCP MAP requests MUST include 286 distinct Internal Ports. 288 If the PCP client does not know the exact number of ports it 289 requires, it MAY then set the Port Set Size to 0xffff, indicating 290 that it is willing to accept as many ports as the PCP server can 291 offer. 293 A PCP client SHOULD NOT send a PORT_SET option for single-port PCP 294 MAP requests (including creation, renewal, and deletion), because 295 that needlessly increases processing on the server. 297 PREFER_FAILURE MUST NOT appear in a request with PORT_SET option. As 298 a reminder PREFER_FAILURE was specifically designed for the Universal 299 Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol 300 Interworking Function (IGD-PCP IWF) [RFC6970]. The reasons for not 301 recommending the use of PREFER_FAILURE are discussed in Section 13.2 302 of [RFC6887]. 304 When the PCP-controlled device supports multiple port-sets delegation 305 for a given PCP client, the PCP client MAY re-initiate a PCP request 306 to get another port set when it has exhausted all the ports within 307 the port-set. 309 4.2. Server Behavior 311 In addition to regular PCP MAP request processing, the following 312 checks are made upon receipt of a PORT_SET option with non-zero 313 Requested Lifetime: 315 o If multiple PORT_SET options are present in a single PCP MAP 316 request, a MALFORMED_OPTION error is returned. 318 o If the Port Set Size is zero, a MALFORMED_OPTION error is 319 returned. 321 o If PREFER_FAILURE option is present, a MALFORMED_OPTION error is 322 returned. 324 The PCP server MAY map fewer ports than the value of Port Set Size 325 from the request. It MUST NOT map more ports than the PCP client 326 asked for. Internal ports outside the range of Port Set Size ports 327 starting from the Internal Port MUST NOT be mapped by the PCP server. 329 If the requested port set cannot be fully satisfied, the PCP server 330 SHOULD map as many ports as possible, and SHOULD map at least one 331 port (which is the same behavior as if Port Set Size is set to 1). 333 If the PCP server ends up mapping only a single port, for any reason, 334 the PORT_SET option MUST NOT be present in the response. In 335 particular, if the PCP server receives a single-port PCP MAP request 336 that includes a PORT_SET option, the PORT_SET option is silently 337 ignored and the request is handled as a single-port PCP MAP request. 339 If the port parity preservation is requested (P = 1), the PCP server 340 MAY preserve port parity. In that case, the External Port is set to 341 a value having the same parity as the First Internal Port. 343 If the mapping is successful, the MAP response's Assigned External 344 Port is set to the first port in the External Port Set, and the 345 PORT_SET option's Port Set Size is set to number of ports in the 346 mapped port set. The First Internal Port field is set to the first 347 port in the Internal Port Set. 349 4.3. Absence of Capability Discovery 351 A PCP client that wishes to make use of a port set includes the 352 PORT_SET option. If no PORT_SET option is present in the response, 353 the PCP client cannot conclude that the PCP server does not support 354 the PORT_SET option. It may just be that the PCP server does support 355 PORT_SET but decided to allocate only a single port, for reasons that 356 are its own. If the client wishes to obtain more ports, it MAY send 357 additional PCP MAP requests (see Section 6.4), which the PCP server 358 may or may not grant according to local policy. 360 If port set capability is added to or removed from a running PCP 361 server, the server MAY reset its Epoch time and send an ANNOUNCE 362 message as described in the PCP specification ([RFC6887], 363 Section 14.1). This causes PCP clients to retry, and those using 364 PORT_SET will now receive a different response. 366 4.4. Port Set Renewal and Deletion 368 Port set mappings are renewed and deleted as a single entity. That 369 is, the lifetime of all port mappings in the set is set to the 370 Assigned Lifetime at once. 372 A PCP client attempting to refresh or delete a port set mapping MUST 373 include the PORT_SET option in its request. 375 4.4.1. Overlap Conditions 377 Port set PCP MAP requests can overlap with existing single port or 378 port set mappings. This can happen either by mistake or after a PCP 379 client becomes out of sync with server state. 381 If a PCP server receives a PCP MAP request, with or without a 382 PORT_SET option, that tries to map one or more internal ports or port 383 sets belonging to already existing mappings, then the request is 384 considered to be a refresh request applying those mappings. Each of 385 the matching port or port set mappings is processed independently, as 386 if a separate refresh request had been received. The processing is 387 as described in Section 15 of [RFC6887]. The PCP server sends a 388 Mapping Update message for each of the mappings. 390 5. Examples 392 5.1. Simple Request on NAT44 394 An application requires a range of 100 IPv4 UDP ports to be mapped to 395 itself. The application running on the host has created sockets 396 bound to IPv4 UDP ports 50,000 to 50,099 for this purpose. It does 397 not care about which external port numbers are allocated. The PCP 398 client sends a PCP request with the following parameters over IPv4: 400 o MAP opcode 402 Mapping Nonce: 404 Protocol: 17 406 Internal Port: 50,000 408 Suggested External Port: 0 410 Suggested External IP Address: ::ffff:0.0.0.0 412 o PORT_SET Option 413 Port Set Size: 100 415 First Internal Port: 50,000 417 P: 0 419 The PCP server is unable to fulfill the request fully: it is 420 configured by local policy to only allocate 32 ports per user. Since 421 the PREFER_FAILURE option is absent from the request, it decides to 422 map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to 423 internal ports 50,000 to 50,031. After setting up the mapping in the 424 NAT44 device it controls, it replies with the following PCP response: 426 o MAP opcode 428 Mapping Nonce: 430 Protocol: 17 432 Internal Port: 50,000 434 Assigned External Port: 37,056 436 Assigned External IP Address: ::ffff:192.0.2.3 438 o PORT_SET Option 440 Port Set Size: 32 442 First Internal Port: 50,000 444 P: 0 446 Upon receiving this response, the host decides that 32 ports is good 447 enough for its purposes. It closes sockets bound to ports 50,032 to 448 50,099, sets up a refresh timer, and starts using the port range it 449 has just been assigned. 451 5.2. Stateless Mapping Discovery 453 A host wants to discover a stateless NAT44 mapping pointing to it. 454 To do so, it sends the following request over IPv4: 456 o MAP opcode 458 Mapping Nonce: 460 Protocol: 0 461 Internal Port: 1 463 Suggested External Port: 0 465 Suggested External IP Address: ::ffff:0.0.0.0 467 o PORT_SET Option 469 Port Set Size: 65,535 471 First Internal Port: 1 473 P: 0 475 The PCP server sends the following response: 477 o MAP opcode 479 Mapping Nonce: 481 Protocol: 0 483 Internal Port: 1 485 Assigned External Port: 26,624 487 Assigned External IP Address: ::ffff:192.0.2.5 489 o PORT_SET Option 491 Port Set Size: 2048 493 First Internal Port: 26,624 495 P: 0 497 From this response, the host understands that a 2048-port stateless 498 mapping is pointing to itself, starting from port 26,624 on external 499 IP address 192.0.2.5. 501 5.3. Resolving Overlap 503 This example relates to Section 4.4.1. 505 Suppose internal port 100 is mapped to external port 100 and port set 506 101-199 is mapped to external port set 201-299. The PCP server 507 receives a PCP MAP request with Internal Port = 100, External Port = 508 0, and a PORT_SET option with Port Set Size = 100. The request's 509 Mapping Nonce is equal to those of the existing single port and port 510 set mappings. This request is therefore treated as two refresh 511 requests, the first one applying to the single port mapping and the 512 second one applying to the port set mapping. The PCP server updates 513 both mapping's lifetimes as usual then sends two responses: the first 514 one contains Internal Port = 100, External Port = 100, and no 515 PORT_SET option, while the second one contains Internal Port = 101, 516 External Port = 201, and a PORT_SET option with Port Set Size = 99. 518 6. Operational Considerations 520 6.1. Limits and Quotas 522 It is up to the PCP server to determine the port-set quota, if any, 523 for each PCP client. 525 If the PCP server is configured to allocate multiple port-set 526 allocations for one subscriber, the same Assigned External IP Address 527 SHOULD be assigned to the subscriber in multiple port-set responses. 529 To optimize the number of mapping entries maintained by the PCP 530 server, it is RECOMMENDED to configure the PCP server to assign the 531 maximum allowed port set size in a single response. This policy 532 SHOULD be configurable. 534 6.2. High Availability 536 The failover mechanism in MAP (Section 14 in [RFC6887]) can also be 537 applied to port sets. 539 6.3. Idempotence 541 A core, desirable property of the PCP protocol is idempotence. In a 542 nutshell, requests produce the same results whether they are executed 543 once or multiple times. This property is preserved with the PORT_SET 544 attribute, with the following caveat: the order in which the PCP 545 server receives requests with overlapping Internal Port Sets will 546 affect the mappings being created and the responses received. 548 For example suppose these two requests are sent by a PCP client: 550 Request A: Internal Port Set 1-10 552 Request B: Internal Port Set 5-14 554 The PCP server's actions will depend on which request is received 555 first. Suppose that A is received before B: 557 Upon reception of A: Internal ports 1-10 are mapped. A success 558 response containing the following fields is sent: 560 Internal Port: 1 562 First Internal Port: 1 564 Port Set Size: 10 566 Upon reception of B: The request matches mapping A. The request is 567 interpreted as a refresh request for mapping A, and a response 568 containing the following fields is sent: 570 Internal Port: 5 572 First Internal Port: 1 574 Port Set Size: 10 576 If the order of reception is reversed (B before A), the created 577 mapping will be different, and the First Internal Port in both 578 responses would then be 5. 580 To avoid surprises, PCP clients MUST ensure that port set mapping 581 requests do not inadvertently overlap. For example, a host's 582 operating system could include a central PCP client process through 583 which port set mapping requests would be arbitrated. Alternatively, 584 individual PCP clients running on the same host would be required to 585 acquire the internal ports from the operating system (e.g., a call to 586 the bind() function from the BSD API) before trying to map them with 587 PCP. 589 6.4. What Should a PCP Client Do When It Receives Fewer Ports than 590 Requested? 592 Suppose a PCP client asks for 16 ports and receives 8. What should 593 it do? Should it consider this a final answer? Should it try a 594 second request, asking for 8 more ports? Should it fall back to 8 595 individual PCP MAP requests? This document leaves the answers to be 596 implementation-specific, but describes issues to be considered when 597 answering them. 599 First, the PCP server has decided to allocate 8 ports for some 600 reason. It may be that allocation sizes have been limited by the PCP 601 server's administrator. It may be that the PCP client has reached a 602 quota. It may be that these 8 ports were the last contiguous ones 603 available. Depending on the reason, asking for more ports may or may 604 not be likely to actually yield more ports. However, the PCP client 605 has no way of knowing. 607 Second, not all PCP clients asking for N ports actually need all N 608 ports to function correctly. For example, a DNS resolver could ask 609 for N ports to be used for source port randomization. If fewer than 610 N ports are received, the DNS resolver will still work correctly, but 611 source port randomization will be slightly less efficient, having 612 fewer bits to play with. In that case, it would not make much sense 613 to ask for more ports. 615 Finally, asking for more ports could be considered abuse. External 616 ports are a resource that is to be shared among multiple PCP clients. 617 A PCP client trying to obtain more than its fair share could trigger 618 countermeasures according to local policy. 620 In conclusion, it is expected that for most applications, asking for 621 more ports would not yield benefits justifying the additional costs. 623 7. Security Considerations 625 The security considerations discussed in [RFC6887] apply to this 626 extension. 628 As described in Section 4.4.1, a single PCP request using the 629 PORT_SET option may result in multiple responses. For this to happen 630 it is necessary that the request contain the nonce associated to 631 multiple mappings on the server. Therefore, an on-path attacker 632 could use an eavesdropped nonce to mount an amplification attack. 633 Use of PCP authentication ([RFC6887], Section 18) eliminates this 634 attack vector. 636 In order to prevent a PCP client from controlling all ports bound to 637 a shared IP address, port quotas should be configured on the PCP 638 server (Section 17.2 of [RFC6887]). 640 8. IANA Considerations 642 IANA has allocated value TBD (note to IANA: to be allocated from the 643 range 128-191) in the "PCP Options" registry at 644 http://www.iana.org/assignments/pcp-parameters for the new PCP option 645 defined in Section 4. 647 9. Contributors 649 The following are extended authors who contributed to the effort: 651 Yunqing Chen 652 China Telecom 654 Room 502, No.118, Xizhimennei Street 656 Beijing 100035 658 P.R.China 660 Chongfeng Xie 662 China Telecom 664 Room 502, No.118, Xizhimennei Street 666 Beijing 100035 668 P.R.China 670 Yong Cui 672 Tsinghua University 674 Beijing 100084 676 P.R.China 678 Phone: +86-10-62603059 680 Email: yong@csnet1.cs.tsinghua.edu.cn 682 Qi Sun 684 Tsinghua University 686 Beijing 100084 688 P.R.China 690 Phone: +86-10-62785822 692 Email: sunqibupt@gmail.com 694 Gabor Bajko 696 Mediatek Inc. 698 Email: gabor.bajko@mediatek.com 699 Xiaohong Deng 701 France Telecom 703 Email: xiaohong.deng@orange-ftgroup.com 705 10. Acknowledgements 707 The authors would like to show sincere appreciation to Alain Durand, 708 Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam 709 Hartman, Stuart Cheshire, Ted Lemon, Yoshihiro Ohba, Meral 710 Shirazipour, Jouni Korhonen, and Ben Campbell for their useful 711 comments and suggestions. 713 11. References 715 11.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 721 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 722 2013. 724 11.2. Informative References 726 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 727 A., Peterson, J., Sparks, R., Handley, M., and E. 728 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 729 June 2002. 731 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 732 Jacobson, "RTP: A Transport Protocol for Real-Time 733 Applications", STD 64, RFC 3550, July 2003. 735 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 736 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 737 RFC 4787, January 2007. 739 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 740 and H. Ashida, "Common Requirements for Carrier-Grade NATs 741 (CGNs)", BCP 127, RFC 6888, April 2013. 743 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 744 Play (UPnP) Internet Gateway Device - Port Control 745 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 746 DOI 10.17487/RFC6970, July 2013, 747 . 749 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 750 Farrer, "Lightweight 4over6: An Extension to the Dual- 751 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 752 July 2015, . 754 Authors' Addresses 756 Qiong Sun 757 China Telecom 758 P.R.China 760 Phone: 86 10 58552936 761 Email: sunqiong@ctbri.com.cn 763 Mohamed Boucadair 764 France Telecom 765 Rennes 35000 766 France 768 Email: mohamed.boucadair@orange.com 770 Senthil Sivakumar 771 Cisco Systems 772 7100-8 Kit Creek Road 773 Research Triangle Park, North Carolina 27709 774 USA 776 Phone: +1 919 392 5158 777 Email: ssenthil@cisco.com 779 Cathy Zhou 780 Huawei Technologies 781 Bantian, Longgang District 782 Shenzhen 518129 783 P.R. China 785 Email: cathy.zhou@huawei.com 786 Tina Tsou 787 Huawei Technologies (USA) 788 2330 Central Expressway 789 Santa Clara, CA 95050 790 USA 792 Phone: +1 408 330 4424 793 Email: Tina.Tsou.Zouting@huawei.com 795 Simon Perreault 796 Jive Communications 797 Quebec, QC 798 Canada 800 Email: sperreault@jive.com