idnits 2.17.1 draft-vyncke-ipv6-traffic-in-p2p-networks-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 7 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 date (March 2, 2012) is 4436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Defeche 3 Internet-Draft University of Liege 4 Intended status: Informational E. Vyncke, Ed. 5 Expires: September 3, 2012 Cisco Systems 6 March 2, 2012 8 Measuring IPv6 Traffic in BitTorrent Networks 9 draft-vyncke-ipv6-traffic-in-p2p-networks-01 11 Abstract 13 This document is a follow-up of a University thesis which aims to 14 measure the evolution over time of IPv6 traffic and to analyze the 15 geographical distribution of IPv6 nodes. The first measurements were 16 done during the Summer 2009 using a specific-purpose program which 17 connects to the BitTorrent peer-to-peer network and this document 18 adds measurements done with the same program but in October 2011 and 19 February 2012. 21 The study was made in Peer-to-Peer (P2P) networks because they are 22 responsible for a big part of Internet traffic and because their 23 structure and functioning permit a rapid discovery of a large number 24 of nodes from all over the world. In addition, the P2P users are 25 more likely to be interested by IPv6 as IPv6 does not have the same 26 NAT problems as IPv4. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 3, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Some explanations about BitTorrent . . . . . . . . . . . . . . 3 61 2.1. Peer Wire Protocol . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Tracker . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Peer Exchange . . . . . . . . . . . . . . . . . . . . . . 5 64 2.4. Distributed Hash Table . . . . . . . . . . . . . . . . . . 5 65 2.5. Local Service Delivery . . . . . . . . . . . . . . . . . . 6 66 3. Tools used for Measurement . . . . . . . . . . . . . . . . . . 6 67 4. What was measured . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Native IPv6 . . . . . . . . . . . . . . . . . . . . . 8 70 4.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.4. ISATAP . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.5. Other Addresses . . . . . . . . . . . . . . . . . . . 9 74 4.2. Traffic Measurements . . . . . . . . . . . . . . . . . . . 10 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 An IPv6 vs. IPv4 measurement was made in Peer-to-Peer (P2P) networks 86 because they are responsible for most Internet traffic [TFE3] in 2009 87 and because their structure and functioning permit a rapid discovery 88 of a large number of nodes from all over the world. In addition, the 89 P2P users are more likely to be interested by IPv6 as IPv6 does not 90 have the same NAT problems as IPv4. 92 The measurements were made in October 2011 and February 2012 re-using 93 the application developped in October 2009 and presented in 94 [I-D.defeche-ipv6-traffic-in-p2p-networks]. This was part of the 95 Master Thesis [THESIS]. 97 Measurements include: number of IPv4 vs. IPv6 nodes, which kind of 98 IPv6 connectivity and geographical distribution. This measurement is 99 intended to be run multiple times per year and the results are 100 displayed on-line [online]. 102 2. Some explanations about BitTorrent 104 Let's start with some explanations about BitTorrent. 106 BitTorrent is based on an hybrid decentralized network which is 107 particularly well suited to the transfer of large files. BitTorrent 108 generates the largest amount of traffic of all P2P networks and was 109 installed on 28.20% of PCs in September 2007, and this number is 110 certainly higher at present. BitTorrent also includes different 111 protocols to discover peers, namely DHT, PEX and LSD which will be 112 discussed later. Thanks to these mechanisms BitTorrent can be 113 completely decentralized. The different clients are all compatible 114 with the core protocol but some divergences concerning PEX, DHT and 115 LSD appear between Azureus and the mainline, which represents at 116 least the BitTorrent and uTorrent clients. Swarming is one of the 117 basis of the protocol and IPv6 specification exists although it is 118 not implemented by all clients. 120 Since BitTorrent is the only protocol that offers in theory a good 121 support to IPv6, our choice was limited in 2009. But there are other 122 reasons why BitTorrent is the network protocol that best matches our 123 needs. 125 o The number of different copies of the same file(s) is far smaller 126 than in other networks. This leads to a larger number of peers 127 sharing the same file(s). Therefore swarming can be more 128 efficient thanks to a larger number of sources. 130 o As BitTorrent is generally used to share large files, peers stay 131 connected longer, giving us more time to discover them. 133 o BitTorrent is responsible for the largest part of the P2P traffic 134 throughout the world. 136 o BitTorrent is widely used in most regions of the world. 138 o Thanks to many different extensions like PEX (Section 2.3), DHT 139 (Section 2.4) and LSD (Section 2.5), the discovery of peers is 140 improved greatly. 142 2.1. Peer Wire Protocol 144 The Peer wire Protocol [TFE5], or PWP, specifies the way peers 145 communicate in an asynchronous fashion with each other to exchange 146 data and signalling messages. It is based on TCP connections that 147 function in Full-Duplex and Pipelining mode to get better 148 performances. This protocol does not define how to choose pieces to 149 request, nor how to select peers to download from and to upload to. 150 Certain algorithms, which are explained below, give some solutions to 151 attain a good propagation of pieces in the swarm and to make peers 152 happy with their download rate compared to their upload rate. 154 2.2. Tracker 156 The trackers [TFE5] act like servers but do not deal with the 157 transfer of files ; their only purposes are to manage the swarm and 158 to respond to periodic client requests for information about peers 159 sharing the same torrent. Since the transfer of files is completely 160 supported by peers, the bandwidth requirement is very low and thus a 161 single tracker can handle many swarms, each one containing a large 162 number of peers. This protocol commonly called THP is used by 163 clients to communicate over HTTP with trackers. As a matter of fact, 164 the trackers run an HTTP server. Peers contact trackers that are 165 present in the metadata file for the following purposes : 167 o to enter a swarm 169 o to leave a swarm 171 o to inform the tracker that the download is complete 173 o to periodically give information on the download state and 174 retrieve information about a random peer set. This time interval 175 is defined by the tracker. If a peer misses a periodical request 176 it can be considered as disconnected by the tracker and thus not 177 present in the swarm any more 179 This communication permits trackers to keep track of peers that are 180 in the swarm and to avoid referencing disconnected peers. 182 Tracker responses do not support IPv6 peers without this extension 183 [TFE12] which means that they do not include IPv6 peers in their 184 responses. This extension adds two new parameters for the tracker 185 requests: 187 o ipv6 : the client IPv6 address. It can be added when the client 188 contacts the tracker over IPv4; 190 o ipv4 : the client IPv4 address. Conversely, when communication is 191 made over IPv6. 193 It permits clients having a dual stack to advertize both its 194 addresses in the swarm. The port of the additional address is the 195 same as the primary one. 197 2.3. Peer Exchange 199 The Peer Exchange or PEX is a means to discover new peers through 200 peers that the client is already connected to. As a matter of fact, 201 peers trade information concerning the peers they are connected to. 202 Only few initial peers are needed to rapidly find a large number of 203 peers. This mechanism permits a reduction of the tracker load and an 204 improvement in the robustness as the tracker dependency is decreased. 206 2.4. Distributed Hash Table 208 The DHT technology [TFE13] is a way to store a hash table over a 209 network, thus in a distributed way, each peers contains a part of it. 210 Files and nodes are identified by a same length key, which is 20 211 bytes in BitTorrent. Each peer also maintains a list of different 212 peers to efficiently route its searches. DHT in BitTorrent is an 213 implementation of Kademlia which is based on the XOR metric that is 214 the distance between two nodes or between a node and a file can be 215 determined by a XOR of their keys. 217 This technology is used to decentralize the tracking mechanism to 218 once more decrease the dependence on trackers. Even if the trackers 219 are down or if no trackers are specified in the metadata file, the 220 DHT technology permits the discovery of peers sharing the same 221 torrent thanks to the info key hash as identifier. Conversely to 222 PEX, no initial peers are needed. 224 2.5. Local Service Delivery 226 The Local Service Discovery or LSD permits the discovery of peers 227 that are downloading the same torrent in the same local network. The 228 transfer rate is much higher between two peers in the same local 229 network than between two peers in different networks since the 230 bandwidth limitation is that of the local network and not the one of 231 the Internet connection which is far smaller, especially the upload 232 stream. Briefly, LSD works as follows : the hash of the info key is 233 broadcasted in the local network to find out peers sharing the same 234 torrent. 236 3. Tools used for Measurement 238 As millions of pieces of information can be reached, the choice of a 239 MySQL database came naturally for effectiveness reasons and because 240 concurrent access is managed. Each program requests, inserts, and/or 241 updates information in this database. 243 The computer that holds the database and executes the programs has 244 native IPv6 and IPv4 connectivity, which will permit a better 245 evaluation of the two versions than if we use Teredo, for instance. 247 Our specialized BitTorrent client joins different swarms and 248 periodically changes to other swarms. While in a swarm we try to get 249 connected to as many peers as possible thanks to all protocols 250 supported by BitTorrent. In this way we are able to easily, 251 automatically and efficiently discover peers. Ideally we should 252 choose swarms with large numbers of peers in order to effectively 253 retrieve information. Concerning the legality issue, we can use a 254 trick to avoid downloading and uploading any files. In fact, we 255 claim that we are not interested in any pieces so we will not 256 download anything and we will not upload either since we have nothing 257 to upload. So we are present in the swarm but without taking part in 258 the sharing of files. 260 4. What was measured 262 The measurements were done in two periods: 264 o May 2009 to July 2009: 5,000,000 peers were discovered but we were 265 only able to to establish a BitTorrent connection with 1,500,000 266 peers; 268 o 1 day in October 2009: 100,000 peers were discovered; 269 o 1 day in October 2011: 180,000 peers were discovered; 271 o 2 days in February 2012: 664,685 peers were discovered. 273 4.1. IPv6 Addresses 275 We will now analyze the distinct IPv6 addresses found via the 276 different protocols and classify them into different categories. The 277 next section will explain the utilization of these addresses over the 278 world in greater detail. 280 +----------------+--------+--------+--------+--------+--------------+ 281 | | Native | Teredo | 6to4 | ISATAP | Tunnel | 282 | | | | | | Brokers | 283 +----------------+--------+--------+--------+--------+--------------+ 284 | Number in 2009 | 1,216 | 99,634 | 41,425 | 24 | 102 | 285 | Percentage in | 0.85 | 69.72 | 28.99 | 0.02 | 0.08 | 286 | 2009 | | | | | | 287 | Number in 2011 | 258 | 1,280 | 636 | 3 | n/a | 288 | Percentage in | 11.85 | 58.80 | 29.22 | 0.14 | n/a | 289 | 2011 | | | | | | 290 | Number in 2012 | 1,466 | 4,483 | 3,582 | 8 | n/a | 291 | Percentage in | 15.37 | 47.00 | 37.55 | 0.08 | n/a | 292 | 2012 | | | | | | 293 +----------------+--------+--------+--------+--------+--------------+ 295 Table 1: Different Types of IPv6 Addresses 297 The next table describes which weird and plain wrong IPv6 address our 298 probe has received. It can be expected that a normal BitTorrent 299 client will try to contact those addresses and therefore will 300 generate packets whose destination IPv6 address is illegal. 302 +----------------+-------+---------+-------------+----------+-------+ 303 | | 6bone | Site | IPv4 | IPv4 | Bogon | 304 | | | Local | Compatible | Mapped | | 305 +----------------+-------+---------+-------------+----------+-------+ 306 | Number in 2009 | 436 | 24 | 1 | 94 | 74 | 307 | Percentage in | 0.31 | 0.02 | 0.00 | 0.07 | 0.05 | 308 | 2009 | | | | | | 309 | Number in 2011 | 0 | 0 | 0 | 0 | 61 | 310 | Percentage in | 0 | 0 | 0 | 0 | 100 | 311 | 2011 | | | | | | 312 | Number in | 0 | 0 | 0 | 2 | 108 | 313 | February 2012 | | | | | | 314 +----------------+-------+---------+-------------+----------+-------+ 316 Table 2: Different Types of IPv6 Addresses (Cont.) 318 4.1.1. Native IPv6 320 In the 2011 study, only 197 distinct native IPv6 addresses were 321 discovered in 25 different countries during our study. More than 40 322 % of these addresses came from the French ISP Free. 324 In the February 2012 study, many native IPv6 addresses have been 325 discovered 1,466 (15% of all IPv6 addresses). France has still the 326 highest ratio of native IPv6 addresses vs any addresses with 2.10% of 327 the French BitTorrent peers using IPv6 (again Free being the largest 328 followed by SFR). The next countries are: 330 o Chine with 0.65% (only CERNET) 332 o Japan with 0.59% (mainly KDDI) 334 o United-States of America: 0.51% (mainly AT&T but also Comcast, 335 Hurricane Electric and Verizon) 337 4.1.2. Teredo 339 Teredo with 47 % of IPv6 addresses found is clearly the most utilized 340 way to get IPv6 connectivity. This ratio is also unsually high 341 compared to other Internet measurements. It is probably linked to: 343 o users: BiTorrent users are mainly residential and not 344 professional, therefore Teredo is allowed to traverse the firewall 345 while most enterprises block all outbound UDP traffic (and 346 blocking Teredo in the same shot) and the most common Teredo 347 implementation (Microsoft) also disables Teredo when used in an 348 Active Directory network; 350 o application: Teredo is only used by Windows to connect to an IPv6 351 which does not have any IPv4 address (in other word [RFC3484] 352 severelly limits the normal use of Teredo), but, with BitTorrent 353 the peers appear always as single stack (i.e. it appears like 354 having only an IPv6 address even if it actually have both version 355 of the IP protocol). 357 When we analyze the servers employed to configure these addresses we 358 notice that only four servers represent 99.6 % of the used ones. 359 Their addresses are as follows (February 2012 but mostly unchanged 360 compared to 2011): 362 1. 65.55.158.118 : is deployed by Microsoft (58.80 %); 364 2. 94.245.115.184 : is deployed by Microsoft ( 1.3 %); 365 3. 94.245.121.251 : is deployed by Microsoft (17.20 %); 367 4. 94.245.121.253 : is deployed by Microsoft (22.30 %); 369 while in October 2009, three different servers represented 99 % of 370 the traffic: 372 1. 213.199.162.214 : is deployed by Microsoft (46.12%); 374 2. 65.55.158.80 : is also set up by Microsoft (41.33%); 376 3. 207.46.48.150 : is once more owned by Microsoft (12.41%). 378 Thus 100 % of the peers that were using Teredo were likely to be 379 using one of the Microsoft Operating Systems. 381 4.1.3. 6to4 383 6to4 is also still broadly used to provide IPv6 connectivity with 384 37.55% in February 2012, 29.21 % in 2011 and was 28.99 % in 2009 were 385 created by this transition mechanism. Nevertheless, it is still far 386 behind Teredo. It must be noted that the proportion of 6to4 nodes 387 has not decreased as indicated by other measurements, but, the other 388 measurements count only the web access to dual-stack servers where 389 happy eye-balls [I-D.ietf-v6ops-happy-eyeballs] and [RFC3484] can 390 influence the browser behavior in order to avoid all tunneling (this 391 includes Teredo and 6to4). 393 4.1.4. ISATAP 395 We only discovered 8 different peers that used ISATAP ([RFC5214]) to 396 get IPv6 connectivity in a non IPv6-capable infrastructure. This 397 mechanism is less common than Teredo ([RFC4380]) and 6to4 398 ([RFC3056]). However, this bad result can be moderated by the fact 399 that ISATAP is mostly destined to enterprises which often have a 400 strict control on applications used by their employees. Thus 401 installing a BitTorrent client is not often possible, and even if it 402 is the firewall can filter its traffic. 404 4.1.5. Other Addresses 406 Although IPv6 addresses with the 6bone prefix should not exist 407 anymore, in October 2009 we found up to 436 addresses with this 408 prefix. In fact, all these addresses have the old Teredo prefix 409 3ffe:831f::/32 which was used in the 6bone network. The 6bone 410 addresses are no more visible in 2011 and 2012. 412 In October 2009, we found 94 IPv4-mapped addresses that were all 413 discovered by PEX. 415 The good news is that in February 2012, we found not a single 6bone 416 address and only 2 IPv4-mapped addresses in our peers. 418 Bogons are IP blocks that are reserved for private or special uses 419 plus those that are not yet allocated by the IANA. Thus a bogon is 420 an illegal IP address that must not appear on the Internet since they 421 are theoretically unroutable. At present, the IPv6 unicast space is 422 limited to the 2000::/3 prefix. During our study we discovered up to 423 1108 bogons via PEX. 425 4.2. Traffic Measurements 427 Most of the European countries have at least 1 % of their peers that 428 can use IPv6 with better results for Latva (3.88%), France (3.02%), 429 Finland (2.90%), Romania (2.83%). The first non-European country is 430 Chile with 2.78%. Another surprising fact is that China has only 431 1.19 % of its peers using IPv6 with 0.65% being native IPv6. This 432 result may be negatively affected by the filter set up in this 433 country. 435 As explained in the analysis of IPv6 addresses section, we only found 436 few native IPv6 addresses. This analysis confirms what we discussed 437 previously, which is that Japan and France have the highest rate but 438 they are now joined by 'newcomers' such as China, USA but also Czech 439 Republic and Slovenia. 441 5. IANA Considerations 443 There are no extra IANA consideration for this document. 445 6. Security Considerations 447 This I-D does not describe any specific protocol, so, the security 448 section is mostly irrelevant. The measures were done with the 449 specific security issues in mind: 451 o copyrighted content: only a first fragment is downloaded and never 452 stored on long term storage, so, it is assumed that even if 453 copyrighted content is actually received it will never be user or 454 propagated further to other peers; 456 o denial of services: timers and rate limiters are used when getting 457 the list of torrents from our directory, when contacting other 458 peers, and so on 460 7. Acknowledgements 462 Many thanks to Professor Guy Leduc of the University of Liege and his 463 research assistants, Cyril Soldani and Sylvain Martin. Martin is 464 also grateful to Arvid Norberg who implemented the LibTorrent 465 Rasterbar library [TFE23]. We also exchanged ideas with Nathan Ward. 467 8. References 469 8.1. Normative References 471 [TFE12] Hazel, G., "IPv6 Tracker Extension", May 2008, 472 . 474 [TFE13] Maymounkov, P. and D. Mazieres, "Kademlia : A Peer-to-peer 475 Information System Based on the XOR Metric", 2002, . 479 [TFE5] Cohen, B., "The BitTorrent Protocol Specification", 2008, 480 . 482 8.2. Informative References 484 [I-D.defeche-ipv6-traffic-in-p2p-networks] 485 Defeche, M. and E. Vyncke, "Measuring IPv6 Traffic in 486 BitTorrent Networks", 487 draft-defeche-ipv6-traffic-in-p2p-networks-00 (work in 488 progress), October 2009. 490 [I-D.ietf-v6ops-happy-eyeballs] 491 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 492 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 493 (work in progress), December 2011. 495 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 496 via IPv4 Clouds", RFC 3056, February 2001. 498 [RFC3484] Draves, R., "Default Address Selection for Internet 499 Protocol version 6 (IPv6)", RFC 3484, February 2003. 501 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 502 Network Address Translations (NATs)", RFC 4380, 503 February 2006. 505 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 506 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 507 March 2008. 509 [TFE23] Norberg, A., "LibTorrent Rasterbar Library", 510 . 512 [TFE3] Schulze, H., "Internet Study 2008/2009", 2009. 514 [THESIS] Defeche, M., "Measure and Analysis of IPv6 Traffic in 515 Peer-to-Peer Networks. Master Thesis", August 2009. 517 [geoip] Maxmind, "GeoLite Country", 2012, 518 . 520 [online] Vyncke, E., "IPv6-enabled BitTorrent Peers", 521 . 523 Authors' Addresses 525 Martin Defeche 526 University of Liege 528 Email: martin.defeche@gmail.com 530 Eric Vyncke (editor) 531 Cisco Systems 532 De Kleetlaan 6a 533 Diegem 1831 534 Belgium 536 Email: evyncke@cisco.com