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

eduroam(tm) expands in Japan

RADIUS based authentication roaming federation eduroam(tm) expands in Japan according to Terena's translated news item. The expansion is done in cooperation between the Japanese National Institute of Informatics (NII) and Livedoor, a Japanese provider of commercial WLAN services.

These kind of cooperation announcements give additional validation to Arch Red's vision on utilising eduroam(tm) tried technology to increase community network coverage through roaming instead of building overlapping Wi-Fi networks or trying to form only one dominating one.

Karri Huhtanen presenting at TREX Workshop 2010

Karri Huhtanen is presenting ICT SHOK Future Internet Testbed, Wireless Tampere and Funet WLAN roaming today on 19th of February at TREX Workshop 2010.

Guest Server 2.8.0 released

Arch Red Guest Server version 2.8.0 is now available. The version number jump from 2.6.x is an indication of a substantial change: the guest server now handles the time in UTC (Coordinated Universal Time). The user interface stays the same, but the users are now associated with a time zone. This change helps organisations that operate on multiple time zones. For example, the user can be located in Finland while the Guest Server runs in the headquarters in Australia's Adelaide *.

The user associated time zones add to the Guest Server's existing support for internationalization and localization. Global organisations can better serve their customers internally and those who want to run guest sever as a service can now offer their service word wide.

Other changes include enhanced support for multiple languages and easier Guest Server installation. Also included is the previously blogged support for duration for all guest account types.

* The normal time in Finland is UTC+2 while Adelaide in southern central Australia uses UTC +9:30. Both observe daylight savings time, but one has to remember that southern hemisphere switches to DST during the autumn while northern hemisphere changes during the spring, as seen from Finland. The exact time difference between Finland and southern central Australia is left as an excercise for the reader ...

Publications added

Publications have now been added in English and in Finnish. We usually try to keep the content on our web pages similar, but this time please see the both. For example, the comprehensive IPv6 and NAT material is only in Finnish.

The topics include papers, tutorials, white papers and reports on WLANs, user authentication, roaming and other networking issues.

This is a good start and more will be available later.

Products and examples - see things that Arch Red does

Product summaries page comes from the experience gathered from the presentations and courses we have given. There is always the moment when the topics are put together, so why not look at the products as a whole too? We already had the products listed individually, and now the summary page shows how they relate to each other, how they can be used to build complete systems and the possibilities to use them with products from others.

Besides products, the page has also architecture design examples. Our products are based on the knowledge we have about what works and what are the right building blocks for a successful design. Depending on the needs of the customer we can use our own products or choose something from the other vendors. Like the examples show, we do not always try to build everything from scratch, but take whatever works best for reaching the requirements.

Going on Tour with Netti-Nysse and Wireless Tampere

Our company does various things. We of course have our products, services and the R&D centered around them, but we have also our hobby projects -- the projects which we do because of their challenges and also because sometimes it is just fun. Tampere City Library's Internet Bus, Netti-Nysse, is one of those projects we are not just doing for money, but because it has its own challenges and it is fun to utilise our expertise to make the concept grow better.

I am currently writing this sitting in the Netti-Nysse's lecture space somewhere near Venice and on route to Ljublana Slovenia. My mission here is to support the Netti-Nysse team in ICT issues such as the handling of the bus's central Linux server and getting Internet connectivity and bandwidth for the bus wherever and however we can. You might think that's an easy task, just add 3G HSPA modems, but the roaming costs of 1.5 EUR/MB do not exactly encourage utilising that kind of connectivity. So mostly it is just WiFi we already are and will be using.

I have also a mission from Wireless Tampere to promote its open cooperative concept of wireless community network to Tampere's partner cities and at the same time I hope I will be able to find new cooperation, contacts, ideas and even roaming agreements between existing city-wide or municipial wireless networks.

Karri Huhtanen (Arch Red Oy)
Internet Roadie