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

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.

Finding rogue IPv6 routers on Mac OS X

In one of the larger wireless campus networks there was a problem of an annoying host advertising 6to4 (2002) and fec0 prefixes to a network segment which already had an official IPv6 router. This is the same kind a situation as rogue DHCP server in IPv4 network. All traffic is sent to go through the advertising host and if that can either route or drop the traffic making IPv6 services slow or unusable. There exists few extensions for IPv6 to secure router advertisements and only accept proper ones, but those extensions are rarely implemented in the mobile devices.

So to find the owner of the misbehaving host, one option is to find the IPv4 address from the 6to4 prefix and inform NOC (Network Operations Center) about it. In 6to4 addresses the original IPv4 address is part of the IPv6 address so we can find out the corresponding IPv4 address this way (example IPv6 prefix 2002:c0a8:2a2a::/48):

% printf "%d\n" 0xc0
192
% printf "%d\n" 0xa8
168
% printf "%d\n" 0x2a
42

The IPv4 address corresponding to 2002:c0a8:2a3a::/48 prefix is thus 192.168.42.42. The IPv4 address is often enough to find the host and its owner, but in large wireless networks the IPv4 addresses may get reassigned so also the time of the problem must be recorded. Then the host and owner can be checked from the DHCP server logs or from the wireless network management system such as Airwave.

There exists also a way to identify the host faster and that is to find out its ethernet mac address. In IPv4 there is ARP, which is used to find out the mac addresses of the corresponding IPv4 addresses. In IPv6 the similar protocol is called Neighbor Discovery Protocol (NDP). The problem was where and how to find this information. In Linux it is possible to use ip utility for this (the addresses in these example are not related to the 6to4 culprit):

% ip -6 neighbor list
fe80::224:36ff:fe9d:c1dc dev br0 lladdr 00:24:36:9d:c1:dc router REACHABLE

It took me for a while to find out what I could use on Mac OS X, but the manual pages hinted that Mac OS X's IPv6 stack conformed to the NetBSD implementation documentation found at:

• http://www.netbsd.org/docs/network/ipv6/
  

The command needed for neighbor discovery protocol control on Mac OS X is called ndp. With this command it is possible to display and manipulate neighbor discovery protocol tables and find out the corresponding ethernet mac addressed for default router IPv6 addresses (listed with netstat -nr):

% netstat -nr
Internet6:
Destination                             Gateway                         Flags      Netif Expire
default                                 fe80::212:3400:9c56:7890%en1    UGc         en1
% ndp -a
Neighbor                        Linklayer Address  Netif Expire    St Flgs Prbs
fe80::212:3400:9c56:7890%en1    0:12:34:56:78:90     en1 23h59m9s  S  R

The more hardcore IPv6 specialists may read the ethernet mac address directly from the link level IPv6 address. The problem is that the link level address may not be always formed from the actual linklayer address so this method is preferable and also a bit more friendlier to user

IPv6 and Arch Red

Arch Red is now fully IPv6 connected. Web pages, email and DNS are most visible to everyone but also less used and internal services such as routing, RADIUS and centralized authentication run on IPv6 now. The latest addition was web availability over IPv6, so we can now consider ourselves as IPv6 enabled.

Why now? Is now the time to start using IPv6? From the technical perspective IPv6 is mostly ready. Some applications and services such as VPN could still be more widely available. There is time to fix these problems, but the according to the projections, IPv4 addresses can only be distributed using the current policy for a relatively short time. For Arch Red's people IPv6 is something we have done for years. Since we consider IPv6 as one of our areas of competence, this is the right time for us.

Based on our own experiences, it is of utmost importance to make your services ready before publishing them to others. Publishing usually means adding IPv6 information to DNS or by some other means advertising your IPv6 availability. This advice about readiness is almost a cliche. As the dictionary says: overused and has thus lost its original impact. Even if this is well known, IPv6 services often do not function as well as their IPv4 counterparts.

There are many things that could be said about IPv6 but now is not the time anymore to roll out barely functional IPv6 services. There are already users out there and more and more are using IPv6 each day.