Previously, there were minor problems in the use of IPv6 that could impose strong bad impression on Internet users even though IPv6 worked well in most cases. The IPv6-Fix activity [1] has been trying to resolve such problems as much as possible by:
Specific goals of the IPv6-Fix activity were as follows:
In the IPv6-Fix activity, we have collected problem incidents and published the information as a per-product database; in particular, we analyzed a well-known connectivity problem with the "captive portal" system used for Internet connectivity services at hotels as a common problematic scenario, and tried to investigate the cause and solve it in the following areas:
In addition, we also planned to explore the following subjects from a more generic point of view:
We set up a database web page about products that had a problem. The information shown in that page contributed to having the vendor fix it in a new version.
There was a problem in the specification that could be a problem in dual-use of IPv4 and IPv6, which was summarized in one of our documents (among materials published by other groups). The problematic specification has been fixed through a recent standardization process, and implementations have been fixed accordingly.
We summarized problems related to DNS servers and resolvers (clients) with proposed counter measures in an RFC[2], in academic papers [3,4,5], and in our web page. We also planned to ask operators who used problematic implementations for fixing the problem; however, we have not actually done that because there were only few problematic implementations, client implementations have introduced workaround, and there was an operational/political barrier to get access to the operators.
The well-known name space for IPv6 reverse mappings had been completely migrated from ip6.int to ip6.arpa; the former was removed from the domain name space in June 2006. We summarized possible issues that could happen with the migration as well as implementation status about the support for the new domain name. There was actually no known confusion during the migration or after the deprecation of ip6.int.
We clarified an issue in the protocol specification that could cause a problem along with existing implementation behaviors. We also suggested how to solve or avoid the problem in the implementation side. There was also a known problem that prohibited a TCP connection from being established smoothly in a large closed network, but such a special network has employed a workaround to mitigate the problem. We believe this type of problem has largely become minor through the implementation changes and operational workaround.
We developed a method and tool to assess the network quality.
We have not achieved an outstanding result in this area; however, the issues are now widely recognized, which has led to other activities such as the one by ICANN to collect information about the problem [6].
In the IPv6-Fix activity, we have worked on analyzing various problems in the deployment of IPv6 that were often seen in captive portal systems, identifying the real cause of the problems, and fixing them as much as possible through our own development efforts or by reporting the problem to vendors. We have suggested technical solutions to the known problems in various aspects and provided developers and operators with feedback from the activity experiences. As a result, typical troubles such as slower web browsing have been less common. Therefore, we conclude that major problems that the IPv6-Fix activity originally aimed to solve have been well settled.
We will continue to assess the quality of the IPv6 Internet as a long term activity. We will also keep maintaining the production database for the moment.
IPv6-Fix Homepage
Common Misbehavior Against DNS Queries for IPv6 Addresses,RFC4074, May 2005.
IPv6-Fix: For the Life with IPv6,IPSJ Magazine, Vol.46 No.8, pp.887-893, Aug. 2005.
Problems on IPv4-IPv6 Network Transition,SAINT2006, Phoenix, Arizona, USA, January 2006.
Fixing DNS Misbehavior Hindering IPv6 Deployment,SAINT2006 IPv6 Workshop, Phoenix, Arizona, USA, January 2006.
Testing Firewalls for IPv6 and EDNS0 Support.
Copyright (C) WIDE Project (2007). All Rights Reserved.