idnits 2.17.1 draft-ietf-pcp-port-set-07.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 (November 9, 2014) is 3449 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: May 13, 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 November 9, 2014 16 Port Control Protocol (PCP) Extension for Port Set Allocation 17 draft-ietf-pcp-port-set-07 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 May 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . 4 64 2. The need for PORT_SET . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. The PORT_SET Option . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . 12 79 6.3. Idempotence . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.4. What should a PCP client do when it receives fewer 81 ports 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 . . . . . . . . . . . . . . . . . . 16 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 193 Purpose: To map sets of ports. 195 Valid for Opcodes: MAP 197 Length: 5 bytes 199 May appear in: Both requests and responses 201 Maximum occurrences: 1 203 The PORT_SET Option indicates that the PCP client wishes to reserve a 204 set of ports. The requested number of ports in that set is indicated 205 in the option. 207 Note that the option number is in the "optional to process" range 208 (128-255), meaning that a MAP request with a PORT_SET option will be 209 interpreted by a PCP server that does not support PORT_SET as a 210 single-port MAP request, as if the PORT_SET option was absent. 212 The PORT_SET Option is formatted as shown in Figure 1. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |Option Code=TBD| Reserved | Option Length=5 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Port Set Size | First Internal Port | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Reserved |P| 222 +-+-+-+-+-+-+-+-+ 224 Figure 1: PORT_SET Option 226 The fields are as follows: 228 Port Set Size: Number of ports requested. MUST NOT be zero. 230 First Internal Port: In a request, this field MUST be set equal to 231 the Internal Port field in the MAP opcode by the PCP client. In a 232 response, this field indicates the first internal port of the port 233 set mapped by the PCP server, which may differ from the value sent 234 in the request. That is to be contrasted to the Internal Port 235 field, which by necessity is always identical in matched requests 236 and responses. 238 Reserved: MUST be set to zero when sending, MUST be ignored when 239 receiving. 241 P: 1 if parity preservation is requested, 0 otherwise. See 242 [RFC4787], Section 4.2.2. 244 The Internal Port Set is defined as being the range of Port Set Size 245 ports starting from the First Internal Port. The External Port Set 246 is respectively defined as being the range of Port Set Size ports 247 starting from the Assigned External Port. The two ranges always have 248 the same size (i.e., the Port Set Size returned by the PCP server). 250 The Suggested External Port corresponds to the first port in the 251 suggested External Port Set. Its purpose is for clients to be able to 252 regenerate previous mappings after state loss. When such an event 253 happens, clients may attempt to regenerate identical mappings by 254 suggesting the same External Port Set as before the state loss. Note 255 that there is no guarantee that the allocated External Port Set will 256 be the one suggested by the client. In particular, the 257 PREFER_FAILURE option MUST NOT be present in a request that contains 258 a PORT_SET option. 260 4.1. Client Behavior 262 To retrieve a set of ports, the PCP client adds a PORT_SET option to 263 its PCP MAP request. If port preservation is required, the PCP 264 Client MUST set the parity bit (to 1) to ask the PCP server to 265 preserve the port parity. 267 The PCP Client MUST NOT include more than one PORT_SET option in a 268 MAP request. If several port sets are needed, the PCP client MUST 269 issue separate MAP requests, each potentially including a PORT_SET 270 option. These individual MAP requests MUST include distinct Internal 271 Port. 273 If the PCP Client does not know the exact number of ports it 274 requires, it MAY then set the Port Set Size to 0xffff, indicating 275 that it is willing to accept as many ports as the PCP server can 276 offer. 278 When the PCP-controlled device supports multiple port-sets delegation 279 for a given PCP client, the PCP client MAY re-initiate a PCP request 280 to get another port set when it has exhausted all the ports within 281 the port-set. 283 4.2. Server Behavior 285 In addition to regular MAP request processing, the following checks 286 are made upon receipt of a PORT_SET option with non-zero Requested 287 Lifetime: 289 o If multiple PORT_SET options are present in a single MAP request, 290 a MALFORMED_OPTION error is returned. 292 o If the Port Set Size is zero, a MALFORMED_OPTION error is 293 returned. 295 PREFER_FAILURE MUST NOT appear in a request with PORT_SET option. 296 The PCP server MAY map fewer ports than the value of Port Set Size 297 from the request. It MUST NOT map more ports than the PCP client 298 asked for. Internal ports outside the range of Port Set Size ports 299 starting from the Internal Port MUST NOT be mapped by the PCP server. 301 If the requested port set cannot be fully satisfied, the PCP server 302 SHOULD map as many ports as possible, and SHOULD map at least one 303 port (which is the same behavior as if Port Set Size is set to 1). 305 If the PCP server ends up mapping only a single port, for any reason, 306 the PORT_SET option MUST NOT be present in the response. 308 If the port parity preservation is requested (P = 1), the PCP server 309 MAY preserve port parity. In that case, the External Port is set to 310 a value having the same parity as the First Internal Port. 312 If the mapping is successful, the MAP response's Assigned External 313 Port is set to the first port in the External Port Set, and the 314 PORT_SET option's Port Set Size is set to number of ports in the 315 mapped port set. The First Internal Port field is set to the first 316 port in the Internal Port Set. 318 4.3. Absence of Capability Discovery 320 There is intentionally no port set capability discovery mechanism. A 321 PCP client that wishes to make use of a port set unconditionally 322 includes the PORT_SET option. If no PORT_SET option is present in 323 the response, the PCP client cannot conclude that the PCP server does 324 not support the PORT_SET option. It may just be that the PCP server 325 does support PORT_SET but decided to allocate only a single port, for 326 reasons that are its own. If the client wishes to obtain more ports, 327 it MAY send additional MAP requests (see Section 6.4), which the PCP 328 server may or may not grant according to local policy. A PCP client 329 MUST NOT try to discover whether a PCP server has PORT_SET capability 330 or not. 332 If port set capability is added to or removed from a running PCP 333 server, the server MAY reset its Epoch time and send an ANNOUNCE 334 message as described in the PCP specification ([RFC6887], Section 335 14.1). This causes PCP clients to re-try, and those using PORT_SET 336 will now receive a different response. 338 4.4. Port Set Renewal and Deletion 340 Port set mappings are renewed and deleted as a single entity. That 341 is, the lifetime of all port mappings in the set is set to the 342 Assigned Lifetime at once. 344 A PCP client attempting to refresh or delete a port set mapping MUST 345 include the PORT_SET option in its request. A PCP client MUST NOT 346 send a PORT_SET option for single-port refreshes. 348 4.4.1. Overlap Conditions 350 Port set map requests can overlap with existing single port or port 351 set mappings. This can happen either by mistake or after a PCP 352 client becomes out of sync with server state. 354 If a PCP server receives a MAP request, with or without a PORT_SET 355 option, that tries to map one or more internal ports or port sets 356 belonging to already existing mappings, then the request is 357 considered to be a refresh request applying those mappings. Each of 358 the matching port or port set mappings is processed independently, as 359 if a separate refresh request had been received. The processing is 360 as described in Section 15 of [RFC6887]. The PCP server sends a 361 Mapping Update message for each of the mappings. 363 5. Examples 365 5.1. Simple Request on NAT44 367 An application requires a range of 100 IPv4 UDP ports to be mapped to 368 itself. The application running on the host has created sockets 369 bound to IPv4 UDP ports 50,000 to 50,099 for this purpose. It does 370 not care about which external port numbers are allocated. The PCP 371 client sends a PCP request with the following parameters over IPv4: 373 o MAP opcode 375 Mapping Nonce: 377 Protocol: 17 379 Internal Port: 50,000 381 Suggested External Port: 0 383 Suggested External IP Address: ::ffff:0.0.0.0 385 o PORT_SET Option 387 Port Set Size: 100 389 First Internal Port: 50,000 391 P: 0 393 The PCP server is unable to fulfill the request fully: it is 394 configured by local policy to only allocate 32 ports per user. Since 395 the PREFER_FAILURE option is absent from the request, it decides to 396 map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to 397 internal ports 50,000 to 50,031. After setting up the mapping in the 398 NAT44 device it controls, it replies with the following PCP response: 400 o MAP opcode 402 Mapping Nonce: 404 Protocol: 17 406 Internal Port: 50,000 408 Assigned External Port: 37,056 410 Assigned External IP Address: ::ffff:192.0.2.3 412 o PORT_SET Option 414 Port Set Size: 32 415 First Internal Port: 50,000 417 P: 0 419 Upon receiving this response, the host decides that 32 ports is good 420 enough for its purposes. It closes sockets bound to ports 50,032 to 421 50,099, sets up a refresh timer, and starts using the port range it 422 has just been assigned. 424 5.2. Stateless Mapping Discovery 426 A host wants to discover a stateless NAT44 mapping pointing to it. 427 To do so, it sends the following request over IPv4: 429 o MAP opcode 431 Mapping Nonce: 433 Protocol: 0 435 Internal Port: 1 437 Suggested External Port: 0 439 Suggested External IP Address: ::ffff:0.0.0.0 441 o PORT_SET Option 443 Port Set Size: 65,535 445 First Internal Port: 1 447 P: 0 449 The PCP server sends the following response: 451 o MAP opcode 453 Mapping Nonce: 455 Protocol: 0 457 Internal Port: 1 459 Assigned External Port: 26,624 460 Assigned External IP Address: ::ffff:192.0.2.5 462 o PORT_SET Option 464 Port Set Size: 2048 466 First Internal Port: 26,624 468 P: 0 470 From this response, the host understands that a 2048-port stateless 471 mapping is pointing to itself, starting from port 26,624 on external 472 IP address 192.0.2.5. 474 5.3. Resolving Overlap 476 This example relates to Section 4.4.1. 478 Suppose internal port 100 is mapped to external port 100 and port set 479 101-199 is mapped to external port set 201-299. The PCP server 480 receives a MAP request with Internal Port = 100, External Port = 0, 481 and a PORT_SET option with Port Set Size = 100. The request's 482 Mapping Nonce is equal to those of the existing single port and port 483 set mappings. This request is therefore treated as two refresh 484 requests, the first one applying to the single port mapping and the 485 second one applying to the port set mapping. The PCP server updates 486 both mapping's lifetimes as usual then sends two responses: the first 487 one contains Internal Port = 100, External Port = 100, and no 488 PORT_SET option, while the second one contains Internal Port = 101, 489 External Port = 201, and a PORT_SET option with Port Set Size = 99. 491 6. Operational Considerations 493 6.1. Limits and Quotas 495 It is up to the PCP server to determine the port-set quota, if any, 496 for each PCP client. 498 If the PCP server is configured to allocate multiple port-set 499 allocations for one subscriber, the same Assigned External IP Address 500 SHOULD be assigned to the subscriber in multiple port-set responses. 502 To optimize the number of mapping entries maintained by the PCP 503 server, it is RECOMMENDED to configure the PCP server to assign the 504 maximum allowed port set size in a single response. This policy 505 SHOULD be configurable. 507 6.2. High Availability 509 The failover mechanism in MAP [section 14 in [RFC6887]] can also be 510 applied to port sets. 512 6.3. Idempotence 514 A core, desirable property of the PCP protocol is idempotence. In a 515 nutshell, requests produce the same results whether they are executed 516 once or multiple times. This property is preserved with the PORT_SET 517 attribute, with the following caveat: the order in which the PCP 518 server receives requests with overlapping Internal Port Sets will 519 affect the mappings being created and the responses received. 521 For example suppose these two requests are sent by a PCP client: 523 Request A: Internal Port Set 1-10 525 Request B: Internal Port Set 5-14 527 The PCP server's actions will depend on which request is received 528 first. Suppose that A is received before B: 530 Upon reception of A: Internal ports 1-10 are mapped. A success 531 response containing the following fields is sent: 533 Internal Port: 1 535 First Internal Port: 1 537 Port Set Size: 10 539 Upon reception of B: The request matches mapping A. The request is 540 interpreted as a refresh request for mapping A, and a response 541 containing the following fields is sent: 543 Internal Port: 5 545 First Internal Port: 1 547 Port Set Size: 10 549 If the order of reception is reversed (B before A), the created 550 mapping will be different, and the First Internal Port in both 551 responses would then be 5. 553 To avoid surprises, PCP clients MUST ensure that port set mapping 554 requests do not inadvertently overlap. For example, a host's 555 operating system could include a central PCP client process through 556 which port set mapping requests would be arbitrated. Alternatively, 557 individual PCP clients running on the same host would be required to 558 acquire the internal ports from the operating system (e.g., a call to 559 the bind() function from the BSD API) before trying to map them with 560 PCP. 562 6.4. What should a PCP client do when it receives fewer ports than 563 requested? 565 Suppose a PCP client asks for 16 ports and receives 8. What should 566 it do? Should it consider this a final answer? Should it try a 567 second request, asking for 8 more ports? Should it fall back to 8 568 individual MAP requests? This document leaves the answers to be 569 implementation-specific, but describes issues to be considered when 570 answering them. 572 First, the PCP server has decided to allocate 8 ports for some 573 reason. It may be that allocation sizes have been limited by the PCP 574 server's administrator. It may be that the PCP client has reached a 575 quota. It may be that these 8 ports were the last contiguous ones 576 available. Depending on the reason, asking for more ports may or may 577 not be likely to actually yield more ports. However, the PCP client 578 has no way of knowing. 580 Second, not all PCP clients asking for N ports actually need all N 581 ports to function correctly. For example, a DNS resolver could ask 582 for N ports to be used for source port randomization. If fewer than 583 N ports are received, the DNS resolver will still work correctly, but 584 source port randomization will be slightly less efficient, having 585 fewer bits to play with. In that case, it would not make much sense 586 to ask for more ports. 588 Finally, asking for more ports could be considered abuse. External 589 ports are a resource that is to be shared among multiple PCP clients. 590 A PCP client trying to obtain more than its fair share could trigger 591 countermeasures according to local policy. 593 In conclusion, it is expected that for most applications, asking for 594 more ports would not yield benefits justifying the additional costs. 596 7. Security Considerations 598 The security considerations discussed in [RFC6887] apply to this 599 extension. 601 As described in Section 4.4.1, a single PCP request using the 602 PORT_SET option may result in multiple responses. For this to happen 603 it is necessary that the request contain the nonce associated to 604 multiple mappings on the server. Therefore, an on-path attacker 605 could use an eavesdropped nonce to mount an amplification attack. 606 Use of PCP authentication ([RFC6887], Section 18) eliminates this 607 attack vector. 609 8. IANA Considerations 611 IANA has allocated value TBD (note to IANA: to be allocated from the 612 range 128-191) in the "PCP Options" registry at 613 http://www.iana.org/assignments/pcp-parameters for the new PCP option 614 defined in Section 4. 616 9. Contributors 618 The following are extended authors who contributed to the effort: 620 Yunqing Chen 622 China Telecom 624 Room 502, No.118, Xizhimennei Street 626 Beijing 100035 628 P.R.China 630 Chongfeng Xie 632 China Telecom 634 Room 502, No.118, Xizhimennei Street 636 Beijing 100035 638 P.R.China 640 Yong Cui 642 Tsinghua University 644 Beijing 100084 646 P.R.China 647 Phone: +86-10-62603059 649 Email: yong@csnet1.cs.tsinghua.edu.cn 651 Qi Sun 653 Tsinghua University 655 Beijing 100084 657 P.R.China 659 Phone: +86-10-62785822 661 Email: sunqibupt@gmail.com 663 Gabor Bajko 665 Nokia 667 Email: gabor.bajko@nokia.com 669 Xiaohong Deng 671 France Telecom 673 Email: xiaohong.deng@orange-ftgroup.com 675 10. Acknowledgements 677 The authors would like to show sincere appreciation to Alain Durand, 678 Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam 679 Hartman, Stuart Cheshire, Ted Lemon, and Yoshihiro Ohba, for their 680 useful comments and suggestions. 682 11. References 684 11.1. Normative References 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 690 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 691 April 2013. 693 11.2. Informative References 695 [I-D.ietf-softwire-lw4over6] 696 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 697 I. Farrer, "Lightweight 4over6: An Extension to the DS- 698 Lite Architecture", draft-ietf-softwire-lw4over6-03 (work 699 in progress), November 2013. 701 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 702 A., Peterson, J., Sparks, R., Handley, M., and E. 703 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 704 June 2002. 706 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 707 Jacobson, "RTP: A Transport Protocol for Real-Time 708 Applications", STD 64, RFC 3550, July 2003. 710 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 711 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 712 RFC 4787, January 2007. 714 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 715 and H. Ashida, "Common Requirements for Carrier-Grade NATs 716 (CGNs)", BCP 127, RFC 6888, April 2013. 718 Authors' Addresses 720 Qiong Sun 721 China Telecom 722 P.R.China 724 Phone: 86 10 58552936 725 Email: sunqiong@ctbri.com.cn 727 Mohamed Boucadair 728 France Telecom 729 Rennes, 35000 730 France 732 Email: mohamed.boucadair@orange.com 733 Senthil Sivakumar 734 Cisco Systems 735 7100-8 Kit Creek Road 736 Research Triangle Park, North Carolina 27709 737 USA 739 Phone: +1 919 392 5158 740 Email: ssenthil@cisco.com 742 Cathy Zhou 743 Huawei Technologies 744 Bantian, Longgang District 745 Shenzhen 518129 746 P.R. China 748 Phone: 749 Email: cathy.zhou@huawei.com 751 Tina Tsou 752 Huawei Technologies (USA) 753 2330 Central Expressway 754 Santa Clara, CA 95050 755 USA 757 Phone: +1 408 330 4424 758 Email: Tina.Tsou.Zouting@huawei.com 760 Simon Perreault 761 Jive Communications 762 Quebec, QC 763 Canada 765 Email: sperreault@jive.com