idnits 2.17.00 (12 Aug 2021) /tmp/idnits9744/draft-defeche-ipv6-traffic-in-p2p-networks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2009) is 4593 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TFE12' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'TFE13' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'TFE28' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'TFE29' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'TFE5' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'TFE23' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'THESIS' is defined on line 756, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations M. Defeche 3 Internet-Draft University of Liege 4 Intended status: Informational E. Vyncke 5 Expires: April 19, 2010 Cisco Systems 6 October 16, 2009 8 Measuring IPv6 Traffic in BitTorrent Networks 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 19, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document summarizes a University thesis which aims to measure 58 the evolution over time of IPv6 traffic, to analyze the geographical 59 distribution of IPv6 nodes and to compare the two Internet Protocol 60 versions on many different criteria (RTT, latency, MTU). The 61 measurements were done during the Summer 2009 using a specific- 62 purpose program which connects to the BitTorrent peer-to-peer 63 network. 65 The study was made in Peer-to-Peer (P2P) networks because they are 66 responsible for most Internet traffic and because their structure and 67 functioning permit a rapid discovery of a large number of nodes from 68 all over the world. In addition, the P2P users are more likely to be 69 interested by IPv6 as IPv6 does not have the same NAT problems as 70 IPv4. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Some explanations about BitTorrent . . . . . . . . . . . . . . 4 76 2.1. Peer Wire Protocol . . . . . . . . . . . . . . . . . . . . 5 77 2.2. Tracker . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2.3. Peer Exchange . . . . . . . . . . . . . . . . . . . . . . 6 79 2.4. Distributed Hash Table . . . . . . . . . . . . . . . . . . 6 80 2.5. Local Service Delivery . . . . . . . . . . . . . . . . . . 6 81 3. Tools used for Measurement . . . . . . . . . . . . . . . . . . 7 82 4. What was measured . . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. IPv6 BitTorrent Clients . . . . . . . . . . . . . . . . . 8 84 4.2. IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 8 85 4.2.1. Native IPv6 . . . . . . . . . . . . . . . . . . . . . 9 86 4.2.2. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.2.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.2.4. Tunnel Brokers . . . . . . . . . . . . . . . . . . . . 10 89 4.2.5. ISATAP . . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.2.6. Other Addresses . . . . . . . . . . . . . . . . . . . 11 91 4.2.7. Summary about IPv6 Addresses . . . . . . . . . . . . . 12 92 4.3. Traffic Measurements . . . . . . . . . . . . . . . . . . . 12 93 4.4. Comparaison IPv4 vs. IPv6 . . . . . . . . . . . . . . . . 12 94 4.5. Round-Trip Time . . . . . . . . . . . . . . . . . . . . . 13 95 4.6. Comparaison of Hops . . . . . . . . . . . . . . . . . . . 14 96 4.7. MTU Comparaison . . . . . . . . . . . . . . . . . . . . . 14 97 4.8. Monthly Evolution . . . . . . . . . . . . . . . . . . . . 15 98 4.9. Protocols Used to Discover Peers . . . . . . . . . . . . . 15 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 104 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 An IPv6 vs. IPv4 measurement was made in Peer-to-Peer (P2P) networks 110 because they are responsible for most Internet traffic [TFE3] and 111 because their structure and functioning permit a rapid discovery of a 112 large number of nodes from all over the world. In addition, the P2P 113 users are more likely to be interested by IPv6 as IPv6 does not have 114 the same NAT problems as IPv4. 116 The measurements were made in May, June, July and October 2009 to get 117 an idea of the evolution within a couple of months. The intend is to 118 run the same measurements every month for a couple of years. 120 Measurements include: number of IPv4 vs. IPv6 nodes, which kind of 121 IPv6 connectivity, comparing the MTU, RTT between the two versions of 122 IP and geographical distribution. 124 2. Some explanations about BitTorrent 126 Let's start with some explanations about BitTorrent. 128 BitTorrent is based on an hybrid decentralized network which is 129 particularly well suited to the transfer of large files. BitTorrent 130 generates the largest amount of traffic of all P2P networks and was 131 installed on 28.20% of PCs in September 2007, and this number is 132 certainly higher at present. BitTorrent also includes different 133 protocols to discover peers, namely DHT, PEX and LSD which will be 134 discussed later. Thanks to these mechanisms BitTorrent can be 135 completely decentralized. The different clients are all compatible 136 with the core protocol but some divergences concerning PEX, DHT and 137 LSD appear between Azureus and the mainline, which represents at 138 least the BitTorrent and [micro]Torrent clients. Swarming is one of 139 the basis of the protocol and IPv6 specification exists although it 140 is not implemented by all clients. 142 Since BitTorrent is the only protocol that offers in theory a good 143 support to IPv6, our choice is limited. But there are other reasons 144 why BitTorrent is the network protocol that best matches our needs. 146 o The number of different copies of the same file(s) is far smaller 147 than in other networks. This leads to a larger number of peers 148 sharing the same file(s). Therefore swarming can be more 149 efficient thanks to a larger number of sources. 151 o As BitTorrent is generally used to share large files, peers stay 152 connected longer, giving us more time to discover them. 154 o BitTorrent is responsible for the largest part of the P2P traffic 155 throughout the world. 157 o BitTorrent is widely used in most regions of the world. 159 o Thanks to many different extensions like PEX (Section 2.3), DHT 160 (Section 2.4) and LSD (Section 2.5), the discovery of peers is 161 improved greatly. 163 2.1. Peer Wire Protocol 165 The Peer wire Protocol [[TFE5]], or PWP, specifies the way peers 166 communicate in an asynchronous fashion with each other to exchange 167 data and signalling messages. It is based on TCP connections that 168 function in Full-Duplex and Pipelining mode to get better 169 performances. This protocol does not define how to choose pieces to 170 request, nor how to select peers to download from and to upload to. 171 Certain algorithms, which are explained below, give some solutions to 172 attain a good propagation of pieces in the swarm and to make peers 173 happy with their download rate compared to their upload rate. 175 2.2. Tracker 177 The trackers [[TFE5]] act like servers but do not deal with the 178 transfer of files ; their only purposes are to manage the swarm and 179 to respond to periodic client requests for information about peers 180 sharing the same torrent. Since the transfer of files is completely 181 supported by peers, the bandwidth requirement is very low and thus a 182 single tracker can handle many swarms, each one containing a large 183 number of peers. This protocol commonly called THP is used by 184 clients to communicate over HTTP with trackers. As a matter of fact, 185 the trackers run an HTTP server. Peers contact trackers that are 186 present in the metadata file for the following purposes : 188 o to enter a swarm 190 o to leave a swarm 192 o to inform the tracker that the download is complete 194 o to periodically give information on the download state and 195 retrieve information about a random peer set. This time interval 196 is defined by the tracker. If a peer misses a periodical request 197 it can be considered as disconnected by the tracker and thus not 198 present in the swarm any more 200 This communication permits trackers to keep track of peers that are 201 in the swarm and to avoid referencing disconnected peers. 203 Tracker responses do not support IPv6 peers without this extension 204 [[[TFE12]]] which means that they do not include IPv6 peers in their 205 responses. This extension adds two new parameters for the tracker 206 requests: 208 o ipv6 : the client IPv6 address. It can be added when the client 209 contacts the tracker over IPv4; 211 o ipv4 : the client IPv4 address. Conversely, when communication 212 is made over IPv6. 214 It permits clients having a dual stack to advertize both its 215 addresses in the swarm. The port of the additional address is the 216 same as the primary one. 218 2.3. Peer Exchange 220 The Peer Exchange or PEX is a means to discover new peers through 221 peers that the client is already connected to. As a matter of fact, 222 peers trade information concerning the peers they are connected to. 223 Only few initial peers are needed to rapidly find a large number of 224 peers. This mechanism permits a reduction of the tracker load and an 225 improvement in the robustness as the tracker dependency is decreased. 227 2.4. Distributed Hash Table 229 The DHT technology [[TFE13]] is a way to store a hash table over a 230 network, thus in a distributed way, each peers contains a part of it. 231 Files and nodes are identified by a same length key, which is 20 232 bytes in BitTorrent. Each peer also maintains a list of different 233 peers to efficiently route its searches. DHT in BitTorrent is an 234 implementation of Kademlia which is based on the XOR metric that is 235 the distance between two nodes or between a node and a file can be 236 determined by a XOR of their keys. 238 This technology is used to decentralize the tracking mechanism to 239 once more decrease the dependence on trackers. Even if the trackers 240 are down or if no trackers are specified in the metadata file, the 241 DHT technology permits the discovery of peers sharing the same 242 torrent thanks to the info key hash as identifier. Conversely to 243 PEX, no initial peers are needed. 245 2.5. Local Service Delivery 247 The Local Service Discovery or LSD permits the discovery of peers 248 that are downloading the same torrent in the same local network. The 249 transfer rate is much higher between two peers in the same local 250 network than between two peers in different networks since the 251 bandwidth limitation is that of the local network and not the one of 252 the Internet connection which is far smaller, especially the upload 253 stream. Briefly, LSD works as follows : the hash of the info key is 254 broadcasted in the local network to find out peers sharing the same 255 torrent. 257 3. Tools used for Measurement 259 As millions of pieces of information can be reached and because this 260 information is retrieved and handled by five different programs, the 261 choice of a MySQL database came naturally for effectiveness reasons 262 and because concurrent access is managed. Each program requests, 263 inserts, and/or updates information in this database. 265 The computer that holds the database and executes the programs runs 266 the operating system Debian GNU/Linux 5.0 and has native IPv6 and 267 IPv4 connectivity, which will permit a better evaluation of the two 268 versions than if we use Teredo, for instance. 270 All our programs evolved constantly to better match our needs and to 271 improve their performance. Most of them where rethought several 272 times to achieve our goals. A long time was spent to debug the 273 LibTorrent Rasterbar library to get a full IPv6-capable BitTorrent 274 client and to identify problems that The Pirate Bay had with IPv6. 276 Our specialized BitTorrent client joins different swarms and 277 periodically changes to other swarms. While in a swarm we try to get 278 connected to as many peers as possible thanks to all protocols 279 supported by BitTorrent. In this way we are able to easily, 280 automatically and efficiently discover peers. Ideally we should 281 choose swarms with large numbers of peers in order to effectively 282 retrieve information. Concerning the legality issue, we can use a 283 trick to avoid downloading and uploading any files. In fact, we 284 claim that we are not interested in any pieces so we will not 285 download anything and we will not upload either since we have nothing 286 to upload. So we are present in the swarm but without taking part in 287 the sharing of files. 289 As we are interested in the number of routers on the path between us 290 and the remote peer we must discover the value of the Time-To-Live or 291 Hop Limit depending on the IP version. Since the TTL or Hop Limit is 292 initially set depending on the operating system, for instance 64 for 293 Linux, and because the number of routers on the path should not 294 exceed 32 we can easily calculate the number of times the field was 295 decremented. 297 Ping and ping6 commands are used to measure the latency to all 298 discovered peers. Tracepath and tracepath6 commands are used to 299 measure the TTL and the MTU between peers. Of course, when the IPv6 300 connectivity of a peer is through a transition mechanism such as 6to4 301 or Teredo, then it is easy to extract the IPv4 address of the peer 302 from its IPv6 address and comparaison can be done. 304 4. What was measured 306 The measurements were done in two periods: 308 o May 2009 to July 2009: 5,000,000 peers were discovered but we 309 were only able to to establish a BitTorrent connection with 310 1,500,000 peers; 312 o 1 day in October 2009: 100,000 peers were discovered. 314 The number of peers to which we managed to establish a BitTorrent 315 connection may seem low in comparison with the number of discovered 316 peers but is not. In fact, certain peers are already disconnected 317 when we obtain information about them. The study made by Tribler on 318 PEX clearly indicated that information retrieved by PEX is mostly 319 garbage. Furthermore, when a BitTorrent client has reached its 320 maximum number of connections, it rejects connection attempts made by 321 remote peers and stops initiating new connections. These are the two 322 principal reasons that explain the difference between the number of 323 discovered peers and peers we were connected to. 325 4.1. IPv6 BitTorrent Clients 327 Among the 621,625 peers whose client is known to us, 542,537 of them 328 utilized one which supports IPv6, that is 87.28%. We could adjust 329 the percentage of peers having IPv6 connectivity with this 330 information. However, the IPv6 results will not be adjusted with 331 this value since it has no influence on the different proportion 332 analyzed. And among the 542,537 peers that used a BitTorrent client 333 that supports IPv6, 53,828 were using IPv6, that is 9.92%. 335 4.2. IPv6 Addresses 337 We will now analyze the 142,904 distinct IPv6 addresses found via the 338 different protocols and classify them into different categories. The 339 next section will explain the utilization of these addresses over the 340 world in greater detail. 342 +------------+--------+--------+--------+--------+----------------+ 343 | | Native | Teredo | 6to4 | ISATAP | Tunnel Brokers | 344 +------------+--------+--------+--------+--------+----------------+ 345 | Number | 1,216 | 99,634 | 41,425 | 24 | 102 | 346 | Percentage | 0.85 | 69.72 | 28.99 | 0.02 | 0.08 | 347 +------------+--------+--------+--------+--------+----------------+ 349 Table 1: Different Types of IPv6 Addresses 351 +------------+-------+----------+---------------+-----------+-------+ 352 | | 6bone | Site | IPv4 | IPv4 | Bogon | 353 | | | Local | Compatible | Mapped | | 354 +------------+-------+----------+---------------+-----------+-------+ 355 | Number | 436 | 24 | 1 | 94 | 74 | 356 | Percentage | 0.31 | 0.02 | 0.00 | 0.07 | 0.05 | 357 +------------+-------+----------+---------------+-----------+-------+ 359 Table 2: Different Types of IPv6 Addresses (Cont.) 361 4.2.1. Native IPv6 363 Only 1,216 distinct native IPv6 addresses were discovered in 28 364 different countries during our study. More than 73% of these 365 addresses came from the French ISP Free. Even if we downloaded 366 torrents whose names contained either FRENCH or VOSTFR we were not 367 connected to more French peers than Italian peers, for instance. As 368 the high number of native IPv6 addresses from France is not due to 369 the high number of peers from France, this phenomenon can be 370 explained principally because Free seems to be the only large ISP 371 that proposes IPv6 connectivity. We also noticed that many 372 Universities and institutes around the world offer IPv6 connectivity 373 especially in Portugal where there are nine of them, which is more 374 than any other country. 376 4.2.2. Teredo 378 Teredo with 69.72% of IPv6 addresses found is clearly the most 379 utilized way to get IPv6 connectivity. This ratio is also unsually 380 high compared to other Internet measurements. It is probably linked 381 to: 383 o users: BiTorrent users are mainly residential and not 384 professional, therefore Teredo is allowed to traverse the firewall 385 while most enterprises block all outbound UDP traffic (and 386 blocking Teredo in the same shot); 388 o application: Teredo is only used by Windows to connect to an IPv6 389 which does not have any IPv4 address (in other word [RFC3484] 390 severelly limits the normal use of Teredo), but, with BitTorrent 391 the peers appear always as single stack. 393 When we analyze the servers employed to configure these addresses we 394 notice that only three servers represent more than 99% of the 395 utilized ones. Their addresses are as follows : 397 1. 213.199.162.214 : is deployed by Microsoft (46.12%); 399 2. 65.55.158.80 : is also set up by Microsoft (41.33%); 401 3. 207.46.48.150 : is once more owned by Microsoft (12.41%). 403 Thus more than 99% of the peers that were using Teredo were likely to 404 be using one of the Microsoft Operating Systems. A test on my 405 personal computer showed that Miredo, which is a type of Teredo IPv6 406 tunneling software for Linux, does not use one of the Microsoft 407 Teredo servers. 409 4.2.3. 6to4 411 6to4 is also broadly used to provide IPv6 connectivity as 28.99% of 412 the addresses found were created by this transition mechanism. 413 Nevertheless, it is still far behind Teredo. As 6to4 is designed to 414 provide IPv6 connectivity to many hosts with a single public IPv4 415 address, we checked if many 6to4 hosts were using the same 6to4 416 router. The result is not very satisfactory since 99.47% of the 6to4 417 hosts employ a distinct 6to4 router. However, we noticed that 9 418 hosts were using the same 6to4 router which is quite high. It seems 419 that the 6to4 mechanism is mostly used for small LAN and not by large 420 sites. 422 6to4 is more commonly used than native IPv6. We found 6to4 users in 423 almost every country in Europe. The USA has far more 6to4 users than 424 other countries. 426 4.2.4. Tunnel Brokers 428 We can determine, via the list of Tunnel Brokers of the SixXS service 429 [[TFE28]] and IPv6 Task Force [[TFE29]] websites, whether an ISP is a 430 tunnel broker. Unfortunately, these lists are not exhaustive so we 431 may have missed a peer using a Tunnel Broker. However, as we are 432 aware of the largest Tunnel Broker, those we missed should be small 433 and thus cannot really influence the result. No dynamic 434 identification of the Tunnel Broker was implemented due to the 435 difficulty of identifying them all. The Tunnel Brokers in Table 3 436 that we discovered represent only 0.08% of the IPv6 addresses found. 438 +--------------------+-------------+--------+------------+ 439 | Tunnel Broker | Region | Number | Percentage | 440 +--------------------+-------------+--------+------------+ 441 | Hurricane Electric | Worldwide | 25 | 24.51 | 442 | Internode | Australia | 2 | 1.96 | 443 | Hexago | Canada | 22 | 21.57 | 444 | SixXs | Worldwide | 49 | 48.04 | 445 | XS4ALL | Netherlands | 4 | 3.92 | 446 +--------------------+-------------+--------+------------+ 448 Table 3: List of Tunnel Brokers 450 Only 5 different Tunnel Brokers were found. The most widely used one 451 is SixXS with 48.04% of the total Tunnel Broker utilization. We 452 noticed that 61% of the peers that were using this Tunnel Broker came 453 from the Czech Republic. Hexago is rather popular for a Tunnel 454 Broker that operates only in Canada. 456 4.2.5. ISATAP 458 We only discovered 24 different peers that used ISATAP ([RFC4212]) to 459 get IPv6 connectivity in a non IPv6-capable infrastructure. Half of 460 these addresses have a global unicast prefix and the other half have 461 a 6to4 prefix. This mechanism is less common than Teredo ([RFC4380]) 462 and 6to4 ([RFC3056]). However, this bad result can be moderated by 463 the fact that ISATAP is mostly destined to enterprises which often 464 have a strict control on applications used by their employees. Thus 465 installing a BitTorrent client is not often possible, and even if it 466 is the firewall can filter its traffic. 468 4.2.6. Other Addresses 470 Although IPv6 addresses with the 6bone prefix should not exist 471 anymore we found up to 436 addresses with this prefix. In fact, all 472 these addresses have the old Teredo prefix 3ffe:831f::/32 which was 473 used in the 6bone network. 475 We found 94 IPv4-mapped addresses that were all discovered by PEX. 477 Bogons are IP blocks that are reserved for private or special uses 478 plus those that are not yet allocated by the IANA. Thus a bogon is 479 an illegal IP address that must not appear on the Internet since they 480 are theoretically unroutable. At present, the IPv6 unicast space is 481 limited to the 2000::/3 prefix. During our study we discovered up to 482 74 bogons via PEX, most of which had the b524::/16 prefix. 484 We found 24 site-local addresses via PEX. These addresses came from 485 peers that were connected to other peers in their site that they 486 found via LSD. These addresses are obviously useless to us since we 487 are not in the same site. 489 4.2.7. Summary about IPv6 Addresses 491 The most impressive results are those of Teredo and 6to4 that 492 represent together 98.71% of IPv6 addresses discovered. The native 493 IPv6 addresses form only a very small fraction of the total. 495 Another important conclusion is that PEX is not ideally implemented 496 in many BitTorrent clients since they exchange data that cannot be 497 used by the remote peers like bogons or addresses reserved for the 498 private-use networks. Filtering the addresses to send via PEX avoids 499 wasting processing time to initiate connections that cannot be 500 established and limits the number of addresses to send which saves 501 bandwidth. 503 4.3. Traffic Measurements 505 Most of the European countries have at least 3% of their peers using 506 IPv6 with better results for Sweden, Portugal and Latvia. Another 507 surprising fact is that China has only 2.64% of its peers using IPv6 508 which seems strange since China is one of the leading countries in 509 IPv6 deployment. This result may be negatively affected by the 510 filter set up in this country. Even if they have many free IPv4 511 block left, the USA still has more than 4.8% of their peers using 512 IPv6 which is more than their current policy supposes. 514 As explained in the analysis of IPv6 addresses section, we only found 515 few native IPv6 addresses. This analysis confirms what we discussed 516 previously, which is that Japan and France have the highest rate with 517 1.09% and 0.65% respectively. China with 0.65%, has a good 518 percentage in comparison with other countries. This is explained by 519 its interest to widely deploy native IPv6. Thus China has 520 particularly poor results concerning 6to4 and Teredo traffic. 522 4.4. Comparaison IPv4 vs. IPv6 524 In this section we will compare the two IP versions with different IT 525 statistics to find out whether the new version is really better. Of 526 course, we must take into account the fact that IPv6 transition 527 mechanisms have a structure that can considerably influence certain 528 statistics. We will thus treat the IPv6 peers differently according 529 to the mechanism they use, if they use one at all. 531 4.5. Round-Trip Time 533 First of all, even if we tried to obtain RTT statistics about each 534 peer we did not get it all because some were disconnected when we did 535 the test and others were not reachable via ICMP as many routers do 536 not forward this type of ICMP message. We obtained this information 537 for approximately 36% of the IPv4 peers and 18% of the IPv6 ones. 539 As we tested it for IPv4 addresses embedded in IPv6 ones we will 540 compare the two results. We have the RTT information of 32% of the 541 embedded IPv4 addresses, most of which come from 6to4. As a matter 542 of fact, many NAT devices block the ICMP traffic which explains why 543 we have so little RTT information about IPv4 addresses embedded in 544 Teredo ones. 546 Table 4 indicates at first sight that IPv4 is two times faster than 547 IPv6. This global result is not representative of the new IP version 548 speed as it is greatly influenced by the transition mechanisms that 549 are normally much slower than native connectivity. The standard 550 deviation average concerns the average of the standard deviation of 551 all peers made thanks to the three different attempts. 553 +--------------------+-------+-------+ 554 | Global | IPv4 | IPv6 | 555 +--------------------+-------+-------+ 556 | Average | 324.8 | 812.8 | 557 | Standard Deviation | 403.6 | 890.8 | 558 +--------------------+-------+-------+ 560 Table 4: Global RTT Information in msec 562 Table 5 shows the results of the native IPv6 peers in comparison with 563 those of the IPv6 (all kind of connectivity) and IPv4 peers. We can 564 immediately see that the IPv6 RTT average is clearly smaller than the 565 global IPv6 RTT average. However, the IPv6 RTT average is still 566 higher than that of IPv4 but this difference can be explained by the 567 current structure of the Internet: where even if the peer has native 568 IPv6 connectivity, it does not mean that the IPv6 peering agreements 569 of his/her ISP are as good as their IPv4 ones. This inconvenience 570 should be reduced by the IPv6 deployment evolution. The average of 571 the standard deviation of IPv6 peers is particularly high which 572 implies that different attempts gave highly different results. 574 +-----------------+--------------------+--------------------+-------+ 575 | | Native IPv6 | All IPv6 | IPv4 | 576 | | connectivity | connectivity | | 577 +-----------------+--------------------+--------------------+-------+ 578 | Average | 493.1 | 812.8 | 324.8 | 579 | Standard | 646.3 | 890.8 | 403.6 | 580 | Deviation | | | | 581 +-----------------+--------------------+--------------------+-------+ 583 Table 5: Native IPv6 RTT Information in msec 585 4.6. Comparaison of Hops 587 We will analyze the TTL and Hop Limit on the path from the remote 588 peers to us for which we obtained more than 1,300,000 statistics 589 about IPv4 peers and more than 90,000 about IPv6 peers. We observe 590 in Table 6 that the number of routers on the path from IPv4 peers is 591 superior to the number of routers from IPv6 peers but not to that of 592 native IPv6 which is quite coherent. As a matter of fact, as the Hop 593 Limit is not decremented in the tunnel, its value arrives higher at 594 the destination. The fact that there is a higher number of routers 595 between native IPv6 peers and us also seems logical as the number of 596 interconnections in the IPv6 Internet is smaller than in the IPv4 597 Internet and that may result in a longer path. 599 +-----------+-------+-------+-------------+ 600 | Hop count | IPv4 | IPv6 | Native IPv6 | 601 +-----------+-------+-------+-------------+ 602 | Average | 15.10 | 11.93 | 18.12 | 603 +-----------+-------+-------+-------------+ 605 Table 6: Native IPv6 RTT Information in msec 607 4.7. MTU Comparaison 609 We obtained more than 190,000 MTU statistics about IPv6 peers and 610 more than 1,800,000 about IPv4 peers, which gives us a sufficient 611 sample. 613 Table 7 shows the different MTU results depending on the IP version 614 and whether the path MTU discovery reached the destination. 615 Unsurprisingly, the global IPv6 MTU is far smaller than the IPv4 one 616 as more than 98% of the addresses where formed thanks to a tunneling 617 mechanism. The results of the native IPv6 peers are much higher but 618 are still inferior to those of IPv4. 620 +---------+---------+---------+-------------+ 621 | MTU | IPv4 | IPv6 | Native IPv6 | 622 +---------+---------+---------+-------------+ 623 | Average | 1,497.6 | 1,288.9 | 1,468.0 | 624 +---------+---------+---------+-------------+ 626 Table 7: Native IPv6 RTT Information in msec 628 4.8. Monthly Evolution 630 The monthly analysis done in 2009, shown in Table 8, allows us to see 631 this decrease more clearly with 1.7% lost between the month of June 632 and July. As July is a holiday month, the sharing habits may be 633 different. As a matter of fact, most downloaders are students. 634 However, this hypothesis does not explain why the IPv6 traffic 635 decreases. The fact that Universities, which may have IPv6 636 connectivity, may be closed during the holidays and thus prevent 637 students from using their bandwidth cannot explain this reduction as 638 the percentage of IPv6 traffic coming from Universities is very low. 639 Nevertheless, this decline from the Universities exists as IPv6 640 traffic in July diminished by more than three times when compared to 641 results in June. 643 Once more the peers that were solely discovered via DHT are not taken 644 into account in the IPv6 evolution analysis. 646 +-----------------+----------+-----------+-----------+--------------+ 647 | | May 2009 | June 2009 | July 2009 | October 2009 | 648 +-----------------+----------+-----------+-----------+--------------+ 649 | %-age of IPv6 | 4.50 | 4.79 | 3.10 | 2.30 | 650 | peers | | | | | 651 +-----------------+----------+-----------+-----------+--------------+ 653 Table 8: Monthly Evolution of IPv6 vs IPv4 peers 655 4.9. Protocols Used to Discover Peers 657 In this section we will look at the effectiveness of the different 658 protocols to discover peers. As we can see in Table 9, PEX is 659 globally far more effective to find peers than other means. It is 660 even more efficient for IPv6 in comparison with the performance of 661 trackers. 663 +---------+-----------+---------+-----------+ 664 | Source | IPv4 | IPv6 | Total | 665 +---------+-----------+---------+-----------+ 666 | Tracker | 1,550,023 | 37,745 | 1,587,768 | 667 | PEX | 3,558,648 | 167,606 | 3,726,254 | 668 | DHT | 843,353 | 0 | 843,353 | 669 | LSD | 0 | 0 | 0 | 670 +---------+-----------+---------+-----------+ 672 Table 9: Number of Valid Peers Discovered by Protocol 674 Concerning DHT, we have never been able to get IPv6 peers by this 675 means because of incompatibilities between BitTorrent clients and 676 because of problems in the LibTorrent Rasterbar library. But if we 677 look at the Table 9, the DHT results are not as good as the other 678 means. 680 The good performance of PEX can be explained by its exponential way 681 of functioning. As a matter of fact, via a small number of peers a 682 large number of peers can be reached. However, as already explained, 683 the proportion of disposable information is very important. 685 We did not receive any peers via LSD either since no other computer 686 was running a BitTorrent client in the local network. Nevertheless, 687 it was functioning during all our study. 689 5. IANA Considerations 691 There are no extra IANA consideration for this document. 693 6. Security Considerations 695 This I-D does not describe any specific protocol, so, the security 696 section is mostly irrelevant. The measures were done with the 697 specific security issues in mind: 699 o copyrighted content: only a first fragment is downloaded and 700 never stored on long term storage, so, it is assumed that even if 701 copyrighted content is actually received it will never be user or 702 propagated further to other peers; 704 o denial of services: timers and rate limiters are used when 705 getting the list of torrents from our directory, when contacting 706 other peers, and so on 708 7. Acknowledgements 710 Many thanks to Professor Guy Leduc of the University of Liege and his 711 research assistants, Cyril Soldani and Sylvain Martin. Martin is 712 also grateful to Arvid Norberg who implemented the LibTorrent 713 Rasterbar library [[TFE23]]. We also exchanged ideas with Nathan 714 Ward. 716 8. References 718 8.1. Normative References 720 [TFE12] Hazel, G., "IPv6 Tracker Extension", May 2008, 721 . 723 [TFE13] Maymounkov, P., "Kademlia : A Peer-to-peer Information 724 System Based on the XOR Metric". 726 [TFE28] SixXs, "List of Tunnel Brokers", 727 . 729 [TFE29] IPv6 Task Force, "List of Tunnel Brokers", . 732 [TFE5] Cohen, B., "The BitTorrent Protocol Specification", 2008, 733 . 735 8.2. Informative References 737 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 738 via IPv4 Clouds", RFC 3056, February 2001. 740 [RFC3484] Draves, R., "Default Address Selection for Internet 741 Protocol version 6 (IPv6)", RFC 3484, February 2003. 743 [RFC4212] Blinov, M. and C. Adams, "Alternative Certificate Formats 744 for the Public-Key Infrastructure Using X.509 (PKIX) 745 Certificate Management Protocols", RFC 4212, October 2005. 747 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 748 Network Address Translations (NATs)", RFC 4380, 749 February 2006. 751 [TFE23] Norberg, Arvid., "LibTorrent Rasterbar Library", 752 . 754 [TFE3] Schulze, H., "Internet Study 2008/2009", 2009. 756 [THESIS] Defeche, M., "Measure and Analysis of IPv6 Traffic in 757 Peer-to-Peer Networks. Master Thesis", August 2009. 759 Authors' Addresses 761 Martin Defeche 762 University of Liege 763 Institut Montefiore 764 Bat. B28 Reseaux informatiques 765 Grande Traverse 10 766 Liege 4000 767 Belgium 769 Email: martin.defeche@gmail.com 771 Eric Vyncke 772 Cisco Systems 773 De Kleetlaan 6a 774 Diegem 1831 775 Belgium 777 Phone: +32 2 778 4677 778 Email: evyncke@cisco.com