Microsoft recommends _not_ to disable IPv6

In IPv6 seminars you often hear the claim that Microsoft recommends not to disable IPv6. The source for this recommendation is not often presented, but now I did look it up for further reference and discussion with IT departments, which disable IPv6 from their computers.

The Argument against Disabling IPv6

It is unfortunate that some organizations disable IPv6 on their computers running Windows Vista or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.

From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.

Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.

-- Joseph Davies in Microsoft Technet article: http://technet.microsoft.com/en-us/library/2009.07.cableguy.aspx

Open System Consultants Ltd. and Arch Red Ltd. to enhance Radiator expert services via cooperation agreement

Open System Consultants, the maker of the "Swiss Army knife of RADIUS Servers" and Finnish Internet architecture expertise company Arch Red have signed a joint agreement to strengthen their cooperation in providing expert services based on OSC's Radiator RADIUS server.

Arch Red brings 8 years experience with Radiator, building RADIUS implementations for eduroam(tm) in Finland, its commercial application, the Wireless Tampere community network as well as for traditional Internet and mobile service providers.

The new closer cooperation between Open System Consultants and Arch Red provides new opportunities for both expert services and product development, Arch Red managing Director, Karri Huhtanen says.

Mike McCauley, OSC's managing director welcomes the synergies this new cooperation offers. With Arch Red's application experience, we can together provide the highest quality access solutions and technical support to our mutual customers.

Cloud Computing Business Models

As a part of my postgraduate studies I attended a TUT seminar course about cloud computing and chose to do my presentation about the cloud computing business models. Obviously this only covers only small part of them, but the presentation gives a general idea about what models are available and on what level of cloud computing solutions (IaaS, PaaS, SaaS etc.).

Cloud Computing Business Models

View more presentations from khuhtanen.

Feel free to comment or ask questions about the presentation and I will try to answer them in the comments.

Arch Red Guest Server v3.0 is coming

A new version (v3.0.0) of Arch Red's guest management software (Arch Red Guest Server v3.0) is nearing its release. A pre-release demo version (2.9.13) is already installed to our demo site. For more information about the demo and user credentials see:

http://www.archred.com/products/arch-red-guest-server/arch-red-guest-server-demo

Arch Red Blog is now IPv6 enabled

Yesterday we found out a way to enable IPv6 for our Google hosted services such as our English and Finnish blogs.

It seems that while Google only enables IPv6 on its on services by request of the IPv6 service provider or IPv6 block owner, it is possible to enable IPv6 on those Google hosted services which are offered under your own domain name.

Since Arch Red blogs are under our own domain name service (archred.com and archred.fi), we can allow them to be accessed also with IPv6 with a simple change in DNS by changing CNAME for them to point to ghs46.google.com instead of IPv4-only ghs.google.com.

Heikki changed our DNS already yesterday and you should be now able to read even this blog entry over IPv6.

ICT SHOK Future Internet Testbed Architecture v2.0 published

Together with CSC, TUT also had a poster about ICT SHOK Future Internet Testbed here at Terena Networking Conference. Earlier we had only few printed copies of the testbed architecture document available, but now the same document is also published in the Internet at address:

http://www.futureinternet.fi/publications/ict-shok-future-internet-testbed-architecture-v20-web-version.pdf

The central idea with our testbed is that instead of building yet another testbed, we will combine existing and new services into a concept, which is supposed to grow and evolve serving various research programs and cooperation both in Finland and abroad.

If you are interested to learn more about our concept, check the architecture specification or contact either me or CSC's Jari Miettinen or Pekka Savola.

Debugging eduroam at TNC2010

Yesterday Matti was having trouble with Helsinki University user accounts and the eduroam network here at TNC2010. Together with few eduroam guys (Stefan Winter and Miroslav Milinovic) and Heikki Vatiainen from our company we tried to find out why the authentication process did not seem to go through. What made it harder was that for example Radiator does not log enough information about failing authentication process unless it clearly ends in success or failure. Increasing log level to debug levels of course helps and we were able to see that the Helsinki University RADIUS server did send response messages to authentication requests even if the process did not go through.

Other servers in Finland worked fine (I have been able to use eduroam the whole time with my TUT accounts) and only difference we first found was that Helsinki University certificate was bigger than the ones in some of the working organisations. This lead us to suspect RADIUS message fragmentation problems somewhere in between European Top Level RADIUS and Matti's device. We then remembered the one Radiator configuration directive, which we found was missing from Helsinki University RADIUS server configuration.

Adding EAPTLS_MaxFragmentSize 1024 solved this problem so if you are having similar problems with eduroam and your home organisation is running Radiator RADIUS, we suggest checking at least this setting found in Radiator manual:

EAPTLS_MaxFragmentSize

For TLS based EAP types such as TLS, TTLS and PEAP, this optional parameter specifies the maximum size in octets permitted for each TLS message fragment. Defaults to 2048, but many EAP clients, routers and wireless Access Points have limitations that require EAPTLS_MaxFragmentSize to be set as low as 1000 or less. Setting this number too small can result in excessive RADIUS request round trips during EAP TLS authentication, slowing down the authentication process. Setting this number too large can result in failure to complete TLS authentication for some types of clients and devices.