Recently I’ve made some tests how to connect to 6LoWPAN nodes in home LAN environment, using ordinary PCs. I’ve been using Grinch Border Router described in previous entries. The main aim was to use no static routes to send traffic to wireless nodes - I’ve tried to use only Router Discovery.
In general, avoiding manual configuration of networks is a hot topic nowadays - not only in Wireless Sensor Networks. There are many problems to solve:
-
Prefix delegation
-
Service discovery
-
Interaction with sleeping or mobile nodes
The problems above are also present for the home LANs. The basic RFC4861 Neighbor Discovery is quite limited and it’s hard to achieve a fully functional LAN with Internet connection using only that (without DHCP). However most new solutions are not supported by common everyday devices found in LANs (like PCs or smartphones). Grinch Border Router is no exception to that - it is a very basic device, and with 8kb of RAM it is not capable of any complicated techniques.
LAN physical setup
I’ve assembled a simple Home LAN as a testbed. Physical setup of the testbed is shown on a picture below - as you can see it is not very realistic (for a typical household) - as it includes a separate switch and wireless router - I’ll explain that below:
The testbed contains two PCs, D-Link 5-port switch, Grinch Border Router, Atmel Raven board and a D-Link DIR-600 wireless router. Test LAN is based entirely on the switch. The wireless router is used only for IPv6 tunnel. At the beginning I planned to use the router for my LAN instead of switch (it would be a more realistic setup). However I decided to add a separate switch because of two reasons:
-
IPv4 traffic - wireless router is used for my primary IPv4 internet connection - and Grinch has no hardware packet filtering.
-
D-Link DIR-600 has some undocumented IPv6 ability. In theory it’s IPv4 only, but it sends Router Advertisements, and I was concerned that it would disturb the experiment.
LAN logical setup
Logical setup of the testbed is shown on a picture below - it is much more realistic than the physical one:
LAN contains one host (one of the laptops) and two routers - one connected to the IPv6 Internet and one connected to Wireless Sensor Network. On the WSN side there is a single node with HTTP webserver (Raven) and RPL is used for routing. For the IPv6 Internet connection Freenet6 GoGo Client is used - I have no public IP therefore normal tunnel won’t work. Through GoGo client /56 prefix is received. LAN uses the first /64 subnet in the prefix, WSN uses the second one.
Problem formulation
When aiming for a zero-configuration connection to WSN nodes in home LAN, one of the main problems is choosing the right router for outgoing transmissions. In LAN like above, a host gets Router Advertisements from both WSN and Internet routers, and saves their addresses in Default Router List. When IPv6-enabled host has more than one router in its Default Router List, it selects the router for outgoing traffic in round-robin fashion (RFC4861). In typical IPv6 operation it’s not a problem - if host chooses non-optimal router, the router sends a Redirect message to the host. Redirect tells the host to use other router for that particular destination. Host saves this information in its Destination Cache and next time it sends the traffic to the correct router. Routers need to know about each other and about accessible routes to send Redirects. Normally routers use some kind of dynamic routing protocol to inform each other about known routes (e.g., RIPng).
Contiki OS (used by Grinch border router) doesn’t support redirects, or any typical routing protocols. It’s not a big technical problem, as the simplest routing protocol - RIPng can be certainly operated by a router like Grinch (maybe with 16kb of RAM). However it’s not the only problem. Typical IPv4 home routers don’t support any kind of routing protocol - they are simple gateways which send traffic to a default route. There are no “typical IPv6 home routers” on the market yet - only “IPv6 enabled routers”, but existing guidelines for home routers don’t contain routing protocol support as a mandatory functionality (RFC6024). Windows operating system also doesn’t support any dynamic routing protocols in Home Edition. At the moment probably the only IPv6 home router solution with RIPng support are special OpenWRT and DD-WRT builds. It might in a couple of years lead to a situation where Internet of Things home deployment is hampered by lack of proper router functionality.
Partial solution - Route Information Options
I’ve decided to look for another solution and found a nice candidate. RFC4191 contains an extension of original Neighbor Discovery which allows adding Route Information Option to Router Advertisements. Router can use this option to inform hosts on a network about routes it knows about. However the router should not use Route Information Option to send its whole routing table to all hosts - it should only advertise specific, important routes. The WSN border router is exactly such case - it should include the route to the WSN in its RAs.
Advantages:
-
doesn’t require any configuration on hosts
-
allows hosts to send traffic to the best router straight away, without waiting for a redirect.
-
no need for a dynamic routing protocol
Disadvantages
-
doesn’t provide WSN-to-Internet connectivity (for that routing protocol is required)
-
not supported in most systems (see below)
Route Information Options for Grinch
Adding RFC4191 support to Grinch was quite trivial - the router only has to send Router Advertisements with an additional bit flag, and Route Information Option. The implementation is compatible with multiple interfaces extension added to Grinch earlier. I’ve added another structure that holds all information necessary for RIOs (uip_ds6_route_info). Because of that the code is not very well optimized for RAM usage. It is possible to implement a more efficient approach, that would use pointers to prefixes held in Prefix Table or Routing Table, but Routing Table doesn’t contain lifetime necessary for the RIO, so still some kind of additional structure is necessary. Other solution is to change Contiki Routing Table to contain route lifetime - it’s used by RPL anyway.
Modified code is available in Git repository::
RIO tests
I’ve run some tests with RFC4191 enabled Grinch. The border router was set to send Router Advertisements with Prefix Information Option containing LAN prefix, and Route Information Option containing WSN prefix. The LAN prefix was also advertised by the laptop running freenet6 client (“Internet router”). Grinch was tested with four kinds of devices - results below:
-
Laptop with Windows XP - IPv6 has to be enabled on the laptop before any experiments. Laptop receives modified Router Advertisements from Grinch correctly and adds a route to WSN to its routing table. It’s immediately possible to ping Raven board after that. However Windows XP doesn’t support IPv6 DNS, so it’s impossible to connect to
ipv6.google.comeven after adding DNS server manually. Fail. -
Laptop with Ubuntu 11.04 - Internet connectivity works after adding DNS manually. However there is no RFC4191 support in Ubuntu. Fail.
Update (April 3, 2012)
Ubuntu 11.10 has RFC4191 support in default build. Route Information Option support is disabled by default. To enable it you need to add two lines to your /etc/sysctl.conf:
net.ipv6.conf.eth0.accept_ra=1 net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 64 -
Android 2.2 - for that test I modified the LAN physical setup, and used wireless router instead of switch. Then I connected the phone to WLAN using WiFi. My phone received IPv6 address but it had no applications that could use IPv6 - even ping. Also it didn’t support RFC4191. Android really needs better IPv6 support. Fail.
-
Laptop with Windows 7 - Internet connectivity works after adding DNS manually. Also laptop receives Router Advertisements with RIO from Grinch correctly and adds a route to WSN to its routing table. However the network is not very stable - pings are sometimes lost for no reason.
Further tests with Windows 7
After playing with the network a bit more I’ve determined that two more details in Grinch software had to be changed:
-
Neighbor Advertisement Router Flag - in Grinch NAs it was set to zero (default for Contiki). That caused the laptop to remove all entries related to Grinch from the Routing Table. It caused periodic “flapping” of the routing table - sometimes pings worked, and a while later they didn’t. After changing the Router Flag to 1, the flapping behavior disappeared.
-
Router Advertisement Router Lifetime - any non-zero value made Grinch to be added to Default Router List on the laptop. It sometimes caused the Internet traffic to be directed to Grinch (with no Redirect ability). This could totally break down Internet connectivity for the laptop. After changing Router Lifetime in Grinch RAs to zero, it is no longer considered a candidate for a Default Router, but Route Information Options still work.
With these changes the solution can be considered successful - I’ve tested it with my wife’s new Windows 7 laptop (with vanilla OS), and it connected to Raven without any problems. Connection to ipv6.google.com required manual DNS setup. Both changes are included in the Git code above.