idnits 2.17.1 draft-deng-softwire-aplusp-experiment-results-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2012) is 4431 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-intarea-shared-addressing-issues' is mentioned on line 258, but not defined == Missing Reference: 'RFC6269' is mentioned on line 601, but not defined == Missing Reference: 'ID.boucadair-port-range' is mentioned on line 665, but not defined Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X.Deng 3 Internet Draft M.Boucadair 4 Intended status: Informational France Telecom 5 Expires: September 2, 2012 Y.Lee 6 Comcast 7 X.Huang 8 Q.Zhao 9 BUPT 10 March 1, 2012 12 Implementing A+P in the provider's IPv6-only network 13 draft-deng-softwire-aplusp-experiment-results-02.txt 15 Abstract 17 This memo describes an implementation of A+P in a provider's IPv6- 18 only network. It provides details of the implementation, network 19 elements, configurations and test results as well. Besides 20 traditional port range A+P, a scattered port sets flavor of A+P is 21 also implemented to verify feasibility of offering non-continuous 22 port sets with A+P approach. 24 The test results consist of the application compatibility test, UPnP 25 1.0 extensions and UPnP 1.0 friendly port allocation for A+P, port 26 usage and BitTorrent behaviors with A+P. 28 This memo focuses on the IPv6 flavor of A+P. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 2, 2012. 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................ 3 65 2. Terminology ................................................. 3 66 3. Implementation environment ................................... 4 67 3.1. Environment Overview .................................... 4 68 3.2. Implementation and Configuration of A+P ................. 5 69 3.2.1. IPv4-Embedded IPv6 Address Format For A+P CPE ...... 6 70 3.2.2. DHCPv6 Configurations .............................. 6 71 3.2.3. Avoiding Fragmentation ............................. 6 72 3.3. Implementing non-continuous Port Sets for A+P ........... 7 73 3.3.1. Non-continuous Port Sets allocation mechanism ...... 7 74 3.3.2. IPv4-Embedded IPv6 Address Format for Non-continuous 75 Port Sets A+P CPE ....................................... 10 76 3.3.3. Customize a non-continuous Ports Set A+P NAT ...... 11 77 4. Application Tests and Experiments in A+P Environment ........ 12 78 4.1. A+P Impacts on Applications ............................ 12 79 4.2. UPnP extension experiment 80 .............................. 13 81 4.2.1. UPnP 1.0 extension ................................ 13 82 4.2.2. UPnP 1.0 friendliness attempts .................... 14 83 4.3. Port Usage of Applications ............................. 16 84 4.4. BitTorrent Behaviour in A+P ............................ 17 85 5. Security Considerations .................................... 18 86 6. IANA Considerations ........................................ 18 87 7. Conclusion ................................................. 18 88 8. References ................................................. 19 89 8.1. Normative References ................................... 19 90 8.2. Informative References ................................. 19 91 9. Additional Authors ......................................... 20 92 10. Acknowledgments ........................................... 20 94 1. Introduction 96 A+P [RFC6346] is a technique to share IPv4 addresses over IPv6-only 97 network without requiring a NAT function in the provider's network. 98 The main idea of A+P is borrowing some bits from the port number in 99 the TCP/UDP header to identify the end point. Those port numbers 100 assigned to the end point will be used by IPv4 applications. A+P can 101 facilitate network migration to IPv6-only while continue to offer 102 IPv4 connectivity to customers by tunneling IPv4 packets over IPv6- 103 only network. 105 We implemented A+P in a residential ADSL access network, where IPv6- 106 only access network is provided over PPPoE. In this memo, we first 107 describe the implementation environment including A+P IPv6 prefix 108 format and network elements configurations, then we describes the 109 test results. In particular, this memo focuses on the SMAP function 110 implementation specified in [RFC6346]. 112 For more application test results in A+P environment, please refer to 113 [draft-boucadair-behave-bittorrent-portrange-02] and [draft- 114 boucadair-port-range-01]. 116 2. Terminology 118 This memo uses the following terms: 120 o PRR: Port Range Router 122 o A+P CPE: A+P aware Customer Premise Equipment 124 3. Implementation environment 126 3.1. Environment Overview 128 public 129 addresses +----------+ 130 realm | PRR | 131 | | 132 === +----------+ 133 IPv4 ^ ^ ^ 134 | | | 135 | v v 136 | +--------------+ 137 | | PPPoE/DHCPv6 | 138 over | | Server | 139 | +--------------+ 140 | === ^ ^ 141 | IPv6 ^ | | 142 | over | | | 143 IPv6 | PPPoE | | | 144 V v | | 145 === === v v 146 ^ +----------+ 147 | | A+P | 148 | | CPE | 149 | +----------+ 150 Private | ^ ^ 151 RFC1918 | | | 152 realm | v v 153 | +----------+ 154 | | Host | 155 | | | 156 V +----------+ 158 Figure 1 : Implementation Environment 160 We developed both A+P CPE function and Port Range Router (PRR) 161 function on Linux. A+P CPE function was implemented on Linksys 162 WRT54GS router running OpenWRT 2.6.32. PRR function was implemented 163 on standard Intel based server. Figure 1 shows the high-level network 164 diagram of the test environment. 166 Figure 2 shows the configuration of A+P CPE. IPv6 prefix was 167 provisioned over PPPoE to CPE by a DHCPv6 server. In addition, it 168 also offered A+P parameters via DHCPv6 options defined in [draft- 169 boucadair-dhcpv6-shared-address-option]. 171 +--------+------------+-------+-----+------------+-----------+------+ 172 | Model | CPU Speed | Flash | RAM | Wireless | Wireless | Wired| 173 | | (MHz) | (MB) | (MB)| NIC | Standard | Ports| 174 +--------+---------- -+-------+-----+------------+-----------+------+ 175 | Linksys| 200 | 8 | 32 | Broadcom | 11g | 5 | 176 | WRT54GS| | | |(integrated)| | | 177 +--------+------------+-------+-----+------------+-----------+------+ 179 Figure 2 :Parameters of A+P CPE 181 3.2. Implementation and Configuration of A+P 183 A+P CPE uses Netfilter framework to implement the port-set restricted 184 NAT. Port set restricted NAT operation was done by iptables rules. 185 After the port restricted NAT operation, IPv4 packets were sent to a 186 TUN interface which was a virtual network interface in Linux. The TUN 187 interface is a virtual interface that performs the IPv4-in-IPv6 188 function. Using the IPv4-Embedded IPv6 address format defined in 189 section 3.2.1, an IPv4-in-IPv6 function is performed by the TUN 190 interface handler. 192 PRR bridges the IPv6 access network to the IPv4 Internet. It contains 193 two main functions: 1) IPv4-in-IPv6 encapsulation/decapsulation; 194 Similar to A+P CPE, PRR implementation leveraged the virtual TUN 195 driver handler for IPv4-in-IPv6 function. 2) Destination IPv4 address 196 and layer 4 port based routing function is responsible for routing 197 the IPv4 traffic originated from the IPv4 Internet to the Port Range 198 restricted A+P CPE. The goal of PRR is to deliver the IPv4 packet to 199 the A+P CPE that was assigned with the port number used in the 200 destination port in the layer 4 header. Since PRR delivers the IPv4 201 packet over IPv4-in-IPv6 tunnel, PRR can embed the IPv4 address and 202 port number in the IPv6 address. The IPv4-Embedded IPv6 address is 203 used to uniquely identify the A+P CPE. Details of how to construct 204 the IPv4-Embedded IPv6 address format is defined in Section 3.2.1. 206 3.2.1. IPv4-Embedded IPv6 Address Format For A+P CPE 208 |31bits|1bit| 32bits|8 bits|16bits|4bits|1bit|1bit|1bit|1bit|32 bits| 209 +------+----+-------+------+------+-----+----+----+----+----+-------+ 210 |A+P |flag|Public | EUI64| port |Port |flag|flag|flag|flag|Public | 211 |Prefix| 0 |IPv4 | | Range|Range| 1 | 2 | 3 | 4 |IPv4 | 212 | | |Address| | |Size | | | | |Address| 213 +------+----+-------+------+------+-----+----+----+----+----+-------+ 215 Figure 3 :IPv4-Embedded IPv6 address format 217 flag0: Is this address used by CPE or PRR? 219 flag1: Is address shared? 221 flag2: Is length of invariable present? 223 flag3: Is port range identifying sub network? 225 flag4: Reserved? 227 To facilitate other parties who are also interested in testing A+P 228 solution, we are considering to release this A+P implementation under 229 open source license. For more implementation details, please refer to 230 [Implementing A+P]. 232 3.2.2. DHCPv6 Configurations 234 DHCPv6 options defined in [draft-boucadair-dhcpv6-shared-address- 235 option] were implemented. These options allow configuring a shared 236 address and a port range using a DHCPv6 option. 238 3.2.3. Avoiding Fragmentation 240 Normally the host TCP/IP protocol stack uses TCP protocol stack uses 241 Maximum Segment Size (MSS) option and/or Path Maximum Transmission 242 Unit Discovery (PMTUD) to determine the MTU. 244 However adding the IPv6 Header and the PPPoE header to the IPv4 245 packet may exceed the maximum MTU of the wire and consequently 246 results in IP fragmentation. 248 One solution is to add a rule to iptables on A+P CPE to modify the 249 MSS value in TCP SYN and SYN-ACK. This can be done using command 250 "iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j 251 TCPMSS --set-mss DESIRED_MSS_VALUE". The DESIRED_MSS_VALUE is set to 252 exclude IPv4 header, TCP header, IPv6 header and PPPoE header length. 254 3.3. Implementing non-continuous Port Sets for A+P 256 3.3.1. Non-continuous Port Sets allocation mechanism 258 [I-D.ietf-intarea-shared-addressing-issues] states that a bulk of 259 incoming ports can be reserved as a centralized resource shared by 260 all subscribers using a given restricted IPv4 address. We could 261 distribute a range of continuous ports to each subscriber. This may 262 create security concerns such as blind attack. An alternative would 263 be to assign a bulk of non-continuous random ports to each 264 subscriber. The following session would describe the implementation 265 of non-continuous port-set. 267 Note that the non-continuous port-set allocation mechanism described 268 here is just one possible solution to implement non-continuous port 269 provisioning. The implementation itself is to achieve two goals: 1) 270 Proving of feasibility of non-continuous port-set with A+P approach; 271 2) Evaluating UPnP 1.0 compatibility with non-continuous port-set. 272 Experiment results are provided in Section 4.2.2. Given a port-set 273 size N, log2(N) bits are randomly chosen as subscribers 274 identification bits(S-bit). S-bit must be chosen between 1st and 16th 275 bits. For example: if sharing ration is 1:32, each subscriber will 276 have five S-bits. Figure 4 shows an example of 5 S-bits (2nd, 5th, 277 7th, 9th and 11th) for a subscriber. 279 Subscriber ID pattern is formed by setting all the S-bits to 1 and 280 other trivial bits to 0. Figure 5 illustrates an example of 281 subscriber ID pattern based on S-bits example in Figure 4. 283 Note that the subscriber ID pattern must be identical for each 284 subscriber that shares the same IPv4 address. 286 Subscribers ID value is assigned by setting subscriber ID pattern 287 bits (s bits shown in figure 4) to a unique customer value to 288 identify each customer and setting other trivial bits to 1. An 289 example of subscriber ID value, having a subscriber ID pattern shown 290 in the figure 5 and a customer value 0, is shown in the figure 6. 292 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 294 +----+----+----+----+----+----+----+----+ 296 | 0 | s | 0 | 0 | s | 0 | s | 0 | 298 +----+----+----+----+----+----+----+----+ 300 |9th |10th|11th|12th|13th|14th|15th|16th| 302 +----+----+----+----+----+----+----+----+ 304 | s | 0 | s | 0 | 0 | 0 | 0 | 0 | 306 +----+----+----+----+----+----+----+----+ 308 Figure 4 : An S-bit selection example (on a sharing ration 1:32 309 address). 311 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 313 +----+----+----+----+----+----+----+----+ 315 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 317 +----+----+----+----+----+----+----+----+ 319 |9th |10th|11th|12th|13th|14th|15th|16th| 321 +----+----+----+----+----+----+----+----+ 323 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 325 +----+----+----+----+----+----+----+----+ 327 Figure 5 : A subscriber ID pattern example (on a sharing ration 1:32 328 address). 330 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 332 +----+----+----+----+----+----+----+----+ 334 | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 336 +----+----+----+----+----+----+----+----+ 338 |9th |10th|11th|12th|13th|14th|15th|16th| 340 +----+----+----+----+----+----+----+----+ 342 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 344 +----+----+----+----+----+----+----+----+ 346 Figure 6 : A subscriber ID value example (customer value: 0) 348 Subscriber ID pattern and subscriber ID value together uniquely 349 define a restricted port set (Non-contiguous port sets or a 350 contiguous port range, depends on Subscriber ID pattern and 351 subscriber ID value) on a restricted IP address. 353 Pseudo-code shown in the Figure 7 describes how to use subscriber ID 354 pattern and subscriber ID value to implement a random ephemeral port 355 selection function within the defined restricted port sets on a 356 customer NAT. 358 do{ 360 restricted_next_ephemeral = (random()|subscriber_ID_pattern) 362 & subscriber_ID_value; 364 if(five-tuple is unique) 366 return restricted_next_ephemeral; 368 } 370 Figure 7 : Random ephemeral port selection within the restricted port 371 set 373 3.3.2. IPv4-Embedded IPv6 Address Format for Non-continuous Port Sets 374 A+P CPE 376 |31bits|1bit| 32bits|8bits|16bits |4bits|1bit|1bit|1bit|1bit|32bits| 377 +------+----+-------+------+------+-----+----+----+----+----+-------+ 378 |A+P |flag|Public | EUI64|SID_ |Reser|flag|flag|flag|flag|Public | 379 |Prefix| 0 |IPv4 | |Value |-ved | 1 | 2 | 3 | 4 | IPv4 | 380 | | |Address| | | | | | | |Address| 381 +------+----+-------+------+------+-----+----+----+----+----+-------+ 383 Figure 8 :IPv4-Embedded IPv6 address format 385 SID Value: Subscriber_ID_Value, which is unique for per subscriber 386 sharing a given restricted IPv4 address. and has been allocated to 387 each subscriber. 389 flag0: Is this address used by CPE or PRR? 391 flag1: Is address shared? 393 flag2: Is length of invariable present? 395 flag3: Is port range identifying sub network? 397 flag4: Reserved? 399 To support non-continuous port-set, PRR maintains a mapping table 400 which contains the pairs of restricted IPv4 address and it's 401 Subscriber ID Pattern. To form an IPv6 destination address for 402 incoming packet, PRR could find the right SID Pattern according to a 403 destination IPv4 address, and then apply a simple operation shown in 404 the figure 9. 406 SID_Value = Destination_Port | (~SID_Pattern); 408 Figure 9 :PRR calculates SID Value 410 3.3.3. Customize a non-continuous Ports Set A+P NAT 412 On a Linux kernel 2.6.32.36, only one line of linux kernel code was 413 Changed to implement this feature. Figure 10 shows the change. Figure 414 11 show the IPtables commands required in the PRR. The beginning of 415 port range changed to SID_Value and the ending of the port range 416 changed to SID_Pattern. 418 bool nf_nat_proto_unique_tuple(...) 420 ... 422 //The Original code: 424 //*portptr = htons(min + off % range_size); 426 // was changed to: 428 *portptr = htons((ntohs(off) | min ) & max ); 430 ... 432 Figure 10:Function of finding a unique 5-tuple for a non- 433 continuousport sets A+P NAT 435 iptables -t nat -A POSTROUTING -o eth0 -p tcp -j SNAT --to-source 436 a.b.c.d: SID_Value-SID_Pattern --random 438 iptables -t nat -A POSTROUTING -o eth0 -p udp -j SNAT --to-source 439 a.b.c.d: SID_Value-SID_Pattern --random 441 Figure 11: IPtables commands for a non-continuousports set A+P NAT 443 4. Application Tests and Experiments in A+P Environment 445 A set of well-known applications was tested. The tests compared A+P 446 over IPv6 and simple A+P without encapsulation on a pain IPv4 447 network. The test results showed that both share the same impacts 448 [draft-boucadair-port-range-01]. Web browsing (IE and Firefox), Email 449 (Outlook), Instant message(MSN),Skype, Google Earth work normally 450 with A+P. For more details, please refer to [draft-boucadair-port- 451 range-01]. 453 4.1. A+P Impacts on Applications 455 +------------------+--------------------------------------+ 456 | Application | A+P impacts | 457 +------------------+--------------------------------------+ 458 | IE | None | 459 +------------------+--------------------------------------+ 460 | Firefox | None | 461 +------------------+--------------------------------------+ 462 | FTP(Passive mode)| None | 463 +------------------+--------------------------------------+ 464 | FTP(Active mode) | require opening port forwarding | 465 | | | 466 +------------------+--------------------------------------+ 467 | Skype | None | 468 +------------------+--------------------------------------+ 469 | Outlook | None | 470 +------------------+--------------------------------------+ 471 | Google Earth | None | 472 +------------------+--------------------------------------+ 473 | BitComet | UPnP extensions may be required, when| 474 | | listening port is out of A+P range; | 475 | | other minor effects(see Section 4.4) | 476 +------------------+--------------------------------------+ 477 | uTorrent | UPnP extensions may be required, when| 478 | | listening port is out of A+P range; | 479 | | other minor effects(see Section 4.4) | 480 +------------------+--------------------------------------+ 481 | Live Messenger | None | 482 +------------------+--------------------------------------+ 484 Figure 12: A+P impacts on applications 486 P2P (Peer-to-Peer) applications using specific port for inbounding 487 connection are likely to fail, because the specific ports may not be 488 available for that A+P subscriber. Some UPnP extensions may be 489 required to make P2P applications work properly with A+P. Other minor 490 effects of A+P are discussed in Section 4.4. 492 4.2. UPnP extension experiment 494 4.2.1. UPnP 1.0 extension 496 To make P2P application work properly with port restricted NAT , we 497 have designed extensions including new variables, new error codes as 498 well as new actions to UPnP 1.0, and have them implemented with 499 [Emule], [open source UPnP SDK 1.0.4 for Linux] and [Linux UPnP IGD 500 0.92]. 502 In figure 5, a new error code is proposed for the existing 503 "AddPortMapping" action to explicitly indicate the situation that the 504 requested external port is out of range. 506 +----------+-----------------------+-----------------------------+ 507 | ErrorCode| errorDescription | Description | 508 +----------+-----------------------+-----------------------------+ 509 | 728 |ExternalPortOutOfRange | The external port is out | 510 | | | of the port range assigned | 511 | | | to this external interface | 512 +----------+-----------------------+-----------------------------+ 514 Figure 13:New ErrorCode for "AddPortMapping" action 516 New state variables have been introduced to reflect the valid port 517 range. The definitions of these state variables are shown in figure 518 6. 520 +-------------+-------+------+----------+---------+-------+ 521 |Variable |Req. or| Data | Allowed | Default | Eng. | 522 | Name | Opt.| Type | Value | Value | Units | 523 +-------------+-------+------+----------+---------+-------+ 524 |PortRangeLow | O | ui2 | >=0 | 0 | N/A | 525 +-------------+-------+------+----------+---------+-------+ 526 |PortRangeHigh| O | ui2 | <=65535 | 65535 | N/A | 527 +-------------+-------+------+----------+---------+-------+ 529 Figure 14: New state variables for port range 531 Correspondingly, new actions, GetPortRangeLow and GetPortRangeHigh, 532 defined to retrieve port range information are illustrated in figure 533 7. An IP address should be provided as argument to invoke the new 534 actions, for the port range is associated with a specific IP address. 536 +----------------+-----------------------+----+--------------------+ 537 | Action Name | Argument |Dir.| Related | 538 | | | | StateVariable | 539 +----------------+-----------------------+----+--------------------+ 540 |GetPortRangeLow | NewExternal IPAddress | IN | ExternalIPAddress | 541 | +-----------------------+----+--------------------+ 542 | | NewPortRange Low | OUT| PortRangeLow | 543 +----------------+-----------------------+----+--------------------+ 544 |GetPortRangeHigh| NewExternal IPAddress | IN | ExternalIPAddress | 545 | +-----------------------+----+--------------------+ 546 | | NewPortRange High | OUT| PortRangeHigh | 547 +----------------+-----------------------+----+--------------------+ 549 Figure 15: New actions for port range 551 Please refer to [UPnP Extension] for more details of UPnP extension 552 experiment in A+P. 554 4.2.2. UPnP 1.0 friendliness attempts 555 +-------------------+----------------------------------------------+ 556 | Application | Behaviors | 557 | | | 558 +-------------------+----------------------------------------------+ 559 | Microtorrent v2.2 | call GetSpecificPortMapping by incremental by| 560 | | 1 each time, | 561 | (also known as | until find an external port available, and | 562 | uTorrent) | then call AddPortMapping,or return error | 563 | | after five failures | 564 +-------------------+----------------------------------------------+ 565 | Emule v0.50a | call AddPortMapping, after finding the | 566 | | external port not available return error | 567 | | | 568 +-------------------+----------------------------------------------+ 569 | Azureus v4.6.0.2 | call AddPortMapping, after finding the | 570 | | external port not available, try the same | 571 | | port 5 more times by call AddPortMapping, | 572 | | then return error | 573 |-------------------+----------------------------------------------+ 574 | Shareazav2.2.5.7 | call GetSpecificPortMapping, after finding | 575 | | the external port not available, return error| 576 | | without issuing AddPortMapping | 577 +-------------------+----------------------------------------------+ 579 Figure 16 UPnP 1.0 applications behaviors of asking for an external 580 port 582 The Behaviors test results in the previous figure shows that if a 583 request of external port failed, some UPnP 1.0 applications, namely 584 Microtorrent v2.2 and Azureus v4.6.0.2 attempt to issue (at most) 4 585 more times request until succeed. With each external port request 586 attempts, the desired external port is incremented by 1 of the 587 previous requested external port. 589 Hence, allocating port sets in a way that each A+P subscriber has sub 590 sets interval less than 5 would make some UPnP 1.0 applications 591 succeed in 5 times retrying. For example, In case a Subscriber ID 592 Pattern 0x02 that makes 2 customers sharing one IPv4 address, and 593 customer 1 have the available ports 594 { 0,1 | 4,5 | 8,9 |12,13|....} while customer 2 have the available 595 ports: 596 { 2,3 | 6,7 | 10,11|14,15|....} 598 Microtorrent v2.2 and Azureus v4.6.0.2 would be compatible with port 599 restriction feature of A+P. 601 IGD:1 is known to be broken in shared address environment [RFC6269]; 602 IGD:2 mitigates the issues encountered in IGD:1. The efforts, 603 documented in section 4.2, were attempts before standardization of 604 IGD:2. 606 4.3. Port Usage of Applications 608 Port consumptions of applications not only impact the deployment 609 factor (i.e., port range size) for A+P solution but also play an 610 important role in determining the port limitation of per customer on 611 AFTR for Dual-Stack Lite. 613 Therefore we have also developed and deployed a Service Probe in our 614 IPv6 network, which use IPv6 TCP socket to ask A+P CPE for NAT 615 session usage, and store A+P NAT statistics in a Mysql database for 616 further analysis of application behaviours in terms of port and 617 session consumptions. 619 In figure 8, the maximum port usage of each application is the peak 620 number of port consumption per second during the whole communication 621 process. The duration time represents the total time from the first 622 NAT binding entry being established to the last one being destroyed. 624 +-----------+--------------------------+--------------+----------+ 625 |Application| Test case | Maximum | Duration | 626 | | | port usage | (seconds)| 627 +-----------+--------------------------+--------------+----------+ 628 | | browsing a news website | 20-25 | 200 | 629 | IE +--------------------------+--------------+----------+ 630 | | browsing a video website | 40-50 | 337 | 631 +-----------+--- ----------------------+--------------+----------+ 632 | | browsing a news website | 25-30 | 240 | 633 | Firefox +--------------------------+--------------+----------+ 634 | | browsing a video website | 80-90 | 230 | 635 +-----------+--------------------------+--------------+----------+ 636 | | browsing a news website | 50-60 | 340 | 637 | Chrome +--------------------------+--------------+----------+ 638 | | browsing a video website | 80-90 | 360 | 639 +-----------+--------------------------+--------------+----------+ 640 | Android | browsing a news website | 40-50 | 300 | 641 | Chrome +--------------------------+--------------+----------+ 642 | | browsing a video website | under 10 | 160 | 643 +-----------+--------------------------+--------------+----------+ 644 | Google | locating a place | 30-35 | 240 | 645 | Earth | | | | 646 +-----------+--------------------------+--------------+----------+ 647 | Android | | | | 648 | Google | locating a place | 10-15 | 240 | 649 | Earth | | | | 650 +-----------+--------------------------+--------------+----------+ 651 | Skype | make a call | under 10 | N/A | 652 +-----------+--------------------------+--------------+----------+ 653 | BitTorrent| downloading a file | 200 | N/A | 654 +-----------+--------------------------+--------------+----------+ 656 Figure 17: Port usage of applications 658 4.4. BitTorrent Behaviour in A+P 660 [draft-boucadair-behave-bittorrent-portrange] provides an exhaustive 661 testing report about the behaviour of BiTtorrent in an A+P 662 architecture. [draft-boucadair-behave-bittorrent-portrange] describes 663 the main behavior of BitTorrent service in an IP shared address 664 environment. Particularly, the tests have been carried out on a 665 testbed implementing [ID.boucadair-port-range] solution. The results 666 are, however, valid for all IP shared address based solutions. 668 Two limitations were experienced. The first limitation occurs when 669 two clients sharing the same IP address want to simultaneously 670 retrieve the SAME file located in a SINGLE remote peer. This 671 limitation is due to the default BitTorrent configuration on the 672 remote peer which does not permit sending the same file to multiple 673 ports of the same IP address. This limitation is mitigated by the 674 fact that clients sharing the same IP address can exchange portions 675 with each other, provided the clients can find each other through a 676 common tracker, DHT, or Peer Exchange. Even if they can not, we 677 observed that the remote peer would begin serving portions of the 678 file automatically as soon as the other client (sharing the same IP 679 address) finished downloading. This limitation is eliminated if the 680 remote peer is configured with bt.allow_same_ip == TRUE. 682 The second limitation occurs when a client tries to download a file 683 located on several seeders, when those seeders share the same IP 684 address. This is because the clients are enforcing bt.allow_same_ip 685 parameter to FALSE. The client will only be able to connect to one 686 sender, among those having the same IP address, to download the file 687 (note that the client can retrieve the file from other seeders having 688 distinct IP addresses). This limitation is eliminated if the local 689 client is configured with bt.allow_same_ip == TRUE, which is somewhat 690 likely as those clients will directly experience better throughput by 691 changing their own configuration. 693 Mutual file sharing between hosts having the same IP address has been 694 checked. Indeed, machines having the same IP address can share 695 files with no alteration compared to current IP architectures. 697 5. Security Considerations 699 TBD 701 6. IANA Considerations 703 This document includes no request to IANA. 705 7. Conclusion 707 Despite A+P introduces some impacts on existence applications, issues 708 of P2P applications due to the port restricted NAT have been resolved 709 by UPnP extension experiment in our test bed, and other issues are 710 shared by other IP address sharing solutions. Therefore, from our 711 work, it has been proved that deploying both port range and non- 712 continuous port sets A+P in the Service Provider's IPv6 network 713 during IPv6 transition period is feasible. 715 8. References 717 8.1. Normative References 719 [Implementing A+P] 721 Xiaoyu ZHAO.,"Implementing Public IPv4 Sharing in IPv6 722 Environment", ICCGI 2010 724 [UPnP Extension] 726 Xiaoyu ZHAO., "UPnP Extensions for Public IPv4 Sharing in 727 IPv6 Environment", ICNS 2010 729 8.2. Informative References 731 [RFC6346] 733 R. Bush., " The Address plus Port (A+P) Approach to the 734 IPv4 Address Shortage", August,2011. 736 [draft-boucadair-dhcpv6-shared-address-option] 738 M. Boucadair., "Dynamic Host Configuration Protocol (DHCPv6) 739 Options for Shared IP Addresses Solutions", draft- 740 boucadair-dhcpv6-shared-address-option-01 (work in 741 progress), December 21, 2009 743 [draft-boucadair-port-range-01] 745 "IPv4 Connectivity Access in the Context of IPv4 Address 746 Exhaustion", draft-boucadair-port-range-01(work in 747 progress), January 30, 2009 749 [Emule] 751 http://www.emule-project.net/. [Accessed October 26, 2009] 753 [UPnP SDK 1.0.4 for Linux] 755 http://upnp.sourceforge.net/. [Accessed October 26, 2009]. 757 [Linux UPnP IGD 0.92]. 759 http://linuxigd.sourceforge.net/. [Accessed October 26, 760 2009]. 762 [draft-boucadair-behave-bittorrent-portrange] 764 M. Boucadair.,"Behaviour of BitTorrent service in an IP 765 Shared Address Environment", draft-boucadair-behave- 766 bittorrent-portrange-02.txt 768 9. Additional Authors 770 Lan Wang 771 France Telecom 772 Hai dian district, 100190, Beijing, China 774 Email: lan.wang@orange-ftgroup.com 776 Tao Zheng 777 France Telecom 778 Hai dian district, 100190, Beijing, China 780 Email: tao.zheng@orange-ftgroup.com 782 Yan MA 783 Beijing University of Post and Telecommunication 784 Email: mayan@bupt.edu.cn 786 10. Acknowledgments 788 The experiments and tests described in this document have been 789 explored, developed and implemented with help from Zhao Xiaoyu, Eric 790 Burgey and JACQUENET Christian. 792 Appreciation to Randy Bush's intitial idea of documenting these 793 experience results, for share the knowledge of what we have learnt 794 with the community. 796 Thanks to Jan Zorz for comments. 798 11. Authors' Addresses 800 Xiaohong Deng 801 France Telecom 802 Hai dian district, 100190, Beijing, 803 China 805 Email: dxhbupt@gmail.com 807 Mohamed BOUCADAIR 808 France Telecom 809 Rennes,35000 France 811 Email: mohamed.boucadair@orange-ftgroup.com 813 Yiu L. Lee 814 Comcast 815 One Comcast Center 816 Philadelphia, PA 19103 817 U.S.A. 819 Email: Yiu_Lee@Cable.Comcast.com 821 Xiaohong Huang 822 Beijing University of Post and Telecommunication 823 Email: huangxh@bupt.edu.cn 825 Qin Zhao 826 Beijing University of Post and Telecommunication 827 Email: zhaoqin.bupt@gmail.com