idnits 2.17.1 draft-ietf-pcp-port-set-06.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 (July 21, 2014) is 3539 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: January 22, 2015 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 July 21, 2014 16 Port Control Protocol (PCP) Extension for Port Set Allocation 17 draft-ietf-pcp-port-set-06 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 January 22, 2015. 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . 9 75 5.3. Resolving Overlap . . . . . . . . . . . . . . . . . . . . 10 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? . . . . . . . . . . . . . . . . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 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 Server-side efficiency: Some PCP-controlled devices can allocate 160 port sets in a manner such that data passing through the device is 161 processed much more efficiently than the equivalent using 162 individual port allocations. For example, a CGN having a "bulk" 163 port allocation scheme (see [RFC6888] section 5) often has this 164 property. 166 Server-side scalability: The number of state table entries in PCP- 167 controlled devices is often a limiting factor. Allocating port 168 sets in a single request can result in a single mapping entry 169 being used, therefore allowing greater scalability. 171 Therefore, while it is functionally possible to obtain the same 172 results using plain MAP, the extension proposed in this document 173 allows greater efficiency, scalability, and simplicity, while 174 lowering latency and necessary network traffic. 176 In addition, PORT_SET supports parity preservation. Some protocols 177 (e.g. RTP [RFC3550]) assign meaning to a port number's parity. When 178 mapping sets of ports for the purpose of using such kind of protocol, 179 preserving parity can be necessary. 181 3. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 4. The PORT_SET Option 189 Option Name: PORT_SET 191 Number: TBD 192 Purpose: To map sets of ports. 194 Valid for Opcodes: MAP 196 Length: 5 bytes 198 May appear in: Both requests and responses 200 Maximum occurrences: 1 202 The PORT_SET Option indicates that the PCP client wishes to reserve a 203 set of ports. The requested number of ports in that set is indicated 204 in the option. 206 Note that the option number is in the "optional to process" range 207 (128-255), meaning that a MAP request with a PORT_SET option will be 208 interpreted by a PCP server that does not support PORT_SET as a 209 single-port MAP request, as if the PORT_SET option was absent. 211 The PORT_SET Option is formatted as shown in Figure 1. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |Option Code=TBD| Reserved | Option Length=5 | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Port Set Size | First Internal Port | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Reserved |P| 221 +-+-+-+-+-+-+-+-+ 223 Figure 1: PORT_SET Option 225 The fields are as follows: 227 Port Set Size: Number of ports requested. MUST NOT be zero. 229 First Internal Port: In a request, this field MUST be set equal to 230 the Internal Port field in the MAP opcode by the PCP client. In a 231 response, this field indicates the first internal port of the port 232 set mapped by the PCP server, which may differ from the value sent 233 in the request. That is to be contrasted to the Internal Port 234 field, which by necessity is always identical in matched requests 235 and responses. 237 Reserved: MUST be set to zero when sending, MUST be ignored when 238 receiving. 240 P: 1 if parity preservation is requested, 0 otherwise. See 241 [RFC4787], Section 4.2.2. 243 The Internal Port Set is defined as being the range of Port Set Size 244 ports starting from the First Internal Port. The External Port Set 245 is respectively defined as being the range of Port Set Size ports 246 starting from the Assigned External Port. The two ranges always have 247 the same size (i.e., the Port Set Size returned by the PCP server). 249 4.1. Client Behavior 251 To retrieve a set of ports, the PCP client adds a PORT_SET option to 252 its PCP MAP request. If port preservation is required, the PCP 253 Client MUST set the parity bit (to 1) to ask the PCP server to 254 preserve the port parity. 256 The PCP Client MUST NOT include more than one PORT_SET option in a 257 MAP request. If several port sets are needed, the PCP client MUST 258 issue separate MAP requests, each potentially including a PORT_SET 259 option. These individual MAP requests MUST include distinct Internal 260 Port. 262 If the PCP Client does not know the exact number of ports it 263 requires, it MAY then set the Port Set Size to 0xffff, indicating 264 that it is willing to accept as many ports as the PCP server can 265 offer. 267 When the PCP-controlled device supports multiple port-sets delegation 268 for a given PCP client, the PCP client MAY re-initiate a PCP request 269 to get another port set when it has exhausted all the ports within 270 the port-set. 272 4.2. Server Behavior 274 In addition to regular MAP request processing, the following checks 275 are made upon receipt of a PORT_SET option with non-zero Requested 276 Lifetime: 278 o If multiple PORT_SET options are present in a single MAP request, 279 a MALFORMED_OPTION error is returned. 281 o If the Port Set Size is zero, a MALFORMED_OPTION error is 282 returned. 284 If the PREFER_FAILURE option is present and the PCP server is unable 285 to map all ports in the requested External Port Set or is unable to 286 preserve parity (P = 1), the CANNOT_PROVIDE_EXTERNAL error is 287 returned. 289 If the PREFER_FAILURE option is absent, the PCP server MAY map fewer 290 ports than the value of Port Set Size from the request. It MUST NOT 291 map more ports than the PCP client asked for. Internal ports outside 292 the range of Port Set Size ports starting from the Internal Port MUST 293 NOT be mapped by the PCP server. 295 If the requested port set cannot be fully satisfied, the PCP server 296 SHOULD map as many ports as possible, and SHOULD map at least one 297 port (which is the same behavior as if Port Set Size is set to 1). 299 If the PCP server ends up mapping only a single port, for any reason, 300 the PORT_SET option MUST NOT be present in the response. 302 If the PREFER_FAILURE option is absent and port parity preservation 303 is requested (P = 1), the PCP server MAY preserve port parity. In 304 that case, the External Port is set to a value having the same parity 305 as the First Internal Port. 307 If the mapping is successful, the MAP response's Assigned External 308 Port is set to the first port in the External Port Set, and the 309 PORT_SET option's Port Set Size is set to number of ports in the 310 mapped port set. The First Internal Port field is set to the first 311 port in the Internal Port Set. 313 4.3. Absence of Capability Discovery 315 There is intentionally no port set capability discovery mechanism. A 316 PCP client that wishes to make use of a port set unconditionally 317 includes the PORT_SET option. If no PORT_SET option is present in 318 the response, the PCP client cannot conclude that the PCP server does 319 not support the PORT_SET option. It may just be that the PCP server 320 does support PORT_SET but decided to allocate only a single port, for 321 reasons that are its own. If the client wishes to obtain more ports, 322 it MAY send additional MAP requests (see Section 6.4), which the PCP 323 server may or may not grant according to local policy. A PCP client 324 MUST NOT try to discover whether a PCP server has PORT_SET capability 325 or not. 327 If port set capability is added to or removed from a running PCP 328 server, the server MAY reset its Epoch time and send an ANNOUNCE 329 message as described in the PCP specification ([RFC6887], 330 Section 14.1). This causes PCP clients to re-try, and those using 331 PORT_SET will now receive a different response. 333 4.4. Port Set Renewal and Deletion 334 Port set mappings are renewed and deleted as a single entity. That 335 is, the lifetime of all port mappings in the set is set to the 336 Assigned Lifetime at once. 338 A PCP client attempting to refresh or delete a port set mapping MUST 339 include the PORT_SET option in its request. 341 4.4.1. Overlap Conditions 343 Port set map requests can overlap with existing single port or port 344 set mappings. This can happen either by mistake or after a PCP 345 client becomes out of sync with server state. 347 If a PCP server receives a MAP request, with or without a PORT_SET 348 option, that tries to map one or more internal ports or port sets 349 belonging to already existing mappings, then the request is 350 considered to be a refresh request applying those mappings. Each of 351 the matching port or port set mappings is processed independently, as 352 if a separate refresh request had been received. The processing is 353 as described in Section 15 of [RFC6887]. The PCP server sends a 354 Mapping Update message for each of the mappings. 356 5. Examples 358 5.1. Simple Request on NAT44 360 An application requires a range of 100 IPv4 UDP ports to be mapped to 361 itself. The application running on the host has created sockets 362 bound to IPv4 UDP ports 50,000 to 50,099 for this purpose. It does 363 not care about which external port numbers are allocated. The PCP 364 client sends a PCP request with the following parameters over IPv4: 366 o MAP opcode 368 Mapping Nonce: 370 Protocol: 17 372 Internal Port: 50,000 374 Suggested External Port: 0 376 Suggested External IP Address: ::ffff:0.0.0.0 378 o PORT_SET Option 380 Port Set Size: 100 381 First Internal Port: 50,000 383 P: 0 385 The PCP server is unable to fulfill the request fully: it is 386 configured by local policy to only allocate 32 ports per user. Since 387 the PREFER_FAILURE option is absent from the request, it decides to 388 map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to 389 internal ports 50,000 to 50,031. After setting up the mapping in the 390 NAT44 device it controls, it replies with the following PCP response: 392 o MAP opcode 394 Mapping Nonce: 396 Protocol: 17 398 Internal Port: 50,000 400 Assigned External Port: 37,056 402 Assigned External IP Address: ::ffff:192.0.2.3 404 o PORT_SET Option 406 Port Set Size: 32 408 First Internal Port: 50,000 410 P: 0 412 Upon receiving this response, the host decides that 32 ports is good 413 enough for its purposes. It closes sockets bound to ports 50,032 to 414 50,099, sets up a refresh timer, and starts using the port range it 415 has just been assigned. 417 5.2. Stateless Mapping Discovery 419 A host wants to discover a stateless NAT44 mapping pointing to it. 420 To do so, it sends the following request over IPv4: 422 o MAP opcode 424 Mapping Nonce: 426 Protocol: 0 428 Internal Port: 1 429 Suggested External Port: 0 431 Suggested External IP Address: ::ffff:0.0.0.0 433 o PORT_SET Option 435 Port Set Size: 65,535 437 First Internal Port: 1 439 P: 0 441 The PCP server sends the following response: 443 o MAP opcode 445 Mapping Nonce: 447 Protocol: 0 449 Internal Port: 1 451 Assigned External Port: 26,624 453 Assigned External IP Address: ::ffff:192.0.2.5 455 o PORT_SET Option 457 Port Set Size: 2048 459 First Internal Port: 26,624 461 P: 0 463 From this response, the host understands that a 2048-port stateless 464 mapping is pointing to itself, starting from port 26,624 on external 465 IP address 192.0.2.5. 467 5.3. Resolving Overlap 469 This example relates to Section 4.4.1. 471 Suppose internal port 100 is mapped to external port 100 and port set 472 101-199 is mapped to external port set 201-299. The PCP server 473 receives a MAP request with Internal Port = 100, External Port = 0, 474 and a PORT_SET option with Port Set Size = 100. The request's 475 Mapping Nonce is equal to those of the existing single port and port 476 set mappings. This request is therefore treated as two refresh 477 requests, the first one applying to the single port mapping and the 478 second one applying to the port set mapping. The PCP server updates 479 both mapping's lifetimes as usual then sends two responses: the first 480 one contains Internal Port = 100, External Port = 100, and no 481 PORT_SET option, while the second one contains Internal Port = 101, 482 External Port = 201, and a PORT_SET option with Port Set Size = 99. 484 6. Operational Considerations 486 6.1. Limits and Quotas 488 It is up to the PCP server to determine the port-set quota, if any, 489 for each PCP client. 491 If the PCP server is configured to allocate multiple port-set 492 allocations for one subscriber, the same Assigned External IP Address 493 SHOULD be assigned to the subscriber in multiple port-set responses. 495 To optimize the number of mapping entries maintained by the PCP 496 server, it is RECOMMENDED to configure the PCP server to assign the 497 maximum allowed port set size in a single response. This policy 498 SHOULD be configurable. 500 6.2. High Availability 502 The failover mechanism in MAP [section 14 in [RFC6887]] can also be 503 applied to port sets. 505 6.3. Idempotence 507 A core, desirable property of the PCP protocol is idempotence. In a 508 nutshell, requests produce the same results whether they are executed 509 once or multiple times. This property is preserved with the PORT_SET 510 attribute, with the following caveat: the order in which the PCP 511 server receives requests with overlapping Internal Port Sets will 512 affect the mappings being created and the responses received. 514 For example suppose these two requests are sent by a PCP client: 516 Request A: Internal Port Set 1-10 518 Request B: Internal Port Set 5-14 520 The PCP server's actions will depend on which request is received 521 first. Suppose that A is received before B: 523 Upon reception of A: Internal ports 1-10 are mapped. A success 524 response containing the following fields is sent: 526 Internal Port: 1 528 First Internal Port: 1 530 Port Set Size: 10 532 Upon reception of B: The request matches mapping A. The request is 533 interpreted as a refresh request for mapping A, and a response 534 containing the following fields is sent: 536 Internal Port: 5 538 First Internal Port: 1 540 Port Set Size: 10 542 If the order of reception is reversed (B before A), the created 543 mapping will be different, and the First Internal Port in both 544 responses would then be 5. 546 To avoid surprises, PCP clients MUST ensure that port set mapping 547 requests do not inadvertently overlap. For example, a host's 548 operating system could include a central PCP client process through 549 which port set mapping requests would be arbitrated. Alternatively, 550 individual PCP clients running on the same host would be required to 551 acquire the internal ports from the operating system (e.g., a call to 552 the bind() function from the BSD API) before trying to map them with 553 PCP. 555 6.4. What should a PCP client do when it receives fewer ports than 556 requested? 558 Suppose a PCP client asks for 16 ports and receives 8. What should 559 it do? Should it consider this a final answer? Should it try a 560 second request, asking for 8 more ports? Should it fall back to 8 561 individual MAP requests? This document leaves the answers to be 562 implementation-specific, but describes issues to be considered when 563 answering them. 565 First, the PCP server has decided to allocate 8 ports for some 566 reason. It may be that allocation sizes have been limited by the PCP 567 server's administrator. It may be that the PCP client has reached a 568 quota. It may be that these 8 ports were the last contiguous ones 569 available. Depending on the reason, asking for more ports may or may 570 not be likely to actually yield more ports. However, the PCP client 571 has no way of knowing. 573 Second, not all PCP clients asking for N ports actually need all N 574 ports to function correctly. For example, a DNS resolver could ask 575 for N ports to be used for source port randomization. If fewer than 576 N ports are received, the DNS resolver will still work correctly, but 577 source port randomization will be slightly less efficient, having 578 fewer bits to play with. In that case, it would not make much sense 579 to ask for more ports. 581 Finally, asking for more ports could be considered abuse. External 582 ports are a resource that is to be shared among multiple PCP clients. 583 A PCP client trying to obtain more than its fair share could trigger 584 countermeasures according to local policy. 586 In conclusion, it is expected that for most applications, asking for 587 more ports would not yield benefits justifying the additional costs. 589 7. Security Considerations 591 The security considerations discussed in [RFC6887] apply to this 592 extension. 594 As described in Section 4.4.1, a single PCP request using the 595 PORT_SET option may result in multiple responses. For this to happen 596 it is necessary that the request contain the nonce associated to 597 multiple mappings on the server. Therefore, an on-path attacker 598 could use an eavesdropped nonce to mount an amplification attack. 599 Use of PCP authentication ([RFC6887], Section 18) eliminates this 600 attack vector. 602 8. IANA Considerations 604 IANA has allocated value TBD (note to IANA: to be allocated from the 605 range 128-191) in the "PCP Options" registry at http://www.iana.org/ 606 assignments/pcp-parameters for the new PCP option defined in 607 Section 4. 609 9. Contributors 611 The following are extended authors who contributed to the effort: 613 Yunqing Chen 615 China Telecom 617 Room 502, No.118, Xizhimennei Street 619 Beijing 100035 620 P.R.China 622 Chongfeng Xie 624 China Telecom 626 Room 502, No.118, Xizhimennei Street 628 Beijing 100035 630 P.R.China 632 Yong Cui 634 Tsinghua University 636 Beijing 100084 638 P.R.China 640 Phone: +86-10-62603059 642 Email: yong@csnet1.cs.tsinghua.edu.cn 644 Qi Sun 646 Tsinghua University 648 Beijing 100084 650 P.R.China 652 Phone: +86-10-62785822 654 Email: sunqibupt@gmail.com 656 Gabor Bajko 658 Nokia 660 Email: gabor.bajko@nokia.com 662 Xiaohong Deng 664 France Telecom 666 Email: xiaohong.deng@orange-ftgroup.com 668 10. Acknowledgements 670 The authors would like to show sincere appreciation to Alain Durand, 671 Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam 672 Hartman, Stuart Cheshire, Ted Lemon, and Yoshihiro Ohba, for their 673 useful comments and suggestions. 675 11. References 677 11.1. Normative References 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 683 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 684 2013. 686 11.2. Informative References 688 [I-D.ietf-softwire-lw4over6] 689 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 690 I. Farrer, "Lightweight 4over6: An Extension to the DS- 691 Lite Architecture", draft-ietf-softwire-lw4over6-03 (work 692 in progress), November 2013. 694 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 695 A., Peterson, J., Sparks, R., Handley, M., and E. 696 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 697 June 2002. 699 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 700 Jacobson, "RTP: A Transport Protocol for Real-Time 701 Applications", STD 64, RFC 3550, July 2003. 703 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 704 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 705 RFC 4787, January 2007. 707 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 708 and H. Ashida, "Common Requirements for Carrier-Grade NATs 709 (CGNs)", BCP 127, RFC 6888, April 2013. 711 Authors' Addresses 713 Qiong Sun 714 China Telecom 715 P.R.China 717 Phone: 86 10 58552936 718 Email: sunqiong@ctbri.com.cn 720 Mohamed Boucadair 721 France Telecom 722 Rennes 35000 723 France 725 Email: mohamed.boucadair@orange.com 727 Senthil Sivakumar 728 Cisco Systems 729 7100-8 Kit Creek Road 730 Research Triangle Park, North Carolina 27709 731 USA 733 Phone: +1 919 392 5158 734 Email: ssenthil@cisco.com 736 Cathy Zhou 737 Huawei Technologies 738 Bantian, Longgang District 739 Shenzhen 518129 740 P.R. China 742 Email: cathy.zhou@huawei.com 744 Tina Tsou 745 Huawei Technologies (USA) 746 2330 Central Expressway 747 Santa Clara, CA 95050 748 USA 750 Phone: +1 408 330 4424 751 Email: Tina.Tsou.Zouting@huawei.com 752 Simon Perreault 753 Jive Communications 754 Quebec, QC 755 Canada 757 Email: sperreault@jive.com