idnits 2.17.1 draft-deng-v6ops-aplusp-experiment-results-01.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 : ---------------------------------------------------------------------------- == 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 (July 8, 2011) is 4676 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 263, but not defined == Missing Reference: 'ID.boucadair-port-range' is mentioned on line 590, but not defined == Unused Reference: '1' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 662, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS X.Deng 3 Internet Draft T.Zheng 4 Intended status: Informational M.Boucadair 5 Expires: January 9, 2012 L.Wang 6 France Telecom 7 X.Huang 8 Q.Zhao 9 Y.Ma 10 BUPT 11 July 8, 2011 13 Implementing AplusP in the provider's IPv6-only network 14 draft-deng-v6ops-aplusp-experiment-results-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 9, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents carefully, 42 as they describe your rights and restrictions with respect to this 43 document. Code Components extracted from this document must include 44 Simplified BSD License text as described in Section 4.e of the Trust 45 Legal Provisions and are provided without warranty as described in the 46 Simplified BSD License. 48 Abstract 50 This memo describes an implementation of A+P in a provider's IPv6- 51 only network. It provides details of the implementation, network 52 elements, configurations and test results as well. Besides traditional 53 port range A+P, a scattered port sets flavour of A+P is also 54 implemented and verified for the sake of distributing incoming ports 55 among customers in a more discrete way. The test results consist of 56 the application compatibility test, UPnP extension for A+P, port usage 57 and BitTorrent behaviour with A+P. 59 This memo focuses on the IPv6 flavor of A+P. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Implementation environment . . . . . . . . . . . . . . . . . . 4 66 3.1. Environment Overview . . . . . . . . . . . . . . . . . . . 4 67 3.2. Implementation and Configuration of A+P . . . . . . . . . 5 68 3.2.1. IPv4-Embedded IPv6 Address Format For A+P CPE. . . . . 5 69 3.2.2. DHCPv6 Configurations . . . . . . . . . . . . . . . . 6 70 3.2.3. Avoiding Fragmentation . . . . . . . . . . . . . . . . 6 71 3.3. Implementing scattered Port Sets for A+P . . . . . . . . . 7 72 3.3.1. Scattered Port Sets allocation mechanism . . . . . . 7 73 3.3.2. IPv4-Embedded IPv6 Address Format for Scattered Port 74 Sets A+P CPE . . . . . . . . . . . . . . . . . . . . 10 75 3.3.3. Customize a scattered Ports Set A+P NAT on Linux . . . 10 76 4. Application Tests and Experiments in A+P Environment . . . . 11 77 4.1. A+P Impacts on Applications . . . . . . . . . . . . . . . 12 78 4.2. UPnP extension experiment . . . . . . . . . . . . . . . . 13 79 4.3. Port Usage of Applications . . . . . . . . . . . . . . . . 14 80 4.4. BitTorrent Behaviour in A+P . . . . . . . . . . . . . . . 16 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 A+P [draft-ymbk-aplusp-09] is a technique to share IPv4 addresses 92 during the IPv6 transition period without requiring a NAT function in 93 the provider's network. The main idea of A+P is treating some bits 94 from the port number in the TCP/UDP header as additional end point 95 identifiers to extend the address field, thereby leaving a range of 96 ports available to applications. This feature facilitates migration of 97 networks to IPv6-only while offering the IPv4 connectivity services to 98 customers, because the IPv4 address and the significant bits from the 99 port range can be encoded in an IPv6 address and therefore 100 transporting IPv4 traffic over IPv6 network by stateless IPv6 routing. 102 We have implemented A+P in a residential ADSL access network, where 103 IPv6-only access network is provided over PPPoE. In this document, we 104 describe the implementation environment including A+P IPv6 prefix 105 format and network elements configurations, and results of application 106 tests as well. The document focuses on the implementation of the SMAP 107 function specified in [draft-ymbk-aplusp-09]: 109 o Implement DHCPv6 options to retrieve an IPv4-embedded IPv6 address 110 and a port range. 112 o Support of those DHCPv6 options in both the DHCPv6 server side and 113 the DHCPv6 client side. 115 o Support of those DHCPv6 options in both the DHCPv6 server side and 116 the DHCPv6 client side. 118 For extensive application tests results in A+P environment, please 119 refer to [draft-boucadair-behave-bittorrent-portrange-02] and [draft- 120 boucadair-port-range-01]. 122 2. Terminology 124 This document makes use of the following terms: 126 o PRR: Port Range Router 128 o A+P CPE: A+P aware Customer Premise Equipment 130 3. Implementation environment 132 3.1. Environment Overview 134 public 135 addresses +----------+ 136 realm | PRR | 137 | | 138 === +----------+ 139 IPv4 ^ ^ ^ 140 | | | 141 | v v 142 | +--------------+ 143 | | PPPoE/DHCPv6 | 144 over | | Server | 145 | +--------------+ 146 | === ^ ^ 147 | IPv6 ^ | | 148 | over | | | 149 IPv6 | PPPoE | | | 150 V v | | 151 === === v v 152 ^ +----------+ 153 | | A+P | 154 | | CPE | 155 | +----------+ 156 Private | ^ ^ 157 RFC1918 | | | 158 realm | v v 159 | +----------+ 160 | | Host | 161 | | | 162 V +----------+ 164 Figure 1 : Implementation Environment 166 We had developed both A+P home gate way function and Port Range Router 167 (PRR) function on Linux platform and ported the home gate way function 168 to a Linksys wrt 54G CPE, on which an openwrt 2.6.32 (based on Linux 169 kernel) is running. 171 Figure 2 shows the Parameters of A+P CPE. IPv6 is provisioning over 172 PPPoE to CPE while DHCPv6 server offers IPv6 prefix and A+P 174 parameters by extended options defined in [draft-boucadair-dhcpv6- 175 shared-address-option]. 177 +--------+------------+-------+-----+------------+-----------+------+ 178 | Model | CPU Speed | Flash | RAM | Wireless | Wireless | Wired| 179 | | (MHz) | (MB) | (MB)| NIC | Standard | Ports| 180 +--------+---------- -+-------+-----+------------+-----------+------+ 181 | Linksys| 200 | 8 | 32 | Broadcom | 11g | 5 | 182 | WRT54GS| | | |(integrated)| | | 183 +--------+------------+-------+-----+------------+-----------+------+ 184 Figure 2 :Parameters of A+P CPE 186 3.2. Implementation and Configuration of A+P 188 Aplusp CPE, using Netfilter framework, the IPv4 port restricted NAT 189 operation performed by CPE has been implemented by simply rules 190 through iptables tool on Linux. After the port restriceted NAT 191 operation, the IPv4 packets are sent to a TUN interface which is 192 described as a virtual network interface in Linux. Using the IPv4- 193 Embedded IPv6 address format defined in section 3.2.1, an IPv4-in- 194 IPv6 encapsulation/decapsulation is performed by the TUN interface 195 handler. 197 PRR, located in the interconnection point of the IPv6 network and IPv4 198 network, has been implemented with two main functions: 1) IPv4- 199 in-IPv6 encapsulation/decapsulation; Like CPE, TUN driver is also used 200 in PRR to achieve function IPv4-in-IPv6 encapsulation/decapsulation. 201 2) destination port based routing function, which is responsible for 202 routing the IPv4 traffic originated from the IPv4 Internet to the Port 203 Range restricted A+P CPE. Destination port based routing is 204 implemented by generating IPv6 destination address, pre-assigned from 205 IPv4 address and port range to each CPE, according to IPv4-Embedded 206 IPv6 address format defined in section 3.2.1. 208 3.2.1. IPv4-Embedded IPv6 Address Format For A+P CPE 209 |31bits|1bit| 32bits|8 bits|16bits|4bits|1bit|1bit|1bit|1bit|32 bits| 210 +------+----+-------+------+------+-----+----+----+----+----+-------+ 211 |AplusP|flag|Public | EUI64| port |Port |flag|flag|flag|flag|Public | 212 |Prefix| 0 |IPv4 | | Range|Range| 1 | 2 | 3 | 4 |IPv4 | 213 | | |Address| | |Size | | | | |Address| 214 +------+----+-------+------+------+-----+----+----+----+----+-------+ 216 Figure 3 :IPv4-Embedded IPv6 address format 218 flag0: Is this address used by CPE or PRR? 220 flag1: Is address shared? 222 flag2: Is length of invariable present? 224 flag3: Is port range identifying sub network? 226 flag4: Reserved? 228 To facilitate test and experiment on AplusP solution, recently, we are 229 considering release this AplusP implementation under open source 230 license. For more implementation details, please refer to 231 [Implementing A+P] 233 3.2.2. DHCPv6 Configurations 235 DHCPv6 options defined in [draft-boucadair-dhcpv6-shared-address- 236 option] have been implemented. These options allow to configure a 237 shared address together with a port range using DHCPv6. 239 3.2.3. Avoiding Fragmentation 241 Normally the TCP protocol stack will employ Maximum Segment Size (MSS) 242 negotiation and/or Path Maximum Transmission Unit Discovery (PMTUD) to 243 determine 245 the maximum packet size, and then try to send as large as possible 246 datagram to achieve better throughput. However the IPv4-in-IPv6 247 encapsulation and the PPPoE header is very likly to cause a larger 248 packet that exceeds the maximum MTU of the wire, and result in 249 undesired fragmentation processing and decrease transmission 250 efficiency. 252 A simple solution is to enable iptables on A+P CPE to modify the MSS 253 value of TCP session, using the command like "iptables -t mangle -A 254 FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 255 DESIRED_MSS_VALUE". Here the DESIRED_MSS_VALUE is taken into account 256 of common size of IPv4 header without options, common size of TCP 257 header and size of basic IPv6 header and PPPoE header as well. 259 3.3. Implementing scattered Port Sets for A+P 261 3.3.1. Scattered Port Sets allocation mechanism 263 As described in [I-D.ietf-intarea-shared-addressing-issues], a bulk of 264 incoming ports can be reserved as a centralized resource shared by all 265 subscribers using a given restricted IPv4 address. In order to 266 distribute incoming ports as scattered as possible among subscribers 267 sharing the same restricted IPv4 address, other than allocating a 268 continuous range of ports to per subscriber, a solution to distribute 269 bulks of non-continuous ports among subscribers, which also takes port 270 randomization of CPE NAT into account, because port randomization is 271 one protection among others against blind attacks, is elaborated 272 thereby. 274 On every restricted IPv4 address, according to port set size N, 275 log2(N)bits are randomly chose as subscribers identification bits(s 276 bit) among 1st and 16th bits. Take a sharing ration 1:32 for example, 277 Figure 4 shows an example of 5bits (2nd, 5th, 7th, 9th, 11th) being 278 chose as s bit. 280 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 281 +----+----+----+----+----+----+----+----+ 282 | 0 | s | 0 | 0 | s | 0 | s | 0 | 283 +----+----+----+----+----+----+----+----+ 285 |9th |10th|11th|12th|13th|14th|15th|16th| 286 +----+----+----+----+----+----+----+----+ 287 | s | 0 | s | 0 | 0 | 0 | 0 | 0 | 288 +----+----+----+----+----+----+----+----+ 290 Figure 4 : An s bit selection example (on a sharing ration 1:32 291 address). 293 Subscriber ID pattern is then formed by setting all the s bits to 1 294 and other trivial bits to 0. Figure 5 illustrates an example of 295 subscriber ID pattern which follows the s bit selection of figure 4. 296 Note that the subscriber ID pattern can be different, ensured by the 297 random s bit selection, per restricted IP address no matter whether 298 the sharing ratio varies. 300 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 301 +----+----+----+----+----+----+----+----+ 302 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 303 +----+----+----+----+----+----+----+----+ 305 |9th |10th|11th|12th|13th|14th|15th|16th| 306 +----+----+----+----+----+----+----+----+ 307 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 308 +----+----+----+----+----+----+----+----+ 310 Figure 5 : A subscriber ID pattern example (on a sharing ration 1:32 311 address). 313 Subscribers ID value is then assigned by setting subscriber ID pattern 314 bits (s bits shown in figure 4) to a unique customer value and setting 315 other trivial bits to 1. An example of subscriber ID value, having a 316 subscriber ID pattern shown in the figure 5 and a customer value 0, is 317 shown in the figure 6. 319 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 320 +----+----+----+----+----+----+----+----+ 321 | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 322 +----+----+----+----+----+----+----+----+ 324 |9th |10th|11th|12th|13th|14th|15th|16th| 325 +----+----+----+----+----+----+----+----+ 326 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 327 +----+----+----+----+----+----+----+----+ 329 Figure 6 : A subscriber ID value example (customer value: 0) 331 Subscriber ID pattern and subscriber ID value together uniquely 332 defines a restricted port set (Non-contiguous port sets or a 333 contiguous port range, depends on Subscriber ID pattern and subscriber 334 ID value) on a restricted IP address. 336 Pseudo-code shown in the figure 7 describes how to use subscriber ID 337 pattern and subscriber ID value to implement a random ephemeral port 338 selection function within the defined restricted port sets on a 339 customer NAT. 341 do{ 343 restricted_next_ephemeral = (random()|subscriber_ID_pattern) 345 & subscriber_ID_value; 347 if(five-tuple is unique) 349 return restricted_next_ephemeral; 351 } 353 Figure 7 : Random ephemeral port selection within the restricted port 354 set 356 3.3.2. IPv4-Embedded IPv6 Address Format for Scattered Port Sets A+P CPE 358 |31bits|1bit| 32bits|8bits|16bits |4bits|1bit|1bit|1bit|1bit|32bits| 359 +------+----+-------+------+------+-----+----+----+----+----+-------+ 360 |AplusP|flag|Public | EUI64|SID_ |Reser|flag|flag|flag|flag|Public | 361 |Prefix| 0 |IPv4 | |Value |-ved | 1 | 2 | 3 | 4 | IPv4 | 362 | | |Address| | | | | | | |Address| 363 +------+----+-------+------+------+-----+----+----+----+----+-------+ 365 Figure 8 :IPv4-Embedded IPv6 address format 367 SID Value: Subscriber_ID_Value, which is unique for per subscriber 368 sharing a given restricted IPv4 address. and has been allocated to 369 each subscriber. 371 flag0: Is this address used by CPE or PRR? 373 flag1: Is address shared? 375 flag2: Is length of invariable present? 377 flag3: Is port range identifying sub network? 379 flag4: Reserved? 380 PRR maintains a mapping table, which consists of restricted IPv4 381 address and it's Subscriber ID Pattern. To form an IPv6 destination 382 address for incoming packet, PRR could find the right SID Pattern 383 according to a destination IPv4 address, and then apply a simple 384 operation shown in the figure 9. 386 SID_Value = Destination_Port | (~SID_Pattern). 388 Figure 9 :PRR calculates SID Value 390 3.3.3. Customize a scattered Ports Set A+P NAT on Linux 392 With a linux kernel 2.6.32.36, only one line of linux kernel code is 393 changed, as shown in the figure5, and the same IPtables command line 394 interface is used with the only one change of semantic that the 395 original staring of port range becomes SID_Value and the ending port 396 of a port range becomes SID_Pattern. The command line with iptables to 397 configure a scattered Ports Set A+P is illustrated in the figure 11. 399 bool nf_nat_proto_unique_tuple(...) 401 ... 403 //The Original code: 405 //*portptr = htons(min + off % range_size); 407 // was changed to: 409 *portptr = htons((ntohs(off) | min ) & max ); 411 ... 413 Figure 10:Function of finding a unique 5-tuple for a scattered port 414 sets A+P NAT 416 iptables -t nat -A POSTROUTING -o eth0 -p tcp -j SNAT --to-source 417 a.b.c.d: SID_Value-SID_Pattern --random 419 iptables -t nat -A POSTROUTING -o eth0 -p udp -j SNAT --to-source 420 a.b.c.d: SID_Value-SID_Pattern --random 422 Figure 11: IPtables commands for a scattered ports set A+P NAT 424 4. Application Tests and Experiments in A+P Environment 426 A set of well-known applications have been tested in this IPv6 flavor 427 of A+P environment to access A+P impacts on them. The test results 428 show that IPv6 flavor of A+P has the same impacts on applications as 429 IPv4 flavor A+P does [draft-boucadair-port-range-01]. Web browsing (IE 430 and Firefox), Email (Outlook), Instant message(MSN),Skype, Google 431 Earth work normally with A+P. For more details, please refer to 432 [draft-boucadair-port-range-01]. 434 4.1. A+P Impacts on Applications 436 +------------------+--------------------------------------+ 437 | Application | A+P impacts | 438 +------------------+--------------------------------------+ 439 | IE | None | 440 +------------------+--------------------------------------+ 441 | Firefox | None | 442 +------------------+--------------------------------------+ 443 | FTP(Passive mode)| None | 444 +------------------+--------------------------------------+ 445 | FTP(Active mode) | require opening port forwarding | 446 +------------------+--------------------------------------+ 447 | Skype | None | 448 +------------------+--------------------------------------+ 449 | Outlook | None | 450 +------------------+--------------------------------------+ 451 | Google Earth | None | 452 +------------------+--------------------------------------+ 453 | BitComet | UPnP extensions may be required, when| 454 | | listening port is out of A+P range; | 455 | | other minor effects(see section 4.4) | 456 +------------------+--------------------------------------+ 457 | uTorrent | UPnP extensions may be required, when| 458 | | listening port is out of A+P range; | 459 | | other minor effects(see section 4.4) | 460 +------------------+--------------------------------------+ 461 | Live Messenger | None | 462 +------------------+--------------------------------------+ 464 Figure 12:Aplusp impacts on applications 466 For P2P (Peer-to-Peer) applications, when some of them listening on 467 specific port to expect inbounding connection, it is likely to fail 468 due to the listening port is out of A+P port range. Some UPnP 469 extensions may be required to make P2P applications work properly with 470 A+P. Other minor effects of A+P are discussed in section 4.4. 472 4.2. UPnP extension experiment 474 To make P2P application work properly with port restricted NAT , we 475 have designed extensions including new variables, new errorcodes as 476 well as new actions to UPnP 1.0, and have them implemented with 477 [Emule], [open source UPnP SDK 1.0.4 for Linux] and [Linux UPnP IGD 478 0.92]. 480 In figure 5, a new error code is proposed for the existing 481 "AddPortMapping" action to explicitly indicate the situation that the 482 requested external port is out of range. 484 +----------+-----------------------+-----------------------------+ 485 | ErrorCode| errorDescription | Description | 486 +----------+-----------------------+-----------------------------+ 487 | 728 |ExternalPortOutOfRange | The external port is out | 488 | | | of the port range assigned | 489 | | | to this external interface | 490 +----------+-----------------------+-----------------------------+ 492 Figure 13:New ErrorCode for "AddPortMapping" action 494 New state variables have been introduced to reflect the valid port 495 range. The definitions of these state variables are shown in figure 6. 497 +-------------+-------+------+----------+---------+-------+ 498 |Variable |Req. or| Data | Allowed | Default | Eng. | 499 | Name | Opt.| Type | Value | Value | Units | 500 +-------------+-------+------+----------+---------+-------+ 501 |PortRangeLow | O | ui2 | >=0 | 0 | N/A | 502 +-------------+-------+------+----------+---------+-------+ 503 |PortRangeHigh| O | ui2 | <=65535 | 65535 | N/A | 504 +-------------+-------+------+----------+---------+-------+ 506 Figure 14: New state variables for port range 508 Correspondingly, new actions, GetPortRangeLow and GetPortRangeHigh, 509 defined to retrieve port range information are illustrated in figure 510 7. An IP address should be provided as argument to invoke the new 511 actions, for the port range is associated with a specific IP address. 513 +----------------+-----------------------+----+--------------------+ 514 | Action Name | Argument |Dir.| Related | 515 | | | | StateVariable | 516 +----------------+-----------------------+----+--------------------+ 517 |GetPortRangeLow | NewExternal IPAddress | IN | ExternalIPAddress | 518 | +-----------------------+----+--------------------+ 519 | | NewPortRange Low | OUT| PortRangeLow | 520 +----------------+-----------------------+----+--------------------+ 521 |GetPortRangeHigh| NewExternal IPAddress | IN | ExternalIPAddress | 522 | +-----------------------+----+--------------------+ 523 | | NewPortRange High | OUT| PortRangeHigh | 524 +----------------+-----------------------+----+--------------------+ 526 Figure 15: New actions for port range 528 Please refer to [UPnP Extension] for more details of UPnP extension 529 experiment in A+P. 531 4.3. Port Usage of Applications 533 Port consumptions of applications not only impact the deployment 534 factor (i.e., port range size) for AplusP solution but also play an 535 important role in determining the port limitation of per customer on 536 AFTR for Dual-Stack Lite. 538 Therefore we have also developed and deployed a Service Probe in our 539 IPv6 network, which use IPv6 TCP socket to ask AplusP CPE for NAT 540 session usage, and store AplusP NAT statistics in a Mysql database for 541 further analysis of application behaviors in terms of port and session 542 consumptions. 544 In figure 8, the maximum port usage of each application is the peak 545 number of port consumption per second during the whole communication 546 process. The duration time represents the total time from the first 547 NAT binding entry being established to the last one being destroyed. 549 +-----------+--------------------------+--------------+----------+ 550 |Application| Test case | Maximum | Duration | 551 | | | port usage | (seconds)| 552 +-----------+--------------------------+--------------+----------+ 553 | | browsing a news website | 20-25 | 200 | 554 | IE +--------------------------+--------------+----------+ 555 | | browsing a video website | 40-50 | 337 | 556 +-----------+--- ----------------------+--------------+----------+ 557 | | browsing a news website | 25-30 | 240 | 558 | Firefox +--------------------------+--------------+----------+ 559 | | browsing a video website | 80-90 | 230 | 560 +-----------+--------------------------+--------------+----------+ 561 | | browsing a news website | 50-60 | 340 | 562 | Chrome +--------------------------+--------------+----------+ 563 | | browsing a video website | 80-90 | 360 | 564 +-----------+--------------------------+--------------+----------+ 565 | Android | browsing a news website | 40-50 | 300 | 566 | Chrome +--------------------------+--------------+----------+ 567 | | browsing a video website | under 10 | 160 | 568 +-----------+--------------------------+--------------+----------+ 569 | Google | locating a place | 30-35 | 240 | 570 | Earth | | | | 571 +-----------+--------------------------+--------------+----------+ 572 | Android | | | | 573 | Google | locating a place | 10-15 | 240 | 574 | Earth | | | | 575 +-----------+--------------------------+--------------+----------+ 576 | Skype | make a call | under 10 | N/A | 577 +-----------+--------------------------+--------------+----------+ 578 | BitTorrent| downloading a file | 200 | N/A | 579 +-----------+--------------------------+--------------+----------+ 581 Figure 16: Port usage of applications 583 4.4. BitTorrent Behaviour in A+P 585 [draft-boucadair-behave-bittorrent-portrange] provides an exhaustive 586 testing report about the behaviour of BiTtorrent in an A+P 587 architecture. [draft-boucadair-behave-bittorrent-portrange] describes 588 the main behavior of BitTorrent service in an IP shared address 589 environment. Particularly, the tests have been carried out on a 590 testbed implementing [ID.boucadair-port-range] solution. The results 591 are, however, valid for all IP shared address based solutions. 593 Two limitations were experienced. The first limitation occurs when 594 two clients sharing the same IP address want to simultaneously 595 retrieve the SAME file located in a SINGLE remote peer. This 596 limitation is due to the default BitTorrent configuration on the 597 remote peer which does not permit sending the same file to multiple 598 ports of the same IP address. This limitation is mitigated by the 599 fact that clients sharing the same IP address can exchange portions 600 with each other, provided the clients can find each other through a 601 common tracker, DHT, or Peer Exchange. Even if they can not, we 602 observed that the remote peer would begin serving portions of the file 603 automatically as soon as the other client (sharing the same IP 604 address) finished downloading. This limitation is eliminated if the 605 remote peer is configured with bt.allow_same_ip == TRUE. 607 The second limitation occurs when a client tries to download a file 608 located on several seeders, when those seeders share the same IP 609 address. This is because the clients are enforcing bt.allow_same_ip 610 parameter to FALSE. The client will only be able to connect to one 611 sender, among those having the same IP address, to download the file 612 (note that the client can retrieve the file from other seeders having 613 distinct IP addresses). This limitation is eliminated if the local 614 client is configured with bt.allow_same_ip == TRUE, which is somewhat 615 likely as those clients will directly experience better throughput by 616 changing their own configuration. 618 Mutual file sharing between hosts having the same IP address has been 619 checked. Indeed, machines having the same IP address can share 620 files with no alteration compared to current IP architectures. 622 5. Security Considerations 624 TBD 626 6. IANA Considerations 627 This document includes no request to IANA. 629 7. Conclusion 631 Despite A+P introduces some impacts on existence applications, issues 632 of P2P applications due to the port restricted NAT have been resolved 633 by UPnP extension experiment in our test bed, and other issues are 634 shared by other IP address sharing solutions. Therefore, from our 635 work, it has been proved that deploying A+P in the Service Provider's 636 IPv6 network during IPv6 transition period is feasible. 638 8. References 640 8.1. Normative References 642 [Implementing A+P] 644 Xiaoyu ZHAO.,"Implementing Public IPv4 Sharing in IPv6 645 Environment", ICCGI 2010 647 [UPnP Extension] 649 Xiaoyu ZHAO., "UPnP Extensions for Public IPv4 Sharing in 650 IPv6 Environment", ICNS 2010 652 8.2. Informative References 654 [1] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 655 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 656 1583. 658 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 659 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 660 1573-1583. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [draft-ymbk-aplusp-09] 668 R. Bush., " The A+P Approach to the IPv4 Address Shortage", 669 draft-ymbk-aplusp-09 (work in progress), February 17, 2011. 671 [draft-boucadair-dhcpv6-shared-address-option] 673 M. Boucadair., "Dynamic Host Configuration Protocol (DHCPv6) 674 Options for Shared IP Addresses Solutions", draft- 675 boucadair-dhcpv6-shared-address-option-01 (work in 676 progress), December 21, 2009 678 [draft-boucadair-port-range-01] 680 "IPv4 Connectivity Access in the Context of IPv4 Address 681 Exhaustion", draft-boucadair-port-range-01(work in 682 progress), January 30, 2009 684 [Emule] 686 http://www.emule-project.net/. [Accessed October 26, 2009] 688 [UPnP SDK 1.0.4 for Linux] 690 http://upnp.sourceforge.net/. [Accessed October 26, 2009]. 692 [Linux UPnP IGD 0.92]. 694 http://linuxigd.sourceforge.net/. [Accessed October 26, 695 2009]. 697 [draft-boucadair-behave-bittorrent-portrange] 699 M. Boucadair.,"Behaviour of BitTorrent service in an IP 700 Shared Address Environment", draft-boucadair-behave- 701 bittorrent-portrange-02.txt 703 9. Acknowledgments 705 The experiments and tests described in this document have been 706 explored, developed and implemented with help from Zhao Xiaoyu, Eric 707 Burgey and JACQUENET Christian. 709 Thanks to Jan Zorz for comments. 711 Authors' Addresses 713 Xiaohong Deng 714 France Telecom 715 Hai dian district, 100190, Beijing, 716 China 718 Email: xiaohong.deng@orange-ftgroup.com 720 Mohamed BOUCADAIR 721 France Telecom 722 Rennes,35000 France 724 Email: mohamed.boucadair@orange-ftgroup.com 726 Lan Wang 727 France Telecom 728 Hai dian district, 100190, Beijing, China 730 Email: lan.wang@orange-ftgroup.com 732 Tao Zheng 733 France Telecom 734 Hai dian district, 100190, Beijing, China 736 Email: tao.zheng@orange-ftgroup.com 738 Xiaohong Huang 739 Beijing University of Post and Telecommunication 740 Email: huangxh@bupt.edu.cn 742 Qin Zhao 743 Beijing University of Post and Telecommunication 744 Email: zhaoqin.bupt@gmail.com 746 Yan MA 747 Beijing University of Post and Telecommunication 748 Email: mayan@bupt.edu.cn