idnits 2.17.1 draft-ietf-pcp-port-set-11.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 abstract seems to contain references ([RFC7596]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 14, 2015) is 3088 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) == Missing Reference: 'RFC6970' is mentioned on line 307, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 16, 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 14, 2015 16 Port Control Protocol (PCP) Extension for Port Set Allocation 17 draft-ietf-pcp-port-set-11 19 Abstract 21 In some use cases, e.g.,Lightweight 4over6 (lw4o6) [RFC7596], the 22 client may require not just one port, but a port set. This document 23 defines an extension to the Port Control Protocol (PCP) allowing 24 clients to manipulate sets of ports as a whole. This is accomplished 25 by a new 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 16, 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 . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . 15 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 11.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 This document extends PCP [RFC6887] with the ability to retrieve a 96 set of ports using a single request. It does so by defining a new 97 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. Instead, the server can pre-allocate a 112 set of ports such that no PCP exchange is needed during call setup. 114 1.2. Lightweight 4over6 116 In the Lightweight 4over6 (lw4o6) [RFC7596] architecture, shared 117 global addresses can be allocated to customers. It allows moving the 118 Network Address Translation (NAT) function, otherwise accomplished by 119 a Carrier-Grade NAT (CGN) [RFC6888], to the Customer-Premises 120 Equipment (CPE). This provides more control over the NAT function to 121 the user, and more scalability to the ISP. 123 In the lw4o6 architecture, the PCP-controlled device corresponds to 124 the Lightweight AFTR (lwAFTR), and the PCP client corresponds to the 125 Lightweight B4 (lwB4). The PCP client sends a PCP MAP request 126 containing a PORT_SET option to trigger shared address allocation on 127 the Lightweight AFTR (lwAFTR). The PCP response contains the shared 128 address information, including the port set allocated to the 129 Lightweight B4 (lwB4). 131 1.3. Firewall Control 133 Port sets are often used in firewall rules. For example, defining a 134 range for RTP [RFC3550] traffic is common practice. The MAP request 135 can already be used for firewall control. The PORT_SET option brings 136 the additional ability to manipulate firewall rules operating on port 137 sets instead of single ports. 139 1.4. Discovering Stateless Port Set Mappings 141 A MAP request can be used to retrieve a mapping from a stateless 142 device (i.e., one that does not establish any per-flow state, and 143 simply rewrites the address and/or port in a purely algorithmic 144 fashion, including no rewriting). Similarly, a MAP request with a 145 PORT_SET request can be used to discover a port set mapping from a 146 stateless device. See Section 5.2 for an example. 148 2. The need for PORT_SET 150 Multiple MAP requests can be used to manipulate a set of ports, 151 having roughly the same effect as a single use of a MAP request with 152 a PORT_SET option. However, use of the PORT_SET option is more 153 efficient when considering the following aspects: 155 Network Traffic: A single request uses less network resources than 156 multiple requests. 158 Latency: Even though MAP requests can be sent in parallel, we can 159 expect the total processing time to be longer for multiple 160 requests than a single one. 162 Server-side efficiency: Some PCP-controlled devices can allocate 163 port sets in a manner such that data passing through the device is 164 processed much more efficiently than the equivalent using 165 individual port allocations. For example, a CGN having a "bulk" 166 port allocation scheme (see [RFC6888] section 5) often has this 167 property. 169 Server-side scalability: The number of state table entries in PCP- 170 controlled devices is often a limiting factor. Allocating port 171 sets in a single request can result in a single mapping entry 172 being used, therefore allowing greater scalability. 174 Therefore, while it is functionally possible to obtain the same 175 results using plain MAP, the extension proposed in this document 176 allows greater efficiency, scalability, and simplicity, while 177 lowering latency and necessary network traffic. 179 In addition, PORT_SET supports parity preservation. Some protocols 180 (e.g. RTP [RFC3550]) assign meaning to a port number's parity. When 181 mapping sets of ports for the purpose of using such kind of protocol, 182 preserving parity can be necessary. 184 3. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 4. The PORT_SET Option 192 Option Name: PORT_SET 194 Number: TBD 196 Purpose: To map sets of ports. 198 Valid for Opcodes: MAP 200 Length: 5 bytes 202 May appear in: Both requests and responses 204 Maximum occurrences: 1 206 The PORT_SET Option indicates that the PCP client wishes to reserve a 207 set of ports. The requested number of ports in that set is indicated 208 in the option. 210 The maximum occurrences of the PORT_SET Option should be limited to 211 1. The reason is that the suggested external port set depends on the 212 data contained in the MAP Opcode header. Having two PORT_SET options 213 with a single MAP Opcode header would imply having two overlapping 214 suggested external port sets. 216 Note that the option number is in the "optional to process" range 217 (128-191), meaning that a MAP request with a PORT_SET option will be 218 interpreted by a PCP server that does not support PORT_SET as a 219 single-port MAP request, as if the PORT_SET option was absent. 221 The PORT_SET Option is formatted as shown in Figure 1. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 |Option Code=TBD| Reserved | Option Length=5 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Port Set Size | First Internal Port | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Reserved |P| 231 +-+-+-+-+-+-+-+-+ 233 Figure 1: PORT_SET Option 235 The fields are as follows: 237 Port Set Size: Number of ports requested. MUST NOT be zero. 239 First Internal Port: In a request, this field MUST be set equal to 240 the Internal Port field in the MAP opcode by the PCP client. In a 241 response, this field indicates the first internal port of the port 242 set mapped by the PCP server, which may differ from the value sent 243 in the request. That is to be contrasted to the Internal Port 244 field, which by necessity is always identical in matched requests 245 and responses. 247 Reserved: MUST be set to zero when sending, MUST be ignored when 248 receiving. 250 P: 1 if parity preservation is requested, 0 otherwise. See 251 [RFC4787], Section 4.2.2. 253 The Internal Port Set is defined as being the range of Port Set Size 254 ports starting from the First Internal Port. The External Port Set 255 is respectively defined as being the range of Port Set Size ports 256 starting from the Assigned External Port. The two ranges always have 257 the same size (i.e., the Port Set Size returned by the PCP server). 259 The Suggested External Port corresponds to the first port in the 260 Assigned External Port Set. Its purpose is for clients to be able to 261 regenerate previous mappings after state loss. When such an event 262 happens, clients may attempt to regenerate identical mappings by 263 suggesting the same External Port Set as before the state loss. Note 264 that there is no guarantee that the allocated External Port Set will 265 be the one suggested by the client. In particular, the 266 PREFER_FAILURE option MUST NOT be present in a request that contains 267 a PORT_SET option. 269 4.1. Client Behavior 271 To retrieve a set of ports, the PCP client adds a PORT_SET option to 272 its PCP MAP request. If port preservation is required, the PCP 273 Client MUST set the parity bit (to 1) to ask the PCP server to 274 preserve the port parity. 276 The PCP Client MUST NOT include more than one PORT_SET option in a 277 MAP request. If several port sets are needed, the PCP client MUST 278 issue separate MAP requests, each potentially including a PORT_SET 279 option. These individual MAP requests MUST include distinct Internal 280 Port. 282 If the PCP Client does not know the exact number of ports it 283 requires, it MAY then set the Port Set Size to 0xffff, indicating 284 that it is willing to accept as many ports as the PCP server can 285 offer. 287 When the PCP-controlled device supports multiple port-sets delegation 288 for a given PCP client, the PCP client MAY re-initiate a PCP request 289 to get another port set when it has exhausted all the ports within 290 the port-set. 292 4.2. Server Behavior 294 In addition to regular MAP request processing, the following checks 295 are made upon receipt of a PORT_SET option with non-zero Requested 296 Lifetime: 298 o If multiple PORT_SET options are present in a single MAP request, 299 a MALFORMED_OPTION error is returned. 301 o If the Port Set Size is zero, a MALFORMED_OPTION error is 302 returned. 304 PREFER_FAILURE MUST NOT appear in a request with PORT_SET option. As 305 a reminder PREFER_FAILURE was specifically designed for the Universal 306 Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol 307 Interworking Function (IGD-PCP IWF) [RFC6970]. The reasons for not 308 recommending the use of PREFER_FAILURE are discussed in Section 13.2 309 of [RFC6887]. The PCP server MAY map fewer ports than the value of 310 Port Set Size from the request. It MUST NOT map more ports than the 311 PCP client asked for. Internal ports outside the range of Port Set 312 Size ports starting from the Internal Port MUST NOT be mapped by the 313 PCP server. 315 If the requested port set cannot be fully satisfied, the PCP server 316 SHOULD map as many ports as possible, and SHOULD map at least one 317 port (which is the same behavior as if Port Set Size is set to 1). 319 If the PCP server ends up mapping only a single port, for any reason, 320 the PORT_SET option MUST NOT be present in the response. 322 If the port parity preservation is requested (P = 1), the PCP server 323 MAY preserve port parity. In that case, the External Port is set to 324 a value having the same parity as the First Internal Port. 326 If the mapping is successful, the MAP response's Assigned External 327 Port is set to the first port in the External Port Set, and the 328 PORT_SET option's Port Set Size is set to number of ports in the 329 mapped port set. The First Internal Port field is set to the first 330 port in the Internal Port Set. 332 4.3. Absence of Capability Discovery 334 A PCP client that wishes to make use of a port set unconditionally 335 includes the PORT_SET option. If no PORT_SET option is present in 336 the response, the PCP client cannot conclude that the PCP server does 337 not support the PORT_SET option. It may just be that the PCP server 338 does support PORT_SET but decided to allocate only a single port, for 339 reasons that are its own. If the client wishes to obtain more ports, 340 it MAY send additional MAP requests (see Section 6.4), which the PCP 341 server may or may not grant according to local policy. 343 If port set capability is added to or removed from a running PCP 344 server, the server MAY reset its Epoch time and send an ANNOUNCE 345 message as described in the PCP specification ([RFC6887], 346 Section 14.1). This causes PCP clients to re-try, and those using 347 PORT_SET will now receive a different response. 349 4.4. Port Set Renewal and Deletion 351 Port set mappings are renewed and deleted as a single entity. That 352 is, the lifetime of all port mappings in the set is set to the 353 Assigned Lifetime at once. 355 A PCP client attempting to refresh or delete a port set mapping MUST 356 include the PORT_SET option in its request. A PCP client MUST NOT 357 send a PORT_SET option for single-port refreshes. 359 4.4.1. Overlap Conditions 361 Port set map requests can overlap with existing single port or port 362 set mappings. This can happen either by mistake or after a PCP 363 client becomes out of sync with server state. 365 If a PCP server receives a MAP request, with or without a PORT_SET 366 option, that tries to map one or more internal ports or port sets 367 belonging to already existing mappings, then the request is 368 considered to be a refresh request applying those mappings. Each of 369 the matching port or port set mappings is processed independently, as 370 if a separate refresh request had been received. The processing is 371 as described in Section 15 of [RFC6887]. The PCP server sends a 372 Mapping Update message for each of the mappings. 374 5. Examples 376 5.1. Simple Request on NAT44 378 An application requires a range of 100 IPv4 UDP ports to be mapped to 379 itself. The application running on the host has created sockets 380 bound to IPv4 UDP ports 50,000 to 50,099 for this purpose. It does 381 not care about which external port numbers are allocated. The PCP 382 client sends a PCP request with the following parameters over IPv4: 384 o MAP opcode 386 Mapping Nonce: 388 Protocol: 17 390 Internal Port: 50,000 392 Suggested External Port: 0 394 Suggested External IP Address: ::ffff:0.0.0.0 396 o PORT_SET Option 398 Port Set Size: 100 400 First Internal Port: 50,000 402 P: 0 404 The PCP server is unable to fulfill the request fully: it is 405 configured by local policy to only allocate 32 ports per user. Since 406 the PREFER_FAILURE option is absent from the request, it decides to 407 map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to 408 internal ports 50,000 to 50,031. After setting up the mapping in the 409 NAT44 device it controls, it replies with the following PCP response: 411 o MAP opcode 413 Mapping Nonce: 415 Protocol: 17 417 Internal Port: 50,000 419 Assigned External Port: 37,056 421 Assigned External IP Address: ::ffff:192.0.2.3 423 o PORT_SET Option 425 Port Set Size: 32 427 First Internal Port: 50,000 429 P: 0 431 Upon receiving this response, the host decides that 32 ports is good 432 enough for its purposes. It closes sockets bound to ports 50,032 to 433 50,099, sets up a refresh timer, and starts using the port range it 434 has just been assigned. 436 5.2. Stateless Mapping Discovery 438 A host wants to discover a stateless NAT44 mapping pointing to it. 439 To do so, it sends the following request over IPv4: 441 o MAP opcode 443 Mapping Nonce: 445 Protocol: 0 447 Internal Port: 1 449 Suggested External Port: 0 451 Suggested External IP Address: ::ffff:0.0.0.0 453 o PORT_SET Option 454 Port Set Size: 65,535 456 First Internal Port: 1 458 P: 0 460 The PCP server sends the following response: 462 o MAP opcode 464 Mapping Nonce: 466 Protocol: 0 468 Internal Port: 1 470 Assigned External Port: 26,624 472 Assigned External IP Address: ::ffff:192.0.2.5 474 o PORT_SET Option 476 Port Set Size: 2048 478 First Internal Port: 26,624 480 P: 0 482 From this response, the host understands that a 2048-port stateless 483 mapping is pointing to itself, starting from port 26,624 on external 484 IP address 192.0.2.5. 486 5.3. Resolving Overlap 488 This example relates to Section 4.4.1. 490 Suppose internal port 100 is mapped to external port 100 and port set 491 101-199 is mapped to external port set 201-299. The PCP server 492 receives a MAP request with Internal Port = 100, External Port = 0, 493 and a PORT_SET option with Port Set Size = 100. The request's 494 Mapping Nonce is equal to those of the existing single port and port 495 set mappings. This request is therefore treated as two refresh 496 requests, the first one applying to the single port mapping and the 497 second one applying to the port set mapping. The PCP server updates 498 both mapping's lifetimes as usual then sends two responses: the first 499 one contains Internal Port = 100, External Port = 100, and no 500 PORT_SET option, while the second one contains Internal Port = 101, 501 External Port = 201, and a PORT_SET option with Port Set Size = 99. 503 6. Operational Considerations 505 6.1. Limits and Quotas 507 It is up to the PCP server to determine the port-set quota, if any, 508 for each PCP client. 510 If the PCP server is configured to allocate multiple port-set 511 allocations for one subscriber, the same Assigned External IP Address 512 SHOULD be assigned to the subscriber in multiple port-set responses. 514 To optimize the number of mapping entries maintained by the PCP 515 server, it is RECOMMENDED to configure the PCP server to assign the 516 maximum allowed port set size in a single response. This policy 517 SHOULD be configurable. 519 6.2. High Availability 521 The failover mechanism in MAP [section 14 in [RFC6887]] can also be 522 applied to port sets. 524 6.3. Idempotence 526 A core, desirable property of the PCP protocol is idempotence. In a 527 nutshell, requests produce the same results whether they are executed 528 once or multiple times. This property is preserved with the PORT_SET 529 attribute, with the following caveat: the order in which the PCP 530 server receives requests with overlapping Internal Port Sets will 531 affect the mappings being created and the responses received. 533 For example suppose these two requests are sent by a PCP client: 535 Request A: Internal Port Set 1-10 537 Request B: Internal Port Set 5-14 539 The PCP server's actions will depend on which request is received 540 first. Suppose that A is received before B: 542 Upon reception of A: Internal ports 1-10 are mapped. A success 543 response containing the following fields is sent: 545 Internal Port: 1 547 First Internal Port: 1 549 Port Set Size: 10 551 Upon reception of B: The request matches mapping A. The request is 552 interpreted as a refresh request for mapping A, and a response 553 containing the following fields is sent: 555 Internal Port: 5 557 First Internal Port: 1 559 Port Set Size: 10 561 If the order of reception is reversed (B before A), the created 562 mapping will be different, and the First Internal Port in both 563 responses would then be 5. 565 To avoid surprises, PCP clients MUST ensure that port set mapping 566 requests do not inadvertently overlap. For example, a host's 567 operating system could include a central PCP client process through 568 which port set mapping requests would be arbitrated. Alternatively, 569 individual PCP clients running on the same host would be required to 570 acquire the internal ports from the operating system (e.g., a call to 571 the bind() function from the BSD API) before trying to map them with 572 PCP. 574 6.4. What should a PCP client do when it receives fewer ports than 575 requested? 577 Suppose a PCP client asks for 16 ports and receives 8. What should 578 it do? Should it consider this a final answer? Should it try a 579 second request, asking for 8 more ports? Should it fall back to 8 580 individual MAP requests? This document leaves the answers to be 581 implementation-specific, but describes issues to be considered when 582 answering them. 584 First, the PCP server has decided to allocate 8 ports for some 585 reason. It may be that allocation sizes have been limited by the PCP 586 server's administrator. It may be that the PCP client has reached a 587 quota. It may be that these 8 ports were the last contiguous ones 588 available. Depending on the reason, asking for more ports may or may 589 not be likely to actually yield more ports. However, the PCP client 590 has no way of knowing. 592 Second, not all PCP clients asking for N ports actually need all N 593 ports to function correctly. For example, a DNS resolver could ask 594 for N ports to be used for source port randomization. If fewer than 595 N ports are received, the DNS resolver will still work correctly, but 596 source port randomization will be slightly less efficient, having 597 fewer bits to play with. In that case, it would not make much sense 598 to ask for more ports. 600 Finally, asking for more ports could be considered abuse. External 601 ports are a resource that is to be shared among multiple PCP clients. 602 A PCP client trying to obtain more than its fair share could trigger 603 countermeasures according to local policy. 605 In conclusion, it is expected that for most applications, asking for 606 more ports would not yield benefits justifying the additional costs. 608 7. Security Considerations 610 The security considerations discussed in [RFC6887] apply to this 611 extension. 613 As described in Section 4.4.1, a single PCP request using the 614 PORT_SET option may result in multiple responses. For this to happen 615 it is necessary that the request contain the nonce associated to 616 multiple mappings on the server. Therefore, an on-path attacker 617 could use an eavesdropped nonce to mount an amplification attack. 618 Use of PCP authentication ([RFC6887], Section 18) eliminates this 619 attack vector. 621 8. IANA Considerations 623 IANA has allocated value TBD (note to IANA: to be allocated from the 624 range 128-191) in the "PCP Options" registry at 625 http://www.iana.org/assignments/pcp-parameters for the new PCP option 626 defined in Section 4. 628 9. Contributors 630 The following are extended authors who contributed to the effort: 632 Yunqing Chen 634 China Telecom 636 Room 502, No.118, Xizhimennei Street 638 Beijing 100035 640 P.R.China 642 Chongfeng Xie 644 China Telecom 646 Room 502, No.118, Xizhimennei Street 647 Beijing 100035 649 P.R.China 651 Yong Cui 653 Tsinghua University 655 Beijing 100084 657 P.R.China 659 Phone: +86-10-62603059 661 Email: yong@csnet1.cs.tsinghua.edu.cn 663 Qi Sun 665 Tsinghua University 667 Beijing 100084 669 P.R.China 671 Phone: +86-10-62785822 673 Email: sunqibupt@gmail.com 675 Gabor Bajko 677 Nokia 679 Email: gabor.bajko@nokia.com 681 Xiaohong Deng 683 France Telecom 685 Email: xiaohong.deng@orange-ftgroup.com 687 10. Acknowledgements 689 The authors would like to show sincere appreciation to Alain Durand, 690 Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam 691 Hartman, Stuart Cheshire, Ted Lemon, and Yoshihiro Ohba, for their 692 useful comments and suggestions. 694 11. References 696 11.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 702 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 703 2013. 705 11.2. Informative References 707 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 708 A., Peterson, J., Sparks, R., Handley, M., and E. 709 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 710 June 2002. 712 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 713 Jacobson, "RTP: A Transport Protocol for Real-Time 714 Applications", STD 64, RFC 3550, July 2003. 716 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 717 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 718 RFC 4787, January 2007. 720 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 721 and H. Ashida, "Common Requirements for Carrier-Grade NATs 722 (CGNs)", BCP 127, RFC 6888, April 2013. 724 [RFC7596] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 725 I. Farrer, "Lightweight 4over6: An Extension to the DS- 726 Lite Architecture", RFC 7596, July 2015. 728 Authors' Addresses 730 Qiong Sun 731 China Telecom 732 P.R.China 734 Phone: 86 10 58552936 735 Email: sunqiong@ctbri.com.cn 736 Mohamed Boucadair 737 France Telecom 738 Rennes 35000 739 France 741 Email: mohamed.boucadair@orange.com 743 Senthil Sivakumar 744 Cisco Systems 745 7100-8 Kit Creek Road 746 Research Triangle Park, North Carolina 27709 747 USA 749 Phone: +1 919 392 5158 750 Email: ssenthil@cisco.com 752 Cathy Zhou 753 Huawei Technologies 754 Bantian, Longgang District 755 Shenzhen 518129 756 P.R. China 758 Email: cathy.zhou@huawei.com 760 Tina Tsou 761 Huawei Technologies (USA) 762 2330 Central Expressway 763 Santa Clara, CA 95050 764 USA 766 Phone: +1 408 330 4424 767 Email: Tina.Tsou.Zouting@huawei.com 769 Simon Perreault 770 Jive Communications 771 Quebec, QC 772 Canada 774 Email: sperreault@jive.com