idnits 2.17.1 draft-ietf-pcp-port-set-05.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 (May 23, 2014) is 3619 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) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-03 Summary: 0 errors (**), 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: November 24, 2014 France Telecom 6 S. Sivakumar 7 Cisco Systems 8 C. Zhou 9 Huawei Technologies 10 T. Tsou 11 Huawei Technologies (USA) 12 S. Perreault 14 May 23, 2014 16 Port Control Protocol (PCP) Extension for Port Set Allocation 17 draft-ietf-pcp-port-set-05 19 Abstract 21 This document defines an extension to the Port Control Protocol (PCP) 22 allowing clients to manipulate sets of ports as a whole. This is 23 accomplished by a new MAP option: PORT_SET. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 24, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Applications Using Port Sets . . . . . . . . . . . . . . 3 61 1.2. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 3 62 1.3. Firewall Control . . . . . . . . . . . . . . . . . . . . 3 63 1.4. Discovering Stateless Port Set Mappings . . . . . . . . . 3 64 2. The need for PORT_SET . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. The PORT_SET Option . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 69 4.3. Absence of Capability Discovery . . . . . . . . . . . . . 7 70 4.4. Port Set Renewal and Deletion . . . . . . . . . . . . . . 8 71 4.4.1. Overlap Conditions . . . . . . . . . . . . . . . . . 8 72 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Simple Request on NAT44 . . . . . . . . . . . . . . . . . 8 74 5.2. Stateless Mapping Discovery . . . . . . . . . . . . . . . 10 75 5.3. Resolving Overlap . . . . . . . . . . . . . . . . . . . . 11 76 6. Operational Considerations . . . . . . . . . . . . . . . . . 11 77 6.1. Limits and Quotas . . . . . . . . . . . . . . . . . . . . 11 78 6.2. High Availability . . . . . . . . . . . . . . . . . . . . 11 79 6.3. Idempotence . . . . . . . . . . . . . . . . . . . . . . . 11 80 6.4. What should a PCP client do when it receives fewer ports 81 than requested? . . . . . . . . . . . . . . . . . . . . . 13 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 11.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 This document extends PCP [RFC6887] with the ability to retrieve a 94 set of ports using a single request. It does so by defining a new 95 PORT_SET option. 97 This section describes a few (and non-exhaustive) envisioned use 98 cases. Note that the PCP extension defined in this document is 99 generic and is expected to be applicable to other use cases. 101 1.1. Applications Using Port Sets 103 Some applications require not just one port, but a port set. One 104 example is a Session Initiation Protocol (SIP) User Agent Server 105 (UAS) [RFC3261] expecting to handle multiple concurrent calls, 106 including media termination. When it receives a call, it needs to 107 signal media port numbers to its peer. Generating individual PCP MAP 108 requests for each of the media ports during call setup would 109 introduce unwanted latency. Instead, the server can pre-allocate a 110 set of ports such that no PCP exchange is needed during call setup. 112 1.2. Lightweight 4over6 114 In the Lightweight 4over6 (lw4o6) [I-D.ietf-softwire-lw4over6] 115 architecture, shared global addresses can be allocated to customers. 116 It allows moving the Network Address Translation (NAT) function, 117 otherwise accomplished by a Carrier-Grade NAT (CGN) [RFC6888], to the 118 Customer-Premises Equipment (CPE). This provides more control over 119 the NAT function to the user, and more scalability to the ISP. 121 In the lw4o6 architecture, the PCP-controlled device corresponds to 122 the lwAFTR, and the PCP client corresponds to the lwB4. The PCP 123 client sends a PCP MAP request containing a PORT_SET option to 124 trigger shared address allocation on the lwAFTR. The PCP response 125 contains the shared address information, including the port set 126 allocated to the lwB4. 128 1.3. Firewall Control 130 Port sets are often used in firewall rules. For example, defining a 131 range for RTP [RFC3550] traffic is common practice. The MAP request 132 can already be used for firewall control. The PORT_SET option brings 133 the additional ability to manipulate firewall rules operating on port 134 sets instead of single ports. 136 1.4. Discovering Stateless Port Set Mappings 138 A MAP request can be used to retrieve a mapping from a stateless 139 device (i.e., one that does not establish any per-flow state, and 140 simply rewrites the address and/or port in a purely algorithmic 141 fashion, including no rewriting). Similarly, a MAP request with a 142 PORT_SET request can be used to discover a port set mapping from a 143 stateless device. See Section 5.2 for an example. 145 2. The need for PORT_SET 147 Multiple MAP requests can be used to manipulate a set of ports, 148 having roughly the same effect as a single use of a MAP request with 149 a PORT_SET option. However, use of the PORT_SET option is more 150 efficient when considering the following aspects: 152 Network Traffic: A single request uses less network resources than 153 multiple requests. 155 Latency: Even though MAP requests can be sent in parallel, we can 156 expect the total processing time to be longer for multiple 157 requests than a single one. 159 Client-side simplicity: The logic that is necessary for maintaining 160 a set of ports using a single port set entity is much simpler than 161 that required for maintaining individual ports, especially when 162 considering failures, retransmissions, lifetime expiration, and 163 re-allocations. 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 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 Note that the option number is in the "optional to process" range 214 (128-255), meaning that a MAP request with a PORT_SET option will be 215 interpreted by a PCP server that does not support PORT_SET as a 216 single-port MAP request, as if the PORT_SET option was absent. 218 The PORT_SET Option is formatted as shown in Figure 1. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |Option Code=TBD| Reserved | Option Length=5 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Port Set Size | First Internal Port | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved |P| 228 +-+-+-+-+-+-+-+-+ 230 Figure 1: PORT_SET Option 232 The fields are as follows: 234 Port Set Size: Number of ports requested. MUST NOT be zero. 236 First Internal Port: In a request, this field MUST be set equal to 237 the Internal Port field in the MAP opcode by the PCP client. In a 238 response, this field indicates the first internal port of the port 239 set mapped by the PCP server, which may differ from the value sent 240 in the request. That is to be contrasted to the Internal Port 241 field, which by necessity is always identical in matched requests 242 and responses. 244 Reserved: MUST be set to zero when sending, MUST be ignored when 245 receiving. 247 P: 1 if parity preservation is requested, 0 otherwise. See 248 [RFC4787], Section 4.2.2. 250 The Internal Port Set is defined as being the range of Port Set Size 251 ports starting from the First Internal Port. The External Port Set 252 is respectively defined as being the range of Port Set Size ports 253 starting from the Assigned External Port. The two ranges always have 254 the same size (i.e., the Port Set Size returned by the PCP server). 256 4.1. Client Behavior 258 To retrieve a set of ports, the PCP client adds a PORT_SET option to 259 its PCP MAP request. If port preservation is required, the PCP 260 Client MUST set the parity bit (to 1) to ask the PCP server to 261 preserve the port parity. 263 The PCP Client MUST NOT include more than one PORT_SET option in a 264 MAP request. If several port sets are needed, the PCP client MUST 265 issue separate MAP requests, each potentially including a PORT_SET 266 option. These individual MAP requests MUST include distinct Internal 267 Port. 269 If the PCP Client does not know the exact number of ports it 270 requires, it MAY then set the Port Set Size to 0xffff, indicating 271 that it is willing to accept as many ports as the PCP server can 272 offer. 274 When the PCP-controlled device supports multiple port-sets delegation 275 for a given PCP client, the PCP client MAY re-initiate a PCP request 276 to get another port set when it has exhausted all the ports within 277 the port-set. 279 4.2. Server Behavior 281 In addition to regular MAP request processing, the following checks 282 are made upon receipt of a PORT_SET option with non-zero Requested 283 Lifetime: 285 o If multiple PORT_SET options are present in a single MAP request, 286 a MALFORMED_OPTION error is returned. 288 o If the Port Set Size is zero, a MALFORMED_OPTION error is 289 returned. 291 If the PREFER_FAILURE option is present and the PCP server is unable 292 to map all ports in the requested External Port Set or is unable to 293 preserve parity (P = 1), the CANNOT_PROVIDE_EXTERNAL error is 294 returned. 296 If the PREFER_FAILURE option is absent, the PCP server MAY map fewer 297 ports than the value of Port Set Size from the request. It MUST NOT 298 map more ports than the PCP client asked for. Internal ports outside 299 the range of Port Set Size ports starting from the Internal Port MUST 300 NOT be mapped by the PCP server. 302 If the requested port set cannot be fully satisfied, the PCP server 303 SHOULD map as many ports as possible, and SHOULD map at least one 304 port (which is the same behavior as if Port Set Size is set to 1). 306 If the PCP server ends up mapping only a single port, for any reason, 307 the PORT_SET option MUST NOT be present in the response. 309 If the PREFER_FAILURE option is absent and port parity preservation 310 is requested (P = 1), the PCP server MAY preserve port parity. In 311 that case, the External Port is set to a value having the same parity 312 as the First Internal Port. 314 If the mapping is successful, the MAP response's Assigned External 315 Port is set to the first port in the External Port Set, and the 316 PORT_SET option's Port Set Size is set to number of ports in the 317 mapped port set. The First Internal Port field is set to the first 318 port in the Internal Port Set. 320 4.3. Absence of Capability Discovery 322 There is intentionally no port set capability discovery mechanism. A 323 PCP client that wishes to make use of a port set unconditionally 324 includes the PORT_SET option. If no PORT_SET option is present in 325 the response, the PCP client cannot conclude that the PCP server does 326 not support the PORT_SET option. It may just be that the PCP server 327 does support PORT_SET but decided to allocate only a single port, for 328 reasons that are its own. If the client wishes to obtain more ports, 329 it MAY send additional MAP requests (see Section 6.4), which the PCP 330 server may or may not grant according to local policy. The presence 331 or absence of the PORT_SET attribute in those requests MUST NOT 332 depend on the presence or absence of the PORT_SET attribute in 333 previous responses. 335 If port set capability is added to or removed from a running PCP 336 server, the server MAY reset its Epoch time and send an ANNOUNCE 337 message as described in the PCP specification ([RFC6887], 338 Section 14.1). This causes PCP clients to re-try, and those using 339 PORT_SET will now receive a different response. 341 4.4. Port Set Renewal and Deletion 343 Port set mappings are renewed and deleted as a single entity. That 344 is, the lifetime of all port mappings in the set is set to the 345 Assigned Lifetime at once. 347 A PCP client attempting to refresh or delete a port set mapping MUST 348 include the PORT_SET option in its request. 350 4.4.1. Overlap Conditions 352 Port set map requests can overlap with existing single port or port 353 set mappings. This can happen either by mistake or after a PCP 354 client becomes out of sync with server state. 356 If a PCP server receives a MAP request, with or without a PORT_SET 357 option, that tries to map one or more internal ports or port sets 358 belonging to already existing mappings, then the request is 359 considered to be a refresh request applying those mappings. Each of 360 the matching port or port set mappings is processed independently, as 361 if a separate refresh request had been received. The processing is 362 as described in Section 15 of [RFC6887]. The PCP server sends a 363 Mapping Update message for each of the mappings. 365 5. Examples 367 5.1. Simple Request on NAT44 369 An application requires a range of 100 IPv4 UDP ports to be mapped to 370 itself. The application running on the host has created sockets 371 bound to IPv4 UDP ports 50,000 to 50,099 for this purpose. It does 372 not care about which external port numbers are allocated. The PCP 373 client sends a PCP request with the following parameters over IPv4: 375 o MAP opcode 377 Mapping Nonce: 379 Protocol: 17 381 Internal Port: 50,000 382 Suggested External Port: 0 384 Suggested External IP Address: ::ffff:0.0.0.0 386 o PORT_SET Option 388 Port Set Size: 100 390 First Internal Port: 50,000 392 P: 0 394 The PCP server is unable to fulfill the request fully: it is 395 configured by local policy to only allocate 32 ports per user. Since 396 the PREFER_FAILURE option is absent from the request, it decides to 397 map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to 398 internal ports 50,000 to 50,031. After setting up the mapping in the 399 NAT44 device it controls, it replies with the following PCP response: 401 o MAP opcode 403 Mapping Nonce: 405 Protocol: 17 407 Internal Port: 50,000 409 Assigned External Port: 37,056 411 Assigned External IP Address: ::ffff:192.0.2.3 413 o PORT_SET Option 415 Port Set Size: 32 417 First Internal Port: 50,000 419 P: 0 421 Upon receiving this response, the host decides that 32 ports is good 422 enough for its purposes. It closes sockets bound to ports 50,032 to 423 50,099, sets up a refresh timer, and starts using the port range it 424 has just been assigned. 426 5.2. Stateless Mapping Discovery 428 A host wants to discover a stateless NAT44 mapping pointing to it. 429 To do so, it sends the following request over IPv4: 431 o MAP opcode 433 Mapping Nonce: 435 Protocol: 0 437 Internal Port: 1 439 Suggested External Port: 0 441 Suggested External IP Address: ::ffff:0.0.0.0 443 o PORT_SET Option 445 Port Set Size: 65,535 447 First Internal Port: 1 449 P: 0 451 The PCP server sends the following response: 453 o MAP opcode 455 Mapping Nonce: 457 Protocol: 0 459 Internal Port: 1 461 Assigned External Port: 26,624 463 Assigned External IP Address: ::ffff:192.0.2.5 465 o PORT_SET Option 467 Port Set Size: 2048 469 First Internal Port: 26,624 471 P: 0 473 From this response, the host understands that a 2048-port stateless 474 mapping is pointing to itself, starting from port 26,624 on external 475 IP address 192.0.2.5. 477 5.3. Resolving Overlap 479 This example relates to Section 4.4.1. 481 Suppose internal port 100 is mapped to external port 100 and port set 482 101-199 is mapped to external port set 201-299. The PCP server 483 receives a MAP request with Internal Port = 100, External Port = 0, 484 and a PORT_SET option with Port Set Size = 100. The request's 485 Mapping Nonce is equal to those of the existing single port and port 486 set mappings. This request is therefore treated as two refresh 487 requests, the first one applying to the single port mapping and the 488 second one applying to the port set mapping. The PCP server updates 489 both mapping's lifetimes as usual then sends two responses: the first 490 one contains Internal Port = 100, External Port = 100, and no 491 PORT_SET option, while the second one contains Internal Port = 101, 492 External Port = 201, and a PORT_SET option with Port Set Size = 99. 494 6. Operational Considerations 496 6.1. Limits and Quotas 498 It is up to the PCP server to determine the port-set quota, if any, 499 for each PCP client. 501 If the PCP server is configured to allocate multiple port-set 502 allocations for one subscriber, the same Assigned External IP Address 503 SHOULD be assigned to the subscriber in multiple port-set responses. 505 To optimize the number of mapping entries maintained by the PCP 506 server, it is RECOMMENDED to configure the PCP server to assign the 507 maximum allowed port set size in a single response. This policy 508 SHOULD be configurable. 510 6.2. High Availability 512 The failover mechanism in MAP [section 14 in [RFC6887]] can also be 513 applied to port sets. 515 6.3. Idempotence 517 A core, desirable property of the PCP protocol is idempotence. In a 518 nutshell, requests produce the same results whether they are executed 519 once or multiple times. This property is preserved with the PORT_SET 520 attribute, with the following caveat: the order in which the PCP 521 server receives requests with overlapping Internal Port Sets will 522 affect the mappings being created and the responses received. 524 For example suppose these two requests are sent by a PCP client: 526 Request A: Internal Port Set 1-10 528 Request B: Internal Port Set 5-14 530 The PCP server's actions will depend on which request is received 531 first. Suppose that A is received before B: 533 Upon reception of A: Internal ports 1-10 are mapped. A success 534 response containing the following fields is sent: 536 Internal Port: 1 538 First Internal Port: 1 540 Port Set Size: 10 542 Upon reception of B: The request matches mapping A. The request is 543 interpreted as a refresh request for mapping A, and a response 544 containing the following fields is sent: 546 Internal Port: 5 548 First Internal Port: 1 550 Port Set Size: 10 552 If the order of reception is reversed (B before A), the created 553 mapping will be different, and the First Internal Port in both 554 responses would then be 5. 556 To avoid surprises, PCP clients MUST ensure that port set mapping 557 requests do not inadvertently overlap. For example, a host's 558 operating system could include a central PCP client process through 559 which port set mapping requests would be arbitrated, Alternatively, 560 individual PCP clients running on the same host would be required to 561 acquire the internal ports from the operating system (e.g., a call to 562 the bind() function from the BSD API) before trying to map them with 563 PCP. 565 6.4. What should a PCP client do when it receives fewer ports than 566 requested? 568 Suppose a PCP client asks for 16 ports and receives 8. What should 569 it do? Should it consider this a final answer? Should it try a 570 second request, asking for 8 more ports? Should it fall back to 8 571 individual MAP requests? This document does not try to answer those 572 questions, but describes issues to be considered when doing so. 574 First, the PCP server has decided to allocate 8 ports for some 575 reason. It may be that allocation sizes have been limited by the PCP 576 server's administrator. It may be that the PCP client has reached a 577 quota. It may be that these 8 ports were the last contiguous ones 578 available. Depending on the reason, asking for more ports may or may 579 not be likely to actually yield more ports. However, the PCP client 580 has no way of knowing. 582 Second, not all PCP clients asking for N ports actually need all N 583 ports to function correctly. For example, a DNS resolver could ask 584 for N ports to be used for source port randomization. If fewer than 585 N ports are received, the DNS resolver will still work correctly, but 586 source port randomization will be slightly less efficient, having 587 fewer bits to play with. In that case, it would not make much sense 588 to ask for more ports. 590 Finally, asking for more ports could be considered abuse. External 591 ports are a resource that is to be shared among multiple PCP clients. 592 A PCP client trying to obtain more than its fair share could trigger 593 countermeasures according to local policy. 595 In conclusion, it is expected that for most applications, asking for 596 more ports would not yield benefits justifying the additional costs. 598 7. Security Considerations 600 The security considerations discussed in [RFC6887] apply to this 601 extension. 603 As described in Section 4.4.1, a single PCP request using the 604 PORT_SET option may result in multiple responses. For this to happen 605 it is necessary that the request contain the nonce associated to 606 multiple mappings on the server. Therefore, an on-path attacker 607 could use an eavesdropped nonce to mount an amplification attack. 608 Use of PCP authentication ([RFC6887], Section 18) eliminates this 609 attack vector. 611 8. IANA Considerations 613 IANA has allocated value TBD (note to IANA: to be allocated from the 614 range 128-191) in the "PCP Options" registry at http://www.iana.org/ 615 assignments/pcp-parameters for the new PCP option defined in 616 Section 4. 618 9. Contributors 620 The following are extended authors who contributed to the effort: 622 Yunqing Chen 624 China Telecom 626 Room 502, No.118, Xizhimennei Street 628 Beijing 100035 630 P.R.China 632 Chongfeng Xie 634 China Telecom 636 Room 502, No.118, Xizhimennei Street 638 Beijing 100035 640 P.R.China 642 Yong Cui 644 Tsinghua University 646 Beijing 100084 648 P.R.China 650 Phone: +86-10-62603059 652 Email: yong@csnet1.cs.tsinghua.edu.cn 654 Qi Sun 656 Tsinghua University 658 Beijing 100084 659 P.R.China 661 Phone: +86-10-62785822 663 Email: sunqibupt@gmail.com 665 Gabor Bajko 667 Nokia 669 Email: gabor.bajko@nokia.com 671 Xiaohong Deng 673 France Telecom 675 Email: xiaohong.deng@orange-ftgroup.com 677 10. Acknowledgements 679 The authors would like to show sincere appreciation to Alain Durand, 680 Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam 681 Hartman, Stuart Cheshire, Ted Lemon, and Yoshihiro Ohba, for their 682 useful comments and suggestions. 684 11. References 686 11.1. Normative References 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, March 1997. 691 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 692 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 693 2013. 695 11.2. Informative References 697 [I-D.ietf-softwire-lw4over6] 698 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 699 I. Farrer, "Lightweight 4over6: An Extension to the DS- 700 Lite Architecture", draft-ietf-softwire-lw4over6-03 (work 701 in progress), November 2013. 703 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 704 A., Peterson, J., Sparks, R., Handley, M., and E. 705 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 706 June 2002. 708 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 709 Jacobson, "RTP: A Transport Protocol for Real-Time 710 Applications", STD 64, RFC 3550, July 2003. 712 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 713 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 714 RFC 4787, January 2007. 716 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 717 and H. Ashida, "Common Requirements for Carrier-Grade NATs 718 (CGNs)", BCP 127, RFC 6888, April 2013. 720 Authors' Addresses 722 Qiong Sun 723 China Telecom 724 P.R.China 726 Phone: 86 10 58552936 727 Email: sunqiong@ctbri.com.cn 729 Mohamed Boucadair 730 France Telecom 731 Rennes 35000 732 France 734 Email: mohamed.boucadair@orange.com 736 Senthil Sivakumar 737 Cisco Systems 738 7100-8 Kit Creek Road 739 Research Triangle Park, North Carolina 27709 740 USA 742 Phone: +1 919 392 5158 743 Email: ssenthil@cisco.com 745 Cathy Zhou 746 Huawei Technologies 747 Bantian, Longgang District 748 Shenzhen 518129 749 P.R. China 751 Email: cathy.zhou@huawei.com 752 Tina Tsou 753 Huawei Technologies (USA) 754 2330 Central Expressway 755 Santa Clara, CA 95050 756 USA 758 Phone: +1 408 330 4424 759 Email: Tina.Tsou.Zouting@huawei.com 761 Simon Perreault 762 Quebec, QC 763 Canada 765 Email: simon@per.reau.lt