<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY RFC4212 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4212.xml">
<!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">

]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>

<rfc category="info" ipr="pre5378Trust200902" docName="<draft-defeche-ipv6-traffic-in-p2p-networks-00.txt>">

<front>

<title abbrev="IPv6 Traffic in BitTorrent">
Measuring IPv6 Traffic in BitTorrent Networks
</title>

	<author initials="M" surname="Defeche" fullname="Martin Defeche">
      <organization>University of Liege</organization>
      <address>
        <postal>
          <street>Institut Montefiore</street>
		  <street>Bat. B28 Reseaux informatiques</street>
          <street>Grande Traverse 10</street>
          <city>Liege</city>
          <country>Belgium</country>
          <code>4000</code>
        </postal>
        <email>martin.defeche@gmail.com</email>
      </address>
    </author>

     <author initials="E" surname="Vyncke" fullname="Eric Vyncke">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>De Kleetlaan 6a</street>
          <city>Diegem</city>
          <country>Belgium</country>
          <code>1831</code>
        </postal>
        <phone>+32 2 778 4677</phone>
        <email>evyncke@cisco.com</email>
      </address>
    </author>


<date day="16" month="October" year="2009"></date>
<workgroup>IPv6 Operations</workgroup>
<keyword>IPv6 Traffic</keyword>
<keyword>Measurements</keyword>
<keyword>BitTorrent</keyword>

<abstract>
<t>
This document summarizes a University thesis which aims to measure the evolution over time of IPv6 traffic, 
to analyze
the geographical distribution of IPv6 nodes and to compare the two Internet Protocol
versions on many different criteria (RTT, latency, MTU). 
The measurements were done during the Summer 2009 using a specific-purpose program which
connects to the BitTorrent peer-to-peer network.
</t>
<t>
The study was made in Peer-to-Peer (P2P) networks because they are responsible
for most Internet traffic and because their structure and functioning permit a rapid
discovery of a large number of nodes from all over the world. In addition, the P2P users
are more likely to be interested by IPv6 as IPv6 does not have the same NAT problems
as IPv4.
</t>
</abstract>

</front>

<middle>

<section anchor="intro" title="Introduction">
  
	<t>
An IPv6 vs. IPv4 measurement was made in Peer-to-Peer (P2P) networks because they are responsible
for most Internet traffic <xref target="TFE3" /> and because their structure and functioning permit a rapid
discovery of a large number of nodes from all over the world. 
In addition, the P2P users
are more likely to be interested by IPv6 as IPv6 does not have the same NAT problems
as IPv4.
</t>
<t>
The measurements were made in May, June, July and October 2009 to get an idea of the evolution
within a couple of months. The intend is to run the same measurements every month for
a couple of years.
</t>	
<t>
Measurements include: number of IPv4 vs. IPv6 nodes, which kind of IPv6 connectivity, comparing the MTU,
RTT between the two versions of IP and geographical distribution.
</t>
</section>

<section anchor="bittorrent" title="Some explanations about BitTorrent">
<t>
Let's start with some explanations about BitTorrent.
</t>
	<t>
BitTorrent is based on an hybrid decentralized network which is particularly well
suited to the transfer of large files. BitTorrent generates the largest amount of traffic
of all P2P networks and was installed on 28.20% of PCs in September 2007, and this
number is certainly higher at present. BitTorrent also includes different protocols to
discover peers, namely DHT, PEX and LSD which will be discussed later. Thanks
to these mechanisms BitTorrent can be completely decentralized. The different clients
are all compatible with the core protocol but some divergences concerning PEX, DHT
and LSD appear between Azureus and the mainline, which represents at least the
BitTorrent and µTorrent clients. Swarming is one of the basis of the protocol and IPv6
specification exists although it is not implemented by all clients.
	</t>
	<t>
	Since BitTorrent is the only protocol that offers in theory a good support to IPv6,
our choice is limited. But there are other reasons why BitTorrent is the network protocol
that best matches our needs.
<list style="symbols">
	<t>The number of different copies of the same file(s) is far smaller than in other
networks. This leads to a larger number of peers sharing the same file(s). Therefore
swarming can be more efficient thanks to a larger number of sources.</t>
	<t>As BitTorrent is generally used to share large files, peers stay connected longer, 
	giving us more time to discover them.</t>
	<t>BitTorrent is responsible for the largest part of the P2P traffic throughout the
world.</t>
	<t>BitTorrent is widely used in most regions of the world.</t>
	<t>Thanks to many different extensions like <xref target="PEX">PEX</xref>, 
	<xref target="DHT">DHT</xref>
 and <xref target="LSD">LSD</xref>, the discovery of peers is improved greatly.</t>
</list>
</t>
<section anchor="PWP" title="Peer Wire Protocol">
<t>
The Peer wire Protocol [<xref target="TFE5"/>], or PWP, specifies the way peers communicate in an
asynchronous fashion with each other to exchange data and signalling messages. It is
based on TCP connections that function in Full-Duplex and Pipelining mode to get
better performances. This protocol does not define how to choose pieces to request,
nor how to select peers to download from and to upload to. Certain algorithms, which
are explained below, give some solutions to attain a good propagation of pieces in the
swarm and to make peers happy with their download rate compared to their upload
rate.
</t>
</section>
<section title="Tracker">
<t>
The trackers [<xref target="TFE5"/>] act like servers but do not deal with the transfer of files ; their only
purposes are to manage the swarm and to respond to periodic client requests for information
about peers sharing the same torrent. Since the transfer of files is completely
supported by peers, the bandwidth requirement is very low and thus a single tracker
can handle many swarms, each one containing a large number of peers.
This protocol commonly called THP is used by clients to communicate over HTTP
with trackers. As a matter of fact, the trackers run an HTTP server. Peers contact
trackers that are present in the metadata file for the following purposes :
<list style="symbols">
	<t>to enter a swarm</t>
	<t>to leave a swarm</t>
	<t>to inform the tracker that the download is complete</t>
	<t>to periodically give information on the download state and retrieve information
	about a random peer set. This time interval is defined by the tracker. If a peer
	misses a periodical request it can be considered as disconnected by the tracker
	and thus not present in the swarm any more</t>
</list>
This communication permits trackers to keep track of peers that are in the swarm and
to avoid referencing disconnected peers.
</t>
<t>
Tracker responses
do not support IPv6 peers without this extension [[<xref target="TFE12"/>]] which means that they do not
include IPv6 peers in their responses. This extension adds two new parameters for the
tracker requests:
<list style="symbols">
	<t>ipv6 : the client IPv6 address. It can be added when the client contacts the tracker
	over IPv4;</t>
	<t>ipv4 : the client IPv4 address. Conversely, when communication is made over IPv6.</t>
</list>
It permits clients having a dual stack to advertize both its addresses in the swarm. The
port of the additional address is the same as the primary one.
</t>
</section>
<section anchor="PEX" title="Peer Exchange">
<t>
The Peer Exchange or PEX is a means to discover new peers through peers that the
client is already connected to. As a matter of fact, peers trade information concerning
the peers they are connected to. Only few initial peers are needed to rapidly find a
large number of peers. This mechanism permits a reduction of the tracker load and an
improvement in the robustness as the tracker dependency is decreased.
</t>
</section>
<section anchor="DHT" title="Distributed Hash Table">
<t>
The DHT technology [<xref target="TFE13"/>] is a way to store a hash table over a network, thus in a
distributed way, each peers contains a part of it. Files and nodes are identified by a
same length key, which is 20 bytes in BitTorrent. Each peer also maintains a list of
different peers to efficiently route its searches. DHT in BitTorrent is an implementation
of Kademlia which is based on the XOR metric that is the distance between two nodes
or between a node and a file can be determined by a XOR of their keys.
</t>
<t>
This technology is used to decentralize the tracking mechanism to once more decrease
the dependence on trackers. Even if the trackers are down or if no trackers are
specified in the metadata file, the DHT technology permits the discovery of peers sharing
the same torrent thanks to the info key hash as identifier. Conversely to PEX, no
initial peers are needed.
</t>
</section>
<section anchor="LSD" title="Local Service Delivery">
<t>
The Local Service Discovery or LSD permits the discovery of peers that are downloading
the same torrent in the same local network. The transfer rate is much higher
between two peers in the same local network than between two peers in different networks
since the bandwidth limitation is that of the local network and not the one of
the Internet connection which is far smaller, especially the upload stream. Briefly, LSD
works as follows : the hash of the info key is broadcasted in the local network to find
out peers sharing the same torrent.
</t>
</section>
</section> <!-- explanations about bittorrent-->

<section anchor="tools" title="Tools used for Measurement">
<t>
As millions of pieces of information can be reached and because this information
is retrieved and handled by five different programs, the choice of a MySQL database
came naturally for effectiveness reasons and because concurrent access is managed.
Each program requests, inserts, and/or updates information in this database.
</t>
<t>
The computer that holds the database and executes the programs runs the operating
system Debian GNU/Linux 5.0 and has native IPv6 and IPv4 connectivity, which
will permit a better evaluation of the two versions than if we use Teredo, for instance.
</t>
<t>
All our programs evolved constantly to better match our needs and to improve their
performance. Most of them where rethought several times to achieve our goals. A long
time was spent to debug the LibTorrent Rasterbar library to get a full IPv6-capable
BitTorrent client and to identify problems that The Pirate Bay had with IPv6.
</t>
<t>
Our specialized BitTorrent client joins different swarms and periodically changes to other swarms.
While in a swarm we try to get connected to as many peers as possible thanks to all
protocols supported by BitTorrent. In this way we are able to easily, automatically and
efficiently discover peers. Ideally we should choose swarms with large numbers of peers
in order to effectively retrieve information. Concerning the legality issue, we can use a
trick to avoid downloading and uploading any files. In fact, we claim that we are not
interested in any pieces so we will not download anything and we will not upload either
since we have nothing to upload. So we are present in the swarm but without taking
part in the sharing of files.
</t>
<t>
As we are interested in the number of routers on the path between us and the remote
peer we must discover the value of the Time-To-Live or Hop Limit depending on the IP
version. Since the TTL or Hop Limit is initially set depending on the operating system,
for instance 64 for Linux, and because the number of routers on the path should not
exceed 32 we can easily calculate the number of times the field was decremented.
</t>
<t>
Ping and ping6 commands are used to measure the latency to all discovered peers.
Tracepath and tracepath6 commands are used to measure the TTL and the MTU between peers. 
Of course, when the IPv6 connectivity of a peer is through a transition mechanism such
as 6to4 or Teredo, then it is easy to extract the IPv4 address of the peer from
its IPv6 address and comparaison can be done.
</t>
</section>

<section anchor="measures" title="What was measured">
<t>
The measurements were done in two periods:
<list style="symbols">
<t>May 2009 to July 2009: 5,000,000 peers were discovered but we were only
  able to to establish a BitTorrent connection with 1,500,000 peers;</t>
<t>1 day in October 2009: 100,000 peers were discovered.</t>
</list>
The number of peers to which we managed to establish a BitTorrent connection 
may seem low in comparison
with the number of discovered peers but is not. In fact, certain peers are already disconnected
when we obtain information about them. The study made by Tribler on PEX
clearly indicated that information retrieved by PEX is mostly garbage. Furthermore,
when a BitTorrent client has reached its maximum number of connections, it rejects
connection attempts made by remote peers and stops initiating new connections. These
are the two principal reasons that explain the difference between the number of discovered
peers and peers we were connected to.
</t>
<section title="IPv6 BitTorrent Clients">
<t>
Among the 621,625 peers whose client is known to us, 542,537 of them utilized
one which supports IPv6, that is 87.28%. We could adjust the percentage of peers
having IPv6 connectivity with this information. However, the IPv6 results will not be
adjusted with this value since it has no influence on the different proportion analyzed.
And among the 542,537 peers that used a BitTorrent client that supports IPv6, 53,828
were using IPv6, that is 9.92%.
</t>
</section>
<section title="IPv6 Addresses">
<t>
We will now analyze the 142,904 distinct IPv6 addresses found via the different protocols
and classify them into different categories.
The next section will explain
the utilization of these addresses over the world in greater detail.
</t>
<texttable anchor="ipv6_addresses" title="Different Types of IPv6 Addresses">

<ttcol></ttcol>
<ttcol>Native</ttcol>
<ttcol>Teredo</ttcol>
<ttcol>6to4</ttcol>
<ttcol>ISATAP</ttcol>
<ttcol>Tunnel Brokers</ttcol>

<c>Number</c>
<c>1,216</c>
<c>99,634</c>
<c>41,425</c>
<c>24</c>
<c>102</c>

<c>Percentage</c>
<c>0.85</c>
<c>69.72</c>
<c>28.99</c>
<c>0.02</c>
<c>0.08</c>
</texttable>

<texttable anchor="ipv6_addresses_cont" title="Different Types of IPv6 Addresses (Cont.)">
<ttcol></ttcol>
<ttcol>6bone</ttcol>
<ttcol>Site Local</ttcol>
<ttcol>IPv4 Compatible</ttcol>
<ttcol>IPv4 Mapped</ttcol>
<ttcol>Bogon</ttcol>

<c>Number</c>
<c>436</c>
<c>24</c>
<c>1</c>
<c>94</c>
<c>74</c>

<c>Percentage</c>
<c>0.31</c>
<c>0.02</c>
<c>0.00</c>
<c>0.07</c>
<c>0.05</c>

</texttable>
<section title="Native IPv6">
<t>
Only 1,216 distinct native IPv6 addresses were discovered in 28 different countries
during our study. More than 73% of these addresses came from the French ISP Free.
Even if we downloaded torrents whose names contained either FRENCH or VOSTFR
we were not connected to more French peers than Italian peers, for instance. As the
high number of native IPv6 addresses from France is not due to the high number of
peers from France, this phenomenon can be explained principally because Free seems
to be the only large ISP that proposes IPv6 connectivity. We also noticed that many
Universities and institutes around the world offer IPv6 connectivity especially in Portugal
where there are nine of them, which is more than any other country.
</t>
</section>
<section title="Teredo">
<t>
Teredo with 69.72% of IPv6 addresses found is clearly the most utilized way to get
IPv6 connectivity. This ratio is also unsually high compared to other Internet
measurements. It is probably linked to:
<list style="symbols">
<t>users: BiTorrent users are mainly residential and not professional, therefore
Teredo is allowed to traverse the firewall while most enterprises block all
outbound UDP traffic (and blocking Teredo in the same shot);</t>
<t>application: Teredo is only used by Windows to connect to an IPv6 which
does not have any IPv4 address (in other word <xref target="RFC3484"/> 
severelly limits
the normal use of Teredo), but, with BitTorrent the peers appear always as
single stack.</t>
</list>
</t>
<t>
When we analyze the servers employed to configure these addresses we notice that
only three servers represent more than 99% of the utilized ones. Their addresses are as
follows :
<list style="numbers">
<t>213.199.162.214 : is deployed by Microsoft (46.12%);</t>
<t>65.55.158.80 : is also set up by Microsoft (41.33%);</t>
<t>207.46.48.150 : is once more owned by Microsoft (12.41%).</t>
</list>
Thus more than 99% of the peers that were using Teredo were likely to be using one of
the Microsoft Operating Systems. A test on my personal computer showed that Miredo,
which is a type of Teredo IPv6 tunneling software for Linux, does not use one of the
Microsoft Teredo servers.
</t>
</section>
<section title="6to4">
<t>
6to4 is also broadly used to provide IPv6 connectivity as 28.99% of the addresses
found were created by this transition mechanism. Nevertheless, it is still far behind
Teredo. As 6to4 is designed to provide IPv6 connectivity to many hosts with a single
public IPv4 address, we checked if many 6to4 hosts were using the same 6to4 router.
The result is not very satisfactory since 99.47% of the 6to4 hosts employ a distinct
6to4 router. However, we noticed that 9 hosts were using the same 6to4 router which
is quite high. It seems that the 6to4 mechanism is mostly used for small LAN and not
by large sites.
</t>
<t>
6to4 is more commonly used than native IPv6. 
We found 6to4 users in almost every country in Europe. The USA
has far more 6to4 users than other countries.
</t>
</section>
<section title="Tunnel Brokers">
<t>
We can determine, via the list of Tunnel Brokers
of the SixXS service [<xref target="TFE28"/>] and 
IPv6 Task Force [<xref target="TFE29"/>] websites, whether an ISP is a tunnel
broker. Unfortunately, these lists are not exhaustive so we may have missed a peer
using a Tunnel Broker. However, as we are aware of the largest Tunnel Broker, those
we missed should be small and thus cannot really influence the result. No dynamic
identification of the Tunnel Broker was implemented due to the difficulty of identifying
them all. The Tunnel Brokers in <xref target="tunnel_brokers"/> 
that we discovered represent only 0.08% of
the IPv6 addresses found.
</t>
<texttable anchor="tunnel_brokers" title="List of Tunnel Brokers">

<ttcol>Tunnel Broker</ttcol>
<ttcol>Region</ttcol>
<ttcol>Number</ttcol>
<ttcol>Percentage</ttcol>

<c>Hurricane Electric</c>
<c>Worldwide</c>
<c>25</c>
<c>24.51</c>

<c>Internode</c>
<c>Australia</c>
<c>2</c>
<c>1.96</c>

<c>Hexago</c>
<c>Canada</c>
<c>22</c>
<c>21.57</c>

<c>SixXs</c>
<c>Worldwide</c>
<c>49</c>
<c>48.04</c>

<c>XS4ALL</c>
<c>Netherlands</c>
<c>4</c>
<c>3.92</c>
</texttable>
<t>
Only 5 different Tunnel Brokers were found. The most widely used one is SixXS
with 48.04% of the total Tunnel Broker utilization. We noticed that 61% of the peers
that were using this Tunnel Broker came from the Czech Republic. Hexago is rather
popular for a Tunnel Broker that operates only in Canada.
</t>
</section>
<section title="ISATAP">
<t>
We only discovered 24 different peers that used ISATAP (<xref target="RFC4212"/>)
to get IPv6 connectivity in
a non IPv6-capable infrastructure. Half of these addresses have a global unicast prefix
and the other half have a 6to4 prefix. This mechanism is less common than Teredo (<xref target="RFC4380"/>)
and 6to4 (<xref target="RFC3056"/>). However, this bad result can be moderated by the fact that ISATAP is mostly
destined to enterprises which often have a strict control on applications used by their
employees. Thus installing a BitTorrent client is not often possible, and even if it is the
firewall can filter its traffic.
</t>
</section>
<section title="Other Addresses">
<t>
Although IPv6 addresses with the 6bone prefix should not exist anymore we found
up to 436 addresses with this prefix. In fact, all these addresses have the old Teredo
prefix 3ffe:831f::/32 which was used in the 6bone network.
</t>
<t>
We found 94 IPv4-mapped addresses that were all discovered by PEX.
</t>
<t>
Bogons are IP blocks that are reserved for private or special uses plus those that
are not yet allocated by the IANA. Thus a bogon is an illegal IP address that must not
appear on the Internet since they are theoretically unroutable. At present, the IPv6
unicast space is limited to the 2000::/3 prefix.
During our study we discovered up to 74 bogons via PEX, most of which had the
b524::/16 prefix.
</t>
<t>
We found 24 site-local addresses via PEX. These addresses came from peers that
were connected to other peers in their site that they found via LSD. These addresses
are obviously useless to us since we are not in the same site.
</t>
</section>
<section title="Summary about IPv6 Addresses">
<t>
The most impressive results are those of Teredo and 6to4 that represent together
98.71% of IPv6 addresses discovered. The native IPv6 addresses form only a very small
fraction of the total.
</t>
<t>
Another important conclusion is that PEX is not ideally implemented in many
BitTorrent clients since they exchange data that cannot be used by the remote peers
like bogons or addresses reserved for the private-use networks. Filtering the addresses
to send via PEX avoids wasting processing time to initiate connections that cannot be
established and limits the number of addresses to send which saves bandwidth.
</t>
</section>
</section> <!-- addresses -->
<section anchor="traffic" title="Traffic Measurements">
<t>
Most of the European countries have at least 3% of their peers using IPv6 with
better results for Sweden, Portugal and Latvia. Another surprising fact is that China
has only 2.64% of its peers using IPv6 which seems strange since China is one of the
leading countries in IPv6 deployment. This result may be negatively affected by the
filter set up in this country. Even if they have many free IPv4 block left, the USA still
has more than 4.8% of their peers using IPv6 which is more than their current policy
supposes.
</t>
<t>
As explained in the analysis of IPv6 addresses section, we only found few native IPv6
addresses. This analysis confirms what we discussed previously, which
is that Japan and France have the highest rate with 1.09% and 0.65% respectively.
China with 0.65%, has a good percentage in comparison with other countries. This
is explained by its interest to widely deploy native IPv6. Thus China has particularly
poor results concerning 6to4 and Teredo traffic.
</t>
</section><!-- traffic-->
<section anchor="compare" title="Comparaison IPv4 vs. IPv6">
<t>
In this section we will compare the two IP versions with different IT statistics
to find out whether the new version is really better. Of course, we must take into
account the fact that IPv6 transition mechanisms have a structure that can considerably
influence certain statistics. We will thus treat the IPv6 peers differently according to
the mechanism they use, if they use one at all.
</t>
</section><!-- comparaison-->
<section title="Round-Trip Time">
<t>
First of all, even if we tried to obtain RTT statistics about each peer we did not
get it all because some were disconnected when we did the test and others were not
reachable via ICMP as many routers do not forward this type of ICMP message. We
obtained this information for approximately 36% of the IPv4 peers and 18% of the
IPv6 ones.
</t>
<t>
As we tested it for IPv4 addresses embedded in IPv6 ones we will compare the two
results. We have the RTT information of 32% of the embedded IPv4 addresses, most of
which come from 6to4. As a matter of fact, many NAT devices block the ICMP traffic
which explains why we have so little RTT information about IPv4 addresses embedded
in Teredo ones.
</t>
<t>
<xref target="rtt" /> indicates at first sight that IPv4 is two times faster than IPv6. This global
result is not representative of the new IP version speed as it is greatly influenced
by the transition mechanisms that are normally much slower than native connectivity.
The standard deviation average concerns the average of the standard deviation of all
peers made thanks to the three different attempts.
</t>
<texttable anchor="rtt" title="Global RTT Information in msec">
<ttcol>Global</ttcol>
<ttcol>IPv4</ttcol>
<ttcol>IPv6</ttcol>

<c>Average</c>
<c>324.8</c>
<c>812.8</c>

<c>Standard Deviation</c>
<c>403.6</c>
<c>890.8</c>
</texttable>
<t>
<xref target="rtt_native"/>
shows the results of the native IPv6 peers in comparison with those
of the IPv6 (all kind of connectivity) and IPv4 peers. 
We can immediately see that the IPv6 RTT average is
clearly smaller than the global IPv6 RTT average.
However, the IPv6 RTT average is still higher than that of IPv4 but this
difference can be explained by the current structure of the Internet: where even if the
peer has native IPv6 connectivity, it does not mean that the IPv6 peering agreements
of his/her ISP are as good as their IPv4 ones.
This inconvenience should be reduced by the IPv6 deployment evolution. The average
of the standard deviation of IPv6 peers is particularly high which implies that different
attempts gave highly different results.
</t>
<texttable anchor="rtt_native" title="Native IPv6 RTT Information in msec">
<ttcol></ttcol>
<ttcol>Native IPv6 connectivity</ttcol>
<ttcol>All IPv6 connectivity</ttcol>
<ttcol>IPv4</ttcol>

<c>Average</c>
<c>493.1</c>
<c>812.8</c>
<c>324.8</c>

<c>Standard Deviation</c>
<c>646.3</c>
<c>890.8</c>
<c>403.6</c>
</texttable>
</section><!--rtt-->
<section anchor="ttl" title="Comparaison of Hops">
<t>
We will analyze the TTL and Hop Limit on the path from the remote peers
to us for which we obtained more than 1,300,000 statistics about IPv4 peers and more
than 90,000 about IPv6 peers. We observe in <xref target="ttl_table"/> that the number of routers on
the path from IPv4 peers is superior to the number of routers from IPv6 peers but not
to that of native IPv6 which is quite coherent. As a matter of fact, as the Hop Limit
is not decremented in the tunnel, its value arrives higher at the destination. The fact
that there is a higher number of routers between native IPv6 peers and us also seems
logical as the number of interconnections in the IPv6 Internet is smaller than in the
IPv4 Internet and that may result in a longer path.
</t>
<texttable anchor="ttl_table" title="Native IPv6 RTT Information in msec">
<ttcol>Hop count</ttcol>
<ttcol>IPv4</ttcol>
<ttcol>IPv6</ttcol>
<ttcol>Native IPv6</ttcol>

<c>Average</c>
<c>15.10</c>
<c>11.93</c>
<c>18.12</c>
</texttable>
</section><!--hops-->
<section anchor="mtu" title="MTU Comparaison">
<t>
We obtained more than 190,000 MTU statistics about IPv6 peers and more than
1,800,000 about IPv4 peers, which gives us a sufficient sample.
</t>
<t>
<xref target="mtu_table"/> shows the different MTU results depending on the IP version and whether
the path MTU discovery reached the destination. Unsurprisingly, the global IPv6
MTU is far smaller than the IPv4 one as more than 98% of the addresses where formed
thanks to a tunneling mechanism. The results of the native IPv6 peers are much higher
but are still inferior to those of IPv4.
</t>
<texttable anchor="mtu_table" title="Native IPv6 RTT Information in msec">
<ttcol>MTU</ttcol>
<ttcol>IPv4</ttcol>
<ttcol>IPv6</ttcol>
<ttcol>Native IPv6</ttcol>

<c>Average</c>
<c>1,497.6</c>
<c>1,288.9</c>
<c>1,468.0</c>
</texttable>
</section><!--mtu-->
<section anchor="evolution" title="Monthly Evolution">
<t>
The monthly analysis done in 2009, shown in <xref target="evolution_tab"/>, 
allows us to see this decrease more
clearly with 1.7% lost between the month of June and July. As July is a holiday month,
the sharing habits may be different. As a matter of fact, most downloaders are students.
However, this hypothesis does not explain why the IPv6 traffic decreases. The fact that
Universities, which may have IPv6 connectivity, may be closed during the holidays
and thus prevent students from using their bandwidth cannot explain this reduction as
the percentage of IPv6 traffic coming from Universities is very low. Nevertheless, this
decline from the Universities exists as IPv6 traffic in July diminished by more than
three times when compared to results in June. 
</t>
<t>
Once more the peers
that were solely discovered via DHT are not taken into account in the IPv6 evolution
analysis.
</t>
<texttable anchor="evolution_tab" title="Monthly Evolution of IPv6 vs IPv4 peers">
<ttcol></ttcol>
<ttcol>May 2009</ttcol>
<ttcol>June 2009</ttcol>
<ttcol>July 2009</ttcol>
<ttcol>October 2009</ttcol>

<c>%-age of IPv6 peers</c>
<c>4.50</c>
<c>4.79</c>
<c>3.10</c>
<c>2.30</c>

</texttable>
</section><!--evolution-->
<section anchor="protocols" title="Protocols Used to Discover Peers">
<t>
In this section we will look at the effectiveness of the different protocols to discover
peers. As we can see in <xref target="protocols_tab"/>, PEX is globally far more effective to find peers than
other means. It is even more efficient for IPv6 in comparison with the performance of
trackers.
</t>
<texttable anchor="protocols_tab" title="Number of Valid Peers Discovered by Protocol">
<ttcol>Source</ttcol>
<ttcol>IPv4</ttcol>
<ttcol>IPv6</ttcol>
<ttcol>Total</ttcol>

<c>Tracker</c>
<c>1,550,023</c>
<c>37,745</c>
<c>1,587,768</c>

<c>PEX</c>
<c>3,558,648</c>
<c>167,606</c>
<c>3,726,254</c>

<c>DHT</c>
<c>843,353</c>
<c>0</c>
<c>843,353</c>

<c>LSD</c>
<c>0</c>
<c>0</c>
<c>0</c>
</texttable>
<t>
Concerning DHT, we have never been able to get IPv6 peers by this means because
of incompatibilities between BitTorrent clients and because of problems in the LibTorrent
Rasterbar library. But if we look at the <xref target="protocols_tab"/>, 
the DHT results are not as good as
the other means.
</t>
<t>
The good performance of PEX can be explained by its exponential way of functioning.
As a matter of fact, via a small number of peers a large number of peers can
be reached. However, as already explained, the proportion of disposable information is
very important.
</t>
<t>
We did not receive any peers via LSD either since no other computer was running
a BitTorrent client in the local network. Nevertheless, it was functioning during all our
study.
</t>
</section><!--protocols-->
</section> <!-- measures -->

<section title="IANA Considerations">


   <t>There are no extra IANA consideration for this document.
   </t>

</section><!--IANA-->

<section title="Security Considerations">

   <t>This I-D does not describe any specific protocol, so, the security section is mostly irrelevant.   
   The measures were done with the specific security issues in mind:
   <list style="symbols">
		<t>copyrighted content: only a first fragment is downloaded and never stored on long term storage,
			so, it is assumed that even if copyrighted content is actually received it will never be
			user or propagated further to other peers;</t>
		<t>denial of services: timers and rate limiters are used when getting the list of torrents
		from our directory, when contacting other peers, and so on</t>
   </list>
   </t> 

</section><!--security-->

<section title="Acknowledgements">

  <t>
  Many thanks to Professor Guy Leduc of the University of Liege 
  and his research assistants, Cyril Soldani and Sylvain Martin.
  Martin is also grateful to Arvid Norberg who implemented the LibTorrent Rasterbar
library [<xref target="TFE23"/>]. We also exchanged ideas with Nathan Ward.
  </t>

</section><!--ack-->

</middle>

<!-- =============================================================== -->

<back>
 <!-- References split into informative and normative -->
 
<references title="Normative References">

	<reference anchor="TFE5" 
		target="http://www.bittorrent.org/beps/bep_0003.html">
		<front>
		<title>The BitTorrent Protocol Specification</title>
		<author surname="Cohen" initials="B."/>
		<date year="2008"/>
		</front>
	</reference>

	
	<reference anchor="TFE12"
		target="http://www.bittorrent.org/beps/bep_0007.html">
		<front>
		<title>IPv6 Tracker Extension</title>
		<author surname="Hazel" initials="G."/>
		<date month="May" year="2008"/>
		</front>
	</reference>
	
	<reference anchor="TFE13">
		<front>
		<title>Kademlia : A Peer-to-peer Information System Based on the XOR Metric</title>
		<author surname="Maymounkov" initials="P."/>
		</front>
	</reference>
	
	<reference anchor="TFE28" target="http://www.sixxs.net/tools/aiccu/brokers/">
		<front>
		<title>List of Tunnel Brokers</title>
		<author surname="SixXs"/>
		</front>
	</reference>
	
	<reference anchor="TFE29" 
		target="http://www.ipv6tf.org/index.php?page=using/connectivity/test">
		<front>
		<title>List of Tunnel Brokers</title>
		<author surname="IPv6 Task Force"/>
		</front>
	</reference>
	
</references>

<references title="Informative References">
	
	<reference anchor="TFE3">
		<front>
		<title>Internet Study 2008/2009</title>
		<author surname="Schulze" initials="H."/>
		<date year="2009"/>
		</front>
	</reference>
	
	<reference anchor="TFE23" target="http://www.rasterbar.com/products/libtorrent/">
		<front>
		<title>LibTorrent Rasterbar Library</title>
		<author surname="Norberg" initials="Arvid"/>
		</front>
	</reference>
	
	<reference anchor="THESIS">
		<front>
		<title>Measure and Analysis of IPv6
Traffic in Peer-to-Peer Networks.
Master Thesis</title>
		<author surname="Defeche" initials="M">
			<organization>University of Liege</organization>
		</author>
		<date month="August" year="2009"/>
		</front>
	</reference>
	
	&RFC3056;
	&RFC3484;
	&RFC4212;
	&RFC4380;
	  
</references>

</back>

</rfc>


