<?xml version="1.0" standalone="no"?>
                    <!DOCTYPE div SYSTEM "/www/backend/www-xml-443/dtd/caidaML.dtd">
                    <!-- do NOT ERASE the DOCTYPE declaration! --><div>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>URL:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<a href="http://www.caida.org/publications/papers/2004/dualstack/">http://www.caida.org/publications/papers/2004/dualstack/</a>
</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Entry Date:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
2004-07-16


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>Abstract:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<p>
One of the major hurdles limiting IPv6 adoption is the existence of
poorly managed experimental IPv6 sites that negatively affect the
perceived quality of the IPv6 Internet. 
To assist network operators in improving IPv6 networks,
we are exploring methods to identify wide-area IPv6 network problems.
Our approach makes use of parallel IPv4 and IPv6 connectivity to
dual-stacked nodes.
</p>

<p>
We identify the existence of an IPv6 path problem by comparing IPv6
delay measurements to IPv4 delay measurements.
Our test results indicate that the majority of IPv6 paths have
delay characteristics comparable to those of IPv4,
although a small number of paths exhibit a much larger delay with IPv6.
Thus, we hope to improve the quality of the IPv6 Internet by identifying
the worst set of problems.
</p>

<p>
Our methodology is simple.
We create a list of systems with IPv6 and IPv4 addresses in actual use
by monitoring DNS messages.
We then measure delay to each address in order to select a few systems
per site based on their IPv6:IPv4 response-time ratios.
Finally, we run traceroute with Path MTU discovery to the selected systems
and then visualize the results for comparative path analysis.
This paper presents the tools used to support this study, and the results
of our measurements conducted from two locations in Japan and one in Spain.
</p>


</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Datasets:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
Data was collected by measurement from three locations in June, 2004.
The three locations are 1) WIDE, a research network in Tokyo,
Japan; 2) IIJ, an ISP providing commercial IPv6 services in Tokyo,
Japan; and 3) Consulintel, in Madrid, Spain,
directly connected to MAD6IX that is part of Euro6IX.


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>Experiments:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
We create a list of systems with IPv6 and IPv4 addresses in actual use
by monitoring DNS messages.
We then measure delay to each address in order to select a few systems
per site based on their IPv6:IPv4 response-time ratios.
Finally, we run traceroute with Path MTU discovery to the selected systems
and then visualize the results for comparative path analysis.


</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Results:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<ul>
   <li>We identify the existence of an IPv6 path problem by comparing IPv6
   delay measurements to IPv4 delay measurements.
   Our test results indicate that the majority of IPv6 paths have
   delay characteristics comparable to those of IPv4,
   although a small number of paths exhibit a much larger delay with IPv6.
   Thus, we hope to improve the quality of the IPv6 Internet by identifying
   the worst set of problems.</li>
</ul>


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>References:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<ul>
  <li> L. Colitti, G. D. Battista, and M. Patrignani,
  "IPv6-in-IPv4 tunnel discovery: methods and experimental results,"
  IEEE Transactions on Network and Service Management, 1(1), Apr. 2004.</li>
</ul>



</font>
  </td>
</tr>
</div>

